ValidaCFD

Sólo una observación a @Sinchi sobre su comentario

Sinchi escribió: ... Mirando otros campos veo que tambien se podria utilizar "referencia" del DomicilioFiscal, el cual es opcional, y por lo tanto casi ni se usa,
...

Pues en mi experiencia sí se utiliza. Hay personas en las que su domicilio fiscal no es una vía (calle, carretera, avenida, etc.). Como caso extremo vi uno en que su domicilio fiscal era "A 200 metros de la Conasupo" (caso real). Aunque su uso más frecuente es cuando al que se le factura quiere que se indique alguna referencia, por ejemplo, entre qué calles está la dirección.

Saludos.

Por lo que veo en este borrador, no hay planes de incorporar serie/folio (generalmente del ERP) como parte de la cadena original.
Es una lastima ya que esto impide a las empresas poder usar el serie/folio como parte del identificador unico de un CFDI.

Espero no sea una pregunta muy tonta pero más vale quedarse con la duda...

@Sinchi, @S3cr3to
¿Porque no se puede usar el folio como identificador único si no está presente en la cadena original al usar un ERP?

@django, si los puedes usar (hablando de los campos Serie y Folio).
El problema radica en que al no formar parte de la cadena original, esos campos pueden ser alterados y nadie puede saber que valores tenían originalmente. Y por lo mismo el sello no se altera pues se genera a partir de la cadena original.

Incluso el campo "moneda" es opcional, y cuando pido algun comprobante en dolares y veo que no le ponen la moneda (por limitaciones del programa del emisor) podemos colocar la moneda y así realizar alguna reimpresión o enlace correcto en la contabilidad.

Estas cosas que son opcionales puede que vuelvan a formar parte de la cadena original (v3.3 según parece) y no podrán ser alterados, ojalá que de como resultado un mejor control y evitar su mal uso.

El sat pide muchas tonterías en la contabilidad electrónica que no pueden ser "forzadas" a los emisores mientras existan algunos campos opcionales (moneda por ejemplo).

¿Porque no se puede usar el folio como identificador único si no está presente en la cadena original al usar un ERP?

Luego existe el caso donde si generas dos comprobantes semejantes con diferencias en todo excepto en milisegundos (los cuales se eliminan en la cadena) y distintos datos en campos serie+folio, estos comprobantes generan una cadena original exactamente igual, lo cual impide a los PACs timbrar ambas, pues detectan que intentas timbrar el mismo documento y solo timbran uno de ellos.

Ejemplo real: En nuestra ciudad el SIAPA (sistema de agua potable) genera el gran lote de comprobantes, en nuestro caso tenemos instalaciones que consumen la misma cantidad (digamos que es una cuota establecida) anda que nos han enviado recibos con diferente Folio y el mismo sello.
Conclusión: solo han facturado un solo recibo y el otro esa volando en el limbo.

Esto comenzó a ocurrir cuando el sat quito la serie y folio de la cadena original, nos paso incluso a nosotros, mi solución añadir el folio interno en los conceptos y libre de problemas. No creo que lo quite aunque vuelva obligatorio la serie y folio. Incluso ahora que vuelvan va a ser un problema volver a integrarlos, gracias chamuco.

Oh, ya me queda calro.

Muchas gracias por la aclaración!

Ayer salio la 3.3 y veo que ahora serie y folio, siguen siendo opcionales, pero si es que estan presentes son incluidos en la cadena original.

Aplausos para el SAT.

El Anexo 20 V3.3 dejo ya de ser un borrador, ya se publico el definitivo, chequenlo aqui