Acest ghid explică cum curg lucrurile în sistem din perspectiva operațională: ce înseamnă fiecare document, când se schimbă cantitățile din depozit și ce se întâmplă când anulați sau închideți ceva. Nu este nevoie să înțelegeți programare — doar cum se reflectă acțiunile voastre în stoc și în statusuri.

Unde e diferența față de Ajutor? Pagina Ajutor descrie ecranul (unde găsiți meniurile, cum vă autentificați). Aici descriem regulile depozitului: ordinea logică a documentelor, consecințele pe inventar și limitele sistemului (de exemplu: nu puteți sări anumite statusuri).

Ce tratează fiecare parte

0. Companie, furnizor și client — ce înseamnă fiecare termen și cum nu se amestecă (detalii).
1. Stoc: două idei simple — diferența între „cât aveți fizic” și „cât mai puteți aloca la comenzi noi”.
2. Intrări — legătura comandă furnizor ↔ recepție; când intră marfa în depozit; ciornă; anulare recepție și efect pe raft.
3. Ieșiri — comandă de vânzare: rezervare, livrare, anulare înainte de livrare.
4. Retururi — când se adaugă marfa înapoi în stoc; anulare retur.
5. Anulări — tabel pe tip de document (comandă cumpărare, recepție, vânzare, retur).
6. Din fiecare status — ce variante aveți în continuare (workflow permis).
7. Tranziții — de ce uneori un pas nu este permis.
8. Istoric mișcări și integrări — trasabilitate internă și notificări către alte sisteme, dacă le folosiți.
9. Ordinea recomandată — ce pregătiți înainte de comenzi (detalii).
10. Greșeli frecvente — situații uzuale și ce verificați (detalii).
11. Scenariu complet — de la pregătire la livrare și retur opțional (detalii).
12. Întrebări suplimentare — FAQ extins (detalii).
13. Coduri în mediul demonstrativ (seeder:scmc) — structură TPL… + CodeGeneratorService (fără prefix vechi SCMC- în coduri) (detalii).

Dacă căutați cum se apasă butoanele pas cu pas, folosiți Ajutor; dacă vreți să înțelegeți regulile, rămâneți aici.

Onboarding furnizor 3PL (super-admin)

1. Wizard 3PL — creare furnizor, alegere module implicite pentru companii noi și trial la facturare (14 sau 30 zile, aceleași praguri ca la pagina Module pe companie). Fără trial implicit = module active fără perioadă de evaluare la facturare.
2. Finalizare wizard — în jurnalul aplicației apare evenimentul structurat product.three_pl_wizard_completed (ID furnizor, trial implicit, număr de companii incluse în wizard), util pentru audit și metrici interne.
3. Sănătate infrastructură — endpoint-ul GET /health (și variantele /up, /api/health) verifică printre altele baza de date, cache-ul, coada, spațiul storage și discul public (upload-uri servite prin /storage, ex. contracte PDF).

---

Cum vă ajută acest document

