01Objetivo
Minimizar el impacto de fallos, incidentes o eventos imprevistos sobre la emisión y recepción de comprobantes fiscales electrónicos (e-CF), asegurando que la información pueda recuperarse y que el servicio se restablezca de forma ordenada.
02Escenarios contemplados
- Fallos de software o errores en la configuración de los sistemas.
- Caída o degradación del proveedor de infraestructura o alojamiento.
- Pérdida de conectividad a internet.
- Indisponibilidad temporal de los servicios de la DGII.
- Pérdida, corrupción o eliminación accidental de información.
- Incidentes de seguridad que obliguen a aislar o suspender un sistema.
- Vencimiento o compromiso de certificados digitales.
03Respaldo de información
Se mantienen copias de seguridad de la información necesaria para restablecer los servicios, incluyendo la configuración fiscal del cliente y los comprobantes emitidos y sus respuestas.
- Frecuencia de respaldo: diaria (snapshots automáticos)
- Ubicación de los respaldos: AWS, región us-east-1
- Período de retención: 30 días
04Recuperación ante fallos
- 1Identificación. Se detecta la falla mediante monitoreo, reporte del cliente o error en la transmisión.
- 2Evaluación. Se determina el alcance: clientes afectados, comprobantes pendientes y causa probable.
- 3Contención. Se aísla el componente afectado para evitar pérdida de datos o duplicidad de comprobantes.
- 4Recuperación. Se corrige la falla o se restaura desde el último respaldo válido.
- 5Verificación. Se confirma la integridad de la información y el correcto envío de los comprobantes pendientes.
- Tiempo objetivo de recuperación (RTO): 4 horas
- Punto objetivo de recuperación / pérdida máxima de datos tolerada (RPO): 24 horas (último respaldo diario)
05Indisponibilidad de los servicios de la DGII
Cuando los servicios de recepción de la DGII no estén disponibles, se aplican los procedimientos de contingencia establecidos por la DGII en la normativa de facturación electrónica vigente. Los comprobantes afectados se identifican y se transmiten una vez restablecido el servicio, dentro de los plazos que la normativa establezca.
El sistema de RUTIVERSOTECH opera mediante una cola de procesamiento:
- Cada comprobante se crea y se firma digitalmente de inmediato, y queda guardado en el sistema antes de enviarse a la DGII.
- El envío se realiza en segundo plano. Si la DGII no responde o no está disponible, el comprobante permanece en cola y el envío se reintenta automáticamente hasta obtener una respuesta definitiva: aprobado, aprobado condicional o rechazado.
- El cliente puede consultar el estado de cada comprobante en todo momento a través de la API.
- Si un comprobante se reenvía con el mismo número e-NCF o la misma referencia externa, el sistema devuelve el documento existente sin duplicarlo, lo que permite reintentar de forma segura tras un corte de conexión.
06Incidentes de infraestructura
Ante una falla del proveedor de alojamiento, red o base de datos, RUTIVERSOTECH coordina con el proveedor correspondiente, informa a los clientes afectados y, cuando sea necesario, restablece el servicio en un entorno alternativo a partir de los respaldos disponibles.
Infraestructura principal: Amazon Web Services (AWS). Entorno alternativo: restauración desde el último respaldo en una nueva instancia de AWS.
07Restauración del servicio
- Se verifica que el sistema funcione correctamente antes de reanudar la emisión.
- Se revisa el estado de los comprobantes emitidos durante el incidente para evitar duplicidades o faltantes.
- Se reenvían los comprobantes pendientes y se confirma su estado ante la DGII.
- Se informa al cliente el cierre del incidente y cualquier acción que deba realizar.
- Se documenta la causa y las medidas preventivas adoptadas.
08Comunicación con clientes
Durante una interrupción, RUTIVERSOTECH informa a los clientes afectados por los canales oficiales indicados en Soporte y Vías de Asistencia, indicando la situación, el impacto y los avances hasta su resolución.
09Revisión y pruebas
Esta política y los procedimientos de restauración se revisan periódicamente y tras cualquier incidente relevante.
Frecuencia de pruebas de restauración de respaldos: mensual.