Furnizorul 3PL (ThreePlProvider) este organizația logistică care operează platforma (furnizor 3PL; sesiune furnizorul 3PL selectat). Compania pe care o selectați în bară este compania 3PL (Client3pl / companie client; sesiune compania selectată). Depozitele (warehouses.three_pl_provider_id) sunt ale furnizorului 3PL și sunt folosite în comun de companiile de sub același furnizor.

În fluxul zilei, compania (context) și partenerii (furnizor de marfă / client pe documente) stau pe aceeași planșă operațională: compania filtrează tot ce vedeți; partenerul apare pe PO, recepție, SO. În baza de date, fiecare partener este legat de o companie (partners.client_3pl_id) — nu e un al doilea tenant, ci contrapartida pe document. Detalii și mapare pe meniuri: glosar (documentație internă).

Diagramă: furnizor 3PL → companie client → depozit partajat → articole și documente per companie.

Articolele nu sunt partajate între companii: fiecare companie 3PL are propriul catalog (articles.client_3pl_id). Partajat este doar depozitul logistic (înregistrare warehouses la 3PL) — aceeași locație poate fi folosită în operațiuni pentru ACME, Global etc., dar stocul și documentele rămân separate pe compania selectată. Partenerii nu partajează catalogul între companii: fiecare rând partners aparține unei singure companii, dar îi selectați alături de contextul companiei când completați documente.

Două tabele, fără dublură: furnizorul logistic stă în furnizor 3PL (ex. Quehenberger); firmele client deservite în companie client (ex. SELGROS). Nu trebuie același CUI în ambele — rândurile „oglindă” (companie = același CUI ca furnizorul) sunt legacy; se elimină cu three-pl:audit-mirror-tenants → migrare → purge → delete-mirror-rows. Stocul și comenzile rămân legate de compania client, nu de furnizor.

Exemplu din mediul demonstrativ (date demonstrative): 3PL ECC Logistics SA (TPL000001, CUI RO90001001); companii 3PL ACME Logistics SRL (RO90001101), Global Distribution SA (RO90001102), Fast Logistics SRL (RO90001103) — cod intern generat cu generatorul de coduri (șablon …-CC-90001101 etc.); depozite create de depozite demonstrative: WH-001 (depozit central), WH-002 (retururi), denumiri gen „ECC - Depozit Central”; parteneri demo cu cod TPL000001-P-SUP1 / P-CUST1 etc.

Fără aceste date, comenzile nu au ce să „agățe” sau veți primi erori de validare.

1. Companie corectă selectată în bara de sus (dacă lucrați cu mai multe).
2. Depozitul (locația fizică sau logistică unde țineți stocul).
3. Articolele în catalog (SKU / coduri) — fără articol nu puteți pune linii valide pe comenzi.
4. Partenerii — furnizori de la care cumpărați, clienți către care vindeți (cu puncte de livrare unde e nevoie).
5. Apoi Intrări: comandă de cumpărare → recepție (crește stocul).
6. Apoi Ieșiri: comandă de vânzare → livrare (scade stocul).
7. Retururi după ce există o livrare de referință (flux tipic).

Nu trebuie să fie mereu strict secvențial în timp (puteți avea deja articole și parteneri), dar în logica sistemului comenzile depind de articole, depozit și parteneri definiți.

În logistică și în aplicație apar des aceste trei cuvinte; sensul lor nu este același.

Companie (compania selectată)

Depozitul (spațiul fizic) este al 3PL-ului — organizația de logistică care operează hala. Compania selectată este contextul în care lucrați acum în acel depozit: articolele, stocul, comenzile și recepțiile din ecran aparțin acestei companii 3PL (Client3pl). Dacă aveți drepturi în mai multe companii, le schimbați din selectorul de companie (de obicei în bara de sus): altă companie înseamnă alt set de date — nu amestecați fluxurile între ele.

Pe scurt: compania = contextul în care lucrați; „lumea” în care se mișcă marfa și documentele pe care le vedeți pentru acel client, în depozitul 3PL.

Exemplu: dacă aveți acces la ACME Logistics și Global Distribution (sau Fast Logistics), selectați compania potrivită când lucrați recepții sau comenzi în contextul acelei companii; dacă comutați la altă companie din același mediu demonstrativ, veți vedea alt stoc și alte comenzi — nu sunt amestecate.

