Contingencia en SFEP Panamá: Guía Técnica para ISVs

Un PAC que no responde a las 11 PM de un viernes de cierre fiscal no es un escenario hipótetico en Panamá. Los ISVs que operan sobre el sistema SFEP del DGI a través de un Proveedor Autorizado de Certificación deben tener un protocolo de contingencia documentado e implementado antes de llegar a producción. Sin embargo, ni la normativa de la DGI ni la documentación técnica del SFEP define un flujo de contingencia estandarizado para el emisor, lo que deja a cada ISV libre de implementar su propia estrategia con resultados muy dispares.

Esta guía define los tipos de fallo que puede enfrentar un emisor en el flujo SFEP, el protocolo técnico paso a paso para operar en contingencia, cómo implementar almacenamiento offline de documentos pendientes y qué criterios evaluar en un PAC para minimizar el riesgo de fallo. Al terminar, el equipo técnico tendrá un protocolo de contingencia implementable que evita la pérdida de transacciones sin esperar a que el DGI o el PAC se restablezcan.

Marco normativo de contingencia en el SFEP de Panamá

El Sistema de Facturación Electrónica de Panamá (SFEP) opera bajo la resolución DGI-108-2021 y sus actualizaciones. La normativa establece que el emisor es responsable de conservar los documentos electrónicos generados y de garantizar su transmisión al DGI a través del PAC. En caso de contingencia, el emisor debe emitir los comprobantes físicos correspondientes o registrar las operaciones de acuerdo con el procedimiento alternativo habilitado. Sin embargo, el reglamento no define un mecanismo técnico específico de contingencia en el flujo electrónico, lo que implica que la implementación es responsabilidad del ISV y el PAC.

Qué dice la normativa DGI sobre operación en contingencia

La normativa DGI requiere que el emisor notifique al DGI cuando opere en contingencia y que los documentos emitidos durante ese período sean transmitidos dentro del plazo establecido una vez restablecido el sistema. Este plazo no está precisado en todos los escenarios; la práctica recomendada por los PAC es transmitir dentro de las primeras 24 horas del restablecimiento. El emisor debe mantener un registro de todos los documentos generados durante contingencia con su timestamp, número de secuencia y estado de transmisión para poder justificar cualquier brecha en la numeración ante una auditoría fiscal.

Responsabilidades del emisor durante un evento de contingencia

Durante un evento de contingencia, el emisor tiene tres responsabilidades fundamentales. Primera: continuar registrando todas las transacciones comerciales con los datos necesarios para generar el FEPA (Factura Electrónica de Panamá) cuando el sistema se restablezca. Segunda: notificar al PAC el inicio del evento de contingencia y documentar el timestamp. Tercera: transmitir los documentos acumulados en el orden correcto una vez restablecida la conectividad, respetando la secuencia numérica y sin generar huecos artificiales en la numeración que puedan interpretarse como documentos omitidos.

Tipos de fallo en el flujo SFEP y cómo clasificarlos

No todos los fallos en el flujo SFEP son iguales ni requieren la misma respuesta. Clasificar el tipo de fallo correctamente es el primer paso del protocolo de contingencia. Existen tres orígenes distintos de fallo, cada uno con implicaciones diferentes para el protocolo de recuperación: fallo del PAC, fallo del DGI y fallo de conectividad del propio emisor.

Fallo del PAC: cómo detectarlo y qué esperar

Un fallo del PAC se manifiesta como timeout en el endpoint de certificación o como un error 5xx del servidor del PAC al intentar firmar o transmitir el FEPA. Este tipo de fallo es el más frecuente y generalmente de menor duración, ya que los PAC tienen SLA de disponibilidad que los obliga a resolver incidencias en menos de 4 horas. La señal de diagnóstico es que el endpoint del DGI responde correctamente en paralelo mientras el endpoint del PAC devuelve error. En este caso, el ISV debe activar el protocolo de cola offline y no reintentarla hasta que el PAC confirme el restablecimiento del servicio.

Fallo del DGI: validación no disponible en el servidor fiscal

Un fallo del DGI significa que el servidor fiscal no está disponible para recibir o validar los FEPA, incluso si el PAC está operativo. Este escenario es menos frecuente pero más extenso en duración. La señal de diagnóstico es que el PAC devuelve un error específico indicando que el DGI no responde o que el certificado de validación del DGI no está disponible. Los PAC con buenas prácticas publican un panel de estado que distingue entre fallo propio y fallo del DGI. El protocolo de contingencia para fallo del DGI es idéntico al de fallo del PAC desde la perspectiva del emisor: encolar offline y transmitir al restablecer.

Fallo de conectividad del emisor: el escenario más controlable

Un fallo de conectividad del emisor ocurre cuando el sistema del ISV pierde acceso a internet o a la red interna que conecta con el PAC, pero el PAC y el DGI están operativos. Este es el escenario más controlable porque el emisor puede resolverlo con redundancia de red. Para ISVs con alta criticidad, se recomienda tener dos proveedores de internet con failover automático o una conexión de respaldo 4G/5G que active de forma automática cuando la principal falla. La cola offline sigue siendo necesaria como medida de seguridad, pero el tiempo de inactividad esperado es de minutos, no horas.

Protocolo técnico de contingencia paso a paso

