Se lo digo sin rodeos: la integración OMS–WMS falla para casi todos los vendedores que conozco. Los pedidos salen del OMS; el almacén dice que nunca llegaron. El almacén dice que los envió; el comprador dice que no llegó nada. Ambos sistemas en verde, y el vendedor se come la mala reseña, el reembolso y el costo de envío.
Llevo cinco años vendiendo transfronterizo. Los primeros tres tuve mi propio almacén pequeño; cuando el volumen lo superó, me pasé a un 3PL en Los Ángeles en September 2024. Mismo OMS, nuevo WMS — y la primera semana me dejó lecciones que pagué con dinero real.
La primera fue el mapeo de SKU.
Teníamos 800+ SKU. Antes del lanzamiento exporté la lista para que el 3PL creara los registros de producto en su WMS. Suena simple. Primera semana: 100+ pedidos atascados en "pending" — se enviaron bien, pero el WMS no encontraba el SKU. Habían creado unos 700; los otros 100+ eran productos nuevos de los últimos dos meses, que faltaban en mi exportación. Los pedidos quedaron dos días hasta que los vi en el informe de excepciones, justo cuando los SKU de otoño/invierno estaban despegando. 100+ pedidos se enviaron dos días tarde; atención al cliente se llevó gritos toda la semana.
Lección dura: la tabla de mapeo de SKU debe conciliar al 100%, no al 99%. Exporto cada SKU del OMS y hago vlookup contra los códigos de artículo del WMS — una fila que falte, no hay lanzamiento. Y una regla dura: ninguna publicación sale en vivo hasta que su mapeo de SKU exista en el WMS. Mapeo primero, publicación después.
La integración OMS WMS empieza con la tabla de mapeo de campos
Un envío de pedido del OMS al WMS es, en esencia, una tabla de mapeo de campos — y el noventa por ciento de los incidentes de integración viven en ella. La mayoría de las guías de mapeo de campos para la integración OMS WMS se detienen en la tabla. La tabla es la parte fácil; las excepciones son donde los vendedores pierden dinero. Aquí está nuestra versión actual, con la última columna marcando dónde me quemé personalmente:
| Campo OMS | Campo WMS | Dónde falla |
|---|---|---|
| Número de pedido del marketplace | Referencia externa del pedido | Los dos sistemas usan números de pedido distintos — envíe ambos; el WMS debe deduplicar por la referencia externa |
| Número de pedido del OMS | Número de pedido de salida | No use aquí el número de pedido del marketplace — un comprador que haga dos pedidos en un día colisionará |
| SKU | Código de artículo | La tabla de mapeo debe existir primero; "crear mapeo" es un paso obligatorio en cada lanzamiento de producto nuevo |
| Cantidad | Cantidad de picking | ¡Unidades! Vender por caja vs. por pieza debe resolverse a una sola unidad en el WMS |
| Destinatario / dirección / ciudad / estado / código postal / teléfono | Información de envío | La línea 2 de la dirección (apt, unit, suite) debe enviarse — muchas integraciones solo envían la línea 1 |
| Método de envío | Transportista + código de servicio | Nunca envíe nombres de pantalla como "Standard" — envíe códigos que ambas partes acordaron de antemano |
| Nota del comprador | Nota de empaque | Su propio campo — nunca la meta en las líneas de dirección o la validación de direcciones falla |
| Tienda / comerciante | Código de comerciante | Obligatorio cuando varias tiendas comparten un WMS, o el inventario se descuenta del propietario equivocado |
Lo más traicionero son las unidades de cantidad. Nuestro pack de variedades se vendía por caja — 12 piezas cada una. El OMS envió "cajas", el registro del WMS estaba en "piezas", y los primeros 20 pedidos picaron 20 piezas en lugar de 20 cajas. Los compradores recibieron una pieza, asumieron que era la caja completa y abrieron disputas por todas partes. Agregamos una columna de "conversión de unidades" y marcamos cada pack de variedades. No ha vuelto a pasar.
Nunca envíe nombres de métodos de envío, solo códigos. Empezamos con "standard" y "expedited" — el 3PL usa cinco transportistas, cada uno con su propio "standard", y el WMS no podía distinguir a cuál nos referíamos. Ahora ambas partes comparten una tabla de códigos, el OMS envía códigos como GROUND_HOME, y las discusiones cayeron un noventa por ciento.
Cuatro excepciones en la integración OMS WMS que verá cada semana
Tengo esta matriz fijada — síntoma, manejo automático y cuándo interviene un humano. Cuatro tipos cubren casi todo:
| Excepción | Síntoma | Manejo automático | Interviene un humano cuando |
|---|---|---|---|
| SKU sin mapear | Pedido atascado en pending en el WMS | Retenido + agregado al informe de excepciones | Mismo día: agregue el mapeo, reenvíe manualmente |
| Stock corto | No hay suficiente stock para completar | Retener todo el pedido, o enviar la cantidad disponible según la regla | Sin resolver después de 4 horas — atención al cliente contacta al comprador |
| Dirección mala | La validación falla / paquete devuelto | Retenido | Verifique manualmente la dirección, corríjala, reenvíe |
| Envío duplicado | La misma referencia externa llega dos veces | El WMS deduplica por la referencia externa y lo descarta | No se necesita acción — pero el conteo de descartes debe aparecer en el informe |
El envío duplicado merece su propia historia — Black Friday 2024. Nuestro envío era API en tiempo real; la red tuvo un problema, el OMS se agotó y reintentó. Sin deduplicación por el número de pedido externo, el WMS creó dos pedidos de salida y el turno de noche envió ambos. Un comprador recibió dos paquetes y devolvió uno — el envío más el producto me costaron casi $40 en ese pedido. Una docena de duplicados esa noche. Todavía duele.
De ahí salieron dos reglas duras. Una: el WMS debe deduplicar por el número de pedido del marketplace — la idempotencia va en el contrato, no en un apretón de manos. Dos: antes del lanzamiento lo pruebo yo mismo, reenviando el mismo pedido 10 veces. Un pedido de salida es aprobado; dos significa que el 3PL vuelve y lo arregla.
Las direcciones malas también merecen una nota. La línea 2 de la dirección en EE. UU. — apt, unit, suite — se pierde constantemente porque los mapeos solo envían la línea 1. Un lote de nuestros pedidos a apartamentos se envió sin número de unidad, falló la entrega y volvió: siete días de ida y vuelta, directo a reseñas de una estrella. Ahora el OMS bloquea el envío a menos que los cuatro estén presentes — destinatario, líneas de dirección (línea 2 incluida), código postal, teléfono.
La conclusión contraintuitiva: menos campos, menos problemas
La mayoría piensa que más campos significa mejor integración e intenta enviar todo hasta los códigos de cupón. Yo también lo pensaba, hasta que me mordió: cada campo extra es otro punto de falla.
Un WMS ejecuta. Necesita el destinatario, el contenido, la cantidad, el método de envío y cualquier nota de empaque. Información de cupones, fuente del anuncio — el WMS no puede usarlos, y un campo malformado puede fallar todo el pedido. Recortamos nuestro payload de 30+ campos a 18; la tasa de excepciones cayó a la mitad.
Compromiso relacionado: envío en tiempo real vs. lote programado. El tiempo real se siente genial — los pedidos llegan al almacén en segundos — pero un problema de red significa pedidos perdidos o duplicados, normalmente a las 2 a.m. sin nadie mirando. El lote (un archivo cada 15 minutos) parece tonto pero es repetible y conciliable; cuando falla, se vuelve a ejecutar el archivo. Mi configuración: envío en tiempo real más un trabajo de conciliación cada 15 minutos que compara los números de pedido en ambos sistemas. Los pedidos en el OMS que falten en el WMS se reenvían automáticamente. ¿Quiere ambos beneficios? Haga ambos trabajos.
Lista de verificación de lanzamiento: 7 cosas que verificar la noche anterior
Nuestro segundo corte funcionó con esta lista — siete marcas, o no hay lanzamiento:
- Idempotencia: reenvíe deliberadamente el mismo pedido 10 veces — el WMS debe crear exactamente 1 pedido de salida.
- Conciliación total de SKU: exporte cada SKU del OMS, haga vlookup contra los códigos de artículo del WMS. Una fila que falte = no hay lanzamiento.
- Conversiones de unidades: packs de variedades y packs por caja, cada conversión detallada en la tabla de mapeo.
- Integridad de la dirección: destinatario, líneas de dirección (línea 2 incluida), código postal, teléfono — el OMS bloquea el envío si falta alguno.
- Tabla de códigos de transportista: ambas partes acuerdan los códigos; sin nombres de pantalla, sin palabras vagas como "standard".
- Las notas tienen su propio campo: las notas del comprador nunca van en las líneas de dirección.
- Prueba sandbox de 50 pedidos: use pedidos históricos reales, incluyendo deliberadamente datos sucios — números de apartamento, apartados postales, códigos postales remotos, teléfonos faltantes.
Cómo leer el informe de excepciones: tres números
Cada mañana a las 8, llega el informe de excepciones. Tres números, nada más:
Primero, cantidad de pedidos pendientes. Un dígito es normal; más de 20 y estoy llamando al 3PL.
Segundo, el desglose de causas de pendientes. Si la misma causa encabeza la lista tres días seguidos, la tabla de mapeo o la regla necesita arreglo — eso es sistémico, no aleatorio.
Tercero, pedidos pendientes por más de 24 horas — la línea roja. Pendiente está bien; ignorado no. Cualquier cosa atascada tanto tiempo es un envío tardío en camino; límpielo el mismo día.
Primeras dos semanas: la tasa de excepciones (pendientes + errores de envío sobre pedidos totales) rondaba el 8%. Dos meses con esta rutina: menos de 0.5%. Las semanas pico como Black Friday rebotan a ~1%, pero todo es visible en el informe y todo es accionable.
La integración OMS–WMS no es un problema de tecnología. Es un problema de atención. Haga bien el mapeo de campos de la integración OMS WMS, dé a cada excepción un responsable y lea el informe diario — haga esas tres cosas y la tasa de fallas cae un noventa por ciento. Lo probé yo mismo — de 8% a 0.5% con esa tabla y ese correo.
Por Ah K, Vendedor de comercio electrónico (5 años de experiencia)
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
