e-CF 32 — Factura de Consumo Electrónica¶

POST /api/v1/documents/32
Authorization: Bearer <su-token>
Content-Type: application/json

El emisor.rnc del cuerpo dice de qué empresa es el comprobante y, a la vez, en nombre de quién se emite: la API comprueba que su token esté habilitado para esa empresa (cómo funciona).

Es el comprobante de las ventas a consumidor final (B2C): el mayor volumen de la operación diaria. No sustenta crédito fiscal, por eso identificar al comprador es opcional… salvo que el monto llegue al umbral.

El umbral de RD$250.000 lo cambia todo¶

Este es el punto que más confunde. El comportamiento del tipo 32 depende de totales.monto_total:

	Por debajo de RD$250.000	Igual o por encima de RD$250.000
Comprador	Opcional (venta a consumidor final)	Obligatorio (`rnc` y `razon_social`)
Líneas de detalle	Hasta 10.000	Hasta 1.000
Numeración	`id_doc.e_ncf` obligatorio; sin fecha de vencimiento de la secuencia (no aplica)	Igual
Cómo se transmite	Como resumen (RFCE) al servicio de la DGII para facturas de consumo	Como e-CF completo
Timbre del QR	`ConsultaTimbreFC` con 4 parámetros	`ConsultaTimbre` con 7 parámetros
TrackID	No existe, nunca (`track_id` queda `null` para siempre)	Sí: llega al transmitirse y el documento pasa a `in_process_dgii`
Cuándo se resuelve	En la misma llamada a la DGII (segundos)	Después, por sondeo del TrackID (automático)

Usted envía el mismo JSON en ambos casos: nosotros decidimos cómo transmitirlo según el monto. Por debajo del umbral firmamos y conservamos el e-CF completo (que es su obligación conservar) y a la DGII le remitimos únicamente el resumen, que referencia el código de seguridad del comprobante completo. Todo esto es transparente para su integración, con una excepción que conviene tener clara: el TrackID.

El resumen (RFCE) no tiene TrackID¶

Una factura de consumo por debajo de RD$250.000 viaja a la DGII como resumen (RFCE), y el servicio de resúmenes no devuelve TrackID: contesta el resultado final (aceptado, aceptado condicional o rechazado) en la propia llamada. No hay nada que sondear después, y por eso el campo track_id de ese documento queda null para siempre. No es un fallo ni algo pendiente.

Dos cosas distintas, que no hay que confundir:

Dónde ve `"track_id": null`	Qué significa
En la respuesta `202` de `POST /api/v1/documents/32`	Es así en todos los tipos, también en los que sí tendrán TrackID: el `202` sólo confirma que recibimos, validamos y encolamos el comprobante; la transmisión a la DGII ocurre después, en segundo plano, y en ese instante todavía no puede existir.
En `GET /api/v1/documents/{identificador}`, con el documento ya `accepted_dgii`	Es lo esperado en un 32 bajo el umbral: el resumen no genera TrackID. En los demás tipos (y en el 32 de RD$250.000 o más) aquí ya vendría el TrackID.

La tabla completa de cuándo aparece (o no) el TrackID está en estados.md.

Cómo seguir un 32 de consumo, entonces: por su identificador (cómo se arma): el RNC de su empresa y el e-NCF, que usted ya tiene. No espere un TrackID para consultarlo:

GET /api/v1/documents/133802074E320000000043
Authorization: Bearer <su-token>

Consulte cada pocos segundos hasta que status sea un estado final: normalmente pasa de received a accepted_dgii (o rejected_dgii) en pocos segundos, sin pasar por TrackID. Cuando queda aceptado se genera la representación impresa y, si corresponde, se envía el correo al comprador (los campos entrega_al_receptor y correo_al_comprador de la misma respuesta lo dicen). En esa misma respuesta, ya aceptado, vienen sus archivos en base64: el xml (el e-CF completo que usted debe conservar), el resumen_rfce (lo que se transmitió a la DGII) y el pdf (mis-documentos.md). Si desea preguntarle directamente a la DGII, use GET /api/v1/documents/{identificador}/dgii-status, que sí sirve para el resumen; track-ids, en cambio, no tiene nada que mostrar para él. Todos los recursos de consulta están en «Consultar qué pasó con un documento» y los de la DGII, con su detalle, en consultas-dgii.md.

Particularidades¶

Aspecto	Regla
Comprador	Opcional por debajo del umbral. Puede usar `identificador_extranjero` si no hay RNC.
Bonos y certificados de regalo	Es el único tipo que admite la forma de pago `5`.
Venta de un bono	Use `indicador_facturacion: 0` (No facturable): no es una venta de bien ni servicio todavía.
`referencia`	Opcional.

Ejemplo mínimo (consumidor final)¶

Sin bloque comprador: es una venta de mostrador.