Furnizor — două sensuri utile

1. Furnizor de servicii 3PL — organizația care vă pune la dispoziție platforma și contractul de logistică (3PL). Este un rol administrativ / contractual, nu apare ca linie pe o recepție ca și cum ar fi „furnizorul de marfă”.

1. Furnizor de marfă (pe comenzi) — firma de la care cumpărați produsele care intră în depozit. Apare pe comanda de cumpărare și pe recepție. În sistem este înregistrată ca partener cu rol de furnizor pentru acel flux.

Nu confundați: cumpărați de la furnizorul de marfă (partener); marfa intră și iese din depozitul 3PL, iar înregistrările din ecran sunt mereu în contextul companiei selectate.

Client (în sens de vânzare)

Este destinatarul mărfii când vindeți sau expediați: apare pe comanda de vânzare și la livrare. De regulă este o altă firmă (sau punct de lucru) definită ca partener cu rol de client — adică cumpărătorul dumneavoastră.

Nu confundați: „Client” pe documentul de vânzare ≠ compania selectată în bară. Compania selectată este compania 3PL pentru care lucrați acum (stocul și documentele pentru această firmă); clientul de pe comandă este partenerul către care merge marfa la acea vânzare (de regulă altă entitate decât compania din selector).

Cum se leagă pe scurt

Compania și partenerul de pe document sunt pe aceeași linie în operațiuni (vezi diagrama la Structură: 3PL, companie client și depozite); în meniu, partenerii se administrează separat, dar pe document nu înlocuiesc compania din bară.

Dacă în meniu vedeți și „Clienți” ca listă separată, acolo sunt de obicei entitățile (firme) pe care le deserviți ca 3PL — tot în cadrul aceluiași model, dar la nivel de administrare; pe documente, „clientul” comenzii de vânzare este în continuare partenerul către care se face livrarea.

În depozit, pentru fiecare articol și locație, veți vedea de obicei:

• Cantitate totală — câtă marfă este fizic în acel depozit (în unitatea folosită la documente).
• Cantitate disponibilă — câtă marfă mai poate fi folosită pentru comenzi noi. Poate fi mai mică decât totalul dacă o parte este deja „ținută” pentru comenzi în lucru (rezervare).

Recepție și retur măresc, în mod normal, ambele (marfa intră fizic și devine disponibilă).

Comandă de vânzare: la tipul de comandă în care sistemul verifică strict stocul, la creare se scade din disponibil (marfa rămâne în depozit, dar nu mai e liberă pentru alte comenzi). La livrare, cantitatea iese din total (marfa a plecat). La anulare înainte de livrare, ce era „ținut” revine la disponibil.

Dacă lucrați cu loturi sau serii, sistemul poate ține evidență și pe lot/serie, nu doar pe total.

Exemplu numeric (înțeles)

Disponibilul vă spune cât mai puteți promite altor clienți; totalul spune câtă marfă fizică evidențiați în acel loc (până la livrare, la unele tipuri de comenzi, cele două nu coincid).

Poveste unică, fără nume de ecrane obligatorii — ideea este să vedeți lanțul de cauze și efecte. Dacă lucrați pe datele demonstrative încărcate cu php artisan mediul demonstrativ (training, scenariu ECC / ACME / Global / Fast), puteți recunoaște denumirile și codurile de mai jos direct în aplicație. Prefixul SCMC- nu mai apare în codurile interne ale acestui set; codurile urmează convențiile din generatorul de coduri (ex. TPL000001, TPL000001-CC-…, TPL000001-ACM-001). Cifrele din tabelul numeric rămân un exemplu rotunjit doar pentru înțeles; cantitățile reale pe documentele de probă pot fi altele (inclusiv stoc inițial variabil pe articol).

Exemplu demonstrativ: cine este cine (denumiri uzuale)

Date pe documente (planificări, „emise acum X zile”): în mediul de probă sunt calculate automat la momentul încărcării datelor — servesc la exercițiu, nu sunt un calendar fix „de produs”.

Context (ACME + ECC, exemplu pentru training)

