Generar el XML sin reportarlo
Construye y firma el XML de un documento de nómina o de su nota de ajuste, sin enviarlo a la DIAN.
/api/xmlNE Genera el documento de nómina firmado y se detiene antes de reportarlo. La respuesta es el XML, con Content-Type: application/xml.
Es por donde conviene empezar a integrar nómina: no gasta consecutivos y no deja nada registrado en la DIAN, así que se puede repetir cuantas veces haga falta para comparar el XML propio con el que arma el PT, y para ver el CUNE que tendría el documento. Atiende los tres documentos del grupo — el tddocumentoelectronico, junto con el tdnota en las notas, decide cuál se genera.
Cómo resuelve el sandbox esta función
Recorre el mismo camino de la emisión pero se detiene antes de la DIAN. Con el documento en JSON calcula el UUID que tendría —CUFE, CUDE o CUDS— y lo valida contra las reglas: si alguna se incumple responde 400 con una entrada por regla, cada una con su código y su mensaje. Si las cumple, construye el documento electrónico, lo firma y devuelve el XML como application/xml, no como JSON: la respuesta es el documento mismo y no un objeto que lo envuelva. El documento no se reporta, así que no gasta consecutivos y la prueba se puede repetir sin costo. A diferencia de la emisión, aquí solo se fuerza el ambiente: no se reemplazan emisor, receptor ni resolución, y la contrapartida es que el CUFE obtenido es el real solo si la resolución y su clave técnica son las verdaderas del emisor.
Desliza el diagrama para verlo completo.
Ver la fuente Mermaid del diagrama
flowchart TD
A(["El documento llega en JSON"]) --> D["Calcula el UUID del documento<br/>CUFE · CUDE · CUDS"]
D --> F{"¿Cumple las reglas?"}
F -- No --> G(["400 · una entrada por regla incumplida,<br/>con su código DIAN y su código InSoft"])
F -- Sí --> H["Construye el documento electrónico<br/>y lo firma"]
H --> J(["200 · el XML firmado, no se reporta a la DIAN<br/>application/xml"])Datos que recibe
Encabezado
Cuerpo
Lo que el sandbox fuerza
El sandbox firma con las credenciales de habilitación, compartidas por todos los desarrolladores. Lo que envíes en estos campos no se usa: se sustituye antes de construir el documento. Todo lo demás viaja tal como lo dejes.
tdambiente2 — Pruebas (habilitación)El XML se firma con las credenciales de habilitación del sandbox. Un documento marcado como de producción firmado con esas credenciales sería inválido, de modo que el ambiente se fuerza antes de construirlo.
Ejecutar la función
Ambiente de habilitación de la DIAN · el XML se firma pero no se reporta, no gasta consecutivos Lo que se envía
El mismo documento del envío, con la numeración que esta función exige: al generar el XML el empleador y el trabajador viajan tal como los envíes, sin reemplazo.
PATCH https://proveedortecnologico-sandbox.azurewebsites.net/api/xmlNE Respuesta
Exportar a Postman
Respuestas
-
200El cuerpo es el XML firmado del documento, conContent-Type: application/xml. No viene envuelto en la estructura estándar del PT. -
400El documento no paso la verificación. Enrespuesta.erroresviaja un elemento por regla incumplida, concodigodian,codigoinsoftymensaje. -
401La 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. -
500Falla al firmar el documento.
Errores frecuentes
-
400El documento electrónico no ha pasado el proceso de verificaciónEs la respuesta de toda regla incumplida. A diferencia del envío, aquí el detalle viene desglosado: cada error trae el código de la regla de la DIAN, el código interno de InSoft y la descripción de que corregir.
-
401El desarrollador autenticado no tiene un perfil registrado en el sandboxLa cuenta se autenticó pero nunca completó el registro de desarrollador. Se resuelve diligenciando el perfil desde el portal.
Ten en cuenta
- Esta función no reemplaza nada del documento salvo el ambiente. El empleador viaja tal como lo envíes, a diferencia del envío, que lo sustituye por la empresa de pruebas. Es lo que la hace útil para comparar tu XML con el del Proveedor Tecnológico.
- El XML se firma con las credenciales de habilitación del sandbox, comunes a todos los desarrolladores. En producción se firma con las del empleador real, que administra el Proveedor Tecnológico.
- En producción la ruta es una sola,
PATCH /api/xml. El tipo de documento del cuerpo es el que decide qué se genera, igual que aquí. - El XML se genera en UTF-8, y así lo declara el propio documento en su primera línea. Léelo y guárdalo con esa codificación: interpretado con otra, cada tilde y cada
ñse convierten en dos caracteres raros y la firma deja de validar. - 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.