Mosce ERP · Centro de ayuda
Fiscal

URLs DGII y portal de certificación

Las URLs públicas que Mosce ERP expone para que DGII y otros emisores envíen e-CF entrantes y acuses comerciales a tu RNC. Qué pegar en qué campo del proceso de certificación de la Oficina Virtual, incluida la URL de Autenticación opcional.

Durante la certificación como Emisor Electrónico, DGII te pide registrar las URLs públicas donde tu sistema recibe e-CFs entrantes y acuses comerciales. Mosce ERP expone esas URLs centralmente; vos las pegás en los campos correspondientes de la Oficina Virtual y DGII las usa desde ese momento para rutear comprobantes a tu RNC. Esta guía cubre cuáles son, qué hace cada una y cómo registrarlas.

Tiempo de lectura: ~6 min

Cuándo usar esto

  • Estás iniciando el proceso de certificación DGII (Steps 7 y 12 - Solicitud de URLs) y necesitás los valores que va a pedir el formulario.
  • Tu cuenta está pre-aprobada por DGII y tenés que completar el último paso técnico antes de pasar a producción.
  • Cambiaste de proveedor (te migraste a Mosce ERP desde otro sistema) y necesitás actualizar las URLs registradas.
  • Un proveedor te pregunta a qué URL te puede enviar e-CFs.
  • Querés entender cómo es posible que múltiples tenants usen la misma URL pública sin que los comprobantes se mezclen.

Antes de empezar

  • La Configuración fiscal está completa (RNC, razón social, régimen). Ver Configuración fiscal.
  • Tenés acceso a la Oficina Virtual DGII con tu certificado digital del contribuyente.
  • Ya iniciaste el proceso de certificación en DGII y estás en el paso que solicita las URLs (típicamente Step 7 o Step 12 del flujo de Emisor Electrónico, según la versión vigente del proceso de certificación).
  • Tenés acceso a fiscal:manage en Mosce ERP si querés guardar el ID de confirmación de DGII en el tenant.

Nota sobre la fuente regulatoria. El detalle exacto del paso 7 / 12 del proceso de certificación se especifica en el documento DGII Proceso de Certificación para ser Emisor Electrónico. Antes de presentar tu organización a certificación, verificá los valores y los nombres de los campos contra la versión más reciente del PDF DGII disponible en el portal DGII. Las URLs que Mosce ERP expone (descritas más abajo) son la verdad de implementación; el mapping a campos del formulario DGII puede actualizarse con futuras revisiones del proceso oficial.

Las 3 URLs que Mosce ERP expone

FunciónPathObligatoriaQuién la llama
Recepción de e-CFhttps://api.helix.do/fe/recepcion/api/ecfDGII (y otros emisores) cuando un proveedor te emite un e-CF
Aprobación Comercialhttps://api.helix.do/fe/aprobacioncomercial/api/ecfEl emisor del e-CF cuando confirma comercial sobre uno de tus comprobantes salientes
Autenticación (semilla)https://api.helix.do/fe/autenticacion/api/semillaOpcionalQuien te envía comprobantes, si decidís exigir un token de acceso antes de recibirlos

Dónde verlas. Mosce ERP tiene una pantalla dedicada de URLs Inbound (sección fiscal) que muestra cada URL con un botón Copiar y un badge Registrada / Pendiente registrar que se actualiza cuando DGII confirma cada una. Los valores también están en esta guía por si preferís copiarlos desde acá.

Recepción de e-CF - POST /fe/recepcion/api/ecf (obligatoria)

URL pública: https://api.helix.do/fe/recepcion/api/ecf

Es donde tus proveedores y DGII envían los e-CF que te emiten. Mosce ERP:

  1. Recibe el XML como multipart/form-data con un campo xml que contiene el application/xml firmado.
  2. Identifica el tenant receptor leyendo el <RNCComprador> dentro del XML.
  3. Verifica la firma digital, valida el XSD canónico DGII del tipo correspondiente, persiste el comprobante.
  4. Construye y firma un Acuse de Recibo Electrónico (ARECF) con el certificado de tu tenant.
  5. Devuelve el ARECF en la respuesta HTTP - síncrono, dentro de los 10 segundos.

Una vez recibido, el comprobante aparece en tu Inbox de comprobantes listo para que tomés la decisión comercial.

