Integración Zoho CRM y ERP: Navision, SAP, Oracle

Hay una escena que se repite en casi todos estos proyectos. El comercial cierra una venta en Zoho, se levanta, va a administración y dicta los datos del cliente para que alguien los teclee otra vez en el ERP. A veces con un Excel de por medio. Y cuando alguien pregunta cuánto se ha vendido este mes, salen dos cifras distintas según a quién le preguntes.

Integrar Zoho CRM con el ERP arregla eso, pero no por donde la gente cree. El problema casi nunca es técnico: las APIs existen y funcionan. El problema es que nadie ha decidido quién manda sobre cada dato. Sin esa decisión, conectar los dos sistemas solo consigue que se pisen más rápido.

Lo que de verdad decide el proyecto: quién es el maestro

Antes de mirar una sola línea de documentación, hay que responder una pregunta por cada entidad compartida: si este dato cambia en los dos sitios a la vez, ¿cuál gana?

En la mayoría de proyectos que montamos, el maestro del cliente es el ERP. Es donde viven la contabilidad, el CIF validado, el riesgo asignado y las condiciones de pago. Eso no significa que el comercial no pueda crear nada: Zoho crea el prospecto con total libertad, porque un lead todavía no es un cliente. Pero en el momento en que la oportunidad se gana, el alta contable la hace el ERP, que devuelve el código de cliente a Zoho.

Ese código es la pieza clave de toda la integración. A partir de ahí, los dos sistemas hablan del mismo cliente sin ambigüedad, y cualquier sincronización posterior tiene una referencia sólida en lugar de intentar emparejar por nombre o por email. En Zoho lo guardamos en un campo propio indexado; sin él, cada sincronización se convierte en un ejercicio de adivinación.

Si dejas que ambos sistemas den de alta clientes con criterios distintos, en seis meses tienes dos maestros y ninguna verdad. Es el fallo más caro de revertir, porque para entonces ya hay histórico contable colgando de los registros equivocados.

Qué se sincroniza en cada dirección

El reparto que funciona casi siempre es asimétrico, y conviene escribirlo antes de programar nada.

Del ERP hacia Zoho viaja lo que el comercial necesita saber pero no debe tocar: el catálogo de productos, las tarifas y descuentos aplicables, y el estado financiero del cliente. Este último es el que más se agradece y el que casi nadie pide al principio: que la ficha muestre saldo pendiente, riesgo consumido y facturas vencidas evita que un comercial dedique tres semanas a una venta que administración va a bloquear el día de la entrega.

De Zoho hacia el ERP viaja poco pero crítico: la oportunidad ganada convertida en pedido, con sus líneas, su cliente y sus condiciones. Poco volumen, mucha responsabilidad.

Fíjate en que casi nada necesita ir en las dos direcciones. La sincronización bidireccional multiplica los casos límite —conflictos de escritura, bucles de actualización, relojes desincronizados— y en la práctica se necesita mucho menos de lo que se pide. La montamos cuando el negocio la justifica, no por defecto.

Dónde se rompe en la práctica

Navision on-premise y Business Central en la nube

Es la distinción que más proyectos descoloca, porque la gente dice “Navision” para las dos cosas y son mundos distintos.

Con Dynamics NAV on-premise trabajas contra web services SOAP u OData que se publican desde el propio servidor de NAV. Técnicamente es sencillo; el trabajo real es de infraestructura. Ese servidor vive dentro de la red corporativa y Zoho está en internet, así que lo primero que hay que resolver —normalmente con el equipo de sistemas del cliente, no con el de aplicaciones— es cómo se expone ese endpoint hacia fuera sin abrir un agujero: VPN, proxy inverso, una capa intermedia propia. Añade la autenticación Windows, que no es lo que espera un cliente HTTP moderno, y ya tienes las dos primeras semanas ocupadas.

Con Business Central en la nube ese problema desaparece: hay una API REST moderna, autenticación OAuth2 contra Microsoft Entra ID y todo es accesible desde internet. El problema se desplaza a otro sitio: los límites de llamadas y la gestión de tokens. Es mejor punto de partida, sin duda, pero no es “gratis”.

Lo importante es que las decisiones de arquitectura son idénticas en ambos casos. Quién es maestro, qué se sincroniza, con qué frecuencia, qué pasa si falla. Lo único que cambia es el transporte. Si alguien te plantea el proyecto al revés —empezando por la API y dejando el modelo para después— es señal de que va a haber sorpresas.

SAP: Business One y S/4HANA no se parecen

Mismo patrón, mismo malentendido. “Integrar con SAP” no significa nada hasta que sabes con cuál.

SAP Business One, el producto para pymes, expone su Service Layer basado en OData, que es con lo que trabajamos hoy. Todavía te puedes encontrar instalaciones apoyadas en la antigua DI API, que es una librería para Windows y condiciona bastante dónde puede correr tu integración.

