Diferencia entre revisiones de «Cambios Integración Anexo V 1.9»

De tfhkacolwiki
Ir a la navegación Ir a la búsqueda
 
(No se muestran 16 ediciones intermedias de 4 usuarios)
Línea 1: Línea 1:
El anexo técnico, que forma parte esencial de esta resolución, debe ser implementado de manera obligatoria por los emisores de facturas electrónicas a partir del 2 de febrero de 2024. Se otorga plazo hasta dicha fecha para que realicen las adecuaciones necesarias en sus sistemas de información, cumpliendo con lo establecido en esta resolución, a continuación se informan los cambios mas relevantes.
+
<includeonly>=</includeonly>==[[Cambios Integración -Cambios Integración Anexo V 1.9|Cambios Integración]]==<includeonly>=</includeonly>
<br>
+
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Resolución 165 Anexo técnico 1.9|Resolución 165 Anexo técnico 1.9]]
[[Archivo:resolucion165.png|800px|sinmarco|center|RESOLUCIÓN 165]]
+
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Separación de catálogos del anexo técnico|Separación de catálogos del anexo técnico]]
<br>
+
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Se elimina el redondeo al total de impuesto a nivel de detalle y total para facturas, notas crédito y débito:|Se elimina el redondeo al total de impuesto a nivel de detalle y total para facturas, notas crédito y débito:]]
<includeonly>=</includeonly><font color="blue">Resolución 165 Anexo técnico 1.9</font><includeonly>=</includeonly>
+
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Se elimina la regla de 10 días posterior e inferior a la fecha y se ha incorporado una nueva regla de rechazo.|Se elimina la regla de 10 días posterior e inferior a la fecha y se ha incorporado una nueva regla de rechazo.]]
<br/>
+
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Medios de pago.|Medios de pago.]]
 +
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Nombre o razon social del emisor debe coincidir al informado en el RUT.|Nombre o razon social del emisor debe coincidir al informado en el RUT.]]
 +
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Se crea el tipo de documento PPT.|Se crea el tipo de documento PPT.]]
 +
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Factura de exportación.|Factura de exportación.]]
 +
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Nuevos tipos de operación.|Nuevos tipos de operación.]]
 +
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Cambios incorporados en las notas crédito.|Cambios incorporados en las notas crédito.]]
 +
# [[Cambios Integración -Cambios Integración Anexo V 1.9#Impuesto al Consumo de Licores, Vinos, Aperitivos Y Similares|Impuesto al Consumo de Licores, Vinos, Aperitivos Y Similares.]]
  
<includeonly>=</includeonly>== <font color="blue">Separación de catálogos del anexo técnico</font>==<includeonly>=</includeonly>
 
<br/>
 
Dentro del proceso de revisión, se ha tomado la decisión de eliminar los catálogos de datos del anexo. Este ajuste tiene la finalidad de facilitar la modificación de los valores de manera más ágil y eficiente. En adelante, estos catálogos permanecerán fuera del anexo y estarán disponibles en una caja de herramientas independiente. Además, se establecerá un proceso de actualización de los catálogos de forma independiente a las resoluciones vigentes.
 
<br/>
 
  
[[Archivo:caja.png|800px|sinmarco|center|Ejemplo]]
+
<includeonly>=</includeonly>==[[Ejemplos estructura SOAP -Cambios Integración Anexo V 1.9|Ejemplos estructura SOAP]]==<includeonly>=</includeonly>
 +
# [[Ejemplos estructura SOAP-Cambios Integración Anexo V 1.9#Ejemplos|Ejemplos estructura SOAP]]
  
 +
<includeonly>=</includeonly>==[[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9|Tablas de códigos de propiedades para emisión de documentos V1.9]]==<includeonly>=</includeonly>
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 1|Tabla 1]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 2|Tabla 2]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 3|Tabla 3]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 4|Tabla 4]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 5|Tabla 5]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 6|Tabla 6]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 7|Tabla 7]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 8|Tabla 8]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 9|Tabla 9]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 10|Tabla 10]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 11|Tabla 11]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 12|Tabla 12]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 13|Tabla 13]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 14|Tabla 14]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 15|Tabla 15]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 16|Tabla 16]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 17|Tabla 17]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 18|Tabla 18]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 19|Tabla 19]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 20|Tabla 20]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 21|Tabla 21]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 22|Tabla 22]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 23|Tabla 23]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 24|Tabla 24]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 25|Tabla 25]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 26|Tabla 26]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 27|Tabla 27]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 28|Tabla 28]]
 +
