Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
ELECTRÓNICA
SANTIAGO OQUENDO GARCÍA
CONTADOR PÚBLICO, ESPECIALISTA
EN GESTIÓN TRIBUTARIA - UDEA
Conceptos generales
sobre la factura
Conceptos generales
FACTURA DOCUMENTO EQUIVALENTE
De acuerdo con el artículo 772 Es el documento soporte que
del Código de Comercio reemplaza a la factura en aquellas
“es un título valor que el operaciones con no obligados a
vendedor o prestador del facturar o personas obligadas que
servicio podrá librar y entregar decidan utilizar modalidades de
o remitir al comprador o facturación como la facturación
beneficiario del servicio”
POS, el boleto para ingreso a cine,
tiquetes de transporte de
pasajeros, etc.
Conceptos generales
• Documento sustitutivo de la
factura
Son los documentos que se
utilizan en algunas operaciones
económicas ante la necesidad de
reconocer cierta cantidad de
operaciones de un periodo para
las cuales no es posible emitir
factura individualmente, y por
ende globalizar dichas
transacciones.
Derecho - Obligación de exigir factura
o documento equivalente
Obligación
Derecho
Art 944 CCio Art 618 ET
Electrónica
Algunos Documentos equivalentes
vigentes
• Tiquetes de máquina registradora
• Las boletas de ingreso a espectáculos públicos
• Tiquetes de transporte de pasajeros
• Recibos de pago de matriculas y pensiones expedidos por establecimientos de
educación, reconocidos por el Gobierno Nacional.
• Pólizas de seguro, título de capitalización y los respectivos comprobantes de pago
• Extractos expedidos por sociedades fiduciarias , fondos de inversión, fondos mutuos de
inversión, fondos de pensiones y cesantías.
• Factura electrónica
• Descuentos de nómina
• Contratos de medicina prepagada
• Documentos emitidos por entidades de derecho público, empresas industriales y
comerciales del Estado, empresas de economía mixta donde el Estado posea más del 50%.
• Recibos emitidos por empresas prestadoras de servicios públicos domiciliarios
Sistema de control técnico
• Casos en que no se requiere Autorización de
numeración
• En la expedición de los documentos equivalentes
(excepto facturación POS y factura electrónica)
• Facturas expedidas por entidades de derecho público
• Facturas emitidas por empresas de servicios públicos
domiciliarios
• Los documentos emitidos por las cámaras de comercio,
notarías y en general los no contribuyentes del
impuesto sobre la renta.
• Decreto • Resoluci
1929 Decreto ón 019
2007 • Resoluci 2015 2242 2016
ón 14465 • Ley 1819
FE como FE como
Documento factura de
equivalente venta
LEY 1819 de 2016 – Nuevo esquema
de Facturación Electrónica
La factura de talonario o de papel y la factura electrónica se consideran factura de
venta
Catálogo de Factura
participante Adquirente
s electrónica
Proveedor
tecnológic
o
Requisitos de la factura electrónica de
venta
1. Estar denominada como factura de venta
11. Indicar calidad de retenedor del Impuesto sobre las ventas – IVA
Directamente -
Proveedor
Software
tecnológico
propio
Durante el proceso de
habilitación se debe solicitar la
autorización de numeración de
acuerdo con la resolución 055
de 2016, y con ello la DIAN
generará la clave de contenido
de control
Pasos para el Registro
Ingrese a la página de la
Pasos para el Registro
Ir a la opción Registrar
Pasos para el Registro
Cuando se ejecuta el
paso anterior se debe
ingresar nuevamente a
la plataforma y el
ambiente mostrará la
siguiente opción
Pasos para el Registro
No es
Facturador
Facturador
electrónico
Recibe Electrónico Recibe el
formato formato
original original
Recibe
representación
gráfica
Proveedor tecnológico
Se deberá reglamentar por parte del Gobierno
Nacional, sin embargo, los proveedores que 29 de
abril de 2019 se encontraran autorizados, pueden
registrarse en el catálogo de participantes siempre y
cuando hayan surtido y aprobado las pruebas del
software de facturación, de acuerdo los
lineamientos de la DIAN.
Catálogo de participantes
Es el registro electrónico administrado por la DIAN, que
provee información de los obligados a facturar
electrónicamente, los adquirentes que decidan recibir el
Formato Electrónico de generación y los Proveedores
Tecnológicos autorizados por la DIAN.
Código Único de Factura Electrónica
(CUFE)
Corresponde a un valor alfanumérico obtenido a partir de la
aplicación de un procedimiento que utiliza datos de factura,
que adicionalmente incluye Clave de Contenido Técnico de
Control* generada y entregada por la DIAN.
El código único de factura electrónica deberá ser incluido
como un campo más dentro de la factura electrónica.
Debe ser visualizada en la representación gráfica y en los
códigos bidimensionales
*Se entrega una vez se autorice la numeración para facturar en forma
electrónica y en lo sucesivo cuando el obligado lo requiera
Código Único de Documento
Electrónica (CUDE)
Corresponde a uno de los requisitos de las notas débito
y crédito y demás documentos electrónicos que se
deriven de la factura de venta, constituido por un valor
alfanumérico que permite identificar a dicho
documento.
Documentos dentro del sistema de
facturación electrónica
1.Factura de venta
2.Notas débito y crédito de la factura de venta
3.Documentos electrónicos derivados de la
factura electrónica
Generación Transmisión Validación
LOGÍSTICA
N° PREGUNTA RESPUESTA
La caja de Herramientas se encuentra publicada en el micrositio de Factura Electrónica
1 No se envió Caja de Herramienta.
https://www.dian.gov.co/fizcalizacioncontrol/herramienconsulta/FacturaElectronica/Paginas/default.aspx
¿De qué manera los contribuyentes obligados a Facturar Electrónicamente, que no están
Los documentos con la respuestas a las preguntas frecuentes, y las nuevas versiones de los anexos y
participando en el piloto de validación previa, pueden acceder a cada uno de los
ejemplificaciones con los ajustes y mejoras propuestas, están siendo publicadas de forma permanente en el portal
2 resultados, mejoras, lecciones aprendidas y otras consideraciones importantes a tener en
web de la DIAN; por lo tanto, de esta manera la información puede ser consultada por cualquier persona que se
cuenta para el momento en que deban iniciar a Facturar Electrónicamente? ¿Cada
encuentre interesada y requiera implementar dichas actualizaciones en el desarrollo de los software de facturación.
cuanto se estaría realizando dicha retroalimentación a los contribuyentes?
Hacen parte del Piloto de Validación Previa de Factura Electrónica, aquellos Proveedores Tecnológicos, ERP y
3 ¿Quiénes hacen parte del piloto?. Empresas, que aceptaron voluntariamente la invitación para vincularse a esta actividad y firmaron los documentos
de compromiso.
Todos los participantes se registran con su rol de facturador (software propio) y los P.T. que una vez hayan sido
¿En qué condición hacen parte del piloto los participantes que son desarrolladores o
4 habilitados como facturadores electrónicos deberán realizar su registro y su autorización para actuar como P.T.
proveedores tecnológicos?
dentro del piloto.
El material esta publicado en el micrositio de Factura Electrónica:
5 ¿Dónde se pueden consultar las presentaciones? https://www.dian.gov.co/fizcalizacioncontrol/herramienconsulta/FacturaElectronica/Novedades/Paginas/noticias.asp
x
Los participantes cuentan con un FACILITADOR que hace parte del proyecto en la DIAN y dos representantes de
¿Qué mecanismos de comunicación electrónica y/o telefónica están habilitados para el los participantes por grupo. Los grupos deben reportar a tráves de los representantes las inquietudes, errores y
6
reporte y atención? preguntas; inicialmente los participantes deben consultar entre sí las dudas que tengan, si en el grupo no hay
solución, los representantes deben escalarar por medio del formato establecido la consulta al facilitador.
¿La atención de soporte a Proveedores Tecnológicos se realizará por un canal especial o Para el Piloto de Validación Previa de Factura Electrónica, únicamente se atenderán las consultas, inquietudes y
7
a tráves del nuevo call center? sugerencias a través de los representantes y facilitadores de cada grupo.
GENERALES
N° PREGUNTA RESPUESTA
La materia fué reglamentada por la Resolucíon 0030 de 2019, de conformidad con lo establecido en el parágrafo 1º
¿Qué pasa si la DIAN no está disponible para la recepción o validación de documentos, del artículo 616-1 del Estatuto Tributario modificado por la Ley 1943 de 2018, estableciendo que en esos casos la
1
cual sería la contingencia a seguir? DIAN manifestará la indisponibilidad del servicio y las facturas serán envíada a los compradores sin la validación.
Cuando se restablezca el servicio el facturador dispone de 48 horas para enviar los documentos a validación.
De acuerdo con la Resolución 020 del 26 de marzo de 2019 "Por la cual se señalan los sujetos obligados a expedir
Factura Electrónica de venta con validación previa a su expedición y se establece el calendario para su
¿Qué plazo tendrán los actuales facturadores electrónicos para migrar a la versión con implementación", los seleccionados por la resolución 000072 de 2017, 000010 de 2018 y, en general, quienes se
2
validación previa?. encuentren habilitados como facturadores electrónicos, tendrían hasta el 31 de mayo para realizar el registro en la
plataforma de Factura Electrónica e iniciar a realizar pruebas de las facturas para habilitación; y conforme a la
norma deberán comenzar a facturar electrónicamente el 2 de septiembre 2019.
a. Siempre y cuando no se haya registrado, habilitado y asociado proveedor técnologico con aceptación de este en
el sistema de información MUISCA antes del 18 de enero, la persona podrá esperar la fecha de obliagación que le
a. ¿Un voluntario inscrito con el Decreto 2242 que hasta el momento no tiene actualizado
indica la Resolución 020 de 2019; cabe aclarar que, de acuerdo a la versión del Decreto 2242 de 2015 "Voluntario"
el RUT puede esperar y entrar con validación previa?
es una persona que se registró antes del 13 de agosto de 2018 o que la cual NO tenía la obliagación de facturar de
acuerdo a sus responsabilidades tributarias.
b. ¿Las empresas registradas bajo el Decreto 2242, que no han iniciado pueden esperar
3
a entrar en validación previa?.
b. Si no se habilitó antes del 18 de enero de 2019, podrá esperar a la fecha de obligación indicada en la
Resolución 020 de 2019.
c. ¿Qué sucede si un cliente envío su solicitud de voluntario antes del 18 de enero de
2019 y a esa fecha no recibió aún la aprobación...se descarta su solicitud?
c. La solicitud no se descarta, con la Resolución 01122 de 2019, fueron se les asignó la responsabilidad de
facturar electrónicamente y actualizado al RUT.
La Resolucion 020 de 26 de Marzo de 2019, fija el calendario de implementación de la factura electrónica. Los
¿Se puede ser voluntario e iniciar a facturar antes de las fechas previstas en la
4 interesados en realizar el proceso de registro como Facturador Electrónico de forma "Anticipada" pueden hacerlo
Resolución 0020 de 2019?
en el portal de Factura Electrónica esté disponible.
Generalmente, en los parqueaderos públicos se exipide documento equivalente tiquete de maquina registradora
5 ¿Cómo aplica Validación Previa en el sector de parqueaderos?.
POS, pero de igual forma deben tener la posibilidad de expedir factura de venta cuando su cliente lo solicite.
En los artículos 651 y siguientes del Estatuto Tributario, se encuentran contempladas las sanciones relativas a la
6 ¿Si los voluntarios no cumplen con algún punto de la normatividad, serán sancionados?
transmisión de información y expedición de facturas, las cuales son aplicables a Factura Electrónica.
No. En la versión Validación Previa, si la factura no es validada por DIAN, se deben corregir los errores
¿Cuando una Factura Electrónica es rechazada por la DIAN, se debe anular a través de
7 informados por la DIAN, firmar electrónicamente y trasmitir nuevamente a la DIAN con el mismo número de factura.
nota crédito?
Se aclara que el número de consecutivo de factura no será consumido para el evento de rechazo.
¿Las validaciones adicionales las debe hacer: la DIAN, la empresa que emite la factura? Es la DIAN la única entidad que realiza la Validación de las facturas electrónicas en tiempo real. El conjunto de
8
¿O las dos partes? Y qué validaciones hace cada parte. validaciones establecido por la DIAN, esta disponible en el anexo técnico.
No. En la versi de Validación Previa, si la factura no es validada ni aceptada por DIAN, se deben corregir los
¿Cuando una Factura Electrónica es rechazada por la DIAN, se debe anular a través de
9 errores informados por la DIAN, firmar electrónicamente y trasmitir nuevamente a la DIAN con el mismo número de
nota crédito?
factura. Se aclara que el número de consecutivo de factura no será consumido para el evento de rechazo.
¿Las validaciones adicionales las debe hacer: la DIAN, la empresa que emite la factura? Es la DIAN la única entidad que realiza la Validación de las facturas electrónicas en tiempo real. El conjunto de
10
¿O las dos partes? Y qué validaciones hace cada parte. validaciones establecido por la DIAN, esta disponible en el anexo técnico.
a. ¿Es posible que este documento sea oficial y avalado por la DIAN de tal manera que el
La Resolución 0030 de 2019 regula el tema. La DIAN busca garantizar una interoperabilidad sencilla y transparente
sistema de facturación gratuita de la DIAN también lo utilice?
12 generando unos mínimos requerimientos que deben ser cumplidos por los actores, sin perjucio que puedan
acordar entre ellos esquemas más sofisticados de interoperación.
b. ¿Se adoptará el modelo propuesto por el gremio como estándar de interoperabilidad?
¿Se ha pensado limitar el acceso de las empresas al servicio gratuito de facturación de la No se tiene contemplado ningún tipo de limitación en el uso del servicio de facturación gratuito a solución gratuita
13
DIAN cuando no son microempresas? que tiene a disposición la Entidad.
¿Si una factura electrónica queda fallida por la Dian y ya fue entregada al adquirente es De conformidad con lo establecido en el artículo 616-1 del Estatuto Tributario, para que una Factura Electrónica
14
válida? O se debe hacer una nota crédito para anularla y emitirla nuevamente? sea entregada al adquirente deberá estar previamente validada por la DIAN.
¿Es posible que se pueda estandarizar los formatos de la Representación Gráfica (pdf)
ya que las personalizaciones que piden los clientes pueden ser engorrosas y costosas?
Está contemplado que la representación gráfica de una Factura Electrónica deberá contener cómo mínino la
15
información que fiscalmente relevante.
Siguiendo modelos de otros países donde, si bien cada empresa puede crear sus propios
diseños, se establecen formatos estandares.
La contingencia de factura electrónica cuando sea atribuible al facturador, podrá manejarse con la expedición de
17 ¿La factura de contingencia seguiría con una resolución independiente? facturas de talonario o de papel y su diligenciamiento podrá hacerse utilizando medio cumputacionales, para lo
cuales es necesario solicitar los rangos a través de la Autorización de Numeración de Facturación.
Si un oferente está realizando Facturas Electrónicas con un XML correcto, pero la
representación gráfica tiene un error e incumple algún requisito del artículo 617 del
Para la DIAN la factura electrónica es el XML firmado y validado por la entidad. La representación grafica es una
18 Estatuto Tributario, ¿Se deben anular ante la DIAN los XML sabiendo que están correctos
forma de visualización de la factura, pero no es la factura, y debe coincidir con el XML..
o prima el XML y no hay problema que la representación gráfica tenga esa
inconsistencia?.
Se pueden regular las grandes superficies, dado que están obligando a sus proveedores
El servicio de facturación gratuita de la DIAN es un mecanismo adecuado para expedir Factura Electrónica a
a tener Factura Electrónica, y en la mayoría de los casos son empresarios muy pequeños
cualquier actor. Si existen conductas por parte de actores que vulneren los derechos de los pequeños empresarios
19 y que no están obligados; aún más los obligan a utilizar proveedores tecnológicos muy
o facturadores, pueden hacerse las denuncias ante la Superintendencia de Industria y Comercio, entidad
costosos, cuando estos empresarios pueden utilizar herramientas gratuitas, y sin pensar
competente para conocer de conductas que vulneren la libre competencia.
en que ellos no pueden pagar valores de implementación de hasta 7 millones de pesos.
Una vez se esté operando con la versión de factura electrónica con validación previa, ¿El
20 El soporte de la DIAN para Factura Electrónica se irá adaptando a las necesidades que presenten los facturadores.
soporte de la DIAN será 24/7?.
¿La versión actual de F.E. quedará inhabilitada cuando entre en vigencia la versión de Se tendrá un periodo de transición hasta el 1 de septiembre de 2019. Que a juicio del facturador podrá extenderse
21
factura electronica con Validación Previa? por otros dos meses.
Si una empresa que es actualmente responsable de IVA, pero a partir del próximo año
Deberá implementar el modelo de Validación Previa de acuerdo al Calendario establecido, según su información
22 será Gran Contribuyente debido al volumen de facturación, ¿Deberá implementar el
actual y su actividad económica (CIIU) principal registrada en el RUT.
modelo de validación previa a partir del 01 enero de 2020?
Si una empresa fue habilitada en el 2018 como Facturador Electrónico voluntario, pero
A partir de la fecha de habilitación tendrá un término máximo de 3 meses para iniciar con su Facturación
tiene inconvenientes con su software contable para entregar la información requerida de
Electrónica versión Decreto 2242 de 2015. Si vencido este término no puede iniciar con su facturación por
23 forma completa, ¿Hasta que fecha tiene esta empresa para iniciar su facturación
inconvenientes de tipo tecnológico o de tipo comercial podrá sujetarse a lo establecido en el Artículo 11 de la
electrónica y así evitar sanciones y con cuál versión debe iniciar? ¿Versión del Decreto
Resolución 0019 modificado por la Resolución 000013 de 2019.
2242 o Validación Previa?
¿Cuál fecha tomó si aparezco en el numeral 1 por actividad, pero también en el numeral Prima la responsabilidad tributaria registrada en la casilla 53 del RUT, frente a la actividad económica principal
24
2 como gran contribuyente?. registrada en la casilla 46, por lo tanto aplica la fecha establecida para los grandes contribuyentes.
25 ¿Cómo queda la vigencia del documento equivalente POS en este proceso? No ha sido modificado, por lo tanto sigue igual.
Estando en producción, cuando se crea un caso en el Contac Center de Soporte, se registra un número para el
26 ¿Se generarán números de caso con ans para soporte?
seguimiento a la respuesta.
Existen empresas en el país que realizan ventas en campo, es decir que con dispositivos
móviles y con carros; son productos que venden a las tiendas del país. Hoy en día estas
empresas cuentan con plan de datos, otras no y en algunas zonas geográficas del país
no se cuenta con cobertura de internet. El no tener acceso a internet podría ser una causal de inconveniente técnico y podría facturar por talonario / papel,
27
una vez tenga conexión a internet, deberá trascribir las factura a XML y enviarla para validación a la DIAN.
¿Como sería el modelo de validación previa para este tipo de operaciones que no
necesariamente van a tener conectividad a internet en el momento en que entregan la
factura a su cliente?.
El MINCIT indica 3 días para la aceptación tácita, pero el Ministerio de Salud indica que
Este es uno de los últimos grupos seleccionados por la DIAN para Facturar Electrónicamente, se estan
para las empresas de este sector pueden tener entre 27 hasta 60 días para pronunciarse
29 desarrollando mesas de trabajo para evaluar la casuística relacionados al sector salud. Teniendo en cuenta la
sobre una factura. ¿Como se va a trabajar estas particularidades en el ecosistema de
normativa especifica de este sector.
factura electrónica?.
Se publicó la Resolución 30 del 29 de abril de 2019, en la cual se señalan los requisitos de la Factura Electrónica
de Validación Previa a su expedición y la resolución 020 de 2019 "Por la cual se señalan los sujetos obligados a
expedir factura electrónica de venta con validación previa a su expedición y se establece el calendario para su
30 ¿Cuándo se espera que se entregue la versión final del Decreto y la Resolución?
implementación".
El Decreto que regula los documentos equivalentes, el registro de facturas electrónicas y los requisitos de los
proveedores técnologicos ya se publicó para cometarios y debe ser firmado próximamente.
Una forma de ser transparente y no generar monopolios es que el tema de la factura
31 gratuita sea operado por todos los F.E. y sea el cliente el que escoja el operador q más le Es una opción que los proveedores tecnológicos ofrezcan servicios de este tipo.
convenga.
Tanto en la versión anterior de factura electrónica, como en la de valicación previa, se mantienen los modos de
operación de Factura Electrónica a saber:
1. Solución Gratuita Dian
2. Proveedor tecnológico
¿Por qué siempre se habla de proveedores tecnológicos y no de productores de software 3. Software Propio
33
que proveen soluciones mucho más eficientes y económicas?
El modelo de negocio de los productores de software es diferente que el de los proveedores tecnológicos, por ello
su responsabildiad es mayor, tambien los requisitos y el régimen sancionatorio que les aplica. No obstante los
productore de software puden ofecer soluciones de facturación electrónica a los facturadores que lo requieran,
siempre y cuando, su modelo de negocio no se asimile al de los proveedores teconológicos.
Paragrafo 4 del articulo 616-1 del Estatuto Tributario que entrará en vigencia una vez sea reglamentado, establece
que los documentos equivalentes generados por máquinas registradoras con sistema POS no otorgan derecho a
impuestos descontables en el impuesto sobre las ventas, ni a costos y deducciones en el impuesto sobre la renta y
complementarios para el adquiriente. No obstante, los adquirientes podrán solicitar al obligado a facturar, factura
de venta, cuando en virtud de su actividad económica tengan derecho a solicitar impuestos descontables, costos y
deducciones.
34 ¿Los documentos equivalentes POS son deducibles?
PARÁGRAFO 4 Resolucion 30 de 29 de abril de 2019. Los documentos equivalentes generados por máquinas
registradoras con sistema POS no otorgan derecho a impuestos descontables en el impuesto sobre las ventas, ni a
costos y deducciones en el impuesto sobre la renta y complementarios para el adquiriente. No obstante, los
adquirientes podrán solicitar al obligado a facturar, factura de venta, cuando en virtud de su actividad económica
tengan derecho a solicitar impuestos descontables, costos y deducciones.
El procedimiento se hace a través de la plataforma de la DIAN y los requisitos estan establecidos en el articulo 12
35 ¿Cuál es el procedimiento y cuáles son los requisitos para ser proveedores autorizados?
del Decreto 2242 de 2015, en concordancia con el Decreto 1625 de 2016.
Se ha evidenciado el caso de ERP aliados con PT que impiden la interoperabilidad Estos casos deben ser denunciados ante la Superintendecia de Industría y Comercio para que sean sancionados.
36
(amarrando información del contribuyente). Se agradece denunciar, puede hacerlo incluso de forma anónima.
Si el piloto finaliza en mayo de 2019, ¿Cuándo inicia la obligatoriedad y cuál será el El 1 de mayo de 2019 ya deben realizar el registro en la plataforma los seleccionados en el primer grupo conforme
37
tiempo brindado para realizar los ajustes? a la Resolución 020 de 2019 y tendrán hasta agosto para salir a producción.
Acuse de Recibo: el adquirente que reciba una Factura Electrónica en formato electrónico de generación deberá
informar al obligado a facturar electrónicamente el recibo de la misma.
¿Cuál es la diferencia entre el acuse de recibo y la aceptación "Explícita o tácita" de la
38 Aceptación Expresa: es el mensaje emitido por el aquirente en el cual se obliga a realizar el pago de la factura de
factura?
manera irrevocable. La aceptación tácita ocurre cuando el adquiente da acuse de recibo o constancia de recepción
de la factura y pasados tres días hábiles no la rechaza, el Código de Comercio, establece que se entiende
aceptada de forma irrevocable.
39 ¿Si los proveedores tecnológicos decidieran ofrecer una solución gratuita sería válida? Es una opción viable que contribuiría a la masificación de la Factura Electrónica.
En diferentes paises se permite la eliminación y/o rechazo de las facturas. ¿Es posible
40 En caso de rechazo por parte del adquiriente, se podrá generar nota crédito.
esto en la versión 2 de Factura Electrónica?
Para la versión del Decreto 2242 de 2015 artículo 3 páragrafo 3 "Cuando la factura electrónica haya sido generada
y tengan lugar devoluciones, anulaciones, rescisiones o resoluciones deberá emitirse la correspondiente nota
crédito, dejando clara la justificación de la misma. En caso de anulaciones, los números de las facturas anuladas
41 ¿Cuáles serán las causales para emisión de nota crédito y/o débito? no podrán ser utilizados nuevamente. Estas notas deben ser entregadas al adquirente y a la DIAN, en la forma
prevista en el parágrafo 2 de este artículo".
Para la versión de Validación Previa se prevee que se debe generar la nota si únicamente está asociada a una
Factura Electrónica validada por la DIAN.
Tal como lo establece el articulo 616-1 del Estatuto Tributario, para que las Facturas Electrónicas tengan efectos
tributarios deben ser previamente validadas por la DIAN, es decir que, si no cumple con las validaciones no podrá
ser utilizada como costo, deducción y/o descontable.
44 ¿Cuál es la sanción si no se cumplen las validaciones previas?
Respecto de las sanciones para el tema de facturación electrónica, estas deben ser consultadas en el Estatuto
Tributario en los siguientes artículos: Artículo 651. Sanción por no enviar información, Artículo 652. Sanción por
expedir facturas sin requisitos, Artículo 657. Sanción de clausura del establecimiento y artículo 684-2. Implantación
de sistemas técnicos de control.
En el anexo técnico de la resolución 20 se establece la fecha de emisión (ISSUEDATE) que autoriza a facturar 5
45 ¿Cómo se va a establecer y a manejar las fechas de corte en las empresas?
días antes o 10 días despues de la fecha de la operación, con lo cual podrá manejar las fechas de corte.
Si, La DIAN dispondrá un servicio web para que los adquirientes que no son Facturadores Electrónicos puedan
¿La DIAN va a tener la opción para que los adquirientes que no son Facturadores
47 aceptar o rechazar las facturas electrónicos. (Application response de aceptación: Application response de recibo:
Electrónicos, puedan aceptar o rechazar facturas desde su portal?
) remitase al anexo técnico que se encuentra dentro de la caja de herramientas.
Una empresa que se encuentra en la versión de Validación Previa, le emite una factura a
Debe enviar el archivo XML, el application response de validación de la DIAN y de requerirlo la representación
48 un receptor que está en la versión del 2242 ¿Debe enviarle solo el XML de la Factura
gráfica.
Electrónica o debe enviársela en el sobre AttachedDocument?
El facturador podrá consultarlo a través de webservice para conocer el estado del documento transmitido a la
¿Cómo la DIAN notificará al P.T., el estado de los documentos Rechazados ya sea por el
50 DIAN. Sin embargo la DIAN comunicará el rechazo de la factura en tiempo real, cuando esta no cumpla con las
adquirente o la DIAN?
validaciones obligatorias.
Cuando se esté en contingencia por parte de la DIAN, y una vez esta se supere ¿Qué
La Factura Electrónica se entiende emitida con la entrega al adquiriente, conforme a Ley 1943 de 2018 y
51 sucede si la factura no pasa las validaciones?
Resolución 30 de 2019 Articulo 12 "Medidas en caso de incovenientes tecnológicos".
¿Cuál es la diferencia entre una Factura Electrónica nacional y una Factura Electrónica
52 En el anexo técnico se encuentran establecidas las caracteristicas que debe tener cada uno de los documentos.
de exportación?
¿Existirá algún medio a nivel software mediante el cual la DIAN notifique una caída de Esta previsto que en dado caso, se informará a través del portal Web de la Entidad por medio de un comunicado,
53
sus servicios y su reestablecimiento? conforme a la Resolución 030 de 2019 artículo 12 numeral 3.
Para el tema del factoring, ¿Que papel jugaran las entidades certificadoras de La DIAN será quien administre el registro de facturas electrónicas donde figurarán los tenedores legitimos de las
54 operaciones de factoring, en el entendido que la DIAN será quien resguarde todos los factuas y el estado de cada documento. La DIAN reglamentará la forma como podrá interoperarse con el registro
eventos que le ocurran a la factura? por parte de los interesados.
El decreto 2242 de 2015 en su artículo 3 numeral d) Indic: " la firma electrónica que
incluye la Factura Electrónica podrá pertenecer a :
- Al obligado a facturar electrónicamente.
- A los sujetos autorizados en su empresa.
- Al proveedor tecnológico, en las condiciones que acuerden, cuando sea expresamente Por favor consultar el artículo 2 de la Resolución 030 del 29 de abril de 2019 "Requisitos de la Factura Electrónica
55
autorizado por el obligado a facturar electrónicamente, para este efecto." de venta" numeral 14 .
Todos los eventos deben ser enviados a la DIAN, en el caso de “NO”, ¿cuáles serían los
eventos que deben enviarse? En caso de que “SI”, ¿cómo envía los eventos a la DIAN unLas Facturas Electrónicas de venta, las notas débito, crédito y el reporte de las facturas de contingencia, deben ser
receptor de facturas que no disponga de proveedor tecnológico? Y ¿Cómo se enteraría el envíadas a la DIAN, en caso de contingencia favor consultar la Resolución 002 de 2019 artículo 2. Para el caso de
56
emisor de los eventos que produce el receptor de la factura? la transimisión y emisión de la Factura Electrónica de venta por favor remitase a la Resulucion 030 del 29 de abril
de 2019 artículos 7 y 8.
¿Todos los eventos del aplication response se deben enviar a la DIAN?
¿Las empresas que actualmente emiten F.E., dado que ya no sera necesaria la El RUT será actualizado de oficio de forma automatica en la fecha que lo indique cada usuario finalizadas las
57
responsabilidad 37 o 38 en el RUT deberán realizar algún trámite para retirarla? pruebas de habilitación.
Las empresas que actualmente emiten F.E., ¿Podrán inscribirse como voluntarias para Deben inciar a Facturar Electrónicamente de acuerdo a lo establecido en la Resolucion 020 del 26 de marzo de
58
fase 2 desde el 11 de Mayo o deberán esperar al 1 de Agosto? 2019, o de manera "Anticipada" si lo requiere.
Ya tenemos claro como proceder cuando la DIAN entra en contingencia ¿Qué pasa
cuando el que entra en contingencia es el facturador electrónico o el proveedor
Por favor consultar el articulo 1 de la Resolución 13 de 15 de febrero de 2019, que modifico el articulo 11 de la
tecnológico. ¿En el caso del facturador electrónico deberá facturar con resolución de
59 Resolución 019 de 2016, Numeral 1, Resolución 30 del 29 de abril de 2019 artículo 12 y la Resolución 002 de 2019
contingencia y enviar posteriormente estas transacciones a la DIAN ¿En el proveedor
artículo 2.
tecnológico que tiempos tendrá para emitir las transacciones a la Dian después de
solucionar su contingencia?
¿Si quiero reenviar un documento que fue fallido, con otro número de consecutivo puedo
60 En el modelo de validación previa, el número de la factura, solo se consume cuando esta es validada exitosamente.
hacerlo, y se puede dejar el documento inicial en estado fallido?
No es posible. Si la nota crédito o débito afecta a una factura de la versión 2242 debe hacerse bajo la misma
¿Se puede hacer una nota crédito o débito en V2 correspondiente a una factura de
61 versión de de facturación, de igual forma para las notas que se deban generar para las facturas emitidas en las
Versión 1?
demás modalidades de Facturación.
Si el adquirente encuentra inconsistencias en los documentos electronicos recibidos, que No esta contemplado este tipo de error; sin embargo en caso que esto se presente, se solicita que la persona
62 debieron y no fueron detectados por la DIAN, ¿Qué procedimiento debe seguir para rechace la Factura Electrónica y se comunique con la línea de Asistencia Telefónica de la DIAN 057(1) 3556922
informar la inconsistencia? Bogotá, para abrir un caso y dicha situación entre en estudio.
En la Resolución 030 de 2019 artículo 10, se encuentra la información correspondiente a los Servicios Gratuitos
para la Factura Electrónica de venta.
¿Cual es el procedimiento para habilitarse como facturador electronico, utilizando el
63 De igual forma que para los demás contribuyentes, toda persona que requiera ser Facturador Electrónico, debe
servicio gratuito de la DIAN?.
iniciar con su registro en la plataforma de Factura Electrónica y realizar las pruebas correspondientes con el
software que haya seleccionado
¿En las consultas que se realizan con autenticación, para verificar documentos y listado
Solo podrá consultar sus propias facturas. La búsqueda se podrá realizar por: CUFE, ID del documento, código
64 de documentos, el facturador electrónico tiene acceso a todas las facturas electrónicas
QR, por período de tiempo, y por NIT.
registradas en la DIAN o que restricciones existen?
Tenga encuenta que para toda transacción comercial se debe emitir factura, sin importar la modalidad de pago,
65 ¿Cuándo la venta fue con medio de pago de contado, se genera acuse de recibo? siempre debe entregar factura al adquiriente, por favor consultar el Concepto 057186 de 2013 emitido por
Normativa y Doctrina de la DIAN.
¿Cuándo un facturador electrónico cambia de proveedor tecnológico debe realizar algún Si la persona cambia de Proveedor Técnologico, debe realizar nuevamente el proceso de habilitación con el nuevo
66
procedimiento? software hasta completar las pruebas indicadas por la plataforma.
Es correcto, la persona debe realizar el proceso de registro y habilitación en la nueva plataforma de Factura
¿Un facturador electrónico que se encuentre en estado producción bajo el decreto 2242,
67 Electrónica, la cual es para la versión de Validación Previa, este proceso incluye realizar las pruebas
debe surtir el proceso de habilitación bajo el modelo de validación previa?
correspondientes para registrar el software.
Un juez autorizado puede consultar la Factura Electrónica, verificar si esta tuvo aceptación tácita o explícita; los
68 ¿La DIAN otorga factura como medio probatorio?
jueces podrán acceder directamente a la Dian.
Esta información se puede consultar en el Cátalogo de Participantes que se encuentra disupuesto en la página
69 ¿Cómo se establece si el facturador está en nueva o antigua versión?
web de Factura Electrónica.
Solamente la Factura Electrónica que haya sido validada de manera exitosa por la DIAN es la que consumira el
70 ¿La Factura Electrónica enviada y rechazada consume numeración?
consecutivo.
Conforme a la Resolución 020 de 2019, existen dos fechas, la primera es la fecha de registro y la segunda es
fecha de obligatoriedad para iniciar a Facturar Electrónicamente, dentro de estos meses se deben realizar las
71 ¿Hay una línea de tiempo establecida para las pruebas de habilitación?
pruebas, siendo el contribuyente quien determina si inicia las pruebas desde el momento de registro o
posteriormente.
El sujeto que presta el bien o servicio, es quien debe facturar y cobrar los impuestos correspondientes en el
momento de la operación. El recaudo, de esa factura a plazo realizada por un tercero no da lugar a impuestos
Los impuestos que se generan por pagos a terceros, estos deben ser asumidos por el adicionales, es solamente un recaudo para un tercero. Para el caso de Fiduciarias o de contratos de mandante /
72
tercero o por quién emite la factura electrónica. mandatario, dentro del Anexo Técnico y las ejemplificaciones de los XML de las Facturas Electrónicas esta el
formato en que se deben desarrollar las Facturas Electrónicas de este tipo, por la tanto al ser transmitidas y
emitidas, se entenderá cual es el modelo de negocio y que el ingreso es para un tercero.
Teniendo en cuenta que una factura de venta (Sin importar la modalidad de la misma) es un soporte fiscal de las
obligaciones que adquieren ambas partes dentro de una transacción comercial, se debe aclar que como tal la
Si existe una diferencia entre un documento fiscal electrónico y un documento tributario
73 Factura Electrónica es un documento electrónico y a su vez un documento tributario, ya que tanto para demostrar
electrónico, es necesario aclararla o dejar un solo concepto
los recaudos de IVA, tener impuestos descontables y en caso de presentarla como prueba de una transacción, la
Factura Electrónica es válida.
Los eventos producidos sobre un documento, hay que informarlos, además de la DIAN, a
Todos los documentos electrónicos deben validarse en la DIAN, los de aceptación y título valor estarán
74 la contraparte, ¿Saldra alguna reglamentación de la forma de envío o es de libre elección
reglamentados en la Resolución de registro.
del emisor?
Todos los documentos electrónicos deben validarse en la DIAN, los de aceptación y título valor estarán
76 Hay aceptación tacita en application response?
reglamentados en la Resolución de registro.
Los eventos generados por el receptor, como por ejemplo: recibo, aceptación o rechazo,
Todos los documentos electrónicos deben validarse en la DIAN, los de aceptación y título valor estarán
77 ¿pueden ser aplicados para las notas crédito, notas débito y las facturas que hayan sido
reglamentados en la Resolución de registro.
generadas por contingencia?
1. Hay un servicio mediante el cual el adquiriente o el facturador pueden consultar el estado de una factura, el
¿Cada cuánto tiempo se tendrá que realizar peticiones sobre todas las facturas que están sistema de la DIAN le devuelveve todos los eventos, asociados a esa factura: EL RESULTADO DE LA
pendientes de dichos eventos, teniendo en cuenta que esta información es vital, NO solo VALIDACIÓN, el acuse de recibo, la aceptación y el rechazo; esto se relizará por medio de webservice.
79
para temas de titulo valor, sino también para poder las áreas de crédito y cartera controlar
sus procesos de radicación y recaudo de dinero? 2. Las funcionalidades del registro de factura estan siendo desarrolladas. El facturador o el adquiriente dispondrán
de un método en el webservice para solicitar rangos de fechas de las facturas autorizadas.
Si el adquiriente rechaza directamente en la plataforma de la DIAN, la DIAN va a notificar NO, el facturador puede consultar las facturas con los eventos que tienen asociados. Su procedimiento deberá
81
al P.T. para que este le notifique al cliente ? definir el momento en el qué utilizará el método dispuesto para tal fin.
Es un reqisito contemplado en el proyecto de Decreto que reglamenta, entre otros temas, lo requisitos que deben
82 ¿Van a exigir conocimiento o certificación de UBL?
cumplir los proveedores tecnológicos
Cuando el adquiriente rechaza la factura dentro de las 72 horas que tiene para hacerlo, el
facturador electrónico tiene dos opciones:
83 1. Hacer la NC de la factura y hacer el proceso nuevamente con una nueva factura. El Facturador Electrónico debe realizar las respectivas notas credito.
2. ¿No hacer nada?, esto es posible?, que el F.E. al saber que tiene un rechazo no haga
nada, se puede dar el caso?
TÉCNICAS
N° PREGUNTA RESPUESTA
1. No, cada participante deberá contar un con un certificado digital (puede ser el mismo o distinto al utilizado para
firmar los DFE), tendrá las mismas carácteristicas de los certificados de la versión 1 de Factura Electrónica, deberá
Dentro de las consideraciones del Anexo Técnico en el capítulo 11: aspectos
ser expedido por una entidad de certificación abierta acreditada por la ONAC..
tecnológicos de los web service de validación previa DIAN Menciona que "para garantizar
2. Para la autenticacion el Web Service no se necesita conocer la llave privada. El sistema consulta el NIT del
la comunicación segura el software cliente deberá autenticarse ante la DIAN utilizando
emisor dentro del certificado en la propiedad "subject"
certificado digital", sin embargo, no especifica como es el uso de dicho certificado digital
3. No aplica para la autenticacion. El XML es el que va firmado por el emisor.
para consumir el servicio. Al respeco se plantean las siguientes inquietudes:
4. Es valido mientras la entidad certificacion siga expidiendolo o el emisor contenga a la fecha uno vigente
1
La autenticación de los usuarios es mediante un certifiacdo digital, dicho certificado debe corresponder
1. ¿Este certificado será provisto por la DIAN, o cada PT deberá tener uno?
"Pertenencia empresa" el cual contiene dentro del nombre de la empresa el NIT de la misma y los datos de
2. ¿Cómo será el manejo de las llaves del certificado?
identificación y nombre del suscriptor, todas las entidades de certificación de Colombia venden certificados
3. ¿Qué información se cifrará?
digitales de "Pertenencia empresa" a "Pertenencia empresa" este certificado será utilizado en los campos previstos
4, ¿Es requerido un certificado tipo .p12? [.pfx] o va a ser otro tipo de certificado ?
dentro del web service para que sea incorporado en la transacción de tal forma que el servidor de la DIAN le da la
información del webservice extraerá el certificado y extraerá la información de la empresa y de quien está haciendo
la operación "logon" "Logon"
3 ¿Cual es el tiempo estimado en que tardará el sistema en realizar las validaciones? El proceso de validación se hace en línea en fracciones de segundo.
En las facturas electrónicas se debe incluir información sobre la forma de pago establecida en la transacción
4 ¿Se contempla dentro de la validación previa, el reporte de pagos en diferentes paises? económica, de acuerdo con las listas de valores relacionadas en el anexo técnico y se puede incluir información de
detalle como pagos en diferentes paises.
No hay problema si los nombres de productos y demas datos de la factura son en ingles… El validador no controla
5 Hay clientes que exigen la factura en inglés, es posible configurar el idioma en el XML.
el idioma contenido dentro de los elmentos. Tampoco el UBL contiene un elemento que defina el idioma.
En las notas se hace referencia a la resolución de autorización, así como al rango de A las notas NO se les autoriza numeración por parte de la DIAN, pero si deben ser numeradas por la línea de
6
numeración otorgado. Esto no es válido en estos documentos no es así? negocio y/o establecimientos de la empresa de forma consecutiva.
¿El CUFE se debe calcular con SHA1 o con SHA256/256/512?
Nota-2: las verificaciones sobre la autorización del NumFac en el SIE FE para los
documentos-e con el «/fe:Invoice/cbc:InvoiceTypeCode=3» se realizan y se registran por
parte de la DIAN para las operaciones de recepción electrónica. Los documentos-e con
7 «/Invoice/cbc:InvoiceTypeCode=3» entregados a la DIAN antes de la fecha de aplicación EL CUFE debe ser calculado con SHA384.
de esta medida correctiva en el Sistema informático (agosto 15 de 2018), y que aparecen
con el resultado de la verificación del NumFac como “fallido”, serán sometidas al
tratamiento de excepción porque el error se originó en la información suministrada por la
DIAN.
¿A qué se refieren con No Operativos en “Recepción ATT (DFE y AR) PA. Son Metodos del Web Service que se tenian contemplados para la figura de un Proveedor Autorizado "PA" pero al
8
(SendBillAttachmentAsync) – No Operativos”? no haber reglamentación del mismo, estos no se encuentran en operación.
¿Por qué no se tiene más información sobre los WS Descarga de NSU no utilizados
Son Metodos del Web Service que se tenian contemplados para la figura de un Proveedor Autorizado "PA" pero al
9 (ReceiveNsuUnusable) – No Operativos y Consulta dicontinuidad de NSU para PA
no haber reglamentación del mismo, estos no se encuentran en operación.
(ConsecutiveNsuMissingPackByPA) – No Operativos?
Para la versión de validación previa de facturas electrónicas no se tiene en cuenta esta validación que se realizaba
Antes del modelo de validación previa se debía informar el elemento los elementos
en la versión 1 "2242". Directamente se tienen que regir a la información solicitada sobre el nuevo anexo de
cac:AccountingCustomerParty/cac:Party/cac:Person/cbc:FirstName y
validación previa ( /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyName nombre comercial de la
10 cac:AccountingCustomerParty/cac:Party/cac:Person/cbc:FamilyName cuando el elmento
persona jurídica y nombre de la persona natural.
cac:AccountingCustomerParty/cbc:AdditionalAccountID era igual a 2 (persona natural),
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:RegistrationName Razón social de la
¿en esta vversión de factura electrónica es requerida esta validación?
persona jurídica.
¿Cómo se asegura que en la versión de validación previa de facturas electrónicas no La versión de validación previa operativamente esa estructurada para funcionar en la tecnologia cloud, lo que
17
queden encoladas las facturas electrónicas? garantiza mayor capacidad de recepción.
Respecto del tema de redondeos , Es de mucho valor la propuesta que hace la Dian en el
documento de especificación técnica, sin embargo, de la manera que se plantea en el
documento se interpreta que es opcional. Por otro lado, si se revisa en detalle este ítem,
se hace necesario la generación de una normativa que regule el mecanismo de redondeo
aprobado por la Dian, sobre que componentes se puede aplicar (líneas,totales y campos
20 No, ya que no corresponde a la Entidad reglamentar ese tema.
en general del documento) de manera que desde los sistemas fuente (ERP) se garantice
la salida con la calidad de datos requerida para que el documento tributario se componga
de la manera adecuada. Nos podrían confirmar que mecanismos se van a implementar
para garantizar la gestión de redondeos? Se requieren varios ejemplos de redondeo
usando las diferentes cifras decimales que los sistemas entreguen.
¿Las personas naturales pueden tener dígito de verificación?, ¿Si es así, debemos El validado exige que se informe el digito de verificacion si el tipo de persona es jurida. Naturales no lo exige ni lo
22
tenerlo en cuenta en las validaciones? valida
23 ¿El application response es un xml adicional? SI, cada uno de ellos son XML adicionales que tienen el mismo CUFE de la factura original.
Qué diferencia existe entre los unitCode "EA" y "NIU", que aparentemente son genericos
27 NIU: Número de unidades internacionales.
para cuando no existe una unidad de medida especifica.
En qué casos se debe usar el campo "cac:AlternativeConditionPrice" y para qué está Cuando se necesita informar el precio real de un articulo que no va ser cobrado al cliente, ejemplo un regalo pero
28
creado especificamente? el impuesto si es pagado
Cuando la factura toda esta en pesos y se paga en pesos es necesario añadir el campo
29 No es necesario si es en PESOS…Este campos campo opcional y asi está descrito en el anexo
"cac:PaymentExchangeRate"?
La actualización de los códigos DIAN de los catálogos será notificada de alguna manera
36 La DIAN diseñará un procedimiento para realizar los ajustes e informarlos a los facturadores.
sistemática a los PT? Cual será el medio?
37 Hay algún servicio para envío masivo de comprobantes? Se podrán enviar F.E. por lotes.
La DIAN valida el campo de notas crédito llamado billingreference en cuanto al ID y Se permitirá la inclusión de varias facturas pertenecientes al mismo adquirente dentro de una nota crédito, la
38 UUID para no permitir relacionar varias facturas. Se debe normar si van a permitir más de referencia de cada factura corresponderá al CUFE de las facturas validadas previamente y que hayan sido
una factura en documento nota. emitidas por el facturador que elabora la Nota Crédito.
Estos elementos son opcionales. Serán controlados en ocasión de que el facturador este interesado en que la
39 Se deben transmitir los campos forma de pago y fecha de vencimiento?
factura sea registrada como "Título valor".
En el anexo técnico - Se indica que deben realizarse controles lógicos como por ejemplo
"no permitir una dirección de cliente en Colombia en una operación de exportación" ¿se El control no será hecho por la existencia de las direccioones, estará asociado a la coherencia del tipo de
40
debe controlar ese tipo de datos?, la DIAN proveerá algún mecanismo de validación de operación, en ocasión de una exportación el adquirente no debe tener una dirección cuyo país sea Colombia.
direcciones?
Que la regla no es obligatoria. De manera general se interpreta que la cardinalidad "0...n" indica que este elemento
¿Qué es considerado una discrepancia menor importante para que en las reglas de
41 es opcional. La regla será obligatoria cuando la cardinalidad sea "1….n".- En ocasión de la no obligatoriedad y al
validación se considere como "Notificación"?
incumplimiento harémos una notificación y en ocasión de "1...n" la DIAN generará un rechazo.
Información Genérica Sobre una Persona o Entidad: cac:Party ¿Cuál es el contexto del Siempre debe incluirse; "Party" es el fragmento donde se incluyen los atributos del vendedor y del comprador o
45
apartado?, en que casos aplica el uso de esta información y en que casos no? adquiriente.
Esas operaciones deben registrarse en forma expicita, si el descuento se aplica a toda la factura el fragmento
"allowancecharge" irá en la sección de cabecera del XML. Si el descuento se aplica a alguno de los ítems, el
Como debe ser la dinámica de descuentos, cargos, impuestos, anticipos, si se informan elemento "allowancecharge" se incluirá en dicho ítem. Los valores incluidos en el elemento "allowancecharge"
46 a nivel de detalle se deben informar a nivel de documento?, como se deben representar afectaran el valor total del ítem, los valores "allowancecharge" del nivel de cabecera afectaran a toda la factura, por
estos diferentes escenarios en el xml? lo tanto las sumátorias algebraicas incluidas en ... harán las operaciones de crédito o de débito (de resta o suma)
pertinentes para obtener el gran total de la factura. No son excluyentes los dos tipos de "allowancecharge"
anteriormentes descritos, pueden ser incluidos ambos dentro de una misma factura.
52 ¿Cómo va a ser la dinámica para el “Recibimiento de Documento”? Ver manual técnico. (PREPARACIÓN) WEBSERVICE REQUEST
Este servicio no será prestado por Factura Electrónica, debe ingresar a su cuenta de usuario en el sistema de
54 ¿Qué servicios va a disponer la DIAN para que se pueda validar el estado del RUT?
información MUISCA.
Como se debe interpretar que en la estructura del xml tanto el nombre como la
55 Anexo tecnico publicado en el micrositio de factura electronica
identificación del adquirente sean opcionales?
Se debe entender que todos los campos R son obligatorios ya que se plantea una
56 La columna ocurrencia define si los campos son obligatorios o no.
validación condicional sobre estos en algunos casos?
En la página 543 del documento “Anexos Técnicos” se mencionan las rutas Xpath para la
60 localización del Signature de los documentos Invoice, CreditNote y DebitNote, pregunta: El attached document lo debe firmar el emisor, por lo general se tratará del Facturador Electrónico.
¿Por qué no aparece el Xpath del Attached Document?, ¿este no se firma?
Las agencias de viajes suelen discriminar en su factura los ingresos propios de los
ingresos de terceros. En los ingresos a terceros por ejemplo incluyen los ingresos por
61 venta de pasajes aereos y de paquetes turisticos, ofrecidos por terceros como las Esta opcion de facturación esta desarrollada para mandato, que puede ser consultada en la caja de herramientas.
aerolineas y los hoteles. Así mismo discriminan el IVA propio y el IVA de terceros, cómo
se debe reportar esta situación en el XML?
62 El documento que se entrega al receptor, ¿es el contenedor, AttachedDocument? Contendor con factura y app response de la Dian.
Cuando se realizan eventos es necesario informar a la contraparte (NO DIAN) con el
63 Unicamente el AppResponse
attachedDocument o es permitido enviar unicamente el ApplicationResponse.
Este contenedor, AttachedDocument, ¿debe contener el UBL 2.1 del documento y todos
64 Debe ser con el formato establecido y siguiendo las caracterísitcas referidas en el anexo técnico numeral 3.5
los eventos producidos sobre él?
Los documentos están definidos por el estándar XML UBL 2.1, ¿se va a permitir la
68 utilización de todos los elementos definidos en el estándar?, o por el contrario ¿se va a El anexo señala cuales elementos del estandar son obligatorios
limitar a un subconjunto del UBL 2.1?
Que pasa si un cliente por error envia mas de 10000 documentos en el ambiente de
70 Pruebas en un periodo muy corto de tiempo. Existira algún tipo de baneo al emisor? O al No
servicio por el cual se envio?
71 Existe algún limite de envio de eventos (ApplicationResponse)? No siempre y cuando cumplan las reglas definidas en la matrix de eventos
Que pasa si regalo el item y quiero regalar el impuesto tambien, pero no quiero imprimirlo
72 En la ejemplificación se detalla como funciona esta transacción y lista de descuentos a nivel de factura
en la representaión gráfica?
Si, es una opción para los grandes facturadores la manera en qué podrán utilizar un método con el cual de forma
75 Se pueden enviar lotes de facturas? asicncronica entregará un paquete de facturas a la DIAN, las cuales podrán ser recogidas posteriormente mediante
mecanismo id tracker.
76 Cuantas pruebas se requieren en el proceso de habilitacion por cada sector? 100 factura 20 notas credito y 20 notas debito
Como nos registramos como proveedor electronico con validacion previa, va existir un El tema fue desarrollado por la Resolucion 30 del 29 de abril de 2019. La guia podra ser consultada en el
77
manual? micrositio de factura electrónica
El algoritmo de redondeo se debe aplicar a los totales por factura o a los totales por
79 Es opcional su aplicación
renglón antes de calcular los de la factura.
83 LB01 - Address: El elemento de la pagina 43 a quien pertenece cual es el padre Depende de donde lo utilice
85 fb04 - @unitCode: Unidades de medida para que las quieren, porque es obligatoria Por estandarización de información.
P᧩na 22, identificador AA15, se menciona que la ocurrencia es 0..1, solo se manejaria en
90 Son 5000 caracteres, casi 10 páginas, se estima más que suficiente.
esta versina sola nota mḩmo?
La DIAN no reglamenta el uso de firmas electrónicas para recibir documentos que serán sometidos a la validación
previa, si mediante la aplicación que se defina en el Decreto, el adquiriente y su facurador acuerdan usar firmas
Se permitirá el uso de una firma electrónica. electrónicas como parte de sus modelos operativos, su uso será de responsabilidad exclusiva de este par de
sjuetos, la legitimidad y el no repudio estará de quienes firmaron el acuerdo de utilizar en sus modelos operativos
92
a. Una firma electrónica se basa en el uso de un certificado digital X509v3 pero que No firmas electrónicas. El facturador electrónico o el adquiriente electrónico enviarán documentos electrónicos a la
emitió una CA abierta reconocida en Colombia. DIAN firmados con certificados expedidos por ECD, acreditados por la ONAC, exclusivamente. Si el facturador
incluyo documentos firmados electrónicamente dentro de su reporte de algún evento a la DIAN se respetará la
legalidad de dicho documento adjunto.
Como se maneja en cuanto a los códigos de tipos de documento (13, 31, 32, etc) como
94 se manejan las empresas asociadas a una cédula con dígito de verificación (RUT), ya Eso es NIT.
que en el anexo técnico no se especifica este caso.
95 Se debe cambiar a un nuevo sistema para enviar los XML? Los documentos que envíe de FE V2 deben cumplir con las condiciones establecidas en el anexo técnico.
¿El Código Postal ahora obligatorio en el eDoc debe solicitarse en formato básico o
97 Es un campo obligatorio.
ampliado para el caso de ciudades?
Sobre el evento 3.5.4.1. Uso Autorizado por PA, mencionan que “Este evento debe ser
100 enviado por el PA al emisor del DFE validado, y deberá también ser enviado por el emisor Este evento no será utilizado en está versión.
para el adquirente, en el mismo contenedor del DFE.” ¿a qué se refieren con eso?
¿Es correcto interpretar que aquellos eventos donde el responsable es la DIAN, son
101 Los eventos responsabilidad de la DIAN, UNICAMENTE los elabora y emite la DIAN.
XMLs ApplicationResponse que no tiene facultad para elaborarlos el PA/PT?
102 ¿Hay penalización si se intenta registrar un evento impedido por la matriz de eventos? Es un rechazo.
similares
105 ¿Es obligatorio que el Receptor registre el evento de Acuse de recibo? Lo genera el PT? No es obligatorio.
RESOLUCIÓN NÚMERO 000020
(26 MAR 2019)
Por la cual se señalan los sujetos obligados a expedir factura electrónica de venta con
validación previa a su expedición y se establece el calendario para su implementación
CONSIDERANDO
Que el artículo 615 del Estatuto Tributario dispone: “Obligación de expedir factura: Para
efectos tributarios, todas las personas o entidades que tengan la calidad de
comerciantes, ejerzan profesiones liberales o presten servicios inherentes a éstas, o
enajenen bienes producto de la actividad agrícola o ganadera, deberán expedir factura
o documento equivalente, y conservar copia de la misma por cada una de las
operaciones que realicen, independientemente de su calidad de contribuyentes o no
contribuyentes de los impuestos administrados por la Dirección General de Impuestos
Nacionales…”
Que el artículo 616-1 del Estatuto Tributario, establece: “Artículo 616-1. Factura o
documento equivalente. La factura de venta o documento equivalente se expedirá, en
las operaciones que se realicen con comerciantes, importadores o prestadores de
servicios o en las ventas a consumidores finales.
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
estos casos, la factura se entenderá expedida con la entrega al adquiriente y deberá
ser enviada a la Dirección de Impuestos y Aduanas Nacionales - DIAN o proveedor
autorizado para su validación dentro de las 48 horas siguientes, contadas a partir del
momento en que se solucionen los problemas tecnológicos.
La validación de las facturas electrónicas de que trata este parágrafo no excluye las
amplias facultades de fiscalización y control de la Administración Tributaria.
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
Las entidades autorizadas para realizar actividades de factoraje tendrán que desarrollar
y adaptar sus sistemas tecnológicos a aquellos de la Dirección de Impuestos y Aduanas
Nacionales-DIAN.
1. Expedir factura y/o documentos equivalentes y/o sustitutivos vigentes, por los
métodos tradicionales diferentes al electrónico.
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
Que el artículo 617 del Estatuto Tributario establece: “Artículo 617. Requisitos de la
factura de venta. Para efectos tributarios, la expedición de factura a que se refiere el
artículo 615 consiste en entregar el original de la misma, con el lleno de los siguientes
requisitos:
Al momento de la expedición de la factura los requisitos de los literales a), b), d) y h),
deberán estar previamente impresos a través de medios litográficos, tipográficos o de
técnicas industriales de carácter similar. Cuando el contribuyente utilice un sistema de
facturación por computador o máquinas registradoras, con la impresión efectuada por
tales medios se entienden cumplidos los requisitos de impresión previa. El sistema de
facturación deberá numerar en forma consecutiva las facturas y se deberán proveer los
medios necesarios para su verificación y auditoría.
Que el parágrafo transitorio del artículo 915 del Estatuto Tributario, establece: “Los
contribuyentes que opten por el impuesto unificado bajo el régimen simple de tributación
-SIMPLE, tendrán plazo para adoptar el sistema de factura electrónica hasta el 31 de
agosto de 2019.”
Que el artículo 18 de la Ley 1943 del 28 de diciembre de 2018, señala: “ARTÍCULO 18°.
Elimínense todas las referencias al régimen simplificado del impuesto a las ventas y del
impuesto nacional al consumo. Las normas que se refieran al régimen común y al
régimen simplificado, se entenderán referidas al régimen de responsabilidad del
impuesto sobre las ventas -IVA.”
Que, de acuerdo con lo anterior, se hace necesario señalar los sujetos obligados a
expedir factura que deben adoptar el sistema de factura electrónica de venta con
validación previa a su expedición y fijar el calendario con las fases y fechas en las cuales
se debe iniciar con la citada obligación.
RESOLUCIÓN NÚMERO 000020 de 26 MAR 2019 Hoja No. 5
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
RESUELVE
Artículo 2. Sujetos que deben expedir factura electrónica de venta con validación
previa a su expedición. Los sujetos que deben expedir factura electrónica de venta,
en lo sucesivo facturadores electrónicos, son los siguientes:
4. Los sujetos que opten de manera voluntaria por expedir factura electrónica.
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
Para efectos de dar aplicación a los títulos que identifican las columnas que contienen
los calendarios de implementación de la factura electrónica de venta de los numerales
1 y 2 del presente artículo, se deben tener en cuenta las siguientes definiciones:
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
e) Código CIIU División a dos (2) dígitos - Código CIIU a tres (3) dígitos (sólo para
divisiones 46 y 47): El Código CIIU División a dos (2) dígitos, corresponde a la
Clasificación de Actividades Económicas – CIIU revisión 4 adaptada para Colombia,
indicada en el Registro Único Tributario -RUT, a la fecha máxima de registro del
literal b). El Código CIIU a 3 primeros dígitos, corresponde a la Clasificación de
Actividades Económicas – CIIU revisión 4 adaptada para Colombia, indicada en el
Registro Único Tributario -RUT, a la fecha máxima de registro del literal b).
f) Otros sujetos: Indica los sujetos obligados a expedir factura electrónica de venta,
que corresponden al numeral 2 del presente artículo, independientemente de la
actividad económica registrada en el Registro Único Tributario –RUT.
Continuación de la Resolución “Por la cual se señalan los sujetos obligados a expedir factura electrónica
de venta con validación previa a su expedición y se establece el calendario para su implementación”
___________________________________________________________________________________
Una vez se cumpla el plazo relacionado con la fecha máxima para iniciar la expedición
de la factura electrónica de venta, se deberá cesar la expedición de la factura
electrónica sin validación previa a su expedición de que tratan los artículos 1.6.1.4.1.1.
al 1.6.1.4.1.21 del decreto 1625 de 2016 y la misma no será reconocida como un
sistema de facturación de conformidad con lo indicado en el artículo 616-1 del Estatuto
Tributario; lo anterior también aplicará para quienes implementen la factura electrónica
de manera anticipada, de acuerdo con lo establecido en el artículo 4° de esta resolución.
FIRMADA EN ORIGINAL
LUZ GABRIELA BARRIGA LESMES
Directora General (E)
Ingreso
Solución Tecnológica
www.dian.gov.co
Ingreso al Sistema
Registro
Una vez se ingrese al sistema al hacer clic en el menú Participantes se
desplegará el submenú Facturador.
Submenú Facturador
En este submenú el usuario podrá ver los datos de su empresa NIT, Nombre, Razón
Social, Correo Electrónico, Estado de Aprobación, Tipo de facturador, Fecha máxima
de registro, Fecha máxima de inicio, Número de resolución y Fecha de
resolución. En el menú Facturador la primera acción que debe hacer un usuario es
Registrarse en caso de que no esté registrado en el sistema.
El tipo de facturador puede ser Voluntario u Obligado. Para que un facturador sea
obligado debe cumplirse que la fecha de registro sea mayor o igual a la fecha máxima de
registro de la parametrización de lo contrario será un facturador Voluntario.
Registrarse
Un facturador debe estar registrado en el sistema para poder realizar alguna acción.
En la interfaz Facturador electrónico debe indicar qué modo de operación ocupará para
facturar. Dé clic en el botón Configurar modos de operación.
Si selecciona Software gratuito, los datos son por defectos los que se muestran.
Una vez aparezca la opción de facturador gratuito en el menú, dar click en esta
opción y lo direccionará a la herramienta de la solución gratuita de la DIAN con
validación previa.
Para usar la herramienta debe dirigirse al manual de “Guía Factura
Electrónica Gratuita DIAN”
Una vez que el facturador emita sus facturas de prueba y queden aprobadas, el estado
de su modo de operación pasaría automáticamente a “Aceptado”. Además, el estado
de aprobación del facturador cambiaría automáticamente a “Habilitado” y podría
Si selecciona Software propio deberá colocar el Nombre y el Pin del software para poder
adicionarlo.
Una vez que se adiciona el modo de operación Software propio se añade al listado
indicando en qué estado se encuentra hasta el momento.
Al hacer clic en el botón Detalles se muestra una gráfica indicando el resumen de los
documentos recibidos y aceptados para el set de pruebas en correspondencia con los
asignados en máximo requerido y total mínimo requerido aceptados.
Ilustración 16. Detalles del set de prueba para Software propio
Una vez que el facturador emita sus facturas de prueba y queden aprobadas, el estado
de su modo de operación pasaría automáticamente a “Aceptado”.
FUNCIONALIDADES DE LA HERRAMIENTA
Los modos de operación pueden ser eliminados en caso de que el facturador no desee
ocuparlo o simplemente tuviera algún error en el momento de configurarlo. Debe hacer
clic en el icono que se encuentra en el listado de los modos de operación para realizar
la acción Eliminar.
Una vez que hace clic sobre el icono el sistema muestra un mensaje de advertencia
confirmando si desea eliminar el modo de operación.
Menú dashboard
Submenú Enviados
Filtros
En la interfaz documento Enviados puede hacer buscadas por diferentes filtros:
CUFE, NIT receptor, Rango de Fechas (Últimos 7 días, Mes actual, Mes anterior,
Últimos 3 meses, Rango de fechas), Estado (Aprobado, Aprobado con notificación),
Tipo de documento (Factura electrónica, Factura de exportación electrónica,
Factura de contingencia electrónica, Nota de débito electrónica, Nota de crédito
electrónica) y Tipo de referencia (Notas de crédito electrónica y Nota de débito
electrónica) y luego hacer clic en el botón Buscar.
Ilustración 26. Filtros documentos enviados
Para ver los detalles de los documentos se debe seleccionarlo haciendo clic sobre este.
Los detalles que se muestran del documento seleccionado son: Estado, Tipo de
documento, Folio, Fecha de emisión, Datos del emisor, Datos del receptor, Totales e
impuestos, Validaciones del documento y Eventos del documento.
Página 24 de
Versión del documento: 00
8
Descargar documento
Versión 001
Página 1 de 812
Control de Versiones
2019-05-13 2.0 Anexo técnico resolución 000030 del 29 de abril Jaime Humberto Niño
del 2018 Anexo técnico de factura electrónica de Peña.
venta Wilmer Camilo Bernal
Rodríguez
Elton Alvaro Gomez
Bonilla.
Ramon Alonso
Espinosa Echeverry
Rodrigo Perez
Eric Van Boxsom
Jose Gregorio
Rodríguez Stevenson
Página 2 de 812
Sumario
Índice de Tablas .......................................................................................................................................................... 9
Índice de Figuras......................................................................................................................................................... 9
1. Introducción .........................................................................................................................................................11
1.1. Confiabilidad de la información: el Formato .................................................................................................11
1.2. Calidad de la información: las Validaciones ...................................................................................................11
1.2.1. Redondeos............................................................................................................................................ 12
1.2.1.1. Redondeos valores monetarios CurrencyCode................................................................................12
1.2.2. Identificador de los documentos electrónicos ..................................................................................... 13
2. Convenciones utilizadas en las tablas ...................................................................................................................14
2.1. Columnas de las tablas de definición.............................................................................................................14
2.2. Tipos de campos de los archivos XML ...........................................................................................................14
2.3. Tamaños de los elementos ............................................................................................................................15
2.4. Convenciones utilizadas en las Tablas de Reglas de Validación .....................................................................16
2.5. Ubicacion estándar para información común................................................................................................17
2.5.1. Invoice: Gestión de los campos de fechas para Documento Electrónico ............................................. 17
3. Formato para la generación de los Documentos Electrónicos .............................................................................19
3.1. Factura Electrónica: Invoice ...........................................................................................................................19
3.2. Nota Crédito: CreditNote...............................................................................................................................78
3.3. Nota Débito: DebitNote ...............................................................................................................................131
3.4. Contenedor de documentos: AttachedDocument ......................................................................................184
3.5. Registro de evento: ApplicationResponse ...................................................................................................190
3.5.1. Garantía de que el evento será registrado en el documento correcto............................................... 190
3.5.2. Relacionamientos mutuos entre los eventos ..................................................................................... 191
3.5.3. Estructura común a todos los eventos ............................................................................................... 192
3.5.4. Detalles de cada evento ..................................................................................................................... 195
3.5.4.1. Uso autorizado por PA ...................................................................................................................195
3.5.4.2. Uso autorizado por la DIAN ...........................................................................................................197
3.5.4.3. Documento Electrónico Validado por PA, y que Debería Haber Sido Rechazado ..........................199
3.5.4.4. Uso NO Autorizado por la DIAN .....................................................................................................201
3.5.4.5. Documento Referenciado no Existe en la Base de Datos de la DIAN .............................................203
3.5.4.6. Acuse de recibo .............................................................................................................................205
3.5.4.7. Rechazo de Documento .................................................................................................................206
3.5.4.8. Recepción de los bienes ................................................................................................................208
3.5.4.9. Aceptación de documento ............................................................................................................209
3.5.4.10. Factura ofrecida para negociación como título valor ..................................................................210
3.5.4.11. Factura negociada como título valor ...........................................................................................211
Página 3 de 812
3.6. Estándar del nombre de los documentos electrónicos XML .......................................................................213
3.7. Guía del nombre del archivo que contiene uno o más documentos electrónicos y que será entregado a la
DIAN mediante un web service de recepción. ....................................................................................................214
4. Campos definidos en las extensiones DIAN ........................................................................................................215
4.1. Firma Electrónica del documento: ds:Signature ..........................................................................................215
5. Inconvenientes tecnológicos generados por parte de la Unidad Administrativa Especial Dirección de Impuestos
y Aduanas Nacionales – DIAN para la validación previa de la factura electrónica. .................................................225
6. Tablas de Contenidos de Elementos y de Atributos ...........................................................................................226
6.1. Códigos Relacionados con Documentos ......................................................................................................226
6.1.1. Ambiente de Destino del Documento: cbc:ProfileExecutionID y cbc:UUID.@schemeID ................... 226
6.1.2. Algoritmo: cbc:UUID.@schemeName ................................................................................................. 226
6.1.2.1. Algoritmo de CUFE: cbc:UUID.@schemeName .............................................................................226
6.1.2.2. Algoritmo de CUDE: cbc:UUID.@schemeName.............................................................................226
6.1.3. Tipo de Documento: cbc:InvoiceTypeCode y cbc:CreditnoteTypeCode ............................................... 226
6.1.4. Referencia a documentos no tributarios: cbc:DocumentTypeCode .................................................... 226
6.1.5. Tipos de operación ............................................................................................................................. 227
6.1.6. Tipos de eventos................................................................................................................................. 228
6.2. Códigos para identificación fiscal ................................................................................................................228
6.2.1. Documento de identificación (Tipo de Identificador Fiscal): cbc:CompanyID.@schemeName;
sts:ProviderID.@schemeName.................................................................................................... 228
6.2.2. Tributos: cac:TaxScheme/ID, cac:TaxScheme/Name .......................................................................... 229
6.2.3. Tipo de organización jurídica (Personas): cbc:AdditionalAccountID ................................................... 229
6.2.4. Nombre de la tabla de obligaciones o responsabilidades Fiscal: cbc:TaxLevelCode.@listName ........ 229
6.2.5. Concepto de Corrección para Notas crédito: cac:DiscrepancyResponse/cbc:ResponseCode ............. 229
6.2.6. Concepto de Correción para Notas débito: cac:DiscrepancyResponse/cbc:ResponseCode ................ 229
6.2.7. Responsabilidades fiscales: cbc:TaxLevelCode .................................................................................... 230
6.3. Códigos Diversos..........................................................................................................................................232
6.3.1. Eventos de un Documento Electrónico: cbc:DocumentRespose/cbc:Description; cbc:ResponseCode232
6.3.2. Lenguaje (ISO 639): @languageID ...................................................................................................... 232
6.3.3. Moneda (ISO 4217): @currencyID ...................................................................................................... 235
6.3.4. Pagos .................................................................................................................................................. 239
6.3.4.1. Formas de Pago: cbc:PaymentMeans/ID .......................................................................................239
6.3.4.2. Medios de Pago: cbc:PaymentMeansCode ....................................................................................239
6.3.5. Productos: @schemeID, @schemeName, @schemeAgencyID ........................................................... 240
6.3.6. Unidades de Cantidad: @unitCode ..................................................................................................... 241
6.3.7. Condiciones de entrega (INCOTERMS): …/cbc:LossRiskResponsibilityCode ....................................... 254
Página 4 de 812
6.3.8. Códigos de descuento ........................................................................................................................ 254
6.3.9. Tablas de tarifas por Impuesto ........................................................................................................... 254
6.3.10. Lista de códigos para precios de referencia ..................................................................................... 257
6.4. Códigos Geográficos ....................................................................................................................................257
6.4.1. Países (ISO 3166-1): cbc:IdentificationCode........................................................................................ 257
6.4.2. Departamentos (ISO 3166-2:CO): cbc:CountrySubentity, cbc:CountrySubentityCode ....................... 266
6.4.3. Municipios: cbc:CityName ................................................................................................................. 266
6.4.4. Código Postal cbc:PostalZone ............................................................................................................. 298
7. Reglas y Mensajes de Validación ........................................................................................................................314
7.1. Documentos Electrónicos ............................................................................................................................315
7.1.1. Factura Electrónica: Invoice ................................................................................................................ 315
7.1.1.1. Línea de Factura: InvoiceLine .........................................................................................................371
7.1.2. Nota Crédito: CreditNote .................................................................................................................... 386
7.1.2.1. Línea de Nota Credito: CreditNoteLine ..........................................................................................433
7.1.3. Nota Débito: DebitNote ...................................................................................................................... 447
7.1.3.1. Línea de Nota Debito: DebitNoteLine ............................................................................................491
7.1.4. Contenedor de Documentos: AttachedDocument ............................................................................. 504
7.1.5. Registro de Evento: ApplicationResponse........................................................................................... 504
7.1.5.1. Estructura Común a Todos los Eventos .........................................................................................504
7.1.5.2. Detalles de Cada Evento ................................................................................................................508
7.2. Firma Electrónica del Documento: ds:Signature .........................................................................................509
7.3. Reglas Relativas al Establecimiento de la Conexión .....................................................................................519
7.3.1. Mensaje del Web Service ................................................................................................................... 519
7.3.2. Schema XML ....................................................................................................................................... 519
7.3.3. Certificado Digital de Transmisión (conexión) .................................................................................... 519
7.3.4. Certificado Digital de Firma (Firma XML) ............................................................................................ 519
7.3.5. Firma................................................................................................................................................... 520
8. Anexo – Códigos de Productos ...........................................................................................................................521
8.1. Colombia Compra Eficiente .........................................................................................................................521
8.2. Números Globales de Identificación de Productos – GTIN ..........................................................................713
Definiciones ............................................................................................................................................................719
Abreviaturas Utilizadas ...........................................................................................................................................722
9. Política de firma ..................................................................................................................................................723
9.1. Observaciones .............................................................................................................................................723
Página 5 de 812
9.2. Consideraciones Generales .........................................................................................................................723
9.3. Especificaciones técnicas sobre la Firma Electrónica Avanzada: .................................................................724
9.4. Alcance de la Política de Firma ....................................................................................................................724
9.5. Política de Firma ..........................................................................................................................................724
9.5.1. Actores de la Firma ............................................................................................................................. 724
9.5.2. Formato de Firma ............................................................................................................................... 725
9.6. Algoritmo de Firma ......................................................................................................................................725
9.7. Algoritmo de Organización de Datos según el Canon ..................................................................................725
9.8. Ubicación de la Firma ..................................................................................................................................726
9.9. Condiciones de la Firma...............................................................................................................................726
9.10. Identificador de la Política .........................................................................................................................728
9.11. Hora de Firma ............................................................................................................................................728
9.12. Firmante ....................................................................................................................................................728
9.13. Mecanismo de firma electrónica ...............................................................................................................729
9.14. Certificado digital desde la vigencia de la circular 03-2016 de la ONAC ....................................................729
10. Mecanismos Sistema Técnico de Control .........................................................................................................735
10.1. Especificación Técnica de Generación Del CUFE y el CUDE .......................................................................735
10.1.1. Consideraciones Generales del CUFE ............................................................................................... 735
10.1.1.1. Generación de CUFE ....................................................................................................................735
10.1.1.2. Ejemplos ......................................................................................................................................736
10.1.1.3. Ejemplo de CUFE para Factura de venta......................................................................................736
10.1.1.4. XPath ...........................................................................................................................................737
10.1.1.5. Ejemplo de CUFE para Factura de exportación ...........................................................................738
10.1.1.6. XPath ...........................................................................................................................................739
10.1.2. Consideraciones Generales del CUDE............................................................................................... 739
10.1.2.1. Generación de CUDE ...................................................................................................................740
10.1.2.2. Ejemplo de CUDE para Factura de contingencia .........................................................................740
10.1.2.3. XPath ...........................................................................................................................................742
10.1.2.4. Ejemplo de Identificador universal para Nota crédito .................................................................743
10.1.2.5. XPath ...........................................................................................................................................745
10.1.2.6. Ejemplo de Identificador universal para Nota débito ..................................................................745
10.1.2.7. xpath ............................................................................................................................................747
10.1.2.8. Generación del CUDE para el Application Response: elaborado y remitido por participante ||
adquirente con “software PIN” ..................................................................................................................747
10.1.2.9. Observación General ...................................................................................................................751
10.2. Localización De La Clave Técnica «Cltec» ..................................................................................................752
10.3. Código Bidimensional «QR» ......................................................................................................................753
10.4. Especificacón Técnica Del Código De Seguridad Del Software ..................................................................755
Página 6 de 812
10.5. Métodos de Calculo ...................................................................................................................................756
10.5.1. Método General ............................................................................................................................... 756
10.5.2. Método incluye las retenciones en la fuente y las autoretenciónes. ............................................... 756
11. Descripción Tecnológicas del Web Services de Validación Previa. ...................................................................757
11.1. Modelo conceptual de comunicación .......................................................................................................757
11.2. Servicios síncronos ....................................................................................................................................758
11.2.1. Secuencia del servicio síncrono : ...................................................................................................... 758
11.3. Servicio asíncrono......................................................................................................................................758
11.3.1. Secuencia del servicio asíncrono ...................................................................................................... 759
11.4. Aspectos tecnológicos de los web services de Validación Previa DIAN .....................................................759
11.5. Estándar de comunicación ........................................................................................................................759
11.6. Estándar de mensajes de los servicios de La DIAN ....................................................................................760
11.7. Descripción de los servicios web de La DIAN .............................................................................................760
11.8. WS recepción documento electrónico - SendBillAsync .............................................................................761
11.8.1. Descripción de procesamiento ......................................................................................................... 761
11.8.2. Mensaje de petición ......................................................................................................................... 762
11.8.3. Mensaje de respuesta ...................................................................................................................... 763
11.9. WS recepción documento electrónico - SendTestSetAsync ......................................................................764
11.9.1. Descripción de procesamiento ......................................................................................................... 764
11.9.2. Mensaje de petición ......................................................................................................................... 765
11.9.3. Mensaje de respuesta ...................................................................................................................... 766
11.10. WS recepción documento electrónico - SendBillSync .............................................................................767
11.10.1. Descripción de procesamiento ....................................................................................................... 767
11.10.2. Mensaje de petición ....................................................................................................................... 769
11.10.3. Mensaje de respuesta .................................................................................................................... 770
11.11. WS recepción documento electrónico - SendBillAttachmetAsync ..........................................................772
11.11.1. Descripción del procesamiento ...................................................................................................... 772
11.11.2. Protocolo de petición ..................................................................................................................... 773
11.11.3. Mensaje de respuesta .................................................................................................................... 774
11.12. WS Consulta del estado de DE - GetStatus ..............................................................................................776
11.12.1. WS Consulta del estado de DE - GetStatus ..................................................................................... 776
11.12.2. Protocolo de petición ..................................................................................................................... 776
11.12.3. Protocolo de respuesta .................................................................................................................. 776
11.13. WS Consulta del estado del ZIP - GetStatusZip ........................................................................................779
Página 7 de 812
11.13.1. WS Consulta del estado de ZIP - GetStatusZip................................................................................ 779
11.13.2. Protocolo de petición ..................................................................................................................... 779
11.13.3. Protocolo de respuesta .................................................................................................................. 780
11.14. WS recepción eventos ante La DIAN - SendEventUpdateStatus..............................................................782
11.14.1. Descripción de procesamiento ....................................................................................................... 782
11.14.2. Mensaje de petición ....................................................................................................................... 784
11.14.3. Mensaje de respuesta .................................................................................................................... 784
11.15. WS Consulta contribuyentes activos de IVA - GetTaxPayer .....................................................................786
11.15.1. Descripción del procesamiento ...................................................................................................... 786
11.15.2. Mensaje de petición ....................................................................................................................... 787
11.15.3. Mensaje de respuesta .................................................................................................................... 787
11.16. WS descarga de XML (GetXmlByDocumentKey) ......................................................................................788
11.16.1. Descripción de procesamiento ....................................................................................................... 788
11.16.2. Mensaje de petición ....................................................................................................................... 789
11.16.3. Mensaje de respuesta .................................................................................................................... 790
11.17. WS consulta de rangos de numeración - GetNumberingRange ..............................................................791
11.17.1. Descripción de procesamiento ....................................................................................................... 791
11.17.2. Mensaje de petición ....................................................................................................................... 792
11.17.3. Mensaje de respuesta .................................................................................................................... 793
12. Anexo: Herramienta para el consumo de Web Services...................................................................................795
12.1. Introducción ..............................................................................................................................................795
12.2. Descargar SOAP UI.....................................................................................................................................795
12.3. Ejecutar SOAP UI .......................................................................................................................................795
12.4. Crear un nuevo proyecto tipo SOAP ..........................................................................................................795
12.5. Configuración inicial ..................................................................................................................................796
12.6. Configurar Keystore ...................................................................................................................................796
12.7. Configurar WS-Security Signature .............................................................................................................797
12.8. Configurar TimeStamp ...............................................................................................................................798
12.9. Configurar GetStatus Request, Authentication y WS-A addressing ...........................................................799
12.10. Configurar y ejecutar GetStatus Request ................................................................................................801
12.11. Configurar y ejecutar SendBillAsync Request ..........................................................................................802
12.12. SendBillAsync Response ..........................................................................................................................803
12.13. Recomendaciones ...................................................................................................................................803
13. Control de cambios...........................................................................................................................................804
13.1.1. Modificaciones Anexos Tecnicos ...................................................................................................... 804
13.1.1.1. Tablas...........................................................................................................................................804
Página 8 de 812
13.1.1.2. Modificaciones Caja de herramienta ...........................................................................................805
13.1.2. Modificaciones Anexo Técnico de factura electrónica ..................................................................... 805
13.1.2.1. Modificaciones sobre el Anexo Tecnico.......................................................................................805
13.1.2.2. Corrección sobre el numeral 9.9 .................................................................................................807
13.1.2.3. Cambio sobre el numeral 10........................................................................................................808
13.1.2.4. Inclusión sobre el numeral 10.3...................................................................................................808
13.1.2.5. Corrección sobre el numeral 10.4 ...............................................................................................808
13.1.3. Modificaciones Anexo Técnico de factura electrónica ..................................................................... 808
13.1.3.1. Eventos ........................................................................................................................................809
13.1.3.2. Incorporación del numeral 5. ......................................................................................................809
13.1.3.3. Algoritmo de CUFE: cbc:UUID.@schemeName ...........................................................................809
13.1.3.4. Caja de herramientas...................................................................................................................809
13.1.4. Modificaciones Anexo Técnico de factura electrónica (2019-05-19) ............................................... 810
13.1.4.1. Anexo técnico. .............................................................................................................................810
13.1.5. Modificación Anexo Tecnico 2019-06-19. ........................................................................................ 812
13.1.5.1. Anexo Técnico. ............................................................................................................................812
13.1.5.2. Caja de herramientas...................................................................................................................812
Índice de Tablas
Tabla 1 – Convenciones Utilizadas en la Tablas de Definición de los Formatos XML ...............................................14
Tabla 2 – Tipos de Campo en los Archivos XML ........................................................................................................14
Tabla 3 – Tipos de Datos de los Elementos en los Archivos XML ..............................................................................15
Tabla 4 – Tamaños de Elementos .............................................................................................................................16
Tabla 5 – Ejemplos de Información de Valores Utilizando los Formatos Numéricos ................................................16
Tabla 6 – Nombres de las Columnas de las Tablas de Reglas de Validación .............................................................17
Tabla 7 – Ubicaciones Estándar para Informaciones Comunes ................................................................................17
Tabla 8 – Relacionamientos Mutuos Entre los Eventos ..........................................................................................191
Tabla 9 – Ejemplos de Mensajes de Validación ......................................................................................................314
Índice de Figuras
Figura 1 – Niveles jerárquivos del sistema de codificación Colombia Compra Eficiente ........................................521
Figura 2 – Estructura de los códigos GTIN 8, 12 y 13..............................................................................................714
Figura 3 – Estructura del código GTIN 14 ...............................................................................................................715
Figura 4 – Árbol de decisión para elección de código GTIN ....................................................................................716
Página 9 de 812
Figura 5 – Estructura de almacenamiento de códigos GTIN ...................................................................................718
Figura 6. Ejemplo de código bidimensional QR ......................................................................................................754
Página 10 de 812
1. Introducción
El presente documento describe el formato de los documentos electrónicos para utilización en el marco de
las validaciones previstas en la Ley 1819 de 29 de diciembre de 2016 y la ley 1943 de 28 de diciembre de 2018.
El formato es un subconjunto del Universal Business Language – UBL, del cual se utilizarán cinco tipos de
documento1: Invoice (factura), CreditNote (Nota Crédito), DebitNote (Nota Débito), ApplicationResponse
(Registro de Evento2) y AttachedDocument (Contenedor de Documentos).
El objetivo de la presente descripción del UBL es buscar, una estandarización de las facturas electrónicas en el
país, de manera que se impulse el comercio electrónico, permitiendo que la información pueda ser utilizada
de la manera más eficaz, eficiente y efectiva posible.
Se imponen por lo tanto dos (2) requisitos: confiabilidad y calidad en las informaciones tal como se describe a
continuación.
1
Otros documentos descritos en el UBL podrán ser utilizados por las empresas, pero serán rechazados en las
validaciones. Por otro lado, campos y grupos de los cinco documentos citados que no se encuentren descritos en
el presente documento serán aceptados como integrantes de los mismos, siguiendo las siguientes condiciones:
Deben obedecer al schema UBL 2.1, de acuerdo con los XSD correspondientes; y
No serán objeto de ninguna crítica o validación de contenido.
2
Por evento, en el citado marco legal, si entiende todo y cualquier hecho relacionado con un Documento
Electrónico, o con la operación descrita en una factura; ver más detalles en las definiciones, al final del presente
documento.
Página 11 de 812
Notificación, si la aplicación de la regla apunta a una discrepancia menos importante, pero que
asimismo merece que se advierta al emisor de un posible problema con las informaciones del
archivo;
Aprobación, si la aplicación de la regla no apunta a ningún tipo de problema.
Las reglas de validación serán aplicadas en los siguientes momentos:
Por la DIAN al recibir en línea, del facturador electrónico directamente, a través de un
Proveedor Tecnologico (PT), o a través de la solución gratuita de facturación electrónica, un
documento electrónico para validación.
Por la DIAN al recibir en contingencia, del facturador electrónico directamente, a través de un
Proveedor Tecnologico (PT), o a través de la solución gratuita de facturación electrónica, un
documento electrónico para validación.
1.2.1. Redondeos
La suma de elementos que son el resultado de otras operaciones aritméticas, como aplicación de
porcentajes, puede llevar a diferencias entre los totales calculados y los correctos. Para evitar la
propagación de errores, para redondeos se recomienda que sea utilizado el siguiente procedimiento:
Dígito siguiente al dígito menos significativo es Redondeo
Entre 0 y 4 Mantener el dígito menos significativo
Entre 6 y 9 Incrementar el dígito menos significativo
5, y el segundo dígito siguiente al dígito menos significativo es cero o par Mantener el dígito menos significativo
5, y el segundo dígito siguiente al dígito menos significativo es impar Incrementar el dígito menos significativo
Esta definición se hace para que se reduzca el riesgo de problemas de suma de los valores redondeados,
para valores originales con décimas conteniendo el número “5”.
En caso que con la adopción de este procedimiento haya diferencia entre los totales calculados y la suma
de los parciales para el valor total de un documento, se deberá utilizar el elemento
/Invoice/LegalMonetaryTotal/cbc:PayableRoundingAmount para informar la diferencia.
Ejemplos para redondear cuando el digito menos significativo es la segunda casilla decimal:
Valor a Redondear Valor Redondeado
1.723 1.72
1.726 1.73
1.7252 1.72
1.7253 1.72
1.7258 1.73
Página 12 de 812
Todos los elementos que almacenan o registran valores monetarios deben estar acompañados del formato
dos decimanles. En ocacion que al convertir una moneda en otra denominación resulten 3 o más cifras
decimanes se aplicaran las reglas del numeral anterior para convertilos al formato de dos decimales
Página 13 de 812
2. Convenciones utilizadas en las tablas
Este capítulo presenta la definición de las estructuras de las tablas de definición del formato XML tanto
de los Documentos Electrónicos, como de las reglas de validación.
Nota: La definición de los prefijos ultilizados en los Documentos Electronicos deben ser mencionados a
nivel de la cabecera del documentos Invoice, CreditNote, DebitNote, Application Response o
AttachedDocument
Página 14 de 812
Tabla 3 – Tipos de Datos de los Elementos en los Archivos XML
Tipo Descripción
A Alfanumérico: son aceptados los caracteres UNICODE permitidos en el XML; corresponde al tipo xsd:normalizedString
B Booleano: acepta solamente los literales “true” y “false” (si debe usar minúsculas)
N Numérico: solamente son aceptados los números “0” a “9”, el punto de separación decimal, y las señales “+” y “-“
Fecha: elementos que deben ser informados en el formato AAAA-MM-DD, de acuerdo con la norma ISO 8601-2, en el cual:
AAAA: año
F
MM: mes
DD: día
Hora: elementos que deben ser informados en el formato de tiempo universal coordinado HH:MM:SSdhh:mm, de acuerdo con
la norma ISO 8601-2, en el cual:
HH: hora UTC (número de horas contadas desde la media noche, o sea, de 00 hasta 23)
MM: minutos
H
SS: segundos
hh:mm – diferencia en horas y minutos con relación a la hora GMT
d: señal (“+” o “-“) para la diferencia con relación a la hora GMT3
Ejemplo: dos y treinta de la tarde en Bogotá debe ser informado como 14:30:00-05:00
Intervalo de tiempo: elementos que deben ser informados en el formato <Fecha Inicial>/<Fecha Final>, siendo que obedece el
I formato “F” para ambas las fechas
Ejemplo: el período entre 01 de septiembre y 30 de septiembre de 2018 debe ser informado como 2018-09-01/2018-09-30
X Documento XML
3
Atención: no es la hora “Zulu”, o sea, referenciada al meridiano zero. Debe ser informada una hora en una zona
horaria específica, de libre elección del emisor: en el ejemplo fue escogido -5, que es la zona horaria oficial de
Colombia.
La zona horaria elegida por el emisor del documento electrónico es indiferente para la aplicación de las
reglas de validación: todas las operaciones de evaluación de horas se realizan tomando en cuenta la zona
horaria informada en el campo específico.
No existe necesidad de utilizar la misma zona horaria en todos los campos del tipo “hora” a lo largo de un
mismo archivo.
Página 15 de 812
Tabla 4 – Tamaños de Elementos
Formato Descripción
Tamaño exacto del elemento
x ej.: 5
o informar menos o más de cinco posiciones tendrá como resultado el rechazo del archivo
Tamaño mínimo de “x”, máximo de “y”
ej.: 0-10
x-y
o es posible expresar ningún valor, porque se permite el tamaño “0”
o informar más de diez posiciones tendrá como resultado el rechazo del archivo
Tamaño exacto del elemento de “x”, con exactamente “n” casillas decimales
ej.: 11 p 4
xpn o El número debe tener once posiciones, siendo exactamente seis posiciones antes del punto decimal, y
exactamente cuatro (4) posiciones después del punto decimal; cualquier otro número de posiciones tendrá
como resultado el rechazo del archivo
Tamaño exacto del elemento de “x”, con entre “n” y “m” casillas decimales
ej.: 11 p (0-6)
x p (n-m) o El número debe tener exatamente once posiciones, aceptándose cualquier combinación desde once
posiciones sin punto decimal hasta exactamente cuatro (4) posiciones antes del punto decimal, y
exactamente seis (6) posiciones después del punto decimal
Tamaño mínimo de “x”, máximo de “y”, con entre “n” y “m” casillas decimales
ej.: 1-11 p (0-6)
o Es obligatorio expresar algún valor, porque no se permite el tamaño “0”
(x-y) p (n-m)
o El número debe entre una (1) y once posiciones, aceptándose cualquier combinación desde once
posiciones sin punto decimal hasta exactamente cuatro (4) posiciones antes del punto decimal, y
exactamente seis (6) posiciones después del punto decimal, pero la parte fraccionaria es opcional
Valores separados El elemento deberá ser informado con tamaño de exactamente una de las opciones listadas
por comas ej.: 1, 3, 5, 8 significa que se debe informar el elemento con uno de estos cuatro tamaños fijos
Ejemplos de cómo se deben informar los valores en los elementos numéricos de acuerdo con el formato
especificado pueden ser encontrados en la Tabla 5.
Tabla 5 – Ejemplos de Información de Valores Utilizando los Formatos Numéricos
Formato Para Informar Llenar elemento con
1,105.13 1105.13
1,105.137 1105.137
0-11 p (0-6) 1,105 1105
0 0
para no informar cantidad dejar el elemento vacío
1,105 1105
1-11 0 0
para no informar cantidad no es posible
Página 16 de 812
Tabla 6 – Nombres de las Columnas de las Tablas de Reglas de Validación
Columna Descripción
Tipo Cataegoría de la regla de validación
# Identificador de la regla de validación
Campo Nombre del campo en las tablas de formato
Regla Descripción de la regla de validación
Cod Código de mensaje correspondiente a la regla de validación
Efecto de la regla de validación:
R: Rechazo, el procesamiento correspondiente ha encontrado problemas que impiden el procesamiento de la solicitud
Y
N: Notificación. el procesamiento correspondiente ha encontrado indicios de potenciales problemas, los cuales no
impiden el procesamiento de la solicitud
Mensaje Mensaje regresado como resultado de un rechazo el de una notificación
V Versión de las reglas de validación
Página 17 de 812
cbc:DueDate
Fecha de vencimiento de la factura, debe estar asociada con las fechas negociadas o acordadas segun los
registros de los campos cac:PaymentTerms/cbc:PaymentDueDate
cbc:TaxPointDate
Fecha del vencimiento para declarar y pagar el IVA de la factura, los periodos son: bimestre, cuatrimestre
o año de de la factura
Nota: tambien se consideraran las definiciones de la Resolución 30 del 2019 respecto a las contingencias
así:
Facturadores: 30 días Candelario.
DIAN: Dentro de las 48 horas.
Página 18 de 812
3. Formato para la generación de los Documentos Electrónicos
El sistema de facturación electrónica de Colombia utiliza cinco (5) documentos del estándar UBL: Invoice, CreditNote, DebitNote, ApplicationResponse y AttachedDocument.
../ext:UBLExtensions/ext:UBLExtension/ex
Datos Resolución de Numeración de
FAB04 sts InvoiceControl G DianExtensions 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
Facturas
:InvoiceControl
../ext:UBLExtensions/ext:UBLExtension/ex
AuthorizationPe Grupo de información relativas a la fecha
FAB06 sts G InvoiceControl 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
riod de autorización de la numeración
:InvoiceControl/sts:AuthorizationPeriod
../ext:UBLExtensions/ext:UBLExtension/ex
Debe ser anterior o igual a la fecha de la emisión de la
Fecha de inicio de la autorización de la AuthorizationPerio t:ExtensionContent/sts:DianExtensions/sts
FAB07 cbc StartDate E F 10 1..1 factura 1.0
numeración d :InvoiceControl/sts:AuthorizationPeriod/c
Rechazo: si StartDate > IssueDate
bc:StartDate
../ext:UBLExtensions/ext:UBLExtension/ex
Debe ser posterior o igual a la fecha de la emisión de la
Fecha final de la autorización de la AuthorizationPerio t:ExtensionContent/sts:DianExtensions/sts
FAB08 cbc EndDate E F 10 1..1 factura 1.0
numeración d :InvoiceControl/sts:AuthorizationPeriod/c
Rechazo: si EndDate < IssueDate
bc:EndDate
../ext:UBLExtensions/ext:UBLExtension/ex
AuthorizedInvoi Grupo de información del rango de
FAB09 sts G InvoiceControl 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
ces numeración autorizado para este emisor
:InvoiceControl/sts:AuthorizedInvoices
Debe ser igual al código de la sucursal correspondiente a
este punto de facturación
Notificación: Si ../ext:UBLExtensions/ext:UBLExtension/ex
Prefijo de la autorización de numeración de AuthorizedInvoice /Invoice/ext:UBLExtensions/ext:UBLExtension/ext:Extensio t:ExtensionContent/sts:DianExtensions/sts
FAB10 sts Prefix E A 0..4 0..1 1.0
facturación dado por el SIE de Numeración s nContent/sts:DianExtensions/sts:InvoiceControl/sts:Author :InvoiceControl/sts:AuthorizedInvoices/sts
izedInvoices/sts:Prefix <> :Prefix
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyL
egalEntity/cac:CorporateRegistrationScheme/cbc:ID
Debe corresponder a un rango en vigor para el
../ext:UBLExtensions/ext:UBLExtension/ex
contribuyente emisor
Valor inicial del rango de numeración AuthorizedInvoice t:ExtensionContent/sts:DianExtensions/sts
FAB11 sts From E N 1..9 1..1 Rechazo Si From no corresponde al inicio de un rango 1.0
otorgado s :InvoiceControl/sts:AuthorizedInvoices/sts
autorizado en el Sistema de numeración para el emisor de
:From
la FE
Debe corresponder a un rango en vigor para el
../ext:UBLExtensions/ext:UBLExtension/ex
contribuyente emisor
Valor final del rango de numeración AuthorizedInvoice t:ExtensionContent/sts:DianExtensions/sts
FAB12 sts To E N 1..9 1..1 Rechazo Si elemento To no corresponde al final de un rango 1.0
otorgado s :InvoiceControl/sts:AuthorizedInvoices/sts
autorizado en el Sistema de numeración para el emisor de
:To
la FE
../ext:UBLExtensions/ext:UBLExtension/ex
t:ExtensionContent/sts:DianExtensions/sts
FAB15 listAgencyID A N IdentificationCode 1..1 Debe ser informado el literal “6” 1.0
:InvoiceSource/cbc:IdentificationCode/@li
stAgencyID
../ext:UBLExtensions/ext:UBLExtension/ex
Debe ser informado el literal “United Nations Economic t:ExtensionContent/sts:DianExtensions/sts
FAB16 listAgencyName A A IdentificationCode 1..1 1.0
Commission for Europe” :InvoiceSource/cbc:IdentificationCode/@li
stAgencyName
../ext:UBLExtensions/ext:UBLExtension/ex
Debe ser informado el literal
t:ExtensionContent/sts:DianExtensions/sts
FAB17 listSchemeURI A A IdentificationCode 1..1 “urn:oasis:names:specification:ubl:codelist:gc:CountryIdent 1.0
:InvoiceSource/cbc:IdentificationCode/@li
ificationCode-2.1”
stSchemeURI
../ext:UBLExtensions/ext:UBLExtension/ex
SoftwareProvide Gupo de información sobre el prestador de
FAB18 sts G DianExtensions 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
r servicios
:SoftwareProvider
Identificador del Proveedor Tecnológico
utilizado en la emisión de la factura. Un
../ext:UBLExtensions/ext:UBLExtension/ex
Obligado a facturar puede ser también NIT del Proveedor Tecnológico debe estar registrado en la
FAB19 sts ProviderID E N SoftwareProvider 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
Proveedor Tecnológico para sí mismo u DIAN sin DV.
:SoftwareProvider/sts:ProviderID
otros, en cuyo caso será Proveedor
Tecnológico
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc t:ExtensionContent/sts:DianExtensions/sts
FAB20 A N ProviderID 1..1 Debe ser informado el literal “195” 1.0
yID :SoftwareProvider/sts:ProviderI/@scheme
AgencyID
../ext:UBLExtensions/ext:UBLExtension/ex
AuthorizationPr Grupo de Informacion del Proveedor
FAB30 sts E N 9 DianExtensions 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
ovider Autorizado (PA) por la DIAN
:AuthorizationProvider
../ext:UBLExtensions/ext:UBLExtension/ex
Debe corresponder al Nit de la DIAN
AuthorizationPr AuthorizationProvi t:ExtensionContent/sts:DianExtensions/sts
FAB31 sts E N 1..1 Rechazo: Si AuthorizationProviderID no corresponde al NIT 1.0
oviderID der :AuthorizationProvider/sts:AuthorizationP
de la DIAN (800197268)
roviderID
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc AuthorizationProvi t:ExtensionContent/sts:DianExtensions/sts
FAB32 A N 1..1 Debe ser informado el literal “195” 1.0
yID derID :AuthorizationProvider/sts:AuthorizationP
roviderID/@schemeAgencyID
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc AuthorizationProvi Debe ser informado el literal “CO, DIAN (Dirección de t:ExtensionContent/sts:DianExtensions/sts
FAB33 A A 1..1 1.0
yName derID Impuestos y Aduanas Nacionales)” :AuthorizationProvider/sts:AuthorizationP
roviderID/@schemeAgencyName
../ext:UBLExtensions/ext:UBLExtension/ex
Si Proveedor Autorizado está identificado por NIT
AuthorizationProvi t:ExtensionContent/sts:DianExtensions/sts
FAB34 @schemeID A N 1..1 (@schemeName=31), el DV del NIT debe ser informado 1.0
derID :AuthorizationProvider/sts:AuthorizationP
en @schemeID. DV de DIAN 4
roviderID/@schemeID
../ext:UBLExtensions/ext:UBLExtension/ex
FAB36 sts QRCode Colocar la definición de este código E N DianExtensions 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
:QRCode
/Invoice/cac:AccountingSupplierParty/cac:
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
FAJ23 A A CompanyID 0..1 1.0 Party/cac:PartyTaxScheme/cbc:CompanyI
yName Impuestos y Aduanas Nacionales)”
D/@schemeAgencyName
/Invoice/cac:AccountingSupplierParty/cac:
Emisor debe tener (@schemeName=31), el DV del NIT
FAJ24 @schemeID DV del NIT del emisor A N 1 CompanyID 1..1 1.0 Party/cac:PartyTaxScheme/cbc:CompanyI
debe ser informado en @schemeID
D/@schemeID
/Invoice/cac:AccountingSupplierParty/cac:
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
FAJ46 A A CompanyID 1..1 1.0 Party/cac:PartyLegalEntity/cbc:CompanyI
yName Impuestos y Aduanas Nacionales)”
D/@schemeAgencyName
/Invoice/cac:AccountingSupplierParty/cac:
El atributo (@schemeName=31), el DV del NIT debe ser
FAJ47 @schemeID DV del NIT del emisor A N CompanyID 1..1 1.0 Party/cac:PartyLegalEntity/cbc:CompanyI
informado en @schemeID
D/@schemeID
El emisor debe informar 31
/Invoice/cac:AccountingSupplierParty/cac:
Ver lista de valores posibles en la columna “Código” en el
FAJ48 @schemeName A N CompanyID 1..1 1.0 Party/cac:PartyLegalEntity/cbc:CompanyI
numeral 6.2.1; solamente si admite NIT de Colombia
D/@schemeName
Rechazo si @schemeName es diferente de “31”
/Invoice/cac:AccountingSupplierParty/cac:
CorporateRegist Grupo de información de registro del
FAJ49 cac E A PartyLegalEntity 1..1 1.0 Party/cac:PartyLegalEntity/cac:CorporateR
rationScheme emisor
egistrationScheme
/Invoice/cac:AccountingSupplierParty/cac:
Prefijo de la facturación usada para el CorporateRegistra Notificación: Debe ser igual al campo sts:prefix informado
FAJ50 cbc ID E N 6 1..1 1.0 Party/cac:PartyLegalEntity/cac:CorporateR
punto de venta tionScheme en el encabezado de la factura.
egistrationScheme/cbc:ID
Número de matrícula mercantil /Invoice/cac:AccountingSupplierParty/cac:
CorporateRegistra
FAJ51 cbc Name (identificador de sucursal: punto de E N 6 0..1 1.0 Party/cac:PartyLegalEntity/cac:CorporateR
tionScheme
facturación) egistrationScheme/cbc:Name
Si se va a opera bajo modalidad de Consorcio o Unión
Grupo de elementos que pertimen temporal, entonces este grupo de información debe ser /Invoice/cac:AccountingSupplierParty/cac:
ShareholderPart
FAJ52 cac registrar la información de los participantes G PartyLegalEntity 0..N completada. 1.0 Party/cac:PartyLegalEntity/cac:Shareholde
y
de un Consorcio o Unión temporal Se debe completar un grupo de elementos por cada rParty
participante del consorcio.
/Invoice/cac:AccountingSupplierParty/cac:
PartecipationPer Porcentaje de los participantes del Se debe informar el procentaje de los participantes del
FAJ53 cbc E ShareholderParty 1..1 1.0 Party/cac:PartyLegalEntity/cac:Shareholde
cent consorcio consorcio
rParty/cbc:PartecipationPercent
/Invoice/cac:AccountingSupplierParty/cac:
Grupo de elemento que pertime registrar
FAJ54 cac Party G ShareholderParty 1..1 1.0 Party/cac:PartyLegalEntity/cac:Shareholde
la información de un consorcio
rParty/cac:Party
/Invoice/cac:AccountingCustomerParty/ca
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
FAK23 A N CompanyID 1..1 1.0 c:Party/cac:PartyTaxScheme/cbc:Company
yName Impuestos y Aduanas Nacionales)”
ID/@schemeAgencyName
/Invoice/cac:AccountingCustomerParty/ca
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
FAK46 A A CompanyID 1..1 1.0 c:Party/cac:PartyLegalEntity/cbc:Company
yName Impuestos y Aduanas Nacionales)2
ID/@schemeAgencyName
/Invoice/cac:Delivery/cac:DeliveryParty/ca
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
FAM34 A A CompanyID 1..1 1.0 c:PartyTaxScheme/cbc:CompanyID/@sche
yName Impuestos y Aduanas Nacionales)”
meAgencyName
/Invoice/cac:Delivery/cac:DeliveryParty/ca
FAM55 cbc CompanyID Identificador del transportador E N 5..12 PartyLegalEntity 1..1 Si transportador es responsable, NIT del transportador 1.0
c:PartyLegalEntity/cbc:CompanyID
/Invoice/cac:Delivery/cac:DeliveryParty/ca
@schemeAgenc
FAM56 A N CompanyID 1..1 Debe ser informado el literal “195” 1.0 c:PartyLegalEntity/cbc:CompanyID/@sche
yID
meAgencyID
/Invoice/cac:Delivery/cac:DeliveryParty/ca
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
FAM57 A A CompanyID 1..1 1.0 c:PartyLegalEntity/cbc:CompanyID/@sche
yName Impuestos y Aduanas Nacionales)”
meAgencyName
Rechazo: si
../cac:TaxTotal/cbc:TaxAmount <> sumatoria de todas las
ocurrencias de
../cac:TaxTotal/TaxSubtotal/cbc:TaxAmount
o dicho de otro modo
every $i in //cac:InvoiceLine satisfies if
0..15 /Invoice/cac:InvoiceLine/cac:TaxTotal/cbc:
FAX02 cbc TaxAmount Valor del tributo E N TaxTotal 1..1 ($i/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cac:Tax 1.0
p (2..6) TaxAmount
Scheme/cbc:ID = '01') then
round($i/cac:TaxTotal[cac:TaxSubtotal/cac:TaxCategory/c
ac:TaxScheme/cbc:ID = '01']/cbc:TaxAmount) =
round(sum($i/cac:TaxTotal/cac:TaxSubtotal[cac:TaxCateg
ory/cac:TaxScheme/cbc:ID = '01']/cbc:TaxAmount)) else
true()
Nota: 01, representa a un código de impuesto, pero para el
calculo se debe considerar todos los tipos de impuesto
que aplique a esta línea.
Ver lista de valores posibles en el numeral 6.3.3 /Invoice/cac:InvoiceLine/cac:TaxTotal/cb
FAX03 @currencyID Código de moneda de la transacción A TaxAmount 1.0
Rechazo: Si el valor es diferente a DocumentCurrencyCode c:TaxAmount/@currencyID
Grupo de información que definen los /Invoice/cac:InvoiceLine/cac:TaxTotal/cac:
FAX04 cbc TaxSubtotal G TaxTotal 1..N Debe ser informado un grupo de estos para cada tarifa. 1.0
valores del tributo TaxSubtotal
El valor de la Base Imponible de la línea es igual al
producto de Cantidad x Precio Unidad menos Descuentos
más Recargos que apliquen para la línea.
Para el caso una operación gratuita (afecta a tributo) , se
Base Imponible sobre la que se calcula el 0..15 /Invoice/cac:InvoiceLine/cac:TaxTotal/cac:
FAX05 cbc TaxableAmount E N TaxSubtotal 1..1 debe informar en la base imponile Cantidad x Precio 1.0
valor del tributo p (2..6) TaxSubtotal/cbc:TaxableAmount
Referncial Unidad menos Descuentos más Recargos que
apliquen para la línea.
Nota: En las operaciones Excluidas, como no hay tributo,
NO se informa la base.
/Invoice/cac:InvoiceLine/cac:TaxTotal/ca
Ver lista de valores posibles en el numeral 6.3.3
FAX06 @currencyID Código de moneda de la transacción A TaxableAmount 1.0 c:TaxSubtotal/cbc:TaxableAmount/@cur
Rechazo:Si el valor es diferente a DocumentCurrencyCode
rencyID
(round(//cac:InvoiceLine/cac:TaxTotal[cac:TaxSubtotal/cac:
TaxCategory/cac:TaxScheme/cbc:ID =
'22']/cbc:TaxAmount) =
round(((//cac:InvoiceLine/cac:TaxTotal/cac:TaxSubtotal[ca
c:TaxCategory/cac:TaxScheme/cbc:ID =
'22']/cbc:PerUnitAmount *
(//cac:InvoiceLine[cac:TaxTotal/cac:TaxSubtotal/cac:TaxCa
tegory/cac:TaxScheme/cbc:ID =
'22']/cbc:InvoicedQuantity)))))
../ext:UBLExtensions/ext:UBLExtension/ex
InvoiceSource Grupo de información de país del InvoiceSource
CAB13 sts G 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
documento electrónico
:InvoiceSource
../ext:UBLExtensions/ext:UBLExtension/ex
IdentificationCo InvoiceSource
CAB14 cbc E A 2 1..1 Debe ser informado el literal “CO” 1.0 t:ExtensionContent/sts:DianExtensions/sts
de
:InvoiceSource/cbc:IdentificationCode
../ext:UBLExtensions/ext:UBLExtension/ex
@listAgencyNa Debe ser informado el literal “United Nations Economic t:ExtensionContent/sts:DianExtensions/sts
CAB16 A A IdentificationCode 1..1 1.0
me Commission for Europe” :InvoiceSource/cbc:IdentificationCode/@li
stAgencyName
../ext:UBLExtensions/ext:UBLExtension/ex
Debe ser informado el literal
t:ExtensionContent/sts:DianExtensions/sts
CAB17 @listSchemeURI A A IdentificationCode 1..1 “urn:oasis:names:specification:ubl:codelist:gc:CountryIde 1.0
:InvoiceSource/cbc:IdentificationCode/@li
ntificationCode-2.1”
stSchemeURI
../ext:UBLExtensions/ext:UBLExtension/ex
SoftwareProvide Gupo de información sobre el prestador de
CAB18 sts G DianExtensions 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
r servicios
:SoftwareProvider
Identificador del Proveedor Tecnológico
utilizado en la emisión de la Nota. Un
../ext:UBLExtensions/ext:UBLExtension/ex
Obligado a facturar puede ser también NIT del Proveedor Tecnológico debe estar registrado en
CAB19 sts ProviderID E N SoftwareProvider 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
Proveedor Tecnológico para sí mismo u la DIAN, si DV.
:SoftwareProvider/sts:ProviderID
otros, en cuyo caso será Proveedor
Tecnológico
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc t:ExtensionContent/sts:DianExtensions/sts
CAB20 A N ProviderID 1..1 Debe ser informado el literal “195” 1.0
yID :SoftwareProvider/sts:ProviderI/@scheme
AgencyID
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de t:ExtensionContent/sts:DianExtensions/sts
CAB21 A A ProviderID 1..1 1.0
yName Impuestos y Aduanas Nacionales)” :SoftwareProvider/sts:ProviderID/@schem
eAgencyName
../ext:UBLExtensions/ext:UBLExtension/ex
Si Proveedor Tecnológico está identificado por NIT
t:ExtensionContent/sts:DianExtensions/sts
CAB22 @schemeID DV del NIT del Proveedor Tecnológico A N ProviderID 0..1 (@schemeName=31), el DV del NIT debe ser informado 1.0
:SoftwareProvider/sts:ProviderID/@schem
en @schemeID
eID
Identificador Software: Identificador del Identificador del software asignado cuando el software si ../ext:UBLExtensions/ext:UBLExtension/ex
CAB24 sts softwareID software habilitado para la emisión de E A SoftwareProvider 1..1 activa en el Sistema de Facturación Electrónica debe 1.0 t:ExtensionContent/sts:DianExtensions/sts
Notas corresponder a un software autorizado para este OFE :SoftwareProvider/sts:softwareID
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc t:ExtensionContent/sts:DianExtensions/sts
CAB25 A N softwareID 1..1 Debe ser informado el literal “195” 1.0
yID :SoftwareProvider/sts:softwareID/@
schemeAgencyID
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de t:ExtensionContent/sts:DianExtensions/sts
CAB26 A A softwareID 1..1 1.0
yName Impuestos y Aduanas Nacionales)” :SoftwareProvider/sts:softwareID/@
schemeAgencyName
Huella del software que autorizó la DIAN al Definida en el numeral 10.4 ../ext:UBLExtensions/ext:UBLExtension/ex
SoftwareSecurit
CAB27 sts Obligado a Facturar Electrónicamente o al E A 48 DianExtensions 1..1 Rechazo: Si la huella no corresponde a un software 1.0 t:ExtensionContent/sts:DianExtensions/sts
yCode
Proveedor Tecnológico autorizado para este OFE :SoftwareSecurityCode
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc SoftwareSecurityC t:ExtensionContent/sts:DianExtensions/sts
CAB28 A N 1..1 Debe ser informado el literal “195” 1.0
yID ode :SoftwareSecurityCode/@schemeAgencyI
D
../ext:UBLExtensions/ext:UBLExtension/ex
@schemeAgenc SoftwareSecurityC Debe ser informado el literal “CO, DIAN (Dirección de t:ExtensionContent/sts:DianExtensions/sts
CAB29 A A 1..1 1.0
yName ode Impuestos y Aduanas Nacionales)” :SoftwareSecurityCode/@schemeAgencyN
ame
../ext:UBLExtensions/ext:UBLExtension/ex
AuthorizationPr Grupo de Informacion del Proveedor
CAB30 sts E N 9 DianExtensions 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
ovider Autorizado (PA) por la DIAN
:AuthorizationProvider
../ext:UBLExtensions/ext:UBLExtension/ex
Debe corresponder al Nit de la DIAN
AuthorizationPr AuthorizationProvi t:ExtensionContent/sts:DianExtensions/sts
CAB31 sts E N 1..1 Rechazo: Si AuthorizationProviderID no corresponde al 1.0
oviderID der :AuthorizationProvider/sts:AuthorizationP
NIT de la DIAN (800197268)
roviderID
../ext:UBLExtensions/ext:UBLExtension/ex
Si Proveedor Autorizado está identificado por NIT
@schemeID AuthorizationProvi t:ExtensionContent/sts:DianExtensions/sts
CAB34 A N 0..1 (@schemeName=31), el DV del NIT debe ser informado 1.0
derID :AuthorizationProvider/sts:AuthorizationP
en @schemeID. DV de DIAN 4
roviderID/@schemeID
../ext:UBLExtensions/ext:UBLExtension/ex
CAB36 sts QRCode Colocar la definición de este código E N DianExtensions 1..1 1.0 t:ExtensionContent/sts:DianExtensions/sts
:QRCode
/CreditNote/cac:AccountingSupplierParty/
Rechazo:
CAJ21 Cbc CompanyID NIT del emisor E N 5..12 PartyTaxScheme 1..1 1.0 cac:Party/cac:PartyTaxScheme/cbc:Compa
NIT no autorizado a facturar electrónicamente
nyID
/CreditNote/cac:AccountingSupplierParty/
@schemeAgenc
CAJ22 A N CompanyID 0..1 Debe ser informado el literal “195” 1.0 cac:Party/cac:PartyTaxScheme/cbc:Compa
yID
nyID/@schemeAgencyID
/CreditNote/cac:AccountingSupplierParty/
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
CAJ23 A A CompanyID 0..1 1.0 cac:Party/cac:PartyTaxScheme/cbc:Compa
yName Impuestos y Aduanas Nacionales)”
nyID/@schemeAgencyName
/CreditNote/cac:AccountingCustomerPart
RegistrationAddre Este código de municipio debe corresponder a valor
CAK29 cbc ID Código del municipio E A 1..15 1..1 1.0 y/cac:Party/cac:PartyTaxScheme/cac:Regis
ss valido de lista de municipios
trationAddress/cbc:ID
Si existe un grupo
..//cac:AccountingCustomerParty/cac:Party/cac:PartyTa
xScheme/cac:TaxScheme
/CreditNote/cac:AccountingCustomerPart
Grupo de detalles tributarios del en el cual el elemento
CAK39 cac TaxScheme G PartyTaxScheme 1..1 1.0 y/cac:Party/cac:PartyTaxScheme/cac:TaxS
adquirente ../cac:AccountingCustomerParty/cac:Party/cac:PartyTax
cheme
Scheme/cbc:ID es 01 y
../cac:AccountingCustomerParty/cac:Party/cac:PartyLeg
alEntity/@schemeName=31
entonces NIT
../cac:AccountingCustomerParty/cac:Party/cac:PartyLeg
alEntity /cbc:CompanyID debe estar activo
Ver lista de valores posibles en 6.2.2
Rechazo: /CreditNote/cac:AccountingCustomerPart
CAK40 cbc ID Identificador del tributo del adquirente E A 3..10 TaxScheme 1..1 Si el contenido de este elemento no corresponde a un 1.0 y/cac:Party/cac:PartyTaxScheme/cac:TaxS
contenido de la columna “Identificador” (aceptase cheme/cbc:ID
elemento sin contenido)
Ver lista de valores posibles en 6.2.2
/CreditNote/cac:AccountingCustomerPart
Rechazo:
CAK41 cbc Name Nombre del tributo E A 10..30 TaxScheme 1..1 1.0 y/cac:Party/cac:PartyTaxScheme/cac:TaxS
Si el contenido de este elemento no corresponde al
cheme/cbc:Name
contenido correspondiente de la columna “Nombre”
Grupo de información legales del AccountingSupplie /CreditNote/cac:AccountingCustomerPart
CAK42 PartyLegalEntity G 0..1 1.0
adquirente rParty y/cac:Party/cac:PartyLegalEntity
Nombre registrado en el RUT. Si el adquirente es persona
jurídica desea también utilizar el nombre comercial en
/CreditNote/cac:AccountingCustomerPart
RegistrationNam el archivo de la factura, debe utilizar el elemento
CAK43 cbc Nombre o Razón Social del adquirente E A 5..450 PartyLegalEntity 1..1 1.0 y/cac:Party/cac:PartyLegalEntity/cbc:Regis
e ../cac:AccountingSupplierParty/cac:Party/cac:PartyNam
trationName
e/cbc:Name
/CreditNote/cac:AccountingCustomerPart
CAK44 cbc CompanyID ID del Adquirente E N 5..12 PartyLegalEntity 1..1 ID del Adquirente 1.0 y/cac:Party/cac:PartyLegalEntity/cbc:Com
panyID
/CreditNote/cac:AccountingCustomerPart
schemeAgencyI
CAK45 A N CompanyID 1..1 Debe ser informado el literal “195” 1.0 y/cac:Party/cac:PartyLegalEntity/cbc:Com
D
panyID/@schemeAgencyID
/CreditNote/cac:Delivery/cac:DeliveryPart
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
CAM57 A A CompanyID 1..1 1.0 y/cac:PartyLegalEntity/cbc:CompanyID/@s
yName Impuestos y Aduanas Nacionales)”
chemeAgencyName
/CreditNote/cac:Delivery/cac:DeliveryPart
CorporateRegist Grupo de información de registro del
CAM60 cac E A PartyLegalEntity 0..1 1.0 y/cac:PartyLegalEntity/cac:CorporateRegis
rationScheme transportador
trationScheme
/CreditNote/cac:Delivery/cac:DeliveryPart
CorporateRegistra
CAM61 cbc Name Número de matrícula mercantil E N 6 0..1 1.0 y/cac:PartyLegalEntity/cac:CorporateRegis
tionScheme
trationScheme/cbc:Name
Grupo de detalles con información de /CreditNote/cac:Delivery/cac:DeliveryPart
CAM62 cac Contact G Party 0..1 1.0
contacto del tranportador y/cac:Contact
Rechazo:
AllowanceTotalA Descuento Total: Suma de todos los 4..15 LegalMonetaryTot /CreditNote/cac:LegalMonetaryTotal/cbc:
CAU08 cbc E N 0..1 Si 1.0
mount descuentos aplicados al total de la factura p (2..6) al AllowanceTotalAmount
round(/sig:CreditNote/cac:LegalMonetaryTotal/cbc:Allow
anceTotalAmount) es distinto de
round(sum(/sig:CreditNote/cac:AllowanceCharge[cbc:C
hargeIndicator = "false"]/cbc:Amount))
Ver lista de valores posibles en 6.3.3
AllowanceTotalAm /CreditNote/cac:LegalMonetaryTotal/cb
CAU09 @currencyID Código de moneda de la transacción A 1..1 Rechazo: 1.0
ount c:AllowanceTotalAmount/@currencyID
Si valor diferente a DocumentCurrencyCode
ChargeTotalAmo Cargo Total: Suma de todos los cargos 4..15 LegalMonetaryTot Rechazo: Si /CreditNote/cac:LegalMonetaryTotal/cbc:
CAU10 cbc E N 0..1 1.0
unt aplicados al total de la factura p (2..6) al round(/sig:CreditNote/cac:LegalMonetaryTotal/cbc:Charg ChargeTotalAmount
eTotalAmount) es distinto de
round(sum(/sig:CreditNote/cac:AllowanceCharge[cbc:C
hargeIndicator = "true"]/cbc:Amount))
ChargeTotalAmou Ver lista de valores posibles en el numeral 6.3.3 /CreditNote/cac:LegalMonetaryTotal/cb
CAU11 @currencyID Código de moneda de la transacción A 1..1 1.0
nt • Rechazo Si valor diferente a DocumentCurrencyCode c:ChargeTotalAmount/@currencyID
El Valor del Anticipo Total es igual a la Suma de todos los
anticipos o prepagos globales aplicados al total de la
factura.
Rechazo:
Anticipo Total: Suma de todos los pagos 4..15 LegalMonetaryTot Si /CreditNote/cac:LegalMonetaryTotal/cbc:
CAU12 cbc PrePaidAmount E N 0..1 1.0
anticipados p (2..6) al (/sig:CreditNote/cac:LegalMonetaryTotal/cbc:PrepaidAm PrepaidAmount
ount) then
round(/sig:CreditNote/cac:LegalMonetaryTotal/cbc:Prep
aidAmount) =
round(sum(/sig:CreditNote/cac:PrepaidPayment/cbc:Pai
dAmount)) else true()
Ver lista de valores posibles en 6.3.3
/CreditNote/cac:LegalMonetaryTotal/cb
CAU13 @currencyID Código de moneda de la transacción A PrePaidAmount 1..1 Rechazo: 1.0
c:PrepaidAmount/@currencyID
Si valor diferente a DocumentCurrencyCode
Rechazo:
Si
o /CreditNote/cac:CreditNoteLine/cbc:LineExtensionAm
ount es distinto de (/CreditNote/Price/cbc:PriceAmount
* /CreditNote/Price/cbc:Price/ BaseQuantity) –
(/CreditNote/cac:CreditNoteLine/cac:AllowanceCharge/
cbc:Amount, correspondientes a aquellos grupos en
donde
/CreditNote/cac:CreditNoteLine/cac:AllowanceCharge/c
bc:ChargeIndicator es “false”
o )+
(/CreditNote/cac:CreditNoteLine/cac:AllowanceCharge/c
bc:Amount, correspondientes a aquellos grupos en
donde AllowanceCharge/cbc:ChargeIndicator es “true”
Valor total de la línea. )
LineExtensionA Cantidad x Precio Unidad menos 0..15 O dicho de otra forma /CreditNote/cac:CreditNoteLine/cbc:LineE
CAV06 cbc E N CreditNoteLine 1..1 1.0
mount descuentos más recargos p (2..6) xtensionAmount
que apliquen para la línea. every $i in /sig:CreditNote/cac:CreditNoteLine satisfies if
(exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=fal
se()]) and
exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=tru
e()]))then(round($i/cbc:LineExtensionAmount) =
round(($i/cac:Price/cbc:PriceAmount *
$i/cac:Price/cbc:BaseQuantity)+
$i/cac:AllowanceCharge[cbc:ChargeIndicator=true()]/cb
c:Amount -
$i/cac:AllowanceCharge[cbc:ChargeIndicator=false()]/cb
c:Amount)) else
(if(exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=f
alse()]))then round($i/cbc:LineExtensionAmount) =
round(($i/cac:Price/cbc:PriceAmount *
$i/cac:Price/cbc:BaseQuantity) -
$i/cac:AllowanceCharge[cbc:ChargeIndicator=false()]/cb
c:Amount) else
if(exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=tr
ue()])) then round($i/cbc:LineExtensionAmount) =
Rechazo:
si
../cac:TaxTotal/cbc:TaxAmount <> sumatoria de todas las
ocurrencias de
../cac:TaxTotal/TaxSubtotal/cbc:TaxAmount
(round(//cac:CreditNoteLine/cac:TaxTotal[cac:TaxSubtota
l/cac:TaxCategory/cac:TaxScheme/cbc:ID =
'22']/cbc:TaxAmount) =
round(((//cac:CreditNoteLine/cac:TaxTotal/cac:TaxSubt
otal[cac:TaxCategory/cac:TaxScheme/cbc:ID =
'22']/cbc:PerUnitAmount *
(//cac:CreditNoteLine[cac:TaxTotal/cac:TaxSubtotal/cac:
TaxCategory/cac:TaxScheme/cbc:ID =
'22']/cbc:CreditedQuantity)))))
Rechazo:
Si el elemento NO es infomado o no existe.
BaseUnitMeasur 0..2 /CreditNote/cac:CreditNoteLine/cac:TaxTo
CAX09 cbc Unidad de medida base para el tributo E N TaxSubtotal 0..1 1.0
e p (0..2) tal/cac:TaxSubtotal/cbc:BaseUnitMeasure
let $i :=
//cac:CreditNoteLine/cac:TaxTotal/cac:TaxSubtotal/cac:
TaxCategory/cac:TaxScheme/cbc:ID, $j :=
//cac:CreditNoteLine/cac:TaxTotal/cac:TaxSubtotal
return every $k in $i satisfies if ($k = '21' or $k = '22' or
$k = '23' or $k ='24') then $j/cbc:BaseUnitMeasure != ''
and $j/cbc:BaseUnitMeasure/@unitCode != '' else true()
/CreditNote/cac:CreditNoteLine/cac:TaxTo
Corresponde a uno de los valores de la tabla de unidades
CAX10 cbc unitCode Identificación de la unidad de medida A A 2..5 BaseUnitMeasure 1..1 1.0 tal/cac:TaxSubtotal/cbc:BaseUnitMeasure
de medida 6.3.3
/@unitCode
Es el valor nominal del tibuto por unidad
Rechazo:
Si el elemento NO es infomado o no existe.
/root/ext:UBLExtensions/ext:UBLExtensio
Grupo de información de país del InvoiceSource
DAB13 sts InvoiceSource G 1..1 1.0 n/ext:ExtensionContent/sts:DianExtension
documento electrónico
s/sts:InvoiceSource
/root/ext:UBLExtensions/ext:UBLExtensio
IdentificationCo InvoiceSource n/ext:ExtensionContent/sts:DianExtension
DAB14 cbc E A 2 1..1 Debe ser informado el literal “CO” 1.0
de s/sts:InvoiceSource/cbc:IdentificationCode
/root/ext:UBLExtensions/ext:UBLExtensio
n/ext:ExtensionContent/sts:DianExtension
DAB15 listAgencyID A N IdentificationCode 1..1 Debe ser informado el literal “6” 1.0
s/sts:InvoiceSource/cbc:IdentificationCode
/@listAgencyID
/root/ext:UBLExtensions/ext:UBLExtensio
Debe ser informado el literal “United Nations Economic n/ext:ExtensionContent/sts:DianExtension
DAB16 listAgencyName A A IdentificationCode 1..1 1.0
Commission for Europe” s/sts:InvoiceSource/cbc:IdentificationCode
/@listAgencyName
/root/ext:UBLExtensions/ext:UBLExtensio
Debe ser informado el literal
n/ext:ExtensionContent/sts:DianExtension
DAB17 listSchemeURI A A IdentificationCode 1..1 “urn:oasis:names:specification:ubl:codelist:gc:CountryIdent 1.0
s/sts:InvoiceSource/cbc:IdentificationCode
ificationCode-2.1”
/@listSchemeURI
/root/ext:UBLExtensions/ext:UBLExtensio
SoftwareProvide Gupo de información sobre el prestador de
DAB18 sts G DianExtensions 1..1 1.0 n/ext:ExtensionContent/sts:DianExtension
r servicios
s/sts:SoftwareProvider
/root/ext:UBLExtensions/ext:UBLExtensio
n/ext:ExtensionContent/sts:DianExtension
@schemeAgenc
DAB20 A N ProviderID 1..1 Debe ser informado el literal “195” 1.0 s/sts:SoftwareProvider/sts:ProviderI/@sch
yID
emeAgencyID
/root/ext:UBLExtensions/ext:UBLExtensio
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de n/ext:ExtensionContent/sts:DianExtension
DAB21 A A ProviderID 1..1 1.0
yName Impuestos y Aduanas Nacionales)” s/sts:SoftwareProvider/sts:ProviderID/@sc
hemeAgencyName
/root/ext:UBLExtensions/ext:UBLExtensio
Si Proveedor Tecnológico está identificado por NIT
n/ext:ExtensionContent/sts:DianExtension
DAB22 @schemeID DV del NIT del Proveedor Tecnológico A N ProviderID 0..1 (@schemeName=31), el DV del NIT debe ser informado en 1.0
s/sts:SoftwareProvider/sts:ProviderID/@sc
@schemeID
hemeID
Identificador del tipo de documento de identidad
/root/ext:UBLExtensions/ext:UBLExtensio
(@schemeName=31) del Proveedor Tecnológico que indica
n/ext:ExtensionContent/sts:DianExtension
DAB23 @schemeName A N ProviderID 1..1 que el esta identificado por NIT y por tanto el DV del NIT 1.0
s/sts:SoftwareProvider/sts:ProviderID/@sc
debe ser informado en atributo @schemeID
hemeName
Identificador Software: Identificador del Identificador del software asignado cuando el software si /root/ext:UBLExtensions/ext:UBLExtensio
DAB24 sts softwareID software habilitado para la emisión de E A SoftwareProvider 1..1 activa en el Sistema de Facturación Electrónica debe 1.0 n/ext:ExtensionContent/sts:DianExtension
Notas corresponder a un software autorizado para este OFE s/sts:SoftwareProvider/sts:softwareID
/root/ext:UBLExtensions/ext:UBLExtensio
@schemeAgenc n/ext:ExtensionContent/sts:DianExtension
DAB25 A N softwareID 1..1 Debe ser informado el literal “195” 1.0
yID s/sts:SoftwareProvider/sts:softwareID/@s
chemeAgencyID
/root/ext:UBLExtensions/ext:UBLExtensio
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de n/ext:ExtensionContent/sts:DianExtension
DAB26 A A softwareID 1..1 1.0
yName Impuestos y Aduanas Nacionales)” s/sts:SoftwareProvider/sts:softwareID/@s
chemeAgencyName
/root/ext:UBLExtensions/ext:UBLExtensio
AuthorizationPr Grupo de Información del Proveedor
DAB30 sts E N 9 DianExtensions 1..1 1.0 n/ext:ExtensionContent/sts:DianExtension
ovider Autorizado (PA) por la DIAN
s/sts:AuthorizationProvider
/root/ext:UBLExtensions/ext:UBLExtensio
Debe corresponder al Nit de la DIAN
AuthorizationPr AuthorizationProvi n/ext:ExtensionContent/sts:DianExtension
DAB31 sts E N 1..1 Rechazo: Si AuthorizationProviderID no corresponde al NIT 1.0
oviderID der s/sts:AuthorizationProvider/sts:Authorizati
de la DIAN (800197268)
onProviderID
/root/ext:UBLExtensions/ext:UBLExtensio
@schemeAgenc AuthorizationProvi n/ext:ExtensionContent/sts:DianExtension
DAB32 A N 1..1 Debe ser informado el literal “195” 1.0
yID derID s/sts:AuthorizationProvider/sts:Authorizati
onProviderID/@schemeAgencyID
/root/ext:UBLExtensions/ext:UBLExtensio
@schemeAgenc AuthorizationProvi Debe ser informado el literal “CO, DIAN (Dirección de n/ext:ExtensionContent/sts:DianExtension
DAB33 A A 1..1 1.0
yName derID Impuestos y Aduanas Nacionales)” s/sts:AuthorizationProvider/sts:Authorizati
onProviderID/@schemeAgencyName
/root/ext:UBLExtensions/ext:UBLExtensio
DAB36 sts QRCode Colocar la definición de este código E N DianExtensions 1..1 1.0 n/ext:ExtensionContent/sts:DianExtension
s/sts:QRCode
Rechazo:
si la fecha de emisión es posterior a diez días calendario
/DebitNote/cbc:IssueDate > fecha calendario + 10 días
/DebitNote/cac:AccountingSupplierParty/c
Rechazo:
DAJ21 cbc CompanyID NIT del emisor E N 5..12 PartyTaxScheme 1..1 1.0 ac:Party/cac:PartyTaxScheme/cbc:Compa
NIT no autorizado a facturar electrónicamente
nyID
/DebitNote/cac:AccountingSupplierParty/c
@schemeAgenc
DAJ22 A N CompanyID 0..1 Debe ser informado el literal “195” 1.0 ac:Party/cac:PartyTaxScheme/cbc:Compa
yID
nyID/@schemeAgencyID
/DebitNote/cac:AccountingSupplierParty/c
@schemeAgenc Debe ser informado el literal “CO, DIAN (Dirección de
DAJ23 A A CompanyID 0..1 1.0 ac:Party/cac:PartyTaxScheme/cbc:Compa
yName Impuestos y Aduanas Nacionales)”
nyID/@schemeAgencyName
/DebitNote/cac:AccountingSupplierParty/c
Si Emisor está identificado por NIT (@schemeName=31), el
DAJ24 @schemeID DV del NIT del emisor A N CompanyID 1..1 1.0 ac:Party/cac:PartyTaxScheme/cbc:Compa
DV del NIT debe ser informado en @schemeID
nyID/@schemeID
Identificador del tipo de documento de identidad
(@schemeName=31) del Proveedor Tecnológico que indica
que el esta identificado por NIT y por tanto el DV del NIT
/DebitNote/cac:AccountingSupplierParty/c
debe ser informado en atributo @schemeID
DAJ25 @schemeName A N ProviderID 1..1 1.0 ac:Party/cac:PartyTaxScheme/cbc:Compa
nyID/@schemeName
Ver lista de valores posibles en la columna “Código” del
ítem 5.2.1; solamente si admite NIT de Colombia Rechazo si
@schemeName es diferente de “31”
/DebitNote/cac:AccountingSupplierParty/c
Rechazo:
DAJ44 cbc CompanyID NIT del emisor E N 5..12 PartyLegalEntity 1..1 1.0 ac:Party/cac:PartyLegalEntity/cbc:Compan
NIT no autorizado a facturar electrónicamente
yID
/DebitNote/cac:AccountingSupplierParty/c
@schemeAgenc
DAJ45 A N CompanyID 1..1 Debe ser informado el literal “195” 1.0 ac:Party/cac:PartyLegalEntity/cbc:Compan
yID
yID/@schemeAgencyID
/DebitNote/cac:AccountingCustomerParty
Este código de municipio debe corresponder a valor valido
DAK09 cbc ID Código del municipio E A 5 Address 1.0 /cac:Party/cac:PhysicalLocation/cac:Addre
de lista de municipios
ss/cbc:ID
Si este es un grupo con información con respeto a la
dirección del adquirente de un documento electrónico,
debe ser un municipio de Colombia /DebitNote/cac:AccountingCustomerParty
DAK10 cbc CityName Nombre de la ciudad E A 1..60 Address 0..1 Si IdentificationCode es “CO”, CountrySubentity debe 1.0 /cac:Party/cac:PhysicalLocation/cac:Addre
corresponder a uno de los valores del la Columna Nombre ss/cbc:CityName
Municipio de 6.4.3
Obligatorio para emisores y Adquirentes Responsables
Ver lista de valores posibles en el numeral 6.4.4
Notificación: Si el valor no corresponde a un valor /DebitNote/cac:AccountingCustomerParty
DAK56 cbc PostalZone Código Postal E A 1..10 Address 0..1 correspondiente a la tabla 6.4.4. /cac:Party/cac:PhysicalLocation/cac:Addre
Notificación: Si el valor del elemento CountrySubentityCode ss/cbc:PostalZone
es diferente a los 2 primeros dígitos del código postal.
Si este es un grupo con información con respeto a la
dirección del adquirente de un documento electrónico,
/DebitNote/cac:AccountingCustomerParty
CountrySubentit debe ser un Departamento de Colombia
DAK11 cbc Nombre del Departamento E A 1..60 Address 0..1 1.0 /cac:Party/cac:PhysicalLocation/cac:Addre
y Si IdentificationCode es “CO”, CountrySubentity debe
ss/cbc:CountrySubentity
corresponder a uno de los valores del la Columna Nombre
de 6.4.2
/DebitNote/cac:AccountingCustomerParty
DAK21 cbc CompanyID Id del adquirente E N 5..12 PartyTaxScheme 1..1 1.0 /cac:Party/cac:PartyTaxScheme/cbc:Comp
anyID
/DebitNote/cac:AccountingCustomerParty
schemeAgencyN Debe ser informado el literal “CO, DIAN (Dirección de
DAK23 A N CompanyID 1..1 1.0 /cac:Party/cac:PartyTaxScheme/cbc:Comp
ame Impuestos y Aduanas Nacionales)”
anyID/@schemeAgencyName
/DebitNote/cac:AccountingCustomerParty
Este elemento representa el tipo de obligación.
DAK26 cbc TaxLevelCode Obligaciones del contribuyente E A 2 PartyTaxScheme 1..1 1.0 /cac:Party/cac:PartyTaxScheme/cbc:TaxLe
Ver lista de valores posiblen en 6.2.7
velCode
/DebitNote/cac:AccountingCustomerParty
DAK27 cbc listName Régimen al que pertenece el Adquiriente A A 5 1..1 Ver lista de valores posibles en 6.2.4 1.0 /cac:Party/cac:PartyTaxScheme/cbc:TaxLe
velCode/@listName
/DebitNote/cac:AccountingCustomerParty
schemeAgencyN Debe ser informado el literal “CO, DIAN (Dirección de
DAK46 A A CompanyID 1..1 1.0 /cac:Party/cac:PartyLegalEntity/cbc:Comp
ame Impuestos y Aduanas Nacionales)2
anyID/@schemeAgencyName
/DebitNote/cac:TaxRepresentativeParty/c
schemeAgencyN Debe ser informado el literal “CO, DIAN (Dirección de
DAL05 A A ID 0..1 1.0 ac:PartyIdentification/cbc:ID/@schemeAg
ame Impuestos y Aduanas Nacionales)”
encyName
/DebitNote/cac:Delivery/cac:DeliveryParty
schemeAgencyN Debe ser informado el literal “CO, DIAN (Dirección de
DAM34 A A CompanyID 1..1 1.0 /cac:PartyTaxScheme/cbc:CompanyID/@s
ame Impuestos y Aduanas Nacionales)”
chemeAgencyName
/DebitNote/cac:Delivery/cac:DeliveryParty
DAM55 cbc CompanyID Identificador del transportador E N 5..12 PartyLegalEntity 1..1 Si transportador es responsable, NIT del transportador 1.0
/cac:PartyLegalEntity/cbc:CompanyID
/DebitNote/cac:Delivery/cac:DeliveryParty
CorporateRegistra
DAM61 cbc Name Número de matrícula mercantil E N 6 0..1 1.0 /cac:PartyLegalEntity/cac:CorporateRegist
tionScheme
rationScheme/cbc:Name
/DebitNote/cac:Delivery/cac:DeliveryParty
DAM63 cbc Name Nombre Contacto E A Contact 0..1 1.0
/cac:Contact/cbc:Name
/DebitNote/cac:Delivery/cac:DeliveryParty
DAM64 cbc Telephone Número de teléfono, celular u otro E A Contact 0..1 1.0
/cac:Contact/cbc:Telephone
/DebitNote/cac:Delivery/cac:DeliveryParty
DAM65 cbc Telefax Número de teléfono, celular u otro E A Contact 0..1 1.0
/cac:Contact/cbc:Telefax
/DebitNote/cac:Delivery/cac:DeliveryParty
DAM66 cbc ElectronicMail Correo electrónico de contacto E A Contact 0..1 Notificación: Si el correo electrónico no es informado 1.0
/cac:Contact/cbc:ElectronicMail
TaxExclusiveAm Total Valor Base Imponible : Base imponible 4..15 RequestedMoneta Rechazo: /DebitNote/cac:RequestedMonetaryTotal/
DAU04 cbc E N 1..1 1.0
ount para el cálculo de los tributos p (2..6) ryTotal Si cbc:TaxExclusiveAmount
round(//cbc:TaxExclusiveAmount) es distinto de
round(sum(//cac:DebitNoteLine/cac:TaxTotal/cac:TaxSubtot
al/cbc:TaxableAmount))
Ver lista de valores posibles en 6.3.3 /DebitNote/cac:RequestedMonetaryTot
TaxExclusiveAmou
DAU05 @currencyID Código de moneda de la transacción A 1..1 Rechazo: 1.0 al/cbc:TaxExclusiveAmount/@currencyI
nt
Si valor diferente a DocumentCurrencyCode D
El Valor Bruto más tributos tiene que ser igual a Valor Bruto
de la factura que contienen el valor comercial más la Suma
de los Tributos de todas las líneas de detalle.
Total de Valor Bruto más tributos
TaxInclusiveAmo 4..15 RequestedMoneta Rechazo: /DebitNote/cac:RequestedMonetaryTotal/
DAU06 cbc E N 1..1 1.0
unt p (2..6) ryTotal si cbc:TaxInclusiveAmount
round(//cac:RequestedMonetaryTotal/cbc:LineExtensionAm
ount +
sum(//cac:TaxTotal[not(ancestor::cac:DebitNoteLine)]/cbc:T
axAmount)) es distinto de round(//cbc:TaxInclusiveAmount)
TaxInclusiveAmou Ver lista de valores posibles en el numeral 6.3.3 /DebitNote/cac:RequestedMonetaryTot
DAU07 @currencyID Código de moneda de la transacción A 1..1 1.0
nt Rechazo: Si valor diferente a DocumentCurrencyCode al/cbc:TaxInclusiveAmount/@currencyID
El Valor del Descuento Total es igual a la Suma de todos los
descuentos globales aplicados al total de la factura.
Rechazo: Si
AllowanceTotalA Descuento Total: Suma de todos los 4..15 RequestedMoneta /DebitNote/cac:RequestedMonetaryTotal/
DAU08 cbc E N 0..1 round(/sig:DebitNote/cac:RequestedMonetaryTotal/cbc:All 1.0
mount descuentos aplicados al total de la factura p (2..6) ryTotal cbc:AllowanceTotalAmount
owanceTotalAmount) es distinto de
round(sum(/sig:DebitNote/cac:AllowanceCharge[cbc:Charg
eIndicator = "false"]/cbc:Amount))
/DebitNote/cac:RequestedMonetaryTot
AllowanceTotalAm Ver lista de valores posibles en el numeral 6.3.3
DAU09 @currencyID Código de moneda de la transacción A 1..1 1.0 al/cbc:AllowanceTotalAmount/@currenc
ount Rechazo: Si valor diferente a DocumentCurrencyCode
yID
Rechazo: Si
o /DebitNote/cac:DebitNoteLine/cbc:LineExtensionAmou
nt es distinto de (/DebitNote/Price/cbc:PriceAmount *
/DebitNote/Price/cbc:Price/ BaseQuantity) –
(/DebitNote/cac:DebitNoteLine/cac:AllowanceCharge/cbc:A
mount, correspondientes a aquellos grupos en donde
/DebitNote/cac:DebitNoteLine/cac:AllowanceCharge/cbc:C
hargeIndicator es “false”
o )+
(/DebitNote/cac:DebitNoteLine/cac:AllowanceCharge/cbc:A
mount, correspondientes a aquellos grupos en donde
AllowanceCharge/cbc:ChargeIndicator es “true”)
O dicho de otra forma
every $i in /sig:DebitNote/cac:DebitNoteLine satisfies if
Valor total de la línea. (exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=false()]
LineExtensionA Cantidad x Precio Unidad menos 0..15 ) and /DebitNote/cac:DebitNoteLine/cbc:LineExt
DAV06 cbc E N DebitNoteLine 1..1 1.0
mount descuentos más recargos p (2..6) exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=true()]) ensionAmount
que apliquen para la línea. )then(round($i/cbc:LineExtensionAmount) =
round(($i/cac:Price/cbc:PriceAmount *
$i/cac:Price/cbc:BaseQuantity)+
$i/cac:AllowanceCharge[cbc:ChargeIndicator=true()]/cbc:A
mount -
$i/cac:AllowanceCharge[cbc:ChargeIndicator=false()]/cbc:A
mount)) else
(if(exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=false
()]))then round($i/cbc:LineExtensionAmount) =
round(($i/cac:Price/cbc:PriceAmount *
$i/cac:Price/cbc:BaseQuantity) -
$i/cac:AllowanceCharge[cbc:ChargeIndicator=false()]/cbc:A
mount) else
if(exists($i/cac:AllowanceCharge[cbc:ChargeIndicator=true(
)])) then round($i/cbc:LineExtensionAmount) =
round(($i/cac:Price/cbc:PriceAmount *
$i/cac:Price/cbc:BaseQuantity) +
$i/cac:AllowanceCharge[cbc:ChargeIndicator=true()]/cbc:A
mount) else $i/cbc:LineExtensionAmount =
Base Imponible sobre la que se calcula el 0..15 Para el caso una operación gratuita (afecta a tributo) , se /DebitNote/cac:DebitNoteLine/cac:TaxTot
DAX05 cbc TaxableAmount E N TaxSubtotal 1..1 1.0
valor del tributo p (2..6) debe informar en la base imponile Cantidad x Precio al/cac:TaxSubtotal/cbc:TaxableAmount
Referncial Unidad menos Descuentos más Recargos que
apliquen para la línea.
La Tabla 8 muestra los efectos del registro de un evento sobre la posibilidad que otro evento sea registrado en el mismo documento electrónico. Los códigos y nombres de los eventos,
que se utilizan en la Tabla 8 y en los elementos /ApplicationResponse/cac:DocumentResponse/cac:Response/cbc:ResponseCode y
/ApplicationResponse/cac:DocumentResponse/cac:Response/cbc:Description, están definidos en 6.3.1.
Es posible la existencia de casos en los cuales exista conflicto entre declaraciones; eso ocurre cuando no existe manera automática de decidir cuál de las dos información debe
prevalecer sobre la otra. En tales situaciones, será necesario intervención de la DIAN para resolver el conflicto, probablemente por medio de contacto con uno o ambos los declarantes.
Las definiciones de los eventos se detallan en cada uno de los ítems que siguen el cuerpo común, detallado a continuación.
ID NS
Campo Descripción T F Tam Padre Oc Observaciones V Xpath
DocumentRespon ApplicationRespons /ApplicationResponse/cac:Docume
AAH01 cac Grupo de información del evento a ser registrado G 1..1 1.0
se e ntResponse
/ApplicationResponse/cac:Docume
AAH02 cac Response Descripción del evento registrado G DocumentResponse 1..1 1.0
ntResponse/cac:Response
/ApplicationResponse/cac:Docume
AAH03 cbc ResponseCode Código del evento registrado E N 3 Response 1..1 Debe contener “01” 1.0 ntResponse/cac:Response/cbc:
ResponseCode
/ApplicationResponse/cac:Docume
15- Debe contener el literal “Uso Autorizado
AAH04 cbc Description Descripción del evento registrado E A Response 1..1 1.0 ntResponse/cac:Response/cbc:Des
100 por PA”
cription
/ApplicationResponse/cac:Docume
DocumentRefere
AAH05 cac Documento al cual está referenciado el evento siendo registrado G DocumentResponse 1..1 1.0 ntResponse/cac:cac:DocumentRef
nce
erence
AAH06 cbc ID Prefijo y Número del documento referenciado E A 12 DocumentResponse 0..1 ../cbc:ID 1.0 ../cac:DocumentReference/cbc:ID
Notificación si esta UUID no existe en la ../cac:AdditionalDocumentReferen
AAH07 cbc UUID CUFE del documento referenciado E A 96 DocumentResponse 0..1 1.0
base de datos del PA o de la DIAN ce/cbc:UUID
Algoritmo utilizado para el cáculo del
CUFE
Ver lista de valores posibles en 6.1.2 ../cac:DocumentReference/cbc:UU
AAH08 cbc @schemeName Identificador del esquema de identificación A A 11 UUID 1..1 1.0
Rechazo si el contenido de este atributo ID/@schemeName
no corresponde a algún de los valores
de la columna “Código”
Ver lista de valores posibles en 6.1.3
Rechazo:
DocumentTypeCo ../cac:AdditionalDocumentReferen
AAH09 cbc Identificador del tipo de documento de referencia A N 2 DocumentResponse 1..1 Si este elemento no corresponde a un 1.0
de ce/cbc:DocumentTypeCode
valor de la columna "Código" de uso
“Tipo de Documento”
3.5.4.3. Documento Electrónico Validado por PA, y que Debería Haber Sido Rechazado
Documento electrónico validado exitosamente por un PA, transmitido por este PA para la DIAN, pero que no cumple satisfactoriamente con todas las validaciones, y que, por lo tanto,
no debiera haber sido validado exitosamente por el PA.
Responsable por el Registro: DIAN
Efectos: Impide el registro de los eventos “Aceptación de Documento” y “Factura Ofrecida para Negociación como Título Valor”, sin posibilidad de resolución de esta situación
PA deberá comunicar el emisor del problema, y el emisor deberá regularizar el documento.
PA deberá corregir su aplicación para que no se repita el problema.
Guía del nombre del archivo xml de un documento electrónico requeridos por la DIAN
Notas:
Los tamaños de cada variable son constantes, es necesario generar el ajuste con ceros a la izquierda en cada uno de ellos.
Los Códigos “ppp” para el Software Propio y Facturación gratuita de la DIAN se manejarán de la siguiente manera:
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
3.7. Guía del nombre del archivo que contiene uno o más documentos electrónicos y que será entregado a la DIAN mediante un web service de recepción.
Guía del nombre del archivo ZIP que Contiene uno o más documentos electrónicos y que será Entregado a la DIAN mediante un web service de recepción.
znnnnnnnnnnpppaadddddddd.zip z: comprimido
archivo comprimido que contiene uno o varios archivos *.xml. Cada archivo nnnnnnnnnn: NIT del Facturador Electrónico sin DV, de diez (10) dígitos alineados a la derecha y relleno con ceros a la
.xml debe ser un documento electrónico ubl-DIAN. izquierda.
si el archivo se transmitirá a la DIAN a través del servicio sincrónico, entonces ppp: Código asignado por la DIAN al PT de tres (3) dígitos.
la cantidad de documentos electrónicos será igual a uno “1”. En caso
aa: Dos (2) últimos dígitos año calendario
contrario el resultado de la operación será RECHAZO.
Si el archivo se transmitirá a la DIAN a través del servicio asincrónico, dddddddd: consecutivo del paquete de archivos comprimidos enviados; de ocho (8) dígitos decimales alineados a la
entonces la cantidad de documentos electrónicos será inferior a 51; el derecha y ajustado a la izquierda con ceros; en el rango:
contenido podrá ser combinado, es decir que podrán incluirse: “fv”, “nc”, 00000001 <= 99999999
“nd”, “ar” dentro del mismo archivo comprimido. Ejemplo de la décima primera factura del Facturador Electrónico con NIT 800197268 con software propio para el año
Este formato será el único para la entrega de archivos comprimidos 2019.
z08001972680001900000011.zip
Regla: el consecutivo se iniciará en “00000001” cada primero de enero.
Nota: El consecutivo “dddddddd” corresponde al envió del archivo .zip enviado a la entidad.
RSAwithSHA256=http://www.w3.org/2001/04/x ../ext:UBLExtensions/ext:UBLExtension/ext:
El algoritmo de firma usado sobre el elemento
DC04 ds SignatureMethod Signature 1..1 mldsig-more#rsa-sha256 1.0 ExtensionContent/ds:Signature/ds:SignedInf
«SignedInfo»
o/ds:SignatureMethod
RSAwithSHA384=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha384
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
../ext:UBLExtensions/ext:UBLExtension/ext:
Grupo de la primera referencia que contiene la firma
DC05 ds Reference G Signature 1..1 URI="" 1.0 ExtensionContent/ds:Signature/ds:SignedInf
aplicada de todo el documento
o/ds:Reference
RSAwithSHA256=http://www.w3.org/2001/04/x ../ext:UBLExtensions/ext:UBLExtension/ext:
DC08 ds DigestMethod El algoritmo de firma usado sobre el elemento Reference 1..1 mldsig-more#rsa-sha256 1.0 ExtensionContent/ds:Signature/ds:SignedInf
o/ds:Reference/ds:DigestMethod
RSAwithSHA384=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha384
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
Resultado de aplicar el algoritmo de generación hash ../ext:UBLExtensions/ext:UBLExtension/ext:
DC09 ds DigestValue especificado en el “DigestMethod” en codificación Reference 1..1 1.0 ExtensionContent/ds:Signature/ds:SignedInf
base64 o/ds:Reference/ds:DigestValue
../ext:UBLExtensions/ext:UBLExtension/ext:
Grupo de la segunda referencia donde se especifica
DC10 ds Reference G Signature 1..1 URI="#{UUID}-KeyInfo" 1.0 ExtensionContent/ds:Signature/ds:SignedInf
clave pública contenida en el elemento KeyInfo.
o/ds:Reference
Puede ser cualquiera de los definidos en la
especificación XML-Signature Syntax and
Processing (http://www.w3.org/TR/xmldsig-
core2/#sec-Algorithms) que actualmente son:
RSAwithSHA256=http://www.w3.org/2001/04/x ../ext:UBLExtensions/ext:UBLExtension/ext:
DC11 ds DigestMethod El algoritmo de firma usado sobre el elemento Reference 1..1 mldsig-more#rsa-sha256 1.0 ExtensionContent/ds:Signature/ds:SignedInf
o/ds:Reference/ds:DigestMethod
RSAwithSHA384=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha384
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
RSAwithSHA256=http://www.w3.org/2001/04/x ../ext:UBLExtensions/ext:UBLExtension/ext:
DC14 ds DigestMethod El algoritmo de firma usado sobre el elemento Reference 1..1 mldsig-more#rsa-sha256 1.0 ExtensionContent/ds:Signature/ds:SignedInf
o/ds:Reference/ds:DigestMethod
RSAwithSHA384=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha384
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
Resultado de aplicar el algoritmo de generación hash ../ext:UBLExtensions/ext:UBLExtension/ext:
DC15 ds DigestValue especificado en el “DigestMethod” en codificación Reference 1..1 1.0 ExtensionContent/ds:Signature/ds:SignedInf
base64 o/ds:Reference/ds:DigestValue
Resultado de aplicar el algoritmo de generación hash ../ext:UBLExtensions/ext:UBLExtension/ext:
DC16 ds SignatureValue especificado en el “SignatureMethod” en Signature 1..1 1.0 ExtensionContent/ds:Signature/ds:Signatur
codificación base64 eValue
Grupo de información para embeber el certificado ../ext:UBLExtensions/ext:UBLExtension/ext:
DC17 ds KeyInfo G Signature 1..1 1.0
público requerido para validar la firma. ExtensionContent/ds:Signature/ds:KeyInfo
../ext:UBLExtensions/ext:UBLExtension/ext:
Grupo que contiene el certificado publico del que
DC18 ds X509Data G KeyInfo 1..1 1.0 ExtensionContent/ds:Signature/ds:KeyInfo/
firma el documento
ds:X509Data
../ext:UBLExtensions/ext:UBLExtension/ext:
Certificado publico requerido para validar la firma del
DC19 ds X509Certificate X509Data 1..1 1.0 ExtensionContent/ds:Signature/ds:KeyInfo/
documento electronico
ds:X509Data/ds:X509Certificate
Grupo de objetos para definir las propiedades de la ../ext:UBLExtensions/ext:UBLExtension/ext:
DC20 ds Object G Signature 1..1 1.0
firma ExtensionContent/ds:Signature/ds:Object
../ext:UBLExtensions/ext:UBLExtension/ext:
QualifyingProperti Grupo de elementos calificables de comprobación del
DC21 xades G Object 1..1 1.0 ExtensionContent/ds:Signature/ds:Object/x
es firma
ades:QualifyingProperties
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
../ext:UBLExtensions/ext:UBLExtension/ext:
ExtensionContent/ds:Signature/ds:Object/x
Resultado de aplicar el algoritmo de generación hash
SignedSignaturePr ades:QualifyingProperties/xades:SignedPro
DC29 ds DigestValue especificado en el “DigestMethod” en codificación 1..1 1.0
operties perties/xades:SignedSignatureProperties/xa
base64
des:SigningCertificate/xades:Cert/xades:Cer
tDigest/ds:DigestValue
../ext:UBLExtensions/ext:UBLExtension/ext:
ExtensionContent/ds:Signature/ds:Object/x
SignedSignaturePr ades:QualifyingProperties/xades:SignedPro
DC30 xades IssuerSerial Grupo para definir los datos del certificado G 1..1 1.0
operties perties/xades:SignedSignatureProperties/xa
des:SigningCertificate/xades:Cert/xades:Issu
erSerial
../ext:UBLExtensions/ext:UBLExtension/ext:
ExtensionContent/ds:Signature/ds:Object/x
Subject del certificado digital con que firma el SignedSignaturePr ades:QualifyingProperties/xades:SignedPro
DC31 ds X509IssuerName 1..1 1.0
documento electrónico operties perties/xades:SignedSignatureProperties/xa
des:SigningCertificate/xades:Cert/xades:Issu
erSerial/ds:X509IssuerName
../ext:UBLExtensions/ext:UBLExtension/ext:
ExtensionContent/ds:Signature/ds:Object/x
Serial del certificado digital con que firma el SignedSignaturePr ades:QualifyingProperties/xades:SignedPro
DC32 ds X509SerialNumber 1..1 1.0
documento electrónico operties perties/xades:SignedSignatureProperties/xa
des:SigningCertificate/xades:Cert/xades:Issu
erSerial/ds:X509SerialNumber
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
../ext:UBLExtensions/ext:UBLExtension/ext:
ExtensionContent/ds:Signature/ds:Object/x
Resultado de aplicar el algoritmo de generación hash
SignedSignaturePr ades:QualifyingProperties/xades:SignedPro
DC36 ds DigestValue especificado en el “DigestMethod” en codificación 1..1 1.0
operties perties/xades:SignedSignatureProperties/xa
base64
des:SigningCertificate/xades:Cert/xades:Cer
tDigest/ds:DigestValue
../ext:UBLExtensions/ext:UBLExtension/ext:
ExtensionContent/ds:Signature/ds:Object/x
SignedSignaturePr ades:QualifyingProperties/xades:SignedPro
DC37 xades IssuerSerial Grupo para definir los datos del certificado G 1..1 1.0
operties perties/xades:SignedSignatureProperties/xa
des:SigningCertificate/xades:Cert/xades:Issu
erSerial
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
RSAwithSHA512=http://www.w3.org/2001/04/x
mldsig-more#rsa-sha512
../ext:UBLExtensions/ext:UBLExtension/ext:
ExtensionContent/ds:Signature/ds:Object/x
Resultado de aplicar el algoritmo de generación hash ades:QualifyingProperties/xades:SignedPro
SignedSignaturePr
DC53 ds DigestValue especificado en el “DigestMethod” en codificación 1..1 1.0 perties/xades:SignedSignatureProperties/xa
operties
base64 des:SignaturePolicyIdentifier/xades:Signatur
ePolicyId/xades:SigPolicyHash/ds:DigestValu
e
1. Detección del error “500 – Internal Server Error” o “503 – Service Unavailable”. Únicamente este error.
2. Transmitir nuevamente a la DIAN la factura electrónica de venta para validación previa transcurridos 20
segundos después de la detección del error “500 – Internal Server Error” o “503 – Service Unavailable”..
Si persiste el error, se deben realizar dos (2) intentos más, cada uno en intervalo de 20 segundos. Al
finalizar la cuarta transmisión en la que se ha detectado el error, es decir un minuto después de la
transmisión inicial y si persiste la condición de error, el facturador electrónico o el proveedor tecnológico
podrá transmitir directamente al adquirente, la factura electrónica sin validación previa.
3. Mantener o archivar las evidencias del error “500 – Internal Server Error” o “503 – Service Unavailable”
en sus registros digitales.
4. Generar nuevamente la factura electrónica de venta cambiando el contenido referenciado en la etiqueta
InvoiceTypeCode con el valor 04 según la tabla 6.1.3 manteniendo el mimo prefijo y numero de factura,
volver a firmar la factura electrónica, incluir la factura electrónica sin Application Response (validación de
la DIAN) en un AttachedDocument y entregar al adquirente.
5. Monitorear la conexión y el sitio web de la DIAN, con el fin de identificar el restablecimiento del servicio
por parte de la DIAN. Transmitir normalmente las Facturas Electrónicas para Validación Previa, e iniciar
la transmisión de las facturas electrónicas entregadas al adquirente sin validación previa al web service
de contingencia dispuesto por la DIAN
Código Nombre
01 Uso Autorizado por PA
02 Uso Autorizado por la DIAN
03 Documento Electrónico Validado por PA, y que Debería Haber Sido Rechazado
04 Uso No Autorizado por la DIAN
011 Documento Referenciado no Existe en la Base de Datos de la DIAN
030 Acuse de recibo
031 Rechazo de Documento
032 Recepción de los Bienes
033 Aceptación de Documento
040 Factura Ofrecida para Negociación como Título Valor
041 Factura Negociada como Título Valor
6.3.4. Pagos
B55 kilovoltios por metro GGR gramo TSH tonelada de vapor por hora
B56 kiloveber por metro GH medio galón (EE. UU.) TT mil metros lineales
B57 año luz GIA branquias TU tubo
B58 litro por mol GII Gill (Reino Unido) TV mil kilogramos
B59 hora lumen GJ gramo por mililitro TW mil hojas
B6 bollo GK gramo por kilogramo TY tanque, cilíndrico
B60 lumen por metro cuadrado GL gramo por litro U1 tratamiento
B61 lumen por vatio GLD galón seco (EE. UU.) U2 tableta
B62 lumen segundo GLI galón (Reino Unido) UA torr
B63 hora de lux GLL galón UB Línea de telecomunicaciones en
servicio promedio.
B64 lux segundo GM gramo por metro cuadrado UC puerto de telecomunicaciones
B65 Maxwell GN galón bruto UD décimo minuto
B66 megaamperios por metro cuadrado GO miligramos por metro UE décima hora
cuadrado
B67 megabecquerel por kilogramo GP miligramo por metro cúbico UF uso por línea de telecomunicación
promedio
B69 megacoulomb por metro cúbico GQ microgramos por metro UH diez mil yardas
cúbico
B7 ciclo GRM gramo UM millones de unidades
B70 megacoulomb por metro cuadrado GRN grano VA voltio amperio por kilogramo
B71 megaelectronvolt GRO bruto VI frasco
B72 megagramo por metro cúbico GRT tonelada de registro bruto VLT voltio
B73 meganewton GT tonelada bruta VQ abultar
B74 medidor de meganewton GV gigajoule VS visitar
ReteIVA 15.00
Tarifa
Conceptos
(cbc:Percent)
Compras de bienes raíces cuya destinación y uso sea vivienda de habitación (por las
primeras 20.000 UVT, es decir hasta $637.780.000) 1.00
Compras de bienes raíces cuya destinación y uso sea distinto a vivienda de habitación 2.50
Servicios de transporte nacional de pasajeros por vía terrestre (no declarantes) 3.50
…//ext:UBLExtensions/ext:U
Tipo de identificador fiscal de BLExtension/ext:ExtensionC
Identificador del tipo de
la persona debe corresponder ontent/sts:DianExtensions/s
FAB35 R schemeName documento de identidad no 1.0
a un valor codificado igual a ts:AuthorizationProvider/sts
es igual a 31
31 :AuthorizationProviderID/@
schemeName
…//ext:UBLExtensions/ext:U
Colocar la definición de este No está informado la BLExtension/ext:ExtensionC
FAB36 R QRCode 1.0
código información del Código QR ontent/sts:DianExtensions/s
ts:QRCode
CustomizationID no indica
Indicador del tipo de /Invoice/cbc:CustomizationI
FAD02 R CustomizationID un valor válido para el tipo 1.0
operación D
de operación
No se permiten caracteres
Número de factura solo puede
FAD05a R ID adicionales como espacios o 1.0 /Invoice/cbc:ID
contener dígitos y letras
guiones
Notificación si la fecha de
La fecha de emisión fue
emisión es anterior a cinco (5)
FAD09c N IssueDate anterior a 5 días de la fecha 1.0 /Invoice/cbc:IssueDate
días de la fecha calendario
actual
actual.
Se debe diligenciar
únicamente cuando la FE se
FBH01 N BillingReference origina a partir de la 1.0 Invoice/cac:BillingReference
corrección o ajuste que se da
mediante un NC
/Invoice/cac:BillingReferenc
CreditNoteDocumen Grupo de información para
FBH02 R 1.0 e/cac:CreditNoteDocument
tReference nota crédito relacionada
Reference
/Invoice/cac:BillingReferenc
Prefijo + Número de la nota ID de NC de referencia no
FBH03 R ID 1.0 e/cac:CreditNoteDocument
crédito referenciada relacionada
Reference/cbc:ID
Se debe diligenciar
únicamente cuando la FE se
origina a partir de la /Invoice/cac:BillingReferenc
FBH04 R UUID corrección o ajuste que se da CUDE de NC referenciada no 1.0 e/cac:CreditNoteDocument
mediante un NC existe
Reference/cbc:UUID
Rechazo si CUDE NC
referenciada no existe
/Invoice/cac:BillingReferenc
e/cac:CreditNoteDocument
FBH05 N @schemeName Algoritmo del CUDE Algoritmo no corresponde 1.0
Reference/cbc:UUID/@sche
meName
Fecha de emisión de la nota
crédito relacionada debe ser
anterior a la fecha de la Fecha NC referenciada /Invoice/cac:BillingReferenc
FBH06 R IssueDate factura anterior a fecha de la 1.0 e/cac:CreditNoteDocument
Rechazo si Fecha NC factura Reference/cbc:IssueDate
referenciada posterior a
Invoice/cbc:IssueDate
Se debe diligenciar
únicamente cuando la FE se
FBI01 N BillingReference origina a partir de la 1.0 Invoice/cac:BillingReference
corrección o ajuste que se da
mediante una ND
/Invoice/cac:BillingReferenc
DebitNoteDocumen Grupo de información para
FBI02 R 1.0 e/cac:DebitNoteDocumentR
tReference nota débito relacionada
eference
/Invoice/cac:BillingReferenc
Prefijo + Número de la nota ID de ND de referencia no
FBI03 R ID 1.0 e/cac:DebitNoteDocumentR
débito relacionada relacionada
eference/cbc:ID
Se debe diligenciar
únicamente cuando la FE se
origina a partir de la /Invoice/cac:BillingReferenc
FBI04 R UUID corrección o ajuste que se da CUDE de ND referenciada 1.0 e/cac:DebitNoteDocumentR
mediante un ND no existe
eference/cbc:UUID
Rechazo si CUDE ND
referenciada no existe
/Invoice/cac:BillingReferenc
e/cac:DebitNoteDocumentR
FBI05 N @schemeName Algoritmo del CUDE Algoritmo no corresponde 1.0
eference/cbc:UUID/@sche
meName
No esta informado el
CUFE del documento /Invoice/cac:AdditionalDocu
FAI03 R UUID elemento UUID (CUFE o 1.0
referenciado mentReference/cbc:UUID
CUDE)
/Invoice/cac:AdditionalDocu
Fecha de emisión del
FAI05 N IssueDate 1.0 mentReference/cbc:IssueDa
documento referenciado
te
/Invoice/cac:AdditionalDocu
Identificador del tipo de No esta informado el tipo de
FAI06 N DocumentTypeCode 1.0 mentReference/cbc:Docum
documento de referencia documento referenciado.
entTypeCode
Identifica el código de
actividad económica del
emisor. Debe informar el Códigos no informados o no /Invoice/cac:AccountingSup
IndustryClasification
FAJ04 N código según lista CIIU. Para corresponden a los que 1.0 plierParty/cac:Party/cbc:Ind
Code
informar varios códigos, se estan en lista ustryClassificationCode
separan por; Ejemplo
7020;5140
Valida estructura de
composición de Código postal /Invoice/cac:AccountingSup
plierParty/cac:Party/cac:Phy
FAJ73 N PostalZone Próximamente este elemento Estructura código no valida 1.0
sicalLocation/cac:Address/c
será solicitado de forma bc:PostalZone
obligatoria.
/Invoice/cac:AccountingSup
Grupo de elemento que
plierParty/cac:Party/cac:Phy
FAJ13 N AddressLine identifica libremente la 1.0
sicalLocation/cac:Address/c
dirección
ac:AddressLine
/Invoice/cac:AccountingSup
Identificador del lenguaje
plierParty/cac:Party/cac:Phy
utilizado en el nombre del
FAJ18 N @languageID Debe contener el literal “es” 1.0 sicalLocation/cac:Address/c
país, debe utilizar el literal
ac:Country/cbc:Name/@lan
“es”
guageID
/Invoice/cac:AccountingSup
Rechazo si el atributo
No esta informado el DV del plierParty/cac:Party/cac:Par
FAJ24a R @schemeID @schemeName es 31 y no se 1.0
NIT tyTaxScheme/cbc:CompanyI
informa el DV en este campo.
D/@schemeID
/Invoice/cac:AccountingSup
Valida que el DV del NIT del
plierParty/cac:Party/cac:Par
FAJ24b R @schemeID emisor informado sea El DV del NIT no es correcto 1.0
tyTaxScheme/cbc:CompanyI
correcto
D/@schemeID
No fue informado el
conjunto formado por los
/Invoice/cac:AccountingSup
elementos: ID, CityName,
RegistrationAddres Grupo de información para plierParty/cac:Party/cac:Par
FAJ28 R CountrySubentity, 1.0
s informar dirección fiscal tyTaxScheme/cac:Registrati
CountrySubentityCode,
onAddress
AddressLine, Line, Country,
IdentificationCode
Valida estructura de
composición de Código postal /Invoice/cac:AccountingSup
plierParty/cac:Party/cac:Par
FAJ74 N PostalZone Nota: Próximamente este Estructura código no valida 1.0
tyTaxScheme/cac:Registrati
elemento será solicitado de onAddress/cbc:PostalZone
forma obligatoria.
El nombre no corresponde un
valor valido de la lista
/Invoice/cac:AccountingSup
Si este es un grupo con plierParty/cac:Party/cac:Par
El nombre no corresponde
FAJ31 N CountrySubentity información con respeto a la 1.0 tyTaxScheme/cac:Registrati
dirección del emisor de un un valor valido de la lista
onAddress/cbc:CountrySube
documento electrónico, debe ntity
ser un Departamento de
Colombia
/Invoice/cac:AccountingSup
Grupo de elemento que
plierParty/cac:Party/cac:Par
FAJ33 N AddressLine identifica libremente la 1.0
tyTaxScheme/cac:Registrati
dirección
onAddress/cac:AddressLine
Notificación: Emisor es
responsable: debe existir la
información correspondiente
Debe existir un grupo
…//cac:AccountingSupplierPar /Invoice/cac:AccountingSup
FAJ39 N TaxScheme ty/cac:Party/cac:PartyTaxSche No se encuentra el grupo 1.0
plierParty/cac:Party/cac:Par
me/cac:TaxScheme en el cual TaxScheme del emisor tyTaxScheme/cac:TaxSchem
el elemento e
…//cac:AccountingSupplierPar
ty/cac:Party/cac:PartyTaxSche
me/cac:TaxScheme/cb:ID es
01
/Invoice/cac:AccountingSup
EL contenido de este
Valida el identificador plierParty/cac:Party/cac:Par
FAJ40 R ID elemento no corresponde a 1.0
tributario del emisor tyTaxScheme/cac:TaxSchem
un contenido valido 01
e/cbc:ID
…//cac:AccountingSupplierP
Grupo de información legal No se encuentra el grupo
FAJ42 R PartyLegalEntity 1.0 arty/cac:Party/cac:PartyLeg
del emisor PartyLegalEntity del emisor
alEntity
…//cac:AccountingSupplierP
Nombre o Razón Social del arty/cac:Party/cac:PartyLeg
FAJ43 R RegistrationName Nombre No informado 1.0
emisor debe ser informado alEntity/cbc:RegistrationNa
me
…//cac:AccountingSupplierP
NIT no autorizado a facturar
FAJ44 R CompanyID NIT del emisor 1.0 arty/cac:Party/cac:PartyLeg
electrónicamente
alEntity/cbc:CompanyID
…//cac:AccountingSupplierP
Debe ser informado el literal No informado el literal arty/cac:Party/cac:PartyLeg
FAJ45 N @schemeAgencyID 1.0
“195” “195” alEntity/cbc:CompanyID/@s
chemeAgencyID
Debe ser informado el literal No informado el literal “CO, …//cac:AccountingSupplierP
@schemeAgencyNa “CO, DIAN (Dirección de DIAN (Dirección de arty/cac:Party/cac:PartyLeg
FAJ46 N 1.0
me Impuestos y Aduanas Impuestos y Aduanas alEntity/cbc:CompanyID/@s
Nacionales) Nacionales) chemeAgencyName
…//cac:AccountingSupplierP
El atributo DV del NIT del emisor no arty/cac:Party/cac:PartyLeg
FAJ47 R @schemeID 1.0
(@schemeName=31), el DV informado alEntity/cbc:CompanyID/@s
chemeID
Si se va a opera bajo
…//cac:AccountingSupplierP
modalidad del consorcio o
No se encuentra el grupo arty/cac:Party/cac:PartyLeg
FAJ52 R ShareholderParty Unión temporal, entonces 1.0
ShareholderParty del emisor alEntity/cac:ShareholderPar
este grupo de información
ty
debe ser completada
Si el documento hace
referencia a un consorcio o …//cac:AccountingSupplierP
No se ha informado el
PartecipationPercen unión temporal entonces de arty/cac:Party/cac:PartyLeg
FAJ53 R porcentaje de los 1.0
t debe informar el Porcentaje alEntity/cac:ShareholderPar
participantes del consorcio
de los participantes del ty/cbc:PartecipationPercent
consocio o unión temporal
Si se va a opera bajo
modalidad del consorcio o /Invoice/cac:AccountingSup
Unión temporal, entonces No se encuentra el grupo plierParty/cac:Party/cac:Par
FAJ54 R Party 1.0
este Grupo de elemento ShareholderParty del emisor tyLegalEntity/cac:Sharehold
permite registrar la erParty/cac:Party
información de un consorcio
…//cac:AccountingSupplierP
Valida que Responsabilidad
Responsabilidad informada arty/cac:Party/cac:PartyLeg
informada por participantes
FAJ62 N TaxLevelCode por participantes no valido 1.0 alEntity/cac:ShareholderPar
se encuentren dentro de la
según lista ty/cac:Party/cac:PartyTaxSc
lista.
heme/cbc:TaxLevelCode
No se encuentra el grupo
AccountingCustome Grupo con información que /Invoice/cac:AccountingCust
FAK01 R AccountingCustomerParty 1.0
rParty definen el Adquirente omerParty
del adquirente
Valida estructura de
composición de Código postal
../cac:Address/cbc:PostalZo
FAK57 N PostalZone Próximamente este elemento Estructura código no valida 1.0
ne
será solicitado de forma
obligatoria.
Grupo de información
tributaria del Adquirente.
Rechazo:
Si el grupo no es informado y
si se cumple al menos una de
las siguientes situaciones:
Si el adquirente es persona …//cac:AccountingCustomer
No se encuentra el grupo
FAK19 R PartyTaxScheme jurídica: 1.0 Party/cac:Party/cac:PartyTa
PartyTaxScheme
xScheme
AdditionalAccountID contiene
“1”
En caso de operación de
exportación: Si
//cbc:InvoiceTypeCode = “02”
Si el valor total de la factura es
mayor de 100 UVT:
…//cac:AccountingCustomer
Id del adquirente debe ser ID de adquirente no
FAK21 R CompanyID 1.0 Party/cac:Party/cac:PartyTa
informado Informado
xScheme/cbc:CompanyID
…//cac:AccountingCustomer
Debe ser informado el literal No informado el literal Party/cac:Party/cac:PartyTa
FAK22 N @schemeAgencyID 1.0
“195” “195” xScheme/cbc:CompanyID/@
schemeAgencyID
Debe ser informado el literal No informado el literal “CO, …//cac:AccountingCustomer
@schemeAgencyNa “CO, DIAN (Dirección de DIAN (Dirección de Party/cac:Party/cac:PartyTa
FAK23 N 1.0
me Impuestos y Aduanas Impuestos y Aduanas xScheme/cbc:CompanyID/@
Nacionales)” Nacionales)” schemeAgencyName
…//cac:AccountingCustomer
Rechazo si el atributo
No esta informado el DV del Party/cac:Party/cac:PartyTa
FAK24 R @schemeID @schemeName es 31 y no se 1.0
NIT xScheme/cbc:CompanyID/@
informa el DV en este campo.
schemeID
…//cac:AccountingCustomer
Valida que el DV del NIT del
Party/cac:Party/cac:PartyTa
FAK25 R @schemeID emisor informado sea El DV del NIT no es correcto 1.0
xScheme/cbc:CompanyID/@
correcto
schemeName
Valida estructura de
composición de Código postal
../cac:RegistratioAddress/cb
FAK58 N PostalZone Próximamente este elemento Estructura código no valida 1.0
c:PostalZone
será solicitado de forma
obligatoria.
Notificación: Si el adquirente
es responsable, el NIT debe
estar activo en el RUT
Si existe un grupo
…///cac:AccountingCustomer
Party/cac:Party/cac:PartyTaxS
cheme/cac:TaxScheme
en el cual el elemento
…//cac:AccountingCustomerP
arty/cac:Party/cac:PartyTaxSc
heme/cbc:ID es 01 y …//cac:AccountingCustomer
No se encuentra el grupo
FAK39 N TaxScheme …//cac:AccountingCustomerP 1.0 Party/cac:Party/cac:PartyTa
TaxScheme
arty/cac:Party/cac:PartyLegalE xScheme/cac:TaxScheme
ntity
/cbc:CompanyID/@schemeNa
me=31
entonces NIT
…//cac:AccountingCustomerP
arty/cac:Party/cac:PartyLegalE
ntity /cbc:CompanyID debe
estar activo
Obligatorio si adquiriente es
responsable
EL contenido de este
Valida el identificador
FAK40 N ID elemento no corresponde a 1.0 ../cac:TaxScheme/cbc:ID
tributario del receptor
un contenido valido 01
…//cac:AccountingCustomer
Grupo de información legal
Obligatorio si adquiriente es
FAK42 N PartyLegalEntity 1.0 Party/cac:Party/cac:PartyLe
del adquirente responsable
galEntity
…//cac:AccountingCustomer
Nombre o Razón Social del
Party/cac:Party/cac:PartyLe
FAK43 N RegistrationName adquirente debe ser Nombre No informado 1.0
galEntity/cbc:RegistrationNa
informado
me
…//cac:AccountingCustomer
FAK44 N CompanyID ID del adquirente ID adquirente no informado 1.0 Party/cac:Party/cac:PartyLe
galEntity /cbc:CompanyID
…//cac:AccountingCustomer
Party/cac:Party/cac:PartyLe
Debe ser informado el literal No informado el literal
FAK45 N @schemeAgencyID 1.0 galEntity
“195” “195”
/cbc:CompanyID/@scheme
AgencyID
…//cac:AccountingCustomer
Debe ser informado el literal No informado el literal “CO,
Party/cac:Party/cac:PartyLe
@schemeAgencyNa “CO, DIAN (Dirección de DIAN (Dirección de
FAK46 N 1.0 galEntity
me Impuestos y Aduanas Impuestos y Aduanas
/cbc:CompanyID/@scheme
Nacionales) Nacionales)
AgencyName
…//cac:AccountingCustomer
El atributo
Party/cac:Party/cac:PartyLe
(@schemeName=31), el DV DV del NIT del emisor no
FAK47 R @schemeID 1.0 galEntity
del NIT debe ser informado en informado
/cbc:CompanyID/@schemeI
@schemeID
D
…/cac:AccountingCustomer
Correo electrónico de Correo electrónico no
FAK55 N ElectronicMail 1.0 Party/cac:Party/cac:Contact
contacto informado
/cbc:ElectronicMail
Grupo de información de la
TaxRepresentativeP ..//cac:TaxRepresentativePa
FAL01 N Persona autorizada para 1.0
arty rty
descargar documentos
…//cac:TaxRepresentativePa
FAL02 N PartyIdentification
rty/cac:PartyIdentification
El atributo
…//cac:TaxRepresentativePa
(@schemeName=31), el DV DV del NIT del emisor no
FAL07 N @schemeID 1.0 rty/cac:PartyIdentification/c
del NIT debe ser informado en informado
bc:ID/@schemeID
@schemeID
Valida estructura de
composición de Código postal
../cac:DeliveryAddress/cbc:
FAM68 N PostalZone Próximamente este elemento Estructura código no valida 1.0
PostalZone
será solicitado de forma
obligatoria.
…//cac:Delivery/cac:Delivery
Nombre comercial de la
FAM17 N Name 1.0 Party
empresa de transporte
/cac:PartyName/cbc:Name
Valida estructura de
composición de Código postal
../cac:Address/cbc:PostalZo
FAM69 N PostalZone Próximamente este elemento Estructura código no valida 1.0
ne
será solicitado de forma
obligatoria.
Si este es un grupo de
información con respeto a la
dirección del emisor de un
documento electrónico, debe
ser un Departamento de El nombre no corresponde ../cac:Address/cbc:CountryS
FAM22 N CountrySubentity Colombia 1.0
un valor valido de la lista ubentity
Si IdentificationCode es “CO”,
CountrySubentity debe
corresponder a uno de los
valores de la lista
Si este es un grupo de
información con respeto a la
dirección del emisor de un
documento electrónico, debe
ser un código de
Departamento de Colombia
CountrySubentityCo Este código no corresponde ../cac:Address/cbc:CountryS
FAM23 N Si IdentificationCode es “CO”, 1.0
de a un valor válido de la lista ubentityCode
CountrySubentity debe
corresponder a uno de los
valores de la Columna Código
de 6.4.2
Obligatorio para Emisores y
Adquirentes Responsables
Si el transportador es …/cac:Delivery/cac:Delivery
Identificador del
FAM32 R CompanyID responsable debe informar 1.0 Party/cac:PartyTaxScheme/c
transportador
NIT bc:CompanyID
…/cac:Delivery/cac:Delivery
Debe ser informado el literal No informado el literal Party/cac:PartyTaxScheme/c
FAM33 N @schemeAgencyID 1.0
“195” “195” bc:CompanyID/@schemeAg
encyID
Debe ser informado el literal No informado el literal “CO, …/cac:Delivery/cac:Delivery
@schemeAgencyNa “CO, DIAN (Dirección de DIAN (Dirección de Party/cac:PartyTaxScheme/c
FAM34 N 1.0
me Impuestos y Aduanas Impuestos y Aduanas bc:CompanyID/@schemeAg
Nacionales)” Nacionales)” encyName
Valida estructura de
composición de Código postal
../cac:RegistrationAddress/c
FAM70 N PostalZone Próximamente este elemento Estructura código no valida 1.0
bc:PostalZone
será solicitado de forma
obligatoria.
Si el contenido de este
elemento no corresponde a
un contenido de la columna
“Identificador”
Nombre registrado en el
RUT. Si el transportador es
persona jurídica desea
también utilizar el nombre
comercial en el archivo de la ../cac:Delivery/cac:DeliveryP
Nombre o Razón Social del factura, debe utilizar el
FAM54 RegistrationName 1.0 arty/cac:PartyLegalEntity/cb
transportador elemento c:RegistrationName
…//cac:AccountingSupplierP
arty/cac:Party/cac:PartyNa
me/cbc:Name
Si transportador es …/cac:Delivery/cac:Delivery
Identificador del
FAM55 CompanyID responsable, NIT del 1.0 Party/cac:PartyLegalEntity/c
transportador
transportador bc:CompanyID
El atributo
(@schemeName=31), el DV DV del NIT del ..//cbc:CompanyID/@schem
FAM58 R @schemeID 1.0
del NIT debe ser informado en transportador no informado eID
@schemeID
…/cac:Delivery/cac:Delivery
CorporateRegistrati Grupo de información de Party/cac:PartyLegalEntity/c
FAM60 1.0
onScheme registro del transportador ac:CorporateRegistrationSch
eme
Valida que este informado el
Número de matrícula …/cac:CorporateRegistratio
FAM61 N Name Número de matrícula 1.0
mercantil no informado nScheme/cbc:Name
mercantil
Condiciones de Entrega:
LossRiskResponsibili Obligatorio cuando sea una …/cac:DeliveryTerms/cbc:Lo
FBC04 R factura de exportación 1.0
tyCode ssRiskResponsibilityCode
Ver lista de valores en 6.3.7
Fecha de vencimiento de la
factura o fecha de
compromiso de pago
Obligatorio si es venta a Venta a crédito sin
información de fecha en la /Invoice/cac:PaymentMeans
FAN04 R PaymentDueDate crédito 1.0
cual se comprometió el /cbc:PaymentDueDate
Rechazo: pago
Si PaymentMeans/ID = 2 y
PaymentDueDate no es
informado
/Invoice/cac:PaymentMeans
FAN05 N PaymentID Identificador del pago 1.0
/cbc:PaymentID
Obligatorio de informar si es
descuento a nivel de factura
internacional. De acuerdo a
los valores establecidos en la
Hay un descuento a nivel de …//cac:AllowanceCharge/c
AllowanceChargeRe tabla 6.3.8
FAQ04 N factura y no indicó el código 1.0 bc:AllowanceChargeReaso
asonCode Rechazo: Si es descuento y no del descuento nCode
se informa
Notificación: si hay un recargo
y este elemento no es
informado
Porcentaje a aplicar.
Porcentaje aplicado en …//cac:AllowanceCharge/c
MultiplierFactorNu decimales Porcentaje que aplica
FAQ06 N 1.0 bc:MultiplierFactorNumeri
meric superior al 100%
Notificación: si este elemento c
> 100
Rechazo:
Si
…//AllowanceCharge/cbc:Char
geIndicator es true y
/Invoice/cac:PaymentExcha
TargetCurrencyBase Base monetaria para la TargetCurrencyBase trae
FAR05 R 1.0 ngeRate/cbc:TargetCurrenc
Rate conversión. Debe ser 1.00 valor diferente a 1.00
yBaseRate
/Invoice/cac:PaymentAltern
TargetCurrencyBase Base monetaria para la TargetCurrencyBase trae
FAG05 N 1.0 ativeExchangeRate/cbc:Targ
Rate conversión. Debe ser 1.00 valor diferente a 1.00
etCurrencyBaseRate
Existe un grupo
Valida que existe solo un
/Invoice/TaxTotal para uno
grupo con información de
de los impuestos s IVA
totales para un mismo
(01), INC (04), ICA (03) sin
FAS01 tributo en la factura y que los
R TaxTotal que exista un grupo 1.0 /Invoice/cac:TaxTotal
b impuestos IVA (01), INC (04),
/Invoice/cac:InvoiceLine
ICA (03) deben existir
con información
también en al menos una
correspondientes al mismo
línea de la factura
impuesto.
../cac:TaxTotal/cac:TaxSubto
Identificación de la unidad de Unidad de medida no
FAS10 N unitCode 1.0 tal/cbc:BaseUnitMeasure/@
medida informada
unitCode
../cac:TaxTotal/TaxSubtotal/
Grupo de información
FAT11 R TaxScheme 1.0 cac:TaxCategory/cac:TaxSch
específica sobre el tributo
eme
Rechazo:
Si
let $TaxInclusiveAmount := if
(boolean(//cbc:TaxInclusiveA Valor a Pagar de Factura es
mount)) then distinto de la Suma de Valor
//cbc:TaxInclusiveAmount else Bruto más tributos - Valor
FAU14 R PayableAmount
0.00, $SumTotalAllowance := del Descuento Total + Valor 1.0 …//cac:LegalMonetaryTotal/
if del Cargo Total - Valor del cbc:PayableAmount
(boolean(//cbc:AllowanceTota Anticipo Total
lAmount)) then
//cbc:AllowanceTotalAmount
else 0.00, $SumTotalCharge
:= if
(boolean(//cbc:ChargeTotalA
mount)) then
//cbc:ChargeTotalAmount else
0.00, $PrepaidAmount := if
(boolean(//cac:PrepaidPayme
nt/cbc:PaidAmount)) then
sum(//cac:PrepaidPayment/cb
c:PaidAmount) else 0.00,
$PayableAmount :=
$TaxInclusiveAmount -
$SumTotalAllowance +
$SumTotalCharge -
$PrepaidAmount return
round(number($PayableAmou
nt)) es distinto de
round(//cac:LegalMonetaryTo
tal/cbc:PayableAmount)
Sin Validación
Remítase a regla FAD15b ya
que al cumplirse dicha regla
Rechazo: Sí no es igual a verifica que este elemento …/cac:AllowanceCharge/cbc:B
FBE09 R @currencyID 1.0
cbc:DocumentCurrencyCode corresponder al mismo valor aseAmount/@currencyID
informado en
DocumentCurrencyCode
let $i :=
//cac:InvoiceLine/cac:TaxTotal/c Si el elemento NO es ../cac:TaxTotal/cac:TaxSubtotal
FAX11 N PerUnitAmount 1.0
informado o no existe. /cbc:PerUnitAmount
ac:TaxSubtotal/cac:TaxCategory
/cac:TaxScheme/cbc:ID, $j :=
//cac:InvoiceLine/cac:TaxTotal/c
ac:TaxSubtotal return every $k
in $i satisfies if ($k = '21' or $k =
'22' or $k = '23' or $k ='24') then
$j/cbc:PerUnitAmount !='' and
$j/cbc:PerUnitAmount/@curren
cyID !='' else true()
Remítase a regla FAD15b ya
que al cumplirse dicha regla ../cac:TaxTotal/cac:TaxSubtot
FAX12 R @currencyID Rechazo: Sí no es igual a verifica que este elemento 1.0 al/cbc:PerUnitAmount/@curr
cbc:DocumentCurrencyCode corresponder al mismo valor encyID
informado en
DocumentCurrencyCode
Grupo de información sobre el ../cac:TaxTotal/cac:TaxSubtotal
FAX13 R TaxCategory 1.0
tributo /cac:TaxCategory
N
Tarifa del tributo
En el caso de que el tributo es
un porcentaje del valor
tributable: informar la tarifa
(porcentaje) a ser aplicada a la
base imponible
Reporta una tarifa diferente ../cac:TaxTotal/cac:TaxSubtotal
FAX14 Percent El valor debe corresponder a los para uno de los tributos 1.0
/cac:TaxCategory/cbc:Percent
presentados en la tabla de enunciados en la tabla 6.3.9
tarifas 6.3.9, para los tributos
que figuren en dicha tabla.
Rechazo:
Si reporta una tarifa diferente
para uno de los tributos
enunciados en la tabla 6.3.9
../cac:TaxTotal/cac:TaxSubtotal
FAX15 R TaxScheme Grupo de información específica 1.0 /cac:TaxCategory/cac:TaxSche
sobre el tributo me
Rechazo:
Si existe más de un grupo
/Invoice/WhitHoldingTax con el
mismo valor en el elemento
/Invoice/WithholdingTaxTotal/T
axSubtotal/cac:TaxCategory/cac
:TaxScheme/cbc:ID
Suma de todos los elementos
../cac:WithholdingTaxTotal/TaxS
ubtotal/cbc:TaxAmount (R) Valor total de un tributo no
corresponde a la suma de todas
Rechazo:
las información ../cac:WithholdingTaxTotal/cbc:
FAY02 R TaxAmount si ../cac: WithholdingTaxTotal correspondientes a cada una 1.0
TaxAmount
/cbc:TaxAmount <> sumatoria de las tarifas informadas en
de todas las ocurrencias de este documento para este
../cac: tributo
WithholdingTaxTotal/TaxSubtot
al/cbc:TaxAmount
Obligatorio si …/cac:PowerOfAttorney/cac:Ag
FBA03 R AgentParty InformationContentProviderPar 1.0
entParty
ty es informado
…//ext:UBLExtensions/ext:U
BLExtension/ext:ExtensionC
Debe ser informado el literal No informado el literal
ontent/sts:DianExtensions/s
CAB16 N listAgencyName “United Nations Economic “United Nations Economic 1.0
ts:CreditNoteSource/cbc:Ide
Commission for Europe” Commission for Europe”
ntificationCode/@listAgency
Name
…//ext:UBLExtensions/ext:U
Debe ser informado el literal No informado el literal BLExtension/ext:ExtensionC
“urn:oasis:names:specificati “urn:oasis:names:specifica ontent/sts:DianExtensions/s
CAB17 N listSchemeURI 1.0
on:ubl:codelist:gc:CountryId tion:ubl:codelist:gc:Countr ts:CreditNoteSource/cbc:Ide
entificationCode-2.1” yIdentificationCode-2.1” ntificationCode/@listSchem
eURI
…//ext:UBLExtensions/ext:U
NIT del Prestador de BLExtension/ext:ExtensionC
NIT del Prestador de
CAB19a R ProviderID Servicios debe estar 1.0 ontent/sts:DianExtensions/s
Servicio no fue informado
informado ts:SoftwareProvider/sts:Pro
viderID
…//ext:UBLExtensions/ext:U
SoftwareSecurityCo Valida que se informe código No se encuentra el código BLExtension/ext:ExtensionC
CAB27a R 1.0
de de seguridad del software de seguridad del software ontent/sts:DianExtensions/s
ts:SoftwareSecurityCode
Huella del software que …//ext:UBLExtensions/ext:U
Huella no corresponde a
SoftwareSecurityCo autorizó la DIAN al Obligado BLExtension/ext:ExtensionC
CAB27b R un software autorizado 1.0
de a Facturar Electrónicamente ontent/sts:DianExtensions/s
para este OFE
o al Proveedor Tecnológico ts:SoftwareSecurityCode
…//ext:UBLExtensions/ext:U
BLExtension/ext:ExtensionC
Debe ser informado el literal No informado el literal
CAB28 N @schemeAgencyID 1.0 ontent/sts:DianExtensions/s
“195” “195”
ts:SoftwareSecurityCode/@
schemeAgencyID
…//ext:UBLExtensions/ext:U
Debe ser informado el literal No informado el literal
BLExtension/ext:ExtensionC
@schemeAgencyNa “CO, DIAN (Dirección de “CO, DIAN (Dirección de
CAB29 N 1.0 ontent/sts:DianExtensions/s
me Impuestos y Aduanas Impuestos y Aduanas
ts:SoftwareSecurityCode/@
Nacionales)” Nacionales)”
schemeAgencyName
AuthorizationProviderID …//ext:UBLExtensions/ext:U
Valida que se encuentre
no corresponde al NIT de BLExtension/ext:ExtensionC
AuthorizationProvid informado el NIT del
CAB31 R la DIAN (800197268) 1.0 ontent/sts:DianExtensions/s
erID Proveedor Autorizado
ts:AuthorizationProvider/sts
(800197268)
:AuthorizationProviderID
…//ext:UBLExtensions/ext:U
BLExtension/ext:ExtensionC
Debe ser informado el literal No informado el literal ontent/sts:DianExtensions/s
CAB32 N @schemeAgencyID 1.0
“195” “195” ts:AuthorizationProvider/sts
:AuthorizationProviderID/@
schemeAgencyID
…//ext:UBLExtensions/ext:U
Debe ser informado el literal No informado el literal BLExtension/ext:ExtensionC
@schemeAgencyNa “CO, DIAN (Dirección de “CO, DIAN (Dirección de ontent/sts:DianExtensions/s
CAB33 N 1.0
me Impuestos y Aduanas Impuestos y Aduanas ts:AuthorizationProvider/sts
Nacionales)” Nacionales)” :AuthorizationProviderID/@
schemeAgencyName
Si Proveedor Autorizado …//ext:UBLExtensions/ext:U
esta identificado por NIT BLExtension/ext:ExtensionC
(@schemeName=31), el DV El DV del NIT no esta
ontent/sts:DianExtensions/s
CAB34 R @schemeID del NIT debe ser informado informado o no es 1.0
ts:AuthorizationProvider/sts
en @schemeID. correcto
:AuthorizationProviderID/@
Nota:DV de DIAN es 4 schemeID
…//ext:UBLExtensions/ext:U
Colocar la defincion de este No esta informado la BLExtension/ext:ExtensionC
CAB36 R QRCode 1.0
Código información del Código QR ontent/sts:DianExtensions/s
ts:QRCode
UBLVersionID : no
Versión base de UBL debe /CreditNote/cbc:UBLVersion
CAD01 R UBLVersionID contiene el literal “UBL 1.0
ser “UBL 2.1” ID
2.1”
CustomizationID no indica
Indicador del tipo de /CreditNote/cbc:Customizati
CAD02 R CustomizationID un valor válido para el tipo 1.0
operación onID
de operación
Ambiente de autorización al
ProfileExecutionID no
que se destina este
indica un valor válido para
documento, debe contener /CreditNote/cbc:ProfileExec
CAD04 R ProfileExecutionID ambiente de destino del 1.0
el código correcto para utionID
documento (1=
indicar si es producción o
Producción ; 2= Prueba)
pruebas
Notificación si la fecha de
emisión es anterior a cinco
(5) días de la fecha La fecha de emisión fue
CAD09c N IssueDate calendario actual. anterior a 5 días de la 1.0 /CreditNote/cbc:IssueDate
fecha actual
/CreditNote/cbc:IssueDate
>= fecha calendario – 5 días
Se debe diligenciar
únicamente cuando la FE se
DiscrepancyRespons origina a partir de la CreditNote/cac:BillingRefere
CBF01 R 1.0
e nce
correcció o ajuste que se da
mediante un NC
Se debe diligenciar
únicamente cuando la FE se
CBI01 /CreditNote/cac:BillingRefer
R BillingReference origina a partir de la 1.0
ence
correcció o ajuste que se da
mediante una ND
CreditNote/cac:BillingRefere
InvoiceDocumentRe Grupo de información para
CBI02 R 1.0 nce/InvoiceDocumentRefer
ference nota débito relacionada
ence
CreditNote/cac:BillingRefere
Prefijo + Número de la nota ID de ND de referencia no
CBI03 R ID 1.0 nce/InvoiceDocumentRefer
débito relacionada relacionada
ence/cbc:ID
Se debe diligenciar
CreditNote/cac:BillingRefere
únicamente cuando la NC se CUFE de ND referenciada
CBI04 R UUID 1.0 nce/InvoiceDocumentRefer
origina a partir de la no existe
ence/cbc:UUID
correcció o ajuste a una FE
CreditNote/cac:BillingRefere
nce/InvoiceDocumentRefer
CBI05 N @schemeName Algoritmo del CUFE Algoritno no corresponde 1.0
ence/cbc:UUID/@schemeN
ame
Fecha de emisión de la
factura electronica Fecha FE referenciada CreditNote/cac:BillingRefere
CBI06 R IssueDate relacionada debe ser posterior a fecha de la 1.0 nce/InvoiceDocumentRefer
anterior a la fecha de la nota Nota Créditonota credito ence/cbc:IssueDate
creditoNota Crédito
Identifica el código de
actividad económica del
emisor. Debe informar el Códigos no informados o …//cac:AccountingSupplierP
IndustryClasification
CAJ04 N código según lista CIIU. Para no corresponden a los que 1.0 arty/cac:Party/cbc:IndustryC
Code
informar varios códigos, se estan en lista lasificationCode
separan por ;. Ejemplo
7020;5140
Valida estructura de
composición de Código
postal Estructura código no ../cac:Address/cbc:PostalZo
CAJ73 N PostalZone 1.0
Próximamente este valida ne
elemento será solicitado de
forma obligatoria.
…//cac:AccountingSupplierP
Valida que el DV del NIT del
El DV del NIT no es arty/cac:Party/cac:PartyTaxS
CAJ24b R @schemeID emisor informado sea 1.0
correcto cheme/cbc:CompanyID/@sc
correcto
hemeID
No fue informado el
conjunto formado por los
elementos: ID, CityName, …//cac:AccountingSupplierP
CAJ28 R RegistrationAddres Grupo de información para CountrySubentity,
1.0
arty/cac:Party/cac:Par
s informar dirección fiscal CountrySubentityCode, tyTaxScheme/cac:Reg
AddressLine, Line, istrationAddress
Country,
IdentificationCode
Valida estructura de
Estructura código no ../cac: RegistrationAddress
CAJ74 N PostalZone composición de Código 1.0
valida /cbc:PostalZone
postal
El nombre no corresponde
un valor valido de la lista
Si este es un grupo con
información con respeto a la
dirección del emisor de un
documento electrónico,
debe ser un Departamento El nombre no corresponde ../cac:RegistrationAddress/c
CAJ31 N CountrySubentity 1.0
de Colombia un valor valido de la lista bc:CountrySubentity
Si IdentificationCode es “CO”,
CountrySubentity debe
corresponder a uno de los
valores de la Columna Código
de 6.4.2
Notificación: Emisor es
responsable: debe existir la
información
correspondiente
Debe existir un grupo
…//cac:AccountingSupplierP No se encuentra el grupo …//cac:AccountingSupplierP
CAJ39 N TaxScheme arty/cac:Party/cac:PartyTaxS TaxScheme del emisor 1.0 arty/cac:Party/cac:PartyTaxS
cheme/cac:TaxScheme en el cheme/cac:TaxScheme
cual el elemento
…//cac:AccountingSupplierP
arty/cac:Party/cac:PartyTaxS
cheme/cac:TaxScheme/cb:ID
es 01
EL contenido de este
Valida el identificador
CAJ40 R ID elemento no corresponde 1.0 ../cac:TaxScheme/cbc:ID
tributario del emisor
a un contenido valido 01
El atributo
…//cac:AccountingSupplierP
(@schemeName=31), el DV DV del NIT del emisor no
CAJ47 R @schemeID 1.0 arty/cac:Party/cac:PartyLeg
del NIT debe ser informado informado
alEntity/@schemeID
en @schemeID
…//cac:AccountingSupplierP
No se encuentra el grupo
CorporateRegistrati Grupo de informaciónes de arty/cac:Party/cac:PartyLeg
CAJ49 R PartyLegalEntity del 1.0
onScheme registro del emisor alEntity/cac:CorporateRegist
emisor
rationScheme
Si se va a opera bajo
…//cac:AccountingSupplierP
modalidad de Consorcio o No se encuentra el grupo
arty/cac:Party/cac:PartyLeg
CAJ52 R ShareholderParty Unión temporal, entonces ShareholderParty del 1.0
alEntity/cac:ShareholderPar
este grupo de información emisor
ty
debe ser completada
Si se va a opera bajo
modalidad de Consorcio o /CreditNote/cac:Accounting
No se encuentra el grupo
Unión temporal, entonces SupplierParty/cac:Party/cac:
CAJ54 R Party ShareholderParty del 1.0
este Grupo de elemento PartyLegalEntity/cac:Shareh
emisor
pertime registrar la olderParty/cac:Party
información de un consorcio
…//cac:AccountingSupplierP
Grupo de informaciónes No se encuentra el grupo arty/cac:Party/cac:PartyLeg
CAJ55 R PartyTaxScheme tributarias de los PartyTaxScheme del 1.0 alEntity/cac:ShareholderPar
participantes del consorcio emisor ty/cac:Party/cac:PartyTaxSc
heme
…//cac:AccountingSupplierP
arty/cac:Party/cac:PartyLeg
Se debe informar el Nombre
No se informó el nombre o alEntity/cac:ShareholderPar
CAJ56 N RegistrationName o Razón Social de 1.0
razón social ty/cac:Party/cac:PartyTaxSc
participante de consorcio
heme/cbc:RegistrationNam
e
…//cac:AccountingSupplierP
ID del participante de ID del participante de arty/cac:Party/cac:PartyLeg
CAJ57 N CompanyID consorcio debe estar consorcio no estar 1.0 alEntity/cac:ShareholderPar
registrado en la DIAN registrado en la DIAN ty/cac:Party/cac:PartyTaxSc
heme/cbc:CompanyID
…//cac:AccountingSupplierP
arty/cac:Party/cac:PartyLeg
Debe ser informado el literal No informado el literal alEntity/cac:ShareholderPar
CAJ58 N @schemeAgencyID 1.0
“195” “195” ty/cac:Party/cac:PartyTaxSc
heme/cbc:CompanyID/@sc
hemeAgencyID
…//cac:AccountingSupplierP
Debe ser informado el literal No informado el literal arty/cac:Party/cac:PartyLeg
@schemeAgencyNa “CO, DIAN (Dirección de “CO, DIAN (Dirección de alEntity/cac:ShareholderPar
CAJ59 N 1.0
me Impuestos y Aduanas Impuestos y Aduanas ty/cac:Party/cac:PartyTaxSc
Nacionales)” Nacionales)” heme/cbc:CompanyID/@sc
hemeAgencyName
…//cac:AccountingSupplierP
Si participante de consorcio
arty/cac:Party/cac:PartyLeg
está identificado por NIT
DV del NIT del participante alEntity/cac:ShareholderPar
CAJ60 R @schemeID (@schemeName=31), el DV 1.0
no informado ty/cac:Party/cac:PartyTaxSc
del NIT debe ser informado
heme/cbc:CompanyID/@sc
en @schemeID
hemeID
No se encuentra el grupo
AccountingCustome Grupo con informaciónes /CreditNote/cac:Accounting
CAK01 R AccountingCustomerParty 1.0
rParty que definen el Adquirente CustomerParty
del adquirente
Este código no
CAK09 N ID Valida que código de corresponde a un valor 1.0 ../cac:Address/cbc:ID
municipio debe válido de la lista
Valida estructura de
composición de Código
postal Estructura código no ../cac:Address/cbc:PostalZo
CAK57 N PostalZone 1.0
Proximamente este valida ne
elemento será solicitado de
forma obligatoria.
Grupo de informaciónes
tributarias del Adquirente.
Rechazo:
Si el grupo no es informado
…//cac:AccountingCustomer
y si se cumple almenos una No se encuentra el grupo
CAK19 R PartyTaxScheme 1.0 Party/cac:Party/cac:PartyTa
de las siguientes situaciones: PartyTaxScheme
xScheme
Si el adquirente es persona
jurídica:
AdditionalAccountID
contiene “1”
Nombre registrado en el
RUT. Si el aqeuirente es
persona jurídica desea
también utilizar el nombre
comercial en el archivo de la
factura, debe utilizar el
elemento
…//cac:AccountingCustomer
Party/cac:Party/cac:PartyNa
me/cbc:Name
…//cac:AccountingCustomer
Nombre o razón social no Party/cac:Party/cac:PartyTa
CAK20 R RegistrationName Si el adquirente es 1.0
informado xScheme/cbc:RegistrationN
responsable debe informar ame
su NIT
CompanyID/@schemeName
es 31, el adquirente debe
informar el nombre
registrado en el RUT en el
elemento
…//cac:AccountingCustomer
Party/cac:Party/cac:PartyTax
Scheme/cbc:RegistrationNa
me
…//cac:AccountingCustomer
Id del adquirente debe ser ID de adquirente no
CAK21 R CompanyID 1.0 Party/cac:Party/cac:PartyTa
informado Informado
xScheme/cbc:CompanyID
…//cac:AccountingCustomer
Debe ser informado el literal No informado el literal Party/cac:Party/cac:PartyTa
CAK22 N @schemeAgencyID 1.0
“195” “195” xScheme/cbc:CompanyID/@
schemeAgencyID
Debe ser informado el literal No informado el literal …//cac:AccountingCustomer
@schemeAgencyNa “CO, DIAN (Dirección de “CO, DIAN (Dirección de Party/cac:Party/cac:PartyTa
CAK23 N 1.0
me Impuestos y Aduanas Impuestos y Aduanas xScheme/cbc:CompanyID/@
Nacionales)” Nacionales)” schemeAgencyName
…//cac:AccountingCustomer
Valida que el DV del NIT del
El DV del NIT no es Party/cac:Party/cac:PartyTa
CAK25 R @schemeName emisor informado sea 1.0
correcto xScheme/cbc:CompanyID/@
correcto
schemeName
Valida que la
Responsabilidad informada
por receptor se encuentren
dentro de la lista.
Para reportar varias
obligaciones /
responsabilidades, se deben
Responsabilidad …//cac:AccountingCustomer
registrar separando cada
CAK26 N TaxLevelCode informada para receptor 1.0 Party/cac:Party/cac:PartyTa
uno de los valores de la lista
no valido según lista xScheme/cbc:TaxLevelCode
con “;”. Ejemplo O-06;O-07;
ya así sucesivamente de
acuerdo a las
responsabilidades
necesarias.
Nota: Aplica solamente para
adquirentes Nacionales.
Valida la estructura de
composición de Código
postal Estructura código no ../cac:RegistratioAddress/cb
CAK58 N PostalZone 1.0
Nota: Proximamente este valida c:PostalZone
elemento será solicitado de
forma obligatoria.
Notificación: Si el adquirente
es responsable, el NIT debe
estar activo en el RUT
Si existe un grupo
…///cac:AccountingCustome
rParty/cac:Party/cac:PartyTa …//cac:AccountingCustomer
No se encuentra el grupo
CAK39 N TaxScheme xScheme/cac:TaxScheme 1.0 Party/cac:Party/cac:PartyTa
TaxScheme
xScheme/cac:TaxScheme
en el cual el elemento
…//cac:AccountingCustomer
Party/cac:Party/cac:PartyTax
Scheme/cbc:ID es 01 y
…//cac:AccountingCustomer
Party/cac:Party/cac:PartyLeg
EL contenido de este
Valida el identificador
CAK40 N ID elemento no corresponde 1.0 ../cac:TaxScheme/cbc:ID
tributario del receptor
a un contenido valido 01
CreditNote/cac:AccountingC
Correo electrónico de Correo electrónico no
CAK55 N ElectronicMail 1.0 ustomerParty/cac:Party/cac:
contacto informado
Contact/cbc:ElectronicMail
Grupo de información de la
TaxRepresentativeP …//cac:TaxRepresentativePa
CAL01 N Persona autorizada para 1.0
arty rty
descargar documentos
…//cac:TaxRepresentativePa
CAL02 N PartyIdentification 1.0
rty/cac:PartyIdentification
El atributo
…//cac:TaxRepresentativePa
(@schemeName=31), el DV DV del NIT del emisor no
CAL07 N @schemeID 1.0 rty/cac:PartyIdentification/c
del NIT debe ser informado informado
bc:ID/@schemeID
en @schemeID
Valida estructura de
composición de Código
postal Estructura código no ../cac:DeliveryAddress/cbc:
CAM68 N PostalZone 1.0
Nota: Proximamente este valida PostalZone
elemento será solicitado de
forma obligatoria.
…//cac:Delivery/cac:Delivery
Nombre comercial de la
CAM17 N Name 1.0 Party/cac:PartyName/cbc:N
empresa de transporte.
ame
Valida la estructura y
composición de Código
postal. Estructura código no ../cac:Address/cbc:PostalZo
CAM69 N PostalZone 1.0
Nota: Proximamente este valida ne
elemento será solicitado de
forma obligatoria.
Grupo de información
…//cac:Delivery/cac:Delivery
CAM30 R PartyTaxScheme tributarias del 1.0
Party/cac:PartyTaxScheme
transportador.
Si el transportador es …/cac:Delivery/cac:Delivery
Identificador del
CAM32 R CompanyID responsable debe informar 1.0 Party/cac:PartyTaxScheme/c
transportador.
NIT. bc:CompanyID
Si el contenido de este
elemento no corresponde a
un contenido de la columna
“Identificador”
../cac:Delivery/cac:DeliveryP
Nombre o Razón Social del
CAM54 N RegistrationName 1.0 arty/cac:PartyLegalEntity/cb
transportador.
c:RegistrationName
Si transportador es …/cac:Delivery/cac:Delivery
Identificador del
CAM55 R CompanyID responsable, NIT del 1.0 Party/cac:PartyLegalEntity/c
transportador.
transportador. bc:CompanyID
El atributo
DV del NIT del
(@schemeName=31), el DV ..//cbc:CompanyID/@schem
CAM58 R @schemeID transportador no 1.0
del NIT debe ser informado eID
informado.
en @schemeID
Condiciones de Entrega: Es
obligatorio cuando sea una /CreditNote/cac:DeliveryTer
LossRiskResponsibili
CBC04 R factura de exportación. 1.0 ms/cbc:LossRiskResponsibili
tyCode
tyCode
Ver lista de valores en 6.3.7
Sin validación.
Fecha de vencimiento de la
factura o fecha de
compromiso de pago.
Obligatorio si es venta a Venta a crédito sin
crédito. información de fecha en la /CreditNote/cac:PaymentM
CAN04 R PaymentDueDate 1.0
cual fue comprometido el eans/cbc:PaymentDueDate
Rechazo: pago.
Si PaymentMeans/ID = 2 y
PaymentDueDate no es
informado
/CreditNote/cac:PaymentM
CAN05 N PaymentID Identificador del pago 1.0
eans/cbc:PaymentID
Descuentos o cargos a nivel
de factura, es decir
descuentos o cargos que no
afectan las bases gravables. /CreditNote/AllowanceChar
CAQ01 N AllowanceCharge 1.0
ge
Los descuentos o cargos que
afectan bases gravables se
informan a nivel de ítem.
Es obligatorio informar si es
descuento a nivel de factura
internacional. De acuerdo a
los valores establecidos en la
tabla 6.3.8 Hay un descuento a nivel
AllowanceChargeRe …//AllowanceCharge/cbc:All
CAQ04 N de factura y no indicó el 1.0
asonCode Rechazo: si es descuento y owanceChargeReasonCode
código del descuento.
no se informa.
Notificación: si hay un
recargo y este elemento no
es informado.
Porcentaje a aplicar.
Porcentaje aplicado en
MultiplierFactorNu decimales. Porcentaje que aplica …//AllowanceCharge/cbc:M
CAQ06 N 1.0
meric superior al 100% ultiplierFactorNumeric
Notificación: si este
elemento > 100
Existe un grupo
Valida que exista un solo
/CreditNote/TaxTotal para
grupo con información de
uno de los impuestos s IVA
totales para un mismo
(01), INC (04), ICA (03) sin
tributo en la factura y que
CAS01b R TaxTotal que exista un grupo 1.0 /CreditNote/TaxTotal
los impuestos IVA (01), INC
/CreditNote/cac:CreditNot
(04), ICA (03) estén
eLine con información
registrados en una línea de
correspondientes al
la factura.
mismo impuesto.
Valor del tributo: producto (R) El valor del tributo que ../cac:TaxTotal/TaxSubtotal/
CAS07 R TaxAmount del porcentaje aplicado corresponde a una de las 1.0 cbc:TaxAmount
sobre la base imponible. tarifas correspondientes,
es diferente del producto
../cac:TaxTotal/TaxSubtotal/
Identificación de la unidad Unidad de medida no
CAS10 N unitCode 1.0 cbc:BaseUnitMeasure/@
de medida. informada.
unitCode
../cac:TaxTotal/TaxSubtotal/
Grupo de información
CAS15 R TaxScheme 1.0 cac:TaxCategory/cac:TaxSch
específica sobre el tributo.
eme
Sin Validación.
Remitase a regla FAD15b
ya que al cumplirse dicha
Rechazo: si no es igual a regla verifica que este …/AllowanceCharge/cbc:B
CBE09 R @currencyID 1.0
cbc:DocumentCurrencyCode elemento corresponda al aseAmount/@currencyID
mismo valor informado en
DocumentCurrencyCode
let $i :=
//cac:InvoiceLine/cac:TaxTot
al/cac:TaxSubtotal/cac:TaxC
ategory/cac:TaxScheme/cbc: Si el elemento NO es ../cac:TaxTotal/cac:TaxSubto
CAX11 N PerUnitAmount 1.0
ID, $j := infomado o no existe. tal/cbc:PerUnitAmount
//cac:InvoiceLine/cac:TaxTot
al/cac:TaxSubtotal return
every $k in $i satisfies if ($k
= '21' or $k = '22' or $k = '23'
or $k ='24') then
$j/cbc:PerUnitAmount !=''
and
$j/cbc:PerUnitAmount/@cur
rencyID !='' else true()
Remítase a la regla
FAD15b, ya que al
cumplirse dicha regla ../cac:TaxTotal/cac:TaxSub
CAX12 R @currencyID Rechazo: si no es igual a
verifica que este elemento 1.0 total/cbc:PerUnitAmount/
cbc:DocumentCurrencyCode @currencyID
corresponda al mismo
valor informado en
DocumentCurrencyCode
Grupo de información sobre ../cac:TaxTotal/TaxSubtotal/
CAX13 R TaxCategory 1.0
el tributo. cac:TaxCategory
Si el “Mandante” está
identificado por NIT …/cac:PartyIdentification/cb
CBA07 R @schemeID DV del NIT del emisor no 1.0
(@schemeName=31), el DV c:ID/@schemeID
informado.
del NIT debe ser informado
en @schemeID
Identificador del tipo de
documento de identidad
(@schemeName=31) del
Mandante, que indica que el
está identificado por NIT y El contenido de este
CBA08 R @schemeName por tanto el DV del NIT debe atributo no corresponde a 1.0 …/cac:PartyIdentification/cb
uno de los valores posibles c:ID/@schemeName
ser informado en atributo
@schemeID de las listas.
CBB04 R BaseQuantity La cantidad real sobre la cual No esta informada la 1.0 ../Price/cbc:BaseQuantity
el precio aplica. cantidad.
…//ext:UBLExtensions/ext:U
BLExtension/ext:ExtensionC
Debe ser informado el literal No informado el literal ontent/sts:DianExtensions/s
DAB16 N listAgencyName “United Nations Economic “United Nations Economic 1.0
ts:DebitNoteSource/cbc:Ide
Commission for Europe”. Commission for Europe”. ntificationCode/@listAgency
Name
…//ext:UBLExtensions/ext:U
No esta registrada la BLExtension/ext:ExtensionC
DAB36 Colocar la defincion de este 1.0
R QRCode información del Código ontent/sts:DianExtensions/s
código.
QR. ts:QRCode
El grupo de la dirección
deberá estar conformado No fue informado el
por al menos un conjunto de conjunto formado por los
elementos. elementos : ID, CityName,
CountrySubentity, ../cac:PhysicalLocation/cac:
DAJ08 R Address ID, CityName, 1.0
CountrySubentityCode, Address
CountrySubentity,
AddressLine, Line,
CountrySubentityCode,
Country,
AddressLine, Line, Country, IdentificationCode
IdentificationCode
El atributo …//cac:AccountingSupplierP
DAJ47 R @schemeID (@schemeName=31), el DV DV del NIT del emisor no 1.0 arty/cac:Party/cac:PartyLeg
del NIT debe ser informado informado. alEntity/@schemeID
en @schemeID
Identificador del tipo de
documento de identidad
(@schemeName=31) del El contenido de este …//cac:AccountingSupplierP
DAJ48 R @schemeName Emisor que indica que el atributo no corresponde a 1.0 arty/cac:Party/cac:PartyLeg
esta identificado por NIT y uno de los valores posibles alEntity/@schemeName
por tanto el DV del NIT debe de las listas.
ser informado en atributo
@schemeID
…//cac:AccountingSupplierP
CorporateRegistrati No se encuentra el grupo arty/cac:Party/cac:PartyLeg
DAJ49 R Grupo de información de 1.0
onScheme PartyLegalEntity del alEntity/cac:CorporateRegist
registro del emisor.
emisor. rationScheme
Prefijo de la facturación Si la numeración de la nota …//cac:AccountingSupplierP
usada para el punto de crédito usa prefijo, se arty/cac:Party/cac:PartyLeg
DAJ50 N ID 1.0
venta. debe informar el prefijo en alEntity/cac:CorporateRegist
este campo. rationScheme/cbc:ID
Se debe validar que exista
Valida que este informado el …//cac:AccountingSupplierP
número de matrícula arty/cac:Party/cac:PartyLeg
DAJ51 N Name Número de matrícula 1.0
mercantil (identificador de alEntity/cac:CorporateRegist
mercantil no informado
sucursal: punto de rationScheme/cbc:Name
facturación)
…//cac:AccountingSupplierP
Si se va a opera bajo No se encuentra el grupo arty/cac:Party/cac:Par
DAJ52 R ShareholderParty modalidad de Consorcio o ShareholderParty del 1.0
tyLegalEntity/cac:Shar
Unión temporal, entonces emisor eholderParty
…//cac:AccountingSupplierP
Debe ser informado el literal No informado el literal arty/cac:Party/cac:PartyLeg
@schemeAgencyNa “CO, DIAN (Dirección de “CO, DIAN (Dirección de alEntity/cac:ShareholderPar
DAJ59 N 1.0
me Impuestos y Aduanas Impuestos y Aduanas ty/cac:Party/cac:PartyTaxSc
Nacionales)” Nacionales)” heme/cbc:CompanyID/@sc
hemeAgencyName
Si el participante de …//cac:AccountingSupplierP
consorcio está identificado arty/cac:Party/cac:PartyLeg
DAJ60 R @schemeID por NIT DV del NIT del participante 1.0 alEntity/cac:ShareholderPar
(@schemeName=31), el DV no informado. ty/cac:Party/cac:PartyTaxSc
del NIT debe ser informado heme/cbc:CompanyID/@sc
en @schemeID hemeID
Si el adquirente es
responsable debe informar
su NIT:
CompanyID/@schemeName
es 31, el adquirente debe
informar el nombre
registrado en el RUT en el
elemento:
…//cac:AccountingCustomer
Party/cac:Party/cac:PartyTax
Scheme/cbc:RegistrationNa
me
…//cac:AccountingCustomer
El Id del adquirente debe ser ID de adquirente no
DAK21 R CompanyID 1.0 Party/cac:Party/cac:PartyTa
informado. Informado. xScheme/cbc:CompanyID
…//cac:AccountingCustomer
Party/cac:Party/cac:PartyTa
DAK22 N @schemeAgencyID Debe ser informado el literal No informado el literal 1.0 xScheme/cbc:CompanyID/@
“195”. “195”. schemeAgencyID
Obligatorio: si el adquiriente
es responsable.
EL contenido de este
DAK40 N ID Valida el identificador 1.0 ../cac:TaxScheme/cbc:ID
elemento no corresponde
tributario del receptor.
a un contenido valido 01.
Valida que el nombre del
identificador tributario del El contenido de este
DAK41 N Name receptor corresponda al elemento NO corresponde 1.0 ../cac:TaxScheme/cbc:Name
nombre “IVA” y el código al nombre y código valido.
(ID) es 01.
Obligatorio si el …//cac:AccountingCustomer
DAK42 N PartyLegalEntity Grupo de información legal 1.0 Party/cac:Party/cac:PartyLe
adquiriente es
del adquirente. galEntity
responsable.
…//cac:AccountingCustomer
El nombre o razón social del Party/cac:Party/cac:PartyLe
DAK43 N RegistrationName adquirente debe ser Nombre NO informado 1.0
galEntity/cbc:RegistrationNa
informado. me
…//cac:AccountingCustomer
DAK44 N CompanyID ID adquirente NO 1.0 Party/cac:Party/cac:PartyLe
ID del aquirente.
informado. galEntity /cbc:CompanyID
…//cac:AccountingCustomer
Debe ser informado el literal NO informado el literal Party/cac:Party/cac:PartyLe
@schemeAgencyNa “CO, DIAN (Dirección de “CO, DIAN (Dirección de
DAK46 N 1.0 galEntity
me Impuestos y Aduanas Impuestos y Aduanas /cbc:CompanyID/@scheme
Nacionales) Nacionales) AgencyName
…//cac:AccountingCustomer
El atributo Party/cac:Party/cac:PartyLe
DAK47 R @schemeID (@schemeName=31), el DV DV del NIT del emisor NO 1.0 galEntity
del NIT debe ser informado informado. /cbc:CompanyID/@schemeI
en @schemeID D
Identificador del tipo de
documento de identidad …//cac:AccountingCustomer
El contenido de este Party/cac:Party/cac:PartyLe
(@schemeName=31) del
DAK48 R @schemeName atributo no corresponde a 1.0 galEntity
Emisor, si está identificado
uno de los valores posibles /cbc:CompanyID/@scheme
por NIT, por tanto el DV del
de las “Listas”. Name
NIT debe ser informado en
atributo @schemeID
…//cac:AccountingCustomer
CorporateRegistrati Grupo de información de Party/cac:Party/cac:PartyLe
DAK49 N 1.0
onScheme registro del adquirente. galEntity/cac:CorporateRegi
strationScheme
…//cac:AccountingCustomer
Valida que este informado el Party/cac:Party/cac:PartyLe
DAK50 N Name Número de matrícula 1.0
número de matrícula galEntity/cac:CorporateRegi
mercantil NO informado.
mercantil. strationScheme/cbc:Name
Grupo de detalles con …/cac:AccountingCustomer
DAK51 N Contact información de contacto del 1.0
Party/cac:Party/cac:Contact
adquirente.
…/cac:AccountingCustomer
DAK55 N ElectronicMail Correo electrónico de Correo electrónico NO 1.0 Party/cac:Party/cac:Contact
contacto. informado. /cbc:ElectronicMail
El atributo …//cac:TaxRepresentativePa
DAL07 N @schemeID (@schemeName=31), el DV DV del NIT del emisor NO 1.0 rty/cac:PartyIdentification/c
del NIT debe ser informado informado bc:ID/@schemeID
en @schemeID
Identificador del tipo de
documento de identidad
El contenido de este …//cac:TaxRepresentativePa
(@schemeName=31) del
DAL06 N @schemeName atributo NO corresponde a 1.0 rty/cac:PartyIdentification/c
emisor, si está identificado
uno de los valores posibles bc:ID/@schemeName
por NIT, debe indicar el DV
de las listas.
del NIT en atributo
@schemeID
Grupo de información para
DAM01 N Delivery 1.0 …//cac:Delivery
entrega de bienes.
Fecha efectiva de salida de
…//cac:Delivery/cbc:ActualD
DAM02 N ActualDeliveryDate los bienes. 1.0
eliveryDate
Sin Validación.
Hora efectiva de salida de
…//cac:Delivery/cbc:ActualD
DAM03 N ActualDeliveryTime los bienes. 1.0
eliveryTime
Sin Validación.
Grupo con información
…//cac:Delivery/cac:Delivery
DAM04 N DeliveryAddress respeCto a la dirección de 1.0
Address
entrega.
Valida que el código del
Este código NO ../ cac:DeliveryAddress
DAM05 N ID municipio corresponda a un 1.0
corresponde a un valor /cbc:ID
valor registrado en la “Lista”
válido de la lista.
de municipios.
Si este es un grupo con
información con respecto a
la dirección del emisor de un
documento electrónico,
deberá ser un municipio de
Colombia.
El nombre NO ../cac:DeliveryAddress
DAM06 N CityName Si IdentificationCode es 1.0
corresponde un valor /cbc:CityName
“CO”, CountrySubentity
valido de la lista.
deberá corresponder a uno
de los valores de la columna
“Nombre Municipio” de la
lista de municipios.
Obligatorio: para Emisores y
Adquirentes Responsables.
Si IdentificationCode es
“CO”, CountrySubentity
Si participante de consorcio
está identificado por NIT …/cac:Delivery/cac:Delivery
DAM35 R @schemeID DV del NIT del participante 1.0 Party/cac:PartyTaxScheme/c
(@schemeName=31), el DV
NO informado. bc:CompanyID/@schemeID
del NIT debe ser informado
en @schemeID
Nombre registrado en el
RUT. Si el transportador es
persona jurídica y desea
utilizar el nombre ../cac:Delivery/cac:DeliveryP
DAM54 N RegistrationName Nombre o Razón Social del comercial en el archivo de 1.0 arty/cac:PartyLegalEntity/cb
transportador. la factura, debe utilizar el c:RegistrationName
elemento:
…//cac:AccountingSupplier
Party/cac:Party/cac:PartyN
ame/cbc:Name
Si transportador es …/cac:Delivery/cac:Delivery
DAM55 R CompanyID Identificador del 1.0 Party/cac:PartyLegalEntity/c
responsable, NIT del
transportador. bc:CompanyID
transportador.
…/cac:Delivery/cac:Delivery
CorporateRegistrati Grupo de información de Party/cac:PartyLegalEntity/c
DAM60 R 1.0
onScheme registro del transportador. ac:CorporateRegistrationSch
eme
Valida que este informado el …/cac:CorporateRegistratio
DAM61 N Name Número de matrícula 1.0
Número de matrícula nScheme/cbc:Name
mercantil NO informado.
mercantil.
Grupo para información /DebitNote/cac:DeliveryTer
DBD01 N DeliveryTerms 1.0
relacionada con la entrega. ms
/DebitNote/cac:DeliveryTer
DBD02 N ID Sin Validación. 1.0
ms/cbc:ID
Método de pago de costes
de transporte: se debe
utilizar para indicar cómo se
pagan los costos del
transporte (por ejemplo,
Portes Debidos, Portes
Pagados). Puede ser un /DebitNote/cac:DeliveryTer
DBD03 N SpecialTerms 1.0
texto libre que entiendan el ms/cbc:SpecialTerms
comprador y vendedor o
codificarlo en una lista, por
ejemplo:
http://www.unece.org/trade
/untdid/d01b/tred/tred4215
.htm
Condiciones de Entrega:
/DebitNote/cac:DeliveryTer
LossRiskResponsibili Obligatorio: cuando sea una
DBD04 R 1.0 ms/cbc:LossRiskResponsibili
tyCode factura de exportación.
tyCode
Ver lista de valores en 6.3.7
Opcional no usado por la
DIAN, las partes pueden
/DebitNote/cac:DeliveryTer
DBD05 N LossRisk definir un significado o 1.0
ms/cbc:LossRisk
simplemente omitirlo.
Sin validación.
Grupo de campos para
/DebitNote/cac:PaymentMe
DAN01 N PaymentMeans informaciónes relacionadas 1.0
ans
con el pago de la factura.
El método de pago debe
estar relacionado en la tabla
/DebitNote/cac:PaymentMe
DAN02 R ID del 6.3.4.1. Método de pago inválido. 1.0
ans/cbc:ID
Rechazo: si el valor de este
elemento NO corresponde a
Fecha de vencimiento de la
factura o fecha de
compromiso de pago.
Venta a crédito sin
Obligatorio: si es venta a
DAN04 R PaymentDueDate información de fecha en la 1.0 /DebitNote/cac:PaymentMe
crédito. ans/cbc:PaymentDueDate
cual se comprometió el
Rechazo: si pago.
PaymentMeans/ID = 2 y
PaymentDueDate no es
informado.
/DebitNote/cac:PaymentMe
DAN05 N PaymentID Identificador del pago. 1.0
ans/cbc:PaymentID
Descuentos o cargos a nivel
de factura, es decir
descuentos o cargos que no
/DebitNote/AllowanceCha
DAQ01 N AllowanceCharge afectan las bases gravables. 1.0
rge
Los descuentos o cargos que
afectan bases gravables se
informan a nivel de ítem.
DAQ02 N ID Sin validación. 1.0
Indica que el elemento es un
Cargo o un descuento. ChargeIndicator contiene …//AllowanceCharge/cbc:
DAQ03 R ChargeIndicator información diferente de 1.0
Rechazo: si este elemento ChargeIndicator
contiene una información “true” o “false”
diferente de “true” o “false”
Obligatorio de informar si es
descuento a nivel de factura
internacional. De acuerdo a Hay un descuento a nivel …//AllowanceCharge/cbc:
AllowanceChargeRe
DAQ04 N los valores establecidos en la de factura y NO indicó el 1.0 AllowanceChargeReasonC
asonCode
tabla 6.3.8 código del descuento. ode
Rechazo: si es descuento y
no se informa.
Existe un grupo
/CreditNote/TaxTotal
Valida que exista un solo
para uno de los
grupo con información de
impuestos s IVA (01), INC
totales para un mismo
(04), ICA (03) sin que
DAS01 tributo en la factura y que exista un grupo
R TaxTotal 1.0 /DebitNote/TaxTotal
b los impuestos IVA (01), INC /CreditNote/cac:CreditNo
(04), ICA (03) deben existir teLine con información
también en al menos una correspondiente al
línea de la factura. mismo impuesto.
round(//cbc:TaxExclusiveAm
ount) es distinto de
round(sum(//cac:DebitNoteL
ine/cac:TaxTotal/cac:TaxSub
total/cbc:TaxableAmount))
Remitase a regla FAD15b
ya que al cumplirse dicha …//cac:RequestedMonetar
DAU05 R @currencyID Rechazo: si no es igual a regla, se verifica que este 1.0 yTotal/cbc:TaxExclusiveAm
cbc:DocumentCurrencyCode elemento corresponda al ount/@currencyID
mismo valor informado en
DocumentCurrencyCode
…//cac:RequestedMonetary
DAU06 R TaxInclusiveAmount Total de Valor Bruto más Valor Bruto más tributos, 1.0 Total/cbc:TaxInclusiveAmou
tributos. es diferente a Valor Bruto nt
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
Sin Validación.
Remitase a regla FAD15b
ya que al cumplirse dicha
Rechazo: si no es igual a regla, se verifica que este 1.0 …/AllowanceCharge/cbc:B
DBE09 R @currencyID
cbc:DocumentCurrencyCode elemento corresponda al aseAmount/@currencyID
mismo valor informado en
DocumentCurrencyCode
let $i :=
//cac:DebitNoteLine/cac:Tax
Total/cac:TaxSubtotal/cac:Ta
xCategory/cac:TaxScheme/c Si el elemento NO es
../cac:TaxTotal/cac:TaxSubto
DAX11 N PerUnitAmount bc:ID, $j := infomado o NO existe. 1.0
tal/cbc:PerUnitAmount
//cac:DebitNoteLine/cac:Tax
Total/cac:TaxSubtotal return
every $k in $i satisfies if ($k
= '21' or $k = '22' or $k = '23'
or $k ='24') then
$j/cbc:PerUnitAmount !=''
and
$j/cbc:PerUnitAmount/@cur
rencyID !='' else true()
Si el mandante está
identificado por NIT …/cac:PartyIdentification/cb
DBA07 R @schemeID DV del NIT del emisor NO 1.0
(@schemeName=31), el DV c:ID/@schemeID
informado.
del NIT debe ser informado
en @schemeID
Identificador del tipo de
documento de identidad
(@schemeName=31) del
Mandante que indica que el
esta identificado por NIT y El contenido de este
DBA08 R @schemeName por tanto el DV del NIT debe atributo NO corresponde a 1.0 …/cac:PartyIdentification/cb
uno de los valores posibles c:ID/@schemeName
ser informado en atributo
@schemeID de las listas
DBB04 R BaseQuantity La cantidad real sobre la cual NO esta informada la 1.0 ../Price/cbc:BaseQuantity
el aplica el precio. cantidad.
…//ext:UBLExtensions/ext:UBL
El método de firma utilizado
SignatureMeth El método debe ser SHA 256 Extension/ext:ExtensionConten
DC04 R no corresponde a la política de 1
od o SHA 384 o SHA 512 t/ds:Signature/ds:SignedInfo/d
firma de la DIAN.
s:SignatureMethod
Debe contener la …//ext:UBLExtensions/ext:UBL
La información suministrada
información de la firma Extension/ext:ExtensionConten
DC05 R Reference no corresponde a la contendia 1
aplicada a todo el t/ds:Signature/ds:SignedInfo/d
en URI=””
documento. s:Reference
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
DC06 R Transforms El grupo debe existir una vez El grupo NO existe una vez 1
t/ds:Signature/ds:SignedInfo/d
s:Reference/ds:Transforms
El valor del elemento debe ser …//ext:UBLExtensions/ext:UBL
El contenido de la firma debe igual a Extension/ext:ExtensionConten
DC07 R TransForm estar embebido en el Algorithm=”http://www.w3.or 1 t/ds:Signature/ds:SignedInfo/d
documento. g/2000/09/xmldsig#enveloped s:Reference/ds:Transforms/ds:
-signature” TransForm
El algoritmo reportado debe
ser uno de los siguientes
valores:
RSAwithSHA256=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha256 …//ext:UBLExtensions/ext:UBL
El valor reportado no
Extension/ext:ExtensionConten
DC08 R DigestMethod corresponde a los definidos en 1
t/ds:Signature/ds:SignedInfo/d
la política de firma.
RSAwithSHA384=http://www s:Reference/ds:DigestMethod
.w3.org/2001/04/xmldsig-
more#rsa-sha384
RSAwithSHA512=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha512
El valor de hash generado a
El valor de hash generado a …//ext:UBLExtensions/ext:UBL
partir del uso del algoritmo
partir del uso del algoritmo Extension/ext:ExtensionConten
DC09 R DigestValue reportado en DigestMethod 1
reportado en DigestMethod no t/ds:Signature/ds:SignedInfo/d
en base 64 debe
corresponde. s:Reference/ds:DigestValue
corresponder.
Debe contener la …//ext:UBLExtensions/ext:UBL
La información suministrada
información correspondiente Extension/ext:ExtensionConten
DC10 R Reference no corresponde a la contendia 1
a la clave públic contenida en t/ds:Signature/ds:SignedInfo/d
en URI=”#{UUID}-KeyInfo”
el elemento KeyInfo s:Reference
RSAwithSHA256=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha256 …//ext:UBLExtensions/ext:UBL
El valor reportado NO
Extension/ext:ExtensionConten
DC11 R DigestMethod corresponde a los definidos en 1
t/ds:Signature/ds:SignedInfo/d
la política de firma
RSAwithSHA384=http://www s:Reference/ds:DigestMethod
.w3.org/2001/04/xmldsig-
more#rsa-sha384
RSAwithSHA512=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha512
El valor de hash generado a
El valor de hash generado a …//ext:UBLExtensions/ext:UBL
partir del uso del algoritmo
partir del uso del algoritmo Extension/ext:ExtensionConten
DC12 R DigestValue reportado en DigestMethod 1
reportado en DigestMethod no t/ds:Signature/ds:SignedInfo/d
en base 64 debe
corresponde. s:Reference/ds:DigestValue
corresponder.
La información suministrada …//ext:UBLExtensions/ext:UBL
Debe contener la
no corresponde a la contendia Extension/ext:ExtensionConten
DC13 R Reference información correspondiente 1
en URI=”#xmldsig-{UUID}- t/ds:Signature/ds:SignedInfo/d
al grupo SignedProperties.
signedprops” s:Reference
El algoritmo reportado debe
ser uno de los siguientes
valores:
RSAwithSHA256=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha256 …//ext:UBLExtensions/ext:UBL
El valor reportado no
Extension/ext:ExtensionConten
DC14 R DigestMethod corresponde a los definidos en 1
t/ds:Signature/ds:SignedInfo/d
RSAwithSHA384=http://www la política de firma. s:Reference/ds:DigestMethod
.w3.org/2001/04/xmldsig-
more#rsa-sha384
RSAwithSHA512=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha512
El valor de hash generado a
El valor de hash generado a …//ext:UBLExtensions/ext:UBL
partir del uso del algoritmo
partir del uso del algoritmo Extension/ext:ExtensionConten
DC15 R DigestValue reportado en DigestMethod 1
reportado en DigestMethod no t/ds:Signature/ds:SignedInfo/d
en base 64 debe
corresponde. s:Reference/ds:DigestValue
corresponder.
RSAwithSHA256=http://www …//ext:UBLExtensions/ext:UBL
.w3.org/2001/04/xmldsig- Extension/ext:ExtensionConten
more#rsa-sha256 t/ds:Signature/ds:Object/xades
El valor reportado NO
:QualifyingProperties/xades:Sig
DC28 R DigestMethod corresponde a los definidos en 1
nedProperties/xades:SignedSig
la política de firma
RSAwithSHA384=http://www natureProperties/xades:Signin
.w3.org/2001/04/xmldsig- gCertificate/xades:Cert/xades:
more#rsa-sha384 CertDigest/ds:DigestMethod
RSAwithSHA512=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha512
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
El valor de hash generado a
El valor de hash generado a t/ds:Signature/ds:Object/xades
partir del uso del algoritmo
partir del uso del algoritmo :QualifyingProperties/xades:Sig
DC29 R DigestValue reportado en DigestMethod 1
reportado en DigestMethod nedProperties/xades:SignedSig
en base 64 debe
NO corresponde. natureProperties/xades:Signin
corresponder.
gCertificate/xades:Cert/xades:
CertDigest/ds:DigestValue
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
:QualifyingProperties/xades:Sig
DC30 R IssuerSerial El grupo debe existir una vez. El grupo no se reportó una vez. 1
nedProperties/xades:SignedSig
natureProperties/xades:Signin
gCertificate/xades:Cert/xades:I
ssuerSerial
RSAwithSHA256=http://www …//ext:UBLExtensions/ext:UBL
.w3.org/2001/04/xmldsig- Extension/ext:ExtensionConten
more#rsa-sha256 t/ds:Signature/ds:Object/xades
El valor reportado NO
:QualifyingProperties/xades:Sig
DC35 R DigestMethod corresponde a los definidos en 1
nedProperties/xades:SignedSig
la política de firma.
RSAwithSHA384=http://www natureProperties/xades:Signin
.w3.org/2001/04/xmldsig- gCertificate/xades:Cert/xades:
more#rsa-sha384 CertDigest/ds:DigestMethod
RSAwithSHA512=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha512
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
RSAwithSHA256=http://www …//ext:UBLExtensions/ext:UBL
.w3.org/2001/04/xmldsig- Extension/ext:ExtensionConten
more#rsa-sha256 t/ds:Signature/ds:Object/xades
El valor reportado NO
:QualifyingProperties/xades:Sig
DC42 R DigestMethod corresponde a los definidos en 1
nedProperties/xades:SignedSig
la política de firma.
RSAwithSHA384=http://www natureProperties/xades:Signin
.w3.org/2001/04/xmldsig- gCertificate/xades:Cert/xades:
more#rsa-sha384 CertDigest/ds:DigestMethod
RSAwithSHA512=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha512
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
El valor de hash generado a
El valor de hash generado a t/ds:Signature/ds:Object/xades
partir del uso del algoritmo
partir del uso del algoritmo :QualifyingProperties/xades:Sig
DC43 R DigestValue reportado en DigestMethod 1
reportado en DigestMethod nedProperties/xades:SignedSig
en base 64 debe
NO corresponde. natureProperties/xades:Signin
corresponder.
gCertificate/xades:Cert/xades:
CertDigest/ds:DigestValue
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
El IssuerName y IssuerSerial El certificado NO pertenece a
t/ds:Signature/ds:Object/xades
deben pertenecer a una una de las Entidades
:QualifyingProperties/xades:Sig
DC44 R IssuerSerial entidad raíz certificadora certificadoras abiertas raíces 1
nedProperties/xades:SignedSig
abierta avalada por la ONAC avaladas por la ONAC en
natureProperties/xades:Signin
en Colombia. Colombia.
gCertificate/xades:Cert/xades:I
ssuerSerial
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
El IssuerName debe t/ds:Signature/ds:Object/xades
El valor NO corresponde a una
pertenecer a una entidad :QualifyingProperties/xades:Sig
X509IssuerNam entidad raíz certificadora
DC45 R raíz certificadora abierta 1 nedProperties/xades:SignedSig
e abierta avalada por la ONAC en
avalada por la ONAC en natureProperties/xades:Signin
Colombia.
Colombia. gCertificate/xades:Cert/xades:I
ssuerSerial/ds:X509IssuerNam
e
…//ext:UBLExtensions/ext:UBL
El SerialNumber debe Extension/ext:ExtensionConten
El valor NO corresponde a una
pertenecer a una entidad t/ds:Signature/ds:Object/xades
X509Serial entidad raíz certificadora
DC46 R raíz certificadora abierta 1 :QualifyingProperties/xades:Sig
Number abierta avalada por la ONAC en
avalada por la ONAC en nedProperties/xades:SignedSig
Colombia.
Colombia. natureProperties/xades:Signin
gCertificate/xades:Cert/xades:I
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
SignaturePolicy
DC47 R El grupo debe existir una vez. El grupo no se reportó una vez. 1 :QualifyingProperties/xades:Sig
Identifier
nedProperties/xades:SignedSig
natureProperties/xades:Signat
urePolicyIdentifier
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
SignaturePolicy :QualifyingProperties/xades:Sig
DC48 R El grupo debe existir una vez. El grupo no se reportó una vez. 1
Id nedProperties/xades:SignedSig
natureProperties/xades:Signat
urePolicyIdentifier/xades:Signa
turePolicyId
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
:QualifyingProperties/xades:Sig
DC49 R SigPolicyId El grupo debe existir una vez. El grupo no se reportó una vez. 1
nedProperties/xades:SignedSig
natureProperties/xades:Signat
urePolicyIdentifier/xades:Signa
turePolicyId/xades:SigPolicyId
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
El identificador NO :QualifyingProperties/xades:Sig
Debe incluir el identificador
DC50 R Identifier corresponde con el valor 1 nedProperties/xades:SignedSig
definido por la DIAN.
definido por la DIAN. natureProperties/xades:Signat
urePolicyIdentifier/xades:Signa
turePolicyId/xades:SigPolicyId/
xades:Identifier
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
:QualifyingProperties/xades:Sig
DC51 R SigPolicyHash El grupo debe existir una vez. El grupo no se reportó una vez. 1 nedProperties/xades:SignedSig
natureProperties/xades:Signat
urePolicyIdentifier/xades:Signa
turePolicyId/xades:SigPolicyHa
sh
…//ext:UBLExtensions/ext:UBL
RSAwithSHA256=http://www
Extension/ext:ExtensionConten
.w3.org/2001/04/xmldsig-
t/ds:Signature/ds:Object/xades
more#rsa-sha256
El valor reportado NO :QualifyingProperties/xades:Sig
DC52 R DigestMethod corresponde a los definidos en 1 nedProperties/xades:SignedSig
la política de firma. natureProperties/xades:Signat
RSAwithSHA384=http://www
urePolicyIdentifier/xades:Signa
.w3.org/2001/04/xmldsig-
turePolicyId/xades:SigPolicyHa
more#rsa-sha384
sh/ds:DigestMethod
RSAwithSHA512=http://www
.w3.org/2001/04/xmldsig-
more#rsa-sha512
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
El valor de hash generado a t/ds:Signature/ds:Object/xades
El valor de hash generado a
partir del uso del algoritmo :QualifyingProperties/xades:Sig
partir del uso del algoritmo
DC53 R DigestValue reportado en DigestMethod 1 nedProperties/xades:SignedSig
reportado en DigestMethod
en base 64 debe natureProperties/xades:Signat
NO corresponde.
corresponder. urePolicyIdentifier/xades:Signa
turePolicyId/xades:SigPolicyHa
sh/ds:DigestValue
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
DC54 R SignerRole El grupo debe existir una vez. El grupo no se reportó una vez. 1 :QualifyingProperties/xades:Sig
nedProperties/xades:SignedSig
natureProperties/xades:Signer
Role
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
DC55 R ClaimedRoles El grupo debe existir una vez. El grupo no se reportó una vez. 1 :QualifyingProperties/xades:Sig
nedProperties/xades:SignedSig
natureProperties/xades:Signer
Role/xades:ClaimedRoles
…//ext:UBLExtensions/ext:UBL
Extension/ext:ExtensionConten
t/ds:Signature/ds:Object/xades
El valor del rol debe ser El valor NO contiene uno de los :QualifyingProperties/xades:Sig
DC56 R ClaimedRole 1
thirdparty ó supplier. definidos. nedProperties/xades:SignedSig
natureProperties/xades:Signer
Role/xades:ClaimedRoles/xade
s:ClaimedRole
7.3.5. Firma
# Regla Y Mensaje V
Verificar si la firma está en el estándar (XMLDSig con formato
ZE01 R Certificado de la Firma con estándar inválido 1.0
XAdES-EPES)
Verificar si el valor de la Firma está válido (difiere del
ZE02 R Valor de la Firma inválido 1.0
calculado)
Identificación (ID) del emisor difiere de la Identificación ID del emisor difiere del proprietário del
ZE03 R 1.0
(proprietário) del Certificado Digital Certificado Digital
4
La guía puede ser descargada desde la dirección
https://www.colombiacompra.gov.co/sites/cce_public/files/cce_documents/cce_guia_codificacion_bienes.pdf.
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
Fuente: Guía para la codificación de bienes y servicios de acuerdo con el código estándar de productos y servicios de Naciones
Unidas, V.14.080, página 02, disponible en
https:/www.colombiacompra.gov.co/sites/cce_public/files/cce_documents/cce_guia_codificacion_bienes.pdf, acceso en 13 de
septiembre de 2018.
5
Acceso en 14 de septiembre de 2018
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
La etiqueta contendrá los elementos que constituyen la implementación del estándar técnico XAdES, i.e. XML Advanced
Electronic Signature asc; firma electrónica avanzada XML.
La política de firma suministra la información que sobre la firma digital con destino al control fiscal de la DIAN,
deberá aplicar el facturador electrónico como medida de ampliación del proceso de expedición de las facturas
electrónicas. Se advierte que los detalles de las técnicas informáticas de implementación no forman parte de esta
política. Únicamente se incluyen las referencias a los estándares que describen las especificaciones técnicas sobre la
implementación.
xPath
/Invoice/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/ds:Signature/ds:Object/xades:Qu
alifyingProperties/xades:SignedProperties/xades:SignedSignatureProperties/xades:SignaturePolicyIde
ntifier/xades:SignaturePolicyId/xades:SigPolicyHash/ds:DigestMethod/@Algorithm:=
Valor: 2 Opciones
http:/www.w3.org/2001/04/xmlenc#sha256 o http:/www.w3.org/2001/04/xmlenc#sha512
xPath:
/Invoice/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/ds:Signature/ds:Object/xades:Qu
alifyingProperties/xades:SignedProperties/xades:SignedSignatureProperties/xades:SignaturePolicyIde
ntifier/xades:SignaturePolicyId/xades:SigPolicyId/xades:Description
Valor: Política de firma para facturas electrónicas de la República de Colombia.
9.12. Firmante
El elemento xades:SignerRole contiene uno y sólo uno de los siguientes atributos:
• “supplier” cuando la firma de la factura la realiza el Obligado a Facturar.
• “third party” cuando la firma la realiza un Proveedor Tecnológico que en su caso, actué en su nombre.
<xades:SignerRole>supplier</xades:SignerRole>
Regla-1
Lapso de Validez del certificado digital Expedido ANTES de octubre 1 de 2016 T00:00:00, y hasta la terminación
de la vigencia
Descripción:
Estamos aplicando la reglamentación de la ONAC, URL
http:/onac.org.co/anexos/documentos/TRANSICIRCULARES/2016circulares/circular03-2016.pdf
Si el valor “Validity” del lapso de vigencia del certificado empezó antes de octubre 1 de 2016, la firma digital de la
factura electrónica puede:
Emplear certificados digitales que hayan sido generados con resúmenes criptográficos del tipo SHA1
Que el fragmento SignedInfo al que se le aplicó el canon fue la entrada para calcular el resumen criptográfico
que fue firmado digitalmente con << http:/www.w3.org/2000/09/xmldsig#rsa-sha1 >>
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
El no cumplimiento de estos valores deberá registrarse como una firma digital fallida para el documento
electrónico, motivada en:
Algoritmo de Firma del certificado digital (tipo SHA1) no previsto por la DIAN
Uso de la clave pública del certificado digital carece de los propósitos “firma digital” o “no repudio”.
Este motivo puede ser concurrente con los descritos en la celda anterior.
Regla-2
Descripción:
Estamos aplicando la reglamentación de la ONAC, URL
http:/onac.org.co/anexos/documentos/TRANSICIRCULARES/2016circulares/circular03-2016.pdf
Si el valor “Validity” del lapso de vigencia del certificado empezó después del 30 de septiembre de 2016 T23:59:59,
la firma digital de la factura electrónica tiene que:
Emplear certificados digitales que hayan sido generados con resúmenes criptográficos del tipo SHA256;
existen otras opciones como aparece en la lista << Signature Algorithm >>
Que el resumen criptográfico que se aplicó al fragmento que fue firmado digitalmente corresponda con el <<
SignatureMethod >> empleado
El no cumplimiento de estos valores deberá registrarse como una firma digital fallida para el documento
electrónico, motivada en:
Algoritmo de Firma del certificado digital (tipo SHA2) no previsto por la DIAN
Uso de la clave pública del certificado digital carece de los propósitos “firma digital” o “no repudio”. Vea
Anexo 2.
Este motivo puede ser concurrente con los descritos en la celda anterior.
Regla-3
Algoritmo de firma digital aplicado Certificado digital expedido después de 30 de septiembre de 2016 T23:59:59
a la factura electrónica dentro del
documento electrónico UBL
/Invoice/ext:UBLExtensions/ext:UBL Algoritmo=RSAwithSHA256
Extension[X]/ext:ExtensionContent/ Use: http:/www.w3.org/2001/04/xmldsig-more#rsa-sha256
ds:Signature/ds:SignedInfo/ds:Sign
atureMethod/@Algorithm= Algoritmo=RSAwithSHA384
Use: http:/www.w3.org/2001/04/xmldsig-more#rsa-sha384
Regla-4
Algoritmos de resumen criptográfico Certificado digital expedido después de 30 de septiembre de 2016
aplicado a los fragmentos de la factura T23:59:59
electrónica que se incluyen dentro del
fragmento que se firma digitalmente
Descripción:
Estamos aplicando la reglamentación de la ONAC, URL
http:/onac.org.co/anexos/documentos/TRANSICIRCULARES/2016circulares/circular03-2016.pdf
El algoritmo de resumen criptográfico utilizado para los fragmentos que intervienen y forman parte del elemento
que se firma digitalmente no tiene correspondencia con el algoritmo de firma digital de la Regla-3.
Si el valor del ../ds:DigestMethod/@Algorithm no corresponde con los valores paramétricos, entonces deberá
registrarse como una firma digital fallida para el documento electrónico, motivada en:
Empleó un algoritmo de resumen criptográfico no previsto por la DIAN. Vea Anexo 2.
10.1.1.2. Ejemplos
10.1.1.4. XPath
De forma no ambigua se especifican las expresiones XPath que deben aplicarse a una factura electrónica
para obtener la información requerida y permitir la generación del CUFE.
Definición CUFE de una factura de venta.
NumFac /Invoice/cbc:ID
FecFac /Invoice/cbc:IssueDate/>
Hora Factura /Invoice/cbc:IssueTime/>
10.1.1.6. XPath
De forma no ambigua se especifican las expresiones XPath que deben aplicarse a una factura electrónica para
obtener la información requerida y permitir la generación del CUFE.
Definición identificadora de la transcripción de una factura de venta de exportación.
NumFac /Invoice/cbc:ID
FecFac /Invoice/cbc:IssueDate/>
Hora Factura /Invoice/cbc:IssueTime/>
Valor Bruto /Invoice/cac:LegalMonetaryTotal/cbc:LineExtensionAmount/>
CodImp1 /Invoice/cacTaxTotal[x]/ cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 01
Valor Impuesto 1 /Invoice/cac:TaxTotal[x]/cbc:TaxAmount
CodImp2 /Invoice/cac:TaxTotal[y]/ cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 04
Valor Impuesto 2 /Invoice/cac:TaxTotal[y]/cbc:TaxAmount
CodImp3 /Invoice/cac:TaxTotal[z]/ cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 03
Valor Impuesto 3 /Invoice/cac:TaxTotal[z]/cbc:TaxAmount
Valor Total a Pagar /Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount/>
NitOFE /Invoice/ cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID/>
NumAdq /Invoice/ cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID/>
ClTec no está en el XML
Tipo de Ambiente /Invoice/cbc:ProfileExecutionID
Ejemplo: CUDE de la transcripción de datos de una factura de venta por contingencia: SHA384
/Invoice/cbc:InvoiceTypeCode=03
NumFac 8110007871
FecFac 2019-02-20
HorFac 16:46:55-05:00
ValFac 235.28
CodImp1 01
CodImp2 04
ValImp2 0.00
CodImp3 03
ValImp3 8.28
ValTol 262.56
NitOFE 900373076
NumAdq 8355990
Software-PIN 12345
TipoAmbiente 2
Composición del
81100078712019-02-2016:46:55-05:00235.280119.00040.00038.28262.569003730768355990123452
CUFE
955327eb55f8bdf16d069358a063d87e1577a292cb088ec186ed60bbc38e750b7b3980659b278ead789b95f9c51
CUFE.SHA-384 a9ef7
Destino: /fe:Invoice/cbc:UUID
Ref: http:/www.sha1-online.com/
Nota-1: las verificaciones sobre la autorización del rango de numeración se realizan respecto a la numeración
de contingencia siempre y cuando el «/Invoice/cbc:InvoiceTypeCode=03»
Nota-2: las transcripciones de datos de una factura de contingencia no utilizan la Clave técnica durante el
cálculo del CUDE, para el reemplazo del mismo se utiliza el PIN del software el cual se indica en el catalogo del
participante y este se registra en el elemento /fe:Invoice/cbc:UUID, debido a que a este rango autorizado no se
le asigna una clave técnica.
10.1.2.3. XPath
De forma no ambigua se especifican las expresiones XPath que deben aplicarse a la transcripción de una factura de
contingencia para obtener la información requerida y permitir la generación del identificador.
Definición del identificador de una factura de contingencia.
NumFac /Invoice/cbc:ID
FecFac / Invoice/cbc:IssueDate/>
HorFac / Invoice/cbc:IssueTime/>
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
NumFac /CreditNote/cbc:ID
FecFac /CreditNote/cbc:IssueDate/>
HorFac /CreditNote/cbc:IssueTime/>
ValFac /CreditNote/cac:LegalMonetaryTotal/cbc:LineExtensionAmount
CodImp1 /CreditNote/cac:TaxTotal[x]/cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 01
ValImp1 /CreditNote/cac:TaxTotal[x]/cbc:TaxAmount
CodImp2 /CreditNote /cac:TaxTotal[y]/ cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 04
ValImp2 /CreditNote /cac:TaxTotal[y]/cbc:TaxAmount
CodImp3 /CreditNote /cac:TaxTotal[z]/ cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 03
ValImp3 /CreditNote /cac:TaxTotal[z]/cbc:TaxAmount
ValTol /CreditNote /cac:LegalMonetaryTotal/cbc:PayableAmount
NitOFE /CreditNote/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID/>
NumAdq /CreditNote/cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID/>
Software-PIN No se encuentra en el XML
TipoAmb /CreditNote/dcc:ProfileExecutionID
10.1.2.7. xpath
De forma no ambigua se especifican las expresiones XPath que deben aplicarse a una factura electrónica para
obtener la información requerida y permitir la generación del CUDE.
Definición CUDE de una NotaDebito
NumFac /DebitNote/cbc:ID
FecFac /DebitNote/cbc:IssueDate/>
HorFac /DebitNote/cbc:IssueTime/>
ValFac /DebitNote/cac:RequestedMonetaryTotal/cbc:LineExtensionAmount
CodImp1 /DebitNote/cac:TaxTotal[x]/cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 01
ValImp1 /DebitNote/cac:TaxTotal[x]/cbc:TaxAmount
CodImp2 /DebitNote/cac:TaxTotal[y]/cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 04
ValImp2 /DebitNote/cac:TaxTotal[y]/cbc:TaxAmount
CodImp3 /DebitNote/cac:TaxTotal[z]/cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:ID = 03
ValImp3 /DebitNote/cac:TaxTotal[z]/cbc:TaxAmount
ValTol /DebitNote/cac:RequestedMonetaryTotal/cbc:PayableAmount
NitOFE /DebitNote/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID
NumAdq /DebitNote/cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID
Software-PIN No se encuentra en el XML
TipoAmbiente /DebitNote/cbc:ProfileExecutionID
10.1.2.8. Generación del CUDE para el Application Response: elaborado y remitido por participante || adquirente
con “software PIN”
Con el propósito de evitar utilizaciones indebidas de este IDENTIFICADOR Universal en documentos electrónicos
que serán sometidos a la Validación Previa que realizará el sistema de factura electrónica de la DIAN, sugiero la
inclusión del valor del “software PIN” en la última posición de la cadena; este “software PIN” fue asignado por el
Num_DE 1
10.1.2.8.2. XPath
De forma no ambigua se especifican las expresiones XPath que deben aplicarse a un documento
electrónico para obtener la información requerida y permitir la generación del CUDE.
Definición CUDE de un documento electrónico.
Campo Xpath
Num_DE /ApplicationResponse/cbc:ID
Fec_Emi /ApplicationResponse/cbc:IssueDate
Hor_Emi /ApplicationResponse/cbc:IssueTime
CompanyID /ApplicationResponse/cac:SenderParty/cac:PartyTaxScheme/cbc:CompanyID
CompanyID /ApplicationResponse/cac:ReceiverParty/cac:PartyTaxScheme/cbc:CompanyID
ID /ApplicationResponse/cac:DocumentResponse/cac:cac:DocumentReference/cbc:ID
10.1.2.8.4. XPath
De forma no ambigua se especifican las expresiones XPath que deben aplicarse a un documento
electrónico para obtener la información requerida y permitir la generación del CUDE.
Definición CUDE de un documento electrónico.
Num_DE /ApplicationResponse/cbc:ID
Fec_Emi /ApplicationResponse/cbc:IssueDate
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
CompanyID /ApplicationResponse/cac:SenderParty/cac:PartyTaxScheme/cbc:CompanyID
CompanyID /ApplicationResponse/cac:ReceiverParty/cac:PartyTaxScheme/cbc:CompanyID
ID /ApplicationResponse/cac:DocumentResponse/cac:cac:DocumentReference/cbc:ID
DocumentTypeC /ApplicationResponse/cac:DocumentResponse/cac:cac:DocumentReference/cbc:Doc
ode umentTypeCode
Application Attached
PARTICIPANTES: Invoice CreditNote DebitNote
Response Document
Facturadores Electrónicos SI SI SI SI SI
Proveedores Tecnológicos SI SI SI SI SI
Adquirentes & SI SI SI SI SI
Facturadores Electrónicos
Adquirentes NO
SI
ELECTRÖNICOS
Examine la Autorización expedida por la DIAN que definió el Rango de Facturación; examine el numeral 11.17 y el
archivo wsdl que lo acompaña. En el archivo response los rangos vienen acompañado de un identificador denominado
clave técnica: ese es el valor que estamos necesitando.
Asegúrese de que el prefijo de dicho rango fue asociado al NIT del proveedor de la versión de software i.e. el OFE o
el PT según el caso— de acuerdo con lo registrado en los servicios del sistema de facturación electrónica de la DIAN;
de esta manera cuando el OFE o el PT entreguen a la DIAN la factura expedida, el mecanismo de control fiscal validará
que este documento electrónico fue generado por un sistema de software activo en el sistema de facturación
electrónica a nombre del OFE o del PT que expide la factura, y podrá recuperar el rango autorizado y la clave técnica
asignada. Con estos últimos el mecanismo de control fiscal validará que la factura está consumiendo elementos del
rango, y podrá aplicar el algoritmo de cálculo del CUFE.
ADVERTENCIA: Cuando un Facturador Electrónico haya agotado el rango de numeración que le fue asignado y deba
solicitar la autorización de un nuevo rango de numeración para facturas electrónicas que sea la continuación de un
rango ya autorizado, se debe tener en cuenta, que el SIE Rangos de Numeración cuando haga la consulta del web
Service, le entregará una nueva CLAVE TÉCNICA, esta CLAVE TÉCNICA, es diferente a la del anterior rango.
Detalle XPath
NumFac: /Invoice/cbc:ID
[NUMERO_FACTURA]
FecFac: [FECHA_FACTURA] /Invoice/cbc:IssueDate
HorFac: /Invoice/cbc:IssueTime
[HORA_FACTURA(con
GMT)]
NitFac: [NIT FACTURADOR] /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyI
D
DocAdq: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:Compan
[NUMERO_ID_ADQUIRENT yID
E]
ValTolFac: /Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount
[VALOR_TOTAL_FACTURA
CUFE /Invoice/cbc:UUID
NumFac: [NUMERO_FACTURA]
FecFac: [FECHA_FACTURA]
HorFac: [HORA_FACTURA(con GMT)]
NitFac: [NIT FACTURADOR] sin puntos ni guiones
DocAdq: [NUMERO_ID_ADQUIRENTE] sin puntos ni guiones
Ejemplo:
Teniendo en cuenta los datos de entrada, se presenta el código QR que se incluye en la representación gráfica de la
factura electrónica:
NumFac: 323200000129
FecFac: 2019-16-01
HorFac: 10:53:10-05:00
NitFac: 700085371
DocAdq: 800199436
ValFac: 1500000.00
ValIva: 285000.00
ValOtroIm: 0.00
ValTolFac: 1785000.00
CUFE: e5bac48e354bc907bccff0ea7d45fbf784f0a8e7243b58337361e1fbd430489d
Tamaño
El tamaño mínimo que debe tener el código bidimensional QR es de 2cm para facilitar la lectura por los diferentes
dispositivos.
La Representación Gráfica
La representación gráfica puede ser diseñada de acuerdo con las necesidades del OFE; como la generación está en
formato XML, entonces cualquier herramienta informática de conversión de este formato a .pdf, .docx, u otros
formatos digitales será suficiente para cumplir lo exigido en el parágrafo 1 del artículo 3 del Decreto 2242-2015. El
requisito que debe cumplir es la inclusión del código bidimensional QR tal como se precisa arriba.
Cada servicio se encuentra respaldado por un metodo Web específico. El modelo de comunicación e
interoperabilidad siempre iniciará en el sistema del contribuyente (HFE), por medio del consumo del método
correspondiente para validar los documentos ante la DIAN.
Metodos Asíncronos:
La llamada (Request) del servidor del cliente a los servicios síncronos es procesado de forma inmediata por el
servidor de DIAN y la respuesta (Response) se realiza en la misma conexión.
Un mensaje con un recibo que confirma que el archivo remitido ha superado las primeras
validaciones y se ha recepcionado, y
Los Facturadores (emisores), Proveedores Tecnológicos/Proveedores Autorizados, realizarán el envío de sus DE,
utilizando los Servicios Web que la DIAN a puesto a disposición de manera de operar máquina a máquina sin
intervención del usuario.
Para ello el sistema de los participantes, deberán tener las siguientes consideraciones:
El modelo de comunicación sigue el estándar de servicios web definido por el WS-Security 1.0 Oasis, con
autenticación X.509 Certificate Token Profile 1.1
El intercambio de mensajes entre los Servicios Web de la DIAN y el sistema del Habilitado para Facturar
Electrónicamente (HFE) o el Proveedor Tecnológico (PT) / Autorizado (PA) será realizado mediante el estándar SOAP
versión 1.2, con intercambio de mensajes XML en el estándar Style/Encoding: Document/Literal.
La llamada de cada uno de los servicios web es realizada con el envío de un mensaje XML a través del campo
<soap:Body/>
La información de control de las llamadas a los Servicios Web se almacena en el elemento Header del SOAP y su fin
es identificar y autenticar por medio del certificado digital utilizado.
Cada servicio se encuentra respaldado por un Método Web específico. El modelo de comunicación e
interoperabilidad siempre iniciará en el sistema del contribuyente (HFE), por medio del consumo del servicio
correspondiente de un PA, el cual posteriormente, consumirá los servicios de la DIAN para validar los documentos
ante esta.
El servicio puede recibir un ZIP con uno o más (Máximo 50) documentos electrónicos firmados digitalmente, en
formato UBL y construido según el esquema detallado en este Manual Técnico.
Se envían los parámetros de consumo en la estructura XML definida para este método.
Se genera un TrackId al ZIP.
Se descomprime ZIP y se validan los siguientes elementos del ZIP:
o Archivo ZIP no este vacío.
o Archivo ZIP no esté corrupto
o Que no sean más de 50 UBLs en el ZIP.
o No den error de lectura los archivos UBLs.
Validaciones iniciales:
Ejemplo de Petición
<soap:Envelope xmlns:soap="http:/www.w3.org/2003/05/soap-envelope" xmlns:wcf="http:/wcf.dian.colombia">
<soap:Header/>
<soap:Body>
<wcf:SendBillAsync>
<wcf:fileName>Test</wcf:fileName>
<wcf:contentFile>cid:179956799470</wcf:contentFile>
</wcf:SendBillAsync>
</soap:Body>
</soap:Envelope>
El servicio puede recibir un ZIP con uno o todos los documentos asociados al Set de Prueba.
Se envían los parámetros de consumo en la estructura XML definida para este método.
Se generara un TrackId al ZIP.
Se descomprime ZIP y se validan los siguientes elementos del ZIP:
o Archivo ZIP no este vacío.
o Archivo ZIP no esté corrupto
o No den error de lectura los archivos UBLs.
Validaciones iniciales:
Ejemplo de Petición
<soap:Envelope xmlns:soap="http:/www.w3.org/2003/05/soap-envelope" xmlns:wcf="http:/wcf.dian.colombia">
<soap:Header/>
<soap:Body>
<wcf:SendBillAsync>
<wcf:fileName>Test</wcf:fileName>
<wcf:contentFile>cid:179956799470</wcf:contentFile>
</wcf:SendBillAsync>
El servicio puede recibir un ZIP con un solo documento electrónico firmado digitalmente, en formato UBL
y construido según el esquema detallado en este Manual Técnico.
Se envían los parámetros de consumo en la estructura XML definida para este método.
Se genera un TrackId al UBL (en general es el CUFE del documento, en caso que no contenga
CUFE se le asignara un TracId)
Se descomprime ZIP y se validan los siguientes elementos del ZIP:
o Archivo ZIP no este vacío.
o Archivo ZIP no esté corrupto
o Que no sean más de 1 UBL en el ZIP.
o No den error de lectura del archivos UBL.
Validaciones iniciales:
Ejemplo de Petición
<soap:Envelope xmlns:soap="http:/www.w3.org/2003/05/soap-envelope" xmlns:wcf="http:/wcf.dian.colombia">
<soap:Header/>
<soap:Body>
<wcf:SendBillAsync>
<wcf:fileName>Test</wcf:fileName>
<wcf:contentFile>cid:179956799470</wcf:contentFile>
</wcf:SendBillAsync>
</soap:Body>
</soap:Envelope>
00 = Procesado Corectamente
R StatusCode 66= NSU no encontrado string 1.0
90 = TrackId no encontrado
99 = validaciones contienen errores en
campos mandatorios
00 = Procesado Corectamente
R StatusDescription 66= NSU no encontrado string 1.0
90 = TrackId no encontrado
99 = validaciones contienen errores en
campos mandatorios
Entrega una descripción del error de
O StatusMessage string 1.0
cada una de la vaidaciones iniciales . Si
no hay errores no entrega descripción
Entrega el UBL correspondiente al
Arreglo de
R XmlBase64Bytes ApplicationResponse con la respuesta 1.0
Bytes
oficial del la DIAN en forma
estructurada en base64
Arreglo de
O XmlBytes 1.0
Bytes
El servicio puede recibir un ZIP con uno o más (Máximo 50) AttachedDocument con los archivos a
validar (DE+AR-Validación)
Se envían los parámetros de consumo en la estructura XML definida para este método.
Se genera un TrackId al ZIP.
Se descomprime ZIP y se validan los siguientes elementos del ZIP:
o Archivo ZIP no este vacío.
o Archivos ZIP no este corrupto
o Que no sean más de 50 AttachedDocument en el ZIP.
o Se verifica que los AttachedDocument contengan (DE+AR-Validación)
o Valida que el AR corresponda al DE que trae asociado.
o No den error de lectura los archivos UBLs.
Validaciones iniciales:
Ejemplo
<soap:Envelope xmlns:soap="http:/www.w3.org/2003/05/soap-envelope" xmlns:wcf="http:/wcf.dian.colombia">
<soap:Header><wsse:Security xmlns:wsse="http:/docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http:/docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"/></soap:Header>
<soap:Body>
<wcf:GetStatus
<wcf:trackId>8763f78ccd241063615affd49580564df2986c07</wcf:trackId>
</wcf:GetStatus>
</soap:Body>
</soap:Envelope>
<b:XmlBase64Bytes>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiIHN0YW5kYWxvbmU9Im5vIj8+PGRlOkFwcGxpY2F0aW9u....==</b:X
mlBase64Bytes>
<b:XmlBytes i:nil="true"/>
<b:XmlDocumentKey>00636660a1b4e22bb2f70c19d4d2fd99e498902b</b:XmlDocumentKey>
<b:XmlFileName>11a65c09-a4ba-4990-9491-3a9d47521aaa</b:XmlFileName>
</GetStatusResult>
</GetStatusResponse>
</s:Body>
</s:Envelope>
StatusCode
R 00 = Procesado Corectamente 1-3 1.0
66= NSU no encontrado
90 = TrackId no encontrado
99 = validaciones contienen errores
en campos mandatorios
La respuesta . ApplicationResponse
con la información del evento
correspondiente. En Base54 ( puede Arreglo de
XmlBase64Bytes 1.0
ser configurado para que esta bytes
información se entregue en un
arreglo de byte
Arreglo de
R XmlBytes Corresponde al valor parámetro: true 1 1.0
bytes
Ejemplo
<soap:Envelope xmlns:soap="http:/www.w3.org/2003/05/soap-envelope" xmlns:wcf="http:/wcf.dian.colombia">
<soap:Header><wsse:Security xmlns:wsse="http:/docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http:/docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"/></soap:Header>
<soap:Body>
<wcf:GetStatus
<wcf:trackId>8763f78ccd241063615affd49580564df2986c07</wcf:trackId>
</wcf:GetStatus>
</soap:Body>
</soap:Envelope>
Ejemplo:
<s:Envelope xmlns:s="http:/www.w3.org/2003/05/soap-envelope" xmlns:a="http:/www.w3.org/2005/08/addressing" xmlns:u="http:/docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<a:Action s:mustUnderstand="1">http:/wcf.dian.colombia/IWcfDianCustomerServices/GetStatusZipResponse</a:Action>
<o:Security s:mustUnderstand="1" xmlns:o="http:/docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2019-02-19T23:55:24.867Z</u:Created>
<u:Expires>2019-02-20T00:00:24.867Z</u:Expires>
</u:Timestamp>
</o:Security>
</s:Header>
<s:Body>
<GetStatusZipResponse xmlns="http:/wcf.dian.colombia">
<GetStatusZipResult xmlns:b="http:/schemas.datacontract.org/2004/07/DianResponse" xmlns:i="http:/www.w3.org/2001/XMLSchema-
instance">
<b:DianResponse>
<b:ErrorMessage xmlns:c="http:/schemas.microsoft.com/2003/10/Serialization/Arrays">
<c:string>Regla: AA09 Valor del CUFE no está calculado correctamente.</c:string>
<c:string>Regla: AA08d Número de factura debe estar contenido en el rango de numeración otorgado</c:string>
<c:string>Regla: ZB01 Fallo en el Schema XML del archivo - The XmlSchemaSet on the document is either null or has no schemas in it.
Provide schema information before calling Validate. -</c:string>
<c:string>Regla: AC38b Documento fue enviado para el ambiente errado (producción o pruebas)</c:string>
</b:ErrorMessage>
<b:IsValid>false</b:IsValid>
<b:StatusCode>99</b:StatusCode>
<b:StatusDescription i:nil="true"/>
<b:StatusMessage>Validación contiene errores en campos mandatorios.</b:StatusMessage>
<b:XmlBase64Bytes>XML en Base 64=</b:XmlBase64Bytes>
<b:XmlBytes i:nil="true"/>
<b:XmlDocumentKey>A08f2283e5dd6c1878e6ea9ec3a695a9431c924e1086607f6ae7123d081af7b88</b:XmlDocumentKey>
<b:XmlFileName>invoice-1-firmado-SHA256</b:XmlFileName>
StatusCode
R 00 = Procesado Corectamente 1-3 1.0
66= NSU no encontrado
90 = TrackId no encontrado
99 = validaciones contienen errores
en campos mandatorios
La respuesta . ApplicationResponse
con la información del evento
correspondiente. En Base54 ( puede Arreglo de
XmlBase64Bytes
ser configurado para que esta bytes
información se entregue en un
arreglo de byte
Arreglo de
R XmlBytes Corresponde al valor parámetro: true 1 1.0
bytes
Validaciones iniciales:
Ejemplo de Petición
<soap:Envelope xmlns:soap="http:/www.w3.org/2003/05/soap-envelope" xmlns:wcf="http:/wcf.dian.colombia">
<soap:Header/>
<soap:Body>
<wcf:SendEventUpdateStatus>
<wcf:contentFile>cid:210162715399</wcf:contentFile>
</wcf:SendEventUpdateStatus>
</soap:Body>
</soap:Envelope>
Codigo de respuesta
100= Acción completada OK
NOTA: Se envían solo los parámetros de autenticación por certificado definida para este método.
Ejemplo
<s:Envelope xmlns:s="http:/www.w3.org/2003/05/soap-envelope" xmlns:a="http:/www.w3.org/2005/08/addressing" xmlns:u="http:/docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
Se envían los parámetros de consumo en la estructura XML definida para este método.
Ejemplo
<s:Envelope xmlns:s="http:/www.w3.org/2003/05/soap-envelope" xmlns:a="http:/www.w3.org/2005/08/addressing" xmlns:u="http:/docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<a:Action s:mustUnderstand="1">http:/wcf.dian.colombia/IWcfDianCustomerServices/GetXmlByDocumentKeyResponse</a:Action>
<o:Security s:mustUnderstand="1" xmlns:o="http:/docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2018-12-14T15:52:37.096Z</u:Created>
<u:Expires>2018-12-14T15:57:37.096Z</u:Expires>
</u:Timestamp>
</o:Security>
</s:Header>
<s:Body>
<GetXmlByDocumentKeyResponse xmlns="http:/wcf.dian.colombia">
<GetXmlByDocumentKeyResult xmlns:i="http:/www.w3.org/2001/XMLSchema-instance">
<b:Code>Ok</b:Code>
<b:Message>El XML para el trackId: f3be1a2f832c10564a18e5044e16891739f77631 fue encontrado</b:Message>
<b:XmlBytesBase64> archivo UBL DE en base 64
</GetXmlByDocumentKeyResult>
</GetXmlByDocumentKeyResponse>
</s:Body>
</s:Envelope>
401= No autorizado
401= No autorizado
Ejemplo de Petición
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wcf="http://wcf.dian.colombia">
<soap:Header/>
<soap:Body>
<wcf:GetNumberingRange>
<wcf:accountCode>2019051401</wcf:accountCode>
<wcf:accountCodeT>800123888</wcf:accountCodeT>
<wcf:softwareCode>0A4d5fad-7b4b-4f3e-b14d-4560246dbc4a</wcf:softwareCode>
</wcf:GetNumberingRange>
</soap:Body>
</soap:Envelope>
Ejemplo
401= No autorizado
https:/www.soapui.org/downloads/soapui.html
Nota: la URL del Web Service “WS” estará expuesta en el catalogo de participante (habilitación ó
producción) una vez se configure el modo de operación y se seleccione uno de estos, sobre el
Listado de modos de operación asociados encontrara la URL del WS.
Los próximos campos a completar debe tener los mismos valores que se indican en la imagen a
continuación.
12.13. Recomendaciones
Se recomienda después de crear o actualizar la configuración del WS-Security eliminar
el request anterior y crear uno nuevo. Estos no ven reflejados las actualizaciones de la
configuración global.
13.1.1.1. Tablas
Se realiza modifiaciones sobre las siguientes tablas :
Formule su petición, queja, sugerencia o reclamo en el Sistema PQSR de la DIAN
Subdirección de Gestión de Fiscalización Tributaria
Cra. 7 Nº 6C-54 piso 7º PBX 607 9800 ext. 907401
Código postal 111711
www.dian.gov.co
13.1.1.2.1. Ejemplificaciones
Se realiza la inclusión de dos ejemplificaciones en la caja de herramienta:
Generica con pago anticipado
Generica con periodo de facturacion
13.1.1.2.3. XSD
Se realiza modificación sobre los archivos XSD expuestos sobre la carpeta maindoc:
DIAN_UBL_Structures.xsd
13.1.2.1.2.1. Modificaciones:
Se generan modificacones sobre los siguientes NS.
DA03 se genera cambio de ext a sts
13.1.2.1.2.2. Adicion
Se genera las adiciones de los siguientes NS.
DA03 se adiciono el NS sts
DA04 se adiciono el NS sts
DA05 se adiciono el NS sts
DA06 se adiciono el NS sts
HB04 se adiciono el NS cbc
AA32 se adiciono el NS cac
AA33 se adiciono el NS cac
AB07 se adiciono el NS cac
EA07 se adiciono el NS cac
AD38 se adiciono el NS cbc
AD20 se adiciono el NS cac
EA03 se adiciono el NS cac
EA06 se adiciono el NS cac
LA02 se adiciono el NS cac
EB03 se adiciono el NS cac
EB06 se adiciono el NS cac
EB07 se adiciono el NS cac
EB08 se adiciono el NS cac
AD22 se adiciono el NS cac
EC03 se adiciono el NS cac
LB01 se adiciono el NS cac
EC07 se adiciono el NS cac
AD25 se adiciono el NS cac
13.1.2.1.3. Campo
Se genera corrección para el campo de el siguiente ID.
FA30 se genera cambio de AdditionalPropertyItem a AdditionalItemProperty
AC26 se genera cambio de RequestedMonetaryTotal a LegalMonetaryTotal
13.1.2.1.4. Descripción
13.1.2.1.4.1. Modificación:
Se generan las modificaciones sobre las descripciones de los siguientes ID.
13.1.2.1.5. Tamaño
13.1.2.1.5.1. Modificación.
Se genera la modificación sobre los tamaños de los siguientes ID.
HH04 se genera cambio de 4 a 11
AA18 se genera cambio de 999 a 1..999
HA02 Se genera cambio de 3..10 a 2
13.1.2.1.6. Ocurrencia
Se genera modificaciones sobre las ocurrencias de los siguientes ID
AD19 se genera cambio de 0..N a 0..1
AD27 se genera cambio de 1..9999 a 1..N
HC07 se genera cambio de 1..N a 1..1
AC19 se genera cambio de 0..N a 0..1
13.1.2.1.7. Xpath
13.1.2.1.7.1. Adición
Se genera adición sobre el Xpath del siguiente ID.
HC06A se incluye el Xpath
../cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:TaxLevelCode
13.1.2.1.7.2. Corrección
Se genera corrección sobre el Xpath de los siguientes ID
AC26 de /CreditNote/cac:RequestedlMonetaryTotal a /CreditNote/cac: LegalMonetaryTotal
13.1.2.1.7.3. Modificación
Se genera modificación sobre los Xpath de los siguientes elementos.
AC26
13.1.3.1.1. Eliminación
Se procese a realizar la eliminación de los siguientes eventos:
Documento Electrónico Referenciado por Otro Documento Electrónico
Documento Referenciado no Existe en la Base de Datos de la DIAN
Anulación de Efecto de Evento
Anotación de Oficio por la DIAN
Anulación de Negocio
Anulación de Documento
Solicitación de Corrección en Documento
13.1.3.1.2. Adición
Se genera la siguiente adición del evento
Uso NO Autorizado por la DIAN
13.1.3.4.2. XSD
Se genera modificación sobre el siguiente XSD
DIAN_UBL_Structures.xsd
13.1.4.1.1. Inclusión
Se informa la utilización de los siguientes NameSpeces “tabla 1” para el bloque de firma electrónica
xades
xmlns
ds
Adicional se incluye la lista GC en la caja de herramientas sobre la ruta Caja de herramienta Factura Electronica
Validacion Previa\Listas de valores
13.1.4.1.3.2. Inclusión
Se genera la incorporación de la tablas
Adicional se incluye la lista GC en la caja de herramientas sobre la ruta Caja de herramienta Factura Electronica
Validacion Previa\Listas de valores
i
Vea el documento «Formatos de los Documentos XML de Facturación Electrónica»
Se incluye la notación xPath porque los expertos en e-commerce & e-biz han recibido entrenamiento en examinar archivos en formato XML, y en
ii