Întrebare	Răspuns pe scurt
Când intră mărfă în depozit?	La Intrări: după ce înregistrați o recepție reală (nu un ciornă).
Ce e ciornă (draft) la recepție sau retur?	Puteți salva incomplet; stocul nu se schimbă până publicați documentul.
În ce ordine e bine să lucrez la început?	Mai întâi date de bază (ce vindeți, unde, cu cine), apoi comenzi care mișcă marfa — vezi Ordinea recomandată.
De ce comanda de cumpărare nu e „completă” deși am recepționat?	Progresul spre „complet recepționat” se calculează în mare parte din recepțiile închise, nu din cele doar „în lucru”.
Când „se ține” marfa pentru o comandă de vânzare?	Depinde de tipul comenzii: la unele comenzi sistemul blochează cantitatea din „disponibil” încă de la creare.
Când iese marfa din depozit la livrare?	Când marcați comanda ca Livrată.
Ce se întâmplă la retur?	Marfa reintră în depozit când returul este salvat definitiv (nu neapărat când îl marcați „închis”). Detalii mai jos.
Ce se întâmplă dacă anulez?	Vezi secțiunea Anulări — pe scurt: la recepție și retur se scoate din stoc ce intrase; la comandă de vânzare se eliberează rezervarea dacă era cazul.
Unde văd ce s-a mișcat?	În istoricul / jurnalul de stoc (mișcări legate de recepții, comenzi, retururi).
Avem integrări (ERP, alt sistem)?	Sistemul poate trimite notificări automate la anumite evenimente — vezi Integrări.
Companie, furnizor și client — ce e diferit?	Vezi secțiunea Companie, furnizor și client.
Ceva „nu merge” sau nu văd documentul	Vezi Greșeli frecvente (companie greșită, recepție neînchisă, stoc rezervat).
Cum arată un flux întreg, de la capăt la capăt?	Scenariu complet (pregătire → intrare marfă → vânzare → livrare → retur).
Alte întrebări frecvente	FAQ suplimentar.
Cum se formează codurile la seeder:scmc?	Coduri demonstrative — aceleași reguli ca în aplicație prin CodeGeneratorService: companii generate (…-CC-…), articole/parteneri cu prefix cod furnizor (TPL000001-…), documente PO/REC/SO cu numerotare per furnizor.
Numele companiei sau un cod (articole, depozit) e foarte lung — ce se întâmplă exact?	Nume mare: ce se întâmplă exact — la nume firmă până la 255 caractere salvate integral (afișare cu „…”); la coduri plafon 30 caractere, cu exemplu R… dacă depășiți.

---

Structură: 3PL, companie client și depozite

Furnizorul 3PL (ThreePlProvider) este organizația logistică care operează platforma (three_pl_providers; sesiune current_three_pl_id). Compania pe care o selectați în bară este compania 3PL (Client3pl / clients_3pl; sesiune current_company_id). 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ă).

flowchart TB
  subgraph tpl ["Furnizor 3PL · three_pl_providers"]
    TPP["ThreePlProvider ex. ECC TPL000001"]
    WH["Warehouse WH-001 · three_pl_provider_id"]
    TPP --> WH
  end

  subgraph ops ["Planșă operațională · current_company_id"]
    direction LR
    C3["Client3pl — context tenant"]
    PAR["Partner — pe PO REC SO"]
  end

  OPS["Articole stoc documente · client_3pl_id"]

  TPP -->|"clients_3pl.three_pl_provider_id"| C3
  C3 --> OPS
  PAR -.->|"partners.client_3pl_id"| C3
  WH -.->|același depozit fizic pentru companiile de sub acest 3PL| C3

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 three_pl_providers (ex. Quehenberger); firmele client deservite în clients_3pl (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 seeder:scmc (ScmcDiagramSeeder): 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 CodeGeneratorService (șablon …-CC-90001101 etc.); depozite create de WarehouseSeeder: WH-001 (depozit central), WH-002 (retururi), denumiri gen „ECC - Depozit Central”; parteneri demo cu cod TPL000001-P-SUP1 / P-CUST1 etc.

---

În ce ordine lucrați (recomandare practică)

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.

---

Companie, furnizor și client — pe scurt

Î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ă”.

2. 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

Rol	Cine este	Unde îl întâlniți cel mai des
Companie	Compania 3PL în contextul căreia lucrați (stoc și documente pentru acea firmă); depozitul fizic e al 3PL	Selector companie; tot ce e „în firmă” (stoc, articole)
Partener (pe document)	Contrapartidă pe comandă: furnizor de marfă sau client la vânzare (Partner), mereu în cadrul companiei selectate	PO, recepție, SO, livrare
Furnizor (marfă)	Rol de partener: de la cine cumpărați	Comandă de cumpărare, recepție
Client (vânzare)	Rol de partener: către cine vindeți / livrați	Comandă de vânzare, livrare

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.

---

Stoc: două idei simple

Î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)