# [[Tablas de códigos de propiedades para emisión de documentos V1.9-Cambios Integración Anexo V 1.9#Tabla 29|Tabla 29]]
  
<includeonly>=</includeonly>== <font color="blue">Se elimina el redondeo al total de impuesto a nivel de detalle y total:</font>==<includeonly>=</includeonly>
+
<includeonly>=</includeonly>==[[Reglas de rechazo anexo técnico V 1.9 -Cambios Integración Anexo V 1.9|Reglas de rechazo anexo técnico V 1.9]]==<includeonly>=</includeonly>
<br/>
 
 
 
<span style="color:#FF0000; text-align:left;"><b>Reglas eliminadas: </b>
 
<br/>
 
<span style="color:#E2583B; text-align:left;"><b>FAS18, CAS18,DAS18: </b>
 
 
 
Redondeo agregado al total del impuesto (no se manejaría el atributo RoundingAmount del nodoTaxTotal que pertenece al Invoice/CreditNote/DebitNote)
 
<br/>
 
 
 
<span style="color:#E2583B; text-align:left;"><b>FAX18, CAX18,DAX18: </b>
 
 
 
Redondeo agregado al total del impuesto  (no se manejaría el atributo RoundingAmount del nodoTaxTotal que pertenece al InvoiceLine/CreditNoteLine/DebitNoteLine)
 
<br/>
 
[[Archivo:redondeo.png|800px|sinmarco|center|Ejemplo:]]
 
[[Archivo:redondeo1.png|800px|sinmarco|center|Ejemplo]]
 
<br>
 
 
 
<includeonly>=</includeonly>== <font color="blue">Se elimina la regla de 10 días posterior e inferior a la fecha y se ha incorporado una nueva regla de rechazo.</font>==<includeonly>=</includeonly>
 
<br/>
 
<span style="color:#FF0000; text-align:left;"><b>Reglas eliminadas: </b>
 
<br/>
 
<span style="color:#E2583B; text-align:left;"><b>FAD09c, CAD09c, DAD09c:</b>
 
 
 
La fecha de emisión no puede ser inferior a 10 días calendarios de la fecha actual
 
<br/>
 
 
 
<span style="color:#E2583B; text-align:left;"><b>FAD09d, CAD09d, DAD09d: </b>
 
 
 
La fecha de emisión no sea posterior a 10 días calendarios de la fecha actual
 
 
 
<span style="color:blue; text-align:left;"><b>Reglas nuevas: </b>
 
<br/>
 
 
 
<b>FAD09e, CAD09e, DAD09e </b>
 
 
 
Valida que fecha de generación sea igual a la fecha de firma, aplica para facturas, notas crédito y débito
 
 
 
[[Archivo:fechaemision.png|800px|sinmarco|center|Ejemplo:]]
 
 
 
<includeonly>=</includeonly>== <font color="blue">Medios de pago.</font>==<includeonly>=</includeonly>
 
<br/>
 
Anteriormente, se establecía la obligatoriedad de indicar el medio de pago únicamente en las facturas de contado. Sin embargo, según el Anexo 1.9, esta obligación se extenderá tanto a las facturas de contado como a las de crédito.
 
<br/>
 
[[Archivo:mediosdepago.png|800px|sinmarco|center|Ejemplo]]
 
<br/>
 
 
 
<includeonly>=</includeonly>== <font color="blue">Nombre o razon social del emisor debe coincidir al informado en el RUT.</font>==<includeonly>=</includeonly>
 
<br/>
 
Se llevará a cabo una validación para asegurar que el Número de Identificación Tributaria (NIT) y el nombre del emisor de las facturas concuerden con los datos registrados en el Registro Único Tributario (RUT), tanto en el proceso de emisión como en el de recepción de dichas facturas.<br/>
 
<br/>
 
<span style="color:blue; text-align:left;"><b>Reglas nuevas: </b>
 
<br/>
 
 
 
<b>FAJ44a:</b> NIT no autorizado a facturar electrónicamente
 
 
<b>FAJ43b:</b> Nombre o Razón Social del emisor debe corresponder al informado en el RUT y debe coincidir con el NIT informado
 
 
 
<b>FAJ44b:</b> NIT o documento de identificación del emisor debe corresponder al informado en el RUT y debe coincidir con la Razón Social o Nombre comercial registrado.
 
 
<b>FAJ43a:</b> Nombre o Razón Social del emisor debe ser informado
 
 
 
