← 🛠️ Volver a Utilidades
🛠️ Herramientas del middleware en esta página:
Easy-IMS Gateway

Flujo CEE — Certificación Emisor Electrónico

Los 15 pasos oficiales de la DGII para postularse y certificarse como Emisor Electrónico de e-CF, con el estatus real de qué está construido en Easy-IMS Gateway frente a lo que es una acción manual de Ed en la Oficina Virtual (OFV).
⚠️ Los badges de abajo describen si el CÓDIGO está listo — NO el avance real de tu certificación en DGII para un RNC específico. Ese estatus real solo vive en el propio portal de la DGII (el listado "Flujo certificación" a la izquierda, con sus check verdes). Un paso puede decir "construido" aquí y aun así no haber sido ejercitado/aprobado por DGII todavía para tu empresa.
código listo (no es progreso DGII)
acción manual pendiente (OFV)
no aplica a código
0 / 15 pasos completados — clic en el número de cada paso para marcarlo
Fuente: DGII, "Proceso de Certificación para ser Emisor Electrónico" (Impuestos Internos, julio 2025) — PDF oficial en dgii.gov.do. Publicación informativa de la DGII, sin validez legal.

Requisitos previos para solicitar

Etapa 1 · Solicitud

Formulario "Solicitud para ser Emisor Electrónico (FI-GDF-016)" en la OFV → acceso al Portal de Certificación de FE.

Etapa 2 · Set de Pruebas