Situație	Total în depozit	Disponibil pentru comenzi noi
Aveți 100 bucăți pe raft, nimic rezervat	100	100
O comandă de vânzare „ține” 30 bucăți (tip cu verificare stoc)	100	70
După livrare a acelor 30 bucăți	70	70

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).

---

Scenariu complet: de la zero la livrare (și retur opțional)

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 seeder:scmc (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 CodeGeneratorService (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)

Element	Ce reprezintă în demo
3PL (hală)	ECC Logistics SA, în listă de obicei ca ECC
Companie (acest scenariu)	ACME Logistics (ACME Logistics SRL)
Alte companii în același demo	Global Distribution, Fast Logistics
Depozit stoc bun	ECC - Depozit Central (depozit principal de marfă „în regulă” pentru ECC)
Parteneri pe ACME	Supplier One SRL, Supplier Two SA
Articol exemplu (ACME)	TPL000001-ACM-001 — „Scanner coduri 2D industrial”, cod bare 590TPLACM00001, UM BUC
Coduri pe comenzi / recepții / livrări	Aceeași numerotare ca în producție: PO-{id_furnizor_3PL}-{nr}, REC-…, SO-… (din CodeGeneratorService / contoare per furnizor)
Conturi de probă	Adrese @scmc-demo.ro; parola comunicată echipei la pregătirea mediului (de ex. parola123 dacă așa vi s-a transmis)

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)

Pas	Ce faceți	Rezultat
1	Verificați compania corectă.	Toate pașii următori se leagă de ACME Logistics.
2	Aveți depozitul și articolul în sistem.	Puteți lega comenzi de ECC - Depozit Central și TPL000001-ACM-001.
3	Aveți Supplier One SRL și Supplier Two SA înregistrați.	Îi puteți alege pe comenzi (ca în mediul demonstrativ).

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

Pas	Ce faceți	Ce se întâmplă cu stocul (exemplu 500 buc comandate)
4	Creați comandă de cumpărare către Supplier One SRL: 500 buc TPL000001-ACM-001.	Document PO; încă nu a intrat marfa în depozit doar din simpla creare (depinde cum lucrați cu statusul „trimis”).
5	Ajunge camionul; faceți recepție pe 500 buc în ECC - Depozit Central și salvați definitiv (sau publicați ciornă).	Stoc: total +500, disponibil +500 (în absența altor comenzi).
6	Închideți recepția dacă fluxul vostru cere asta pentru raportare.	Comanda de cumpărare poate trece la complet recepționată când regulile din sistem sunt îndeplinite (inclusiv recepție închisă).

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

Pas	Ce faceți	Ce se întâmplă (tip de comandă cu rezervare)
7	Creați comandă de vânzare către Supplier Two SA: 120 buc TPL000001-ACM-001 din același depozit.	Disponibil scade la 380; total rămâne 500 până la livrare.
8	Avansați statusurile operaționale (ex. În lucru → Încărcată) după cum lucrați fizic.	Marfa încă e considerată în depozit până la livrare.

Faza 4 — Livrare (iese marfa din depozit)

Pas	Ce faceți	Ce se întâmplă
9	Marcați comanda Livrată.	Total scade cu 120 → 380; disponibil se aliniază (ex. 380 și 380 dacă nu mai sunt alte rezervări).

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

Pas	Ce faceți	Ce se întâmplă
10	Clientul returnează 20 buc; creați retur legat de comanda livrată, depozit ales, salvare definitivă.	Total +20 → 400; disponibil +20 → 400 (exemplu simplu).
11	Anulați returul din greșeală.	Cantitățile adăugate la retur se scot din stoc înapoi.

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

Moment	Total TPL000001-ACM-001	Disponibil (exemplu)
După recepție 500	500	500
După comandă vânzare 120 (rezervare)	500	380
După livrare	380	380
După retur 20	400	400

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șă.

---

1. Intrări: comandă de cumpărare → recepție → stoc

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)

