Muy pocas personas. Cada operador tiene el control total del gateway: puede cambiar el Modo de transmisión GLOBAL de todas las empresas, crear y borrar tokens de API, cambiar los certificados de firma y crear o borrar a otros operadores. No hay roles que lo limiten; lo único que se puede restringir es el Alcance Certificación CerteCF, y eso solo limita la herramienta de certificación.
Quién debe tener usuario de operador| Persona | Acceso | Por qué |
|---|---|---|
| El dueño de la plataforma (quien administra el gateway) | Sí, con 2FA | Administra el gateway de todas las empresas. |
| Un respaldo técnico de total confianza | Opcional, con 2FA | Para que alguien pueda actuar si el dueño no está disponible. |
| Alguien que solo corre el set de pruebas DGII de una empresa | Solo si hace falta | Limítelo con Alcance Certificación CerteCF al RNC de esa empresa. Igual verá y podrá cambiar todo lo demás del portal: déselo solo a alguien de confianza. |
EASYIMS_GW_ADMIN_KEY).easyims-middleware en Render.app/repr_impresa.py:151-180):
RncEmisor — RNC del emisorCodigoSeguridad — los primeros 6 caracteres de la firma digital (SignatureValue) del propio e-CF. Ejemplo real, e-NCF E320000000127:
ENCF — el e-NCF (número de comprobante)MontoTotal — el monto total de la facturaSignatureValue
localmente, antes de que nada se envíe a la DGII; el Código de Seguridad es simplemente sus primeros 6
caracteres. La DGII nunca lo calcula ni lo asigna — solo lo recibe embebido en el XML firmado y lo usa
después como índice para su propio servicio de Consulta Timbre.
Excepción: en una RFCE (Consumo < RD$250mil), el código no sale de la
firma del resumen mismo, sino que se copia del CodigoSeguridadeCF de la
factura completa original — así lo exige el propio XSD de la DGII ("Hash generado en factura de consumo original").
RncComprador — RNC del compradorFechaEmision — fecha de emisiónFechaFirma — fecha/hora de la firma digitalfc.dgii.gov.do, no
ecf.dgii.gov.do) y solo cuatro parámetros (RncEmisor, ENCF,
MontoTotal, CodigoSeguridad) — sin comprador ni fechas.
rfce-32.xsd) trae ese campo con el comentario
"Hash generado en factura de consumo original".
ecf.dgii.gov.do y los 7 parámetros normales, igual que una Factura
de Crédito Fiscal — la complicación de "dos documentos, dos firmas" solo existe por debajo de ese monto.
RFCE = Resumen de Factura de Consumo Electrónica. Es el mecanismo que utiliza la DGII para recibir la información de las Facturas de Consumo Electrónicas (e-CF tipo 32) cuyo monto es inferior a RD$250,000.
La documentación técnica vigente de la DGII mantiene el RFCE como un formato específico y el servicio correspondiente como Recepción de Resumen Factura de Consumo e-CF.
Este es probablemente el punto que más confusión causa. Supongamos que vendes:
Tu sistema genera un e-CF 32 completo (E320000000123) que contiene toda la información
de la factura: Encabezado, Cliente/receptor, Items, Impuestos, Totales, Firma digital, etc. Pero como es
una factura de consumo menor de RD$250,000, no envías ese XML completo mediante el servicio normal
de recepción de e-CF.
La DGII establece que el emisor debe conservar el e-CF completo y enviar a DGII el resumen correspondiente.
Esta es una confusión muy común. Supongamos que tienes 4 ventas del día:
NO haces un solo resumen agrupado ("RFCE: 4 facturas, Total RD$53,500"). La DGII indica que debes reportar las informaciones de cada una de las facturas mediante el formato RFCE:
Cada factura conserva su propio e-NCF y su propio XML completo en tu sistema.
Porque el RFCE contiene un subconjunto/resumen de la información del e-CF completo — no contiene todos los datos del XML completo. La documentación de DGII literalmente lo describe como un resumen que contiene las informaciones principales del e-CF.
La estructura exacta debe seguir el XSD/formato RFCE publicado por DGII; no conviene construirla simplemente copiando campos del e-CF. DGII publica un XSD específico para RFCE 32 v1.0.
Sí. Esto es importante para tu middleware — el servicio recibe el resumen como XML firmado digitalmente. Por tanto tienes DOS firmas distintas:
Aquí está la diferencia fundamental con recepción normal.
La documentación técnica de DGII dice expresamente que RFCE devuelve el estado de validación directamente: Aceptado, Aceptado Condicional o Rechazado.
Cliente consumidor final, tipo E32, monto RD$50,000:
Tu base de datos debería quedar:
Ese NULL en track_id es perfectamente válido.
La factura sí existe como e-CF completo aunque tú hayas enviado a DGII solamente el RFCE. DGII indica que el emisor debe conservar el e-CF completo y entregar la Representación Impresa (RI) al consumidor final.
Para una Factura de Consumo menor de RD$250,000 (RFCE), el FAQ oficial de la DGII sobre este formato trata al comprador siempre como receptor no electrónico — la entrega es siempre mediante RI. Revisamos el documento completo (todas las menciones a "receptor" en ese FAQ dicen explícitamente "receptor no electrónico", incluso la pregunta sobre entrega por correo electrónico) y no encontramos ningún caso, dentro del contexto específico de RFCE, donde la DGII contemple entregar el XML a un receptor electrónico. Tiene sentido: la Factura de Consumo es por definición B2C (consumidor final).
receptor_delivery.py).La documentación de certificación de DGII también distingue:
Importante sobre el monto
La documentación histórica de DGII también especifica que el límite de RD$250,000 se determina sobre el monto facturado sin ITBIS, no sobre el total con ITBIS. Por ejemplo:
Aunque el total sea RD$289,100, el monto facturado sin ITBIS es RD$245,000 → 245,000 < 250,000 → RFCE.
MontoTotal (CON ITBIS) contra el umbral, no el monto sin ITBIS. Ya se redactó una pregunta
formal a la DGII para confirmar esto antes de cambiar la lógica de clasificación —
dgii_docs/DGII_Consulta_Umbral_RFCE_250mil.md. No asumir todavía que el código ya aplica
esta regla.Tabla de submissions recomendada:
Y la lógica:
Eso elimina una cantidad enorme de problemas.
Aunque DGII reciba un RFCE, eso no significa que el RFCE sea el comprobante fiscal que
entregas al cliente. El e-NCF (E320000000501) pertenece al e-CF; el RFCE es solo el formato
de reporte/resumen para transmitir a la DGII la información de ese e-CF. La propia DGII aclara que el
contribuyente debe conservar el e-CF extendido correspondiente para procesos futuros.
if track_id is null: resend()
— sería peligroso. Para RFCE, track_id = NULL + status = ACEPTADO es un estado
perfectamente válido. Para un e-CF normal, track_id = ABC123 + status = EN_PROCESO
es otro estado válido. El método de envío (ECF vs RFCE) debe determinar cómo interpretas la
respuesta, no la existencia o ausencia de track_id.
RFCE no está limitado a un tipo específico de empresa o sector. Lo determina el tipo de operación y el monto de la Factura de Consumo Electrónica, no si la empresa es una tienda, supermercado, restaurante, farmacia, taller, etc. La regla oficial de la DGII es que deben enviar RFCE los emisores electrónicos que realicen transferencias de bienes, entregas en uso o prestaciones de servicios mediante Facturas de Consumo Electrónicas menores de RD$250,000.
Ejemplos
Por eso pueden utilizar RFCE:
La propia DGII lo describe como el canal B2C para las facturas de consumo electrónicas menores de RD$250,000.
La clave es que sean emisores electrónicos y que la operación se documente como e-CF tipo 32 (Factura de Consumo Electrónica).
Un ejemplo muy claro: una ferretería
Tu sistema genera e-CF tipo: 32, e-NCF: E320000000123. Pero como la
operación es menor de RD$250,000: se conserva en tu sistema, se entrega al consumidor según corresponda,
y se genera RFCE → DGII / RecepcionFC. La DGII confirma que cada factura conserva su propio e-NCF y debe
generarse un comprobante completo, aunque a DGII se le reporte mediante RFCE.
Para tu middleware
No pondría una configuración por "tipo de compañía = RFCE". Pondría la regla:
/fe/recepcion/api/ecf y /fe/aprobacioncomercial/api/ecf —
tanto pruebas de certificación de la DGII (pasos 9/11) como tráfico real después de ir en vivo. No se
puede distinguir por código (la DGII usa el mismo endpoint para ambos), así que la marca de
"Certificación completa" por cliente abajo es lo único que permite saber si algo llegó antes o después.
| Tipo | RNC Emisor | RNC Comprador | e-NCF | Estado | ¿Cuándo llegó? | Recibido | Revisado |
|---|
👉 Quién debería tener usuario: vea ¿Quién debe tener acceso? (botón arriba a la derecha).
Qué puede hacer un operador/admin-portal con su usuario y clave. Su sesión dura 12 horas; un reinicio del servidor (por ejemplo, un despliegue) la cierra y debe volver a entrar.131384463,132307739) y pulse Guardar para limitarla a esos RNC (aparece 🔒 en rojo). Déjelo vacío y Guardar para quitar el límite. Solo limita la certificación; el resto del portal lo sigue viendo completo.easyims-middleware en Render.
| Usuario | Activo | 2FA | Alcance Certificación CerteCF | Creado | Acciones |
|---|
| Fecha | Quién | Origen | Cliente | Antes | Después | Clientes que movió |
|---|---|---|---|---|---|---|
| Cargando… | ||||||
| # | Empresa | Modo | Ambiente | Lo que aplica | Significado |
|---|---|---|---|---|---|
| Cargando… | |||||
| RNC | Tipo | Titular | Archivo | RNC autorizados | Activo | Acciones |
|---|
| Correo | Nombre | Rol | RNC/Cédula | Estado | MFA | Último acceso |
|---|
GET /v1/status (your_ip). El portal con usuario y contraseña no se restringe.Interna = una de sus empresas, la usa EasyIMS (token dmw_). Externa = un cliente del gateway que factura desde su propio sistema, p. ej. AdingSoft (token dmx_).
dmx_… una sola vez: cópielo y entrégueselo al cliente por un canal seguro (no por correo ni chat abiertos). Si se pierde, se genera otro desde su fila.format_id.| ID | Nombre | RNC / grupos | Token (prefijo) | Cert | IPs permitidas | Modo DGII | Formato predet. | Acciones |
|---|
| # | Tipo | e-NCF | Fase | Estado | Motivo | Acciones |
|---|
| Run ID | RNC | Archivo | Modo | Ambiente | Estado | Iniciado | Acciones |
|---|
Un formato dice cómo convertir el JSON que produce otro sistema (no canónico, p. ej. AdingSoft) a nuestro formato canónico (el de EasyIMS), del que se arma el XML del e-CF. Pertenece a un cliente: créelo bajo la empresa que envía ese JSON.
Pasos/v1/ecf con format_id, su JSON se traduce a nuestro formato canónico antes de construir el XML — el generador de XML nunca cambia.| ID | Cliente | Nombre | Activo | Acciones |
|---|
| Sigla / término | Significado |
|---|---|
e-CF | Comprobante Fiscal Electrónico |
e-NCF | Número de Comprobante Fiscal Electrónico (la secuencia, ej. E310000000001) |
RNC | Registro Nacional del Contribuyente |
ARECF | Acuse de Recibo de e-CF — confirma que recibiste el documento (Estado 0 = recibido, 1 = no recibido) |
ACECF | Aprobación Comercial de e-CF — el comprador acepta/rechaza la operación |
ANECF | Anulación de e-CF |
RFCE | Resumen Factura de Consumo Electrónica (Consumo tipo 32 menor a RD$250,000) |
Semilla | Archivo XML con un valor único que se firma digitalmente y se cambia por un token |
TrackId | Identificador único que devuelve la DGII al recibir un e-CF (para consultar su estado) |
Código de Seguridad | Primeros 6 caracteres del SignatureValue de la firma — se imprime y va en el QR |
PSFE | Proveedor de Servicios de Facturación Electrónica (solo si transmites para terceros) |
TesteCF / CerteCF / eCF | Ambientes DGII: pruebas / certificación / producción |
31 | Factura de Crédito Fiscal |
32 | Factura de Consumo |
33 | Nota de Débito |
34 | Nota de Crédito |
41 | Compras |
43 | Gastos Menores |
44 | Regímenes Especiales |
45 | Gubernamental |
46 | Exportaciones |
47 | Pagos al Exterior |
| Aceptado | e-CF válido (terminal) |
| Aceptado Condicional | válido con observaciones (terminal) |
| Rechazado | no válido (terminal) |
| En Proceso | aún en validación — seguir consultando |