Nueva versión 2.

1 de
Factura Electrónica
Con Validación Previa

ATEB COLOMBIA SAS

 Objetivo
Dar a conocer toda la información detallada de la “Versión 2.1 con validación
previa de facturación electrónica”. Así como entender el nuevo esquema en
todos los procesos, los participantes y los ajustes requeridos para el debido
cumplimiento de la autoridad fiscal.
Calendario de masificación
• Resolución 000020 del 26 de marzo de 2019
• Por código de actividad económica
• Comienza en mayo 2019
• Inicia tres meses después del registro
• Los últimos entrarán en 2020

Adicionalmente
• Operaciones de exportaciones, importaciones, nóminas y pagos
• Registro de facturas para el Factoring
 Participantes

• Proveedores Tecnológicos
• ERP´s
• Desarrolladores
• Empresas interesadas

Duración proyecto piloto: 11 marzo - 10 mayo 2019

 Cronograma Piloto

Normatividad Seguimiento
Plenaria Plenaria
Tributación y FE representantes

20
Marzo

Ajustes informáticos Pruebas de habilitación Pruebas de Operación

11-13 26 11
Marzo Marzo abril

Fin piloto
Registro Envío de
Conocimiento Inicio envío facturas
de facturas Producción
 Procedimiento para habilitación
validación previa
…
6
5 Postulación
como PT con

4 Realizar
pruebas
consecutivas
validación
previa

3 Cambia a
estado
2 Cambia a
estado:
HABILITADO
“PRODUCCIÓN”

1
Realizar 100
pruebas
Selecciona consecutivas
modo de
REGISTRO EN operación
CATÁLOGO

AMBIENTE DE PRUEBA / TEST

Procedimiento de registro de autorización como
PT validación previa

11
10
AUTORIZACIÓN
9 Activación de
8 Adjuntar
pruebas
consecutivas

7 Se activa botón
documentación
requerida
donde se postula
como PT
REGISTRO COMO
PROVEEDOR
TECNOLÓGICO
CON VALIDACIÓN
PREVIA

AMBIENTE DE PRUEBA / TEST

 Pruebas mínimas durante el piloto

1.Genérica 1.Nota Debito 1.Acuse de recibo

RESPONSE
DOCUMENTO
ejemplificaciones

APLICCATION
2.Derivados
3. Auto retenedores
2.Nota Credito 2.Aceptación
4.Mandato/mandatario 3.Anotaciones 3.Validación DIAN
5.Excluidos/exentos
6.Servicios AIU
7.Exportación

20 Ejemplificaciones x 20 F.E diarias = 400 x 15 días = 6.000

6.900 PRUEBAS
F.E CON
Cada documento x 20 F.E diarias = 60 x15 días = 900 VALIDACIÓN
PREVIA
Modelo de Operación Validación Previa Factura Electrónica

PROCESO GENERAL ACTIVIDAD SISTEMA DE INFORMACIÓN

Inicio

Enrolamiento de participantes:
• Facturadores electrónicos
• Proveedores tecnológicos
• Adquirentes
• Autorizados especiales

Habilitación automática:
• Inicio
• Cambio de PT

Solicitud numeraciones de facturación

electrónica y asociación a PT cuando aplique
Validación previa de facturas electrónicas

Contingencia

Consultas

Fin
Proyecto Factura Electrónica
Modelo de Operación Validación Previa Factura Electrónica
ENROLAMIENTO DE PARTICIPANTES

ACTIVIDAD Funcionario Facturador Proveedor

Adquirente
DIAN Electrónico Tecnológico

Inicio
Registrar o actualizar resolución de Obligadosa
Facturar

Identificar el tipo de participante 1

¿El Proveedor Tecnológico ya está habilitado N

como Facturador Electrónico? 1
S

Incorporar información del participante

Seleccionar modo de operación (Directo,

Facturación Gratuita, Proveedor Tecnológico)

Asociar software

Activar ejemplos para pruebas

Fin
Proyecto Factura Electrónica
Modelo de Operación Validación Previa Factura Electrónica
VALIDACIÓN PREVIA
Facturador Proveedor Solución Validación
ACTIVIDAD
Electrónico Tecnológico Gratuita Previa
Inicio

Generar y firmar documento electrónico