Lucrați pentru ACME Logistics (selectată în bară). Depozitul fizic este al 3PL ECC; în ecran folosiți depozitul stoc OK „ECC - Depozit Central”. Articolul folosit ca „SKU” în exemplul numeric: TPL000001-ACM-001 (scanner, BUC). Pe fluxul de achiziție din mediul demonstrativ, primul partener folosit este de obicei Supplier One SRL; pe comenzile de vânzare din același exemplu se alternează Supplier One SRL și Supplier Two SA (ambele înregistrate la ACME Logistics).

Faza 1 — Pregătire (încă fără mișcare de stoc pe acest articol)

Faza 2 — Intrare marfă (crește stocul)

Faza 3 — Vânzare fără livrare încă (disponibil poate scădea)

Faza 4 — Livrare (iese marfa din depozit)

Faza 5 — Retur opțional (marfa înapoi)

Tabel recap (exemplu numeric simplificat — articol TPL000001-ACM-001)

Checklist „înainte de livrare” (operator)

• [ ] Compania selectată este cea corectă.
• [ ] Depozitul și articolele de pe comandă există și sunt cele așteptate.
• [ ] Cantitatea livrată nu depășește ce puteți confirma fizic.
• [ ] Statusul Livrat îl puneți doar când marfa a plecat (nu „doar pentru probă”).

Variații utile (aceeași logică, alte cifre)

• Recepție parțială: comanda de cumpărare poate rămâne „în curs” până primiți restul; fiecare recepție salvată crește stocul cu cantitatea ei (vezi și Intrări).
• Mai multe comenzi de vânzare pe același articol: fiecare comandă care rezervă scade din disponibil; totalul scade la fiecare livrare în parte.
• Livrări eșalonate: dacă livrați din aceeași comandă în mai multe tranșe (unde fluxul permite), urmăriți cum se actualizează cantitățile livrate vs. rămase — principiul rămâne: iese din depozit când confirmați livrarea pentru acea tranșă.

Comanda de cumpărare (PO) spune ce ați comandat de la furnizor. Recepția spune ce a intrat efectiv în depozit — poate fi mai puțin sau împărțit în mai multe recepții.

Comandă furnizor  →  Recepție în depozit  →  Stocul crește
     (PO)                  (recepție)

Ce vezi într-un mediu demonstrativ (intrări)

Pe companiile exemplu (ACME Logistics, Global Distribution, Fast Logistics) apar de regulă două comenzi de cumpărare: una trimisă, cu recepție asociată în lucru și cantități primite mai mici decât pe comandă (recepție parțială); alta complet recepționată, cu recepție închisă și cantități aliniate comenzii. Codurile PO / REC urmează formatul aplicației (PO-{id_furnizor}-{nr} etc.); pe linii pot apărea loturi de forma LOT-{id_companie}-{id_articol}. La ACME, furnizorul folosit pe primul flux este de obicei Supplier One SRL (cu punct de lucru „Sediu …”). Depozitul de intrare este în mod tipic ECC - Depozit Central.

Pas cu pas (flux tipic)

1. Creați comanda de cumpărare cu furnizorul și cantitățile comandate (linii pe articole).
2. O trimiteți în fluxul „trimisă” când e cazul în organizația dumneavoastră.
3. Când marfa fizică ajunge, deschideți o recepție legată de acea comandă, alegeți depozitul unde intră marfa și introduceți cantitățile efectiv primite (pot fi mai mici decât pe comandă).
4. Salvați recepția ca document definitiv sau publicați ciornă — abia atunci cantitățile se adaugă la stoc.
5. Dacă recepția nu e încă „închisă”, dar a fost deja salvată definitiv, stocul poate fi deja actualizat; închiderea recepției ajută la raportare și la calculul „cât s-a luat din comandă” pentru comanda de cumpărare (parțial / complet).
6. Puteți face mai multe recepții pe aceeași comandă până acoperiți cantitățile sau până închideți subiectul.

Exemplu: recepție parțială

• Pe comandă: 200 bucăți.
• Prima recepție (închisă): 80 bucăți → stocul crește cu 80; comanda poate apărea parțial recepționată.
• A doua recepție: 120 bucăți → după închidere, total recepționat = 200 → comanda poate deveni complet recepționată (conform regulilor din sistem).

Cum evoluează comanda de cumpărare (statusuri)

Multe schimbări la „parțial” și „complet” vin automat din recepțiile închise (vezi mai jos), nu doar din setare manuală.

