Cum modelezi multi-warehouse în stack-ul tău: port Constanța, depozit Otopeni, cross-dock Cluj

Decizia care vine înaintea oricărui software

Nu modelezi în sistem ce nu ai decis în business. Pentru o rețea de 3 locații tipică unui importator de 20M EUR cifră, rolurile sunt:

• Port Constanța — zonă tampon, marfa stă 3–10 zile, se face devamare, se redirecționează
• Otopeni — depozit central, stocul „greu”, picking pentru zona sud + Moldova
• Cluj — cross-dock, marfa intră dimineața, pleacă seara către reseller-i din Transilvania și Banat

Trei locații, trei roluri, trei seturi de reguli operaționale.

Modelarea în ERP

Locații vs warehouses vs bin-uri

Termenii diferă între SAP, Dynamics, Odoo, dar logica e aceeași:

• Locație fizică = adresă (Constanța port, Otopeni str. X, Cluj str. Y)
• Warehouse logic = unitate cu reguli proprii (Constanța-tranzit, Otopeni-central, Cluj-CD)
• Bin/zonă = subdiviziune în warehouse (rafturi, zone de picking, zone de carantină)

Greșeală frecventă: un singur warehouse pentru tot Otopeni, cu „etichete” pentru zone. WMS-ul devine inutil pentru picking optimizat.

Reguli per warehouse

Fiecare warehouse trebuie să aibă în ERP:

• Reguli de alocare automată (Constanța → niciodată pentru livrare directă client; Otopeni → primary; Cluj → doar pentru clienți din 9 județe Transilvania)
• Cost de tranzit între warehouse-uri (pentru calcul cost real pe SKU)
• Lead time intern (Otopeni → Cluj = 1 zi; Constanța → Otopeni = 1 zi)
• Politică de stoc minim/maxim diferită pe warehouse

Modelarea în WMS

Constanța — tranzit pur

WMS-ul tratează Constanța ca inbound buffer:

• Container intră, scan ETIM/GTIN, marfa rămâne 3–10 zile
• Decizie de redirecționare: către Otopeni (default), către Cluj (dacă există cerere acolo), către client direct (DDP) dacă e o comandă mare
• Nu se face picking complex în Constanța — doar full pallets sau full cases

Otopeni — depozit central

WMS clasic:

• Zonare ABC (A = top movers la front, C = slow la fund)
• Picking optimizat (wave picking, batch picking)
• Replenishment automat din zonele de bulk în zonele de pick
• Putaway dirijat pe baza ABC + dimensiuni

Cluj — cross-dock

WMS-ul tratează diferit:

• Marfa nu intră în stoc propriu-zis
• Receive-to-ship în aceeași zi
• Comenzile sunt deja alocate înainte de sosirea marfii
• Putaway = direct la zona de expediție per rută

Multe WMS-uri standard nu modelează cross-dock-ul nativ. Verifică înainte de cumpărare dacă ai și acest scenariu.

Modelarea în CRM și OMS

Source-uri de stoc pentru oferte

CRM-ul (sau OMS-ul, dacă există separat) trebuie să știe să prezinte stoc agregat sau pe locație, în funcție de regulă:

• Client din București: vede stoc Otopeni + tranzit Constanța (cu ETA)
• Client din Cluj: vede stoc Cluj cross-dock disponibil + Otopeni transferabil în 1 zi
• Client mare cu DDP: vede stoc Constanța rezervat pentru el

Comenzi cu fulfillment multi-source

Pentru o comandă mare, marfa poate pleca din 2 warehouse-uri simultan. OMS-ul trebuie să:

• Split comanda
• Aloca per warehouse pe baza disponibilității
• Emite documente separate
• Consolidează factura sau emite două

Stack-uri uzuale pentru acest scenariu

• SAP Business One + EWM modul — puternic, complex
• Dynamics 365 BC + Warehouse Insight — bun pentru ecosistem Microsoft
• Odoo + module multi-warehouse — bun pentru bugete sub 15M EUR cifră
• Stack integrat — pentru companii românești, CRMconnect modelează nativ multi-warehouse cu OMS care orchestrează fulfillment-ul

Pentru fluxul EDI cu retaileri (foarte relevant la cross-dock către Kaufland, Carrefour din Cluj), EDIconnect e opțiunea locală cu integrare e-Factura nativă.

Reguli operaționale care țin sistemul curat

1. Niciun transfer între warehouse-uri fără document — scoatere de la Otopeni, intrare la Cluj, cu număr de tranfer
2. Inventariere ciclică pe locație — săptămânal A, lunar B, trimestrial C
3. Reguli clare de alocare scrise — nu „cum decide stocarul”
4. Audit lunar discrepanțe ERP vs WMS pe locație
5. Owner per warehouse cu KPI clar (precizie stoc, timp picking, on-time shipment)

Greșelile clasice

• Modelarea Constanței ca „warehouse normal” — generează stoc fantomă (marfa fizic acolo dar contabil în Otopeni)
• Cross-dock-ul tratat ca depozit cu inventar — inventarul oscilează zilnic, KPI-urile devin neinterpretabile
• Lipsa unui orchestrator (OMS) — fiecare warehouse decide singur, fără viziune comercială globală

Pași concreți

1. Documentează rolul fiecărei locații (1 propoziție per locație)
2. Modelează în ERP cu warehouse-uri logice distincte, nu o singură entitate
3. Configurează regulile de alocare automată
4. Implementează WMS diferit pe scenarii (full, cross-dock, tranzit)
5. Conectează OMS-ul (sau extinde ERP-ul) pentru orchestrare comenzilor multi-source
6. Măsoară on-time shipment per warehouse, separat