Saltar a contenido

Historial de cambios

Qué cambió en la API y en esta documentación, del más reciente al más antiguo, para que un integrador sepa de un vistazo qué es nuevo y desde cuándo. Cada sección con fecha es una «versión» de la documentación; los cambios que no afectan la integración (certificación, infraestructura, código interno) no se listan.

Cómo se actualiza

Todo cambio en la documentación o en el contrato público de la API se registra aquí el mismo día. Si la fecha del cambio no existe, se crea la sección arriba del todo. Un cambio sin su entrada en este historial no se considera terminado.

2026-10-09

  • Los ejemplos curl y las peticiones HTTP de la guía ya usan el host real del entorno de pruebas (https://endpoint-test.emision.do, el APP_URL del servidor) en lugar del comodín <su-host>: se pueden copiar y ejecutar tal cual.

  • Paleta de marca aplicada al sitio: azul #18224C de primario, cian #00D0FF de acento y los planos verde #579601 y violeta #5F4EDA en los avisos; títulos en azul de marca, cabeceras de tabla y tipografía Poppins. La paleta vive en docs/stylesheets/marca.css y vale para claro y oscuro.

  • Nuevo historial de cambios en docs/cambios.md, visible en el menú del sitio: desde hoy, todo cambio de la documentación se registra aquí el mismo día.
  • La columna «Descripción» de la representación impresa (PDF) imprime nombre - descripcion cuando el ítem lleva ambos campos; si llega uno solo, ese; si son iguales, una vez. Los PDF ya emitidos se regeneran con dgii:regenerate-pdf sin tocar la DGII.
  • comprador.correo y emisor.correo admiten varios correos separados por «;», validados uno a uno: los del emisor se construyen en CC y los del comprador en TO al entregar por correo. El correo de la ficha de la empresa se usa como respaldo del emisor.
  • Aclarado el ciclo del track_id: cuándo aparece, cuándo no (p. ej. el 32 bajo umbral transmitido como resumen RFCE) y en qué momento llega. Todos los ejemplos incluyen el nodo emisor.
  • Página de recepción de e-CF puesta al día: rutas, autenticación y enlaces cruzados.

2026-10-08

  • Envelope único de respuesta en todas las rutas /api/* (ADR 0005): siempre status, message y data o document; los errores de validación y del framework hablan el mismo idioma.
  • Un e-CF se consulta por su identificador (RNCEmisor + e-NCF) y el detalle trae los archivos en base64 (XML, PDF, respuesta de la DGII); desaparecen las descargas por URL firmada (ADR 0004). La Bóveda y «Mis documentos» del facturador consumen ese detalle.
  • El resumen RFCE no tiene TrackID: consultar sus track-ids responde 200 con envios vacío (la DGII contesta «TrackId no encontrado»). Tabla única con todos los recursos de consulta.
  • Colección Postman: carpeta de consultas completa y ejemplo del tipo 32 con dos productos.

2026-10-07

  • El emisor se declara en el cuerpo de la petición (emisor.rnc, RNCEmisor o emisor_rnc); la cabecera X-Emisor-RNC desaparece (ADR 0003). Las respuestas de recibidos traen emisor_rnc.
  • Entrega por correo: cuando el receptor no es electrónico se envía la representación impresa, y cuando hay correo se adjuntan el PDF y el XML firmado.
  • Modelo de aliados desplegado en pruebas y producción: un token por aliado (no por empresa), GET /api/v1/companies y atribución de documentos (ADR 0002).
  • La autenticación que expone el servicio de recepción acepta certificados con pasaporte en el SN.

2026-10-06

  • Un token ausente o inválido responde 401 (con el motivo), nunca 500.
  • El QR de la representación impresa omite el parámetro del RNC del comprador cuando no hay comprador.

2026-10-05

  • La numeración la lleva el cliente: el API recibe el e-NCF completo y ya no reserva números.

2026-09-18

  • Se publica el sitio de documentación para integradores, con sólo el contenido del cliente.
  • «Mis documentos» (bóveda): listado de emitidos y descarga de sus artefactos para el portal y el facturador.
  • Cada token declara qué puede hacer (abilities); el emisor se declara en el JSON y se contrasta con la credencial.
  • Colección de Postman con los 23 endpoints, importable tal cual.

2026-09-07

  • El e-NCF lo puede traer el integrador, y el comprador llega completo a la representación impresa.

2026-08-28

  • Documentación de integración completa y publicable (primera versión del sitio).

2026-08-13

  • La anulación de secuencias deja rastro antes de transmitir y los procesos de fondo se pueden vigilar.

2026-08-12

  • Consulta de estado por e-NCF y consulta de TrackIDs.
  • Modo XML passthrough: el integrador envía su propio XML firmado y el API lo valida y transmite.
  • Directorio de facturadores electrónicos, que resuelve el camino de entrega del comprobante.
  • Anulación de secuencias e-NCF (ANECF).
  • Entrega del e-CF al receptor con reintentos para lo que sí se reintenta.

2026-08-11

  • Servicio de autenticación del receptor (la tercera URL que exige la certificación).
  • Campos de referencia del ítem para el ISC de alcoholes, cervezas y tabaco.

2026-08-04

  • Gestión del certificado propio del emisor (.p12) por la API.
  • Identificadores del código a inglés y reglas de subtotales corregidas.

2026-08-03

  • Rutas de la API en inglés y documentada la recepción para integradores.
  • RFCE: el tipo 32 bajo el umbral se transmite como resumen, no como e-CF completo.

2026-08-01

  • Reglas transversales implementadas: el ISC entra en la base del ITBIS por línea, tope de la nota de crédito y corrección de texto.

2026-07-31

  • Documentación de integración por tipo (31, 32, 33, 34) con ejemplos JSON verificados.

2026-07-29

  • Representación impresa del e-CF conforme a la norma DGII (Informe Técnico §18).

2026-07-24

  • Los tipos de e-CF 32 a 47 validan su XML contra el XSD de la DGII.

2026-07-23

  • Primer hito: autenticación semilla → token y primeras rutas de emisión.