Aprobación Comercial - POST /fe/aprobacioncomercial/api/ecf (obligatoria)

URL pública: https://api.helix.do/fe/aprobacioncomercial/api/ecf

Es donde tus clientes envían su decisión comercial (ACECF - Acuse Comercial e-CF) sobre los comprobantes que vos les emitiste. Cuando uno de tus clientes acepta, rechaza o acepta parcialmente uno de tus e-CFs, su sistema firma un ACECF y lo POSTea acá. Mosce ERP:

  1. Recibe el XML.
  2. Identifica el tenant emisor por el RNC interno del XML.
  3. Verifica la firma del receptor con el certificado público del que firmó.
  4. Valida el XSD ACECF.
  5. Mapea el <Estado> (aceptado, rechazado, aceptación parcial) al estado correspondiente del comprobante.
  6. Persiste la decisión y actualiza el resumen de aprobación comercial del comprobante para que aparezca en tu pantalla de Documentos e-CF.
  7. Devuelve { codigo: "OK" } o { codigo: "Error", mensaje: "..." }.

Esa decisión queda visible en la pantalla Documentos e-CF de tu emisión saliente - sabés en cualquier momento si tu cliente confirmó comercialmente la operación.

Autenticación (opcional) - dos direcciones

La Autenticación es opcional según DGII: solo la registrás si querés que quien te envía comprobantes se autentique antes de que aceptes su e-CF o su aprobación comercial. Mientras no la exijas, la recepción funciona igual que hoy - Mosce ERP valida la firma digital del XML como control primario de seguridad y no rechaza a los emisores existentes por no traer token.

La fila de Autenticación muestra dos direcciones:

Dirección¿Se registra en el OFV?Qué es
URL de semilla - https://api.helix.do/fe/autenticacion/api/semilla - es la que pegás en el portalGET que devuelve un archivo semilla (XML de un solo uso) que el emisor debe firmar
URL de validación de certificado - https://api.helix.do/fe/autenticacion/api/validacioncertificadoNo - es informativaPOST donde el emisor envía la semilla firmada y recibe el token

El intercambio, en tres pasos:

  1. Quien te va a enviar comprobantes pide una semilla a la URL de semilla (un archivo XML de un solo uso).
  2. Firma esa semilla con su certificado digital y la envía a la URL de validación de certificado.
  3. Si la firma es válida y su RNC está autorizado, recibe un token de acceso temporal (RFC 6750, vigencia de 1 hora) que incluye en el header Authorization: Bearer … al enviarte el e-CF o la aprobación comercial.

En el portal OFV solo se pega la URL de semilla. La URL de validación de certificado es el segundo paso del intercambio y se muestra únicamente como referencia.

Por qué la misma URL sirve a múltiples RNCs

Mosce ERP usa una arquitectura single-host: las URLs públicas están en un único dominio (api.helix.do) y atienden a todos los tenants. El routing al tenant correcto se hace por el <RNCComprador> dentro del XML, no por la URL.

Cuando el comprobante llega a https://api.helix.do/fe/recepcion/api/ecf, Mosce ERP lee ese campo, busca el tenant correspondiente y lo persiste en su scope. Si el RNC del XML no corresponde a ningún tenant en Mosce ERP, la respuesta es un ARECF de rechazo firmado - no se filtra información sobre qué RNCs sí están registrados.

Consecuencias prácticas: no tenés una URL "tuya" (todos los contribuyentes Mosce ERP comparten la misma URL pública); la firma digital del XML y el routing por contenido aseguran aislamiento; DGII permite este modelo porque la especificación define routing por contenido, no por URL.

Cómo encontrar las URLs en Mosce ERP

En la sección fiscal de Mosce ERP, abrí la pestaña URLs Inbound. Cada URL trae un botón Copiar y un badge que indica si DGII ya la confirmó (Registrada) o si todavía la tenés que pegar en el OFV (Pendiente registrar). La fila de Autenticación muestra sus dos direcciones (semilla y validación de certificado). Los valores fijos, por si preferís copiarlos desde esta guía:

Recepción (obligatoria)
  https://api.helix.do/fe/recepcion/api/ecf

Aprobación Comercial (obligatoria)
  https://api.helix.do/fe/aprobacioncomercial/api/ecf

