Integración ERP con Adobe Commerce: SAP, Oracle y Microsoft Dynamics

La mayoría de los proyectos de ecommerce empresarial que llegan a WolfSellers no fracasan por el frontend. Fracasan —o se retrasan meses— en la integración con el ERP. Es la pieza que más subestiman los planes de proyecto, la que más dependencias externas tiene, la que involucra a los equipos que no reportan a marketing ni a digital, y la única cuya falla se nota inmediatamente en la operación: un cliente compra algo que no existe en almacén, un pedido se procesa con el precio de otra lista, una factura no se timbra, un saldo de crédito se calcula mal.

La razón de fondo es que una integración ERP no es un proyecto técnico de conectar dos APIs. Es un ejercicio de gobierno de datos: decidir, entidad por entidad, qué sistema manda. Cuando esa decisión no se toma explícitamente al principio, se toma implícitamente después —y de forma inconsistente— en cada endpoint que alguien escribe. El resultado es el patrón que hemos visto reiteradamente al hacer rescate de proyectos: dos sistemas que se escriben mutuamente el mismo campo, sin un árbitro, hasta que nadie sabe cuál de los dos tiene el dato correcto.

Adobe Commerce (antes Magento) es, en arquitecturas empresariales, un sistema de interacción: el lugar donde el cliente descubre, configura, cotiza y compra. El ERP —SAP, Oracle o Microsoft Dynamics 365 en la gran mayoría de las empresas medianas y grandes en México— es el sistema de registro: el lugar donde vive la verdad contable, fiscal y logística del negocio. Este artículo es la guía técnica y metodológica de cómo conectarlos: qué flujos existen, qué patrones de integración conviene usar en cada caso, qué implica cada familia de ERP, cómo la facturación electrónica CFDI condiciona toda la arquitectura en México, y qué errores se repiten en casi todos los proyectos.

No es un artículo de vertical ni de funcionalidades. Si buscás el ángulo de industria, escribimos sobre ecommerce B2B en manufactura e industria; si buscás qué trae Adobe Commerce B2B de fábrica, lo detallamos en capacidades y funciones B2B de Adobe Commerce. Acá hablamos de la integración en sí.

---

Sistema de registro vs. sistema de interacción: por qué importa la distinción

Un sistema de registro (system of record) es la autoridad sobre un conjunto de datos: si hay conflicto, gana él. Un sistema de interacción (system of engagement) es donde el usuario opera sobre esos datos, normalmente con una copia local optimizada para lectura rápida.

El ERP es el sistema de registro de inventario, costos, precios contratados, límites de crédito, entidades fiscales y documentos contables. Adobe Commerce es el sistema de interacción: expone ese estado al comprador, captura intención y la convierte en una transacción que el ERP luego reconoce como propia.

Confundir los dos roles produce dos errores simétricos, ambos costosos:

• Tratar a Adobe Commerce como sistema de registro de datos que no le pertenecen. Ejemplo típico: dejar que un administrador edite stock en el panel de Adobe Commerce cuando el stock lo gobierna el ERP. Al siguiente ciclo de sincronización el cambio se pisa, alguien lo vuelve a hacer, y el equipo concluye que "la integración falla".
• Tratar al ERP como sistema de interacción, consultándolo en línea en cada pageview para pintar precio y disponibilidad. El ERP no fue diseñado para el patrón de carga de un catálogo público: la latencia se dispara, y cuando el ERP entra en cierre de mes o en ventana de mantenimiento, el sitio se cae con él.

La tabla de fuentes de verdad

El primer entregable de cualquier proyecto de integración ERP en WolfSellers no es un diagrama: es esta tabla, acordada y firmada por el dueño del ERP y el dueño del canal digital antes de escribir una línea de código.

Cuando esta tabla existe, el 80% de las discusiones de diseño se resuelven solas. Cuando no existe, se resuelven en producción.

---

Los flujos de integración canónicos

Toda integración entre Adobe Commerce y un ERP se compone de un subconjunto de estos flujos. No todos son necesarios desde el día uno —de hecho, recomendamos explícitamente que no lo sean, ver la sección de fases— pero conviene mapearlos completos desde el diseño para no descubrir a mitad del proyecto que falta un canal de datos.

Notas sobre los flujos que más se equivocan

