Integración entre ERP y ecommerce: cómo evitar diferencias de inventario, pedidos duplicados y tareas manuales

Un proyecto de integración entre un ERP y una tienda online suele resumirse como un conector bidireccional: productos e inventario van hacia el canal de venta y los pedidos regresan al sistema de gestión. Esa descripción oculta las decisiones que determinan si la operación será confiable o si dependerá de correcciones manuales.

La dificultad no está solamente en consumir una API. Está en decidir qué sistema controla cada dato, cómo se identifica el mismo registro en plataformas distintas, cómo se recupera una operación fallida y cómo el equipo puede demostrar que el proceso terminó correctamente.

Una integración débil puede funcionar durante semanas y, al mismo tiempo, acumular errores silenciosos: disponibilidad diferente del inventario físico, precios promocionales sobrescritos, pedidos creados dos veces, pagos confirmados que nunca llegan a facturación o colas detenidas sin alertas.

Esta guía presenta las decisiones técnicas y operativas que deben tomarse antes de conectar un ERP con una plataforma de ecommerce. Los principios se aplican tanto a operaciones B2C como B2B y también a entornos con marketplaces, PIM, WMS, pagos y logística.

1. Mapea la operación antes de mapear endpoints

Empieza describiendo el recorrido comercial completo:

¿Dónde se crea el producto?
¿Qué sistema define el precio base, las promociones y las listas por cliente?
¿Dónde se calcula el inventario disponible para vender?
¿En qué momento se reserva una unidad?
¿Cuándo debe enviarse el pedido al ERP?
¿Qué evento autoriza facturación, preparación y despacho?
¿Cómo liberan inventario los pagos rechazados, vencimientos y cancelaciones?
¿De dónde provienen factura, seguimiento y estado posventa?

Si estas reglas no están claras, la automatización hará circular la ambigüedad con mayor velocidad. Un conector técnico no puede resolver una decisión operativa que nunca fue definida.

Señales de que la integración actual ya quedó pequeña

el equipo mantiene hojas de cálculo paralelas para corregir inventario o precios;
los pedidos online deben cargarse nuevamente en el ERP;
soporte consulta varios sistemas para descubrir el estado real;
reprocesar una tarea puede duplicar productos o pedidos;
nadie identifica el último registro procesado con éxito;
los clientes detectan las fallas antes que el monitoreo;
un cambio comercial sencillo exige ediciones manuales en varios canales.

En este punto, la arquitectura de integración ya no es un detalle técnico: limita crecimiento, margen y calidad de servicio.

2. Define un sistema de registro para cada entidad

Decir que “el ERP es la fuente de verdad” puede ser correcto, pero es insuficiente. El ERP puede controlar inventario y facturación mientras la tienda controla contenido comercial, imágenes y SEO. La autoridad debe definirse por entidad y, cuando sea necesario, por campo.

Cuando la autoridad está definida, las escrituras provenientes de sistemas consumidores deben bloquearse o conciliarse explícitamente. Si el ERP controla el precio, una edición manual en la tienda no debería permanecer sin una regla de excepción documentada.

Documenta dirección, disparador y nivel de servicio

Para cada flujo, registra:

origen y destino;
evento que inicia el proceso;
comportamiento en tiempo real, programado o por lotes;
demora máxima aceptable;
campos obligatorios y validaciones;
tratamiento de registros inválidos;
responsable operativo;
procedimiento de corrección y reproceso.

Este mapa es el contrato operativo de la integración, no solamente un diagrama técnico.

3. Resuelve la identidad antes de sincronizar

Los identificadores internos pertenecen a cada sistema. El producto 1842 en el ERP puede ser 9631 en la tienda y tener otro código en cada marketplace. La integración necesita mantener una relación estable entre esos registros.

Productos y variantes

Usa SKU como identificador comercial cuando sea único, estable y gobernado. Cada variante vendible debe poseer su propio identificador. GTIN puede ayudar a reconocer equivalencias entre canales, pero no siempre reemplaza el SKU interno.

No relaciones productos por nombre, descripción o posición de atributos. Esos valores cambian y generan asociaciones frágiles.

Un registro de equivalencia suele guardar:

tenant u operación;
sistema e identificador de origen;
sistema e identificador de destino;
SKU y GTIN opcional;
estado de la relación;
última versión o fecha sincronizada;
situación de error o revisión.

Clientes y pedidos

El correo y los identificadores fiscales locales pueden ayudar a localizar clientes, pero no son universales ni siempre estables y además implican requisitos de privacidad. Un comprador puede cambiar su correo, comprar como invitado o utilizar identidades personales y empresariales diferentes. Conserva los identificadores externos emitidos por cada plataforma.

Para pedidos, mantén como mínimo:

identificador interno de integración;
número del pedido en el canal;
identificador en el ERP;
identificador de la transacción de pago;
clave de idempotencia;
identificador de correlación para registros y trazas.

4. El inventario es una regla de negocio, no un único número

El inventario físico no es necesariamente la cantidad que puede anunciarse. Un modelo frecuente es:

inventario disponible = existencia física − reservas − inventario de seguridad

La operación también puede necesitar considerar mercancía en tránsito, lotes bloqueados, varios almacenes, kits, componentes, fabricación bajo pedido y cuotas por canal.

Decisiones que deben ser explícitas

¿La reserva ocurre al agregar al carrito, crear el pedido o confirmar el pago?
¿Cuánto dura la reserva de una transferencia o pago pendiente?
¿Un pago rechazado libera el inventario inmediatamente?
¿Qué almacén atiende cada región o canal?
¿Un kit descuenta el producto final o sus componentes?
¿Qué ocurre cuando dos ventas disputan la última unidad?
¿Se permiten pedidos sin disponibilidad inmediata?
¿El inventario de seguridad es común o específico por canal?

Evita ciclos de retroalimentación

Un fallo común aparece cuando ERP y ecommerce se devuelven la misma modificación. El ERP publica inventario; la tienda lo aplica; un webhook interpreta esa aplicación como un nuevo cambio y la devuelve al ERP.

Registra el origen de cada actualización, usa versiones o fechas confiables e ignora eventos que solo confirman un estado ya aplicado. Las reglas de autoridad deben convertir las escrituras circulares en una excepción.

5. Modela el ciclo de vida del pedido

No intentes forzar todas las plataformas externas dentro de una única lista de estados. Cada sistema representa el proceso de forma diferente. Construye un modelo canónico interno y relaciona con él los estados externos.

Un ciclo posible incluye:

pedido recibido;
pendiente de pago;
pago confirmado;
en cola para el ERP;
aceptado por el ERP;
facturado;
en preparación;
enviado;
entregado;
cancelado, reembolsado o devuelto.

La distinción más importante es entre evento recibido y procesamiento concluido. Recibir el webhook del pago no demuestra que el pedido exista en el ERP. Enviar una solicitud no demuestra que el ERP la haya validado y guardado.

Conserva las transiciones

Guarda el historial con fecha, origen, datos relevantes y resultado. Así será posible responder:

cuándo se confirmó el pago;
cuánto tiempo permaneció el pedido en la cola;
qué intento creó el registro en el ERP;
por qué se liberó la reserva;
quién canceló o modificó el pedido;
qué estado fue comunicado al cliente.

6. Diseña operaciones idempotentes

Las redes pueden fallar de forma ambigua. Un sistema envía una solicitud, no recibe respuesta y vuelve a intentarlo aunque la primera ejecución haya terminado. Sin idempotencia, el nuevo intento puede crear otro pedido, cobrar nuevamente o descontar inventario dos veces.

Una operación idempotente produce el mismo efecto cuando se repite con la misma identidad. Una implementación sólida debe:

generar o aceptar una clave única por operación;
guardar la clave junto con el cambio de estado;
devolver el resultado anterior o rechazar duplicados;
usar una restricción única en la base de datos cuando sea posible;
no depender solamente de fechas o del hash completo del payload.

Para crear un pedido en el ERP, una clave adecuada puede combinar operación, canal e identificador original. Aplica el mismo principio a pagos, cancelaciones, reembolsos, envíos y movimientos de inventario.

La idempotencia no reemplaza las transacciones de base de datos. Protege la frontera entre sistemas; la consistencia local todavía necesita garantías transaccionales.

7. Usa procesamiento asíncrono cuando la experiencia lo permita

La tienda no siempre debe esperar a todos los sistemas posteriores. Después de aceptar el pedido de forma segura, su creación en el ERP puede procesarse mediante una cola, siempre que el estado sea visible y exista monitoreo.

Las colas permiten:

absorber picos;
proteger APIs externas;
aislar el checkout de una indisponibilidad temporal del ERP;
ejecutar nuevos intentos;
escalar workers de manera independiente;
conservar evidencia del procesamiento.

Los reintentos necesitan clasificación y límites

Errores transitorios — timeout, indisponibilidad temporal o límite de solicitudes — pueden reintentarse con intervalos crecientes. Errores permanentes — SKU desconocido, información fiscal inválida o campo obligatorio ausente — deben fallar rápido y enviarse a revisión.

Configura:

máximo de intentos;
backoff exponencial con variación aleatoria;
cola de mensajes fallidos;
alertas por acumulación y antigüedad;
reproceso controlado e idempotente.

Reintentar indefinidamente no es resiliencia: consume recursos y oculta datos inválidos.

8. Valida contratos y normaliza formatos

Dos APIs pueden intercambiar JSON y aun así discrepar sobre el significado de los datos. Define contratos explícitos para:

moneda y redondeo;
precisión de precio y cantidad;
zonas horarias y fechas;
direcciones y códigos de país o región;
identificadores fiscales locales;
descuentos por línea y por pedido;
envío, impuestos, aranceles y total final;
productos simples, variantes, kits, suscripciones y servicios;
campos nulos, opcionales y valores predeterminados.