Se valida la capacidad técnica del software para cumplir los requisitos de emisor electrónico. Pasos 1–11.
🎥 Videos de referencia (no oficiales de DGII)
No encontré timestamps verificables por paso dentro de estos videos — son walkthroughs completos del portal de certificación (pasos 1–11), hechos por proveedores de software, no por la DGII:
🔗 Servicios oficiales TESTECF: Autenticación Recepción Consulta de Resultado Aprobación Comercial
1
Registradomanual
📄 Datos enviados — JEP GROUP SRL, RNC 131384463 (postulación firmada, 2026-10-23 10:06 PM)
Datos del contribuyente
Tipo de registroFacturador ElectrónicoTipos de comprobantes31,32,33,34,41,43,44,45,46,47
RNC/Cédula131384463Razón socialJEP GROUP SRL
Nombre comercialJEP GROUP SRLActividad económicaTRANSPORTE EN GENERAL
Teléfono829-681-1700Correo electrónicoe••••••@hotmail.com
DirecciónROBERTO PASTORIZA, NO. 510ProvinciaSANTO DOMINGO
MunicipioDISTRITO NACIONALSectorEVARISTO MORALES
Datos del representante
Representante asociadoJAVIER FERNANDEZ FERRERRNC/Cédula001-•••••••-5
Dirección(oculta)Provincia / MunicipioDISTRITO NACIONAL / SANTO DOMINGO DE GUZMAN
Correo electrónicoe••••••@hotmail.comTeléfono / Celular—
Datos del software a utilizar
Tipo de softwarePROPIONombre / Versióneasy-ims 1.0
URL de recepciónhttps://portal.easy-ims.com/fe/recepcion/api/ecf
URL de aprobación comercialhttps://portal.easy-ims.com/fe/aprobacioncomercial/api/ecf
URL de autenticaciónhttps://portal.easy-ims.com/fe/autenticacion/api/[semilla|validacioncertificado]
Archivo de postulación firmado
Archivo202610234100810-firmado.xmlPostulacionID94853
Firmado porJAVIER FERNANDEZ FERRER (el representante)CertificadoViafirma Qualified Certificates, persona física, válido 2026-01-31 → 2027-01-31
FirmaVálida: digest correcto y firma RSA-SHA256 verificada como la recalcula la DGII (con los namespaces xsi/xsd del documento)
Verificación de la firma (quién firmó y si es válida)
FirmanteJAVIER FERNANDEZ FERRERCédula001-•••••••-5 (en el certificado como IDCDO-…)
TipoCertificado calificado de persona física — trámites tributariosEmitido porVIAFIRMA QUALIFIED CERTIFICATES (Viafirma Dominicana)
Vigencia31 enero 2026 → 31 enero 2027¿Coincide con el formulario?Sí: es el representante escogido (RNCRepresentante)
DigestCorrecto — el contenido no cambió después de firmar.
Firma RSAVálida al verificarla como la recalcula la DGII: el SignedInfo con los namespaces xsi/xsd del documento.
Falsa alarmaLa librería estándar de verificación (signxml) la da como inválida: es una falsa alarma conocida con este tipo de documento (raíz con xmlns:xsi / xmlns:xsd), documentada en el firmador del gateway (app/signer.py). Es el mismo método que la DGII aceptó para CESEHE.
ContenidoCoincide con el formulario: JEP GROUP SRL 131384463, comprobantes 31–47, software easy-ims 1.0, las 3 URL en portal.easy-ims.com.
Incidente: el certificado para firmar la postulación (2026-10-23)
Qué se vioAdmin portal → Certificados de firma (captura 7:10 PM): el certificado de Javier estaba registrado con RNC principal 001-•••••••-6 pero su titular era 001-•••••••-5 (su cédula real, la misma del formulario de la DGII). Archivo 20260131-…-MXED2KRBN.p12, con 131384463 en "RNC autorizados".
Por qué importaEl firmador busca el certificado por lo que se escribe en "RNC del certificado": 1) RNC principal, 2) RNC autorizados, 3) certificado del cliente con ese RNC. Con el RNC principal mal escrito, poner la cédula real de Javier no encontraba su certificado (solo funcionaba escribiendo 131384463). Además cada RNC de empresa debe estar en un solo certificado: si dos lo tienen, se usa el primero que aparezca (así firmó antes otra persona por JEP GROUP).
SoluciónSe volvió a registrar el mismo .p12 con RNC principal = la cédula real de Javier y RNC adicional 131384463, y se borró la fila con el RNC equivocado. Resultado: dos filas limpias — su certificado (CESEHE, ELMUNDO y otros) y el de Javier (solo JEP GROUP).
VerificaciónEasyIMS → GET /ecf-signing-config/gateway-certificate (empresa JEP GROUP): el gateway usa 20260131-…-MXED2KRBN.p12, encontrado por "RNC autorizados", legible (contraseña correcta), válido hasta 2027-01-31. Luego se firmó la postulación con "RNC del certificado" = 131384463 y el XML resultó firmado por Javier (ver verificación arriba).
OjoCon esta configuración, las facturas (e-CF) de JEP GROUP también las firma Javier: en la OFV debe tener el rol de Firmante delegado para JEP GROUP (o ser su representante).
Siguiente: Portal DGII, Paso 1 → "Envío de archivo de postulación firmado" → Browse → este archivo → ENVIAR ARCHIVO, y revisar los Logs.
Fuente: 01-Postulacion - Portal Certificacion.pdf (2026-10-23 10:06 PM) y el XML firmado. En esa captura el archivo firmado ya está seleccionado en "Envío de archivo de postulación firmado"; se envió con ENVIAR ARCHIVO y la DGII la aceptó: a las 10:31 PM JEP GROUP ya estaba en el Paso 2. Tras recargar la página, la DGII deja vacíos los campos del representante y del software: es normal — los datos enviados son los del XML firmado (arriba).
Formulario de postulación (datos del contribuyente, representante, y del software: tipo, nombre, versión, URLs de Recepción/Aprobación/Autenticación). Se firma en XML y se envía desde el Portal de Certificación.
🖊️ Para firmar el XML de postulación con tu certificado, usa el firmador del Paso 13 (mismo firmador genérico, ejecutable aquí mismo).
📄 Datos enviados — ELMUNDO (EL MUNDO DE LAS JUNTAS RD SRL), RNC 133200155
  • Tipo de registro: Facturador Electrónico · Tipos de comprobantes: 31,32,33,34,41,43,44,45,46,47
  • Razón social: EL MUNDO DE LAS JUNTAS RD SRL · Nombre comercial: EL MUNDO DE LAS JUNTAS RD
  • Actividad económica: 291904 · Tel: 8095656595 · Correo: estherperez21@hotmail.com
  • Dirección: Resp. Las Américas, No. 167, Las Américas — Santo Domingo / Santo Domingo Este / Las Américas
  • Representante: Edwards Cristopher Perez Cortorreal — Cédula 00112280243, tel 8095656595, cel 8098708940
  • Dirección representante: San Antón, No. 6-B, Zona Industrial Herrera — Santo Domingo / Santo Domingo Este
  • Software: PROPIO — EASY-IMS v1.0
