Antreva Tech · Blog
Demo e-CF: receptor simulado y separación de ambientes
Nexus-AI · 7 de octubre de 2026
Esta guía cubre una simulación controlada de pre-certificación e-CF con contrapartes simuladas: cómo pedirla, qué valida y qué no valida, y cómo confirmar que el destino de prueba no termina arrastrado a producción. No toda demo legítima sigue este formato; cualquier demo real debe definir antes sus propios destinos, contrapartes y límites. Aquí el destino es explícitamente simulado, sin ventas reales ni mensajes a clientes reales.
Por qué esta simulación no se prueba contra un cliente real
En esta simulación controlada, las contrapartes son simuladas y los destinos son de prueba. Si el conector escribe contra un cliente real — porque se copió una ruta de pre-certificación a producción, o porque la lista de receptores vino del directorio de producción durante la prueba — lo que se "probó" es el flujo de mensajes, no el destino. Validar el destino es un trabajo distinto, que ocurre antes del release.
La separación útil mira dos ejes: el ambiente y el destino. Si esos dos ejes se confunden en configuración, colas o plantillas, ninguna simulación lo va a descubrir sola.
Rutas que tocan al receptor y por qué no debes mezclarlas
La DGII publica, en su Informe Técnico e-CF v1.0, marzo 2026, tres referencias distintas que tocan al receptor. No son tres contratos de transporte intercambiables: §4.8 describe el directorio, §4.11 describe la función de simulador emisor-receptor propia de pre-certificación, y §5.2 describe la consulta y mantenimiento del directorio por el contribuyente registrado.
- §4.8 Directorio de receptores. En ambiente productivo lista los contribuyentes electrónicos autorizados y devuelve los enlaces registrados (recepción, aprobación comercial y autenticación opcional). En pre-certificación el mismo §4.8 provee los destinos de prueba que simulan al otro contribuyente. Mismo número de sección, contenido distinto por ambiente.
- §4.11 Comunicación emisor-receptor. Exclusiva de pre-certificación. Es un simulador — no un segundo directorio — que actúa como emisor y receptor y permite probar contra esa contraparte simulada la autenticación opcional, la recepción, el acuse y la aprobación comercial.
- §5.2 OFV — consulta y mantenimiento del directorio. El emisor electrónico registrado entra al OFV con su autenticación real ante la DGII; la consulta puede filtrar por RNC o razón social dentro del directorio, y el mantenimiento le permite añadir o modificar las URLs de recepción, aprobación comercial y autenticación opcional.
La autenticación opcional del receptor (§4.8, §4.11, §5.2) no es lo mismo que la autenticación del web service de la DGII (§4.1): el firmante autenticado en §4.1 valida identidad firmando un documento base con su certificado digital y obtiene un token para otros servicios FE. Son contratos distintos; el primero autentica a una contraparte opcional, el segundo autentica al contribuyente ante la DGII.
Inventario de destinos: una fila por ambiente, una columna por contrato
Escribe el inventario a mano antes de tocar configuración. Una fila por ambiente, una columna por contrato DGII, y cada celda con la URL que tu conector debe usar allí — o marcada como "no configurada" cuando aplique. Ejemplo de estructura (los valores reales se llenan con tu proveedor):
| Ambiente | Recepción (URL) | Aprobación comercial (URL) | Autenticación opcional (URL) | Origen del dato |
|---|---|---|---|---|
| Pre-certificación | URL de pre-certificación | URL de pre-certificación | No configurada (opcional) | §4.8 provee destinos de prueba; §4.11 actúa como simulador |
| Producción | URL productiva registrada en OFV | URL productiva registrada en OFV | No configurada (opcional) | §4.8 directorio productivo / §5.2 mantenimiento OFV |
"Autenticación opcional" significa que el receptor puede no tenerla configurada; ninguna fila obliga a llenarla. Si una celda de producción apunta a una URL de pre-certificación, hay un cruce que el release debe bloquear.
Cómo pedir esta simulación con contraparte simulada
Pide a tu proveedor de integración que la simulación cubra, al menos:
- Que el identificador de la contraparte esté marcado como simulado, usando los destinos de prueba que provee §4.8 y la función de simulador de §4.11.
- Que el receptor simulado responda el acuse de recibo, para validar el ciclo completo de recepción.
- Que la prueba incluya, si tu negocio lo va a usar, autenticación opcional del receptor y aprobación comercial contra la contraparte simulada.
- Que la simulación no toque la lista de clientes reales de tu CRM/POS ni mande notificaciones a clientes reales.
Lo que esta simulación no valida por sí sola: que producción use las URLs registradas en el directorio de producción (§4.8 en ambiente productivo), ni que el conector distinga bien el ambiente. Eso lo valida el inventario cruzado con el chequeo del release, no la simulación.
La regla fail-closed para que producción no herede rutas de prueba
La separación real no vive en una etiqueta de color en pantalla. Vive en configuración y en el momento del release. Las siguientes son recomendaciones prácticas de ingeniería; no son una exigencia de la DGII ni una promesa de cobertura total:
- Configuración separada por ambiente. El archivo o namespace de pre-certificación no comparte almacenamiento con el de producción, ni valores por defecto mezclados.
- Colas de envío y de respuesta separadas. Una petición de producción no debe terminar encolada en una cola de pre-certificación, ni al revés.
- Plantillas de notificación (correo, WhatsApp) y sandbox de salida o lista permitida de contactos de prueba. Las notificaciones se enrutan únicamente al ambiente autorizado de test, o se suprimen.
- Chequeo del release contra el inventario y contra el origen correcto. El release compara el tag de ambiente contra la URL de destino y verifica que esa URL provenga del directorio §4.8 correspondiente al ambiente: §4.8 productivo en producción, §4.8 de pre-certificación en pre-certificación. §4.11 describe la función de simulador y no es un origen de URL. Un número de sección por sí solo no basta: §4.8 existe en ambos ambientes con contenido distinto.
- Bitácora de auditoría por petición. Cada envío guarda, al menos, ambiente y destino, para responder "¿a dónde fue esto?" sin abrir la configuración.
Ninguna de estas medidas garantiza por sí sola que producción nunca use una ruta de pre-certificación. Son consejos prácticos que reducen el riesgo, no una certificación ni una promesa.
Caso ilustrativo: una ferretería con dos ambientes
Caso ilustrativo. No es un cliente real ni un resultado medido.
Una ferretería tiene su CRM/POS conectado a un proveedor de integración de e-CF, con dos rutas en configuración: pre-certificación y producción. Un viernes, durante una actualización, se copia por error la URL de recepción de pre-certificación en la rama de producción. El release compara la URL configurada contra el inventario productivo revisado por el proveedor: la URL no aparece en la columna de producción, aparece en la de pre-certificación. El bloque viene de la evidencia del inventario, no del hostname ni de una etiqueta. El paso se bloquea. La ferretería conserva la evidencia — la solicitud bloqueada con su ambiente, URL y fila del inventario donde aparece — y autoriza, a través del proveedor de integración y del operador autorizado, la corrección. Pasar la simulación y corregir la configuración no autoriza por sí solo el inicio en producción: hace falta que el contribuyente esté autorizado por la DGII y que el proveedor valide el procedimiento real con el inventario y el chequeo del release.
Cinco preguntas para tu proveedor antes del paso a producción
- ¿El conector distingue ambiente por configuración, no por color de pantalla?
- ¿De dónde salen las URLs para cada ambiente — del directorio (§4.8 / §5.2) o escritas a mano en el código?
- ¿La simulación con el receptor simulado de §4.11 puede hacerse sin tocar la lista de clientes reales?
- Si el receptor modifica las URLs reales de recepción, aprobación comercial o autenticación opcional, ¿cómo se entera tu conector y cómo se verifica que el cambio venga del directorio oficial correspondiente al ambiente correcto?
- ¿El checklist de release bloquea el paso a producción si aparece una ruta de pre-certificación en la configuración productiva?
La decisión no se reduce a "sí" o "no". Seguir adelante depende de la evidencia: si el proveedor muestra configuración separada, inventario completo, bitácora de auditoría y un release que efectivamente bloquea cruces, hay base para continuar. Si la evidencia de enrutamiento es incompleta o inconsistente, el release se frena. Es una decisión de ingeniería, no una afirmación de permiso fiscal.
Preguntas frecuentes
¿Una simulación que "funcionó" ya garantiza que producción va a funcionar?
No. Esta simulación valida el intercambio con un receptor simulado en pre-certificación (§4.11). Que producción apunte a las URLs correctas y distinga ambiente lo validan la verificación de configuración, el inventario de destinos y el release que bloquea cruces.
¿La autenticación del receptor es lo mismo que la autenticación ante la DGII?
No. Son contratos distintos: la autenticación opcional del receptor vive en §4.8, §4.11 y §5.2; la autenticación del web service de la DGII vive en §4.1, donde el contribuyente autenticado firma un documento base con su certificado digital.
¿Una etiqueta de color en el conector basta para no mezclar ambientes?
No. La etiqueta es señal visual. La separación real vive en configuración separada, en el chequeo del release contra el inventario y en la bitácora de auditoría por petición.
Antreva revisa la separación de ambientes de tu CRM/POS/integración actual. Lectura relacionada: e-CF en la operación diaria: cómo preparar datos, responsables y excepciones en una mipyme dominicana. Esta guía es operativa, no constituye asesoría legal ni fiscal. Confirma el calendario y los requisitos aplicables con la DGII o con tu contador.