Cum evoluează recepția (statusuri)

Important: nu puteți sări direct de la „Creată” la „Închisă” — trebuie fie În lucru, fie Anulată (conform regulilor din interfață).

Când crește stocul la recepție?

• Nu crește dacă aveți doar o ciornă nesalvată definitiv.
• Crește când salvați recepția finală sau când publicați o ciornă (devine document definitiv).
• Dacă modificați o recepție încă deschisă la editare, sistemul ajustează stocul la noile cantități (scoate vechiul, pune noul).

Legătura cu comanda de cumpărare

Sistemul recalculează starea comenzii de cumpărare (trimisă / parțial / complet) pe baza recepțiilor închise: se adună cantitățile din recepțiile marcate Închise și se compară cu ce era comandat.

Recepțiile doar create sau în lucru (dar neînchise) nu mută singure comanda la „complet recepționată” — contează în special momentul închiderii recepției pentru acest calcul.

De reținut explicit: stocul (marfa în depozit) se actualizează în momentul salvării / publicării recepției, iar progresul comenzii de cumpărare (parțial / complet) ține cont de recepțiile închise. Dacă aveți marfa în stoc dar comanda încă „nu arată complet”, verificați dacă recepțiile sunt închise și dacă cantitățile acoperă tot ce era pe comandă.

Recepții „ciornă” (draft)

• Puteți salva progres fără să mișcați stocul.
• La publicare, documentul primește cod final și abia atunci intră marfa în stoc.
• Puteți șterge o ciornă fără efect pe inventar.

Comanda de vânzare este documentul prin care cereți ieșirea mărfii către client.

Ce vezi într-un mediu demonstrativ (ieșiri)

Apare adesea câte o comandă de vânzare pentru fiecare status tipic (Creată, În lucru, Încărcată, Livrată) — ca să puteți compara cum arată listele și detaliile. Codurile SO urmează același model numerotat ca PO (SO-{id_furnizor}-{nr}). Partenerul de livrare variază între înregistrările companiei: pe ACME veți recunoaște furnizorii exemplu (Supplier One / Supplier Two), pe Global Distribution clienții exemplu (Customer One / Customer Two). Cantitățile pe linii sunt mici, de exercițiu. Depozitul sursă este același tip ca la intrări (ECC - Depozit Central).

Pas cu pas (flux tipic)

1. Verificați că articolul există în catalog și că stocul este suficient în depozitul sursă ales pe comandă.
2. Creați comanda de vânzare cu clientul (partenerul), liniile și cantitățile.
3. La tipul de comandă cu verificare strictă a stocului, la salvare disponibilul scade cu cantitatea comenzii — altă comandă nu mai poate „folosi” aceeași marfă până eliberați rezervarea.
4. Parcurgeți statusurile operaționale (Creată → În lucru → Încărcată), în funcție de cum lucrați în depozit.
5. Când marfa a plecat efectiv, marcați Livrată — totalul din depozit scade (marfa nu mai e la voi).
6. Dacă anulați înainte de livrare, ce era blocat în disponibil revine (la tipul de comandă cu rezervare).

Tip de comandă și „disponibil”

La comenzile pentru care sistemul ține cont strict de stoc disponibil, la creare se blochează cantitatea din „disponibil” (alte comenzi nu mai pot folosi aceeași marfă). Fizic, marfa încă e în depozit până la livrare.

La livrare (status Livrat), cantitatea iese din depozit (nu mai este nici total, nici disponibil pentru acea linie).

La anulare înainte de livrare, ce era blocat pentru acea comandă revine la disponibil (unde se aplică acest mod de lucru).

La tipuri de comandă care nu blochează disponibilul la creare, verificarea de stoc se poate face altfel (ex. la livrare sau conform politicii); dacă nu sunteți siguri, întrebați administratorul companiei ce tip folosiți.

Statusuri uzuale la comandă de vânzare

După Livrat sau Anulat, în mod normal nu mai schimbați statusul (sunt stări finale).

Returul leagă o comandă de vânzare deja livrată (sau context permis de formular) de reintrarea mărfii în depozit.

Pas cu pas (flux tipic)