Inventario. El error frecuente es enviar el catálogo completo cada quince minutos. Con veinte mil SKUs y varios almacenes eso es un job pesado que además no aporta: la enorme mayoría de los SKUs no cambió. Enviar delta —solo lo que se movió desde el último corte— reduce el volumen uno o dos órdenes de magnitud. En Adobe Commerce, el inventario multi-almacén se modela con fuentes y stocks (MSI): las fuentes corresponden a los almacenes del ERP y el stock agregado es lo que el comprador ve como cantidad vendible. Las reservas que Adobe Commerce genera al confirmar un pedido son locales y transitorias: existen para no sobrevender entre dos ciclos de sincronía, y se liberan cuando el ERP confirma el surtido.

Precios por cliente. En B2B es habitual que cada cuenta tenga condiciones propias. Precalcular el producto cartesiano de clientes por SKU es viable con cientos de clientes y decenas de miles de SKUs, y deja de serlo cuando esos números crecen. La alternativa es resolver el precio bajo demanda —al entrar a la ficha de producto o al armar el carrito— con una llamada al ERP o al middleware, y cachear el resultado por sesión con un TTL corto. La decisión entre precalcular y resolver en vivo es de las que más impacta el rendimiento del sitio, y hay que tomarla con los volúmenes reales del cliente sobre la mesa.

Orden de venta. Es el único flujo donde perder un mensaje significa perder dinero. Debe ser asíncrono, encolado, con reintentos y con una clave de idempotencia —típicamente el increment ID del pedido— para que un reintento no cree una segunda orden en el ERP. Y debe tener una cola de mensajes fallidos con alerta: un pedido atorado tiene que ser visible para un humano en minutos, no descubrirse en el cierre de mes.

---

Los cuatro patrones de integración

Casi todas las arquitecturas Adobe Commerce–ERP que hemos construido caen en uno de cuatro patrones, o en una combinación de ellos. La elección no es ideológica: depende del número de flujos, del volumen, de la versión del ERP y —lo que casi nadie considera al inicio— de quién va a operar la integración dentro de tres años.

1. Punto a punto vía APIs REST

Es el patrón más directo: el conector habla con las APIs REST de Adobe Commerce por un lado y con las del ERP por el otro. La lógica de mapeo, transformación y reintentos vive en código propio, ya sea como módulo de Adobe Commerce o —preferentemente— fuera del monolito.

En Adobe Commerce, el enfoque moderno para esto es la extensibilidad fuera del proceso: en lugar de meter la integración dentro del código de la tienda, se ejecuta en servicios externos que consumen las APIs REST y GraphQL de la plataforma y reaccionan a sus eventos. Adobe empuja explícitamente en esa dirección con App Builder y con su modelo de eventos, y la razón práctica es contundente: una integración que vive fuera del monolito no se rompe con cada upgrade de la plataforma ni compite por los recursos del servidor web durante un pico de tráfico.

• Ventajas: menor costo inicial, sin licencia adicional, control total sobre la lógica, tiempo de arranque corto.
• Desventajas: la observabilidad hay que construirla; cada flujo nuevo agrega código propio; el conocimiento tiende a concentrarse en pocas personas; con N sistemas el número de conexiones a mantener crece rápido.
• Cuándo lo elegimos: proyectos con un ERP moderno, un puñado de flujos bien definidos y un equipo que va a seguir cerca del sistema.

2. Middleware / capa de integración (iPaaS)

Un middleware —MuleSoft, Dell Boomi, Azure Integration Services, SAP Integration Suite, Oracle Integration Cloud, o incluso una capa de integración propia bien construida— se sienta entre Adobe Commerce y el ERP, y normalmente entre todos los demás sistemas del negocio.

Su valor real no es técnico sino operativo: un solo lugar donde ver qué mensajes pasaron, cuáles fallaron y por qué; una sola política de reintentos; transformaciones declarativas en vez de código disperso; y la capacidad de cambiar un extremo —migrar de una versión de ERP a otra, agregar un segundo canal de venta— sin reescribir el otro.

• Ventajas: trazabilidad y monitoreo centralizados, reutilización de flujos entre canales, desacople real entre extremos, gobierno más fácil cuando hay varios equipos.
• Desventajas: costo de licencia y de plataforma, curva de aprendizaje, un componente más que operar y que puede convertirse en cuello de botella si se le mete demasiada lógica de negocio.
• Cuándo lo elegimos: cuando el ecommerce no es el único consumidor del ERP, cuando hay más de una marca, país o canal, o cuando el cliente ya tiene un iPaaS corporativo —en ese caso discutir el patrón es discutir contra una decisión ya tomada, y lo sensato es aprovecharla.

3. Integración basada en eventos con colas y mensajería