S/4HANA publica servicios OData a través de su gateway, y ahí el trabajo suele ser tanto de negociación como de código: conseguir que el equipo de SAP del cliente active y exponga los servicios que necesitas rara vez es inmediato. En instalaciones ECC más antiguas la vía sigue siendo RFC o BAPI, y ahí casi siempre acabas metiendo una capa intermedia.

En SAP, más que en ningún otro, el calendario del proyecto depende de un tercero. Lo decimos desde la primera reunión.

Oracle: primero averigua cuál

“Oracle” abarca NetSuite, E-Business Suite y Fusion Cloud ERP, y no tienen nada que ver entre sí. NetSuite tiene su propia API REST y SuiteTalk; Fusion Cloud expone servicios REST; E-Business Suite, según la versión, te deja con integraciones bastante más artesanales.

La primera tarea ante un “queremos conectar Zoho con Oracle” es concretar de qué producto y qué versión hablamos. Suena obvio y es donde se pierden las primeras semanas cuando nadie lo pregunta a tiempo.

La carga inicial es donde se rompe todo

Las sincronizaciones del día a día son de bajo volumen y casi nunca dan problemas. Lo que revienta es la primera carga: veinte mil clientes, cincuenta mil artículos y el histórico de pedidos, todo de golpe.

Dos cosas que hacemos siempre. La primera, tratar la carga inicial como un proceso distinto del incremental, con su propio ritmo y sus lotes, en vez de reutilizar el flujo normal y agotar el crédito diario de la API de Zoho en la primera hora. La segunda, no migrar histórico por defecto. Casi nadie necesita en el CRM los pedidos de hace ocho años; necesita los del último ejercicio y un enlace para consultar el resto en el ERP. Cada registro que no migras es un registro que no tienes que limpiar, deduplicar ni mantener sincronizado para siempre.

Cómo lo abordamos

Empezamos por una tabla, no por la API. Una fila por entidad compartida —cliente, producto, tarifa, pedido, factura— y tres columnas: quién es el maestro, en qué dirección viaja, con qué frecuencia. Esa tabla se acuerda con el cliente antes de escribir código. Es la parte menos vistosa del proyecto y la que decide si funciona el segundo año.

Todo apoyado en identificadores externos. El código de cliente del ERP guardado en Zoho, y el ID de Zoho guardado en el ERP cuando se puede. Con eso, cualquier operación se puede repetir sin duplicar nada: si un proceso se corta a medias y lo relanzas, actualiza en lugar de crear. Una integración que no se puede relanzar con seguridad es una integración que nadie se atreve a tocar.

Ritmos separados según el dato. Un pedido ganado se escribe al instante. El catálogo se sincroniza por lotes de madrugada y solo lo que ha cambiado. Meter ambas cosas en el mismo proceso es la forma más rápida de tumbar la sincronización un martes por la mañana.

Un proceso de reconciliación nocturno. Por muy bien diseñado que esté, un flujo continuo acumula deriva: un evento perdido, una escritura que falló y nadie reintentó. Un job que cada noche compara los dos sistemas y reporta las diferencias detecta el problema antes que el cliente. Es barato de montar y es lo que separa una integración en la que se confía de una que se revisa a mano cada semana.

Errores que nunca fallan en silencio. Reintentos con espera progresiva, colas para no perder eventos si un sistema está caído, y una alerta a una persona concreta cuando algo se atasca. Sin esto, el primer aviso de que la integración lleva rota diez días te lo da el cliente.

Errores que conviene evitar

• Conectar antes de decidir el maestro. Sin esa regla escrita, los dos sistemas se sobrescriben y en tres meses nadie se fía de ningún dato.
• Emparejar clientes por nombre o email. “Construcciones García S.L.” y “CONSTRUCCIONES GARCIA SL” son la misma empresa y no coinciden. El emparejamiento va por código, siempre.
• Integrar sin limpiar antes. Si arrastras duplicados y campos basura, la integración solo los propaga más rápido y hacia un sistema contable.
• Montar todo bidireccional “por si acaso”. Multiplica los casos límite a cambio de una flexibilidad que casi nunca se usa.
• Migrar todo el histórico. Infla el proyecto, agota los límites de la API y llena el CRM de datos que nadie va a mirar.
• Reutilizar el flujo incremental para la carga inicial. Es el clásico que deja la sincronización caída el primer día, justo delante de todo el mundo.
• No validar el CIF en el origen. Un identificador fiscal mal capturado en el CRM se convierte en un problema con Hacienda semanas después, cuando ya ha generado facturas.

Cierre

En LMNHUB tratamos la integración entre Zoho CRM y el ERP como lo que es: un proyecto de ingeniería sobre los datos que sostienen tu contabilidad. Acordamos los maestros antes de tocar código, montamos la sincronización con identificadores externos y reconciliación nocturna, y dejamos documentado qué hace cada flujo para que no dependas de nadie.

Si quieres el panorama completo de todas las conexiones de Zoho, lo tratamos en nuestra guía de integración de Zoho CRM.

Y si estás valorando conectar Zoho con Navision, Business Central, SAP u Oracle, cuéntanos tu caso y te respondemos con un enfoque concreto y un equipo senior, no con un presupuesto genérico.