Integrazione WMS per le piccole attività di e-commerce
La domanda su quando valga la pena integrare un sistema di gestione del magazzino si pone prima di quanto molte piccole attività di e-commerce si aspettino. I fogli di calcolo funzionano bene finché non bastano più, e il punto di svolta di solito non è il volume degli ordini, ma la loro complessità: più SKU con tracciamento delle varianti, pacchetti di prodotti, ordini in attesa di disponibilità su più sedi di evasione o la necessità di dati precisi sulla disponibilità promettibile al checkout. Questo articolo racconta la nostra esperienza nell’integrare GreaterWMS con una piccola attività di e-commerce: cosa ha funzionato, cosa ha richiesto più progettazione del previsto e in quali casi i fogli di calcolo restano la scelta giusta.
Perché GreaterWMS
GreaterWMS è un sistema di gestione del magazzino open source con un’API REST, un backend Django e un frontend Vue. Supporta la gestione delle scorte su più magazzini, la tracciabilità dei lotti, la gestione degli ordini in entrata e in uscita e una reportistica di base. Il codice viene mantenuto attivamente e la documentazione API, pur non essendo esaustiva, copre le operazioni principali.
Lo abbiamo scelto al posto di alternative ospitate da terzi per due motivi. Primo, gestivamo già un’infrastruttura propria e non volevamo aggiungere un’altra dipendenza SaaS con prezzi per ordine al crescere dei volumi. Secondo, la natura open source ci permetteva di estendere il modello dati senza attendere il ciclo di gestione delle richieste di funzionalità del fornitore. Per una piccola attività con esigenze specifiche di tracciamento delle scadenze dei lotti, questa flessibilità era importante.
La nostra distribuzione usa uno stack Docker Compose con l’applicazione Django, PostgreSQL e Redis; il file Compose del progetto originale include solo i container frontend e backend e le impostazioni predefinite usano SQLite. Su un VPS modesto funziona senza difficoltà insieme ad altri servizi. La configurazione iniziale richiede qualche ora; il lavoro di integrazione richiede molto più tempo.
Modelli di integrazione API
GreaterWMS usa l’autenticazione basata su token. Ogni utente ha un token (il valore openid), che passi in un header di richiesta personalizzato token anziché come token Bearer nell’header Authorization. Non sono integrati né un flusso OAuth né un meccanismo di rotazione delle chiavi API: conviene quindi creare un utente di servizio dedicato con autorizzazioni minime, anziché usare un account amministratore.
L’API è prevalentemente RESTful, con payload JSON. Le risorse principali con cui interagisci per un’integrazione e-commerce sono: goods, il catalogo prodotti nella terminologia WMS; inventory, i livelli attuali delle scorte per magazzino e prodotto; gli ordini in entrata, cioè ordini di acquisto e resi; e gli ordini in uscita, cioè ordini dei clienti da evadere.
Abbiamo stabilito presto una regola: non chiamare mai l’API WMS in modo sincrono dal percorso di checkout. Il WMS non fa parte del percorso critico della transazione e, se è lento o temporaneamente indisponibile, non dovrebbe impedire al cliente di completare un acquisto. Tutte le interazioni con il WMS passano attraverso una coda asincrona. Il checkout registra l’ordine nel database principale e pubblica un evento. Un processo in background preleva l’evento e crea l’ordine in uscita in GreaterWMS. In caso di errore, riprova con tempi di attesa crescenti in modo esponenziale e genera un avviso se l’errore persiste. Questo disaccoppiamento è indispensabile.
Sincronizzazione degli ordini
La chiamata di creazione di un ordine in uscita riceve un ID goods, una quantità e le informazioni sull’indirizzo di destinazione. La corrispondenza tra le righe d’ordine dell’e-commerce e gli ID goods del WMS deve essere mantenuta esplicitamente. Memorizziamo l’ID goods del WMS come campo aggiuntivo su ogni variante di prodotto nel database del catalogo. Questa corrispondenza viene impostata manualmente alla creazione di un nuovo prodotto e verificata dal processo di sincronizzazione prima di inviare la richiesta di creazione dell’ordine in uscita.
La sincronizzazione degli stati procede nella direzione opposta: GreaterWMS aggiorna lo stato dell’ordine in uscita man mano che il magazzino lo elabora e il sistema e-commerce deve riflettere questi aggiornamenti. GreaterWMS non invia automaticamente le modifiche di stato: devi interrogarlo periodicamente. Eseguiamo ogni pochi minuti un’attività che interroga gli ordini in uscita con stato «in progress» e verifica se sono passati a «dispatched» o «cancelled». In tal caso, aggiorniamo l’ordine corrispondente nel database e-commerce e attiviamo le azioni successive, come le email di notifica al cliente e gli aggiornamenti del numero di tracciamento.
L’idempotenza nella creazione degli ordini in uscita è importante. Se il processo in background riprova dopo un errore transitorio, non deve creare ordini duplicati in GreaterWMS. Memorizziamo l’ID dell’ordine in uscita del WMS nel nostro record interno subito dopo una chiamata di creazione riuscita. Al nuovo tentativo, il processo controlla se esiste già un ID WMS prima di effettuare la chiamata. Se esiste, salta la creazione e prosegue con l’azione successiva che stava tentando di eseguire. Questo controllo non copre una chiamata di creazione che riesce in GreaterWMS ma la cui risposta va persa prima che l’ID venga memorizzato; in questi casi è comunque necessario un confronto con il WMS prima di riprovare.
Aggiornamento delle scorte
Mantenere sincronizzate con il WMS le quantità delle scorte dell’e-commerce è la parte che richiede più attenzione continuativa. Le direzioni sono due: la piattaforma e-commerce ha bisogno di livelli accurati delle scorte per evitare vendite oltre la disponibilità, mentre il WMS deve riflettere acquisti e resi che hanno origine al di fuori di esso.
Per leggere i livelli delle scorte, recuperiamo periodicamente istantanee dall’API inventory di GreaterWMS e scriviamo i valori in una cache Redis letta dal negozio online. L’intervallo di interrogazione dipende dalla velocità delle vendite. Per prodotti a bassa rotazione, una volta all’ora va bene. Per prodotti venduti in picchi, serve un intervallo più breve oppure un modello di prenotazione, in cui l’inserimento di un articolo nel carrello riserva temporaneamente le scorte, indipendentemente dal ciclo di sincronizzazione del WMS.
I resi sono il caso più complesso. Un articolo restituito può rientrare nelle scorte, passare in un’area di quarantena per l’ispezione o essere scartato. GreaterWMS prevede un flusso di ordini in entrata per i resi, ma la corrispondenza tra gli stati dei resi nell’e-commerce e gli stati degli ordini in entrata nel WMS va progettata esplicitamente. Abbiamo creato una macchina a stati che traduce i codici dei motivi di reso del sistema e-commerce nei codici di destinazione del WMS. Rivediamo questa corrispondenza con il team di magazzino ogni volta che viene aggiunto un nuovo motivo di reso. Senza questa mappatura, le scorte restituite non ricompaiono tra quelle disponibili, senza alcuna segnalazione.
Condizioni di competizione e scorta di riserva
Anche con una sincronizzazione delle scorte basata su interrogazioni periodiche possono verificarsi condizioni di competizione. Se due ordini arrivano contemporaneamente ed entrambi leggono lo stesso livello delle scorte nella cache prima che uno dei due sia registrato nel WMS, puoi vendere oltre la disponibilità per un numero di unità pari a quelle vendute nell’intervallo di interrogazione. Per i prodotti per cui questo è inaccettabile, come articoli in edizione limitata o deperibili con vincoli rigorosi sui lotti, la soluzione corretta è un livello di prenotazione che riduce la quantità disponibile locale al checkout e la riconcilia con il WMS in modo asincrono.
Una mitigazione più semplice è la scorta di riserva: mantieni nel database e-commerce una quantità disponibile pari al livello delle scorte del WMS meno una piccola riserva. Gli ordini consumano questo margine. Quando il margine raggiunge zero, il prodotto risulta esaurito anche se il WMS mostra ancora unità disponibili. Questo comporta un piccolo rischio di trattenere scorte che i clienti non possono ordinare, ma riduce il rischio di vendere oltre la disponibilità e non richiede una logica di prenotazione. Per la maggior parte delle piccole attività, è il compromesso giusto.
Quando conviene un WMS e quando bastano i fogli di calcolo
Un sistema di gestione del magazzino aggiunge complessità di integrazione, oneri operativi e un nuovo sistema da mantenere. Prima di impegnarti in un’integrazione, valuta con onestà se i problemi che vuoi risolvere richiedano davvero un WMS.
I fogli di calcolo bastano quando il numero di SKU è ridotto e stabile, hai un solo magazzino o una sola sede di evasione, gli ordini vengono elaborati manualmente e i volumi sono bassi, e non ti serve la disponibilità promettibile in tempo reale al checkout. In questo caso, costruire e mantenere l’integrazione WMS costa più dei problemi che risolve.
Un WMS comincia a ripagarsi quando hai più magazzini o punti di prelievo, ti serve la tracciabilità dei lotti per ragioni di conformità o qualità, il tasso di reso è abbastanza alto da richiedere una gestione sistematica della destinazione dei resi, oppure l’elaborazione degli ordini è automatizzata e richiede una prenotazione accurata delle scorte per evitare vendite oltre la disponibilità. Sono problemi operativi che i fogli di calcolo non possono risolvere con un livello ragionevole di rigore.
Il lavoro di integrazione descritto in questo articolo ha richiesto diverse settimane di sviluppo, test inclusi. Quel tempo avrebbe potuto finanziare una quantità significativa di lavoro manuale di coordinamento del magazzino. Prima di iniziare, definisci con precisione quali problemi stai risolvendo e se il software sia lo strumento giusto.