Fuente: captura del formulario, 2026-09-15 (DGII_Postulacion_ELMUNDO/paso_01.pdf). Postulación aún sin generar/firmar al momento de esa captura.
📋 URLs de software declaradas para este RNC
Host (los 3 campos)portal.easy-ims.com
🔐 Certificados de firma — registrar / probar aquí
El mismo panel del admin portal: suba el .p12 del representante con su cédula como RNC principal y el RNC de la empresa en "RNC adicionales". Cada RNC de empresa en un solo certificado. Requiere la clave de administrador; si ya entró al admin portal en este navegador, se usa esa sesión. Abrir en pantalla completa ↗
✅ Postulación firmada
2026-09-15 vía Firmar XML genérico — archivo 20260915033893.xml, RNC del certificado 133200155 → "Firmado y descargado". Certificado resuelto automáticamente para ese RNC, sin necesidad de subir un .p12 por separado en este paso. Pendiente: cargar ese XML firmado en la sección "Envío de archivo de postulación firmado" del propio Portal DGII y pulsar ENVIAR ARCHIVO.
🖊️ Firmar XML de la postulación (Paso 1)
El XML que da GENERAR ARCHIVO en el Paso 1 de la DGII, firmado con el certificado del representante que escogió en el formulario. Luego súbalo en "Envío de archivo de postulación firmado" → ENVIAR ARCHIVO.
⚠️ Si sale "HTTP 401: Bad or missing X-Admin-Key / session": la casilla Admin Key tiene algo que el gateway no acepta (por ejemplo la contraseña de un operador: esa sirve para entrar al admin portal, no es la Admin Key), y lo escrito se usa en lugar de su sesión. Solución: 1) deje Admin Key vacía; 2) en otra pestaña del mismo navegador entre al admin portal con su usuario y contraseña (o la Admin Key maestra); 3) vuelva aquí, recargue (Ctrl+F5), elija el XML y firme. La sesión vence: si vuelve el 401 más tarde, entre de nuevo al admin portal. Alternativa: el panel morado 🖊️ Firmar XML genérico dentro del admin portal no pide clave.
2
Pruebas de Datos e-CFconstruido
DGII entrega un Set de Pruebas (Excel) con datos fijos; el software debe generar los XML de e-CF exactamente con esos campos, en el mismo orden, y enviarlos al servicio de recepción de Impuestos Internos.
📸 Captura: JEP GROUP SRL (131384463), 2026-10-23 10:31 PM — ya en Paso 2 (la DGII aceptó la postulación del Paso 1). Contadores en 0: 0/21 Comprobantes, 0/4 Resúmenes de Consumo, 0/4 Facturas de consumo < 250Mil; logs vacíos. Set de pruebas descargado: 131384463-23102026221030_SampleData.xlsx. Antes de enviar: ambiente del gateway en CERTECF.
📋 Orden de Emisión de Comprobantes Para las Pruebas (DGII — link "Verifique orden de envío de comprobantes aquí")
Primero:
31 - Factura de Crédito Fiscal Electrónica
32 - Factura de Consumo Electrónica Mayor o Igual RD$250,000.00
41 - Compras Electrónico
43 - Gastos Menores Electrónico
44 - Regímenes Especiales Electrónico
45 - Gubernamental Electrónico
46 - Comprobante de Exportaciones Electrónico
47 - Comprobante para Pagos al Exterior Electrónico
Segundo:
33 - Nota de Débito Electrónica
34 - Nota de Crédito Electrónica

Tercero:
32 - Resumen Factura de Consumo Electrónica Menor a RD$250,000.00