Status	Ce înseamnă pentru echipă
Ciornă	Comanda nu e încă „oficială” în fluxul de trimis.
Trimisă	Ați lansat comanda; așteptați livrări.
Parțial recepționată	A intrat ceva, dar nu tot ce era pe comandă.
Complet recepționată	Cantitățile recepționate acoperă comanda (după regulile din sistem).
Anulată	Comanda nu mai este urmărită ca deschisă; nu veți mai face recepții noi pe ea.

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)

Status	Ce înseamnă
Creată	Document înregistrat; puteți trece la „în lucru” sau anula.
În lucru	Pregătiți/recepționați; apoi puteți închide sau anula.
Închisă	Recepția este considerată finalizată pentru raportare și pentru calculul „cât s-a luat din comandă”.
Anulată	Recepția nu mai este valabilă; dacă marfa intrase deja în stoc la salvarea recepției, sistemul scoate acele cantități înapoi la anulare.

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.

---

2. Ieșiri: comandă de vânzare → rezervare / livrare

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

Status	Sens pentru operator
Creată	Comandă înregistrată; urmează pregătire sau anulare.
În lucru	Se pick-uiește / se pregătește.
Încărcată	Pregătită de expediere.
Livrată	Marfa a plecat — stoc scăzut corespunzător.
Anulată	Comandă oprită; rezervările se eliberează unde e cazul.

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

---

3. Retururi: marfă înapoi dinspre client

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

Status	Sens
Creată / În lucru	Puteți edita; la salvare, stocul se aliniază cu liniile.
Închisă	Flux încheiat din punct de vedere operațional.
Anulată	Intrarea de marfă din acel retur este anulată în stoc.

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

---

Anulări — ce se întâmplă „în spate”, pe înțeles

Rezumat rapid

Ce anulați	Efect principal asupra stocului
Comandă de cumpărare	Nu scoate marfa din depozit singură; stocul s-a schimbat doar prin recepții / retururi.
Recepție	Dacă marfa intrase la salvare, la anulare se scoate acea cantitate din stoc.
Comandă de vânzare (înainte de livrare)	Se eliberează ce era ținut în „disponibil” (unde se folosește rezervarea).
Comandă de vânzare (după livrare)	Nu se „anulează livrarea” prin același flux simplu — comanda livrată e încheiată.
Retur	Se scoate din stoc ce intrase prin acel retur.

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.

---

Din fiecare status — ce aveți voie să faceți (pe scurt)

Comandă de cumpărare

Sunteți în…	În general puteți merge la…
Ciornă	Trimisă sau Anulată
Trimisă	Parțial recepționată, Complet recepționată sau Anulată (și variații afișate în interfață)
Parțial recepționată	Complet recepționată sau Anulată
Complet recepționată / Anulată	Nu mai urmează pași (final)

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

Recepție

Sunteți în…	În general puteți merge la…
Creată	În lucru sau Anulată
În lucru	Închisă sau Anulată
Închisă / Anulată	Final

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

Comandă de vânzare

Sunteți în…	În general puteți merge la…
Creată	În lucru sau Anulată
În lucru	Încărcată sau Anulată
Încărcată	Livrată sau Anulată
Livrată / Anulată	Final

Retur

Sunteți în…	În general puteți merge la…
Creată	În lucru sau Anulată
În lucru	Închisă sau Anulată
Închisă / Anulată	Final

---

Tranziții: de ce uneori butonul nu merge

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.

---

Greșeli frecvente și clarificări