[[Archivo:razonnitigual.png|800px|sinmarco|center|Ejemplo:]]
 
 
 
<includeonly>=</includeonly>== <font color="blue">Se crea el tipo de documento PPT.</font>==<includeonly>=</includeonly>
 
<br/>
 
Dentro del catalogo de tipo de documento se crea PPT (Permiso de protección temporal) con el código 48, el cual es un documento de identificación para personas en movilidad humana provenientes de Venezuela,este documento permite aplicar a los programas sociales del estado, y acceder de manera amplia a derechos como la salud, la educación y el trabajo.
 
<br/>
 
 
 
{| class="wikitable" style="width: 100%;" style="margin: auto;"
 
! style="color:white;background:#2F5496; text-align:center;"|Código
 
! style="color:white;background:#2F5496; text-align:center;"|Significado
 
|- valign="center"
 
|48
 
|PPT (Permiso de protección temporal)
 
|-
 
|}
 
<br/>
 
[[Archivo:PPTEJEMPLO.png|800px|sinmarco|center|Ejemplo]]
 
<br/>
 
 
 
<includeonly>=</includeonly>== <font color="blue">Factura de exportación.</font>==<includeonly>=</includeonly>
 
<br/>
 
 
 
Las facturas de exportación deben expresarse en COP y se crea una segmento XML para poner los valores en otra moneda, se puede colocar en las dos monedas en la representación gráfica(se va enviar una estructura en el extensible para que se vea en la RG)
 
 
 
[[Archivo:facexp.png|800px|sinmarco|center|Ejemplo]]
 
 
 
<includeonly>=</includeonly>== <font color="blue">Nuevos tipos de operación.</font>==<includeonly>=</includeonly>
 
<br/>
 
 
 
Para el control cambiario se Incluyen dos modos de operación (Compra Divisas y Venta Divisas) con los códigos 15 y 16 respectivamente, cuando uno de estos códigos se informe en el CustomizationID se deberá informar la UBL extensión.
 
<br/>
 
 
 
[[Archivo:cvdivisas.png|800px|sinmarco|center|Ejemplo]]
 
 
 
 
 
<includeonly>=</includeonly>== <font color="blue">Cambios incorporados en las notas crédito.</font>==<includeonly>=</includeonly>
 
<br/>
 
 
 
No se permite notas crédito para facturas aceptadas.
 
 
 
Solo se puede anular facturas sin aceptar.
 
 
 
Para todas las facturas sin referencia debe incluir el perido (mes) que afecta.
 
 
 
[[Archivo:periodonc.png|800px|sinmarco|center|Ejemplo]]
 
<br/>
 
 
 
[[Archivo:EJPERIODO.png|800px|sinmarco|center|Ejemplo]]
 
<br/>
 
 
 
<includeonly>=</includeonly>==<font color="blue">Tablas de códigos de propiedades para emisión de documentos</font>==<includeonly>=</includeonly>
 
En la siguiente sección encontrará información referente a las diferentes tablas de códigos de propiedades definidas por la DIAN en el anexo técnico 1.9.
 
==<font color="Blue">Tabla 1</font>==
 
{| class="wikitable" style="width: 100%;"
 
|+ Tipos de Documentos
 
|- valign="center"
 
|-style="text-align:center;"
 
|colspan="2"|Anexo 1.9-2023 - 13.1.3. Tipo de Documento:
 
{| class="wikitable" style="width: 100%;"
 
! style="color:white;background:#2F5496; text-align:center;"|Código
 
! style="color:white;background:#2F5496; text-align:center;"|Significado
 
! style="color:white;background:#2F5496; text-align:center;"|Uso
 
|- valign="center"
 
|-
 
|01
 
|Factura electrónica de Venta
 
|rowspan="4"|Tipos de factura
 
|-
 
|02
 
|Factura electrónica de Venta - exportación
 
|-
 
|03
 
|Documento electrónico de transmisión - tipo 03
 
|-
 
|04
 
|Factura electrónica de Venta - tipo 04
 
|-
 
|91
 
|Nota Crédito
 
|rowspan="2"|Exclusivo en referencias a documentos (elementos DocumentReference)
 
|-
 
|92
 
|Nota Débito
 
|-
 
|05
 
|Documento Soporte en adquisiciones a No Obligados a Facturar
 
|rowspan="2"|Exclusivo para Documento Soporte en adquisiciones a No Obligados a Facturar
 
|-
 
|95
 
|Nota de Ajuste Documento Documento Soporte en adquisiciones a No Obligados a Facturar
 
|-
 
|96
 
|Eventos(ApplicationResponse)
 
|}
 
|}
 