1
(Fac-e, ND, NC, Application Response, otros)
Transmitir documento electrónico al ambiente
de operación de factura electrónica
Verificar reglas y condiciones de documentos
electrónicos (Fac-e, ND, NC, App Resp, otros)
Generar y firmar documento de aprobación o
rechazo (Application Response)

Transmitir aprobación o rechazo DIAN

(Application Response) al solicitante

¿El documento electrónico fue aprobado por la N

1
DIAN? S
Conformar y remitir el contenedor de documento s
(Attached Document con Fac-e y Application
Response aprobación DIAN)

Continúa en la siguiente página 2

Proyecto Factura Electrónica

Modelo de Operación Validación Previa Factura Electrónica
VALIDACIÓN PREVIA
Facturador Proveedor Validación
ACTIVIDAD Adquirente
Electrónico Tecnológico Previa
Continuación Validación Previa 2

Recibir contenedor de documentos (Attached

Document):

¿El adquirente es electrónico? N

S
Consulta la factura electrónica

Generar, firmar y remitir acuse de recibo de la

factura electrónica (Application Response)
Recibe acuse de recibo de la factura
electrónica (Application Response)
Consultar acuse de recibo de la factura
electrónica

Generar, firmar y remitir aceptación de la

factura electrónica (Application Response)

Consultar la aceptación de la factura

electrónica
Fin

Proyecto Factura Electrónica

Modelo de Operación Validación Previa Factura Electrónica
HABILITACIÓN AUTOMÁTICA

Pruebas Operación Automática

• Facturas • Similar a la • Otorgada por el

operación de sistema
• Notas débito validación
previa • No requiere
• Notas crédito participación de
• Ejemplos para los funcionarios
• Acuses de pruebas
recibo de la DIAN
• Control de
• Aceptación cantidad de
facturas, ND y
NC

Proyecto Factura Electrónica

Modelo de Operación Validación Previa Factura Electrónica
consultas

Por
documento

Con Listado de
autenticación emitidas

Lista de
Consultas recibidas

Sin Por
autenticación documento

Proyecto Factura Electrónica

 LA FACTURA
ELECTRÓNICA
App Response
4 Acuse de
Recibo
A
App Response
Acuse de CFE

2 FE
Recibo

NC y ND App
Response DIA 4 5
Validación
N B Operaciones a Crédito
INVOICE
App Response Expresa
1 Acepta o
niega
FE CFE X

App
Response
INVOICE Validación

3
No regulado. Sin perjuicio de cumplimiento de 4 A Y 4 B

App Response
1. = Generación y transmisión COMPRADOR
4 Acuse de
2. = Validación
Recibo F.E: Directo, PT ,
3. = Entrega
Gratuita
VENDEDOR: 1 + 2 + 3 = Expedición
CFE
4 A = Acuse de recibo Consumidor: WEB Dian
Directo, PT o 4 B = Acuse de recibo si no se envía 4 A
Gratuita 5. = Aceptación
Modelo de Operación Validación Previa Factura Electrónica
CONTINGENCIA DIAN

Adquirente
• Recibo
Fac-e • Aceptación

Facturador 48 horas

• Entrega de la Fac-e al adquirente sin validación previa

• Al restaurar los servicios, 48 horas para transmitir a la DIAN paravalidación
• La DIAN transmite aprobación o rechazo
• El adquirente remite el acuse de recibo y la aceptación de la factura electrónica cuando la
DIAN termine la contingencia

Proyecto Factura Electrónica

Aspectos Técnicos

1. Documento guía o base.

2. El anexo técnico (Carpeta anexo técnico).
3. Documentos de apoyo para entendimiento de XML-UBL, carpeta
Documentos de apoyo – inglés.
4. Listas de valores utilizadas, carpeta Lista de Valores. Los archivos
en extensión gc., se pueden ver con un visor XML.
5. Esquemas utilizados, con reglas de validación, carpeta schemes.
Los archivos .sch se pueden abrir con un visor XML.
6. Casos de ejemplo, en la carpeta Ejemplificaciones, tanto en Excel
como en XML.
7. XSD.
8. XSLT.

Caja de
herramientas
Principales cambios
• Adopción de estándar UBL 2.1
– Se eliminan personalizaciones, es prefijos
– Se armoniza grupos de información con descripción de negocio
– Solamente el grupo DianExtensions como personalización

• Incremento de validaciones (8-264)

