Magento 2, MSI e inventory_reservation dopo l’integrazione con ERP

Magento 2 con MSI può gestire molto bene il magazzino multi-source, le reservation e la salable quantity. Il problema inizia quando questo meccanismo arriva in un’implementazione in cui la vera fonte di verità sullo stock non è Magento, ma un ERP o un WMS esterno. In quel modello la logica delle reservation continua spesso a funzionare dal punto di vista tecnico, ma dal punto di vista business non è più necessaria. Invece di aiutare, inizia a distorcere la disponibilità reale.

Questo è uno di quei problemi che per molto tempo sembrano poco importanti. Lo store funziona, gli ordini arrivano, gli import di stock vanno a buon fine e tuttavia, col tempo, iniziano a emergere domande:

• perché la salable quantity non coincide con lo stock ERP
• perché un prodotto risulta non disponibile se l’ERP lo mostra disponibile
• perché in inventory_reservation ci sono centinaia di migliaia o milioni di record
• perché diagnosticare i problemi di stock in Magento diventa sempre più difficile

Nella pratica, questo è uno scenario molto frequente negli store già maturi dal punto di vista delle integrazioni e operativi secondo un modello ERP-first.

Dove inizia il problema

Nel Magento 2 standard con MSI, i record in inventory_reservation vengono creati quando viene effettuato un ordine e poi compensati da operazioni successive come spedizione o annullamento. In teoria tutto è coerente. In pratica, se lo store sovrascrive regolarmente lo stock dall’ERP, Magento non è più l’unica fonte di verità e non gestisce il magazzino in autonomia.

Questo significa che due logiche iniziano a lavorare in parallelo:

• l’ERP stabilisce la disponibilità reale
• Magento continua a mantenere il proprio layer di reservation

Se questa architettura non è stata semplificata consapevolmente, iniziano a comparire disallineamenti. Non sempre subito, ma col tempo quasi sempre.

Sintomi che vediamo nei progetti

Di solito il problema emerge in una delle seguenti forme.

1. La salable quantity è inferiore allo stock ERP

È il caso più comune. Il team dello store vede che l’ERP mostra disponibilità, mentre Magento continua a bloccare la vendita o riduce il numero di unità acquistabili.

2. La tabella inventory_reservation cresce continuamente

Negli store con volumi d’ordine più alti questa tabella può crescere molto rapidamente. La crescita di per sé non è ancora un errore, ma in un modello ERP-first spesso diventa solo un costo di manutenzione inutile e un altro punto che rende meno chiara la situazione reale del magazzino.

3. Diagnosi più difficile dei problemi di magazzino

Quando la disponibilità di un prodotto dipende contemporaneamente dall’import ERP, dall’indicizzazione di Magento e dalle reservation MSI memorizzate, la diagnosi smette di essere semplice. Il team deve analizzare se il problema si trova nell’import, nell’indice, nello stock, nel source assignment o proprio nella tabella inventory_reservation.

4. Conflitti tra import e logica attuale di Magento

In alcune implementazioni Magento si comporta correttamente secondo le proprie regole, ma non secondo le aspettative del business. È una distinzione importante. Un sistema non deve essere tecnicamente rotto per funzionare in modo scorretto rispetto a un determinato modello operativo.

Perché l’approccio standard non sempre basta

In teoria si potrebbe dire: se Magento ha MSI, basta lasciarlo lavorare. Il problema è che MSI non è stato progettato specificamente per ogni modello di integrazione ERP. In alcune implementazioni è l’architettura ideale. In altre richiede una semplificazione consapevole.

Non si tratta di combattere Magento. Si tratta di rimuovere dal processo quegli elementi che in un determinato progetto non portano più valore e iniziano invece a creare problemi.

In un ambiente ERP-first di solito sono più importanti:

• coerenza con lo stock ERP
• prevedibilità del comportamento
• automazione rapida
• pochi punti in cui possono nascere disallineamenti

Se le reservation MSI non vengono realmente usate come meccanismo di protezione dello stock, la loro pulizia regolare è spesso semplicemente la soluzione più pratica.

Come affrontiamo la soluzione

In progetti di questo tipo non cerchiamo di "riparare MSI" né di ricostruire la storia delle reservation. Questo di solito porta solo a complessità inutile. Invece partiamo da una domanda: qual è il reale modello operativo dello store?

Se lo store funziona con:

• ERP come fonte di verità
• import ciclico dello stock in Magento
• accettazione di un breve ritardo tra ERP e store
• nessuna necessità di mantenere reservation persistenti lato Magento

allora la direzione più sensata è una pulizia controllata, veloce e sicura di inventory_reservation.

Cosa conta in una soluzione di questo tipo

Non basta semplicemente "cancellare record". Una soluzione del genere deve essere prevedibile dal punto di vista operativo.

Per questo prestiamo attenzione a diversi elementi:

• possibilità di esecuzione automatica via CRON
• possibilità di esecuzione manuale via CLI
• blocco contro esecuzioni parallele
• modalità diagnostica senza cancellare i dati
• reindicizzazione opzionale dopo il processo
• possibilità di esecuzione solo in ambienti specifici
• un modello di performance sensato per tabelle grandi

È proprio da questo approccio che è nato il nostro modulo.