En lugar de que un sistema pregunte periódicamente "¿cambió algo?", el sistema que cambia publica un evento y los interesados reaccionan. Es el patrón que mejor escala y el que mejor tolera fallas, porque la cola actúa de amortiguador: si el consumidor está caído, los mensajes esperan.

Adobe Commerce trae mensajería asíncrona de fábrica —usa una cola de mensajes para procesos pesados y expone endpoints asíncronos y de carga masiva que devuelven de inmediato y procesan en segundo plano—, y puede emitir eventos hacia servicios externos. Del lado del ERP, las plataformas modernas también publican eventos de negocio: SAP con su capacidad de eventos y su bus de mensajería, Dynamics 365 Finance & Operations con business events, y prácticamente todos los ERP cloud con algún mecanismo de webhooks.

• Ventajas: latencia baja sin polling, resiliencia ante caídas, desacople temporal entre productor y consumidor, escala horizontal natural.
• Desventajas: exige disciplina en el diseño —orden de mensajes, entrega duplicada, idempotencia obligatoria— y equipos capaces de depurar un flujo asíncrono, que es más difícil que depurar una llamada síncrona.
• Cuándo lo elegimos: para inventario y estados de orden en operaciones de volumen alto, y siempre que el pedido no pueda perderse bajo ninguna circunstancia.

4. Batch / archivo

Sigue vivo y sigue siendo la respuesta correcta en más casos de los que la industria admite. Un ERP muy personalizado, o una versión antigua sin servicios expuestos, muchas veces solo puede generar un archivo en una ventana nocturna. Y para ciertos datos eso alcanza perfectamente: un maestro de artículos que cambia dos veces por semana no necesita eventos.

• Ventajas: simple, barato, robusto, soportado por cualquier ERP sin importar su antigüedad, óptimo para volúmenes muy grandes.
• Desventajas: latencia de horas, reprocesar un archivo con errores es incómodo, y la ventana nocturna se vuelve un recurso escaso cuando compiten varios procesos.
• Cuándo lo elegimos: carga inicial del catálogo, maestros de baja volatilidad, reconciliación nocturna, y como puente temporal mientras se moderniza el ERP.

Cómo elegir sin sobre-diseñar

Nuestra recomendación práctica en WolfSellers: empezar con el patrón más simple que resuelva los flujos críticos, pero estructurar el código desde el día uno como si fuera a haber middleware. Es decir, aislar el mapeo de datos, no acoplar la lógica de negocio a un cliente HTTP específico, y encolar todo lo que sea escritura. Ese diseño hace que migrar de punto a punto a iPaaS más adelante sea una refactorización acotada y no una reescritura. El error inverso —comprar un iPaaS para dos flujos— es igual de costoso, solo que el costo se paga en licencia y en tiempo de arranque.

---

Particularidades por ERP: SAP, Oracle y Microsoft Dynamics

Esta sección no compara cuál ERP es mejor. Esa es una decisión de la empresa, tomada por razones que preceden al proyecto de ecommerce y que rara vez se revisan por él. Lo que sí importa para la arquitectura de integración es qué implica conectarse a cada uno: qué interfaces expone, cómo se comportan y qué trampas conocidas tiene cada familia.

SAP: S/4HANA y ECC

SAP es el ERP más frecuente entre las empresas grandes de manufactura, distribución y consumo en México, y es también el que presenta la mayor diferencia entre generaciones.

• S/4HANA expone un catálogo amplio de servicios OData (v2 y v4) para prácticamente todos los objetos de negocio relevantes: material, socio de negocio, condiciones de precio, pedido de venta, documento de facturación. Es la vía preferente y la que mejor se documenta. Complementariamente, SAP puede publicar eventos de negocio para notificar cambios sin polling.
• ECC, la generación anterior que sigue en producción en muchísimas empresas, se integra principalmente mediante BAPI/RFC e IDoc. Los IDoc son un formato de mensaje maduro y confiable —con tipos estándar para maestro de materiales, maestro de clientes y pedidos— pero son asíncronos por naturaleza y su monitoreo vive dentro de SAP, lo que complica la observabilidad desde el lado del canal digital.
• Lo que hay que anticipar: SAP suele estar fuertemente personalizado. Los campos que el negocio considera "el precio" o "el stock" muchas veces no son los campos estándar, sino campos Z añadidos por un proyecto anterior. La sesión de descubrimiento con el equipo funcional de SAP es la actividad de mayor retorno de todo el proyecto, y conviene hacerla antes de estimar nada.
• Determinación de precios: SAP resuelve el precio con una cadena de condiciones que puede depender de cliente, material, volumen, fecha, campaña y jerarquía de cliente simultáneamente. Replicar esa lógica dentro de Adobe Commerce es tentador y casi siempre un error: cuando el negocio cambia una condición en SAP, la copia en el canal digital queda desfasada. Es preferible pedirle el precio a SAP —precalculado por lista o resuelto en vivo— que reimplementar su motor.