1. Identificați comanda de vânzare originală (livrată) și clientul.
2. Alegeți depozitul unde reintră marfa (poate fi același sau altul, după regulile voastre).
3. Introduceți articolele și cantitățile returnate.
4. Salvați returul definitiv sau publicați ciornă — abia atunci cantitățile se adaugă la stoc.
5. Puteți închide în continuare documentul din punct de vedere administrativ; închiderea nu adaugă încă o dată aceeași cantitate în stoc dacă marfa intrase deja la salvarea de la pasul 4.

Când intră marfa din retur în stoc?

În practică, imediat ce salvați returul ca document definitiv (creare directă sau publicare după ciornă). Nu așteptați neapărat statusul „Închis” ca să apară marfa — „Închis” înseamnă de obicei că procesul de retur este încheiat la nivel de document, nu o a doua intrare de marfă.

La anulare retur

Dacă marcați returul Anulat, sistemul scoate din stoc cantitățile pe care le adusese la intrare (marfa nu mai este considerată reintrată prin acel document).

Statusuri

Ciornă la retur: până publicați, nu se schimbă stocul; după publicare, la fel ca la creare directă.

Rezumat rapid

Comandă de cumpărare anulată

• Nu mișcă direct marfa din depozit; marfa s-a mișcat doar prin recepții și retururi.
• Comanda devine închisă ca subiect; nu veți mai continua recepții pe ea conform regulilor din sistem.

Recepție anulată

• Documentul este marcat Anulat.
• Dacă marfa intrase deja în stoc la salvare/publicare, la anulare acele cantități sunt scoase înapoi, ca să rămână inventarul corect.

Comandă de vânzare anulată

• Înainte de livrare: ce era ținut pentru comandă (disponibil blocat) se eliberează unde se folosește acest mecanism.
• După Livrat: nu puteți „anula livrarea” prin același flux — comanda livrată este finală din perspectiva acestui workflow.

Retur anulat

• Cantitățile care intraseră în stoc prin acel retur sunt scăse înapoi la anulare.

Comandă de cumpărare

Stocul se mișcă prin recepții, nu prin simpla schimbare a numelui statusului pe PO.

Recepție

Din „Creată” nu merge direct la „Închisă” — treceți prin „În lucru” sau anulați.

Comandă de vânzare

Retur

Tranziția = trecerea de la un status la altul. Sistemul permite doar anumite combinații (ca să nu existe pași lipsă sau ilegale). Dacă o acțiune este refuzată, de obicei nu este permisă trecerea directă — verificați statusul curent și pașii din tabelele de mai sus.

Exemple concrete

• Recepție: din Creată nu merge direct la Închisă — trebuie mai întâi În lucru (sau Anulată).
• Comandă de vânzare: din Livrată nu puteți merge la Anulată — livrarea este considerată finală.
• Comandă de vânzare: din Creată nu săriți la Livrată fără pașii intermediari permisi de sistem (ex. În lucru → Încărcată → Livrată), dacă interfața impune această ordine.

Dacă mesajul spune „tranziție nepermisă”, nu e neapărat o eroare de date — înseamnă că trebuie alt pas următor decât cel ales.

Nume mare: ce se întâmplă exact {#nume-mare-ce-se-intampla}

În aplicație, „nume mare” poate însemna fie denumirea (firmă, produs), fie un cod (articole, depozite, parteneri). Regulile sunt diferite; nu trebuie confundate.

1) Denumire legală / comercială a companiei (numele afișat al firmei)

• La salvare: textul este acceptat până la 255 de caractere și este memorat integral (nu este înlocuit cu litere aleatorii și nu este tăiat la baza de date doar pentru că e lung).
• În interfață: pe bară sau în liste, același nume poate apărea scurtat cu „…” — este doar modul de afișare, nu ștergerea numelui. La selectorul de companie, trecerea cu mouse-ul peste rând sau peste buton poate arăta tooltip cu numele complet (depinde de navigator).
• Important: numele lung al firmei nu se transformă în codul rezervă R…; formatul R… este folosit numai pentru anumite câmpuri de cod (vezi punctul 2).

2) Cod articol, cod depozit, cod intern partener, coduri similare la import