• Nuevos documentos:
– Application Response (Registro de 16 eventos)
– Attached Document (Contenedor o sobre)

• NC y ND "si y solamente si existe una Factura"

Principales cambios
Principales cambios
• Mandante
– Reporte NIT por ítem (línea de factura)

• Grupo para información de transporte o entregas

– Opcional
– Para estandarizar donde reportar dicha información para los
interesados

• Obligatoriedad de reporte de información

– Emisor
• NIT y DV
• Información de Dirección
– Adquirientes Responsables (Ley 1943 / 2018)
• NIT y DV
• Información de Dirección
Principales cambios

• Información de pagos
– Tipo transacción (Contado ó Crédito)
• Crédito: condición mínima para factoring electrónico
– Forma de pago
• Si es Contado
– Informa medio de pago

• Descuentos
– A nivel de ítem
• Afectan base gravable
– A nivel de factura
• No afectan bases gravables
• Tipificados en lista de valores
Principales cambios

• Cargos
– Si causan tributos
• Informarlos como un ítem más
– Si no causan tributos
• Informarlos a nivel de factura

• Impuestos
– Informados a nivel de ítem cuando aplique
– Un grupo TaxTotal por cada impuesto reportado a nivel factura.
– Impuestos retenidos en grupo diferente a TaxTotal, WithHoldingTax
– Tarifas porcentuales tipificadas para algunos tributos, i.e., IVA (0%,
5%, 16%, 19%)
– Elementos adicionales para reportar tributos nominales (Unidad
Medida, Valor)
Principales cambios

• Totales
- Formulados según anexo
- Margen para manejo de diferencias

• Líneas de detalle:
– Deben incluir impuestos, si aplica
– Deben incluir mandante, si aplica
– Inclusión de campos comodín, formato (llave, valor), para
información comercial complementaria; i.e. vehículos (marca:
xxxx), (modelo: 2015), ….
– Inclusión campo precio de referencia para muestras o regalos
comerciales.

• Ambiente de ejecución:
– Determina si el documento es de producción ó pruebas
Ejemplificaciones
Caso Genérico
• Este caso aplica a la mayor parte del mercado. En este ejemplo se ilustra
el reporte de información de:

1. Items gravados
2. Items excluidos
3. Items como muestra comercial o regalo
4. Descuentos a nivel de ítem (afectan base gravable)
5. Cargos gravados, los cuales se deben reportar como ítems
6. Impuesto de bolsas plásticas
7. Descuentos a nivel de factura
8. Cargos a nivel de factura
9. Totales de factura
Ejemplificaciones
•Caso Excluidos y Exentos
•La diferencia entre los dos, es que para bienes y servicios excluidos no se
informa el grupo cac:TaxTotal a nivel de ítem. Para los bienes y servicios Exentos,
si se debe informar dicho grupo con la tarifa del respectivo tributo en 0.0

• Caso Mandatos
• El NIT del mandante se debe informar a nivel de ítem.

• Caso Contratos AIU

• A nivel de ítem se deben informar los conceptos que sumados den el valor
completo del contrato.
•El concepto AIU o Utilidad reporta el grupo de impuestos, con base en la
normatividad vigente.
Ejemplificaciones
• Caso Emisor es Autoretenedor
• Este caso aplica cuando el Emisor enuncia las retenciones que le
práctica al Adquirente. Es importante resaltar que las retenciones de IVA y
ReteFuente se deben registrar a nivel de ítem. Mientras que las
retenciones de Ica a nivel de factura.

• Caso combustibles
• La diferencia frente a otros casos, va en los tributos a reportar, los cuales
en su mayoría son específicos al sector y vienen expresados en valores
nominales por galón. La tabla de tributos incluye los diferentes conceptos
del sector, las tarifas por tributo, dada la variabilidad, serán exclusiva
responsabilidad del emisor en su reporte.
Mini FAQ

-Se validan todos los documentos: Fac-e, ND, NC, Application Response, otros.

- Hay reglas de rechazo y reglas de notificación.

• Rechazo: Información NO acorde a la regla establecida
• Notificación: Eventos ocasionales por lógica comercial, que no deben
ser recurrentes en operación

- Si hay un rechazo en una regla se rechaza todo el documento.

- Los rechazos no consumen número.

Sobre el Elemento UBLExtensions se incluyen los siguiente elementos