Kowal Reservation Cleaner per Magento 2

Per i progetti in cui il problema delle reservation MSI tornava regolarmente, abbiamo preparato il nostro modulo: Kowal Reservation Cleaner per Magento 2.

Abbiamo creato questo strumento pensando alle implementazioni ERP-first, dove inventory_reservation deve rimanere pulita o almeno completamente sotto controllo.

Il modulo non rimuove MSI da Magento e non modifica il core. Il suo compito è ordinare il layer delle reservation in modo che lo store mantenga:

• coerenza con il modello di sincronizzazione stock adottato
• comportamento prevedibile dopo l’import ERP
• diagnosi più semplice della disponibilità
• minor rischio di salable quantity sottostimata

Come funziona il nostro modulo

Il modulo supporta tre modalità operative principali.

full_reset

È la modalità più semplice e di solito anche la più pratica. Se la pulizia deve coprire tutti gli stock, il modulo utilizza il rapidissimo:

TRUNCATE TABLE inventory_reservation

Questo è importante perché, in store grandi e con tabelle molto grandi, un normale DELETE massivo può essere inutilmente pesante.

log_only

Questa modalità serve per la diagnostica. Non rimuove i dati, ma permette di osservare quanto rapidamente cresce la tabella delle reservation e se l’implementazione richiede davvero una pulizia automatica.

clean_after_erp_sync

Questa variante è pensata per i team che vogliono collegare chiaramente il momento della pulizia al calendario di import dell’ERP. Ad esempio: l’ERP sincronizza lo stock alle 02:00 e il modulo pulisce le reservation alle 02:10.

Pulizia solo per stock selezionati

Questa è una delle funzioni che si adatta particolarmente bene alle implementazioni multi-stock più complesse.

Non tutti gli store vogliono pulire l’intera tabella inventory_reservation. A volte il problema riguarda solo alcuni stock, canali specifici o un modello logistico separato. In questi casi il modulo permette di limitare la pulizia solo agli stock_id indicati.

Questo significa che:

• per tutti gli stock si può usare il velocissimo TRUNCATE
• per stock selezionati il modulo passa al DELETE selettivo

È un compromesso tra performance e controllo. In molte implementazioni è proprio il compromesso necessario.

CRON, CLI e sicurezza del processo

Il modulo può essere eseguito automaticamente da Magento CRON oppure manualmente tramite CLI. Questo è importante perché store diversi hanno modelli di integrazione diversi.

Nella pratica incontriamo soprattutto due scenari:

• pulizia avviata a un’ora specifica dal planner di Magento
• pulizia avviata direttamente dopo l’import ERP da uno script di integrazione

Il modulo include:

• meccanismo di lock
• logging su file
• controllo del tempo di esecuzione
• modalità dry-run
• reindicizzazione opzionale
• cache clean opzionale

Sono dettagli che in una scheda prodotto sembrano tecnici, ma in produzione determinano se la soluzione è davvero gestibile senza stress.

Cosa porta a livello business

Dal punto di vista operativo, i vantaggi principali sono molto concreti:

• meno problemi di disponibilità prodotto
• migliore coerenza tra Magento e ERP
• meno tempo perso nella diagnosi degli stock
• un modello più semplice per la gestione di MSI nello store
• possibilità di automatizzare il processo senza modificare il core

Non è un modulo "per tutti gli store Magento". Ed è proprio questo il suo vantaggio. È stato progettato per un tipo specifico di implementazione che affronta davvero questo problema.

Quando vale la pena considerare questa soluzione

Se nel tuo store:

• lo stock viene regolarmente sovrascritto dall’ERP
• Magento non dovrebbe essere il livello principale di gestione delle giacenze
• inventory_reservation continua a crescere e complica l’analisi
• la salable quantity diverge dallo stock reale
• il team ha bisogno di un modello operativo più semplice

allora la pulizia regolare delle reservation può essere una direzione sensata.

Naturalmente non sempre. Negli store che si basano sulla logica nativa MSI come meccanismo chiave di controllo stock, questo approccio non sarà corretto. Per questo prima bisogna capire il modello di business e solo dopo scegliere la soluzione.

Riepilogo

Il problema di inventory_reservation in Magento 2 di solito non nasce dal fatto che MSI sia "sbagliato". Nasce dal fatto che un meccanismo progettato per un modello operativo viene utilizzato in un altro modello, molto spesso fortemente integrato con ERP.

In implementazioni di questo tipo la priorità non è la massima complessità, ma la prevedibilità e la coerenza con il processo reale di magazzino. Per questo, in alcuni store, la soluzione migliore non è ampliare la logica MSI, ma semplificarla consapevolmente.

Se cerchi una soluzione pronta per questo scenario, dai un’occhiata al nostro modulo: Kowal Reservation Cleaner per Magento 2.

Se invece vuoi prima valutare se il tuo store ha davvero questo problema, vale la pena iniziare dall’analisi del modello di sincronizzazione dello stock, del modo in cui viene usato MSI e del comportamento della salable quantity dopo l’import ERP.

Fonti

• Pagina prodotto Kowal Reservation Cleaner dla Magento 2: https://kowal.store/kowal-reservation-cleaner-dla-magento-2