{
  "emisor": {
    "rnc": "133802074"
  },
  "id_doc": {
    "e_ncf": "E320000000001",
    "indicador_monto_gravado": 0,
    "tipo_ingresos": "01",
    "tipo_pago": "1",
    "formas_pago": [
      { "forma": "1", "monto": 590.00 }
    ]
  },
  "items": [
    {
      "nombre": "Camisa",
      "cantidad": 10,
      "unidad_medida": "34",
      "precio_unitario": 50.00,
      "monto": 500.00,
      "indicador_facturacion": 1,
      "indicador_bien_servicio": "1"
    }
  ],
  "totales": {
    "monto_gravado_total": 500.00,
    "itbis1": 18,
    "total_itbis": 90.00,
    "monto_total": 590.00,
    "monto_gravado_i1": 500.00,
    "total_itbis1": 90.00
  }
}

Archivo: ejemplos/ecf-32-minimo.json

Ejemplo: venta de un bono de regalo¶

Al vender el bono todavía no hay transferencia de bienes ni prestación de servicios (Norma General 03-08), así que la línea va como no facturable (indicador_facturacion: 0).

{
  "emisor": {
    "rnc": "133802074"
  },
  "id_doc": {
    "e_ncf": "E320000000002",
    "tipo_ingresos": "01",
    "tipo_pago": "1",
    "formas_pago": [ { "forma": "1", "monto": 2000.00 } ]
  },
  "items": [
    {
      "nombre": "Bono de regalo",
      "cantidad": 1,
      "unidad_medida": "43",
      "precio_unitario": 2000.00,
      "monto": 2000.00,
      "indicador_facturacion": 0,      // No facturable
      "indicador_bien_servicio": "1"
    }
  ],
  "totales": {
    "monto_no_facturable": 2000.00,
    "monto_total": 0.00               // ¡ojo! ver la nota de abajo
  }
}

Archivo: ejemplos/ecf-32-bono.json

⚠️ monto_total va en 0. La fórmula normativa es monto_total = gravado + exento + total ITBIS + impuesto adicional, y el monto no facturable no forma parte de ella. El valor cobrado se refleja en monto_no_facturable y en las formas de pago. Si pone monto_total: 2000.00, la validación de cuadratura lo rechazará con 422.

Cuando el cliente redime el bono, emite una Factura de Consumo normal por los bienes entregados y registra el bono como forma de pago 5.

Respuesta¶

Idéntica a la del tipo 31, con ecf_type_code: "32". Recuerde que track_id llega null en el 202 y que en el resumen (por debajo de RD$250.000) sigue null aunque el documento ya esté aceptado (por qué).

Errores frecuentes¶

Cada mensaje llega en un 422 dentro de document.errors (y, por campo, en document.detailed_errors); la forma completa está en Cómo responde la API.

Mensaje	Causa
El campo RNC/Cédula del comprador es obligatorio.	El monto total alcanzó RD$250.000: ya debe identificar al comprador.
El campo detalle de ítems no debe tener más de 1000 elementos.	Pasó el umbral y con él el tope baja de 10.000 a 1.000 líneas.
El indicador de facturación seleccionado es inválido.	Valores válidos: `0`, `1`, `2`, `3`, `4`.
Hay ítems gravados con ITBIS, así que el indicador de monto gravado (id_doc.indicador_monto_gravado) es obligatorio: 0 si los montos de las líneas no incluyen ITBIS, 1 si lo incluyen.	Falta `id_doc.indicador_monto_gravado`. La DGII lo exige cuando hay ítems gravados (Formato e-CF, campo 7) y, si no viene, rechaza el comprobante con el código 176.
El campo fecha límite de pago es obligatorio cuando tipo de pago es 2.	Una venta a crédito siempre declara su `fecha_limite_pago`.
La fecha límite de pago (…) no puede ser anterior a la fecha de emisión, que es la de hoy (…).	`id_doc.fecha_limite_pago` está en el pasado. Con `tipo_pago` `2` (crédito) es obligatoria y tiene que ser igual o posterior a hoy.

Referencias¶

Campos comunes · Catálogos · Estados

Ejemplo con varios productos y descuentos¶

ejemplos/ecf-32-varios-productos-con-descuento.json — tres líneas, dos de ellas con descuento_monto, más los datos del comprador (que en el 32 son opcionales) y su id_doc.e_ncf.

Ojo con el descuento por línea: monto va ya neto (bruto menos descuento). El descuento_monto es informativo y se imprime en su columna de la representación impresa, pero lo que la DGII totaliza es el monto.

Ejemplo con dos productos¶

ejemplos/ecf-32-dos-productos.json — dos líneas gravadas (monto por línea sin ITBIS, indicador_monto_gravado: 0), el comprador con sólo razón social y varios correos separados por «;» (comprador.correo), la copia del emisor en emisor.correo (que prevalece sobre el correo de la empresa), y el pago en efectivo por el total con ITBIS (2596.00). Como queda por debajo de RD$250.000 se transmite como resumen: su track_id será siempre null (ver arriba); se sigue por su identificador.