Cuarto:
32 - Factura de Consumo Electrónica Menor a RD$250,000.00 (subida manual en el portal: botón "Íntegro" de cada fila RFCE)
El sistema ya envía en este orden. Al reintentar filas a mano, respete el mismo orden: primero las del grupo "Primero", luego las notas (33 antes de 34).
✅ certrunner.py — corre este set completo (Fase 1) automatizado desde el admin portal, o aquí mismo:
🧪 Ejecutar Set de Pruebas (Paso 2)
o ver una corrida anterior:
📎 Las 4 Facturas de consumo < 250Mil: cuando cada fila 32 (RFCE) esté ACEPTADA, baje su Íntegro y súbalo en la DGII, uno a la vez, en "Facturas de consumo < 250Mil" → ENVIAR.
📋 Pantalla real de la DGII (confirmado 2026-09-16, RNC 133200155)
📸 JEP GROUP (131384463), 2026-10-26: 21/21 Comprobantes y 4/4 Resúmenes aceptados; falta la casilla "Facturas de consumo < 250Mil" (0/4) — se suben los 4 Íntegro de la corrida que envió los Resúmenes.
Esta misma pantalla (rail izquierdo en "2 Pruebas de Datos e-CF") tiene DOS tarjetas: "Set de datos a utilizar" (botón "Descargar Comprobantes") y, debajo, "Facturas de consumo < 250Mil" — un solo "Elegir archivo" + botón ENVIAR, contador propio "X/4 Comprobantes Aceptados", separado del contador de arriba.
"Facturas de consumo < 250Mil" no es un archivo que se busca — es el XML Íntegro (factura completa, no el Resumen RFCE) que certrunner.py ya construyó y firmó al enviar cada Resumen tipo 32<250Mil, guardado para exactamente este paso. Se descarga desde nuestro propio admin portal, botón "Íntegro" junto a cada fila "32 (RFCE)" de la corrida (o GET /admin/certrun/{run_id}/rows/{row_id}/xml-full), y se sube uno a la vez, repitiendo la acción 4 veces (una por cada Resumen ya Aceptado).
Copias locales (ELMUNDO, corrida #29, 2026-09-16): c:\claude\dgii_postulacion\menor_250K\ — E320000000018_integro.xml, 019, 020, 021.
El contador "Comprobantes Aceptados"/"Resúmenes Aceptados" de arriba puede mostrar 0/21·0/4 aun con todo genuinamente Aceptado por DGII (trackId verificable) — es el defecto de reinicio del Portal ya documentado (CERTECF_PLAYBOOK.md §16, dgii_docs/DGII_Reinicio_Paso2_SetPruebas_Seguimiento.md §10). No bloquea subir las Facturas <250Mil.
3
Pruebas de Datos Aprobación Comercialconstruido
Igual que el paso 2, pero generando las Aprobaciones o Rechazos Comerciales (ACECF) en su formato XML a partir de otro Excel de datos fijos (hoja "ACEECF_Generadas").
✅ app/receptor.py (load_acecf_rows/build_acecf/signed_acecf) + app/dgii_real.py (send_acecf) — verificado en vivo 2026-08-21 contra CERTECF, 11/11 Aprobadas.
📤 Enviar Aprobaciones Comerciales (Paso 3)
4
Pruebas de Simulación e-CFconstruido
Ya no son datos fijos: se generan e-CF (31, 32≥250k, 33, 34, 41, 43, 44, 45, 46, 47) a partir de datos representativos de la operación real del contribuyente, en el orden que exige DGII (31/32≥250k/41/43/44/45/46/47 primero, luego 33/34, luego resúmenes 32<250k).
✅ certrunner.py Fases 1–3 — respeta ese mismo orden.
🧪 Certificación automática (Set de pruebas) — ejecutar aquí
Herramienta del middleware (requiere la clave de administrador; si ya entraste al admin portal en este navegador, se usa esa sesión). Abrir en pantalla completa ↗
📋 Pantalla real de la DGII (confirmado 2026-08-28)
Arriba del todo: link Verifique orden de envío de comprobantes aquí — el orden de 4 fases que ya respeta certrunner.py (ver arriba).
"Estado actual de las pruebas de simulación" — un contador X/Y en vivo por cada tipo: tipo 31 · tipo 32 >=250Mil · tipo 33 · tipo 34 · tipo 41 · tipo 43 · tipo 44 · tipo 45 · tipo 46 · tipo 47 · tipo 32 RFCE (el resumen <250Mil, contado aparte del 32 normal).
Tarjeta separada, "Facturas de consumo < 250Mil" — un solo "Elegir archivo" + botón ENVIAR, contador propio "X/4 Comprobantes Aceptados". Este es el upload manual de los 4 XML Íntegro (factura completa, no el resumen RFCE) — se sube uno a la vez, repitiendo la acción 4 veces. Los archivos salen de GET /admin/certrun/{run_id}/rows/{row_id}/xml-full para cada fila RFCE del run (ver CERTECF_PLAYBOOK.md §5).
📤 Correr Simulación e-CF (Paso 4)
⚠️ ANTES DE CORRER EL PASO 4 — revise estas 4 cosas
  1. RNC = el de la empresa que se certifica (ej. JEP GROUP: 131384463). La casilla empieza vacía; si el RNC no es el del Excel, sale una advertencia antes de enviar nada (puede correr igual, pero entonces la razón social no se reemplaza).
  2. Razón social del emisor = el nombre exacto como está registrado en la DGII, ej. JEP GROUP SRL. Se llena sola al escribir el RNC (registro RNC de la DGII, ver "📥 Registro RNC" abajo); si sale en naranja, verifíquela. Sin esto el XML sale con el nombre genérico del Set de Pruebas.
  3. Antes de subir nada al portal, abra un Íntegro descargado y confirme que <RazonSocialEmisor> dice el nombre real — no "DOCUMENTOS ELECTRONICOS…".
  4. Un Íntegro no se puede corregir: se guarda firmado al enviar, y bajarlo otra vez da el mismo archivo. Si salió mal, hay que correr el Paso 4 de nuevo (e-NCF nuevos).
Por qué (JEP GROUP, 2026-10-27): la DGII devolvió a JEP al Paso 4 porque el XML traía la razón social genérica del Set de Pruebas ("DOCUMENTOS ELECTRONICOS DE 02" y, en consumo, "…PRUEBA FACTURA DE CONSUMO MENOR 250MIL"). La corrida #55 salió 25/25 aceptada pero con el nombre genérico: la casilla RNC traía 132307739 (CESEHE) y el nombre no se reemplazó. La DGII acepta el envío igual — el error lo ve después el revisor. Dirección, teléfono y correo del emisor sí salen del Set de Pruebas tal cual; solo la razón social se reemplaza. En el Paso 2 se deja el nombre genérico (ahí la DGII lo compara con su archivo).
Por ahora reutiliza el mismo Excel del Set de Pruebas (Paso 2/3) — mismo mecanismo, distinta clasificación de paso. Cambiar a datos 100% representativos de la operación real queda pendiente.
📥 Opcional — cargar o actualizar el registro RNC de la DGII (para que la razón social se llene sola)
…
Actualizarlo: descargue de la DGII el archivo RNC_Contribuyentes (.zip) y súbalo aquí tal cual (también acepta .csv o .csv.gz). La carga tarda unos minutos y reemplaza el registro anterior.
📋 Pasos (JEP GROUP, 2026-10-26)
  1. Razón social del emisor: se llena sola al escribir el RNC, desde el registro RNC de la DGII; debe quedar exacta como está registrada en la DGII, ej. JEP GROUP SRL. El Set de Pruebas trae un nombre genérico ("DOCUMENTOS ELECTRONICOS DE 02"); en el Paso 4 la DGII exige el nombre real dentro del XML (JEP GROUP tuvo que repetir el Paso 4 por esto, 2026-10-27). En el Paso 2 no: ahí se deja el genérico.
  2. Excel: el mismo Set de Pruebas del Paso 2 (ej. 131384463-26102026105857.xlsx) — no el de Aprobaciones Comerciales del Paso 3.
  3. ▶ Correr contra DGII. Los e-NCF nuevos se asignan solos (en el Paso 4 la DGII exige números nuevos; no se marca nada). Anote el número de corrida.
  4. Si sale HTTP 409 "Ya hay una corrida en curso": cargue esa corrida en la casilla del Paso 2 (📂 Cargar corrida) y pulse ⏹ Cancelar corrida; luego vuelva a correr.
  5. Si alguna fila sale ❌: pare — el Paso 4 también se reinicia con cualquier rechazo.
  6. Espere a que la corrida termine: primero 31/32≥250Mil/41/43/44/45/46/47, luego 90 s de espera, luego 33/34 y al final las 4 32 (RFCE). En el portal, "Comprobantes tipo 32 RFCE" debe decir 4/4.
  7. Facturas de consumo < 250Mil — bajar los Íntegro: en la casilla "🧪 Ejecutar Set de Pruebas (Paso 2)" escriba el número de corrida del Paso 4 en "ver una corrida anterior" → 📂 Cargar corrida (no hace falta RNC ni Excel) → ⬇ Íntegro en cada una de las 4 filas 32 (RFCE). Debajo sale "⬇ … bajado (carpeta Descargas)". Si Chrome bloquea la descarga (ícono en la barra de direcciones), elija "Permitir siempre".
  8. Subirlos: portal de la DGII, Paso 4, casilla "Facturas de consumo < 250Mil": Browse → el primer …_integro.xml → ENVIAR; repita con el 2º, 3º y 4º, uno a la vez. Recargue (F5) hasta ver 4/4 Comprobantes Aceptados.
  9. Importante: use los Íntegro de la corrida del Paso 4, no los del Paso 2 — son otros números. Si alguno se rechaza, pare.
  10. Luego el portal pasa al Paso 5 (Representación Impresa): usa los PDF de esta misma corrida del Paso 4 — guarde su número.
🔑 ¿Dónde está la Admin Key? Es la clave maestra del gateway, guardada en Render: dashboard.render.com → servicio easyims-middleware → Environment → variable EASYIMS_GW_ADMIN_KEY (o DGII_MW_ADMIN_KEY, su nombre anterior) → 👁 para verla y copiarla. Péguela solo en esta casilla: nunca en mensajes, documentos ni capturas (quien la tenga controla el gateway de todas las empresas). No la cambie en Render: cambiarla reinicia el gateway. Alternativa sin clave: entre al admin portal con su usuario y contraseña (los firmadores de los Pasos 1 y 13 usan esa sesión con la casilla vacía). Nota (2026-10-23): una captura del dashboard de Render con este valor visible no se publica aquí por esa razón.
5
Pruebas Simulación Representación Impresaconstruido
Por cada e-CF del paso 4, generar y enviar su Representación Impresa en PDF (máx. 10MB combinados), con el QR leíble y los datos tal cual fueron enviados en el e-CF.
✅ app/repr_impresa.py — renderiza HTML+QR por tipo de comprobante.
📄 Informe Técnico e-CF (especificación oficial de Representación Impresa)
📋 Pantalla real de la DGII (re-confirmado 2026-08-28)

Once campos, cada uno su propio "Elegir archivo" (NO un solo combinado):
Representación para comprobante tipo 31 · tipo 32 >=RD$250mil · tipo 33 · tipo 34 · tipo 41 · tipo 43 · tipo 44 · tipo 45 · tipo 46 · tipo 47 · tipo 32 < RD$250mil

Los nombres de archivo que produce el ZIP de abajo ya calzan con cada casilla (tipo_31.pdf, tipo_32_mayor_250mil.pdf, tipo_32_menor_250mil.pdf, etc.) — no hace falta renombrar. Suma de todos los archivos: máx. 10MB.
"Es responsabilidad del contribuyente asegurar que la representación impresa del e-CF cumpla con el formato y las disposiciones establecidas en la Ley núm. 32-23, así como en la documentación técnica y complementaria del Formato de e-CF, cuyo incumplimiento puede generar sanciones conforme a lo dispuesto en dicha ley."
Dos botones abajo en la pantalla de la DGII: Retornar Postulación confirmado en vivo — regresa toda la postulación al Paso 4 sin borrar lo ya Aceptado en Pasos 1-3 (así se resolvió el bug de Razón Social del 28-08-2026, ver Run #25 en CERTECF_PLAYBOOK.md §5). Cancelar Postulación SIN PROBAR — no lo toques sin confirmar con la DGII primero, el nombre sugiere que cancela la postulación completa.
📄 Generar PDF combinado (Paso 5)
Genera un .zip con 11 PDF (uno por tipo de comprobante, combinando todas las páginas de ese tipo) — la pantalla de la DGII para este paso pide un archivo separado por casilla, no uno solo. Descomprime y sube cada PDF en su casilla correspondiente (paso manual, igual que las facturas íntegras del Paso 2).
6
Validación Representación Impresano aplica
DGII responde Aprobada / Rechazada sobre lo enviado en el paso 5. No es una acción nuestra — es la respuesta de DGII.
📋 Pantalla real de la DGII (confirmado 2026-08-28)
Banner único, sin campos ni botones — pura revisión asíncrona del lado de la DGII:
"Etapa en la que DGII valida las Representaciones Impresas de e-CF enviadas en la prueba anterior (paso 5). Para continuar con el proceso de certificación es necesario que las Representaciones Impresas sean aprobadas."
No hay nada que ejecutar ni subir aquí — solo revisar periódicamente si este paso pasa a verde (Aprobada) o si la DGII deja un log de rechazo (como pasó el 28-08-2026 con la Razón Social, resuelto vía Run #25 — ver Paso 5 arriba y CERTECF_PLAYBOOK.md §5-6).
7
URL Servicio de Pruebamanual
Confirmar/actualizar en el Portal las URLs de Recepción, Aprobación Comercial y (opcional) Autenticación que recibirán tráfico de DGII en el ambiente de prueba.
Requiere el deploy público en Render primero — endpoints ya listos en app/routers/fe.py (/fe/recepcion/api/ecf, /fe/aprobacioncomercial/api/ecf, /fe/autenticacion/api/[semilla|validacioncertificado]).
📋 URLs para pegar en este paso
Host (usar en los 3 campos del formulario DGII)portal.easy-ims.com
❓ Qué pasa cuando alguien llama a estas URLs
Autenticación (opcional según la propia DGII): quien nos llama pide una semilla, la firma con su certificado y nos la devuelve — verificamos esa firma y entregamos un token. Solo se registra si lo usan, no es obligatorio.

Recepción (obligatorio): al llegar un e-CF, el servidor lee el XML, saca RNC emisor, RNC comprador y e-NCF, lo guarda como InboundDoc, y devuelve en la misma respuesta un acuse (ARECF) firmado digitalmente con tu certificado — "Estado 0" si pudo leer los datos básicos, "Estado 1" si no.

Aprobación Comercial (obligatorio): al llegar una aprobación o rechazo sobre algo que emitimos, se guarda y se responde 200 (aceptado) o 400 (rechazado, si falta el e-NCF).

Estos 3 endpoints no distinguen prueba de producción — ni falta que hace. El concepto TESTECF/CERTECF/PRODUCTION solo aplica cuando nosotros le enviamos algo a la DGII (ahí sí elegimos el ambiente). Aquí es al revés: alguien nos llama a nosotros, y el servidor responde igual sin importar si es la DGII certificando hoy o un proveedor real después — por eso el mismo host sirve para los pasos 7, 10 y 12.
8
Inicio Prueba Recepción e-CFmanual
Descargar el certificado raíz de DGII (opcional, para validar sus firmas) e indicar en el Portal que el sistema está listo para recibir e-CF.
🔐 Probar Autenticación — obtener semilla
Solo trae la semilla (XML a firmar) — no necesita parámetros. El siguiente paso real (validacioncertificado, firmar esa semilla y canjearla por un token) requiere firmarla con un certificado digital de verdad, así que no se puede simular desde este formulario — eso es lo que DGII ejercita al conectarse de verdad en el Paso 9.
9
Recepción e-CFconstruido
DGII envía comprobantes de prueba a nuestras URLs registradas; el sistema debe persistirlos y devolver el acuse de recibo (ARECF) firmado.
✅ Código probado end-to-end contra TesteCF en el pasado (semilla→firma→token, recepción→ARECF firmado) — esto NO es el estatus de DGII para tu RNC hoy; usa el simulador de abajo para un chequeo rápido, o revisa el portal de la DGII para el estatus real.
📥 Documentos Recibidos (Recepción / Aprobación Comercial) — ver aquí
Herramienta del middleware (requiere la clave de administrador; si ya entraste al admin portal en este navegador, se usa esa sesión). Abrir en pantalla completa ↗
🧪 Simular un e-CF entrante (Recepción) contra este servidor
Siempre responde HTTP 200 con el XML del acuse (ARECF) — Estado 0 dentro de ese XML significa recibido, Estado 1 significa no recibido (falta RNCEmisor o eNCF legibles). Se firma con tu certificado si el RNC Comprador coincide con uno registrado (132307739); si no, el acuse vuelve sin firmar.
10
Inicio Prueba Recepción Aprobación Comercialmanual
Igual que el paso 8, pero para el flujo de Aprobaciones/Rechazos Comerciales — confirmar URLs e indicar que el sistema está listo.
📋 Mismas URLs del paso 7 — por si las necesitas de nuevo aquí
Host (usar en los 3 campos del formulario DGII)portal.easy-ims.com
✅ Endpoint destino (POST /fe/aprobacioncomercial/api/ecf) probado en vivo contra la instancia desplegada — caso aceptado (200) y caso rechazado sin eNCF (400) responden correctamente. Usa el simulador del paso 11 para repetir la prueba; esto NO es el estatus de DGII para tu RNC hoy.
11
Recepción Aprobación Comercialconstruido
DGII envía Aprobaciones/Rechazos Comerciales de prueba; el sistema responde OK / Error por cada una.
✅ POST /fe/aprobacioncomercial/api/ecf — código probado (200 en aceptación); NO es el estatus de DGII para tu RNC hoy, revisa el portal para eso.
📥 Documentos Recibidos (Recepción / Aprobación Comercial) — ver aquí
Herramienta del middleware (requiere la clave de administrador; si ya entraste al admin portal en este navegador, se usa esa sesión). Abrir en pantalla completa ↗
🧪 Simular una Aprobación Comercial (ACECF) contra este servidor
El botón llama a location.origin — el mismo host desde donde cargaste esta página (Render si estás aquí en producción, tu localhost si corres el middleware local). El HTTP 200 confirma que el endpoint recibió el ACECF, lo parseó y lo guardó como InboundDoc (kind="ACECF") en la base de datos de esa misma instancia. Un HTTP 400 ("ACECF inválido: falta eNCF") es el caso de rechazo — ocurre cuando el XML no trae un eNCF legible.

Etapa 3 · Certificación

Trámite final y activación productiva. Pasos 12–15.
12
URL Servicios Producciónmanual
Registrar en la OFV las URLs de Recepción, Aprobación Comercial y Autenticación del ambiente productivo (no el de prueba). Quedan cargadas en el directorio electrónico de DGII.
📋 URLs para pegar en este paso
Host (usar en los 3 campos del formulario DGII)portal.easy-ims.com
Mismo host que el ambiente de prueba (una sola instancia atiende ambos) — el modo SIM/REAL y TESTECF/CERTECF/PRODUCTION se controla por variables de entorno, no por URL distinta.
13
Declaración Juradamanual
Formulario legal, bajo fe de juramento, firmado en XML por el representante — declara que la certificación se hizo de forma íntegra, sin fraude ni irregularidades. Confirmado en pantalla real 2026-09-01: DGII también valida ahí la relación del representante con el RNC y su estatus en la OFV.
1️⃣ En la pantalla del propio Paso 13, clic en "GENERAR ARCHIVO" — DGII te entrega el XML de la Declaración Jurada listo para firmar (no hace falta ir a buscarlo a la OFV, como se pensaba antes).
2️⃣ Fírmalo abajo (mismo firmador genérico del admin portal, ejecutable aquí mismo).
3️⃣ Sube el XML firmado en "Envío de archivo de declaración jurada firmado" (campo XML) en esa misma pantalla.
⚠️ El firmador es genérico y funciona con cualquier XML (probado con e-CF y semilla de autenticación), pero el formato de firma que usamos (XML-DSig envuelto, sin prefijo ds:) todavía no está confirmado para este tipo de documento — si DGII lo rechaza, puede requerir un formato distinto (p. ej. XAdES-BES).
🖊️ Firmar XML genérico (Paso 13)
⚠️ Si sale "HTTP 401: Bad or missing X-Admin-Key / session": la casilla Admin Key tiene algo que el gateway no acepta (por ejemplo la contraseña de un operador: esa sirve para entrar al admin portal, no es la Admin Key), y lo escrito se usa en lugar de su sesión. Solución: 1) deje Admin Key vacía; 2) en otra pestaña del mismo navegador entre al admin portal con su usuario y contraseña (o la Admin Key maestra); 3) vuelva aquí, recargue (Ctrl+F5), elija el XML y firme. La sesión vence: si vuelve el 401 más tarde, entre de nuevo al admin portal. Alternativa: el panel morado 🖊️ Firmar XML genérico dentro del admin portal no pide clave.
14
Verificación Estatusno aplica
DGII confirma que el RNC sigue al día: obligaciones tributarias, clave OFV, Alta NCF y representante registrado.
Sin pantalla propia — DGII lo verifica internamente y pasa directo al Paso 15; el rail izquierdo solo lo marca ✓ sin mostrar una vista dedicada (confirmado en la captura del Paso 15, que ya muestra el 14 en verde).
15
Finalizadometa
Certificación como Facturador Electrónico completada. Se habilita en la OFV el menú de facturación electrónica: contingencia, delegación, consulta de e-CF emitidos/recibidos/anulados, y mantenimiento del directorio electrónico.
Nota: el contribuyente puede cancelar la postulación en cualquier paso del 1 al 13, indicando el motivo (cambio de representante, cambio de proveedor, etc.) y volver a postularse. Ed certifica sus 2 RNC propios directamente como emisor — esto no requiere autorización PSFE (esa es solo para transmitir por cuenta de terceros).
Captura de la pantalla real de la DGII