Flusso degli stati degli ordini in PrestaShop: personalizzazione e automazione

Ecco la parte di PrestaShop che fa girare in silenzio tutto il tuo back office e che quasi nessuno configura davvero con metodo: lo stato dell'ordine. Ogni ordine si trova sempre in un unico stato, e quel singolo valore decide che cosa vede il cliente nel suo account, se lo stock è stato scalato, se esiste una fattura e quale email è appena arrivata nella sua casella. Lascia invariati gli stati predefiniti e un negozio trafficato finisce per procedere a tentoni. Modella invece gli stati sul modo in cui evadi davvero gli ordini, e lo stesso back office comincia a dire al tuo team qual è il prossimo passo — e ai tuoi clienti che cosa sta succedendo, prima ancora che ti scrivano per chiederlo. Questa guida spiega come arrivarci nello specifico in PrestaShop: che cosa attiva davvero ogni stato predefinito, come crearne di tuoi in Parametri negozio → Stati, che cosa c'è sotto nella tabella ps_order_state e come automatizzare le transizioni, così le persone del tuo team smettono di fare da trigger di database con il battito cardiaco.

Ultimo aggiornamento: giugno 2026.

Che cos'è davvero uno stato ordine in PrestaShop

In PrestaShop uno stato ordine non è soltanto un'etichetta. Ogni stato è una riga nella tabella ps_order_state (con il nome traducibile in ps_order_state_lang), e quella riga contiene una serie di flag booleani che dicono al core che cosa fare quando un ordine entra in quello stato: generare o meno una fattura, segnare l'ordine come pagato, marcarlo come spedito, rendere disponibile il PDF della consegna, inviare un'email. (La riduzione dello stock non è uno di questi flag: PrestaShop riduce lo stock disponibile quando l'ordine viene convalidato/creato, non quando scatta il flag di uno stato; ci torniamo più sotto.) Lo stato corrente dell'ordine si trova in ps_orders.current_state; oltre a questo, PrestaShop scrive una nuova riga in ps_order_history ogni volta che lo stato cambia, quindi l'ordine mantiene anche una traccia completa, con data e ora, di tutti gli stati attraversati. Lo "stato corrente" che vedi nell'amministrazione è il valore in current_state, mentre ps_order_history registra come ci è arrivato.

La conseguenza pratica per il titolare di un negozio: l'elenco degli stati è il luogo in cui vive la tua logica operativa. Imposti bene i flag una volta sola e PrestaShop li applica a ogni ordine, per sempre: nessun membro dello staff deve ricordarsi che "generiamo la fattura quando il pagamento è confermato, non prima". Impostali male, e puoi ritrovarti a generare in silenzio fatture per ordini che nessuno ha pagato. Più sotto torniamo anche su questa mina.

Gli stati ordine predefiniti — e che cosa attiva davvero ciascuno

PrestaShop viene fornito con un insieme predefinito di stati. Molti commercianti li trattano come semplice decorazione; in realtà ciascuno attiva azioni concrete nel database nel momento esatto in cui un ordine vi entra. Ecco che cosa succede davvero sotto il cofano.

In attesa di pagamento con assegno

Applicato quando un cliente sceglie il pagamento con assegno al momento dell'ordine. L'ordine esiste, ma il denaro non è ancora arrivato. L'ordine viene convalidato al momento dell'inserimento, quindi lo stock disponibile viene gestito in quel momento secondo le tue impostazioni di magazzino — non viene "riservato" separatamente da questo stato — non viene generata alcuna fattura e l'ordine resta qui finché non confermi manualmente che l'assegno è stato incassato. Nulla procede da solo: è voluto.

In attesa di bonifico bancario