Mantén las reglas regionales en una frontera clara. Una operación puede necesitar IVA, identificadores fiscales, formatos locales de factura, referencias de transferencia bancaria o información aduanera. El núcleo de la integración debe permitir esas adaptaciones sin mezclar las reglas de todos los países en cada flujo.

Versiona los contratos. Agregar un campo opcional suele ser seguro; cambiar el significado de un estado, una unidad de medida o un total monetario puede romper consumidores sin producir un error evidente.

9. Construye observabilidad alrededor del pedido

La integración no está lista para operar si soporte necesita consultar directamente la base de datos para localizar un pedido.

Registros estructurados

Cada evento relevante debe incluir campos buscables:

tenant o cuenta comercial;
sistema de origen y destino;
tipo de entidad;
identificadores externos;
clave de idempotencia;
trace_id o identificador de correlación;
número de intento;
duración;
resultado y código de error.

No registres credenciales, datos completos de pago ni información personal innecesaria.

Métricas operativas y comerciales

eventos recibidos y concluidos;
tasa de error por conector;
tiempo medio y percentiles p95/p99;
antigüedad del mensaje más antiguo;
cantidad de reintentos;
volumen en la cola de fallos;
diferencias encontradas por conciliación;
pedidos pagados todavía no aceptados por el ERP.

Trazabilidad distribuida

Cuando una solicitud atraviesa API, cola, worker y ERP, un identificador de correlación permite seguir la misma operación entre componentes. Relacionar registros y trazas reduce el tiempo necesario para descubrir exactamente dónde se detuvo el flujo.

10. Concilia los sistemas periódicamente

Un mensaje entregado no equivale a un resultado comercial verificado. Los webhooks pueden perderse, las APIs pueden quedar indisponibles y los usuarios pueden modificar datos manualmente. La integración en tiempo real debe complementarse con conciliación programada.

Algunas verificaciones útiles:

pedidos pagados en la tienda que no existen en el ERP;
pedidos facturados sin seguimiento en el ecommerce;
diferencias de precio o inventario;
cancelaciones aplicadas en un solo sistema;
pedidos duplicados por identificador externo;
eventos detenidos más allá del límite acordado.

La conciliación puede reparar automáticamente casos inequívocos y abrir una tarea para los ambiguos. El informe debe mostrar cantidad, impacto, registros afectados y acción realizada.

11. Prueba los caminos de fallo

Un único pedido exitoso no valida una integración. Construye una matriz de escenarios:

Prueba además concurrencia, volumen, expiración de credenciales, cambios de permisos, reinicio de workers y recuperación después de una caída externa.

12. Implementa por etapas y conserva un plan de reversión

Una migración segura puede comenzar en modo de lectura y comparación, sin escrituras automáticas. Después, habilita una categoría o grupo pequeño de pedidos, observa resultados y amplía únicamente cuando la conciliación sea estable.

Una secuencia posible:

limpiar y relacionar identificadores;
ejecutar la sincronización inicial;
comparar sistemas sin corrección automática;
habilitar catálogo e inventario para un grupo controlado;
procesar pedidos de prueba;
observar alertas y conciliación;
ampliar gradualmente;
retirar el proceso anterior solo después de demostrar estabilidad.

El plan de reversión debe explicar cómo pausar consumidores, conservar eventos pendientes, restaurar configuraciones y evitar que el flujo nuevo y el anterior escriban al mismo tiempo.

Lista de verificación técnica y comercial

Antes de desarrollar o contratar una integración, confirma:

Existe un sistema de registro para cada entidad.
Productos y variantes usan identificadores gobernados.
El inventario vendible posee una fórmula documentada.
Los estados del pedido están relacionados en ambos sentidos.
Las escrituras críticas son idempotentes.
Los reintentos separan errores transitorios y permanentes.
Los mensajes fallidos pueden revisarse y reprocesarse con seguridad.
Los registros permiten localizar un pedido sin acceder a la base de datos.
Las métricas y alertas cubren demora, error y divergencia.
La conciliación compara resultados comerciales.
El entorno de homologación representa escenarios reales.
Credenciales, permisos y datos personales están protegidos.
Implementación y reversión están documentadas.

Una integración confiable es una capacidad operativa

Una buena integración hace más que mover datos cuando todos los servicios están disponibles. Evita duplicidades, resiste indisponibilidades temporales, hace visibles los errores y permite recuperar la operación sin improvisación.

AGTI diseña y evoluciona plataformas de venta, integraciones con ERP y automatizaciones para operaciones B2C y B2B. Si las diferencias de inventario, las excepciones de pedidos o las tareas manuales están limitando tu ecommerce, podemos mapear el flujo actual y convertir las necesidades del negocio en una arquitectura ejecutable.

CTA: Habla con AGTI sobre tu integración

Referencias técnicas

AWS — Retry with backoff pattern: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html
Stripe — Idempotency in API requests: https://docs.stripe.com/api-v2-overview
OpenTelemetry — Log correlation: https://opentelemetry.io/docs/specs/otel/logs/
Google Analytics — Ecommerce measurement: https://developers.google.com/analytics/devguides/collection/ga4/ecommerce