Magento 2, MSI e inventory_reservation después de la integración con ERP

Magento 2 con MSI puede gestionar muy bien inventario multifuente, reservas y salable quantity. El problema empieza cuando este mecanismo llega a una implementación en la que la fuente real de verdad sobre el stock no es Magento, sino un ERP o un WMS externo. En ese modelo, la lógica de reservas suele seguir funcionando técnicamente, pero desde el punto de vista del negocio deja de ser necesaria. En lugar de ayudar, empieza a distorsionar la visión de la disponibilidad.

Este es uno de esos problemas que durante mucho tiempo parecen insignificantes. La tienda funciona, entran pedidos, las importaciones de stock se ejecutan correctamente y, aun así, con el tiempo empiezan a aparecer preguntas:

• por qué salable quantity no coincide con el stock del ERP
• por qué un producto no está disponible si el ERP muestra disponibilidad
• por qué hay cientos de miles o millones de registros en inventory_reservation
• por qué diagnosticar problemas de stock en Magento se vuelve cada vez más difícil

En la práctica, este es un escenario muy común en tiendas que ya están maduras en términos de integración y funcionan en un modelo ERP-first.

Dónde empieza el problema

En Magento 2 estándar con MSI, las entradas en inventory_reservation se crean al realizar pedidos y luego se compensan mediante operaciones posteriores, como envío o cancelación. En teoría, todo es coherente. En la práctica, si la tienda sobrescribe regularmente el stock desde ERP, Magento deja de ser la única fuente de verdad y ya no gestiona el inventario por sí mismo.

Eso significa que dos lógicas empiezan a operar en paralelo:

• el ERP define la disponibilidad real
• Magento sigue manteniendo su propia capa de reservas

Si esa arquitectura no se ha ordenado conscientemente, empiezan a aparecer desviaciones. No siempre de inmediato, pero con el tiempo casi siempre.

Síntomas que vemos en los proyectos

Lo más habitual es que el problema se manifieste en una de varias formas.

1. salable quantity es menor que el stock del ERP

Este es el caso más frecuente. El equipo de la tienda ve que el ERP muestra disponibilidad, mientras Magento sigue bloqueando la venta o reduce el número de unidades que se pueden comprar.

2. La tabla inventory_reservation crece constantemente

En tiendas con mayor volumen de pedidos, esta tabla puede crecer muy rápido. El crecimiento por sí solo no es necesariamente un error, pero en un modelo ERP-first a menudo se convierte simplemente en un coste de mantenimiento innecesario y en otro lugar que oculta la imagen real del stock.

3. Diagnóstico más difícil de los problemas de inventario

Cuando la disponibilidad del producto depende al mismo tiempo de la importación desde ERP, de la indexación de Magento y de las reservas MSI guardadas, el diagnóstico deja de ser sencillo. El equipo tiene que analizar si el problema está en la importación, en el índice, en el stock, en la asignación de sources o en la propia tabla inventory_reservation.

4. Conflictos entre la importación y la lógica actual de Magento

En algunas implementaciones, Magento se comporta correctamente desde el punto de vista de sus propias reglas, pero no de acuerdo con las expectativas del negocio. Es una diferencia importante. El sistema no tiene que estar técnicamente roto para comportarse de forma incorrecta dentro de un determinado modelo operativo.

Por qué el enfoque estándar no siempre es suficiente

En teoría podría decirse: si Magento tiene MSI, basta con dejarlo funcionar. El problema es que MSI no fue diseñado específicamente para cada modelo de integración con ERP. En algunas implementaciones es una arquitectura ideal. En otras, requiere una simplificación consciente.

No se trata de luchar contra Magento. Se trata de eliminar del proceso aquellos elementos que en una implementación concreta ya no aportan valor y empiezan a causar problemas.

En un entorno ERP-first, normalmente importan más:

• la coherencia con el stock del ERP
• la previsibilidad del funcionamiento
• la automatización rápida
• un número reducido de puntos en los que puedan aparecer desviaciones

Si las reservas MSI no se utilizan realmente como un mecanismo real de protección del stock, limpiarlas regularmente suele ser simplemente la solución más práctica.

Cómo abordamos la solución

En este tipo de proyectos no intentamos "arreglar MSI" ni reconstruir el historial de reservas. Eso suele llevar a una complejidad innecesaria. En su lugar, partimos de una pregunta: cuál es el modelo operativo real de la tienda.

Si la tienda funciona con:

• ERP como fuente de verdad
• importación cíclica de stock a Magento
• aceptación de un pequeño retraso entre ERP y la tienda
• sin necesidad de mantener reservas persistentes en Magento

entonces la dirección más razonable es una limpieza controlada, rápida y segura de inventory_reservation.

Qué es importante en este tipo de solución

No basta con simplemente "borrar registros". Una solución así tiene que ser predecible desde el punto de vista operativo.

Por eso prestamos atención a varios elementos:

• posibilidad de ejecutarlo automáticamente con CRON
• posibilidad de ejecutarlo manualmente desde CLI
• bloqueo contra ejecución en paralelo
• modo diagnóstico sin borrar datos
• reindexación opcional después del proceso
• posibilidad de ejecutarlo solo en entornos concretos
• un modelo de rendimiento razonable para tablas grandes