L'equivalente per il bonifico bancario. Al cliente vengono mostrati IBAN/BIC e riferimento dell'ordine, lo stock disponibile viene gestito alla convalida dell'ordine in base alle tue impostazioni di magazzino, e l'ordine resta parcheggiato qui finché non lo contrassegni come pagato — di solito uno-tre giorni lavorativi dopo, quando il bonifico arriva. È lo stato che più vale la pena automatizzare (ne parliamo nella sezione sull'automazione), perché confermare i bonifici a mano è pura amministrazione ripetitiva.

Pagamento accettato

Questo è lo stato decisivo. Quando un ordine raggiunge Pagamento accettato, PrestaShop:

• Genera la fattura (se lo stato ha il flag fattura attivo — per impostazione predefinita ce l'ha);
• Segna l'ordine come pagato nel database;
• Invia al cliente l'email relativa allo stato.

Nota che cosa questo stato non fa: non scala lo stock. Lo stock disponibile viene ridotto quando l'ordine viene creato/convalidato alla finalizzazione dell'ordine — cosa che accade anche per gli ordini che restano in In attesa di pagamento — quindi il movimento di magazzino di solito è già avvenuto prima ancora che l'ordine raggiunga Pagamento accettato.

Per i pagamenti tramite gateway — PayPal, Stripe, Mollie — il modulo di pagamento imposta automaticamente questo stato nel momento in cui il gateway conferma l'addebito. Tu non devi toccarlo. Quella transizione automatica, guidata dal codice, è esattamente il comportamento che vuoi replicare per i tuoi metodi di pagamento manuali.

Elaborazione in corso / Preparazione in corso

Uno stato intermedio facoltativo che dice "il magazzino sta prelevando e imballando". Non attiva azioni automatiche: tutto il suo valore sta nel coordinamento umano. Alcuni negozi lo saltano; quelli ad alto volume lo trovano indispensabile per distinguere a colpo d'occhio la coda degli imballatori dalla coda degli ordini non pagati.

Spedito

Applicato quando il pacco lascia il tuo magazzino. Attiva un'email di conferma spedizione (con il numero di tracciamento, se presente) e rende disponibile la bolla di consegna. La sequenza conta: inserisci il numero di tracciamento nella sezione Corrieri dell'ordine prima di passare lo stato a Spedito, altrimenti l'email parte senza il link di tracciamento e ricevi comunque il messaggio "dov'è il mio pacco?".

Consegnato

Indica che il cliente ha ricevuto la merce: impostato manualmente o da un'integrazione API con il corriere. Nell'UE è il momento da cui parte la finestra di 14 giorni per il reso nelle vendite a distanza, quindi date di consegna accurate non sono un dettaglio estetico: sono l'orologio su cui si basa la tua politica di reso.

Annullato

L'annullamento di un ordine può reincrementare lo stock disponibile dei prodotti dell'ordine (attraverso il normale comportamento di gestione magazzino di PrestaShop, dato che lo stock era già stato decrementato al momento dell'ordine) e il cliente riceve un'email di annullamento. Due cose che non fa automaticamente: rimborsare il denaro (lo gestisci separatamente) ed eliminare eventuali fatture già generate. Se esiste una fattura, emetti una nota di credito invece di fingere che la fattura non sia mai esistita: il tuo commercialista ti ringrazierà.

Rimborsato

Applicato dopo l'elaborazione di un rimborso. Una nota di credito non viene creata soltanto applicando questa etichetta di stato: viene generata tramite il flusso di rimborso (il pannello Rimborso standard / Rimborso parziale / Reso prodotti) quando selezioni l'opzione per generarla. Anche il rientro degli articoli nello stock vendibile dipende da come hai gestito il rimborso in quel pannello.

Errore di pagamento

Impostato quando un tentativo di pagamento fallisce: carta rifiutata, fondi insufficienti, passaggio 3-D Secure non riuscito. Non viene scalato stock, non viene generata fattura. Se il cliente viene informato oppure no dipende interamente dal modulo di pagamento.

In riassortimento (pagato / non pagato)

Per i negozi che accettano ordini che non possono ancora spedire. L'ordine viene acquisito, ma l'evasione aspetta il riassortimento. Le varianti "pagato" e "non pagato" ti permettono di mantenere corretto lo stato del pagamento mentre la merce è in arrivo da te.

Leggere gli stati nel database

Non avrai mai bisogno di toccare SQL per gestire un negozio, ma conoscere la forma dei dati rende sensate le schermate di amministrazione — ed è ciò a cui si aggancia qualsiasi automazione. Le tre tabelle che contano:

Poiché ogni cambio di stato aggiunge una nuova riga in ps_order_history (oltre ad aggiornare current_state sull'ordine), la cronologia non è mai una sovrascrittura distruttiva: è una traccia di audit. È per questo che puoi sempre vedere dove è passato un ordine, ed è anche il motivo per cui un aggiornamento SQL di massa fatto con leggerezza sugli stati ordine è pericoloso: scrivendo direttamente nelle tabelle salti ogni flag, email e movimento di magazzino che normalmente il core attiverebbe. Il modo supportato per spostare un ordine via codice passa dall'oggetto ordine, non da UPDATE grezzi. Nella sezione per sviluppatori vediamo gli hook giusti.

Creare stati ordine personalizzati

Vai in Parametri negozio → Stati (in PrestaShop 1.6 si trovava sotto Ordini → Stati). Clicca su Aggiungi nuovo stato ordine e stai configurando dall'interfaccia una di quelle righe di ps_order_state. I campi che contano:

• Nome dello stato: ciò che il tuo team legge nell'elenco ordini. "In attesa del fornitore" batte "Stato 7" ogni volta: la chiarezza qui elimina un'intera categoria di domande del tipo "che cosa significa questo?".
• Icona e colore: il segnale visivo nell'elenco ordini. Scegli una convenzione e mantienila: verde per tutto ok, arancione per in sospeso, rosso per problemi. Un commerciante dovrebbe poter triagiare l'elenco ordini per colore anche dall'altra parte della stanza.
• Flag di comportamento — questo è il vero motore:
  • Considera l'ordine associato come convalidato: conteggia l'ordine nelle statistiche di vendita.
  • Consenti al cliente di scaricare e visualizzare le versioni PDF delle fatture: controlla la visibilità della fattura nell'account del cliente.
  • Imposta l'ordine come pagato: comunica al resto di PrestaShop che il denaro è stato ricevuto.
  • Mostra PDF consegna / Imposta l'ordine come spedito: segna la merce come uscita e rende disponibile la bolla di consegna.
  • Genera fattura: crea il PDF della fattura in questa transizione.
  • Invia un'email al cliente quando lo stato dell'ordine cambia: il trigger che trasforma uno stato in una notifica al cliente.
• Template email: quale messaggio viene inviato quando il flag email è attivo.

Il "quindi?" di quei flag: sono la differenza tra uno stato che è solo un colore e uno che gestisce in silenzio la tua contabilità. Impostali con criterio e PrestaShop farà la cosa giusta su ogni ordine futuro, senza che nessuno debba sorvegliarlo.

Gli stati personalizzati che vediamo più spesso

Lavorando ogni giorno con negozi PrestaShop, questi sono gli stati personalizzati che si guadagnano il loro posto:

• In attesa del fornitore: pagato, ma un articolo deve essere ordinato. Nessuna email al cliente: è un flag interno, non una notizia che il cliente deve ricevere.
• Pronto per il ritiro: per il ritiro in negozio. Email attiva, con indirizzo, orari e cosa portare.
• Spedito parzialmente: alcuni articoli sono partiti, altri devono ancora arrivare. Scrivi al cliente che cosa è stato spedito e che cosa resta in sospeso.
• In verifica: ordini di valore elevato o segnalati come potenzialmente fraudolenti, messi in attesa per un controllo manuale. Nessuna email al cliente.
• In attesa di risposta dal cliente: lo hai contattato (correzione indirizzo, domanda sul prodotto) e l'ordine è sospeso finché non risponde.
• Reso richiesto / Reso ricevuto: le due metà di una RMA: il cliente ha fatto richiesta e, in seguito, il pacco è tornato da te per l'ispezione.

Trigger email per ogni stato

Quando uno stato ha il flag email attivo, PrestaShop invia al cliente il template associato a quello stato. I template si trovano in /mails/LANGUAGE_CODE/ come coppie di file HTML e TXT (la versione in testo semplice è il ripiego per i client che bloccano l'HTML, quindi devono esistere entrambe).

Collegare un'email a uno stato personalizzato

Attiva l'email per uno stato personalizzato e diventi responsabile del template: se manca, l'invio fallisce in silenzio nei log. Per collegarlo correttamente:

• Crea i file HTML e TXT corrispondenti in ogni cartella lingua sotto /mails/: il nome del template deve corrispondere a quello atteso dallo stato.
• Riutilizza i segnaposto delle variabili che il core espone già: {firstname}, {lastname}, {order_name}, {id_order}, {shipping_number} per il tracciamento, e gli altri.
• Definisci l'aspetto una volta sola in Design → Tema email, invece di modificare ogni file a mano.

Se preferisci non scrivere template, il caso davvero comune è semplicemente reinviare un'email d'ordine che il cliente ha perso. PrestaShop può reinviare la conferma esistente direttamente dalla pagina dell'ordine: spieghiamo esattamente dove si trova quel pulsante in come reinviare un'email di conferma ordine.

Inviare le email giuste, non tutte

• Non esagerare con le email. I clienti non vogliono un messaggio per ogni passaggio interno. "Preparazione in corso" serve al tuo team, non alla loro casella di posta. Riserva le email ai momenti che contano davvero per loro: pagamento confermato, spedito (con tracciamento), consegnato.
• Rendi ogni email azionabile. L'email di spedizione contiene numero e link di tracciamento; quella per il ritiro contiene indirizzo, orari e cosa portare. Un'email senza un prossimo passo genera soltanto una risposta.
• Imposta le aspettative. In caso di riassortimento, comunica l'attesa. Un vago "lo stato del tuo ordine è cambiato" senza dettagli è un ticket di assistenza pronto a nascere.

Automatizzare i cambi di stato

Gestire gli stati a mano va bene con dieci o venti ordini al giorno. Oltre quella soglia, ogni transizione manuale è tempo che paghi e un'occasione per dimenticare un passaggio. Le opportunità, in ordine approssimativo di ritorno:

Conferma del pagamento

I gateway per carte lo automatizzano già: PayPal, Stripe e Mollie portano l'ordine a Pagamento accettato alla conferma, senza intervento umano. Il vuoto riguarda bonifici e assegni, dove resti con la conferma manuale, un'integrazione con il flusso bancario che abbina i bonifici in entrata agli ordini tramite riferimento, oppure un controllo pianificato su un webhook del gateway. Chiudere quel vuoto è spesso il più grande risparmio di tempo dell'intero flusso ordine.

Spedizione

Un modulo di integrazione con il corriere (Colissimo, DHL, Mondial Relay e simili) dovrebbe passare l'ordine a Spedito e scrivere il numero di tracciamento nel momento in cui stampi l'etichetta. Se il tuo non lo fa, quasi sempre l'impostazione per abilitarlo esiste nel modulo: è solo disattivata per impostazione predefinita.

Conferma di consegna

Le API dei corrieri possono comunicare la consegna. Un'attività pianificata che interroga ogni giorno l'API e sposta i pacchi confermati su Consegnato mantiene corretto quell'orologio UE dei resi senza che nessuno controlli le pagine di tracciamento. Questo è il terreno classico dei cron job: lo imposti una volta e lo lasci lavorare mentre dormi.

Automazione del flusso basata su regole

Per la logica "se questo, allora quello" che il core non copre — se il metodo di pagamento è bonifico bancario e il totale supera 500 EUR, imposta In verifica e avvisa l'amministratore — serve un'automazione degli stati basata su regole, non codice personalizzato che si rompe al prossimo aggiornamento. È il tipo di flusso condizionale per cui il nostro team crea moduli su mypresta.rocks: definisci condizioni e azioni dal back office, e PrestaShop instrada ogni ordine sul percorso giusto da solo. Il vantaggio non è "automazione" come parola alla moda: è che il collo di bottiglia smette di essere una persona che deve trovarsi alla scrivania.

Hook degli stati ordine per sviluppatori

Se costruisci tu l'automazione, PrestaShop attiva hook attorno a ogni cambio di stato, così non devi mai scrivere direttamente nelle tabelle:

• actionOrderStatusUpdate: scatta mentre viene applicato un cambio di stato. È un hook di tipo notifica, quindi trattalo come il punto in cui eseguire le tue validazioni e la logica del modulo attorno a una transizione, non come un modo garantito e supportato dal core per bloccarla in modo pulito.
• actionOrderStatusPostUpdate: scatta dopo il commit della modifica: il posto giusto per lavori successivi, come sincronizzare l'ordine con un ERP o una piattaforma di spedizione.
• actionOrderHistoryAddAfter: scatta dopo la scrittura di una nuova riga in ps_order_history: utile per i tuoi log e le tue tracce di audit.

Uno schema tipico: al passaggio a Spedito, invii un webhook all'API del partner logistico; al passaggio a Consegnato, metti in coda un'email di richiesta recensione per sette giorni dopo. Poiché sposti l'ordine attraverso il suo oggetto e ascolti questi hook, ogni flag, email e movimento di magazzino gestito dal core continua ad attivarsi correttamente: è esattamente il motivo per cui usi gli hook invece di un UPDATE SQL grezzo su ps_order_state.

Modificare e correggere gli ordini lungo il percorso

Gli stati descrivono dove si trova un ordine; altrettanto spesso devi cambiare che cosa c'è dentro: correggere una quantità, sostituire un indirizzo, applicare uno sconto a posteriori. PrestaShop ti permette di modificare un ordine già inserito dalla sua pagina dettaglio, con limiti concreti dopo che esiste una fattura. La guida completa su che cosa è sicuro cambiare e quando si trova in come modificare un ordine dopo che è stato inserito; il lavoro quotidiano più ampio sull'elenco ordini — filtri, azioni massive, stati nel contesto — è trattato nella nostra guida completa alla gestione degli ordini in PrestaShop.

Gestire le spedizioni parziali

Le spedizioni parziali sono il flusso più difficile tra quelli che i valori predefiniti di PrestaShop riescono a gestire. Il core dà silenziosamente per scontato che un ordine equivalga a una spedizione: il supporto nativo alle spedizioni parziali è limitato, e le bolle di consegna sono documenti a livello di ordine — PrestaShop non modella in modo pulito, di default, spedizioni parziali a livello di singolo articolo. Un approccio manuale praticabile è questo:

• Crea uno stato personalizzato Spedito parzialmente;
• Registra il numero di tracciamento per gli articoli che partono ora;
• Quando il resto è pronto, spediscilo con un nuovo numero di tracciamento;
• Passa a Spedito solo quando tutto è uscito.

Il punto di attrito: la pagina dettaglio ordine predefinita non tiene traccia nativamente di quali articoli sono finiti in quale pacco, e generare un documento di consegna per singola spedizione, solo per gli articoli contenuti in quel pacco, non è un'operazione nativa. I negozi che dividono regolarmente gli ordini hanno bisogno di un flusso personalizzato o di un modulo per gestire davvero tracciamento e documenti per articolo sopra il core; altrimenti la cronologia dell'ordine ti dice che qualcosa è stato spedito, ma non che cosa.

Flussi ordine B2B

L'evasione B2B non segue il percorso B2C, e l'elenco degli stati è il punto in cui codifichi la differenza:

• Preventivo e approvazione: ordini che richiedono approvazione prima del pagamento, modellati come "Preventivo inviato" → "Preventivo approvato" → "In attesa di pagamento" → "Pagamento accettato".
• Ordini d'acquisto: condizioni a 30/60/90 giorni significano che evasione e incasso viaggiano su due orologi separati; i tuoi stati devono tracciare entrambi senza confonderli.
• Spedizioni parziali: gli ordini B2B multi-articolo con tempi di approvvigionamento diversi si appoggiano di routine alla configurazione delle spedizioni parziali descritta sopra, non come eccezione.
• Applicazione dell'ordine minimo: gli ordini sotto soglia possono passare da "In verifica" prima che qualcuno li prepari.

Reportistica sui tuoi stati

Poiché ogni transizione è una riga con data e ora in ps_order_history, i dati sugli stati sono la tua reportistica operativa — gratis, se li guardi:

• Tempo in ogni stato: quanto a lungo gli ordini restano in Pagamento accettato prima di Spedito è, letteralmente, la tua velocità di evasione.
• Distribuzione degli stati: un cumulo crescente in "In attesa del fornitore" è un problema di approvvigionamento che si manifesta prima che il fornitore lo ammetta.
• Annullamenti per fase: se gli ordini si fermano in modo sproporzionato in uno stato, quella fase del processo ha una perdita.
• Ciclo di vita completo: dall'inserimento alla consegna, seguito nel tempo, ti dice se stai diventando più veloce o se stai rallentando senza accorgertene.

Errori comuni da evitare

• Troppi stati. Superata una dozzina circa, nessuno li ricorda e l'elenco smette di aiutare nella triage. Se il tuo team non riesce a recitarli, ne hai troppi.
• Nomi poco chiari. "Stato A" e "Stato B" non dicono niente a nessuno. Chiamali per ciò che significano.
• Uno stato personalizzato con email attiva ma senza template. È il caso di fallimento silenzioso: l'invio muore nei log e il cliente non riceve nulla.
• Personale non formato. Il flusso più pulito è inutile se il team non sa quando applicare ogni stato. Una scheda di riferimento di una pagina si ripaga da sola.
• La mina del flag fattura. Attiva Genera fattura per uno stato che non conferma il pagamento e comincerai a sfornare fatture per ordini che nessuno ha pagato: un vero caos contabile e fiscale da sistemare. Ricontrolla quel flag prima di salvare.

Una nota sugli ordini di prova

Mentre configuri tutto questo, inserirai ordini di prova per vedere stati ed email attivarsi — e ognuno di essi sporca le tue statistiche, la sequenza delle fatture e ps_order_history se lo lasci lì. Eliminali prima di andare online; il modo sicuro per rimuoverli (e il motivo per cui non dovresti limitarti a fare DELETE sulle righe) è spiegato in come eliminare gli ordini di prova in PrestaShop.

Domande frequenti

Dove aggiungo uno stato ordine personalizzato in PrestaShop?

Vai in Parametri negozio → Stati, poi clicca su Aggiungi nuovo stato ordine. In PrestaShop 1.6 la stessa schermata si trovava sotto Ordini → Stati. Ogni stato che crei è una riga nella tabella ps_order_state, e le caselle di spunta in quel modulo (pagato, spedito, genera fattura, invia email) sono i flag di comportamento che il core attiva ogni volta che un ordine entra nello stato.

Passare un ordine a "Pagamento accettato" scala lo stock?

No. Lo stock disponibile viene ridotto quando l'ordine viene convalidato/creato alla finalizzazione dell'ordine — cosa che accade anche mentre l'ordine resta in "In attesa di pagamento" — non quando scatta il flag pagato. Quando un ordine raggiunge Pagamento accettato, il movimento di magazzino di solito è già avvenuto. Lo stato pagato genera la fattura, segna l'ordine come pagato e invia l'email di stato; non tocca lo stock.

Perché l'email del mio stato personalizzato non è mai partita?

Quasi sempre per un template mancante. Quando attivi il flag email per uno stato, PrestaShop cerca file HTML e TXT con il nome corrispondente sotto /mails/LANGUAGE_CODE/ in ogni cartella lingua. Se quei file non esistono, l'invio fallisce in silenzio nei log e il cliente non riceve nulla. Crea i template HTML/TXT accoppiati per ogni lingua prima di fare affidamento sull'email.

Posso cambiare lo stato di un ordine da codice senza scrivere SQL?

Sì — e dovresti farlo. Sposta l'ordine attraverso il suo oggetto ordine, così ogni flag, email e movimento di magazzino continua ad attivarsi, e ascolta gli hook forniti da PrestaShop: actionOrderStatusUpdate (mentre la modifica viene applicata), actionOrderStatusPostUpdate (dopo il commit — utile per sincronizzazioni ERP/spedizioni) e actionOrderHistoryAddAfter (dopo la scrittura della riga di cronologia). Un UPDATE grezzo su ps_order_state salta tutto questo ed è il modo in cui ti ritrovi con fatture ed email fuori sincronia.

Come evito di generare fatture per ordini non pagati?

Tieni d'occhio il flag Genera fattura. Se lo attivi per uno stato che non conferma il pagamento, PrestaShop emetterà fatture per ordini che nessuno ha pagato: un vero caos contabile e fiscale da sistemare. Mantieni la generazione delle fatture legata solo allo stato di pagamento confermato e ricontrolla quella casella prima di salvare un nuovo stato.

Posso automatizzare i cambi di stato per bonifici bancari e regole condizionali?

I gateway per carte portano già automaticamente gli ordini a Pagamento accettato; il vuoto riguarda bonifici, assegni e logiche condizionali come "se bonifico bancario e totale oltre 500 EUR, imposta In verifica". Questo tipo di flusso basato su regole è esattamente ciò che il nostro modulo di automazione del flusso ordini gestisce dal back office, così il collo di bottiglia smette di essere una persona che deve stare alla scrivania per cambiare gli stati.

Un flusso degli stati ordine ben modellato è la spina dorsale di un back office tranquillo: il team sa che cosa fare dopo, il cliente riceve il messaggio giusto al momento giusto e la contabilità resta pulita perché sono i flag — non una persona stanca alle 18:00 — a decidere quando esiste una fattura e quando si muove lo stock. Pianifica il flusso prima di collegarlo, perché una volta che gli ordini scorrono attraverso i tuoi stati, cambiarli a metà percorso è molto più dirompente che impostarli bene fin dall'inizio. Quando le transizioni manuali non bastano più, l'automazione basata su regole di mypresta.rocks toglie dal piatto del tuo team il cambio di stato ripetitivo, così ogni ordine segue lo stesso percorso dall'inserimento alla consegna — ogni volta, che qualcuno stia guardando oppure no.