Nel corso degli anni, seguendo progetti Magento per merchant che vendono online e in negozio, mi sono ritrovato quasi sempre davanti alla stessa richiesta: “abbiamo tre magazzini e due punti vendita, come facciamo a mostrare la disponibilità giusta sul sito?”. Fino a qualche tempo fa la risposta era una sola: un’estensione di terze parti, con tutto quello che comporta in termini di costi di licenza, dipendenze da mantenere e conflitti a ogni upgrade. Con il Multi-Source Inventory — o MSI — introdotto nativamente in Magento 2.3, quella risposta è cambiata. E vale la pena capire quando conviene davvero usarlo e quando invece no.
Cosa cambia con MSI nativo
Il punto che continuo a ripetere ai team con cui lavoro è semplice: MSI è parte del core di Magento dalla versione 2.3.0, non è più un modulo da comprare. Prima di allora Magento gestiva una sola quantità per SKU, un unico “secchio” di stock. Se avevi più magazzini, dovevi sommare tutto a mano o affidarti a un’estensione che simulasse la multi-sorgente. Oggi il modello è ripensato in profondità e lavora su due concetti che è bene tenere distinti fin dall’inizio: Sources e Stocks.
Sources e Stocks: il modello mentale giusto
Un Source è una posizione fisica in cui hai merce: un magazzino, un punto vendita, un fornitore che spedisce in dropshipping. Per ogni Source registri la quantità reale di ogni SKU. Uno Stock invece è un aggregatore logico: collega uno o più Source a uno o più sales channel (nell’implementazione attuale, i website). È lo Stock che decide quale disponibilità mostrare su un dato sito.
Faccio un esempio anonimizzato. Un merchant fashion con cui ho lavorato aveva due website — Italia e resto Europa — e tre magazzini fisici. Abbiamo modellato tre Source (i magazzini) e due Stock: allo Stock “Italia” abbiamo collegato tutti e tre i Source, allo Stock “Europa” solo due, perché uno dei magazzini non spediva fuori confine. Il risultato è che lo stesso prodotto mostra disponibilità diverse a seconda del canale, senza duplicare i cataloghi. Questo, prima di MSI, richiedeva parecchia acrobazia.
Salable Quantity e reservations: dove si nasconde la logica
Qui c’è il concetto che secondo me viene capito meno e crea più confusione in fase di go-live. In MSI convivono due numeri diversi: la Quantity per Source, cioè la merce fisica, e la Salable Quantity, cioè quanto puoi ancora vendere. Non sono la stessa cosa, ed è giusto così.
Quando un cliente conferma un ordine, Magento non scala subito la quantità di magazzino: crea una reservation, una riga che riduce la Salable Quantity ma lascia intatta la Quantity fisica. Il magazzino viene decrementato solo quando generi la spedizione. In mezzo c’è la finestra in cui l’ordine è confermato ma non ancora spedito, e la reservation serve esattamente a evitare l’oversell in quella finestra. La Salable Quantity, quindi, è la somma delle quantità dei Source collegati allo Stock, meno la soglia di out-of-stock, meno le reservation attive.
Il motivo per cui insisto su questo punto è pratico: quando qualcuno mi scrive “i numeri non tornano dopo una spedizione parziale”, nove volte su dieci il problema è che non ha in mente la differenza tra questi due valori.
Come Magento sceglie da quale magazzino spedire
Alla conferma della spedizione, MSI propone da quale Source prelevare tramite un Source Selection Algorithm. In 2.3.0 l’unico algoritmo disponibile era Priority: ordini i Source per priorità e Magento suggerisce di spedire dal primo che ha abbastanza merce. Dalla 2.3.1 si è aggiunto Distance Priority, che usa distanza geografica (via geo-coordinate o provider di mappe) per proporre il Source più vicino all’indirizzo di consegna. Sono suggerimenti: l’operatore in fase di shipment può sempre correggere a mano. Trovo giusto che sia così, perché nessun algoritmo conosce il magazzino meglio di chi ci lavora dentro.
In-store pickup: il pezzo omnichannel
Chi ha punti vendita fisici mi chiede sempre del ritiro in negozio. La logica dei Source rende questo scenario naturale: un Source può essere marcato come pickup location, e a quel punto il cliente in checkout può scegliere di ritirare in quel punto invece di farsi spedire. Il “compra online, ritira in negozio” smette di essere un progetto custom e diventa configurazione. Attenzione però: il supporto nativo più completo all’in-store pickup è arrivato per gradi e sulla linea Commerce, quindi va verificato caso per caso quale versione stai usando prima di prometterlo al cliente.
Quando conviene MSI e quando no
La mia posizione, dopo averlo messo in produzione su più progetti, è netta: MSI conviene se hai un numero contenuto di sorgenti — indicativamente da poche unità fino a una ventina — e vuoi togliere di mezzo un’estensione. In quella fascia fa il suo lavoro, è mantenuto da Adobe insieme al core e ti risparmia una dipendenza esterna a ogni aggiornamento. Per un merchant con due o tre magazzini e qualche negozio, oggi lo consiglio praticamente sempre.
Dove alzo la mano è sui numeri grossi. Con decine di Source, cataloghi da molte migliaia di SKU e volumi d’ordine alti, MSI mostra il fianco. Non perché sia scritto male, ma perché il modello ha un costo.
I limiti reali che ho visto sul campo
Sarò onesto, perché è la parte che raramente trovi scritta nelle guide entusiaste. Il primo tema è la tabella delle reservation che cresce e non si svuota da sola: su store ad alto volume diventa un punto di attrito e va gestita con manutenzione periodica, altrimenti le query iniziano a rallentare. Il secondo è l’indexer: con molti Source e cataloghi grandi, la reindicizzazione e le performance in admin peggiorano in modo evidente. Il terzo riguarda la logica di split degli ordini quando servi da più magazzini: è più basilare di quanto ci si aspetti, e su fulfillment complessi resta più semplice di un WMS dedicato.
Nessuno di questi limiti mi fa dire “non usatelo”. Mi fanno dire un’altra cosa: MSI è un ottimo strumento di inventory per l’e-commerce, non un sistema di gestione magazzino. Se il tuo problema è mostrare la disponibilità corretta per canale e gestire pickup, è la scelta giusta. Se il tuo problema è orchestrare picking, packing e logistica su scala industriale, MSI è il pezzo che parla con il tuo gestionale, non quello che lo sostituisce.
In sintesi
Il vero cambiamento portato dal Multi-Source Inventory non è tecnico, è di posizionamento: una funzione che prima pagavi a parte oggi è nel core, mantenuta insieme a Magento. Per la maggior parte dei merchant mid-market che seguo questo significa un’estensione in meno da gestire e un modello dati più pulito. Basta usarlo per quello che è, conoscerne i limiti prima di andare in produzione, e disegnare Source e Stock con la testa fin dal primo giorno.
Mini-FAQ
MSI richiede un’estensione a pagamento?
No. Multi-Source Inventory è incluso nativamente nel core di Magento a partire dalla versione 2.3.0.
Qual è la differenza tra Quantity e Salable Quantity?
La Quantity è la merce fisica presente in un Source. La Salable Quantity è quanto puoi ancora vendere: somma dei Source dello Stock, meno la soglia di out-of-stock, meno le reservation attive degli ordini non ancora spediti.
Da quale magazzino spedisce Magento?
Lo suggerisce il Source Selection Algorithm: Priority (per ordine di priorità) dalla 2.3.0, oppure Distance Priority (per vicinanza geografica) dalla 2.3.1. L’operatore può comunque modificare la scelta.
MSI gestisce il ritiro in negozio?
Sì: un Source può essere marcato come pickup location e diventare selezionabile in checkout. Il livello di supporto nativo dipende dalla versione, quindi va verificato.
Fino a quanti magazzini ha senso usarlo?
Funziona bene con poche sorgenti, indicativamente fino a una ventina. Oltre, con cataloghi grandi e volumi alti, emergono limiti su reservation, indexer e split degli ordini.
Fabio Canovi lavora su Magento e Adobe Commerce dal 2011, seguendo progetti e-commerce per merchant mid-market. È tra i primi professionisti in Italia ad aver ottenuto la certificazione Adobe Commerce. Su questo blog racconta, dietro le quinte e senza filtri commerciali, cosa succede davvero nei progetti e cosa significa per chi vende online.