Precisamente a partir de este enfoque nació nuestro módulo.

Kowal Reservation Cleaner para Magento 2

Para proyectos en los que el problema con las reservas MSI reaparecía con frecuencia, preparamos nuestro propio módulo: Kowal Reservation Cleaner para Magento 2.

Creamos esta herramienta pensando en implementaciones ERP-first, donde inventory_reservation debe mantenerse limpio o al menos completamente bajo control.

El módulo no elimina MSI de Magento ni modifica el core. Su tarea es ordenar la capa de reservas de forma que la tienda mantenga:

• coherencia con el modelo de sincronización de stock adoptado
• funcionamiento predecible tras la importación del ERP
• diagnóstico más simple de la disponibilidad
• menor riesgo de salable quantity infravalorado

Cómo funciona nuestro módulo

El módulo soporta tres modos de trabajo principales.

full_reset

Es el modo más simple y, normalmente, el más práctico. Si la limpieza debe abarcar todos los stocks, el módulo utiliza el muy rápido:

TRUNCATE TABLE inventory_reservation

Esto es importante porque, en tiendas grandes y con tablas grandes, un DELETE masivo normal puede resultar innecesariamente pesado.

log_only

Este modo sirve para diagnóstico. No elimina datos, pero permite observar lo rápido que crece la tabla de reservas y si la implementación realmente necesita limpieza automática.

clean_after_erp_sync

Esta variante está pensada para equipos que quieren vincular claramente el momento de limpieza con el horario de importación del ERP. Por ejemplo: el ERP sincroniza el stock a las 02:00 y el módulo limpia las reservas a las 02:10.

Limpieza solo para stocks seleccionados

Esta es una de las funciones que funciona especialmente bien en implementaciones multi-stock más complejas.

No todas las tiendas quieren limpiar toda la tabla inventory_reservation. A veces el problema afecta solo a determinados stocks, canales concretos o a un modelo logístico separado. En esos casos, el módulo permite limitar la limpieza únicamente a los stock_id indicados.

Eso significa que:

• para todos los stocks se puede usar el rapidísimo TRUNCATE
• para stocks seleccionados el módulo cambia a DELETE selectivo

Es un compromiso entre rendimiento y control. En muchas implementaciones, precisamente ese compromiso es el necesario.

CRON, CLI y seguridad del proceso

El módulo puede ejecutarse automáticamente desde Magento CRON o manualmente a través de CLI. Esto es importante porque distintas tiendas tienen distintos modelos de integración.

En la práctica vemos dos escenarios principales:

• limpieza lanzada a una hora concreta desde el planificador de Magento
• limpieza lanzada directamente después de la importación del ERP por un script de integración

El módulo incluye:

• mecanismo de lock
• logging a archivo
• control del tiempo de ejecución
• modo dry-run
• reindexación opcional
• limpieza de caché opcional

Son detalles que en la descripción del producto parecen técnicos, pero en producción deciden si la solución se puede mantener sin estrés.

Qué aporta al negocio

Desde la perspectiva operativa, los beneficios más importantes son muy concretos:

• menos problemas con la disponibilidad de productos
• mejor coherencia entre Magento y ERP
• menos tiempo perdido diagnosticando estados
• un modelo más simple de mantenimiento de MSI en la tienda
• posibilidad de automatizar el proceso sin modificar el core

No es un módulo "para cualquier tienda Magento". Y precisamente esa es su ventaja. Fue diseñado para un tipo concreto de implementación que realmente se enfrenta a este problema.

Cuándo merece la pena considerar este enfoque

Si en tu tienda:

• el stock se sobrescribe regularmente desde ERP
• Magento no debería ser la capa principal de gestión de inventario
• inventory_reservation sigue creciendo y dificulta el análisis
• salable quantity se desvía del stock real
• el equipo necesita un modelo operativo más simple

entonces la limpieza regular de reservas puede ser una dirección razonable.

Por supuesto, no siempre. En tiendas que dependen de la lógica nativa de MSI como mecanismo clave de control de stock, este enfoque no será correcto. Por eso primero hay que entender el modelo de negocio y solo después elegir la solución.

Resumen

El problema con inventory_reservation en Magento 2 normalmente no proviene de que MSI sea "malo". Proviene de que un mecanismo diseñado para un modelo operativo se utiliza en otro, normalmente muy integrado con ERP.

En este tipo de implementaciones, la prioridad no es la complejidad máxima, sino la previsibilidad y la coherencia con el proceso real de almacén. Por eso, en algunas tiendas, la mejor solución no es ampliar la lógica de MSI, sino simplificarla conscientemente.

Si buscas una solución lista para este escenario, echa un vistazo a nuestro módulo: Kowal Reservation Cleaner para Magento 2.

Si primero quieres evaluar si tu tienda realmente tiene este problema, merece la pena empezar analizando el modelo de sincronización de stock, la forma en que se usa MSI y el comportamiento de salable quantity tras la importación desde ERP.

Fuentes

• Página del producto Kowal Reservation Cleaner dla Magento 2: https://kowal.store/kowal-reservation-cleaner-dla-magento-2