Guía
Integra tu ERP con la tienda, el CRM o la pasarela de pagos sin duplicar datos
Antes de conectar un ERP, una tienda, un CRM o una pasarela hace falta escribir tres reglas: cuál sistema manda en cada dato, qué pasa si uno no responde, y cómo evitar cargar la misma operación dos veces.
Revisado el por Grupo Anta.
Quién manda
Un dato tiene un solo dueño, aunque viva en dos sistemas
Cuando el ERP y la tienda —o el CRM, o la pasarela— no coinciden en el mismo dato, uno de los dos tiene que ganar antes de que la diferencia se copie al otro. Esa regla se escribe por dato, no por sistema completo. Este es un reparto típico; en tu caso puede cambiar, y se decide contigo.
| Dato | Quién manda | Por qué |
|---|---|---|
| Stock y precio de venta | El ERP | Es donde se registran la compra y el costo; la tienda muestra lo que el ERP dice. |
| Datos del cliente (contacto, dirección) | El CRM si existe; si no, el ERP | El CRM es donde el equipo comercial corrige el dato; sin CRM, el ERP es la única fuente y evita que dos sistemas discrepen sobre el mismo cliente. |
| Si un pago se hizo o se rechazó | La pasarela (Culqi, Izipay) | Es quien de verdad cobró o rechazó; el ERP y la tienda solo reflejan lo que la pasarela confirma. |
| El comprobante ya emitido | El emisor de comprobantes ante SUNAT | Un comprobante que SUNAT o el OSE rechazó no es válido, aunque el ERP ya lo haya generado. |
Esta misma regla es la que se escribe antes de conectar Odoo con una tienda en línea: ver la demostración.
Lote o evento
Lo que el cliente espera ver al instante se sincroniza por evento, y lo demás por lotes
Sincronizar en tiempo real cuesta más de construir y de mantener que revisar los cambios cada cierto tiempo, así que el tiempo real se reserva para lo que de verdad lo necesita.
Por lotes
Un proceso corre cada cierto tiempo —cada noche, cada hora— y sincroniza lo que cambió desde la corrida anterior.
- El volumen es bajo o no es urgente: precios de catálogo, un reporte contable.
- Uno de los dos sistemas no tiene forma de avisar al otro cuando algo cambia.
- Tolera que el dato esté desactualizado entre una corrida y la siguiente.
Por evento
Cada sistema avisa al otro apenas pasa algo, normalmente con un webhook, y el otro reacciona en segundos.
- El cliente espera una confirmación inmediata: un pago aprobado, un pedido con stock.
- Un retraso de minutos ya es un problema, no un detalle.
- Exige que el sistema que recibe esté disponible, o que haya una cola de reintento.
Si uno no responde
Un reintento no duplica si cada operación lleva una clave que no se puede cargar dos veces
Sincronizar por evento significa que el otro sistema puede estar caído justo cuando algo pasa. Lo que evita perder o repetir esa operación es una cola de reintento y una clave que la identifica.
- Regla del negocio Si el sistema de destino no responde, la operación queda en una cola y se reintenta más tarde: no se pierde por una caída de segundos o minutos.
- Cómo se comprueba Cortar la conexión al enviar un pedido y restablecerla poco después: el pedido llega cuando la conexión vuelve, sin que nadie lo reenvíe.
- Regla del negocio Cada operación lleva una clave de idempotencia: un identificador que marca esa operación como única. Si la misma operación llega dos veces con la misma clave, el sistema que recibe descarta la segunda.
- Cómo se comprueba Enviar dos veces el mismo pedido, como pasa cuando un corte deja la duda de si llegó: el sistema de destino crea un solo registro.
- Regla del negocio La cola tiene un límite de reintentos. Superado ese límite, la operación queda a la vista de una persona con el motivo, en vez de reintentar sin fin.
- Cómo se comprueba Simular una caída larga del sistema de destino: tras el último reintento, alguien recibe la operación pendiente y por qué no se pudo completar.
Escenario ilustrativo con datos ficticios.
Sin API
Sin API, el archivo de importación sigue siendo una integración, solo que por lotes
Un sistema contable que no expone una API todavía se puede sincronizar: exporta un archivo, un proceso lo revisa, y el destino lo importa ya comprobado.
- El ERP exporta el archivo (Excel o texto)
- Un proceso revisa y prepara los datos
- El sistema destino lo importa ya comprobado
Concar, por ejemplo, se integra solo entre sus propios módulos. Para conectarlo con otro sistema, la vía es el archivo que sí exporta e importa. Confirmado en realsystems.com.pe.
Cuándo no conviene
Si el conector ya existe, contratar un desarrollo es pagar dos veces por lo mismo
Antes de escribir una línea de código conviene revisar si el conector ya viene con el producto, o si una herramienta sin código alcanza para el flujo que necesitas.
| Tu situación | Con qué se resuelve | ¿Hace falta un desarrollo? |
|---|---|---|
| Los dos sistemas ya tienen un conector oficial entre ellos | El conector que trae el propio producto: por ejemplo, el de tu ERP hacia Culqi o Izipay. | No |
| Conectar apps con flujos simples: una planilla, un correo, un CRM genérico | Una herramienta sin código como Zapier, Make, Power Automate o n8n. | A veces |
| Uno de los extremos es SUNAT o la emisión de comprobantes | Un OSE (Nubefact, Efact u otro): ninguna herramienta sin código trae ese conector de fábrica. | Sí, junto con un OSE |
| Hay que decidir quién manda, evitar un duplicado o conectar un sistema sin conector ni API | Un desarrollo a medida, con esas reglas escritas antes de programar. | Sí |
Antes de firmar
Antes de firmar, pide ver cómo se comprueba que la integración no pierde ni duplica
Las mismas preguntas que se le hacen a cualquier proveedor de desarrollo aplican aquí, con dos propias de una integración: quién escribe la regla de conflicto, y cómo se prueba que no pierde ni duplica.
¿Qué tiene que mostrarte antes de firmar?
Una integración funcionando, aunque sea con datos de prueba, y la comprobación de cada regla. Una propuesta sola no te deja ver cómo decide cuando dos sistemas no coinciden.
¿Quién escribe la regla de cuál sistema manda?
Se define y se revisa contigo antes de programar nada. Si el proveedor la decide solo y la entrega ya hecha, no hay forma de comprobar que resuelve tu caso.
¿Qué te llevas si el proyecto termina?
El código de la integración y su documentación, no solo el acceso a un panel que el proveedor sigue operando.
¿Cómo se prueba que no pierde ni duplica antes de pasar a producción?
Con el mismo tipo de corte de conexión y reenvío descritos arriba, contra un ambiente de prueba, antes de que toque datos reales.
Lo siguiente depende de qué lado de la integración es tu problema hoy
- ¿Cómo leer facturas y documentos automáticamente?
Si lo que sincronizas entre sistemas son facturas o guías, la lectura y la comprobación antes de cargarlas viven aquí. Guía
- ¿Cómo paso los XML de mis comprobantes electrónicos a Excel?
Si tus comprobantes ya son electrónicos, pasa los XML a una tabla antes de decidir qué automatizar. Herramienta gratuita
- ¿Mi proceso necesita software, una automatización o IA?
Antes de mandar a construir, comprueba si tu caso es software, una automatización o si ya alcanza con lo que tienes. Herramienta gratuita
- ¿Qué parte de mi proceso puedo dejar de hacer a mano?
Si lo que hoy se hace a mano es un proceso completo, no solo un dato entre dos sistemas. Lo que construimos
¿Qué dos sistemas necesitas conectar, y qué pasa hoy cuando no coinciden?
Cuéntanos qué sistemas usas y cómo los concilias hoy. Te decimos qué regla falta escribir y si de verdad hace falta un desarrollo.