Configuración e-CF
Centraliza los datos fiscales del emisor, el certificado digital P12, las secuencias e-NCF, los pasos de la certificación DGII y la habilitación PROD vía Delegación de Roles.
Checklist: qué necesita un tenant para certificarse
Revísalo antes de crear la postulación. Cada punto que falte aparece después como un bloqueo en medio del proceso, y varios pasos de la DGII se reinician ante cualquier rechazo.
Ante la DGII (fuera de la app)
- [ ] RNC activo y al día con las obligaciones tributarias (declaraciones y pagos). La DGII lo comprueba al final, en «Verificación de estatus»: una omisión abierta detiene la certificación en el último paso.
- [ ] Clave de Oficina Virtual (OFV) de la empresa, y acceso al Buzón: ahí llega la invitación al Portal de Certificación y las respuestas de cada paso.
- [ ] Solicitud de Emisor Electrónico presentada en OFV (formulario FI-GDF-016). La DGII responde por el Buzón con el acceso al portal de certificación.
- [ ] Certificado digital para Procedimiento Tributario vigente, emitido por una entidad certificadora autorizada (Viafirma, Avansi/Digifirma, Cámara de Comercio), en archivo .p12 con su contraseña. Puede ser de la empresa o de su representante (persona física).
- [ ] Si el certificado es de una persona física y el RNC es de una empresa: hacer la Delegación de Roles de Facturación Electrónica en OFV (el representante delega al RNC). No bloquea la certificación, pero sin ella la autenticación en producción falla. Hazla temprano.
- [ ] Un correo que la empresa revise: la DGII avisa por el Buzón, y la app envía la copia de los e-CF al correo del emisor.
En la app (Fase 0 del asistente los valida solos)
- [ ] P0.1 Certificado P12 cargado en Config e-CF, con contraseña; el sistema extrae vigencia y titular. Quien lo carga debe ser dueño o administrador del tenant (la clave privada no está al alcance de otros roles).
- [ ] P0.2 Datos del emisor completos: RNC, razón social, nombre comercial, dirección (obligatoria en el XML), teléfono, correo. Municipio y provincia solo viajan como código DGII de 6 dígitos; si no los tienes, déjalos vacíos.
- [ ] P0.3 Postulación firmada con el P12 y subida al portal. La app la firma; tú la subes.
- [ ] P0.4 Delegación (ver arriba). Aplica al pasar a producción.
- [ ] Secuencias e-NCF de certificación: un rango activo por cada uno de los 10 tipos (31, 32, 33, 34, 41, 43, 44, 45, 46, 47) en Secuencias e-NCF, con fecha de vencimiento. En certificación el rango es libre (1 a 10,000,000). Sin ellas el Paso 4 no emite nada. El cierre de certificación las anula; los rangos de producción los autoriza la DGII después.
- [ ] Contactos: al menos un cliente con RNC (o el botón «Usar a Khaostozen como cliente de simulación»), el consumidor final y un contacto extranjero para 46/47 (o su botón de simulación). El asistente del Paso 4 te lo pide si falta.
- [ ] Catálogo con al menos un servicio o producto con precio. Si está vacío, el asistente usa una línea genérica de simulación.
- [ ] Nombre y versión del software para la postulación: Simpli5CRM y la versión que muestra el pie de la app.
Durante el proceso
- [ ] Los pasos 2, 3 y 4 se reinician enteros ante un solo rechazo. Emite con el asistente, no a mano, y no subas al portal archivos que no salgan del panel correspondiente.
- [ ] Los pasos 6, 11 y 14 los resuelve la DGII a su ritmo (días). El asistente los marca con «Avanzar» cuando el portal confirme.
- [ ] Para los pasos 7 a 11 (recepción), las URL de servicios las genera la app; la DGII envía documentos de prueba a esas URL y la app responde sola.
- [ ] Al terminar: Activar Producción en la app purga los documentos de prueba, anula las secuencias de certificación y retira las facturas de simulación. Después registra los rangos e-NCF de producción que te apruebe la DGII.
Cómo usarlo
- Certificado Digital P12 — sube el
.p12que te entregó la entidad certificadora (Viafirma, Avansi, etc.) y guarda su contraseña. Queda encriptado en el vault de Supabase. - Datos del Emisor — completa razón social, RNC, dirección, teléfono, email, régimen fiscal. Estos datos se inyectan en cada e-CF emitido.
- Postulación DGII — baja el XML de Postulación desde el portal de certificación DGII, súbelo aquí, fírmalo con el P12 y descarga el firmado para subirlo al portal.
- Delegación de Roles e-CF — paso post-certificación obligatorio cuando el cert es personal y el RNC corporativo. Sin esto, ValidarSemilla en PROD rechaza la autenticación.
- Ambiente DGII — readonly. Indica si este tenant emite contra TEST, CERT o PROD. Se activa automáticamente vía el closeout (botón Activar Producción) tras completar las pruebas DGII; no se cambia a mano.
- Secuencias e-NCF — agrega los rangos autorizados por DGII para cada tipo de e-CF (31, 32, 33, 34, 41, 43, 44, 45, 46, 47).
- API Keys (e-CF como servicio) — emite claves para que sistemas externos consuman tu emisor vía la API REST.
- Parámetros Operativos — ITBIS por defecto y Modo Sandbox (intercepta envíos a DGII y devuelve respuestas ficticias para entrenamiento).
Delegación de Roles e-CF (post-certificación)
Si tu certificado es personal (Persona Física) y emitís en nombre de un RNC corporativo, DGII exige que el RNC delegue formalmente los roles de Facturación Electrónica al titular del cert. Sin esta delegación registrada en el ambiente PROD, la autenticación contra ValidarSemilla falla con HTTP 400 y un HTML genérico (<h2>ERROR: </h2>), porque DGII rechaza la petición en su capa de infraestructura antes de llegar a la aplicación.
Flujo end-to-end (5 pasos resumidos):
- En la OFV personal del representante legal, ve a Delegación de e-CF → Delegación de Roles. Busca tu cédula, marca los 4 roles (Administrador, Firmante, Solicitante, Aprobador), acepta los términos y descarga el XML.
- Subí el XML al bloque Delegación de Roles e-CF de esta pantalla y presioná Firmar con P12. La plataforma firma con el mismo cert del vault y te descarga el XML firmado automáticamente.
- Volvé a la OFV → Delegación de e-CF → Carga XML Delegación, subí el
_firmado.xmly guardá. - Andá al Buzón de la OFV personal, abrí los mensajes "Delegación de Rol de Facturación Electrónica" y aceptá cada rol.
- Verificá en Consulta de Delegaciones que los 4 roles aparezcan aprobados.
Después de paso 5, probá la conexión en Monitor DGII → Probar Conexión a DGII. Debería devolver token JSON en lugar del 400 ERROR.
Guía detallada paso-a-paso (incluye screenshots, errores comunes, troubleshooting): ver docs/dgii-activacion-prod.md — playbook completo para clientes nuevos.
Validación automática P12 ↔ Delegación
Probar Conexión a DGII compara la huella SHA-1 del certificado P12 actual contra la huella del cert que firmó tu última Delegación FE registrada in-app, y muestra el resultado como step delegacion:
- ✅ OK — las huellas coinciden, la Delegación está alineada con el cert actual.
- ⚠ Warning "P12 actual ≠ cert que firmó la Delegación" — renovaste el
.p12o subiste otro y la Delegación quedó atada al cert anterior. DGII vincula la autorización a la huella del cert, no al sujeto, así que la delegación está huérfana. Solución: rehaz el flujo Delegación de Roles (pasos 1–5) con el cert actual. - ⚠ Warning "Sin Delegación FE registrada in-app" — no hay evidencia firmada por la plataforma. Si firmaste con la App Firma DGII externa no podemos verificar coincidencia; subí el XML aquí y firmá nuevamente para registrar la evidencia.
Modo Sandbox / Entrenamiento
Cuando está activo, todo envío a DGII para este tenant se intercepta y devuelve respuestas ficticias (TrackId con prefijo MOCK-, asientos contables marcados [MOCK_QA_SUBMIT]). Sirve para entrenar usuarios sin riesgo fiscal. Apagar antes de salir a producción real — combinarlo con ambiente PROD genera la trampa silenciosa de "creés que emitís y nada llega a DGII".
Permisos
- owner / firm_admin / accountant — pueden editar todos los campos y firmar XMLs.
- cashier / sales — solo lectura.
Preguntas frecuentes
Las Fases 1, 2 y 3 me salen «Bloqueada». ¿Es por la Delegación de Roles?
No. La Delegación (P0.4) solo condiciona el paso a Producción, nunca las pruebas de certificación — puedes gestionarla cuando termines. Lo que abre las fases 1-3 es P0.1 Certificado + P0.2 Datos del Emisor + P0.3 Postulación. Si las ves bloqueadas, revisa cuál de esos tres está incompleto.
Dice que suba el certificado, pero yo sé que ya está cargado.
Si entraste con una cuenta invitada y no eres el dueño, necesitas rol de administrador para leer el certificado: es la clave privada de firma y no está al alcance de todos los miembros. Pide al dueño que te cambie el rol. La pantalla te lo indica cuando detecta que el certificado existe pero tu cuenta no lo alcanza.
¿Por qué ValidarSemilla en PROD me devuelve 400 con HTML genérico?
99% del tiempo es porque falta la Delegación de Roles del cert personal hacia el RNC corporativo en el ambiente PROD, o porque renovaste el P12 y la Delegación quedó atada al cert anterior. Hacé el flujo de Delegación arriba; el step delegacion de Probar Conexión te avisa si hay mismatch de huella.
¿Cómo distingo "delegación faltante" de "XML mal formado"?
Por el Content-Type de la respuesta DGII: si es text/html con <h2>ERROR: </h2> y headers reducidos (sin set-cookie citrix_ns_id), DGII rechazó en infraestructura → falta delegación o el cert no está autorizado. Si es application/json con {mensaje, errores}, llegó a la app → revisar el XML/firma.
¿Puedo firmar el XML de Delegación con la App Firma DGII en lugar de la plataforma?
Sí, pero no hace falta. La plataforma usa el mismo XMLDSig estándar (RSA-SHA256, C14N, SHA-256) que la App Firma — el resultado es equivalente.
¿La firma se rehace cada vez que cambio de ambiente?
No. La firma es independiente del ambiente. La delegación que registrás en PROD vale sólo para PROD, y la de CERT sólo para CERT.
En el Paso 4 no encuentro dónde subir el Set de Pruebas.
No hay archivo. El Paso 4 se emite como facturas normales, con datos de tu
operación: son 25 comprobantes de 10 tipos distintos. El paso trae su propio
asistente de simulación: elige qué contacto hace de cliente, de consumidor
final y de extranjero (los selects vienen ya elegidos cuando no hay duda), revisa
el plan de las 25 facturas que arma con tu catálogo, y pulsa Emitir. Las crea
marcadas como simulación (número SIM-P4-…, nota «sin validez fiscal») y las
envía una por una en el orden del portal; se detiene en el primer rechazo y te
muestra el motivo. Lo ya aceptado no se repite al volver a pulsar. Al activar
producción, el cierre retira esas facturas del listado.
La tabla de arriba muestra las 11 casillas del portal (la factura de consumo se
parte en dos: de RD$250,000 en adelante y por debajo) y se va llenando a medida
que la DGII acepta. Solo cuentan los emitidos desde el CRM: los del Set de
Pruebas del Paso 2 no valen aquí aunque estén aceptados.
¿De verdad la DGII quiere datos «reales» en una certificación? Mi empresa es nueva y no tiene clientes.
«Datos de operaciones reales» quiere decir datos propios y verosímiles, no el
set de la DGII (ese fue el del Paso 2) ni clientes de verdad. En certificación la
DGII solo comprueba que el RNC del comprador exista; no valida quién es ni si es
tu cliente. Khaostozen certificó en abril de 2026 sin un solo cliente, con
compradores inventados sobre el RNC del contribuyente de pruebas de la DGII. El
asistente hace lo mismo: si no tienes contactos con RNC ni extranjeros, dos
botones crean los contactos de simulación que hacen falta, marcados como tales.
El cliente de simulación es Khaostozen Technologies SRL, la empresa de la
plataforma (RNC real y activo); solo si el tenant que certifica es Khaostozen se
usa el contribuyente de pruebas de la DGII, porque el emisor no puede ser su
propio comprador.
Subí un archivo en el Paso 2 y dice que es el del Paso 3.
La DGII entrega dos archivos parecidos. El del Paso 2 trae la hoja ECF con
los comprobantes que tú emites. El del Paso 3 trae ACEECF_Generadas: el
emisor es el contribuyente de pruebas de la DGII, tú eres el comprador, y trae la
columna FechaHoraAprobacionComercial. Ese va en el Paso 3.
¿Las facturas de simulación se pueden quitar del CRM?
Sí, en dos momentos. Cuando la matriz llega a 25 de 25, el asistente ofrece
enviarlas a la Papelera (salen de Facturación, KPIs y CxC; se pueden
restaurar). Mientras la matriz no esté completa hay que dejarlas: las notas 33 y
34 se cuelgan de las 31 aceptadas. Y al activar producción, el cierre de
certificación las elimina del todo, junto con los contactos de simulación y los
e-CF de prueba. La representación impresa del Paso 5 y las facturas de consumo
pequeñas para subir al portal no dependen de ellas: salen de los e-CF aceptados.
Paso 5: ¿de dónde salen las 11 representaciones impresas y en qué formato?
Del propio asistente, debajo del Paso 5: una fila por casilla del portal (31, 32
de 250K en adelante, 33, 34, 41, 43, 44, 45, 46, 47 y 32 por debajo de 250K),
tomando el e-CF aceptado del Paso 4 de cada tipo. Para la de consumo pequeña usa
la factura completa firmada al emitir, no el Resumen: ahí están las líneas y
el código de seguridad que valida el QR. El botón PDF abre la vista de
impresión: elige «Guardar como PDF». El portal admite hasta 10 MB en total.
Antes de subir, escanea el QR de cada una: debe abrir ConsultaTimbre y decir
«Aceptado». Marca en la fila si el QR validó.
¿Puedo crear las facturas a mano en vez de usar el asistente?
Sí, desde Facturación, con el tipo e-CF y el contacto adecuados (ver más abajo).
El asistente hace lo mismo, en el orden correcto y sin transcribir nada.
Antes de emitir el primero: registra las secuencias.
Cada tipo necesita un rango de e-NCF activo en Secuencias e-NCF (más abajo en
esta misma pantalla). Sin él, el envío falla con «Sequence error» y no llega a la
DGII. En certificación el rango es libre (1 a 10,000,000 por tipo); pon un
vencimiento porque el XML lo lleva y el esquema lo exige en casi todos los tipos.
El panel del Paso 4 te dice qué tipos siguen sin secuencia. Si ya emitiste
documentos del Paso 2 con números fijos, empieza el rango por encima de ellos:
en certificación un número usado no se repite.
¿Qué pasa con esas secuencias al activar producción?
El cierre de certificación las anula (quedan como «anuladas» para auditoría) y
purga los documentos de prueba. Los rangos de producción los autoriza la DGII
después de certificar: regístralos entonces, con su vencimiento real.
¿Cómo se emite cada tipo desde Facturación?
Con el tipo e-CF correcto en la factura y el contacto adecuado:
- 31, 44, 45: contacto con RNC. Para el 45 tiene que ser una entidad del
Estado; para el 44, una empresa de régimen especial (zona franca, etc.).
- 32: consumidor final, con o sin RNC. Dos por RD$250,000 o más y cuatro por
menos; estas últimas mandan solo el Resumen y se suben a mano al final.
- 41: el «contacto» es el proveedor informal al que le compras (su cédula
va como RNC del comprador).
- 43: gastos menores. No lleva comprador; el contacto de la factura se
ignora.
- 46, 47: contacto extranjero, con tipo de identificación Pasaporte o
Tax ID y su identificador; el país se toma del contacto. Sin ITBIS. Si no
tienes ninguno, el asistente crea uno de simulación con un clic. El 47 solo
admite servicios y lleva retención de ISR; el 41 lleva retención de ITBIS e
ISR (el asistente las pone).
- 33 y 34: desde la factura ya aceptada, botones ND y NC en la lista.
Referencian ese documento; no se crean sueltas.
Las líneas sin ITBIS viajan como exentas; en la 46 todo va con ITBIS 0%.
El total del XML se recalcula desde las líneas y, si no cuadra con el de la
factura, el envío se detiene con un mensaje que muestra ambos montos.
¿En qué orden hay que emitirlos?
El portal lo fija y conviene respetarlo:
- Los tipos 31, 32 (≥250K), 41, 43, 44, 45, 46 y 47.
- Después las notas: 33 y 34 — referencian a los de arriba, así que no pueden ir antes.
- Los Resúmenes de las facturas de consumo menores a 250K.
- Y solo cuando esos Resúmenes estén aceptados, las facturas completas de esas mismas.
Aquí una secuencia rechazada se pierde.
A diferencia del Paso 2 —donde los e-NCF venían fijos en el Excel y se reintentaba
con el mismo— en el Paso 4 el número de un comprobante rechazado no se reutiliza:
el reintento va con el siguiente. Y cualquier rechazo reinicia el paso completo.
Emite despacio y revisa antes de enviar.
¿De dónde saco las facturas de consumo <250K que pide el último tramo?
Del propio asistente: en el Paso 4, debajo de la lista de aceptados, aparece un
botón por cada una. Ese archivo es el que se firmó al emitirla, y es el único que
el portal acepta — uno vuelto a firmar lleva otra hora y por tanto otro código de
seguridad, distinto del que ya viajó en el Resumen.
Subí el archivo del Set de Pruebas y me dice que no encuentra la hoja «ECF».
Son dos archivos distintos y se parecen. El del Paso 2 trae la hoja ECF con los
comprobantes que tú emites; el del Paso 3 trae ACEECF_Generadas con las facturas
que otra empresa te emitió y tú tienes que aprobar. La pantalla te dice cuál subiste y
cuál esperaba: llévalo al paso que le toca.
El Paso 3 (Aprobaciones Comerciales) no se sube al portal de la DGII.
Correcto, y es la parte que más confunde. En el Paso 2 firmas y subes; en el Paso 3
envías las aprobaciones al servicio de la DGII desde la plataforma, y el portal se
actualiza solo. Sube el archivo, revisa la lista y pulsa Enviar aprobaciones. Van una
por una a propósito: si alguna falla, ves cuál.
La DGII rechazó una aprobación por la fecha y hora, y ahora el set aparece vacío.
La hora de la aprobación no es la del envío: la DGII la fija en el archivo que te
entrega y la compara al segundo. La plataforma la reenvía tal cual, así que no la
modifiques al abrir el Excel. Y sí, cualquier rechazo reinicia el set completo —no
solo el comprobante rechazado—, así que hay que volver a enviarlo entero. Reenviar es
seguro: no se duplica nada.
Si el Set de Pruebas falla, ¿puedo volver a enviarlo con el mismo archivo?
Sí. El Excel del Set de Pruebas trae los e-NCF fijos, y la DGII no consume la secuencia cuando rechaza (responde secuenciaUtilizada: false), así que reenviar el mismo documento con el mismo e-NCF es lo correcto. La plataforma reutiliza el registro del intento fallido y lo deja limpio antes de reenviar. Corrige lo que reportó la DGII (datos del emisor, secuencias, XML) y vuelve a pulsar Generar y Enviar con el mismo archivo.
Esto aplica sólo a documentos en estado Rechazado o Error, y sólo fuera de producción. Si el e-NCF corresponde a un documento aceptado o todavía en vuelo, la plataforma lo bloquea con un aviso: un e-CF aceptado no se reescribe, se corrige con una Nota de Crédito (tipo 34).
El contador del botón "Generar y Enviar" no coincide con la suma de las hojas del Excel. ¿Está bien?
Sí. La hoja RFCE del Set describe los mismos documentos que las facturas de consumo menores a 250 000 de la hoja ECF — es su representación resumida, no documentos aparte. La plataforma los emite una sola vez: arma la factura completa, la firma, extrae el CodigoSeguridadeCF de esa firma y envía el RFCE. Por eso el botón cuenta los documentos de la hoja ECF.