Situație	Explicație
„Am recepționat, dar comanda de cumpărare nu e completă”	Verificați dacă recepțiile sunt închise și dacă suma cantităților acoperă comanda.
„Am marfă în stoc, dar nu pot promite la alt client”	Posibil ca disponibilul să fie deja blocat de comenzi în lucru; verificați comenzile de vânzare deschise.
„Am închis returul dar nu văd dublarea”	Marfa intră de obicei la salvare / publicare, nu la a doua închidere; verificați dacă returul a fost salvat definitiv.
„Am schimbat compania din bară și nu mai văd comanda”	Comenzile aparțin companiei selectate; altă companie = alt set de documente.
„Am pus Livrat dar marfa încă e în depozit”	Livrat trebuie să reflecte plecarea reală; dacă a fost o greșeală, corectați conform procedurilor interne (retur, ajustare) — nu folosiți statusul ca „probă”.
„Disponibilul și totalul nu se potrivesc cu ce număr pe raft”	Verificați recepții parțiale, comenzi în lucru (rezervare), retururi și dacă același articol e în mai multe depozite — stocul e pe combinație articol + depozit.
„Am anulat recepția dar văd încă mișcarea în istoric”	Anularea inversează stocul; în jurnal poate rămâne trasabilitatea evenimentului (ce s-a întâmplat și ce s-a corectat).
„Numele companiei e foarte lung sau conține multe cuvinte / un URL”	Vezi Nume mare: ce se întâmplă exact — două situații: nume firmă (până la 255 caractere, afișare eventual cu „…”) vs coduri (plafon 30 caractere, rezervă R… dacă depășiți).

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 CodeGeneratorService. 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 CodeGeneratorService (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.

---

Întrebări suplimentare (FAQ)

Întrebare	Răspuns scurt
Pot avea aceeași firmă ca furnizor și ca client?	În practică da (firme care vă și vând și cumpără); în sistem apar ca roluri diferite pe documente — important e să alegeți rolul corect pe fiecare comandă.
De ce nu pot sări de la „Creată” la „Închisă” la recepție?	Pentru control operațional: se înregistrează că ați preluat munca (În lucru) sau că renunțați (Anulat), nu doar „salt” final.
Comanda de cumpărare anulată scoate marfa din depozit?	Nu direct; marfa a intrat prin recepții. Dacă recepțiile erau deja făcute, ele rămân subiect separat (corectare prin recepție anulată sau ajustare, după caz).
Ce fac dacă am recepționat pe depozitul greșit?	Depinde de procedura voastră: de obicei corecție (documente/anulări) astfel încât stocul să reflecte locul real — nu există „mutare invizibilă” fără înregistrare.
Returul trebuie neapărat „închis” ca să intre marfa?	În fluxul descris aici, cantitatea reintră la salvare definitivă a returului; închis poate fi pentru închidere administrativă — verificați în aplicație dacă mai există pași obligatorii.
Unde văd întregul flux într-un exemplu?	Secțiunea Scenariu complet — același lanț, cu denumiri din mediul demonstrativ (seeder:scmc).
De ce la PO / REC / SO văd un număr după tipul documentului?	În aplicație codurile operaționale sunt per furnizor 3PL, de forma PO-{id_furnizor}-{număr} (și similar pentru REC, SO). Nu e versiune de document, ci secvență alocată automat.
De ce am patru comenzi de vânzare cu statusuri diferite?	În datele de probă sunt puse adesea patru comenzi ca să vedeți fiecare status în parte, de la creat la livrat.
Pe Global Distribution, un „client” apare și la achiziție?	În exemplul de probă, primul partener din listă poate fi folosit și pe comandă de cumpărare — e doar pentru demonstrație, nu o regulă comercială.
Unde sunt articolele TPL000001-ACM / TPL000001-GLB / TPL000001-FST?	Secțiunea Coduri demonstrative (structură + tabele). În aplicație: catalogul companiei demo respective.
Cine poate descărca backup-ul unei companii client?	Administratorul firmei (rol admin pe acea companie) vede doar backup-urile firmei sale. Echipa furnizorului 3PL (rol admin la furnizor) poate accesa backup-urile tuturor companiilor client de sub același furnizor — pentru suport operațional. Nu se folosește accesul generic „orice companie de sub furnizor” pentru utilizatori doar pe o firmă client.

---

Coduri în mediul demonstrativ (seeder:scmc) — o structură pentru tot

Î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 (CodeGeneratorService) 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: CodeGeneratorService

• Î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 seeder:scmc (comod pentru echipă); asta nu înseamnă că codurile din baza de date trebuie să înceapă cu SCMC-.

Verificare față de codul sursă (seeder:scmc)

• Comanda php artisan seeder:scmc (clasa App\Console\Commands\SeederScmc) rulează migrate:fresh cu --seeder=Database\Seeders\SeederScmcRunner, apoi cache:clear.
• SeederScmcRunner apelează ScmcDiagramSeeder, 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, WarehouseSeeder, 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 )

