Conecta tus sistemas actuales sin cambiar nada

En tu día a día, la falta de comunicación entre los sistemas que ya tienes genera retrabajo, errores y demoras que impactan directamente en la rentabilidad. En este artículo encontrarás una guía práctica para conectar esos sistemas sin sustituirlos, cumpliendo con la normativa peruana y garantizando continuidad operativa.

Con qué se tiene que hablar

Antes de pensar en cualquier herramienta o proyecto, es fundamental hacer un inventario detallado de los sistemas que ya están en producción:

• ERP o contabilidad (por ejemplo, SAP Business One, Contasis, o un software a medida).
• CRM o gestión de ventas (Zoho, HubSpot, o una hoja de cálculo compartida).
• Plataformas de e‑commerce (Tiendanube, Shopify, Magento).
• Sistemas de gestión de almacenes (WMS propio o módulos de ERP).
• Herramientas de comunicación (WhatsApp Business, correo corporativo, Slack).
• Bancos y pasarelas de pago (Niubiz, Izipay, Yape, Plin).

Estos sistemas no se van a tirar; la meta es que “hablen” entre sí. El primer paso es mapear los puntos de intercambio de datos: facturas, órdenes de compra, pagos, stock y clientes. Cada punto se convierte en un evento que debe ser capturado y reenviado a los demás sistemas.

SUNAT y facturación electrónica

En Perú, la normativa de la SUNAT obliga a que toda factura electrónica sea emitida y validada en tiempo real. Los requisitos clave son:

1. Certificado Digital activo y vigente.
2. API de la SUNAT (REST) para envío de documentos y consulta de estados.
3. Formato XML conforme al catálogo de la SUNAT (Ubl 2.1).
4. Respuesta de aceptación o rechazo en menos de 30 segundos.

Los errores más comunes son:

• Cadena de caracteres incorrecta por cambios de versión del XML.
• Timeout cuando el ERP envía lotes sin controlar la concurrencia.
• Desincronización entre el número de serie interno y el número autorizado por SUNAT.

Cómo evitarlo:

• Implementar un middleware que valide el XML antes de enviarlo y que registre la respuesta de la SUNAT en una tabla de auditoría.
• Programar una re‑intento automático con back‑off exponencial: primer intento inmediato, segundo a los 5 seg, tercer intento a los 15 seg, y abortar después de tres fallos.
• Establecer una ventana de conciliación semanal (2‑3 horas) para revisar los documentos rechazados y corregirlos.

En la práctica, conectar tu ERP con la API de SUNAT suele requerir 2‑3 semanas de desarrollo y pruebas, siempre que la documentación del ERP esté disponible y el equipo de SUNAT no cambie sus endpoints.

Cobros y bancos

Los pagos digitales en Perú se concentran en cuatro canales principales:

• Yape (transferencias entre cuentas móviles).
• Plin (similar a Yape, operado por Interbank).
• Niubiz (pasarela tradicional de tarjetas).
• Izipay (integración con billeteras y QR).

Cómo se conectan de verdad

1. API pública vs. API privada: Yape y Plin ofrecen API REST limitadas a socios aprobados; Niubiz e Izipay disponen de SDKs y endpoints de SOAP y REST.
2. Webhook de confirmación: la mayoría envía una notificación HTTP POST cuando el pago se confirma. Es esencial exponer un endpoint seguro (HTTPS, certificado TLS 1.2) que reciba el payload y lo inserte en tu base de datos de cobros.
3. Validación de firma: los payloads incluyen una firma HMAC; verifica la integridad antes de aceptar el pago.
4. Reconcilación: genera un batch de conciliación cada 24 h que compare los registros internos con los reportes del banco. Un desfase mayor al 2 % debe disparar una alerta automática.

Plazos típicos

• Integración con Yape/Plin: 1‑2 semanas (registro de cliente corporativo y pruebas sandbox).
• Niubiz: 2‑3 semanas (incluye pruebas de 3DS y certificación de producción).
• Izipay: 2‑4 semanas (dependiendo de la complejidad del flujo QR).

Errores frecuentes y cómo mitigarlos

• Duplicidad de notificaciones: algunos bancos re‑envían el webhook si no reciben 200 OK. Implementa idempotencia usando el transaction_id.
• Desfase de zona horaria: los timestamps vienen en UTC; conviértelos a la zona horaria local (America/Lima) antes de guardarlos.
• Límites de tasa: Yape permite 100 req/min; si superas el límite, el API responde 429. Usa un rate limiter interno.

Qué pedirle al proveedor

El éxito de la integración depende de la información que obtengas del proveedor del sistema origen o destino.

API y documentación

• Especificación OpenAPI/Swagger o WSDL actualizado.
• Ejemplos de request/response en formato JSON o XML.
• Límites de tasa y política de versionado (¿se mantiene la v1 por al menos 12 meses?).

Contratos de servicio (SLA)

• Tiempo máximo de respuesta (p.ej., <200 ms para consultas de stock).
• Disponibilidad mínima (99.5 % mensual).
• Soporte para cambios de esquema: notificación mínima 30 días antes de una ruptura.

Cuando la otra parte cambia

1. Versionado semántico: la nueva versión debe ser compatible (cambio menor) o, si es mayor, el proveedor debe ofrecer endpoint paralelo durante al menos 60 días.
2. Pruebas de regresión: mantén un suite de pruebas automatizadas que valide los contratos críticos (factura, pago, stock).
3. Plan de migración: agenda una ventana de 2‑4 horas para actualizar tu middleware, con rollback preparado.

Conclusión

Al mapear tus sistemas existentes, cumplir con los requisitos de SUNAT, conectar los canales de cobro locales y exigir documentación y SLA claros a los proveedores, puedes lograr una integración robusta en 6‑10 semanas sin sustituir ninguna herramienta. El esfuerzo se concentra en la capa intermedia (middleware), que actúa como traductor y garante de consistencia, reduciendo el tiempo de operación manual en un 30‑45 % y evitando errores costosos de duplicidad o desincronización.

Una integración bien planificada permite que tus sistemas actuales trabajen como una sola plataforma, sin necesidad de reemplazarlos.