* AuthorizationProvider * QRCode
Información del Proveedor Autorizado (PA) por la DIAN

Información sobre el QRCode.

Invoice

<ext:UBLExtensions>
<ext:UBLExtension> </sts:InvoiceControl>

</sts:InvoiceSource> </sts:SoftwareProvider>

</sts:SoftwareSecurityCode> </sts:AuthorizationProvider>

</ext:UBLExtension> <ext:UBLExtension>

</ds:SignedInfo> </ds:SignatureValue>

</ds:KeyInfo> </ds:Object>

</ext:UBLExtensions>
Sobre el Elemento UBLExtensions se incluyen los siguiente elementos
* AuthorizationProvider * QRCode

Información del Proveedor Autorizado (PA) por la DIAN Información sobre el QRCode.

CreditNote
<ext:UBLExtensions> <ext:UBLExtension>

</sts:InvoiceSource> </sts:SoftwareProvider>

</sts:SoftwareSecurityCode> </sts:AuthorizationProvider>

</ext:UBLExtension> <ext:UBLExtension>

</ds:SignedInfo> </ds:SignatureValue>

</ds:KeyInfo> </ds:Object>

</ext:UBLExtension> </ext:UBLExtensions>
Sobre el Elemento UBLExtensions se incluyen los siguiente elementos

* AuthorizationProvider * QRCode
Información del Proveedor Autorizado (PA) por la DIAN Información sobre el QRCode.
DebitNote
<ext:UBLExtensions>
<ext:UBLExtension> </sts:InvoiceSource>
</sts:SoftwareProvider> </sts:SoftwareSecurityCode>
</sts:AuthorizationProvider> </ext:UBLExtension>
<ext:UBLExtension> </ds:SignedInfo>
</ds:SignatureValue> </ds:KeyInfo>
</ds:Object> </ext:UBLExtension>
</ext:UBLExtensions>
Estructura
Invoice
</cbc:UBLVersionID>
</cbc:CustomizationID>
</cbc:ProfileID>
</cbc:ProfileExecutionID>
</cbc:ID>
</cbc:UUID>
</cbc:IssueDate>
</cbc:IssueTime>
</cbc:InvoiceTypeCode> < – 1,
2 -->
</cbc:DocumentCurrencyCode>
</cbc:LineCountNumeric>
</cac:OrderReference>
</cac:AccountingSupplierParty>
</cac:AccountingCustomerParty
> </cac:AccountingCustomerParty>
</cac:PaymentMeans>
</cac:AllowanceCharge>
</cac:TaxTotal>
</cac:LegalMonetaryTotal>
</cac:InvoiceLine>
</Invoice>
El elemento cbc:ProfileExecutionID informar el ambiente en donde se va a emitir este documento
1. Producción
2. Pruebas
CreditNote
</cbc:UBLVersionID>
</cbc:CustomizationID>
</cbc:ProfileID>
</cbc:ProfileExecutionID>
</cbc:ID>
</cbc:UUID>
</cbc:IssueDate>
</cbc:IssueTime>
</cbc:CreditNoteTypeCode>
</cbc:DocumentCurrencyCode>
</cbc:LineCountNumeric>
</cac:DiscrepancyResponse>
</cac:AdditionalDocumentReference </cac:LegalMonetaryTotal>
> </cac:DebitNoteLine>
</cac:AccountingSupplierParty>
</cac:TaxTotal>
</cac:LegalMonetaryTotal>
</cac:CreditNoteLine>
</CreditNote>
DebitNote
</cbc:UBLVersionID>
</cbc:CustomizationID>
</cbc:ProfileID>
</cbc:ProfileExecutionID>
</cbc:DocumentCurrencyCode>
</cbc:LineCountNumeric>
</cac:DiscrepancyResponse>
</cac:AdditionalDocumentReferenc
e>
</cac:AccountingSupplierParty>
</cac:AccountingCustomerParty>
</cac:TaxTotal>
</DebitNote>
ApplicationResponseType
</cbc:UBLVersionID minOccurs>
</cbc:CustomizationID minOccurs>
</cbc:ProfileID minOccurs>
</cbc:ProfileExecutionID minOccurs>
</cbc:ID minOccurs>
</cbc:UUID minOccurs>
</cbc:IssueDate minOccurs>
</cbc:IssueTime minOccurs>
</cbc:ResponseDate minOccurs>
</cbc:ResponseTime minOccurs>
</cbc:Note minOccurs>
</cbc:VersionID minOccurs>
</cac:Signature minOccurs>
</cac:SenderParty minOccurs>
</cac:ReceiverParty minOccurs>
</cac:DocumentResponse
minOccurs>
Modelos de Cálculo
1 Especificación técnica del código de seguridad del Software.
El elemento SoftwareSecurityCode pasa de ser constante debido a la implementación del siguiente
calculo.
• Identificador del software asignado desde el sistema de la DIAN cuando el software se activa
en el Sistema de Facturación Electrónica. i.e. código de activación.
• PIN del software que usted asignó en el sistema de la DIAN cuando el software se activa en el
Sistema de Facturación Electrónica.
•Numero de la factura /invoice/DebitNote/CreditNote/cbc:ID
SHA384(Identificador del software + PIN del software+NroDocumento)
Donde + significa la concatenación de las cadenas de caracteres.

