Skip to main content
POST
Crea y emite una Nota de Credito o Debito contra una factura original validada por el SIAT. La nota permite ajustar montos por devoluciones parciales o totales.
La factura original debe estar en estado VALIDATED. No se puede emitir una nota contra facturas rechazadas, anuladas o pendientes.

Path Parameters

Headers

Request Body

returnedDetails[]

Notas Descuento e ICE (sectores 47 y 48)

Ademas de la nota estandar (24), el campo documentSectorType permite emitir dos variantes especializadas:
No re-envies las lineas de la factura original. En los tres sectores, las lineas originales (codigoDetalleTransaccion=1) se clonan automaticamente desde la base de datos — espejan exacto la factura registrada en SIAT. Enviar tus propias lineas originales causaba rechazos SIAT [1049] (detalle diferente) y [1030] (monto original erroneo). Ahora solo mandas los items devueltos en returnedDetails.

Sector 47 — solo returnedDetails

Identico al 24 a nivel de request: mandas unicamente returnedDetails. El campo originalDetails, si viene, se ignora.

Sector 48 — returnedDetails + overlay ICE

La compra-venta original no almacena los montos ICE, asi que en el sector 48 esos numeros si vienen del request, en originalDetails, como un overlay minimal matcheado por nroItem. La base (actividad/producto/descripcion/cantidad/precio) se toma de la BD; en originalDetails solo importan los campos ICE:
En sectores 47/48, cada returnedDetails[].nroItem tambien referencia el lineNumber de la linea original que se devuelve (para el prorrateo del descuento). Consulta los numeros de linea de la factura original con GET /api/v1/invoices/{id}details[].lineNumber.
Ejemplo originalDetails (sector 48)
Modo estructural: si la factura original no tenia ICE, envia marcaIce: 2 con montos en 0. La nota se emite con la estructura ICE requerida por el XSD del sector 48 pero sin monto ICE real.

Comportamiento

  1. El sistema obtiene automaticamente los datos de la factura original (cliente, CUF, montos)
  2. Los returnedDetails se marcan con codigoDetalleTransaccion=2 (devolucion)
  3. Los items originales se clonan desde la base de datos con codigoDetalleTransaccion=1 (nunca del request)
  4. Se calcula: montoTotalOriginal, montoTotalDevuelto, montoDescuentoCreditoDebito, montoEfectivoCreditoDebito
  5. La nota se envia al SIAT via el WSDL de documento de ajuste (sector 24/47/48 segun documentSectorType)
  6. Se genera PDF (A4 + ticket opcional), XML y se envia email al cliente
Si la factura original tiene items con montoGiftCard > 0, el paymentMethodCode debe incluir el codigo 27 (Gift Card). Error SIAT 1050 si se omite.
La nota genera su propio CUF unico. Puedes acceder a ella via /f/{cuf} o los endpoints publicos, igual que una factura regular.
Seguridad — ofuscacion de tarjeta. Si envias cardNumber, la API conserva solo los 4 primeros y 4 ultimos digitos y reemplaza el resto por ceros antes de persistir y emitir el XML SIAT (ej: 41111111111111114111000000001111). El numero completo (PAN) nunca se guarda en la base de datos ni viaja al SIAT. Numeros de 8 digitos o menos se dejan tal cual.