<br>
 
<includeonly>=</includeonly>==<font color="blue">Contingencia Facturador Electrónico</font>==<includeonly>=</includeonly>
 
La contingencia de Factura Electrónica es un aliado para la operación de nuestros clientes. En el marco de la entrada en vigencia de la obligatoriedad a
 
partir del 1 de febrero de 2024 para la adopción del anexo técnico de factura electrónica de venta versión 1.9, en el cual se tiene establecido entre sus
 
principales cambios que "La fecha de generación y la fecha de la firma de la factura electrónica debe ser el mismo día" se ha eliminado la regla de 10 días
 
posterior e inferior a la fecha.
 
Por lo antes mencionado, va a ser clave que como aliados y casas de software se tengan implementados los procedimientos de facturación en escenarios de
 
contingencia total o parcial bajo la premisa de máximo esfuerzo de validación ante la DIAN con esquemas auditables. Y su vez el tener procesos bien implementados
 
para la contingencia de Facturación Electrónica va a ser un gran aliado a la hora que se presenten intermitencias o timeouts en el servicio de la DIAN,
 
interrupción del servicio de internet o ante intermitencias en la plataforma de emisión de facturas electrónicas de The Factory HKA Colombia. Sobre todo
 
en los puntos de ventas tengamos procedimientos que garanticen que las operaciones continúen y no se detengan. En tal sentido los invitamos a estudiar el
 
material o contenido que se presenta a continuación:
 
 
 
[[Archivo:contingencia01.png|800px|sinmarco|centro|contingencia01]]
 
 
 
  <br>
 
 
 
Analizando el alcance que pueden tener los escenarios de contingencia de nuestros clientes podemos hablar de dos tipos de alcance:
 
===Tipos de Contingencia Facturador Electrónico (Tipo 03)===
 
 
 
====Contingencia Total====
 
 
 
Es lo que se tiene establecido en el anexo técnico 1.9 y está alineado con esquemas B2B, ahora con la masificación de la factura electrónica no es tan sencillo aplicarlo. Eventos fuera de la operación normal,
 
hacking, como ejemplo lo recientemente ocurrido con IFX Networks
 
 
 
====Contingencia Parcial====
 
Es una sugerencia de Procedimiento TFHKA bajo la premisa de “Máximo Esfuerzo de Validación ante la DIAN” con Esquemas Auditables. En la regulación no se presentan esquemas aplicables a este tipo de contingencia
 
es más alineado a esquemas B2C.
 
 
 
=====Contingencia Total Facturador Electrónico (Tipo 03) – Anexo Técnico 1.9=====
 
 
 
Corresponde al esquema que se tiene establecido en el anexo técnico 1.9.
 
 
 
Los inconvenientes tecnológicos por parte del facturador electrónico implican que esté tenga en cuenta lo siguiente:
 
• Por el tiempo en que dure la contingencia expedir factura de venta de talonario o de papel, la cual se podrá generar para su expedición de forma manual o autógrafa o a través de sistemas informáticos electrónicos
 
• El facturador electrónico deberá generar una carta declarando el inconveniente tecnológico o superación del misma, la cual debe ir firmada por el representante legal de la compañía o quien haga de sus veces y remitirla al
 
correo electrónico contingencia.facturadorvp@dian.gov.co con lo siguiente:
 
o Asunto: Nit de la empresa separado con un guión el digito de verificación; Nombre de la empresa.
 
o Adjunto: PDF de la carta donde se declaren en contingencia con la firma del representante legal o quien haga de sus veces.
 
o Cuerpo del correo: Datos de contacto (Nombres, teléfono/Celular de contacto).
 
▪ Nota: Este correo únicamente será para la recepción de correos de los facturadores electrónicos para informar el inconveniente tecnológico o superación de este.
 
▪ Nota: Adicionalmente, si quieren entregar estas constancias por escrito lo pueden realizar a través de radicados, el cual deberá remitirse a la DIAN - nivel central - factura electrónica.
 
 
 
• Una vez el facturador electrónico superé el inconveniente tecnológico deberá proceder a generar, transmitir, expedir y recibir sus documentos e instrumentos electrónicos de manera habitual.
 