• Plafon: 30 de caractere pentru valoarea salvată ca cod (formulare, API, import, seed-uri care trec prin același mecanism).
• Serviciu central: regulile (inclusiv normalizarea la plafon și codurile de rezervă R…) sunt aplicate prin generatorul de coduri. Implementarea de nivel jos (InsertableCode) este folosită prin acest serviciu în fluxurile curente ale aplicației, nu direct din controllere.
• Seedere: orice seeder care creează sau normalizează coduri de business (articole, depozite, parteneri, fluxuri demo/complete etc.) trebuie să treacă prin generatorul de coduri (același lucru ca la formulare și import). Există și seedere care nu emit astfel de coduri (ex. roluri, module) sau care folosesc valori fixe scurte doar ca date de catalog vechi (ex. CLI-001 în seed generic DatabaseSeeder) — acolo nu intră în joc generarea automată, dar codurile rămân scurte și valide.
• Dacă introduceți sau importați un cod mai lung de 30 de caractere: sistemul nu păstrează acel șir ca atare în câmpul de cod. Îl înlocuiește cu un cod de rezervă de exact 30 de caractere: litera R urmată de 29 de caractere hexadecimale (cifre 0–9 și litere A–F), obținute din amprenta (hash) a textului original. Același cod lung introdus de două ori produce mereu același cod scurt (util când reîncărcați același fișier de import).
• Cum recunoașteți produsul: după descriere și cod de bare (sau alte câmpuri descriptive), nu după codul R…, care e doar etichetă tehnică de rezervă.

Exemplu concret (cod articol, nu nume firmă): presupuneți că în import puneți la coloana „cod articol” exact 40 de litere A unul după altul (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA). Acest șir are 40 de caractere, deci depășește plafonul de 30. Codul salvat în baza de date pentru acel articol nu va fi cele 40 de A, ci rezerva de 30 de caractere calculată automat, de forma:

RF0A2FB80AC0699075FB6C7B0EE2BC

(începe cu R, are exact 30 caractere; valoarea exactă depinde de algoritmul de hash din aplicație — exemplul de mai sus corespunde acelui șir de 40 de A în versiunea curentă a codului.) Coloanele descriere și cod de bare din același rând de import rămân ce le-ați trecut dumneavoastră, dacă sunt valide.

3) Ciorne de documente

• Comenzi, recepții, retururi etc.: la salvare ca ciornă se pot folosi coduri temporare DRAFT-PO-, DRAFT-REC-, … (scurtate la max. 30 caractere). La publicare, dacă codul e recunoscut ca temporar, sistemul alocă codul final (PO-{id_furnizor}-{nr}, REC-…, la fel ca documentele normale).
• Articole (produse): ciorna folosește deja același tip de cod ca articolul publicat — PRODUS-{id_furnizor_3PL}-{număr} (ex. PRODUS-3-00042). Nu se mai generează *DRAFT-ART- la salvare; puteți modifica codul manual în formular. Ciorne foarte vechi cu DRAFT-ART sunt actualizate automat la cod PRODUS** la încărcare sau salvare.
• Detalii tehnice complete: docs/internal-codes.md.

În logistică e util ca toate codurile „să se citească la fel”: cine e 3PL-ul (sau contextul logistic) → ce fel de entitate e → detaliul (firmă, depozit, număr de articol, partener etc.). În codul sursă, același mecanism ca în formulare și import (generatorul de coduri) este folosit și la încărcarea datelor demo, astfel încât nu primiti un set de reguli „doar pentru seed” separat de producție.

Centralizare: generatorul de coduri

• În aplicație: generare / normalizare pentru coduri interne relevante (ex. companie client CC, partener P…, documente PO/REC/SO/RET per furnizor, ciorne DRAFT-…, plafon 30 caractere, rezervă R…).
• În seedere: orice seeder care produce coduri de business merge prin același serviciu acolo unde se scriu aceste câmpuri; seedere fără coduri operaționale (permisiuni, module etc.) nu îl apelează — este normal.
• Nume de scenariu: comanda Artisan se numește în continuare mediul demonstrativ (comod pentru echipă); asta nu înseamnă că codurile din baza de date trebuie să înceapă cu SCMC-.

Verificare față de codul sursă (mediul demonstrativ)