2 Policitas de Firma
El algoritmo de firma usado sobre el elemento SignedInfo para la firma digital de la factura
electrónica puede ser:
• Recomendado RSAwithSHA256 http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
• Recomendado RSAwithSHA384 http://www.w3.org/2001/04/xmldsig-more#rsa-sha384
• Recomendado RSAwithSHA512 http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
3 Código Único de Factura Electrónica CUFE
XPath CUFE Invoice
NumFac /Invoice/cbc:ID
FecFac /Invoice/cbc:IssueDate
HorFac /Invoice/cbc:IssueTime
ValBru /Invoice/cac:LegalMonetaryTotal/cbc:LineExtensionAmount
CodImp1 /Invoice/cac:TaxTotal[X]/cac:TaxSubtotal[X]/cac:TaxCategory[X]/cac:TaxScheme[X]/cbc:ID[X]=01
ValImp1 /Invoice/cac:TaxTotal[X]/cbc:TaxAmount[X]
CodImp2 /Invoice/cac:TaxTotal[Y]/cac:TaxSubtotal[Y]/cac:TaxCategory[Y]/cac:TaxScheme[Y]/cbc:ID[Y]=02
ValImp2 /Invoice/cac:TaxTotal[Y]/cbc:TaxAmount[Y]
CodImp3 /Invoice/cac:TaxTotal[Z]/cac:TaxSubtotal[Z]/cac:TaxCategory[Z]/cac:TaxScheme[Z]/cbc:ID[Z]=03
ValImp3 /Invoice/cac:TaxTotal[Z]/cbc:TaxAmount[Z]
ValTot /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 debe ir informado en el XML
Tipo de Ambiente /Invoice/cbc:ProfileExecutionID

Composición del CUFE = SHA1 o SHA256 (NumFac + FecFac + HorFac + ValBru + CodImp1 + ValImp1 +
CodImp2 + ValImp2 + CodImp3 + ValImp3 + ValTot + NitOFE + NumAdq + ClTec + TipoAmbie)
Donde + significa la concatenación de las cadenas de caracteres.

Los Valores monetarios se representa con punto decimal, con decimales a dos (2) dígitos,sin separadores
de miles, ni símbolo pesos.
Los valores de los impuestos se representan con punto decimal, con decimales a dos (2) dígitos, sin
separadores de miles, ni símbolo pesos.
Ajustes de la Firma electrónica
El siguiente fragmento de la firma digital será el nuevo modelo que se
incluirá en la factura electrónica con Validación Previa de Colombia
• sender: elemento diligenciado por el Facturador Electrónico o el PT
• signer: elemento diligenciado por el Servicio de Firma Digital. - i.e.
Servicio de ECD que firma digitalmente por mandato las facturas del
Facturador Electrónico
 Eventos que pueden incurrir en una factura

Número Secuencial Único “NSU” • Uso Autorizado por PA