Oracle: NetSuite y Oracle Fusion / EBS

Bajo la marca Oracle conviven productos muy distintos, y tratarlos como uno solo es una fuente clásica de malentendidos en el alcance.

• NetSuite es un ERP cloud orientado a empresas medianas, con integración vía SuiteTalk (servicios web SOAP y REST), RESTlets (endpoints propios escritos en SuiteScript) y consultas tipo SQL sobre sus registros. Es cómodo de integrar y muy flexible, pero tiene límites de gobernanza: cada script consume unidades de un presupuesto acotado, y una integración mal diseñada —que lea de más o de a un registro por vez— choca contra ese techo. Diseñar para operaciones por lote no es una optimización opcional en NetSuite: es un requisito.
• Oracle Fusion Cloud ERP expone APIs REST para los objetos de negocio y mecanismos de importación masiva basados en archivo para volúmenes grandes, además de una capa de integración propia. La combinación habitual es REST para lo transaccional en línea y carga masiva para maestros y cargas iniciales.
• Oracle E-Business Suite (EBS), la generación on-premise, se integra por servicios expuestos desde su capa de integración, procedimientos almacenados e interfaces de tabla. Es más artesanal y se parece más al mundo batch que al mundo API.
• Lo que hay que anticipar: en Oracle es especialmente importante fijar temprano el modelo de datos del cliente. La distinción entre la entidad legal, la cuenta comercial y la dirección de envío tiene implicaciones directas sobre cómo se modelan las cuentas de empresa en Adobe Commerce B2B, y rehacerlo después de tener cuentas productivas es doloroso.

Microsoft Dynamics 365: Business Central y Finance & Operations

También aquí hay dos productos distintos bajo el mismo paraguas, con perfiles de empresa diferentes.

• Business Central es la opción para empresas medianas. Expone APIs OData v4 sobre sus entidades estándar, permite publicar entidades propias desde extensiones, y se conecta con naturalidad al ecosistema de automatización de Microsoft. Para muchos proyectos de tamaño medio es de los ERP más cómodos de integrar.
• Finance & Operations apunta a la empresa grande. Se integra mediante entidades OData, servicios personalizados, un marco de gestión de datos para cargas masivas recurrentes, y business events para notificar cambios de forma reactiva. Además, la integración con Dataverse permite exponer datos hacia el ecosistema Power Platform, lo que a veces resuelve necesidades de back-office sin tocar el canal digital.
• Lo que hay que anticipar: los volúmenes. Las entidades OData son cómodas para lo transaccional pero no son la vía adecuada para mover cientos de miles de registros; para eso está el mecanismo de carga masiva. Mezclar los dos caminos —o intentar el masivo por OData— es una de las causas más comunes de proyectos que funcionan en QA y se caen en producción.

Lo que es común a los tres

---

CFDI 4.0 y timbrado ante el SAT: por qué define la arquitectura en México

Este es el punto donde una integración diseñada en otro país se rompe al aterrizar en México, y donde con más frecuencia vemos arquitecturas que hay que rehacer. La facturación electrónica mexicana no es un detalle de la última milla del proyecto: es una restricción que condiciona el modelo de datos del checkout, la secuencia de estados del pedido y la definición misma de qué sistema emite qué documento.

Qué es el CFDI y quién lo emite

El CFDI (Comprobante Fiscal Digital por Internet) es el comprobante fiscal electrónico obligatorio en México. Su versión vigente es la 4.0, obligatoria desde 2023 tras varias prórrogas. Un CFDI no es un PDF: es un archivo XML con estructura definida por el SAT que debe ser timbrado por un PAC (Proveedor Autorizado de Certificación) antes de tener validez fiscal. El timbrado devuelve un UUID o folio fiscal que identifica al comprobante de forma única.

La pregunta arquitectónica es quién dispara ese timbrado. Nuestra respuesta, salvo excepciones muy justificadas, es el ERP, por cuatro razones concretas:

