Saltar a contenido

Recepción: los e-CF que le envían sus proveedores

Ser emisor electrónico también obliga a recibir e-CF de terceros. De esa parte se encarga esta API: exponemos los servicios que el estándar define (/fe/recepcion/api/ecf y /fe/aprobacioncomercial/api/ecf), respondemos el Acuse de Recibo firmado (ARECF) y archivamos lo recibido. A usted le quedan dos recursos:

Endpoint Para qué Permiso
GET /api/v1/received-documents Ver los e-CF que sus proveedores le enviaron (los 100 más recientes). received:read
POST /api/v1/received-documents/{eNCF}/commercial-approval Aceptar o rechazar comercialmente uno de esos e-CF. received:approve

Ambos actúan en nombre de su empresa, declarada con el parámetro emisor_rnc de la consulta (en el listado) o con emisor.rnc en el cuerpo JSON (en la aprobación) (autenticación): aquí no hay identificador con prefijo, porque el comprobante es de un tercero.

El acuse y la aprobación son cosas distintas. El acuse de recibo (automático, al llegarnos el XML) sólo dice que el comprobante llegó firmado y válido en forma. La aprobación comercial es su conformidad con la operación, y es opcional: se puede aceptar, rechazar (con motivo) o no pronunciarse nunca.

Listado de recibidos

GET /api/v1/received-documents?emisor_rnc=133802074
Authorization: Bearer <su-token>

{
  "status": "success",
  "message": "Consulta exitosa.",
  "data": [
    {
      "id": 512,
      "emisor_rnc": "131880738",
      "ecf_type_code": "31",
      "e_ncf": "E310000000099",
      "total_amount": 2360,
      "recibido": true,
      "motivo_no_recibido": null,
      "acuse_emitido_en": "10-08-2026 09:14:22"
    },
    {
      "id": 511,
      "emisor_rnc": "131888888",
      "ecf_type_code": "32",
      "e_ncf": "E320000000043",
      "total_amount": 1180,
      "recibido": false,
      "motivo_no_recibido": 3,
      "acuse_emitido_en": "10-08-2026 08:59:01"
    }
  ]
}
Campo Qué es
id Identificador interno del registro recibido.
emisor_rnc ⚠️ El RNC del proveedor que envió el e-CF — no confundirlo con el emisor_rnc de la petición, que es el de su empresa.
ecf_type_code Tipo del e-CF recibido (31, 32, …).
e_ncf El número del comprobante que le facturaron.
total_amount Monto total del comprobante recibido.
recibido true = acusamos recibo (llegó firmado y válido en forma); false = se rechazó con el motivo de al lado.
motivo_no_recibido Código del motivo cuando recibido es false (ver tabla).
acuse_emitido_en Cuándo se emitió el acuse (d-m-Y H:i:s).

Sin paginación ni filtros: devuelve los 100 más recientes (por la fecha del acuse), y cada elemento es el resumen justo para un listado.

Motivos de no recepción que pueden aparecer en el listado:

Código Motivo
3 Envío duplicado: ya habíamos recibido ese e-NCF.
4 El comprador del e-CF no corresponde a su empresa.

Los motivos 1 (no cumple la especificación) y 2 (firma no válida) no se guardan: un XML sin firma de confianza no llega a registrarse, así que nunca aparece en este listado.

Que un e-CF esté aquí no demuestra que la DGII lo aceptó: demuestra que llegó firmado. Para comprobar su validez fiscal, GET /api/v1/received-documents/{eNCF}/dgii-status (consultas-dgii.md).

El listado no trae track_id: un comprobante recibido no es una emisión suya y no hay ningún TrackID que mostrarle. El TrackID que tendría ese e-CF es el que la DGII le dio a su emisor (a su proveedor) al transmitirlo; por eso la validez fiscal se consulta con el RNC del emisor y el e-NCF, y en esa respuesta el RNC que aparece es el del proveedor. Cuándo aparece el track_id y cuándo no, en estados.md.

Aprobación comercial

Acepta o rechaza la transacción de un e-CF recibido. Al emitirla, construimos el ACECF, lo firmamos y lo transmitimos a la DGII. El ACECF identifica el comprobante con el RNC del emisor (su proveedor) y el e-NCF, y su empresa figura como compradora.

POST /api/v1/received-documents/E310000000099/commercial-approval
Authorization: Bearer <su-token>
Content-Type: application/json

{
  "emisor": { "rnc": "133802074" },
  "estado": 1,
  "motivo_rechazo": null
}
Campo Reglas
emisor.rnc Su empresa (la que recibió), como en todo cuerpo JSON (autenticación).
estado 1 acepta la operación, 2 la rechaza.
motivo_rechazo Obligatorio si estado es 2; texto libre de hasta 250 caracteres.

Respuesta 202:

{
  "status": "success",
  "message": "Aprobación comercial emitida y transmitida a la DGII.",
  "data": {
    "e_ncf": "E310000000099",
    "estado": 1,
    "motivo_rechazo": null,
    "aceptada_por_dgii": true,
    "mensajes_dgii": [],
    "emitida_en": "10-08-2026 10:03:44"
  }
}
  • No hay TrackID en la aprobación comercial, ni en la respuesta ni después: el servicio de la DGII la resuelve en la misma llamada (como el resumen RFCE) y el campo queda null siempre. Lo que confirma la transmisión es aceptada_por_dgii (el código de la DGII: true = la recibió como aprobada, false = la recibió como rechazada) y, si la DGII advirtiera algo, mensajes_dgii. Cuándo aparece el track_id (nunca en el 202, llega al transmitir y jamás en el resumen RFCE), en estados.md.
  • Es idempotente en la práctica: reintentar con el mismo estado devuelve la aprobación ya emitida, no una segunda.

Errores

Código Cuándo
404 Ese e-NCF no consta como recibido para su empresa: «No se encontró el e-CF recibido.», con el texto largo en data.detalle.
422 Validación: falta estado, motivo_rechazo al rechazar, etc. → data.detalle y data.errores por campo (cómo leerlos).
422 Reglas de negocio, en data.detalle: rechazar sin motivo, aprobar un e-CF que no superó el acuse (recibido: false), o volver a aprobar con otro estado (la conformidad se declara una sola vez).
503 El servicio de la DGII no está disponible; reintente (envelope).
401/403 Token o permisos, como en toda la API (autenticación).

Referencias