• Uso Autorizado por la DIAN
• Documento Electrónico Validado por PA, y que Debería Haber Sido Rechazado
LIFO (Last In First
• Documento Electrónico Referenciado por Otro Documento Electrónico
Out)
• Documento Referenciado no Existe en la Base de Datos de la DIAN
• Anulación de Efecto de Evento
T1 1
• Anotación de Oficio por la DIAN
T2 2 • Anulación de Negocio
• Anulación de Documento
T N • Solicitación de Corrección en Documento
T N
• Acuse de recibo
N +
• Rechazo de Documento
• Recibimiento de los Bienes
Las validaciones sobre un • Aceptación de Documento
documento siempre se revisan • Factura Ofrecida para Negociación como Título Valor
del ultimo evento hasta el • Factura Negociada como Título Valor
primero, estando un evento N • Nota Crédito
ligado a una tiempo N donde se • Nota debito
realizo dicho evento. • Invoice
• Application Response
T:Tiempo ; Tn < Tn+1
Nota: No se cuenta con una reglamentación para los Proveedores Autorizados PA
 Autenticación
al Web Service

• El modelo de comunicación sigue el estándar de servicios web

definidos por WS-Security1.0 Oasis.
• Para garantizar una conexión segura se establece el uso de un
Certificado Digital para la conexión a través del WS utilizando
el protocolo TLS Transport Layer Security versión 1.2
Web Services de la DIAN
https://colombia-dian-webservices-input-
sbx.azurewebsites.net/WcfDianCustomerServices.svc?wsdl

Para operar con la solución de validación previa de la DIAN, se debe entender el modelo
conceptual de comunicación y tecnológico que lo sustenta, el cual involucra la utilización de UBL
2.1, como lenguaje para el intercambio de información de los documentos electrónicos, el firmado
de los anteriores archivos a través de certificados digitales, la utilización de Web Services para el
intercambio seguro de los DE, la lógica de validación, respuesta y registros de los documentos y
eventos en la DIAN.

Para esto contamos con dos Métodos:

Sincrónico
Se consideran a aquellos en los cuales el procesamiento y respuesta del servicio se realizan en la
misma conexión de consumo.

Asincrónico
Son aquellos en los cuales el resultado del procesamiento del servicio requerido no es entregado
en la misma conexión de la solicitud de consumo. Consta de un mensaje y un número de atención.
Métodos Síncronos:
• Recepción DE (SendBillSync).
Este servicio atiende la funcionalidad de enviar a la DIAN los documentos, de forma tal que la plataforma DIAN
reciba y valide los documentos UBL (factura electrónica, nota de crédito y nota de débito) y forma síncrona de
respuesta de validación para su uso y expedición.
• Recepción Evento (SendEventUpdateStatus).
Este servicio atiende la funcionalidad de recepción y registro de los eventos de los documentos tributarios, ante
la DIAN
• Consulta DE (GetStatus).
Este servicio atiende la funcionalidad de consultar el estado del documento registrado en la DIAN, por medio
del CUFE o TrackId, devolviendo el estado
• Consulta DE (GetStatusZIP).
Este servicio atiende la funcionalidad de consultar el estado de todos los documento enviados en un ZIP, por los
métodos SendBillSync o SendBillAttachmentAsync y que se encuentran registrados en la DIAN.
• Consulta Contribuyentes Activos de IVA. ( GetTaxPayer)
Este servicio devuelve el listado de todos los contribuyentes activos de IVA registrados en la DIAN
• Consulta de Rangos de Numeración. (GetNumberingRange).
Este servicio devuelve la lista de Rangos de Numeración y su información complementaria.
Se requiriere como parámetro el NIT de la empresa, NIT Proveedor Tecnológico, IdentificadorSoftware
• Descarga DE por CUFE (GetXmlByDocumentKey).
Este servicio permite descargar el UBL de DFE a través de la consulta del CUFE.
Se valida que el usuario autenticado, por certificado digital, corresponda al NIT de la empresa
emisora o receptora del UBL consultado.
Métodos Asíncronos:
• Recepción DE. (SendBillAsync).
Este servicio atiende la funcionalidad de enviar a la DIAN los documentos, de forma tal que la
plataforma DIAN reciba y valide los documentos UBL (factura electrónica, nota de crédito y nota de
débito) para efectos de obtener un TrackId que le permitirá consumir servicio GetStatusZIP para
obtener la respuesta de validación para su uso y expedición.

• Recepción DE en ambiente habilitación (SendTestSetAsync).

Este servicio atiende la funcionalidad de enviar a la DIAN los documentos, de forma tal que la
plataforma DIAN reciba y valide los documentos UBL (factura electrónica, nota de crédito y nota de
débito) para efectos de obtener un TrackId que le permitirá consumir servicio GetStatusZIP con el
cual se obtendrá la respuesta de validación de estos documentos en pruebas de habilitación.