1. La factura es un asiento contable, no un artefacto del canal de venta. Nace en el mismo lugar donde se registran ingresos, impuestos y cuentas por cobrar.
2. El folio fiscal debe ser único e irrepetible para toda la empresa. Si el ecommerce timbra por su cuenta, la empresa termina con dos fuentes de folios que hay que conciliar, y esa conciliación es exactamente el tipo de trabajo manual que el proyecto venía a eliminar.
3. El ecommerce no es el único canal. Mostrador, televentas, distribuidores y marketplaces facturan por el ERP. Sacar al canal digital de ese circuito lo convierte en una excepción permanente.
4. La cancelación y sustitución de comprobantes exige control fino: motivo de cancelación, comprobante que sustituye, y en varios supuestos aceptación del receptor. Ese flujo pertenece al área fiscal, que trabaja en el ERP.

La excepción razonable es el B2C puro de alto volumen con factura al público en general, donde a veces se usa un servicio de timbrado especializado conectado directamente al canal —típicamente con un portal de autofacturación— y el ERP recibe el resumen. Incluso ahí, el criterio de diseño es que exista un solo emisor por tipo de operación, nunca dos compitiendo.

Qué debe capturar y validar el canal digital

Aunque no emita el comprobante, Adobe Commerce sí es responsable de capturar correctamente los datos fiscales, porque un dato mal capturado se convierte en un timbrado rechazado horas después, cuando el cliente ya se fue.

CFDI 4.0 endureció la validación de los datos del receptor. En la práctica, el checkout debe capturar y —en lo posible— validar:

• RFC del receptor, con la estructura correcta según sea persona física o moral.
• Nombre o razón social exactamente como aparece en la constancia de situación fiscal. Este es el campo que más rechazos genera: variaciones de puntuación, abreviaturas o el sufijo del tipo de sociedad hacen fallar el timbrado.
• Régimen fiscal del receptor.
• Código postal del domicilio fiscal, que no necesariamente coincide con el domicilio de entrega.
• Uso del CFDI, que el comprador elige y que debe ser compatible con su régimen fiscal.
• Forma y método de pago, que determinan si la operación se factura como pago en una sola exhibición o como pago en parcialidades o diferido.

Para ventas al público en general existe el uso del RFC genérico, con reglas propias. Conviene modelar ese caso explícitamente en lugar de tratarlo como excepción, porque en B2C suele ser la mayoría de las operaciones.

El complemento de pago, el detalle que casi siempre se descubre tarde

Cuando la operación se factura como pago en parcialidades o diferido —el caso normal en B2B a crédito— la factura inicial no cierra el ciclo. Cada pago recibido debe documentarse con un complemento de pago (recibo electrónico de pago) que referencia el comprobante original.

Esto tiene una consecuencia directa sobre la arquitectura: el ciclo fiscal de un pedido B2B no termina cuando el pedido se entrega, sino cuando se cobra, y eso puede ocurrir semanas después. El canal digital debe reflejar esa realidad si el cliente espera ver su estado de cuenta en el portal: no alcanza con sincronizar facturas, hay que sincronizar también las aplicaciones de pago. Es de los flujos que más veces hemos visto quedar fuera del alcance inicial y entrar como cambio de alcance a mitad de proyecto.

Devoluciones y notas de crédito

Una devolución en el canal digital normalmente se origina como una solicitud de devolución (RMA) en Adobe Commerce. Pero el documento fiscal que la refleja —la nota de crédito, un CFDI de egreso que referencia el comprobante original— lo emite el ERP. El diseño correcto separa los dos planos: el flujo de autorización, logística inversa y reembolso puede vivir en el canal digital u orquestarse en el OMS, mientras que la emisión del comprobante y su relación con el original quedan del lado del ERP.

Conviene además dejar decidido desde el principio qué se hace con las cancelaciones fuera de plazo, con las devoluciones parciales y con las que llegan después del cierre del mes. Son casos borde reales que aparecen en la primera semana de operación.

Qué implica todo esto para el diseño

Cuando el negocio además mueve mercancía por territorio nacional con transporte propio o contratado, aparecen requisitos adicionales de documentación del traslado que conviene revisar con el área fiscal en el descubrimiento, porque impactan al flujo logístico y no solo al contable.

---

Rendimiento y resiliencia: la integración no puede tumbar el sitio

Una integración bien diseñada es invisible cuando funciona y degrada con dignidad cuando no. Estos son los principios que aplicamos en todos nuestros proyectos de implementación.

Regla uno: el ERP no se consulta en cada pageview

Es la regla más importante y la más violada. Consultar el ERP en línea para pintar precio y disponibilidad en una ficha de producto significa que:

• La latencia de tu sitio pasa a ser la latencia del ERP, sobre la que no tenés control.
• La caché de página completa deja de servir, porque cada render depende de una llamada externa.
• Un pico de tráfico —una campaña, El Buen Fin, un correo masivo— se convierte en un ataque de denegación de servicio contra tu propio ERP.
• Una ventana de mantenimiento del ERP se convierte en una caída del canal de venta.

La disciplina correcta es proyectar el estado del ERP dentro de Adobe Commerce y refrescarlo por sincronía o por evento. El comprador lee de la proyección local, que responde en milisegundos.

Dónde sí conviene consultar en vivo

Hay tres momentos donde la llamada síncrona se justifica porque el costo del dato obsoleto supera al de la latencia, y donde el volumen de llamadas es acotado por definición:

1. Verificación de disponibilidad al confirmar el pedido, no antes. Es una llamada por pedido, no una por visita.
2. Consulta de crédito disponible en el checkout B2B, porque autorizar un pedido contra un saldo obsoleto es un problema de cobranza, no de experiencia.
3. Precio contratado de un cliente específico en catálogos demasiado grandes para precalcular, cacheado por sesión con un TTL corto.

Incluso en estos casos, la llamada necesita timeout agresivo y comportamiento definido ante falla: si el ERP no responde en el plazo, el sistema debe tener una respuesta prevista —aceptar el pedido y marcarlo para revisión, o bloquear con un mensaje claro— pero nunca quedarse colgado esperando.

Caché con intención

No toda la información caduca igual. Un esquema que funciona bien en la práctica:

• Precio de lista: caché larga, invalidación por evento cuando el ERP publica un cambio.
• Inventario: caché corta (minutos) con umbrales. Un SKU con mil unidades no necesita precisión al segundo; uno con tres unidades sí, y ahí conviene bajar el TTL o marcar el producto como de disponibilidad ajustada.
• Crédito y saldo: caché por sesión y muy corta, o directamente sin caché en el momento del checkout.
• Estado de la orden: refresco por evento, con un respaldo periódico por si el evento se perdió.

Idempotencia, reintentos y colas

Todo mensaje de escritura hacia el ERP debe ser idempotente: procesarlo dos veces tiene que producir el mismo resultado que procesarlo una. Sin esto, cualquier reintento —y va a haber reintentos— duplica órdenes. La forma habitual es enviar una clave estable en cada mensaje y que el receptor la use para detectar duplicados.

Los reintentos deben usar espera exponencial con jitter, no un ciclo cerrado: si el ERP está saturado, reintentar cada segundo lo empeora. Y deben tener un límite, después del cual el mensaje va a una cola de mensajes fallidos con alerta activa. Un pedido que no llegó al ERP debe generar una notificación, no esperar a que alguien lo note.

Vale la pena agregar un cortacircuitos: cuando el ERP acumula fallas, dejar de intentar por un período y encolar, en vez de golpear un sistema caído. El canal sigue vendiendo, los mensajes se acumulan, y cuando el ERP vuelve la cola se drena sola. Esa es exactamente la diferencia entre una ventana de mantenimiento del ERP que nadie nota y una que sale en el reporte de incidencias.

Reconciliación y detección de drift

Aun con todo lo anterior bien hecho, los sistemas se desincronizan. Un mensaje se pierde, un cambio manual se cuela, un despliegue interrumpe un ciclo. Por eso incluimos siempre un proceso de reconciliación nocturno que compara ambos lados —conteos por entidad, sumas de control, muestras de precios y stock— y reporta las diferencias.

El objetivo no es que el proceso las corrija automáticamente, al menos no al principio: es que las haga visibles antes que el negocio. La diferencia entre un equipo que descubre un desfase en el reporte de las 7 de la mañana y uno que lo descubre porque un cliente reclamó es enorme, y se construye con un job de reconciliación y un tablero.

Cerrando el círculo, la observabilidad de la integración necesita métricas propias: mensajes procesados y fallidos por flujo, latencia por llamada, antigüedad del dato en cada proyección, y profundidad de cola. Si un flujo se detiene, el tiempo hasta detectarlo debería medirse en minutos.

---

Secuencia de proyecto: qué integrar primero

El error de secuencia más común es intentar integrar todo antes del primer go-live. Produce proyectos largos, sin retroalimentación real y con toda la deuda de riesgo concentrada en una sola fecha. Nuestra recomendación es al revés: el primer go-live debe incluir el mínimo de flujos que permite vender de verdad, y el resto entra por incrementos con el sitio ya en producción.