Părți	Ce înseamnă în cuvinte simple
COD3PL	Codul intern al furnizorului 3PL din baza de date — în aplicație adesea seria TPL + 6 cifre (ex. TPL000001). Denumirea afișată poate fi ECC; nu trebuie să coincidă cu literele codului.
TIP	Ce fel de lucru e: la companii client folosiți în practică segmentul CC din generateClientCode (ex. TPL000001-CC-90001101); P = partener; PO / REC / SO = documente; ACM / GLB / FST = segment scurt de catalog în demo, etc.
DETALIU	Numele scurt al firmei, număr de articol, cod depozit scurt, rol (SUP1, CUST1)…

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

• 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).

Cod intern companie (demo, exemplu)	Cum se citește	Prefix articol	Articole (5 buc.)
TPL000001-CC-90001101 (ACME)	furnizor TPL000001 + CC + CUI	TPL000001-ACM	TPL000001-ACM-001 … 005
TPL000001-CC-90001102 (Global)	idem	TPL000001-GLB	TPL000001-GLB-001 … 005
TPL000001-CC-90001103 (Fast)	idem	TPL000001-FST	TPL000001-FST-001 … 005

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 CodeGeneratorService (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 seeder:scmc, 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ă.

Situație	Unde merge textul lung	Cod articol demo (ACME)
Denumire foarte lungă la firmă	Fișă companie, liste	TPL000001-ACM-001 (neschimbat)
Descriere lungă la produs	Catalog / articol	TPL000001-ACM-001 (neschimbat)
Ați vrea și codul articolului la fel de lung	Plafon 30 caractere la salvare/import; peste limită → cod rezervă R… (vezi paragraful de mai sus)	În tabelele de mai jos: mereu TPL000001-ACM-001 … 005

ACME (TPL000001-ACM-*)

Cod articol	Descriere	Cod de bare (UM principală)
TPL000001-ACM-001	Scanner coduri 2D industrial	590TPLACM00001
TPL000001-ACM-002	Etichete termice 100x150mm	590TPLACM00002
TPL000001-ACM-003	Transpalet manual 2500 kg	590TPLACM00003
TPL000001-ACM-004	Folie stretch 23 µm	590TPLACM00004
TPL000001-ACM-005	Mănuși nitril M cutie 100	590TPLACM00005

Global (TPL000001-GLB-*)

Cod articol	Descriere	Cod de bare
TPL000001-GLB-001	Bax apă minerală 6×1,5L	590TPLGLB00001
TPL000001-GLB-002	Snack mix sărat 150g	590TPLGLB00002
TPL000001-GLB-003	Cafea boabe 1 kg	590TPLGLB00003
TPL000001-GLB-004	Lapte UHT 3,5% 1L	590TPLGLB00004
TPL000001-GLB-005	Hârtie igienică 10 role	590TPLGLB00005

Fast (TPL000001-FST-*)

Cod articol	Descriere	Cod de bare
TPL000001-FST-001	Cutie carton triplu strat	590TPLFST00001
TPL000001-FST-002	Bandă adezivă PP 48mm	590TPLFST00002
TPL000001-FST-003	Pungi courier biodegradabile	590TPLFST00003
TPL000001-FST-004	Document pouch A4	590TPLFST00004
TPL000001-FST-005	Role termice 80mm	590TPLFST00005

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).

---

Istoricul mișcărilor de stoc

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.

---

Integrări (notificări către alte sisteme)

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.