CFDI 4.0, postergado, pero hay trabajo por hacer

Bueno, finalmente (como siempre) el SAT hace prorroga de la entrada en vigor de un estándar nuevo para la factura electrónica.

La nueva fecha será el 1ro de enero de 2023.

Entre los principales cambios es que ahora si es obligatorio el domicilio fiscal tanto de emisor como de receptor. Esto implica adecuaciones en los campos en Company Information y Customer sin importar si es de ahí de donde llamamos los datos para el archivo o desde la factura registrada, como sea, deberemos asegurarnos de no mandar caracteres raros que no sean soportados en el estándar de xml (validación de datos/caracteres en campos).

Lo de los múltiples CFDIs relacionados para sustitución, será algo complicado al tener la opción de que una factura sustituya a varias creando así una relación de uno a muchos (1:n).

Cambios en la generación del complemento para pagos (2.0) con ajustes para identificar si los pagos son sujetos a impuesto y cuales, y cuánto. Esto podría ser sencillo al hacer el pago en el diario de pagos liquidando contra la factura previamente registrada, pero ¿qué pasa en pagos anticipados sin factura de anticipo? ¿creamos una provisión de impuestos al 16% y agregamos esa información al complemento? ¿O simplemente no lo declaramos en el momento del pago, pero si al liquidar la factura contra dicho anticipo? Al parecer, deberemos de utilizar la factura de anticipo y exigirla al proveedor si quiere dinero por delante.

En la cancelación del CFDI se debe establecer el motivo, mayor razón para no cancelar en NAV/BC, se que implica pagos de ISR pero recordemos que el proceso “mas correcto” seria cancelar el CFDI en el SAT y luego hacer una nota de crédito interna para liquidarla contra la factura con CFDI ya cancelada, sin embargo, deberíamos igualmente llenar los datos resultado de la cancelación en dicha nota de crédito interna para control de folios, UUIDs y toda esa parafernalia.

Para exportar, complemento de exportación que en si mismo ya es algo y luego agregar un atributo más al CFDI.

En la “solución” de Microsoft se creó un campo de “Uso de CFDI”, bueno, se debe eliminar el “Por Definir”.

También hay que tomar en cuenta los cambios para facturación global y a cuenta de terceros

Ahora bien, ¿qué es lo que se debe hacer? sencillo, adecuar el sistema a la nueva versión. Para esto, los caminos dependen de varias cosas:

Versión de sistema – Si es NAV o Business Central difiere tanto a nivel código como a nivel conexión

PAC – Cada Proveedor Autorizado de Certificación tiene su método de conexión además de estructura y tipo de archivo.

Veamos el primer tema, si es NAV el sistema que tenemos, normalmente estará on-premise por lo que la adecuación es más sencilla, así como la conexión a los servicios del PAC pudiendo ser vía FTP, Web Services o una app local instalada en el servidor.

Se deben agregar los campos necesarios en los pedidos de venta (tablas 36 y 37) así como los de remisiones y los de facturación (112 y 113), agregar más datos en la tabla de clientes, productos y finalmente conjuntar todo eso en las tablas de facturación para poder generar el archivo a “subir” con el PAC.

Esto lógicamente requiere el uso de un ambiente de pruebas del ERP así como del PAC para validar estructura del archivo a subir, los datos subidos, recibir la respuesta y verificar que todo está ok. La parte de negociar con el PAC el área de pruebas, queda en el cliente, lo demás, lo debe hacer el departamento interno de desarrollo o el partner contratado, incluyendo las pruebas.

Al ser un desarrollo “a la antigua”, es decir, sin ser extensiones, debe ser realizado para cada cliente ya que normalmente esas instalaciones tienen sus “particularidades”.

¿Qué pasa con Business Central?

Bueno, dependerá de si fue desarrollo especial o si es una extensión.

Normalmente una extensión simplemente se actualizará a una nueva versión agregando campos y comportamientos, si revisamos nuestra administración de extensiones, podremos ver algo como

“Facturación electrónica X versión 1.1.0.0”

Y después de la actualización, simplemente será versión 2.0.0.0 o un número superior al anterior. Esto nos permitirá detectar varias cosas:

• El fabricante de la extensión (normalmente el partner) está al día en su trabajo y obligaciones acorde al costo mensual de la extensión.
• La extensión realmente está estandarizada con un PAC y con el sistema.
• No es un desarrollo para mí que muy bien pude pagar pero que no está estandarizado.
• El partner ya realizó las pruebas con el PAC así que solo me informará que campos nuevos y que datos deben ser agregados y en que parte del proceso, todo esto, por escrito en un manual de actualización.

¿Y si no ocurre lo anterior?

Bueno, entonces es una “extensión” a la medida (antiguamente se le llamaba desarrollo) y al no estar estandarizado, implica que se deberá realizar lo mismo que se describió más arriba para NAV, hacer la nueva extensión ya sea adecuando la versión a las nuevas necesidades lo que implica remanufacturar el código existente, otra opción seria “extender la extensión” pero esto solo aplica cuando fue planeado así por el partner.

Una extensión “extensible” seria igualmente algo estandarizado con el PAC (o varios PACs) con una estructura base que sirva para todos, a partir de ahí, vendrían extensiones para conectar y recibir la respuesta la cual debería ser procesada acorde a la información que mande el PAC. entonces aquí entraría la extensión de la extensión para agregar las nuevas definiciones, pero, por consiguiente, la extensión de conexión al PAC debería ser extendida o remanufacturada, es decir, dependencias entre extensiones.

En todo caso, este nuevo estándar y los trabajos y tiempos derivados deberían estar cubiertos por el partner si:

El desarrollo fue vendido como extensión con pago mensual ya sea por empresa o usuario.

La “extensión” tiene una cuota mensual o anual de suscripción por concepto de mantenimiento.

¿Cuándo no estaría cubierto?

Lógicamente, hablando de los puntos anteriores, si hubiera algún pago no realizado, cosa casi imposible porque el partner podría inhabilitar la extensión a partir de la falta de pago.

Cuando el desarrollo en cuestión especifique claramente que cualquier adecuación futura tendrá costo ya que dicho desarrollo le pertenece al cliente (pensando en hacer un post sobre ese tema).

¿Qué sigue?

Si no has hecho nada aún, tienes tiempo de tomar en cuenta todo lo anterior y buscar una solución mas estandarizada a futuro para “solo esperar el cambio de versión o upgrade de la extensión”.