Autenticación - semilla (opcional, se registra en el OFV)
  https://api.helix.do/fe/autenticacion/api/semilla

Autenticación - validación de certificado (informativa, no se registra)
  https://api.helix.do/fe/autenticacion/api/validacioncertificado

Paso a paso - registrar las URLs en la Oficina Virtual

Verificá los nombres exactos de campos contra la versión vigente del Proceso de Certificación para ser Emisor Electrónico DGII antes de presentar a certificación.

  1. Entrá a la Oficina Virtual con tu certificado digital del contribuyente.
  2. Navegá al menú Facturación ElectrónicaProceso de certificación (o equivalente según la versión vigente del proceso).
  3. Ubicá los pasos de Solicitud de URLs (Steps 7 y 12 en el flujo histórico). Vas a ver dos formularios:
    • URL de Recepción de e-CF.
    • URL de Aprobación Comercial.
  4. Pegá las URLs de Mosce ERP correspondientes (sección anterior), una en cada campo.
  5. Si el formulario incluye un campo opcional para URL de Autenticación y querés exigir token, pegá ahí la URL de semilla (.../fe/autenticacion/api/semilla); si no, dejalo en blanco. La URL de validación de certificado no se registra en el portal.
  6. Guardá el formulario. DGII devuelve un ID de confirmación o un código de la solicitud.
  7. Guardá el ID de confirmación en tu archivo del proceso. En la pestaña URLs Inbound de Mosce ERP vas a ver el badge de cada URL pasar a Registrada cuando DGII la confirme.
  8. Esperá a que DGII apruebe el paso. En ese punto, la URL queda activa y empezás a recibir e-CF y ACECF reales.

Troubleshooting

SíntomaCausa probableSolución
DGII rechaza la URL como inválidaURL pegada con espacios al final o con esquema http:// en lugar de https://Volver a copiar desde esta guía exactamente - todas las URLs son https://
El proveedor reporta timeout al enviarme un e-CFEl POST tardó > 10 segundos; típicamente carga muy alta o un tenant con muchos comprobantes en colaEsperar y reintentar; si el problema persiste, contactar soporte para revisar la latencia del endpoint
Recibo Error 415 Unsupported Media TypeEl emisor envió application/json u otro content-type en lugar de multipart/form-data con campo xmlEl emisor debe corregir su cliente; el endpoint solo acepta multipart con un único archivo xml
DGII manda un e-CF pero nunca aparece en Mosce ERPMosce ERP no reconoce el <RNCComprador> (RNC erróneo en el XML) o falló la verificación de firmaPedir al emisor que confirme el RNC dentro del XML; revisar logs de soporte
Cambié de hosting y la URL ya no respondeLos registros DGII apuntan al dominio anteriorActualizar las URLs en OFV a la nueva URL base

Resultado esperado

  • Dos URLs (recepción + aprobación comercial) registradas en DGII y aprobadas como parte del proceso de certificación.
  • El RNC del tenant queda activo como receptor electrónico en DGII.
  • Los comprobantes de tus proveedores empiezan a aparecer automáticamente en el Inbox de comprobantes.
  • Las decisiones comerciales que toman tus clientes sobre tus e-CF aparecen en la pantalla Documentos e-CF.

Relacionados


Última actualización: 2026-07-09

Fuentes regulatorias

  1. DGII - Proceso de Certificación para ser Emisor Electrónico. Antes de presentar tu organización a certificación, verificá los pasos vigentes contra el PDF más reciente en el portal DGII. Los valores que se pegan en el formulario son los mismos aunque DGII renombre los campos en revisiones futuras del proceso.
  2. DGII - Descripción Técnica de los Servicios (bloque Comunicación Emisor-Receptor). Define el servicio de autenticación del receptor: GET /fe/autenticacion/api/semilla retorna la semilla XML; POST /fe/autenticacion/api/validacioncertificado valida la semilla firmada y retorna { token, expira, expedido }, un token de acceso temporal por header Authorization: Bearer … (RFC 6750, vigencia de 1 hora). Disponible en el portal DGII.
  3. DGII - Informe Técnico e-CF v1.0 - «URL Autenticación Opcional»: el registro de la URL de autenticación es opcional para el receptor. Disponible en el portal DGII.