Los tiempos son orientativos y dependen sobre todo de dos variables que no controla el equipo de ecommerce: la disponibilidad del equipo de ERP y el grado de personalización del ERP. En proyectos donde el equipo funcional de SAP u Oracle tuvo dedicación asignada desde el descubrimiento, hemos visto fases completarse en la mitad del tiempo que cuando ese equipo participa a demanda.

Una nota sobre B2C versus B2B: en B2C puro las fases 1 a 3 suelen alcanzar para una operación completa. La fase 4 es la que separa un proyecto B2B de uno B2C, y es también la más larga, porque el crédito y los precios por contrato tocan las reglas comerciales más idiosincrásicas de cada empresa. Si el proyecto es B2B, conviene no subestimarla ni dejarla para el final del presupuesto.

---

Errores frecuentes en integraciones ERP

Esta tabla resume lo que hemos encontrado repetidamente al auditar integraciones existentes y al hacer rescate de proyectos detenidos.

---

WolfSellers e integraciones ERP en México

En WolfSellers somos Adobe Gold Partner con más de una década implementando Adobe Commerce y Adobe Experience Cloud en México y LATAM, y la integración con sistemas de back-office es una de nuestras prácticas centrales. Hemos diseñado y construido integraciones Adobe Commerce–ERP en manufactura, distribución y retail, con las tres familias que cubre este artículo, tanto en arquitecturas punto a punto como sobre middleware corporativo.

Lo que aporta esa experiencia no es principalmente código: es criterio para las decisiones que se toman en las primeras semanas y que después son caras de revertir. Qué flujos entran en la fase uno y cuáles pueden esperar. Cuándo un iPaaS se paga solo y cuándo es sobre-ingeniería. Cómo modelar la jerarquía de cuentas cuando el ERP y el negocio no la ven igual. Y cómo acomodar la realidad fiscal mexicana —CFDI, complemento de pago, cancelaciones— dentro de un modelo de datos que además tiene que funcionar para el comprador.

Nuestro punto de partida nunca es proponer una arquitectura. Es entender el negocio y el ERP tal como está hoy, no como está documentado: ¿qué versión corre y cuánto está personalizada? ¿Qué interfaces ya existen y quién las mantiene? ¿Hay un middleware corporativo en el que el ecommerce debería apoyarse? ¿La operación es B2B a crédito, B2C, o ambas sobre la misma plataforma? ¿Quién timbra hoy y cómo se resuelven las cancelaciones? ¿Qué equipo del lado del ERP va a estar disponible y con qué dedicación? Las respuestas determinan el patrón, el orden de las fases y el alcance realista del primer go-live.

Si estás evaluando integrar Adobe Commerce con tu ERP, rescatando una integración existente que no termina de estabilizarse, o dimensionando un proyecto antes de comprometer presupuesto, te invitamos a empezar con un discovery gratuito con nuestro equipo. Nuestros servicios de integración ERP, desarrollo a medida y consultoría cubren desde el diseño de la arquitectura hasta la operación continua de los flujos.

---

Preguntas frecuentes sobre integración ERP con Adobe Commerce

¿Cuánto tarda una integración ERP con Adobe Commerce?

Depende del alcance y, sobre todo, de dos variables que suelen estar fuera del control del equipo de ecommerce: qué tan personalizado está el ERP y cuánta dedicación tiene asignada el equipo que lo mantiene. Como referencia de nuestros proyectos, una integración de alcance acotado —catálogo, inventario, precio de lista y orden de venta, que es lo mínimo para vender de verdad— suele tomar entre 8 y 14 semanas desde el descubrimiento, incluyendo pruebas. Sumar el bloque fiscal completo (CFDI, complemento de pago, notas de crédito) agrega típicamente entre 2 y 5 semanas. Un alcance B2B completo, con alta de cuentas, precios por contrato y validación de crédito en línea, lleva el total a un rango de 5 a 8 meses. Recomendamos siempre fasear: salir a producción con los flujos críticos e incorporar el resto con el sitio ya operando genera retorno antes y reduce el riesgo concentrado en una sola fecha de go-live.

¿Conviene middleware o punto a punto?

