Eventos de la DIAN

1 · El ciclo de vida de una factura

Reportar una factura a la DIAN no cierra la historia del documento: la abre. A partir de ahí el receptor —no el emisor— va reportando lo que pasa con ella: que la recibió, que recibió el bien o el servicio, y que la acepta o la reclama. Esa secuencia de hechos es el ciclo de vida, y cada hecho es un evento.

El ciclo importa por una razón muy concreta: cuando existen el recibo del bien o servicio y la aceptación —expresa o tácita—, la factura electrónica se convierte en título valor, es decir, en un documento negociable. Los eventos no son un trámite: son lo que le da ese carácter a la factura.

2 · Los cinco eventos

Los cinco comparten estructura: lo único que cambia entre uno y otro es el tdevento. El reclamo es el único que exige un dato adicional, el motivo.

3 · El ApplicationResponse

Un evento no es una anotación sobre la factura: es un documento electrónico propio. Se transmite como un ApplicationResponse, con su propio identificador —un CUDE— y su propia firma. Su tipo de documento es 96, y el sandbox lo fuerza, de modo que no hace falta enviarlo.

La factura afectada va en docreferencia, identificada por su CUFE: es el dato con el que la DIAN localiza el documento sobre el que aplica el evento.

La tabla de datos de cada ficha nombra el tipo de sus campos y desde ahí enlaza al título que dice qué va dentro. Las dos partes y el documento referenciado son los mismos objetos de facturación —TTercero y TDocumentoElectronico—, y están documentados allá.

El asterisco marca lo que hay que enviar, igual que en la tabla de datos de cada ficha, y «no se envía» los que calcula el Proveedor Tecnológico: van en la respuesta y en el XML, pero mandarlos no cambia nada porque se recalculan siempre. Lo que depende de otro dato lo dice la explicación del atributo.

4 · Cómo lo resuelve el sandbox

flowchart TD
    A(["El documento llega en JSON"]) --> B{"¿Ya se reportó esa numeración?"}
    B -- Sí --> G{"¿Llega igual que antes?"}
    G -- Sí --> R0(["200 · estado, UUID y documento adjunto,<br/>sin volver a reportarlo"])
    G -- No --> R1(["409 · regla 90, entrega el XML del documento"])
    B -- No --> C{"¿Cumple las reglas?"}
    C -- No --> R2(["400 · una entrada por regla incumplida,<br/>con su código DIAN y su código InSoft"])
    C -- Sí --> D["Construye el documento y lo firma,<br/>lo reporta y espera a la DIAN"]
    D --> E{"¿La DIAN lo aceptó?"}
    E -- No --> R3(["400 · el rechazo de la DIAN, o «intente más tarde»<br/>si no hubo conexión"])
    E -- Sí --> H(["200 · estado del documento, su UUID<br/>y el documento adjunto"])

Los tres procesos que siguen son iguales para todas las funciones del portal. El primero contesta que reemplaza el sandbox antes de reportar —en eventos se conservan el documento referenciado, el tipo de evento y el usuario que lo suscribe, que es justo lo que estás probando—. El segundo, por qué un reenvío puede responder 409 con la regla 90 de la DIAN, y por qué ese 409 trae el documento adjunto. El tercero, por qué una función puede responder 401 aunque tu JSON esté perfecto.

flowchart TD
    J(["Documento que envía el desarrollador"]) --> A["Ambiente: siempre habilitación"]
    A --> B["Identidad del emisor y del receptor:<br/>la de la empresa de pruebas"]
    B --> C["Se conservan ubicación, responsabilidades<br/>fiscales y datos de contacto"]
    C --> D["Resolución y numeración:<br/>las del sandbox, si están registradas"]
    D --> E["Todo lo demás viaja como se envió:<br/>ítems, tributos, descuentos y totales"]
    E --> F(["Se reporta a la DIAN"])

flowchart TD
    A(["Se envía un documento<br/>con una numeración"]) --> B{"¿Esa numeración ya se reportó?"}
    B -- No --> S(["Sigue el proceso normal de emisión"])
    B -- Sí --> C{"¿El documento sigue siendo el mismo?"}
    C -- Sí --> D(["200 · devuelve el que ya se reportó,<br/>sin duplicarlo"])
    C -- No --> E(["409 · regla 90, rechazo, y entrega<br/>el XML del documento"])

flowchart TD
    R(["Petición del desarrollador<br/>Authorization: Bearer idToken"]) --> T{"¿Viene el token?"}
    T -- No --> E1(["400 · No se especificó el token<br/>de autenticación"])
    T -- Sí --> F{"¿El token es válido?"}
    F -- No --> E2(["401 · Token de autenticación no válido"])
    F -- Sí --> Q{"¿Perfil registrado y activo?"}
    Q -- No --> E4(["401 · Perfil no registrado o suspendido,<br/>con el motivo en el mensaje"])
    Q -- Sí --> OK(["200 · Autorizado, continúa la operación"])