Enviar nota de eliminación

Anula un documento de nómina ya reportado, sin reemplazarlo.

POST /api/DocumentoNE

Es la ruta de la función, y no cambia entre ambientes. La URL base con la que la ejecutas aquí es la del sandbox. Es la URL del sandbox y no corresponde a la etapa productiva de la integración. La URL base de producción se te entrega al adquirir el servicio.

¿Es tu primer contacto con esta parte de la plataforma? Empieza por Nómina electrónica, donde se explica qué documentos existen, cómo se arma el JSON y qué valida el servidor antes de que ejecutes nada.

La nota de eliminación —tddocumentoelectronico en 103 con tdnota en 2— anula un documento de nómina ya reportado sin poner otro en su lugar. Es el camino cuando la nómina no debio emitirse: un trabajador que no correspondia, un periodo duplicado.

A diferencia de la nota de ajuste, no lleva devengos ni deducciones: no hay liquidación que reemplazar. Solo identifica el documento que se anula —en docreferencia, por su CUNE— y quién lo anula. La nota genera su propio CUNE.

Cómo resuelve el sandbox esta función

Emisión de un documento a la DIAN

Lo primero que se mira es la numeración del documento. Si nunca se reportó, el documento sigue el proceso completo. Si ya se reportó, se compara con el que está guardado: llegando igual responde 200 con el estado del documento, su UUID y el documento adjunto, sin volver a reportarlo ni gastar otro consecutivo; llegando con datos distintos responde 409 con la regla 90 de la DIAN y entrega el XML del documento que sí quedó reportado. Para el documento nuevo siguen las validaciones: un incumplimiento responde 400 con una entrada por regla, cada una con su código de la DIAN, su código de InSoft y su mensaje. Solo cuando las pasa se construye el documento electrónico, se firma, se reporta a la DIAN y se espera su respuesta. Si la DIAN lo rechaza, el 400 trae sus mensajes; si no se pudo establecer conexión con ella, responde también 400 pidiendo reintentar más tarde, y en ese caso el documento no quedó reportado. Las validaciones van antes de construir, así que un documento que no va a ser aceptado se rechaza sin gastar un consecutivo.

Emisión de un documento a la DIANLo primero que se mira es la numeración del documento. Si nunca se reportó, el documento sigue el proceso completo. Si ya se reportó, se compara con el que está guardado: llegando igual responde 200 con el estado del documento, su UUID y el documento adjunto, sin volver a reportarlo ni gastar otro consecutivo; llegando con datos distintos responde 409 con la regla 90 de la DIAN y entrega el XML del documento que sí quedó reportado. Para el documento nuevo siguen las validaciones: un incumplimiento responde 400 con una entrada por regla, cada una con su código de la DIAN, su código de InSoft y su mensaje. Solo cuando las pasa se construye el documento electrónico, se firma, se reporta a la DIAN y se espera su respuesta. Si la DIAN lo rechaza, el 400 trae sus mensajes; si no se pudo establecer conexión con ella, responde también 400 pidiendo reintentar más tarde, y en ese caso el documento no quedó reportado. Las validaciones van antes de construir, así que un documento que no va a ser aceptado se rechaza sin gastar un consecutivo.SÍNOSÍNONOSÍNOSÍEl documento llega en JSON¿Ya se reportó esanumeración?¿Llega igualque antes?¿Cumple las reglas?200Estado, UUID y documentoadjunto, sin volvera reportarlo409Regla 90 · entrega el XMLdel documentoConstruye el documentoy lo firma, lo reportay espera a la DIAN400Una entrada por reglaincumplida, con su códigoDIAN y su código InSoft¿La DIAN lo aceptó?400El rechazo de la DIAN, o«intente más tarde» sino hubo conexión200Estado del documento, su UUIDy el documento adjuntoLEYENDAInicio y finPasoDecisiónError

Desliza el diagrama para verlo completo.

Ver la fuente Mermaid del diagrama
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"])

Datos que recibe

Encabezado

DatoTipoDescripción
Authorization*string

Credencial de la petición, con el prefijo Bearer. En el sandbox la pone el portal por ti y la renueva antes de cada ejecución; en producción la controlas tú, con el JWT que genera tu integración a partir de sus credenciales — ver Credenciales y JWT.

Ejemplo:Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6...

Cuerpo

