Contingencia DGII / e-CF en operación real

La contingencia no es un “modo de emergencia” para el brochure. Es lo que decide si a las 12:40, con la fila en la puerta y la DGII sin responder, usted sigue cobrando o anota en un cuaderno “para facturar después”. Esta guía describe cómo debe comportarse un e-CF en operación real: mostrador, red inestable y cierre del día.

1. Qué es la contingencia (en lenguaje de caja)

Contingencia significa: el sistema acepta la venta, genera el comprobante según las reglas vigentes, lo deja listo para transmisión y reintenta cuando el servicio de la DGII vuelve. El cliente no se queda esperando un “timeout” del portal. El supervisor no inventa un NCF a mano.

No confundir con:

• “Guarde el XML y súbalo usted mañana” — eso es trabajo manual, no contingencia.
• “Use el facturador gratis mientras tanto” — doble digitación y descuadre de inventario.
• “Anule y vuelva a intentar” — pierde la fila y el control de caja.

2. Cuándo “cae” la DGII (escenarios reales)

• El servicio de recepción no responde o responde tarde.
• Hay saturación en horarios pico (cierres de mes, fechas límite).
• Su local tiene internet intermitente: la falla puede ser suya, no del fisco — el sistema igual debe encolar.
• El certificado o la secuencia están mal configurados: eso no es contingencia; es un error de implementación que hay que corregir antes del go-live.

3. Flujo correcto en el mostrador

1. El cajero cobra (efectivo, tarjeta, mixto).
2. El sistema arma el e-CF (E31/E32 u otro tipo).
3. Intenta transmitir a la DGII.
4. Si no hay respuesta aceptable: marca el documento en cola de contingencia, imprime o entrega representación según política, y no bloquea la siguiente venta.
5. Un proceso de reintento (automático) vuelve a enviar hasta aceptación o hasta que soporte revise el rechazo.
6. Inventario y asiento ya reflejaron la venta; no se “espera a que DGII diga sí” para descontar el SKU.

En abaPOS: si la DGII no responde, la venta se cierra y el comprobante se encola y reenvía. Detalle de producto: facturación electrónica e-CF.

4. Checklist: ¿su software tiene contingencia de verdad?

Capacidad	Pregunte en la demo
Encolar sin perder la venta	¿Puedo cobrar 20 tickets seguidos con DGII caída?
Reintentos automáticos	¿Cada cuánto reintenta? ¿Hay tope y alerta?
Visibilidad	¿Veo la cola de pendientes y el estado de cada e-CF?
Rechazos vs timeout	¿Distingue “DGII no respondió” de “documento rechazado”?
Reportes	¿El 607 incluye lo emitido en contingencia una vez aceptado?
API / multi-RNC	Si integra varios emisores, ¿la cola es por RNC?

5. Riesgos si no hay contingencia

• Pérdida de venta: el cliente se va; el ticket queda “a medias”.
• Dobles documentos: se reintenta a mano y se duplica el comprobante.
• Inventario mentiroso: se vendió en cuaderno pero el sistema no bajó stock.
• 607 incompleto: a fin de mes alguien completa desde WhatsApp y memoria.
• Multas y estrés: no por “no querer cumplir”, sino por no poder operar el día.

6. Buenas prácticas operativas

• Antes del go-live: pruebe contingencia a propósito (corte de red o ambiente de prueba), no el primer sábado de diciembre.
• Roles: quién puede forzar reenvío o anular un e-CF en cola.
• Impresión: defina qué ve el cliente mientras el documento está pendiente de aceptación.
• Monitoreo: al cierre de caja, revise pendientes de transmisión como parte del ritual — igual que el efectivo.
• Certificado: vigile vencimiento del .p12; un certificado vencido no se “cura” con contingencia.

7. Casas de software e integradores

Si usted emite por API para varios RNCs, la contingencia debe ser del lado del emisor/gateway: aceptar el POST, encolar y reintentar sin que cada pyme reinvente el protocolo. Documentación: API e-CF abaPOS.

8. Relación con el resto del sistema

Contingencia sin POS integrado solo empuja el problema al cuaderno. Contingencia en un ERP que ya movió stock y CxC es lo que mantiene el negocio vivo. Por eso al elegir software use el checklist de sistema contable en RD y no solo “¿emite e-CF?”.

9. Ritual de cierre de día (plantilla)

1. Cierre de caja (efectivo / tarjeta / transferencia) como siempre.
2. Lista de e-CF aceptados del día.
3. Lista de e-CF en cola / contingencia: cantidad y antigüedad.
4. Si hay pendientes > X horas: avisar a soporte o al responsable fiscal (defina X: p. ej. 2 horas en hora pico).
5. Confirmar que stock y CxC cuadran con las ventas del día — no “esperar al lunes a que DGII acepte”.

10. Mitos que escuchará

• “Si la DGII cae, nadie puede vender”. Falso si el software tiene cola real.
• “Contingencia es ilegal”. Lo ilegal es inventar comprobantes o no transmitir cuando el canal vuelve. La operación en contingencia está pensada precisamente para no paralizar el comercio.
• “Con buena fibra no hace falta”. La fibra no evita saturar el receptor fiscal ni un DNS caído en el local.
• “El contador lo resuelve el 5”. El 5 no recupera la fila del viernes ni el inventario ya mentiroso.

11. Indicadores que debe mirar el dueño

• % de e-CF aceptados a la primera vs en cola.
• Tiempo medio en cola hasta aceptación.
• Ventas realizadas durante incidentes (prueba de que no se apagó la caja).
• Rechazos por datos (RNC, totales) vs timeouts — son problemas distintos.

12. Resumen

Contingencia real = vender → encolar → reenviar → reportar, sin doble digitación y sin parar la caja. Si su proveedor no puede demostrarlo en cinco minutos, no lo tiene.

Siguiente lectura: cómo elegir sistema contable en RD · guía e-CF 2026 · canales de soporte.