• Author / Uploaded
• ruddy

Citation preview

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 Seguimiento representantes

Normatividad Tributación y FE

Plenaria

Plenaria

20 Marzo

Ajustes informáticos

11-13 Marzo

Conocimiento

Pruebas de habilitación

Pruebas de Operación

26 Marzo

11 abril

Registro Inicio envío de facturas

Envío de facturas Producción

Fin piloto

Procedimiento para habilitación validación previa …

1 REGISTRO EN CATÁLOGO

2 Selecciona modo de operación

3 Realizar 100 pruebas consecutivas

4 Cambia a estado: HABILITADO

6

5 Cambia a estado “PRODUCCIÓN”

Realizar pruebas consecutivas

Postulación como PT con validación previa

AMBIENTE DE PRUEBA / TEST

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

9 8 7 REGISTRO COMO PROVEEDOR TECNOLÓGICO CON VALIDACIÓN PREVIA

Se activa botón donde se postula como PT

Adjuntar documentación requerida

AUTORIZACIÓN

Activación de pruebas consecutivas

AMBIENTE DE PRUEBA / TEST

1.Nota Debito 2.Nota Credito 3.Anotaciones

20 Ejemplificaciones x 20 F.E diarias = 400 x 15 días = 6.000 Cada documento x 20 F.E diarias = 60 x15 días = 900

APLICCATION RESPONSE

1.Genérica 2.Derivados 3. Auto retenedores 4.Mandato/mandatario 5.Excluidos/exentos 6.Servicios AIU 7.Exportación

DOCUMENTO

ejemplificaciones

Pruebas mínimas durante el piloto

1.Acuse de recibo 2.Aceptación 3.Validación DIAN

6.900 PRUEBAS F.E CON VALIDACIÓN PREVIA

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

PROCESO GENERAL

ACTIVIDAD 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

SISTEMA DE INFORMACIÓN

Modelo de Operación Validación Previa Factura Electrónica ENROLAMIENTO DE PARTICIPANTES Funcionario DIAN

ACTIVIDAD

Facturador Electrónico

Proveedor Tecnológico

Inicio Registrar o actualizar resolución de Obligadosa Facturar Identificar el tipo de participante ¿El Proveedor Tecnológico ya está habilitado como Facturador Electrónico? 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

1 1

N S

Adquirente

Modelo de Operación Validación Previa Factura Electrónica VALIDACIÓN PREVIA ACTIVIDAD

Facturador Electrónico

Proveedor Tecnológico

Solución Gratuita

Validación Previa

Inicio Generar y firmar documento electrónico (Fac-e, ND, NC, Application Response, otros)

1

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 DIAN?

1

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 Proyecto Factura Electrónica

2

N S

Modelo de Operación Validación Previa Factura Electrónica VALIDACIÓN PREVIA ACTIVIDAD Continuación Validación Previa

Facturador Electrónico

Proveedor Tecnológico

Adquirente

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

Validación Previa

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

Pruebas • Facturas • Notas débito • Notas crédito • Acuses de recibo • Aceptación

Proyecto Factura Electrónica

Operación • Similar a la operación de validación previa • Ejemplos para pruebas • Control de cantidad de facturas, ND y NC

Automática • Otorgada por el sistema • No requiere participación de los funcionarios de la DIAN

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

Por documento

Con autenticación

Lista de recibidas

Consultas Sin autenticación Proyecto Factura Electrónica

Listado de emitidas

Por documento

LA FACTURA ELECTRÓNICA App Response Acuse de Recibo

4 A App Response Acuse de Recibo

2 NC y ND

FE

App Response Validación

INVOICE

CFE

DIA N

5

4 B

Operaciones a Crédito

App Response Acepta o niega

1 CFE

FE

INVOICE

Expresa

X

App Response Validación

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

4

VENDEDOR: Directo, PT o Gratuita

App Response Acuse de Recibo CFE

1. = Generación y transmisión 2. = Validación 3. = Entrega 1 + 2 + 3 = Expedición 4 A = Acuse de recibo 4 B = Acuse de recibo si no se envía 4 A 5. = Aceptación

COMPRADOR F.E: Directo, PT , Gratuita Consumidor: WEB Dian

Modelo de Operación Validación Previa Factura Electrónica CONTINGENCIA DIAN

Adquirente Fac-e

Facturador

• • • •

• •

Recibo Aceptación

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. 2. 3.

4.

5.

6.

7. 8.

Documento guía o base. El anexo técnico (Carpeta anexo técnico). Documentos de apoyo para entendimiento de XML-UBL, carpeta Documentos de apoyo – inglés. Listas de valores utilizadas, carpeta Lista de Valores. Los archivos en extensión gc., se pueden ver con un visor XML. Esquemas utilizados, con reglas de validación, carpeta schemes. Los archivos .sch se pueden abrir con un visor XML. Casos de ejemplo, en la carpeta Ejemplificaciones, tanto en Excel como en XML. XSD. 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

















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



















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

















Estructura Invoice





< – 1, 2 -->







CreditNote

DebitNote





















ApplicationResponseType











El elemento cbc:ProfileExecutionID informar el ambiente en donde se va a emitir este documento 1. Producción 2. Pruebas

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 FecFac HorFac ValBru

/Invoice/cbc:ID /Invoice/cbc:IssueDate /Invoice/cbc:IssueTime /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 ValTot NitOFE NumAdq ClTec Tipo de Ambiente

/Invoice/cac:TaxTotal[Z]/cbc:TaxAmount[Z] /Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID No debe ir informado en el XML /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” LIFO (Last In First Out) T1

1

T2

2

T

N T N N +

Las validaciones sobre un documento siempre se revisan del ultimo evento hasta el primero, estando un evento N ligado a una tiempo N donde se realizo dicho evento. T:Tiempo ; Tn < Tn+1

• • • • • • • • • • • • • • • • • • • •

Uso Autorizado por PA Uso Autorizado por la DIAN Documento Electrónico Validado por PA, y que Debería Haber Sido Rechazado 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 Acuse de recibo Rechazo de Documento Recibimiento de los Bienes Aceptación de Documento Factura Ofrecida para Negociación como Título Valor Factura Negociada como Título Valor Nota Crédito Nota debito Invoice Application Response

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