DatoTipoDescripción
tddocumentoelectronico*string

Tipo de documento de nómina.

Ver los 2 valores admitidos
  • 102 · Documento soporte de pago de nómina electrónica
  • 103 · Nota de ajuste de nómina electrónica
numerodocumentostring

Número del documento: prefijo más consecutivo. La numeración es automática: si el campo no viaja, el sandbox lo numera con su prefijo y su propio consecutivo, y es lo que hacen los ejemplos. Ojo con la diferencia frente a facturación: allá la numeración automática se pide con el valor <auto>, y aquí se pide omitiendo el campo — un <auto> en nómina llegaría tal cual a la DIAN, que solo admite alfanuméricos.

Ejemplo:SBX1

fechadocumentodate-time

Fecha y hora de generación del documento. Es opcional: si no la envías, el PT le asigna la de ahora, el momento en que recibe el documento, y es lo que hacen los ejemplos. Si la envías, va en ISO 8601 con zona (2026-08-31T18:00:00-05:00).

Ejemplo:2026-08-31T18:00:00-05:00

empleador*TTercero

Empresa que paga la nómina. En el sandbox su identidad se reemplaza por la de la empresa de pruebas.

trabajador*TTrabajador

Empleado al que se le paga. El sandbox no lo reemplaza: es el dato que se controla por completo en la prueba.

trabajador.tdtrabajador*string

Tipo de trabajador según el catálogo de la DIAN.

Ver los 6 valores admitidos
  • 01 · Dependiente
  • 02 · Servicio domestico
  • 04 · Madre comunitaria
  • 12 · Aprendiz del SENA en etapa lectiva
  • 19 · Aprendiz del SENA en etapa productiva
  • 51 · Trabajador de tiempo parcial
trabajador.tdcontrato*number

Tipo de contrato laboral.

Ver los 5 valores admitidos
  • 1 · Termino fijo
  • 2 · Termino indefinido
  • 3 · Obra o labor
  • 4 · Aprendizaje
  • 5 · Practicas o pasantias
trabajador.baltoriesgoboolean

Indica si el trabajador está afiliado a pensión de alto riesgo.

trabajador.bsalariointegralboolean

Indica si devenga salario integral. Cambia la base de aportes que valida la DIAN.

periodoliquidar*TPeriodo

Rango del periodo liquidado, con fechainicial y fechafinal en ISO 8601.

periodocontrato*TPeriodo

Vigencia del contrato, en ISO 8601. fechainicial es obligatoria; fechafinal es la fecha de retiro, y en el XML sale como FechaRetiro. Los ejemplos publican un contrato vigente con una fecha lejana (2099-01-01), de modo que cubra todo el periodo que liquidan; si el trabajador sigue activo también puedes omitirla, y entonces el documento va sin fecha de retiro.

lugargeneracion*TUbicacion

Municipio donde se genera el documento, con su código de municipio (17001) y de departamento (17).

notasArray<string>

Observaciones libres del documento.

tdnota*number

Tipo de ajuste que se reporta sobre el documento referenciado.

Ver los 2 valores admitidos
  • 1 · Reemplazar — corrige el documento con la liquidación correcta
  • 2 · Eliminar — anula el documento sin reemplazarlo
docreferencia*TDocumentoElectronico

Documento de nómina al que aplica la nota, con su numerodocumento, su fechadocumento —en ISO 8601— y su uuid. El uuid es el CUNE que la DIAN calculó al reportar ese documento, no un dato que se escriba: lo entrega la respuesta del envío. Por eso el ejemplo no trae uno: lleva un marcador que hay que reemplazar. Primero envía una nómina electrónica, copia el CUNE de su respuesta y pégalo aquí.

Lo que el sandbox fuerza

El sandbox emite con una integración y una empresa de pruebas compartidas por todos los desarrolladores. Lo que envíes en estos campos no se usa: se sustituye antes de reportar el documento a la DIAN. Todo lo demás viaja tal como lo dejes.

  • tdambiente
    2 — Pruebas (habilitación)

    El sandbox solo emite contra el ambiente de habilitación de la DIAN, sin importar lo que llegue en el documento.

  • empleador.nit
    NIT de la empresa de pruebas

    Es el único NIT que el sandbox tiene habilitado ante la DIAN. El resto del empleador viaja como lo envíes.

  • resolucion.prefijo
    El prefijo del número enviado, o el configurado en el sandbox

    La DIAN no exige resolución de nómina en habilitación. Si falta el prefijo, el sandbox lo deduce del numerodocumento; si tampoco viene, usa el suyo.

  • numerodocumento
    Prefijo más el siguiente consecutivo del sandbox

    Cuando el campo no viaja, que es como lo publican los ejemplos: así el documento queda numerado de forma consistente sin que tengas que conseguirte un consecutivo. Ojo con la diferencia frente a facturación, que en su lugar reconoce el valor <auto>.

