Diferencia entre revisiones de «Reglas de rechazo anexo técnico V 1.9 -Cambios Integración Anexo V 1.9»

De tfhkacolwiki
Ir a la navegación Ir a la búsqueda
(ajuste reglas de fecha de emision.)
 
(No se muestran 8 ediciones intermedias del mismo usuario)
Línea 91: Línea 91:
 
</br>
 
</br>
  
*El indicador del tipo de operación debe ser igual a 20 (nota crédito referenciada) cuando el concepto de corrección corresponde a 2 (Anulación de factura electrónica), [[Tablas de códigos de propiedades para emisión de documentos V1.9 - Cambios Integración Anexo V 1.9#Tabla 9|Tabla 9]]
+
*El indicador del tipo de operación debe ser igual a 20 (nota crédito referenciada) cuando el concepto de corrección corresponde a 2 (Anulación de factura electrónica) como se evidencia en la siguiente imagen.
 +
</br>
 +
'''Ejemplo SOAP:'''
 +
[[Archivo:tipooperacion.png|800px|sinmarco|center|ejemplo]]
 +
<center>Imagen 1. Estructura SOAP.</center>
 +
</br>
 +
</br>
 +
'''Ejemplo estructura API:'''
 +
[[Archivo:opapi.png|800px|sinmarco|center|ejemplo]]
 +
<center>Imagen 2. Estructura API.</center>
 +
</br>
 +
'''Ejemplo API:'''
 +
</br>
 +
02|91|CONSECUTIVO|PREFIJO-RANGODESDE|2024-05-22 00:00:00||COP|||1003.00|1193.57|2|2023-12-31 00:00:00|2023-12-01 00:00:00|||<b>20</b>||1003.00|1193.57||1|
 +
</br>
 +
</br>
 +
</br>
  
 +
'''Ejemplo estructura DLL:'''
 +
[[Archivo:opdll.png|800px|sinmarco|center|ejemplo]]
 +
<center>Imagen 3. Estructura DLL.</center>
 +
</br>
 +
</br>
 +
'''Ejemplo DLL:'''
 +
</br>
 +
</br>
 +
02|91|CONSECUTIVO|RANGO-CAMPODESDE|2024-05-22 00:00:00|2024-05-22|COP|0.00|0.00|5980.00|7116.20|2||||0.00|<b>20</b>|0.00|5980.00|7116.20|0.00|1|
 +
</br>
 
</br>
 
</br>
 
 
 
  
 
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo FAD09e - Mensaje: Valida que fecha de generación de la factura sea igual a la fecha de firma de la factura </font> ==<includeonly>=</includeonly>
 
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo FAD09e - Mensaje: Valida que fecha de generación de la factura sea igual a la fecha de firma de la factura </font> ==<includeonly>=</includeonly>
Línea 173: Línea 196:
 
</br>
 
</br>
  
*Si el medio de pago no corresponde con relación a la tabla 14.5.4.2
+
*Si el medio de pago no corresponde con relación a la tabla 13.3.4.2
  
 
'''Solución:'''
 
'''Solución:'''
 
</br>
 
</br>
  
*El medio de pago debe corresponder a la relación a la tabla [[Tablas de códigos de propiedades para emisión de documentos V1.9- Cambios Integración Anexo V 1.9#Tabla 13|Tabla 13]]
+
*El medio de pago debe corresponder a la relación del catalogo 13.3.4.2 Medios de Pago PaymentMeansCode el cual lo encontrará en la Caja de Herramientas que dispone la DIAN en el siguiente enlace:
 
 
También se encuentra en la Caja de Herramientas que dispone la DIAN:
 
  
“Caja_de_herramientas_Factura_Electronica_Validacion_Previa.zip\AnexoTecnico\Tablas
+
https://micrositios.dian.gov.co/sistema-de-facturacion-electronica/documentacion-tecnica/
Referenciadas”, en formato Excel “.xlsx”.
 
  
 
</br>
 
</br>
 
 
  
 
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo AAD09e - Mensaje: Valida que fecha de generación del evento sea igual a la fecha de firma del evento </font> ==<includeonly>=</includeonly>
 
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo AAD09e - Mensaje: Valida que fecha de generación del evento sea igual a la fecha de firma del evento </font> ==<includeonly>=</includeonly>
Línea 261: Línea 279:
 
*Se debe informar la fecha de fin del periodo de facturación.
 
*Se debe informar la fecha de fin del periodo de facturación.
 
<b>IMPORTANTE:</b> Recuerde que en la estructura se debe informar primero la fecha fin y luego la fecha inicial
 
<b>IMPORTANTE:</b> Recuerde que en la estructura se debe informar primero la fecha fin y luego la fecha inicial
 +
</br>
 +
Ejemplos:
 +
 +
[[Archivo:EJPERIODO.png|800px|sinmarco|center|Ejemplo]]
 +
<br/>
 +
 +
En estructura API:
 +
 +
[[Archivo:apinc.png|800px|sinmarco|center|Ejemplo]]
 +
<br/>
 +
 +
En estructura DLL:
 +
 +
[[Archivo:dllnc.png|800px|sinmarco|center|Ejemplo]]
 +
<br/>
  
  
Línea 278: Línea 311:
 
*Se debe informar la fecha de inicio del periodo de facturación.
 
*Se debe informar la fecha de inicio del periodo de facturación.
 
<b> IMPORTANTE:</b> Recuerde que en la estructura se debe informar primero la fecha fin y luego la fecha inicial
 
<b> IMPORTANTE:</b> Recuerde que en la estructura se debe informar primero la fecha fin y luego la fecha inicial
 +
</br>
 +
Ejemplos:
 +
 +
[[Archivo:EJPERIODO.png|800px|sinmarco|center|Ejemplo]]
 +
<br/>
 +
 +
En estructura API:
 +
 +
[[Archivo:apinc.png|800px|sinmarco|center|Ejemplo]]
 +
<br/>
 +
 +
En estructura DLL:
 +
 +
[[Archivo:dllnc.png|800px|sinmarco|center|Ejemplo]]
 +
<br/>
 +
  
 
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo CBG05- Mensaje: Algoritmo no corresponde. </font> ==<includeonly>=</includeonly>
 
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo CBG05- Mensaje: Algoritmo no corresponde. </font> ==<includeonly>=</includeonly>
Línea 292: Línea 341:
 
'''Solución:'''
 
'''Solución:'''
 
</br>
 
</br>
*En el segundo objeto de documentosReferenciados se debe infromar el campo tipoCUFE cuando en código interno es igual a 5 de la siguiente manera:
+
*Para solucionar este rechazo en el segundo objeto de documentosReferenciados se debe informar el campo tipoCUFE como CUFE-SHA384 cuando código interno sea igual a 5. Ver imágenes anexas  con las estructuras para SOAP, dll y api:
 +
 
 +
*Segun anexo técnico 1.9
 +
</br>
 +
[[Archivo:tipocufe.png|800px|sinmarco|center|ejemplo]]
 +
 
 +
</br>
 
[[Archivo:tipoCuff.png|800px|sinmarco|center|ejemplo xml]]
 
[[Archivo:tipoCuff.png|800px|sinmarco|center|ejemplo xml]]
'''ARCHIVO PLANO:'''
+
<center> Imagen 1. Estructura SOAP </center>
 +
 
 +
 
 +
</br>
 
[[Archivo:tipoPlano.png|800px|sinmarco|center|ejemplo plano]]
 
[[Archivo:tipoPlano.png|800px|sinmarco|center|ejemplo plano]]
'''DLL hkafact21 - Emisión V4:'''
+
<center> Imagen 2. Estructura para archivos planos API</center>
 +
 
 +
 
 +
</br>
 
[[Archivo:tipoDll.png|800px|sinmarco|center|ejemplo dll]]
 
[[Archivo:tipoDll.png|800px|sinmarco|center|ejemplo dll]]
 +
<center>Imagen 3. Estructura para dll.</center>
 +
 +
</br>
 +
 +
 +
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo FAR02- Mensaje: Si no es igual al COP </font> ==<includeonly>=</includeonly>
 +
 +
</br>
 +
'''Mensaje de Error:'''
 +
</br>
 +
Remitase a regla FAD15b ya que al cumplirse dicha regla verifica que este elemento corresponder al mismo valor informado en DocumentCurrencyCode
 +
 +
'''Rechazo:'''
 +
</br>
 +
*Si monedaOrigen no es igual al COP
 +
'''Solución:'''
 +
</br>
 +
*La monedaOrigen dentro de la tasa de cambio siempre deberá ser igual a COP
 +
 +
[[Archivo:monedaorigen.png|800px|sinmarco|center|ejemplo]]
 +
 +
</br>
 +
 +
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo FAR03- Mensaje: Si trae valor igual a 1.00 </font> ==<includeonly>=</includeonly>
 +
 +
</br>
 +
'''Mensaje de Error:'''
 +
</br>
 +
Si trae valor igual a 1.00.
 +
 +
'''Rechazo:'''
 +
</br>
 +
*Base monetaria de la divisa COP que se deberá convertir a moneda extranjera.
 +
'''Solución:'''
 +
</br>
 +
*La base monetaria de la divisa COP que se deberá convertir a moneda extranjera, ejemplo: si es USD el valor a informar es el valor equivalente de un dólar en pesos.
 +
 +
[[Archivo:tsdecambio.png|800px|sinmarco|center|ejemplo]]
 +
</br>
 +
 +
<includeonly>=</includeonly>== <font color="blue"> Regla de Rechazo ZE02- Mensaje: Valor de la Firma inválido </font> ==<includeonly>=</includeonly>
 +
 +
</br>
 +
'''Mensaje de Error:'''
 +
</br>
 +
Valor de la Firma inválido.
 +
 +
'''Rechazo:'''
 +
</br>
 +
*Valor de la Firma inválido.
 +
'''Solución:'''
 +
</br>
 +
*Con el cambio de estructura para la factura de exportación, hemos evidenciado que este rechazo se presenta cuando no se envía la estructura de información del campo extra FEXP2, que construye el nodo AdditionalInformation para los "DATOS ADICIONALES" en este caso si identifican que el envío de esta información no aplica para el cliente, se deberá enviar el nombre del campo y su valor vacío:
 +
 +
*Ejemplo:
  
*Se debe informar el tipoCUFE dentro del segundo objeto de la Class.DocumentoReferencia cuando en código interno es igual a 5.
+
<valor>Responsable: #Lugar de Salida: #Medio de transporte: #Tipo de Doc.de transporte: #N° de Doc. de transporte: #Transportadora o Tramitadora: #País de Origen de la M/cia: #Destino: #Términos de pago: #Seguro: #Observaciones: </valor>
  
[[Archivo:tipocufe.png|800px|sinmarco|center|ejemplo ]]
+
[[Archivo:exp2.png|800px|sinmarco|center|ejemplo]]

Revisión actual del 03:15 23 may 2024

Sumario

Regla de Rechazo FAJ43a- Mensaje:Nombre o Razón Social del emisor debe ser informado


Mensaje de Error:

Nombre No informado

Rechazo:

  • Nombre o Razón Social del emisor debe ser informado.

Solución:

  • El Nombre o Razón Social del emisor debe coincidir con el informado en el RUT.



Regla de Rechazo FAJ43b- Mensaje:Nombre informado No corresponde al registrado en el RUT con respecto al Nit suministrado.


Mensaje de Error:

Nombre informado No corresponde al registrado en el RUT con respecto al Nit suministrado.

Rechazo:

  • Nombre informado No corresponde al registrado en el RUT con respecto al Nit suministrado.

Solución:

  • El Nombre o Razón Social del emisor debe corresponder al informado en el RUT y debe coincidir con el NIT informado.



Regla de Rechazo FAJ44a- Mensaje: NIT no autorizado a facturar electrónicamente


Mensaje de Error:

Nombre informado No corresponde al registrado en el RUT con respecto al Nit suministrado.

Rechazo:

  • NIT del emisor.

Solución:

  • El Nit o Documento de Identificación informado debe corresponder al registrado en el RUT con respecto a la razón social o nombre comercial suministrado.



Regla de Rechazo FAJ44b- Mensaje: Nit o Documento de Identificación informado No corresponde al registrado en el RUT con respecto a la razón social o nombre comercial suministrado.


Mensaje de Error:

Nit o Documento de Identificación informado No corresponde al registrado en el RUT con respecto a la razón social o nombre comercial suministrado. Rechazo:

  • 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.

Solución:

  • El Nit o Documento de Identificación informado debe corresponder al registrado en el RUT con respecto a la razón social o nombre comercial suministrado.



Regla de Rechazo CAD02a- Mensaje: Indicador del tipo de operación, cuando se utiliza el código ”2” de la tabla 13.2.4 Concepto de Anulación para Notas Credito.


Mensaje de Error:

CustomizationID debe ser igual a “20”

Rechazo:


  • Si el indicador del tipo de operación es distinto a 20 (nota crédito referenciada) cuando el concepto de corrección corresponde a 2 (Anulación de factura electrónica).

Solución:

  • El indicador del tipo de operación debe ser igual a 20 (nota crédito referenciada) cuando el concepto de corrección corresponde a 2 (Anulación de factura electrónica) como se evidencia en la siguiente imagen.


Ejemplo SOAP:

ejemplo
Imagen 1. Estructura SOAP.



Ejemplo estructura API:

ejemplo
Imagen 2. Estructura API.


Ejemplo API:
02|91|CONSECUTIVO|PREFIJO-RANGODESDE|2024-05-22 00:00:00||COP|||1003.00|1193.57|2|2023-12-31 00:00:00|2023-12-01 00:00:00|||20||1003.00|1193.57||1|


Ejemplo estructura DLL:

ejemplo
Imagen 3. Estructura DLL.



Ejemplo DLL:

02|91|CONSECUTIVO|RANGO-CAMPODESDE|2024-05-22 00:00:00|2024-05-22|COP|0.00|0.00|5980.00|7116.20|2||||0.00|20|0.00|5980.00|7116.20|0.00|1|

Regla de Rechazo FAD09e - Mensaje: Valida que fecha de generación de la factura sea igual a la fecha de firma de la factura


Mensaje de Error:

La fecha de generación de la factura es diferente a la fecha de firma de la factura

Rechazo:


  • Si la fecha de generación de la factura es diferente a la fecha de firma de la factura


Solución:

  • La fecha de generación de la factura debe ser igual a la fecha de firma de la factura, por favor verificar y asegurar que la fecha de emisión de los documentos coincidan con la fecha de transmisión de los mismos. Es decir, que para los documentos que presenten esta regla de rechazo deben actualizar la fecha de emisión con la fecha actual y retransmitirlos.


Regla de Rechazo CAD09e - Mensaje: Valida que fecha de generación de la NC sea igual a la fecha de firma de la NC


Mensaje de Error:

La fecha de generación de la NC es diferente a la fecha de firma de la NC

Rechazo:


  • Si la fecha de generación de la NC es diferente a la fecha de firma de la NC.

Solución:

  • La fecha de generación de la Nota crédito debe ser igual a la fecha de firma de la Nota crédito, por favor verificar y asegurar que la fecha de emisión de los documentos coincidan con la fecha de transmisión de los mismos. Es decir, que para los documentos que presenten esta regla de rechazo deben actualizar la fecha de emisión con la fecha actual y retransmitirlos.


Regla de Rechazo DAD09e - Mensaje: Valida que fecha de generación de la ND sea igual a la fecha de firma de la ND


Mensaje de Error:

La fecha de generación de la ND es diferente a la fecha de firma de la ND

Rechazo:


  • Si la fecha de generación de la ND es diferente a la fecha de firma de la ND

Solución:

  • La fecha de generación de la Nota débito debe ser igual a la fecha de firma de la Nota débito, por favor verificar y asegurar que la fecha de emisión de los documentos coincidan con la fecha de transmisión de los mismos. Es decir, que para los documentos que presenten esta regla de rechazo deben actualizar la fecha de emisión con la fecha actual y retransmitirlos.


Regla de Rechazo FAN03 - Mensaje: El medio de pago debe ser informadocon relación a la tabla 14.5.4.2


Mensaje de Error:

Medio de pago informado es inválido

Rechazo:


  • Si el medio de pago no corresponde con relación a la tabla 13.3.4.2

Solución:

  • El medio de pago debe corresponder a la relación del catalogo 13.3.4.2 Medios de Pago PaymentMeansCode el cual lo encontrará en la Caja de Herramientas que dispone la DIAN en el siguiente enlace:

https://micrositios.dian.gov.co/sistema-de-facturacion-electronica/documentacion-tecnica/


Regla de Rechazo AAD09e - Mensaje: Valida que fecha de generación del evento sea igual a la fecha de firma del evento


Mensaje de Error:

Valida que fecha de generación del evento sea igual a la fecha de firma del evento

Rechazo:


  • Si la fecha de generación del evento es diferente a la fecha de firma del evento

Solución:

  • La fecha de generación del evento debe ser igual a la fecha de firma del evento.


Regla de Rechazo AAD09e - Mensaje: Valida que fecha de generación del evento sea igual a la fecha de firma del evento


Mensaje de Error:

Valida que fecha de generación del evento sea igual a la fecha de firma del evento

Rechazo:


  • Si la fecha de generación del evento es diferente a la fecha de firma del evento

Solución:

  • La fecha de generación del evento debe ser igual a la fecha de firma del evento.


Regla de Rechazo CBF03a - Mensaje: Si el CustomizationID es igual a 22 y elcac:DiscrepancyResponse/cbc:Respon seCode es igual a 2


Mensaje de Error:

Con este tipo de Notas Crédito no puede anular Facturas

Rechazo:


  • No se puede anular facturas con una nota crédito no referenciada.

Solución:

  • El indicador del tipo de operación debe ser diferente a 22 (nota crédito sin referenciada) cuando el concepto de corrección corresponde a 2 (Anulación de factura electrónica


Regla de Rechazo CAE04- Mensaje: Este elemento se debe informar cuando se requiera mencionar un periodo de tiempo


Mensaje de Error:
No fue informado el fin del periodo de facturación que modifica esta nota crédito

Rechazo:

  • Fecha de fin del periodo de facturación.

Solución:

  • Se debe informar la fecha de fin del periodo de facturación.

IMPORTANTE: Recuerde que en la estructura se debe informar primero la fecha fin y luego la fecha inicial
Ejemplos:

Ejemplo


En estructura API:

Ejemplo


En estructura DLL:

Ejemplo



Regla de Rechazo CAE02- Mensaje: Este elemento se debe informar cuando se requiera mencionar un periodo de tiempo


Mensaje de Error:
No fue informado el inicio del periodo de facturación que modifica esta nota crédito

Rechazo:

  • Fecha de inicio del periodo de facturación.

Solución:

  • Se debe informar la fecha de inicio del periodo de facturación.

IMPORTANTE: Recuerde que en la estructura se debe informar primero la fecha fin y luego la fecha inicial
Ejemplos:

Ejemplo


En estructura API:

Ejemplo


En estructura DLL:

Ejemplo



Regla de Rechazo CBG05- Mensaje: Algoritmo no corresponde.


Mensaje de Error:
Algoritmo del CUFE

Rechazo:

  • Algoritmo no corresponde.

Solución:

  • Para solucionar este rechazo en el segundo objeto de documentosReferenciados se debe informar el campo tipoCUFE como CUFE-SHA384 cuando código interno sea igual a 5. Ver imágenes anexas con las estructuras para SOAP, dll y api:
  • Segun anexo técnico 1.9


ejemplo


ejemplo xml
Imagen 1. Estructura SOAP



ejemplo plano
Imagen 2. Estructura para archivos planos API



ejemplo dll
Imagen 3. Estructura para dll.



Regla de Rechazo FAR02- Mensaje: Si no es igual al COP


Mensaje de Error:
Remitase a regla FAD15b ya que al cumplirse dicha regla verifica que este elemento corresponder al mismo valor informado en DocumentCurrencyCode

Rechazo:

  • Si monedaOrigen no es igual al COP

Solución:

  • La monedaOrigen dentro de la tasa de cambio siempre deberá ser igual a COP
ejemplo


Regla de Rechazo FAR03- Mensaje: Si trae valor igual a 1.00


Mensaje de Error:
Si trae valor igual a 1.00.

Rechazo:

  • Base monetaria de la divisa COP que se deberá convertir a moneda extranjera.

Solución:

  • La base monetaria de la divisa COP que se deberá convertir a moneda extranjera, ejemplo: si es USD el valor a informar es el valor equivalente de un dólar en pesos.
ejemplo


Regla de Rechazo ZE02- Mensaje: Valor de la Firma inválido


Mensaje de Error:
Valor de la Firma inválido.

Rechazo:

  • Valor de la Firma inválido.

Solución:

  • Con el cambio de estructura para la factura de exportación, hemos evidenciado que este rechazo se presenta cuando no se envía la estructura de información del campo extra FEXP2, que construye el nodo AdditionalInformation para los "DATOS ADICIONALES" en este caso si identifican que el envío de esta información no aplica para el cliente, se deberá enviar el nombre del campo y su valor vacío:
  • Ejemplo:

<valor>Responsable: #Lugar de Salida: #Medio de transporte: #Tipo de Doc.de transporte: #N° de Doc. de transporte: #Transportadora o Tramitadora: #País de Origen de la M/cia: #Destino: #Términos de pago: #Seguro: #Observaciones: </valor>

ejemplo