• Comanda php artisan mediul demonstrativ (clasa App\Console\Commands\SeederScmc) rulează migrate:fresh cu --seeder=Database\Seeders\SeederScmcRunner, apoi cache:clear.
• SeederScmcRunner apelează date demonstrative, care: creează furnizorii 3PL (inclusiv ECC / cod TPL000001, CUI RO90001001), cele trei companii 3PL (ACME, Global Distribution, Fast Logistics cu CUI RO90001101–03), partenerii din seedPartners, depozite demonstrative, module, ScmcOperationalUsersSeeder (parola parola123 pentru conturile @scmc-demo.ro) și ScmcActiveTenantSeeder (articole TPL000001-ACM-\* / GLB / FST, stoc, două PO + recepții, patru SO pe statusuri, jurnal, activity log).
• Codurile interne ale companiilor (…-CC-90001101 etc.) urmează CodeGeneratorService::generateClientCode (CUI fără litere). Articolele și barele din tabelele de mai jos coincid cu ScmcActiveTenantSeeder::seedArticles (inclusiv sufixul -C la UM secundară).
• Codurile PO / REC / SO allocate în seed folosesc InvoiceNumberService::allocateNextDocumentCodeForThreePl: formă PO-{id_numeric_three_pl_providers}-{număr} (separator din config), nu șirul TPL000001 — acela e codul intern al furnizorului, alt câmp decât cheia primară numerică din codul documentului.
• Cantitățile pe stoc și pe unele linii de document sunt random_int în seeder; tabelul numeric din Scenariu complet rămâne ilustrativ, nu trebuie să reproducă bit cu bit baza după fiecare rulare.
• Retururile (RET) nu sunt create de ScmcActiveTenantSeeder; explicațiile despre retur din ghid descriu regulile aplicației, nu neapărat rânduri RET imediat după seed.

Regula simplă (cum vă gândiți la coduri)

Forma logică (aceeași peste tot):

COD3PL - TIP - DETALIU ( eventual - SUFIX )

Exemple „ca în manual” (model de citire, aliniat la baza de date și la generatorul de coduri):

• Companie client (3PL): TPL000001-CC-90001101 — cod furnizor TPL000001, segment CC, apoi CUI fără litere (ex. din RO90001101).
• Depozit (cod tehnic): WH-001 — generat pe 3PL; numele afișat poate fi tot „ECC - Depozit Central”.
• Articol: TPL000001-ACM-001 — cod furnizor + segment scurt de catalog (ACM = exemplu ACME) + număr.

Codul furnizorului în demo: TPL000001 (ECC)

În datele de probă, furnizorul 3PL din poveste se numește „ECC” în denumiri afișate (depozit „ECC - Depozit Central” etc.), dar codul intern al acelui furnizor în baza de date este TPL000001 — aceeași serie TPL + 6 cifre ca la crearea automată din aplicație.

• Companie client (3PL): cod generat ca în producție — TPL000001-CC-{CUI_fără_litere} (ex. TPL000001-CC-90001101 pentru ACME cu CUI RO90001101), prin CodeGeneratorService::generateClientCode.
• Articole: TPL000001-ACM-001 … — prefix cod furnizor + segment catalog (ACM / GLB / FST) + număr.
• Parteneri: TPL000001-P-SUP1 etc. — același prefix de furnizor, apoi P și un sufix scurt de rol demo.

Depozitele: codul tehnic poate rămâne tip WH… pe 3PL; numele afișat rămâne ECC - ….

Articole în setul demonstrativ — legătura cu structura de mai sus

Fiecărei companii demo îi sunt pregătite cinci articole cu coduri fixe (tabelele de mai jos), cu descriere și cod de bare. Unitatea principală la exemple este Bucată (BUC).

Forma articolului: cod furnizor + - + prescurtare catalog (ACM / GLB / FST) + - + trei cifre. Denumirea lungă a firmei nu intră în cod; rămâne la fișa companiei sau în descrierea articolului.

Dacă ați vrea litere foarte multe în fiecare parte: codul întreg devine impractic și, la salvare/import, depășește plafonul de 30 de caractere pentru câmpurile de cod — vezi Nume mare: ce se întâmplă exact.

Dacă în loc de prefixul furnizorului sau „ACM” ați avea text foarte lung (ex. 249 caractere fiecare)

