Saltar al contenido principal

El set de pruebas de la DGII: la etapa que alarga toda certificación

Es el paso donde se atasca casi todo el mundo y el peor documentado del proceso. Qué se prueba, en qué ambiente, y por qué la mayoría de los rechazos son de datos y no de software.

8 min de lectura

Entre la solicitud de Emisor Electrónico y la autorización para emitir en producción hay una etapa que rara vez se explica bien: el set de pruebas. Es una batería de casos de uso que la DGII exige aprobar en su ambiente de certificación, y supera los treinta escenarios.

Qué es el ambiente de certificación

Es un entorno separado del de producción donde los comprobantes que emites no tienen efecto fiscal. Sirve para demostrar que tu sistema genera el XML correcto, lo firma bien, lo transmite y sabe interpretar la respuesta. Nada de lo que emitas ahí cuenta como factura.

Esa separación es útil y conviene aprovecharla: es el único momento en el que puedes equivocarte sin consecuencias. Pasar a producción sin haber provocado deliberadamente los errores en certificación significa descubrirlos con un cliente delante.

Qué se prueba

Los casos cubren los tipos de comprobante que vas a emitir y las variantes de cada uno. A grandes rasgos:

  • Emisión de los tipos de e-CF que corresponden a tu operación.
  • Notas de crédito y de débito, que casi siempre se prueban menos de lo que se usan.
  • Los resúmenes de facturas de consumo electrónicas.
  • La recepción y el procesamiento de las respuestas de la DGII, incluidos los rechazos.
  • Los escenarios de anulación y las secuencias de e-NCF.

Dónde falla la mayoría

El patrón se repite: la gente asume que es un problema de software y casi siempre es de datos. El sistema genera un XML técnicamente válido, pero con información que no cuadra.

  • RNC de clientes mal registrados o con formato incorrecto en la base de datos.
  • Tipos de comprobante asignados al perfil de cliente equivocado.
  • Montos e ITBIS con diferencias de redondeo entre el sistema y lo que espera el validador.
  • Certificado digital mal instalado, vencido o con la contraseña del P12 fuera de sitio.
  • Secuencias de e-NCF mal configuradas o agotadas a mitad de las pruebas.
  • Campos obligatorios vacíos porque en la operación real nunca se llenaban.

Esto último es lo más revelador del proceso: el set de pruebas no audita tu software, audita la calidad de tus datos maestros. Una empresa con el catálogo de clientes limpio pasa rápido. Una que arrastra años de registros incompletos descubre el problema aquí.

Cómo acortarlo

  1. Limpia los datos maestros antes de empezar: RNC, razones sociales, tipos de cliente. Es trabajo que hay que hacer igual, y hacerlo antes evita repetir casos.
  2. Define qué tipos de comprobante necesitas realmente, mirando las facturas del último año en lugar de la lista completa.
  3. Prueba primero los casos de error a propósito, no solo el camino feliz. Un rechazo entendido en certificación es un incidente menos en producción.
  4. Documenta cada caso aprobado con su respuesta. Cuando algo falle en producción, esa es tu referencia.
  5. Deja configurada la contingencia antes de salir: encolar y reintentar, no detener la facturación.

El set de pruebas es una de las etapas de convertirse en emisor electrónico; el resto del recorrido está ahí.

Preguntas frecuentes

Todos los que correspondan a los tipos de comprobante que vas a emitir. Por eso definir bien ese alcance al inicio ahorra tiempo: cada tipo que declares arrastra sus propios casos.

Se corrige y se vuelve a enviar. No hay penalización por fallar en certificación — para eso existe el ambiente. Lo que sí cuesta es el tiempo de ida y vuelta, que es donde se alargan los proyectos que llegan justos a su fecha límite.

Depende del ambiente. Los casos exigen entender tanto el requisito fiscal como el comportamiento del sistema que emite, así que lo habitual es que funcione mejor a cuatro manos: el contador valida que el comprobante es correcto y quien conoce el sistema corrige lo que la validación devuelve.

La aprobación forma parte del expediente de autorización. Si cambias de ruta de emisión o de proveedor, es razonable esperar que haya que volver a validar, porque lo que se certificó fue una configuración concreta. Confírmalo con la DGII para tu caso.

¿Atascado en el set de pruebas?

Es la etapa en la que más acompañamos. Revisamos los casos que fallan, corregimos la causa —que suele estar en los datos, no en el código— y volvemos a enviarlos hasta la aprobación.

Ver el servicio de facturación electrónica e-CF