Ejecutar la función

Ambiente de habilitación de la DIAN · los documentos son reales pero no tienen efectos tributarios

Antes de ejecutar esta función hace falta un documento que anular. El uuid de docreferencia es el CUNE que la DIAN calcula al reportar la nómina, de modo que no hay forma de escribirlo: hay que generarlo. El orden es enviar una nómina electrónica, tomar el uuid que traiga su respuesta y pegarlo aquí antes de enviar la nota.

Lo que se envía

Anula el documento referenciado. Sin devengos ni deducciones.

Documento que se envía — editalo para armar tu caso de prueba
Se enviara POST https://proveedortecnologico-sandbox.azurewebsites.net/api/DocumentoNE

Es la URL del sandbox y no corresponde a la etapa productiva de la integración. La URL base de producción se te entrega al adquirir el servicio. Lo que si es igual en los dos es la ruta.

Respuesta

Aquí queda tu ejecución: la ruta que viajó, el cuerpo que enviaste, el código con el que respondió el sandbox y el tiempo discriminado. Un error también queda: es lo que se necesita junto al cuerpo que lo produjo.

Exportar a Postman

Descarga esta función como colección de Postman, con los valores que tienes ahora en la barra y tu credencial vigente: se importa y se envía sin configurar nada.

Respuestas

  • 200 La DIAN recibió el documento. En respuesta viajan el CUNE generado, el estado de la DIAN y sus mensajes de validación.
  • 400 El documento no paso las validaciones del PT o de la DIAN. El mensaje indica la regla incumplida.
  • 401 La credencial no llegó, ya venció, o la cuenta no tiene perfil registrado en el sandbox. En producción es además el código con el que se rechaza un emisor que la credencial no tiene autorizado — ver Credenciales y JWT.
  • 500 Falla al firmar o al comunicarse con la DIAN.

Errores frecuentes

  • 400 El documento referenciado no existe en la DIAN

    El CUNE de docreferencia no corresponde a un documento reportado en ese ambiente.

  • 401 El desarrollador autenticado no tiene un perfil registrado en el sandbox

    La cuenta se autenticó pero nunca completó el registro de desarrollador. Se resuelve diligenciando el perfil desde el portal.

  • 400 El total devengado no corresponde con los conceptos reportados

    La DIAN recalcula el devengado y el deducido desde los conceptos. Un concepto con valor que no cuadra con su cantidad y su porcentaje produce este rechazo.

  • 400 Los días laborados no corresponden con el periodo liquidado

    qdiaslaborados es incompatible con el rango de periodoliquidar. La DIAN cuenta el mes comercial de 30 días.

  • 500 El sandbox no tiene registrada la configuración SANDBOX - CONFIG-NE

    Es un problema de montaje del ambiente, no de la petición. Hay que reportarlo al equipo de InSoft.

Ten en cuenta

  • El CUNE no se escribe: se calcula. Lo calcula la DIAN al reportar el documento, de modo que el flujo para probar la eliminación son dos envíos: primero una nómina electrónica, y después esta nota con el CUNE que devolvió esa respuesta en docreferencia.uuid.
  • Una nómina eliminada no se puede volver a emitir con el mismo número: hay que numerar la nueva con otro consecutivo.
  • El trabajador no se reemplaza. Es una persona natural que define el desarrollador como parte de su caso de prueba, y la DIAN no lo valida contra la empresa habilitada.
  • La resolución de nómina tampoco se fuerza: la DIAN no la exige en el ambiente de habilitación.
  • Los devengos y las deducciones viajan sin modificación. Ahí es donde se prueba de verdad la liquidación.
  • El sandbox emite con una integración compartida por todos los desarrolladores. El token con el que se reporta a la DIAN lo abre el propio servicio y nunca sale hacia el navegador.