• Se deberá transcribir la información mediante el documento electrónico de transmisión de cada una de las facturas de venta de talonario o papel expedidas en el tiempo que duró la contingencia, al momento de transmitir
 
la DIAN está informará las notificaciones y/o rechazos a que haya lugar sobre estás, las cuales deberán expedir dentro de las 48 horas siguientes al momento en que se supera el inconveniente.
 
• El envío de los instrumentos electrónicos debe realizarse a través del método SendBillSync.
 
 
 
Se informa que los documentos CreditNote, DebitNote y ApplicationResponse no tienen esquemas de contingencia, por tanto, el facturador no deberá usar la numeración de contingencia para estos documentos, sino la numeración establecida
 
por el facturador para estos. Dicho lo anterior se deberán generar, transmitir, validar y expedir los documentos según se establece el presente anexo cuando los inconvenientes tecnológicos presentados por parte del facturador electrónico
 
estén superados.
 
 
 
[[Archivo:contingencia02.png|800px|sinmarco|centro|contingencia02]] 
 
 
 
'''Declaración Contingencia Total Facturador Electrónico (Tipo 03)'''
 
 
 
A continuación se presentan ejemplos de Inicio y Finalización  de Declaración Contingencia Total Facturador Electrónico.
 
 
 
[[Archivo:contingencia03.png|800px|sinmarco|centro|contingencia03]] 
 
<br>
 
=====Solicitud Aprobación Contingencia Parcial Facturador Electrónico (Tipo 03)=====
 
A continuación se presenta ejemplo de Solicitud Aprobación Contingencia Parcial Facturador Electrónico (Tipo 03), este tipo de esquemas no se encuentra en la regulación actual pero es el esquema que algunos de nuestros aliados han
 
implementado y los cuales han superado procesos de auditorías por parte de la DIAN. Y es la recomendación que damos por experiencia. Esta solicitud la debe elaborar la empresa emisora en el momento que vaya a masificar su facturación
 
electrónica, es un ejemplo o referencia, cada contribuyente debe adecuarla a sus procesos y operación. Debe quedar debidamente resguardado y bajo esquemas de documentación propias de Sistemas de Gestión de la empresa de ser posible.
 
Se recomienda que al momento de generarse la necesidad de entrar en contingencia parcial haya una aprobación o autorización por parte de un supervisor o persona designada por la empresa, y que quede trazabilidad del inicio y fin de la
 
contingencia, con la finalidad que pueda ser auditado posteriormente. No debe estar en potestad de un cajero o agente de punto de venta el entrar en contingencia tipo 03. Se busca garantizar que la operación y ventas no se detengan.
 
 
 
 
 
[[Archivo:contingencia04.png|800px|sinmarco|centro|contingencia04]]
 
<br>
 
[[Archivo:contingencia05.png|800px|sinmarco|centro|contingencia05]] 
 
 
<br>
 
A continuación se presentan los gráficos de cómo pueden presentarse las contingencias parciales.
 
<br>
 
======Escenario 1 Contingencia Parcial con base en Ejemplo en Solicitud======
 
 
[[Archivo:contingencia06.png|800px|sinmarco|centro|contingencia06]] 
 
<br>
 
En la generación se tienen los datos que va a tener en el futuro la factura, aún no se tiene la factura electrónica.
 
Intento de transmisión, se envían los datos de lo que va a tener la factura para que con base a las validaciones de la DIAN si se convierta en factura electrónica de venta, hasta que la DIAN no lo valide no se tiene la factura electrónica.
 
Expedición, es entregar la factura con la validación de la DIAN. Bajo un esquema de contingencia voy a tener generación, en la generación los datos deben estar almacenados en una base de datos (disco duro, nube, sistema POS, RAM-ROM de un
 
celular) para tener la posibilidad de reconstruir la transacción en caso de contingencia, sobre todo en contingencias parciales.
 
En el escenario 1 se hacen dos intentos cada uno de 1 minuto y después del segundo se toma la decisión de expedirlo sin validación de la DIAN. La contingencia va ir sin validación pero cumpliendo con los requisitos de la factura de venta
 
de talonario papel, tiene una fecha de expedición, independientemente de que se transmita o no ya al adquirente le sirve esa factura para deducción de costos y gastos. La responsabilidad queda de parte del facturador electrónico, y puede
 
