Modelul de Date OMS: Comenzi, Linii de Comandă și Fulfillment-uri
Modelul de date de sub un OMS determină ce poate reprezenta efectiv sistemul și, prin extensie, ce scenarii de business poate gestiona fără soluții improvizate. Comenzile, liniile de comandă și fulfillment-urile sunt cele trei entități fundamentale, iar modul în care se relaționează între ele modelează tot ce se construiește deasupra.
Un design naiv tratează o comandă ca pe o singură înregistrare cu o listă de produse și o adresă de livrare, ceea ce funcționează bine până la prima expediere împărțită, returnare parțială sau backorder. Procesarea reală a comenzilor cere separarea intenției originale a clientului — ce a comandat și a fost de acord să plătească — de realitatea operațională a modului în care este onorată, care poate implica mai multe expedieri, mai multe depozite și mai mulți transportatori pentru o singură comandă. De aceea platformele OMS mature modelează comenzile, liniile de comandă și fulfillment-urile ca entități legate, dar independente, nu ca un singur tabel plat.
- Comanda: acordul comercial — client, totaluri, plată, date promise — care rareori se schimbă odată confirmată
- Linia de comandă: un produs și o cantitate în cadrul comenzii, purtând propriul preț, taxă și alocare de discount, independent de celelalte linii
- Fulfillment-ul: o unitate fizică de lucru — o expediere sau ridicare specifică — care referențiază una sau mai multe linii de comandă (sau cantități parțiale ale lor) și își urmărește propriul status independent de comandă în ansamblu
Cu liniile de comandă și fulfillment-urile ca entități distincte, o singură comandă poate susține natural scenarii care rup un model plat: expedierea unei părți din comandă azi și restul săptămâna viitoare, returnarea unei unități dintr-o linie de comandă păstrând restul, sau substituirea unui produs în mijlocul fulfillment-ului fără a atinge înregistrarea comercială originală. Fiecare fulfillment poate purta propriul număr de tracking, transportator și status, în timp ce comanda rămâne punctul de referință stabil pe care clientul îl vede drept „comanda mea".
Deoarece calculele de preț, discount și taxă se întâmplă la nivelul liniei de comandă, modelul trebuie să păstreze exact cât dintr-o plată se aplică fiecărei linii și, prin extensie, fiecărui fulfillment derivat din ea. Această trasabilitate este ceea ce face ca rambursările parțiale, anulările parțiale și recunoașterea veniturilor per expediere să fie calculabile fără reconciliere manuală — o cerință care devine obligatorie odată ce departamentul financiar trebuie să raporteze venitul pe data de fulfillment, nu pe data comenzii.
Un model de date bine proiectat anticipează câmpuri de care nu are încă nevoie — atribute personalizate pe o linie de comandă pentru împachetare cadou sau personalizare, sau metadate pe un fulfillment pentru instrucțiuni speciale de manipulare — prin structuri de atribute extensibile, în loc să necesite o migrare de schemă pentru fiecare cerință de business nouă. Sistemele care codifică logica de business direct în structuri de tabel rigide tind să acumuleze rapid datorie tehnică pe măsură ce apar tipuri noi de comenzi.