Cómo integrar un nuevo sistema sin romper
Descubre paso a paso cómo conectar un software nuevo con tus procesos existentes, evitando fricciones y ganando eficiencia en tu empresa peruana
Foto de RDNE Stock project en Pexels
La resistencia del equipo suele aparecer cuando el nuevo sistema no “habla” con las herramientas que ya manejan día a día. En este artículo encontrarás una guía práctica para que la integración sea fluida, sin perder datos ni tiempo.
Con qué se tiene que hablar
Antes de abrir cualquier solicitud al proveedor, haz un inventario de los sistemas que tu empresa mantiene en producción. En la mayoría de las pymes peruanas, los pilares son:
- ERP contable: lleva la contabilidad y genera los asientos que la SUNAT revisa.
- CRM de ventas: registra oportunidades, contactos y seguimiento de clientes.
- Plataforma de nómina: calcula sueldos, retenciones y genera los pagos a AFP.
- Herramientas de gestión de proyectos: Trello, Asana o similares, donde los equipos planifican sus tareas.
- Sistemas de facturación electrónica: a veces son módulos internos, a veces proveedores externos.
Cada uno de estos sistemas tiene su propio modelo de datos y sus propias reglas de negocio. La clave es identificar los puntos de contacto críticos: dónde se generan los datos que el nuevo software necesitará y dónde debe devolver información. Por ejemplo, si el nuevo ERP necesita los códigos de cliente que ya están en el CRM, esa tabla debe quedar disponible mediante una API o un archivo plano que se actualice diariamente.
Señales de que la integración está mal definida
- Los usuarios siguen introduciendo datos manualmente. Indica que la información no fluye automáticamente entre sistemas.
- Los reportes mensuales se retrasan. Cuando el nuevo software no entrega la información a tiempo, el cierre contable se vuelve una pesadilla.
- Se generan duplicados de clientes o facturas. Es señal de que la lógica de sincronización no está alineada.
SUNAT y facturación electrónica
En Perú, la SUNAT exige que toda factura electrónica cumpla con el Ubl 2.1 y se envíe en tiempo real o, a más tardar, dentro de 24 horas. El nuevo sistema debe poder:
- Generar el XML con los campos obligatorios (RUC, número de documento, detalle de ítems, impuestos, etc.).
- Firmar digitalmente con el certificado de la empresa.
- Transmitir a la API de SUNAT (código de respuesta 0 = aceptado, 98 = rechazo).
- Almacenar la CDR (Constancia de Recepción) y el CDR de anulación.
Los errores más habituales son:
- Formato de fecha distinto al requerido (YYYY‑MM‑DD). Un solo día fuera de formato retrasa cientos de documentos.
- Montos redondeados con decimales diferentes a los aceptados por SUNAT, lo que genera rechazo automático.
- No validar la existencia del cliente en la tabla maestra antes de enviar la factura; la SUNAT rechaza documentos con RUC inexistente.
Para evitar fricciones, solicita al proveedor que entregue:
- Un módulo de validación previa que simule la respuesta de SUNAT antes de enviar.
- Logs detallados de cada envío, con timestamps y códigos de error.
- La posibilidad de re‑intentos automáticos en caso de caída de la conexión, con un máximo de tres intentos en 15 minutos.
Cobros y bancos
Los pagos en Perú se están diversificando: Yape, Plin, Niubiz, Izipay y la banca tradicional siguen coexistiendo. Cada canal tiene su propio flujo y sus propias APIs.
| Canal | Tipo de integración | Tiempo típico de respuesta | Comentario clave |
|---|---|---|---|
| Yape | Webhook o API REST | < 2 seg | Necesita token de cliente y firma HMAC. |
| Plin | API REST + certificado SSL | 3‑5 seg | Requiere registro previo de la empresa en la plataforma. |
| Niubiz | API SOAP + certificado | 4‑6 seg | Soporta conciliación automática de pagos y devoluciones. |
| Izipay | API REST + webhook | 2‑4 seg | Permite pagos con código QR y tarjeta sin tarjeta. |
| Banca tradicional | Archivo plano (CNAB) o API | 24‑48 h (archivo) | Los bancos mayoristas siguen usando archivos diarios. |
Cómo conectarlos de verdad
- Normaliza los estados de pago. Define una tabla única con estados como pendiente, autorizado, rechazado, reembolsado. Cada API debe mapear su código al estándar interno.
- Sincroniza en batch y en tiempo real. Para Yape y Plin, usa webhooks que actualicen la tabla de pagos en menos de 5 seg. Para Niubiz e Izipay, programa una conciliación nocturna que procese los archivos generados entre 02:00 y 04:00 h.
- Gestión de cambios de API. La mayoría de los proveedores avisan con 30 días de antelación. Implementa una capa de adapter que traduzca la versión antigua a la nueva sin tocar el núcleo del ERP.
Qué pedirle al proveedor
La claridad en los requerimientos técnicos evita sorpresas costosas. Al iniciar la negociación, incluye una sección “Integración y mantenimiento” con los siguientes ítems:
- APIs RESTful con especificación OpenAPI 3.0. Cada endpoint debe describir parámetros, tipos de datos y códigos de error.
- Documentación de webhook: formato de payload, firma, método de verificación y política de re‑intentos.
- Versionado: todas las APIs deben seguir semver (v1.0, v1.1, v2.0). Cambios mayores deben ser comunicados con al menos 60 días de antelación.
- Entorno de pruebas (sandbox) idéntico al de producción en estructura de datos, pero con datos ficticios. El sandbox debe estar disponible 24 h/7 días.
- Acuerdos de nivel de servicio (SLA) para disponibilidad de la API (mínimo 99.5 % mensual) y tiempo de respuesta (≤ 300 ms para llamadas críticas).
- Procedimiento de migración: pasos detallados, responsables y plazos. Un buen proveedor entrega un plan de 6 semanas: 2 semanas de pruebas, 2 semanas de ajustes, 2 semanas de puesta en producción.
Comparativa de enfoque de integración
Proveedor A
- Documentación básica
- Versionado sin semver
- SLA 98 %
Proveedor B
- Documentación OpenAPI 3.0 + ejemplos
- Versionado semver con aviso 60 días
- SLA 99.7 %
Conclusión
Al leer este artículo deberías llevarte tres aprendizajes claros: primero, mapear exhaustivamente los sistemas actuales y sus puntos de contacto antes de firmar cualquier contrato; segundo, garantizar que la integración con SUNAT y con los canales de cobro cumpla con los requisitos técnicos y de tiempo real que la normativa peruana exige; y tercero, exigir al proveedor entregas concretas –APIs versionadas, sandbox activo y SLA robusto– para que cualquier cambio futuro no vuelva a ser una fuente de resistencia interna.
Una integración bien planeada reduce la fricción del equipo en un 40 % y acelera la adopción del nuevo sistema en menos de 8 semanas.
