Qué hacer cuando se cae el sistema y conectarlo

Cuando el sistema de tu empresa se cae, la primera preocupación no es solo volver a encenderlo, sino cómo volver a conectar todo lo que ya funciona sin generar nuevos errores. En este artículo verás los puntos críticos que debes revisar para que, una vez restablecido el servicio, la integración con tus procesos existentes sea fluida y segura.

Con qué se tiene que hablar

Antes de mover cualquier dato o cambiar de proveedor, identifica los sistemas que ya forman parte del ecosistema de tu empresa y que permanecerán en operación:

• ERP o contabilidad: normalmente integrado con la facturación electrónica y los reportes financieros.
• CRM: gestiona la relación con clientes y suele estar conectado a campañas de marketing.
• Plataformas de e‑commerce: si vendes online, el carrito y el motor de pagos ya están enlazados.
• Sistemas de recursos humanos: nómina, control de asistencia y beneficios.
• Herramientas de BI: tableros que extraen datos en tiempo real.

Cada uno de estos módulos tiene puntos de integración (APIs, webhooks o conexiones de base de datos) que no deben romperse al cambiar el hosting. El primer paso es crear un inventario detallado de:

1. Tipo de conexión (REST, SOAP, ODBC, etc.).
2. Frecuencia de intercambio (en tiempo real, batch nocturno, etc.).
3. Credenciales y certificados usados actualmente.
4. Dependencias críticas (por ejemplo, el ERP necesita que la tabla de clientes esté disponible antes de generar la factura).

Con esta información podrás validar que el nuevo entorno (ya sea nube pública, privado o un servidor dedicado) soporta los mismos protocolos y latencias. En la práctica, si tu ERP requiere menos de 200 ms de respuesta para validar una factura, el nuevo hosting debe ofrecer una conectividad que garantice ese tiempo.

SUNAT y facturación electrónica

En Perú, la SUNAT exige que la facturación electrónica sea enviada en tiempo real y que el archivo XML cumpla con su esquema de validación. Cuando el sistema se cae, el riesgo principal es la pérdida o retraso de los comprobantes.

Requisitos esenciales

• Certificado digital vigente: debe estar disponible en el nuevo hosting y configurado en el mismo nivel de seguridad (TLS 1.2 mínimo).
• Endpoint de SUNAT: la URL de envío no cambia, pero la IP del cliente sí; asegúrate de que la nueva infraestructura tenga acceso a los puertos 443 y 80 sin firewalls intermedios.
• Cronograma de envío: si tu proceso de envío corre cada 5 min, el nuevo servidor debe ejecutar la tarea con la misma periodicidad.

Errores típicos al reconectar

• Caducidad del token: al migrar, el token de autenticación puede quedar desactualizado; programa una renovación automática antes de la primera transmisión.
• Desincronización de horarios: la SUNAT valida la fecha/hora del XML; configura el servidor con NTP y verifica que la zona horaria sea America/Lima.
• Cambios en el esquema: la SUNAT publica actualizaciones cada trimestre. Mantén una suscripción a su boletín y prueba los cambios en un entorno de pre‑producción antes de la migración.

Cobros y bancos

Los medios de pago locales como Yape, Plin, Niubiz e Izipay utilizan APIs específicas y, a veces, SDKs que deben estar instalados en el mismo entorno que tu ERP o plataforma de ventas.

Cómo se conectan de verdad

1. Yape y Plin: ofrecen APIs REST con autenticación OAuth 2.0. Necesitas almacenar el client_id y client_secret en un vault seguro y refrescar el token cada 24 h.
2. Niubiz: usa un modelo híbrido (REST + SOAP). La clave de cifrado RSA‑2048 debe estar en el mismo servidor que procesa la respuesta de la transacción para evitar latencias.
3. Izipay: requiere un webhook que notifique el estado de la operación. Asegúrate de que el dominio público del webhook sea accesible desde internet y que el certificado SSL sea válido.

Pasos concretos después de una caída

• Validar los logs de cada API: revisa si la caída provocó peticiones pendientes o expiradas.
• Re‑enviar transacciones fallidas: la mayoría de los proveedores tiene un endpoint de re‑process; úsalo dentro de las 48 h posteriores a la interrupción.
• Sincronizar saldos: compara los reportes de conciliación bancaria con los registros internos; cualquier diferencia mayor al 0,5 % debe investigarse antes de reabrir el sistema.

Qué pedirle al proveedor

Al seleccionar o cambiar de hosting, la negociación con el proveedor no termina en la firma del contrato. Debes exigir garantías técnicas que aseguren la continuidad de las integraciones.

APIs y documentación

• Documentación actualizada: solicita versiones PDF/HTML que incluyan ejemplos de llamadas y respuestas.
• Versionado: el proveedor debe mantener al menos dos versiones estables de sus APIs; si una cambia, tendrás 30 días para adaptar tus sistemas.
• Entorno de pruebas: un sandbox idéntico al entorno productivo donde puedas validar cambios sin riesgo.

Cambios de la otra parte

• Notificaciones anticipadas: exige que cualquier actualización de API o de infraestructura sea comunicada con al menos 15 días de antelación.
• Plan de contingencia: el proveedor debe disponer de un plan de recuperación ante desastres (DRP) que incluya pruebas trimestrales y tiempos de recuperación (RTO) no mayores a 2 h.
• Soporte de nivel 2: acceso directo a ingenieros que comprendan tu stack tecnológico (Java, .NET, PostgreSQL, etc.).

Conclusión

Quien haya leído hasta aquí lleva claro que la clave para minimizar el impacto cuando se cae el sistema está en la preparación de la integración. Inventariar los sistemas existentes, cumplir con los requisitos de SUNAT, asegurar la correcta configuración de los medios de pago y exigir cláusulas técnicas al proveedor son pasos medibles que reducen el tiempo de inactividad y evitan sorpresas después de la migración. Con estos lineamientos, tu empresa podrá restablecer la operación rápidamente y mantener la confianza de clientes y reguladores.