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.

Cómo usarlo

1. Certificado Digital P12 — subí el .p12 que te entregó la entidad certificadora (Viafirma, Avansi, etc.) y guardá su password. Queda encriptado en el vault de Supabase.
2. Datos del Emisor — completá razón social, RNC, dirección, teléfono, email, régimen fiscal. Estos datos se inyectan en cada e-CF emitido.
3. Postulación DGII — bajá el XML de Postulación desde el portal de certificación DGII, subilo aquí, firmá con P12 y descargá el firmado para subirlo al portal.
4. 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.
5. 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.
6. Secuencias e-NCF — agregá los rangos autorizados por DGII para cada tipo de e-CF (31, 32, 33, 34, 41, 43, 44, 45, 46, 47).
7. API Keys (e-CF como servicio) — emití claves para que sistemas externos consuman tu emisor vía la API REST.
8. 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):

1. En la OFV personal del representante legal, andá a Delegación de e-CF → Delegación de Roles. Buscá tu cédula, marcá los 4 roles (Administrador, Firmante, Solicitante, Aprobador), aceptá los términos y descargá el XML.
2. 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.
3. Volvé a la OFV → Delegación de e-CF → Carga XML Delegación, subí el _firmado.xml y guardá.
4. Andá al Buzón de la OFV personal, abrí los mensajes "Delegación de Rol de Facturación Electrónica" y aceptá cada rol.
5. 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 .p12 o 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: rehacé 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

¿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.