Recomendaciones para integraciones ante escenarios de intermitencia o Timeouts DIAN

Recomendaciones para integraciones ante escenarios de intermitencia o Timeouts DIAN

Ante escenarios de intermitencia o lentitud en la respuesta DIAN se describen:

Puntos de falla por timeout:

En un análisis de riesgo de falla decimos que debemos considerar 4 puntos principalmente de fuente de timeouts.

1. En el request enviado a TFHKA por parte del sistema: Este caso se identifica porque al volver a enviar un documento a nuestra plataforma o al consultar el estatus del documento, no se informará que existe uno previamente. Existe una baja probabilidad de una transacción que sí se haya recibido, pero por un error interno transaccional la misma se hace rollback y aunque existe evidencia de su recepción la plataforma actuará como si no tuviese registro previo. Sin embargo, este escenario es inferior al 0,01% de nuestras transacciones.
2. En el request de TFHKA a la DIAN: Este caso se identifica de forma similar al indicado previamente. Sin embargo, hemos visto que en los momentos de inestabilidad de la plataforma de la DIAN, la cual puede ocurrir ante controles de cambio mayores. Este escenario no sólo corresponde a temas de red (no alcance de los paquetes de red), sino que a veces se debe a procesos no conclusivos dentro del propio sistema de la DIAN (similar a lo indicado previamente para TFHKA, desconocemos una tasa de probabilidad de este escenario).
3. En el response de la DIAN a TFHKA: Hemos registrado tiempos largos de validación por parte de la plataforma de la DIAN a veces (muy muy pocas veces) mayores a 10 min. Estos casos se conocen porque la plataforma TFHKA aunque desconoce el estatus conclusivo de la transacción en la DIAN, cuando se consulta por la misma (una vez ha sido validada que puede requerir varios intentos), se obtiene respuesta definitiva de validación por parte de la DIAN.
4. En el response de TFHKA a a usuario del sistema: Se detecta porque hay una transacción concluida (excepto que hablemos de escenarios 2 o 3) en nuestra plataforma obtenible por consultas de estatus y descarga de documentos.

Cuando la DIAN presenta retrasos en procesamiento:

Nuestra plataforma para lidiar con escenarios 2 y 3, deja las transacciones incompletas en un estatus "intermedio" realiza procesos posteriores para la búsqueda de estatus definitivos y conclusivos de estas transacciones identificando Rechazos, validaciones y/o inexistencia. Los dos primeros actualizan la transacción generadora del evento (el ubl enviado que tuvo el timeout), aquí este punto es muy importante para el caso de reintentos y consumo de consecutivos, porque la DIAN solo valida uno de los intentos transaccionales por lo que el que está validado es el que debe ser actualizado. Para los casos de inexistencia, se inactiva el primer intento transaccional y se permite realizar un reenvío para dar estatus conclusivo a la misma.

Los códigos de error 100/500 responden a dificultad de comunicación con la plataforma de la DIAN o a una respuesta inesperada por parte del proceso de validación de la DIAN. En algún próximo intento transaccional del mismo consecutivo fiscal ocurre lo siguiente:

a) La DIAN nos indica que el documento ya ha sido previamente procesado.

b) La plataforma de TFHKA identificando que es un escenario 3 busca ejecutar la reconstrucción transaccional de ese consecutivo fiscal indicando como válido el registro que originó la transacción y retornando el UBL que le corresponde a esa transacción.

c) Dado que el intento transaccional que disparó el proceso de reconstrucción es distinto a nivel de contenido del documento que había sido previamente validado en la DIAN, pero que no se había podido obtener estatus conclusivo se puede producir disparidad o inconsistencia de información en el documento.

d) The Factory HKA Colombia cuenta en sus logs múltiples intentos transaccionales en sus entradas, pero solo uno de ellos es el correctamente validado por la DIAN (El primero entregado efectivamente a la DIAN que cumple las condiciones de validación, es importante resaltar que previamente pudo haber otros casos que fueran rechazados por validación DIAN o que quedaran en el escenario 2). Dado que ese proceso de validación concluyó en un timeout o en un error inesperado de conexión la misma podría estar en los escenarios 2 y 3.

e) El siguiente intento transaccional es el que "revela" que el escenario realmente era el 3 y es requerido la reconstrucción transaccional con el documento previamente validado. (Esto ocurre porque el reintento de la transacción se genera antes de que nuestros procesos de reconstrucción automáticos puedan hallar de la DIAN estatus definitivo). Si esto último ocurre entonces la respuesta de nuestra plataforma es "documento previamente generado" evitando que el escenario sea aún más complejo.

Recomendaciones:

Lo más adecuado es no realizar reaprovechamiento de consecutivos fiscales y evitar en general reusarlo en lapsos de tiempo menores a 2 horas. Dado que un reintento transaccional de un consecutivo fiscal puede por lo explicado anteriormente tratar de rescatar un estatus transaccional definitivo en la DIAN, que no pudo obtener en previos intentos. En los momentos de dificultades de procesamiento de la DIAN, pueden durar decenas de minutos, por lo que puede generarse un conjunto de transacciones que concluyen en timeout de forma consecutiva y que hacen más complejo la claridad del procesamiento. Sin embargo, si el reenvío es el mismo contenido fiscal -como sugerimos-. Sin importar cual de todos esos intentos concluya satisfactoriamente ante la DIAN desde el punto de vista fiscal y tributario es el mismo documento y así evitar la inconsistencia en los documentos.

1) Código 102: Número de documento inválido:

En este caso, el mensaje se encuentra asociado a un documento que no ha sido transmitido a la plataforma o que su emisión resultó en un rechazo. En este último escenario y en caso de que el sistema almacene los response de cada documento, se deberá validar en el response del método Enviar las causas que generaron el rechazo de dicho documento, al realizar la lectura del array mensajesValidacion, o validar las causas de rechazo en la sección de Documentos Rechazados del portal. Ante este escenario se recomienda realizar un reenvío del documento.

2) Código 200 con esValidoDIAN = true:

El documento se encuentra procesado satisfactoriamente y cuenta con el ApplicationResponse por parte de la DIAN. En este caso, pueden realizar las descarga de PDF (RG estándar), XML Invoice, XML AttachedDocument, reenvío del correo de notificación al adquiriente y, en caso de las emisiones con adjuntos, realizar la sincronización de archivos adjuntos correspondientes al documento para completar el ciclo de emisión del mismo ante la plataforma y sea entregado el correo de notificación al adquiriente.

3) Código 200 con esValidoDIAN = false:

El documento se encuentra procesado satisfactoriamente ante la plataforma, sin embargo, se encuentra a la espera del ApplicationResponse por parte de la DIAN (escenario de intermitencia durante la emisión del mismo). Ante este escenario se recomienda realizar nuevamente la consulta del estatus luego de 1 hora. De persistir este escenario luego de un tercer intento, recomendamos notificarnos vía correo indicando el NIT y el consecutivo, con el fin de realizar las validaciones correspondientes y en caso de encontrarse en los registro de la plataforma de la DIAN, se realiza la respectiva actualización ante la plataforma de TFHKA para que pueda ser consultado desde el sistema.

Flujo de trabajo con sugerencias sobre cómo manejar diferentes escenarios de la operación de Facturación Electrónica

Generalmente cuando la DIAN está intermitente aumentan sus tiempos de respuesta considerablemente, lo cual puede ocasionar time Outs en los puntos 2, 3 y 4 como se muestra en la siguiente imagen:

Generalmente si se presenta un time Out en en el enlace 1 (ERP-TFHKA), esto puede ser internet del cliente ó que nuestra plataforma esté presentando una latencia, en este escenario no se alcanza a llegar a la DIAN, los códigos que generalmente retorna la plataforma son 100, 103 ó se genera una excepción por time out ó por tiempo de enlace configurado en el ERP, ante estos escenarios si la latencia persiste es importante siempre tener presente emitir por contingencia.

Cuando se presentan time Out en los enlaces 2, 3 y 4 (comunicación con la TFHKA-DIAN), es donde resulta más complejo debido a los siguientes escenarios:

1. Vencimiento del tiempo de espera de conexión entre TFHKA-DIAN (enlace 2), lo cual hace que el documento quede en espera ó en proceso y el ERP pudo haber recibido en código 100, 103 ó una excepción por time out, en estos escenarios en la mayoría de los casos el ERP puede hacer el reenvío y el documento será procesado ya que nuestro WS al detectar si el documento ya existe en la DIAN realiza un proceso de reconstrucción para cerrar la transacción correctamente.
2. Se recibe respuesta de la DIAN pero con una estructura no esperada (enlace 3), ejemplo que el app Response (validación DIAN) llegue vacío ó la DIAN nos retorne un código no esperado producto de la intermitencia. Este escenario es el más complejo y es en cual a veces muchas facturas tienen que regenerarse de manera manual, muchas veces en esta situación nuestra plataforma retorna incluso un 200 y un CUFE pero esto no quiere decir que el documento fue autorizado por la DIAN ya que en la propiedad esValidoDIAN se retorna en 'false'.

Una vez indicado lo anterior, en todos los escenarios anteriores TFHKA, es decir en presencia de códigos 100, 103, 200, etc, siempre es importante validar el estado de la propiedad esValidoDIAN = 'True' ya que si esta propiedad es 'false' es un indicativo de que el documento no se puedo validar ante la DIAN en la conexión síncrona, algunas integraciones no validan este propiedad y la misma es muy importante para controlar el estado de la validación.

Adicional, es importante tener presente siempre el escenario o la facturación por contingencia ya que ante intermitencia o latencia tecnológica este esquema de facturación está definido en la normativa.

Flujo de trabajo, con sugerencias sobre cómo manejar diferentes escenarios de la facturación