El protocolo de contingencia debe estar documentado en el runbook del equipo de operaciones del ISV y debe poder ejecutarse sin acceso al sistema de facturación principal. Esto significa que los pasos deben estar disponibles offline, que los contactos del PAC deben estar actualizados y que el personal operativo debe conocer el procedimiento antes de que ocurra un incidente real.

Paso 1: Detección y clasificación del fallo

Al detectar un error en el flujo SFEP, el primer paso es clasificar el origen del fallo antes de tomar cualquier acción. El procedimiento: ejecutar un health check contra el endpoint de estado del PAC, ejecutar en paralelo un ping o consulta al endpoint público del DGI, y verificar la conectividad de red local. Con estos tres datos se puede determinar si el fallo es del PAC, del DGI o del emisor. El resultado de esta clasificación debe registrarse con timestamp como primer evento del incidente. No activar la cola offline antes de completar este paso para evitar contingencias innecesarias por fallos transitorios de menos de 60 segundos.

Paso 2: Activación de la cola offline y emisión durante contingencia

Una vez confirmado el fallo, activar la cola offline significa que el sistema de emisión deja de intentar transmitir al PAC y comienza a almacenar los documentos generados localmente con estado EN_CONTINGENCIA. Cada documento debe incluir: datos completos del FEPA, número de secuencia asignado, timestamp de generación y motivo del estado de contingencia. Los documentos deben generarse con la misma firma y estructura que se usaría para transmisión normal, de modo que al restablecer el sistema solo sea necesario transmitirlos sin regenerarlos. Notificar al PAC del inicio de la contingencia via canal alternativo (email o teléfono) para que el PAC tenga contexto al recibir los documentos acumulados.

Paso 3: Sincronización posterior al restablecimiento del servicio

Al restablecer el servicio, el proceso de sincronización debe ejecutarse de forma controlada y no en ráfaga. Transmitir todos los documentos acumulados simultáneamente puede generar un pico de carga que sature el PAC y produzca nuevos rechazos. La estrategia recomendada es transmitir en lotes ordenados por timestamp de generación, con un máximo de 50 documentos por lote y una espera de 2 segundos entre lotes. Esta velocidad es suficiente para transmitir 1.500 documentos por minuto sin saturar el endpoint del PAC. Al completar la sincronización, verificar que todos los documentos pasaron de estado EN_CONTINGENCIA a TRANSMITIDO y luego a ACEPTADO_DGI.

Implementación de la cola offline para documentos en contingencia

La cola offline es la pieza central del protocolo de contingencia. Su diseño determina cuánto tiempo puede operar el sistema sin conectividad con el PAC y cuán rápido puede recuperarse al restablecer el servicio. Una cola mal diseñada puede perder documentos, crear duplicados o transmitir en orden incorrecto, lo que produce problemas de secuencia numérica que requieren intervención manual.

Estructura mínima de la cola de contingencia

La tabla de cola de contingencia debe incluir como mínimo los siguientes campos: ID único del documento, número de FEPA asignado, XML firmado del documento (o referencia al almacenamiento de archivos), timestamp de generación, timestamp de último intento de transmisión, código de error del último intento, estado actual (EN_CONTINGENCIA, TRANSMITIDO, ACEPTADO_DGI, FALLO_DEFINITIVO) y número de intentos de transmisión. Esta estructura permite consultar el estado de cualquier documento durante y después del incidente, y sirve como evidencia de continuidad operativa ante una auditoría fiscal.

Ordenamiento y deduplicación al sincronizar documentos acumulados

Al transmitir la cola offline, el orden de envío debe ser estrictamente por timestamp de generación ascendente, nunca por orden de ingreso a la cola (que puede ser diferente si hay reintentos intercalados). Antes de iniciar la sincronización, ejecutar una consulta de deduplicación para eliminar entradas duplicadas en la cola: dos entradas con el mismo número de FEPA y el mismo contenido deben tratarse como un único documento y transmitirse una sola vez. Si existen dos entradas con el mismo FEPA pero contenido diferente, pausar la sincronización y escalar a revisión manual antes de transmitir.

Criterios técnicos para evaluar la resiliencia del PAC contratado

El protocolo de contingencia del ISV es solo una mitad de la ecuación. La otra mitad es la resiliencia del PAC elegido. No todos los PAC autorizados por la DGI tienen la misma infraestructura de contingencia, y las diferencias son operativamente significativas para ISVs con alto volumen de transacciones.

SLA, redundancia geográfica y notificaciones de degradación del PAC

Al evaluar un PAC, los criterios técnicos de resiliencia que deben verificarse son: disponibilidad garantizada contractualmente (el estándar mínimo para producción es 99.5% mensual), redundancia en al menos dos zonas de disponibilidad distintas, panel de estado público que distinga entre degradación propia y del DGI, notificaciones automáticas de incidente vía webhook o email con latencia menor a 5 minutos, y soporte técnico con tiempo de respuesta garantizado menor a 30 minutos para incidentes de prioridad alta. Para ISVs que evalúan opciones de PAC con infraestructura regional y API REST con soporte de contingencia integrado, la solución de facturación electrónica para Panamá de Alanube cubre los criterios descritos en esta sección con infraestructura multi-zona y SLA documentado.