En una integración entre ERP y CRM, cada dato tiene un único sistema que manda. El ERP es dueño de lo fiscal y financiero: datos fiscales del cliente, productos, precios, pedidos confirmados, facturas y cobros. El CRM es dueño de la relación comercial: contactos, oportunidades y actividad. Cada campo viaja en una sola dirección, con IDs externos, eventos idempotentes y reintentos. Así lo planteamos en cada proyecto de integración de ERP y CRM en Madrid.
Sin esa regla, los dos sistemas acaban discutiendo. Un comercial corrige la dirección de facturación en el CRM, el ERP la sobrescribe por la noche con la antigua y la factura sale mal; o el mismo cliente aparece dos veces porque cada sistema lo dio de alta por su cuenta. Es lo que solemos encontrar cuando revisamos integraciones montadas con conectores low-code sin control de errores.
Al terminar tendrás un reparto de propiedad por entidad y sabrás cuándo sincronizar por eventos o por lotes y cómo evitar duplicados y conflictos. Si lo que necesitas es conectar una app de comerciales a esos sistemas, tienes la arquitectura para integrar una app móvil con ERP y CRM; y si aún no has elegido CRM, empieza por cuándo un CRM a medida aporta más que uno comercial.
Qué es una integración ERP y CRM
Una integración entre ERP y CRM es el conjunto de conexiones que mantiene coherentes los datos que ambos sistemas comparten, como clientes, productos, precios, pedidos y facturas. Define qué datos viajan, en qué dirección, cuándo y qué ocurre si una copia falla, para que ventas y administración trabajen con la misma ficha de cada cliente.
Es distinta de una migración, que traslada los datos una vez y apaga el sistema antiguo: aquí los dos sistemas siguen vivos y la sincronización no termina. El mapeo de campos sí se parece, y la carga inicial conviene hacerla con un plan de migración y conciliación de la carga inicial.
Quién manda: el dueño de cada dato
La decisión más importante de la integración es de negocio. Para cada entidad, y a veces para cada campo, se decide qué sistema es la fuente de verdad: el único donde ese dato se crea y se modifica. El otro lo recibe en solo lectura. Este reparto se cierra con administración y con ventas, idealmente durante el mapeo de procesos de la empresa en Madrid previo al desarrollo:
- Cliente, datos fiscales: NIF, razón social, dirección de facturación, condiciones de pago y límite de crédito. Manda el ERP, porque de ellos dependen las facturas y el riesgo.
- Cliente, datos comerciales: contactos, teléfonos, comercial asignado y segmento. Manda el CRM.
- Producto: referencia, descripción, impuestos y unidad de venta. Manda el ERP; el CRM los consulta para preparar ofertas.
- Precio y tarifa: manda el ERP. El CRM puede aplicar descuentos dentro de los márgenes que el ERP define, y cada oferta guarda el precio que tenía al enviarse.
- Oportunidad y oferta: manda el CRM hasta que el cliente acepta.
- Pedido: nace en el CRM al ganar la oportunidad, y desde que el ERP lo confirma es suyo: stock, entregas y estados se actualizan allí y el CRM los refleja.
- Factura y cobro: siempre el ERP. El CRM muestra el estado para que el comercial sepa si un cliente tiene deuda antes de venderle más.
La factura es el caso más claro. El reglamento aprobado por el Real Decreto 1007/2023 exige que los sistemas de facturación garanticen la integridad e inalterabilidad de los registros de facturación y su trazabilidad mediante encadenamiento. Por eso la factura se emite en un único sistema preparado para ello y el resto solo la consulta, igual que el portal donde tu cliente descarga sus facturas.
Qué sincronizar y qué dejar fuera
Sincroniza solo lo que el otro sistema usa. El CRM necesita los datos fiscales del cliente para no crear duplicados, el estado de pedidos y facturas para el seguimiento comercial y, como mucho, el saldo pendiente. No necesita los asientos contables ni cada movimiento de almacén. Cada campo de más es un punto de fallo y, si es un dato personal, una copia más que proteger, con los mismos controles de acceso que exige un área privada de clientes.
Eventos o lotes: cuándo sincronizar
Hay dos formas de mover los datos. Por eventos, el sistema de origen avisa con un webhook cada vez que algo cambia y el destino se actualiza en segundos. Por lotes, un proceso programado consulta los cambios desde la última ejecución, por ejemplo cada quince minutos o cada noche. Lo primero da inmediatez; lo segundo es más sencillo y tolera mejor que un sistema esté caído un rato. El volumen que aguantas depende de las colas y de la concurrencia en el backend.
En la práctica se combinan. Lo que afecta a una venta en curso, como un pedido confirmado o un cliente bloqueado por impago, va por evento. Catálogos y tarifas pueden ir por lotes. Y conviene mantener una conciliación nocturna que compare ambos lados y recupere lo que se haya perdido, porque un evento puede perderse. Si el ERP es comercial, revisa qué eventos ofrece antes de diseñar; si es propio, se definen junto a los módulos de un ERP desarrollado a medida.
IDs externos: cómo no duplicar clientes
Cada registro sincronizado guarda el identificador que tiene en el otro sistema. El cliente del CRM lleva el código del ERP y viceversa, así que la integración busca por ese ID antes de crear nada y actualiza si ya existe. Microsoft lo resuelve en Dataverse con claves alternativas, que identifican un registro por el identificador del sistema externo cuando no se puede guardar el propio en el otro lado. En la primera carga, el emparejamiento se hace por NIF normalizado y una persona revisa los casos dudosos.
Idempotencia, errores y reintentos
Los emisores de webhooks reintentan cuando no reciben respuesta, así que el mismo evento puede llegar dos veces. Stripe, en su guía para recibir eventos por webhook, reintenta durante hasta tres días en modo real, advierte de que no garantiza el orden de los eventos y recomienda registrar los ID ya procesados para descartar duplicados. Es el comportamiento que debes asumir de cualquier emisor.
Por eso el receptor tiene que ser idempotente: procesar un evento dos veces debe dejar los datos igual que procesarlo una vez, la misma propiedad que la RFC 9110 define para los métodos HTTP idempotentes. En la práctica significa guardar el ID de cada evento con un índice único, responder rápido y procesar en una cola. Y no fiarse del orden: si llega la actualización de un pedido que aún no existe, se reencola o se consulta al origen.
Lo que no se resuelve con reintentos va a una cola de revisión con el motivo del error, visible en el panel de administración donde se revisan las incidencias, con un aviso cuando se acumulan.
Conflictos: cuando los dos sistemas cambian el mismo dato
Con dueños por campo, la mayoría de conflictos desaparecen: si el CRM intenta cambiar el NIF, la integración rechaza ese campo y lo registra. Quedan los datos que el negocio necesita editar en ambos lados, como una dirección de entrega. Para ellos hay dos opciones razonables: que gane la última modificación según una marca de tiempo fiable del origen, o enviar el cambio al sistema dueño como solicitud que alguien aprueba. La primera falla en silencio si los relojes no son fiables, un problema conocido en la sincronización offline-first con caché.
CodeZone Pro Tip: haz que cada webhook sea idempotente y que solo escriba los campos de los que su sistema es dueño
// Aplica un cambio recibido por webhook respetando quién manda en cada campo
type Sistema = "erp" | "crm";
interface Evento { id: string; origen: Sistema; clienteId: string; campos: Record<string, unknown> }
// Dueño de cada campo del cliente: solo su sistema puede modificarlo
const DUENO: Record<string, Sistema> = {
nif: "erp", razonSocial: "erp", condicionesPago: "erp", limiteCredito: "erp",
telefono: "crm", email: "crm", comercialAsignado: "crm", segmento: "crm",
};
const procesados = new Set<string>(); // en producción: tabla con índice único
const clientes = new Map<string, Record<string, unknown>>();
export function aplicar(ev: Evento): string {
if (procesados.has(ev.id)) return `${ev.id}: duplicado, ignorado`; // reintento del emisor
const actual = clientes.get(ev.clienteId) ?? {};
const rechazados: string[] = [];
for (const [campo, valor] of Object.entries(ev.campos)) {
if (DUENO[campo] === ev.origen) actual[campo] = valor; // el dueño escribe
else rechazados.push(campo); // el resto se registra para revisar
}
clientes.set(ev.clienteId, actual);
procesados.add(ev.id); // marcar solo cuando se ha aplicado
return `${ev.id}: aplicado` + (rechazados.length ? `, rechazados [${rechazados}]` : "");
}
// Prueba con eventos hipotéticos: el segundo llega dos veces y el CRM intenta tocar el NIF
const e1: Evento = { id: "ev-1", origen: "erp", clienteId: "C-7", campos: { nif: "B12345678", condicionesPago: "60 días" } };
const e2: Evento = { id: "ev-2", origen: "crm", clienteId: "C-7", campos: { email: "compras@cliente.es", nif: "B00000000" } };
[e1, e2, e2].forEach((e) => console.log(aplicar(e)));
console.log(clientes.get("C-7"));El manejador descarta los eventos ya procesados, aplica solo los campos que pertenecen al sistema que envía el cambio y devuelve los rechazados para revisarlos. En la prueba, el segundo evento llega dos veces y el CRM intenta cambiar el NIF: el email se actualiza, el NIF se queda como dice el ERP y el duplicado se ignora. En producción, el registro de eventos procesados es una tabla con índice único que se escribe en la misma transacción que los datos, algo que deberías exigir a cualquier empresa de software que integre tu ERP en Madrid.
Si uno de los sistemas es comercial
Con un ERP o un CRM comercial, sus límites marcan el diseño: qué eventos emite, cuántas llamadas por minuto admite su API y si permite campos personalizados para guardar el ID externo. Antes de presupuestar, pide esa documentación y prueba la API con datos reales. Si los límites se quedan cortos, valora una capa intermedia propia, como en las integraciones de Shopify con APIs y middleware, dentro de un proyecto de desarrollo de software con integraciones ERP en Madrid.
El Precio de Dos Sistemas que No Se Ponen de Acuerdo
Una integración sin dueños claros produce facturas con datos viejos, comerciales que venden a clientes bloqueados y horas de administración cuadrando listados. Si estás decidiendo qué automatizar en los procesos administrativos de tu empresa en Madrid, la sincronización entre ERP y CRM merece una buena puntuación, porque toca ventas y facturación a la vez.
En Codezone diseñamos integraciones entre ERP, CRM y el resto de tus sistemas con el reparto de propiedad como primer entregable, y damos soporte y mantenimiento de integraciones en Madrid cuando están en producción. Cuéntanos qué sistemas usas y qué datos se te desincronizan y te proponemos el diseño.