Da, ar deveni prea lung pentru un cod de articol folosit zilnic: întregul șir (toate părțile + -001 … -005) depășește clar plafonul de 30 de caractere folosit la salvare / import pentru astfel de coduri. Două blocuri de câte 249 caractere, plus cratime și sufixul -001, nu mai trec validarea obișnuită — trebuie cod scurt sau lăsăm aplicația să înlocuiască automat (vezi mai jos).

La inserare (formulare, API, import din fișier, seed-uri): regulile sunt aplicate prin serviciul generatorul de coduri (normalizare unică). Dacă textul depășește 30 de caractere, nu se păstrează șirul întreg; se folosește un cod de rezervă foarte scurt care începe cu R și continuă cu o amprentă (din același text lung), astfel încât același cod lung din fișier produce mereu același cod scurt la reimport. În catalog recunoaște articolul după descriere și cod de bare. Codurile DRAFT-… pentru ciorne rămân recunoscute (prefix special), tot sub aceeași lungime maximă.

Chiar când matematic „încape” un singur bloc uriaș + -001: codurile kilometrice sunt greu de citit, de scanat și de căutat în liste. De aceea în demo prefixul de furnizor (TPL000001), segmentul (ACM / GLB / FST) și seria 001…005 rămân scurte la nivel de exemplu; detaliile lungi despre produs stau în descriere, nu în cod.

Exemplu: companie 249 caractere și „produs” 249 caractere

În practică, denumiri foarte lungi la firmă sau la descrierea produsului sunt acceptate până la plafonul obișnuit (255 caractere pe astfel de câmpuri), deci și 249 caractere sunt posibile acolo.

1) Companie — denumire de 249 caractere

• Exemplu concret (249 caractere într-un singur șir): prefix fix SOCIETATE- (10 caractere), apoi litera B repetată de 239 ori (10 + 239 = 249).
• În datele încărcate cu mediul demonstrativ, codul intern al companiei este cel generat (ex. TPL000001-CC-90001101), nu denumirea lungă. Prefixul articolelor (TPL000001-ACM) se construiește din codul furnizorului + segmentul de catalog, nu din cele 249 de caractere de la firmă.
• Rezultat: articolele demo rămân TPL000001-ACM-001 … 005. Textul de 249 caractere apare la datele firmei, nu în codul articolului.

2) Produs — descriere de 249 caractere

• Exemplu concret: propoziția fixă Articol logistic pentru demonstrație — (urmată de un spațiu la final, astfel încât întregul prefix să fie 39 de caractere), plus 210 de litere X → 249 caractere în total în câmpul de descriere.
• Codul articolului în demo rămâne TPL000001-ACM-001 — textul lung stă în descriere, separat de cod.

3) Cod articol propriu, foarte lung

• Un cod de 249 caractere nu respectă plafonul de 30 caractere folosit la inserare pentru coduri; aplicația îl înlocuiește cu rezerva R… (vezi mai sus). Nu este cazul valorilor din tabelele demo de mai jos.
• Recomandare: cod scurt + descriere detaliată.

ACME (TPL000001-ACM-*)

Global (TPL000001-GLB-*)

Fast (TPL000001-FST-*)

Unitate secundară „Cutie”

La fiecare articol de mai sus există și o unitate secundară „Cutie”: codul de bare al acesteia este codul de bare principal, la care se adaugă sufixul -C (ex. 590TPLACM00001-C pentru articolul TPL000001-ACM-001).

Fiecare mișcare importantă (intrare la recepție/retur, ieșire la livrare, rezervare, anulare rezervare) poate lăsa o înregistrare pe care o puteți folosi pentru trasabilitate și reconciliere. Detaliile exacte (tip mișcare, document sursă, cod intern) apar în ecranul de jurnal / rapoarte din aplicație.

La ce vă ajută în practică: să demonstrați când s-a schimbat cantitatea, de ce document provine (recepție, comandă livrată, retur anulat etc.) și să verificați diferențele la inventar sau reclamații.

Dacă organizația folosește integrări (ex. către ERP sau un alt serviciu), sistemul poate trimite notificări când se întâmplă evenimente importante: comenzi create sau modificate, recepții, schimbări de status la comenzi de vânzare sau retururi, modificări de stoc. Ciornele de recepție nu generează în general aceleași evenimente ca documentele finale.

Lista exactă de evenimente și configurarea se fac împreună cu administratorul tehnic sau din documentația de integrare.