Nota debito con descuento en la linea

POST /api/ubl2.1/debit-note/:testSetId

PRIMER ENVIO DE NOTA DEBITO

Requiere el token de la empresa en el header Authorization: Bearer {api_token}. Ese token se entrega en la respuesta del Paso 1 - Config Company; si se extravio, se cambia con el comando php artisan api:rotate-token {nit} o con PUT /api/ubl2.1/config/rotate-token/{nit} usando el header X-Admin-Token.
Requiere la resolucion de nota de debito configurada en el Paso 4 de la seccion 01B. Si la empresa tiene mas de una resolucion de nota de debito, se debe enviar el campo resolution_number para indicar cual se utiliza.
El bloque billing_reference identifica la factura que se esta corrigiendo con su number, uuid (el CUFE) e issue_date. Si la nota debito no hace referencia a una factura se omite ese bloque.
Los campos discrepancyresponsecode y discrepancyresponsedescription corresponden al motivo de la nota debito segun la tabla 13.3.1 de la DIAN.
En URL el ultimo parametro corresponde al id del set de pruebas que la dian entrego al momento de registrar el modo de operacion software propio.

.../ubl2.1/debit-note/iddelsetdepruebasdeladian

El modo sincrono no afecta al set de pruebas, pero la respuesta de la DIAN incluye posibles errores de validacion y el estado de la nota debito, valida o no valida.
El modo asincrono, afecta el set de pruebas y en la respuesta no se incluye el resultado de la nota debito, solo se entrega un ZIP_KEY el cual debe ser consultado mediante el endpoint:

.../ubl2.1/status/zip

de la seccion 03 - Consultas de estado para asi poder establecer si la nota debito fue valida o no y los errores de validacion.

Request

Successful response