La regla práctica que usamos: si el ecommerce es el único sistema que necesita hablar con el ERP y los flujos son pocos y estables, punto a punto es más rápido y más barato, y no hay razón para agregar un componente más. Si hay varios sistemas en juego —ERP, PIM, OMS, CRM, WMS—, varias marcas, países o canales de venta, o si la empresa ya opera un iPaaS corporativo, el middleware se justifica solo: su valor está en la trazabilidad centralizada, la reutilización de flujos y el desacople entre extremos, que es lo que permite cambiar de versión de ERP sin reescribir el canal. Nuestra recomendación en cualquiera de los dos casos es estructurar el código como si fuera a haber middleware —mapeos aislados, escrituras encoladas, sin acoplar la lógica de negocio al cliente HTTP— para que la migración posterior, si llega, sea una refactorización acotada y no una reescritura.

¿Quién debe emitir el CFDI: el ERP o el ecommerce?

En la gran mayoría de los casos, el ERP. La factura es un documento contable y fiscal que nace donde se registran ingresos, impuestos y cuentas por cobrar; el folio fiscal debe ser único para toda la empresa; el ecommerce no es el único canal que factura (también lo hacen mostrador, televentas y distribuidores); y los flujos de cancelación y sustitución de comprobantes, con su motivo y su relación con el documento que sustituyen, pertenecen al área fiscal. Que el ecommerce timbre por su cuenta crea una segunda fuente de folios que hay que conciliar. La excepción razonable es el B2C de alto volumen con factura al público en general, donde a veces se usa un servicio de timbrado conectado al canal —normalmente con portal de autofacturación— y el ERP recibe el resumen. El criterio de diseño, en cualquier escenario, es que haya un solo emisor por tipo de operación: el problema no es dónde se timbra, sino que se timbre en dos lados.

¿Cada cuánto debe sincronizarse el inventario entre el ERP y Adobe Commerce?

Para la mayoría de las operaciones, un ciclo de 5 a 15 minutos con envío por delta —solo lo que cambió— es suficiente y evita cargar ambos sistemas innecesariamente. Si el ERP puede emitir eventos de cambio de stock, mejor todavía: la latencia baja a segundos sin polling. Lo que no recomendamos en ningún escenario es consultar el ERP en línea en cada vista de producto: destruye la caché de página, ata la latencia del sitio a la del ERP y convierte cualquier pico de tráfico en un problema para el back-office. El patrón correcto es proyectar el stock dentro de Adobe Commerce con reservas locales que eviten sobreventa entre ciclos, y hacer una verificación en vivo únicamente al confirmar el pedido, que es una llamada por pedido y no una por visita. Para SKUs con inventario muy bajo conviene además acortar el TTL o marcarlos con disponibilidad ajustada.

¿Se puede integrar Adobe Commerce con un ERP antiguo que no tiene APIs REST?

Sí, y es más común de lo que parece. Los ERP legacy suelen ofrecer alguna combinación de intercambio de archivos por SFTP, mensajería propietaria, llamadas a funciones remotas, procedimientos almacenados o tablas de interfaz. El diseño habitual en estos casos es híbrido: batch para los maestros de baja volatilidad (artículos, listas de precio, clientes), que toleran latencia de horas sin ningún impacto de negocio, y una capa intermedia que expone servicios modernos hacia Adobe Commerce para lo transaccional —órdenes, consulta de crédito, estado— traduciendo hacia el mecanismo que el ERP sí soporta. Esa capa intermedia puede ser un iPaaS o un servicio propio; lo importante es que exista, para que el canal digital no quede acoplado a los formatos del ERP y una eventual modernización del ERP no obligue a reescribir el ecommerce.

¿Qué pasa con los pedidos si el ERP se cae?

Con una arquitectura bien diseñada, no pasa nada visible para el comprador: sigue comprando. La condición es que la escritura de la orden hacia el ERP sea asíncrona y encolada. Adobe Commerce acepta el pedido, cobra si corresponde y encola el mensaje; si el ERP no responde, el mensaje espera y se reintenta con espera exponencial. Cuando el ERP vuelve, la cola se drena sola y las órdenes entran en orden. Los tres complementos que hacen que esto funcione de verdad son: idempotencia, para que los reintentos no dupliquen órdenes; una cola de mensajes fallidos con alerta, para que un pedido atorado sea visible para un humano en minutos; y un cortacircuitos que deje de golpear al ERP cuando acumula fallas. Lo que sí se degrada durante la caída son las consultas en vivo —crédito disponible, verificación final de stock— y para esas hay que tener definida de antemano la política: aceptar el pedido y marcarlo para revisión manual, o bloquear con un mensaje claro. Lo que nunca debe pasar es que el checkout se quede colgado esperando una respuesta que no va a llegar.

---

Servicios relacionados