Errores en Generación de Eventos - AAH07 y AAH09

Por medio de este artículo daremos claridad sobre las reglas de rechazo AAH07 y AAH09 que se han estado presentado con la generación de los eventos en documentos electrónicos.

Contexto

La DIAN tiene definidos dos tipos de inconvenientes tecnológicos (03 y 04) ambos definidos en el Suplemento C: Inconvenientes tecnológicos del Anexo Técnico de Factura Electrónica de Venta (Versión 1.8, vigente a la fecha).

En el XML de una factura electrónica, se puede identificar en el campo InvoiceTypeCode el tipo de documento generado, por medio de un código. Ver los valores posibles en la siguiente imagen tomada del anexo técnico:

El código 03 se utiliza cuando el tipo de inconveniente presentado se origina en el software de facturación, también conocido como Contingencia del Facturador Electrónico.

El código 04 se utiliza cuando el tipo de inconveniente presentado es por parte de la DIAN, también conocido como Contingencia DIAN.

Este último tipo de inconveniente se encuentra definido en el numeral 12.2 del Anexo Técnico.

https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Resolucion-000012-09022021.pdf consultar la pág. 585.

Hemos identificado que cuando la DIAN se encuentra con intermitencias muchos proveedores tecnológicos están generando los documentos electrónicos bajo contingencia DIAN (Inconveniente Tecnológico Tipo 04)

Cuando el proveedor tecnológico notifica al cliente/adquiriente el documento emitido bajo Contingencia DIAN (Inconveniente Tecnológico Tipo 04), dicha factura llega al correo electrónico marcada con el código 04 en el campo: InvoiceTypeCode del XML Invoice (Factura Electrónica de Venta), con su respectivo CUFE.

Posteriormente, cuando la DIAN se estabiliza, los proveedores tecnológicos transmiten a la DIAN dicha factura de venta (con el mismo prefijo y número):

Escenario 1

Algunos al transmitir este documento modifican el valor del campo InvoiceTypeCode cambiando el valor 04 por el 01, y dejan el mismo valor del CUFE notificado al cliente.

Posteriormente, vuelven a notificar al cliente este documento electrónico con este cambio, es decir, en el correo del cliente/adquiriente quedan 2 correos asociados a una misma factura de venta, solo que el primero tiene en el XML el InvoiceTypeCode 04 y el segundo el InvoiceTypeCode 01.

¿Qué sucede en este caso?

Cuando se genera un evento, este internamente debe indicar a que factura de venta está relacionado, el tipo de factura (InvoiceTypeCode) y su CUFE.

Nuestro sistema tiene el XML de dicha factura con el InvoiceTypeCode 04 (ya que corresponde al primer correo que se procesó, el segundo correo falla en nuestro sistema porque identificamos que ese número de factura ya fue procesado, registrando dicho error en la ventana de Gestión de Documentos Recibidos).

En la DIAN esta factura quedó marcada con el InvoiceTypeCode 01

Cuando nuestro sistema envía el evento a la DIAN, dicha entidad genera el rechazo por la regla AAH09, ya que identifica diferencias en el InvoiceTypeCode.

Escenario 2

Otros proveedores tecnológicos, adicional al cambio del InvoiceTypeCode, también modifican el CUFE de la factura de venta que transmiten a la DIAN, y vuelven a notificar al cliente este documento electrónico con estos cambios (InvoiceTypeCode 01 y un nuevo valor en el CUFE), es decir, en el correo del cliente/adquiriente quedan 2 correos asociados a una misma factura de venta, solo que el primero tiene en el XML el InvoiceTypeCode 04 con CUFE ABC y el segundo el InvoiceTypeCode 01 con CUFE XYZ.

¿Qué sucede en este caso?

Cuando se genera un evento, este internamente debe indicar a que factura de venta está relacionado, el tipo de factura (InvoiceTypeCode) y su CUFE.

Nuestro sistema tiene el XML de dicha factura con el InvoiceTypeCode 04 y CUFE ABC (ya que corresponde al primer correo que se procesó, el segundo correo falla en nuestro sistema porque identificamos que ese número de factura ya fue procesado, registrando dicho error en la ventana de Gestión de Documentos Recibidos).

En la DIAN esta factura quedó marcada con el InvoiceTypeCode 01 y con el CUFE XYZ.

Cuando nuestro sistema envía el evento a la DIAN, dicha entidad genera el rechazo por la regla AAH07, ya que identifica diferencias en el CUFE de la factura relacionada.

Conclusiones

Lastimosamente, este es un error en el proceso de emisión del documento, ya que el documento que se notifique al cliente debe ser el mismo que se notifique a la DIAN, para así poder garantizar que el proceso de generación de eventos que deben realizar los clientes/adquirientes de dichas facturas sea exitoso (ya que al generar un evento se debe relacionar la información de la factura, y esta información debe ser consistente con la registrada en la DIAN)

Aclaramos que este no es un error de nuestro sistema, ya que al cliente se le notifica información diferente a la registrada en la DIAN, y al intentar generar los eventos con la información suministrada, la DIAN genera el rechazo por la inconsistencia en la información.

Como producto, estamos implementando una funcionalidad que le permita a estas compañías subsanar estos errores, permitiendo eliminar aquellos documentos que los presenten, para que puedan importar el documento que consideren sea el correcto (el notificado a la DIAN). Tan pronto liberemos dicha funcionalidad se los estaremos comunicando. Adicionalmente, consideramos que este tipo de errores debe ser solucionado desde el origen de los datos, es decir, los proveedores tecnológicos de los emisores de estos documentos deberían revisar la implementación del proceso de contingencia DIAN para garantizar que la información notificada al cliente y a la DIAN sean consistentes.