estar expuesto a sanciones por no transmitir en debida forma en los tiempos establecidos, es decir, 48 horas contadas a partir de haber salido de la contingencia. Después de la expedición se debe hacer la transmisión de los documentos.
 
 
 
======Escenario 2 Contingencia Parcial con base en Ejemplo en Solicitud======
 
 
 
[[Archivo:contingencia07.png|800px|sinmarco|centro|contingencia07]] 
 
 
 
======Escenario 3 Contingencia Parcial con base en Ejemplo en Solicitud======
 
 
 
[[Archivo:contingencia08.png|800px|sinmarco|centro|contingencia08]] 
 
<br>
 
Estamos en rutas de venta y se llega a un sitio donde no hay internet, las transacciones se van almacenando en el dispositivo móvil, se hace el intento de transmitir y no se puede transmitir, se entrega la factura contingencia de talonario
 
papel y cuando se llega a una zona de cobertura ya se tiene en el sistema la posibilidad de empezar a transmitirla. Es recomendable mantener una copia física de la transacción para tener respaldo en caso de robo o extravío del dispositivo
 
móvil.
 
 
 
===Conciliación===
 
 
 
Ante escenarios de estados indeterminados de transacciones electrónicas que pueden ser origen de documentos emitidos en contingencia, es necesario realizar el último esfuerzo de conciliar el estado definitivo de los mismos, ejemplos:
 
1. Transacción validada por la DIAN después del lapso de tiempo especificado para la expedición de una factura electrónica de contingencia. Esta transacción se debe anular con una nota crédito referenciada.
 
<br>
 
[[Archivo:conciliación.png|800px|sinmarco|centro|conciliación]] 
 
<br>
 
2. Transacción en estado de error por la DIAN después del lapso de tiempo especificado para la expedición de una factura electrónica de contingencia. Esta transacción se puede consultar por API y no se puede ver por el portal de la DIAN.
 
Se debe dejar registrado el intento de anulación de la transacción así no se logre.
 
<br>
 
[[Archivo:conciliacion01.png|800px|sinmarco|centro|conciliacion01]] 
 
<br>
 
3.En la documentación técnica de TFHKA de estatus indeterminados pueden ver escenarios adicionales y sugerencias de manejo.
 
<br>
 
[[Archivo:conciliacion03.png|800px|sinmarco|centro|conciliacion03]] 
 
<br>
 
Documentos con estatus indeterminado en HKAFactura, En esta sección de la felcowiki  puede encontrar información acerca de que es, porque ocurre y como solucionar los estatus indeterminados en la emisión de facturas.
 
 
 
 
 
[[Canal de Notificaciones Técnicas Telegram]]
 
 
 
[[Documentos con estatus indeterminado en HKAFactura]]
 
 
 
 
 
 
 
'''Datos Origen de conciliación:'''
 
<br>
 
#Reporte del Portal DIAN “Facturando Electrónicamente” (Emisión / Recepción).
 
#Reporte de documentos desde los portales de TFHKA.
 
#Reporte de documentos desde los Sistemas de Facturación – ERP´s.
 
<br>
 
[[Archivo:conciliacion04.png|800px|sinmarco|centro|conciliacion04]] 
 
<br>
 
'''Requisitos de las facturas de talonario o papel'''
 
A continuación se muestran los requisitos que deben cumplir las facturas de talonario o papel según lo establecido en el artículo 12 de la resolución DIAN 000165 de 01-11-2023.
 
<br>
 
[[Archivo:requisitos.png|800px|sinmarco|centro|requisitos]] 
 
<br>
 
===Las facturas de Talonario o Papel deben incluir código QR si se expiden a través de Sistemas Informáticos & el código QR debe incluir CUFE===
 
<br>
 
En el numeral 14 del artículo 12 de de la resolución DIAN 000165 de 01-11-2023.indica que El Código de respuesta rápida -Código QR-, en caso de que la factura de venta de talonario o de papel se genere a través de sistemas
 
informáticos electrónicos.
 
<br>
 
[[Archivo:facturaTalonario.png|800px|sinmarco|centro|facturaTalonario]] 
 
<br>
 
'''Generación del CUFE'''
 
<br>
 
[[Archivo:cufe.png|800px|sinmarco|centro|cufe]] 
 
<br>
 
'''Ejemplo - Generación del CUFE'''
 
<br>
 
[[Archivo:ejemploCufe.png|800px|sinmarco|centro|ejemploCufe]] 
 
<br>
 

Revisión actual del 17:08 9 ene 2024