Multi-POS — mai multe puncte, zero conflicte

• Cui vorbim:* manager / proprietar care operează 2-10 puncte de vânzare.

Ce înseamnă "multi-POS" la noi

Fiecare punct de vânzare (magazin, locație, casă din mall) este o entitate distinctă în sistem, cu:

• Catalog comun — produsele sunt definite o singură dată, dar fiecare POS poate avea prețuri proprii, stoc propriu, taxe diferite (zonă HoReCa vs. magazin, de exemplu).
• Operatori scoped — un casier de la POS 1 nu vede / nu modifică stocul POS 2 decât dacă i se dă explicit acest drept.
• Rapoarte separate ȘI consolidate — vezi performanța per locație, dar și total lanț.

Scenariu: lanț 4 puncte

        ┌── Magazinul Centru (POS-001)
        │     casier: maria, casier: ion
        ├── Magazinul Botanica (POS-002)
LANT ───┤     casier: andrei
        ├── Magazinul Riscani (POS-003)
        │     casier: oxana, manager: vlad
        └── Magazinul Buiucani (POS-004)
              casier: dorin

Maria de la Centru vinde un produs → stocul POS-001 scade. Andrei de la Botanica vinde simultan altceva → stocul POS-002 scade. Operațiunile lor nu se blochează una pe alta. Sistemul actualizează doar punctul respectiv, fără ca cele 4 puncte să "concureze" pentru aceeași resursă.

Transferuri inter-POS

Cazul tipic: "trimite-mi 30 de bucăți"

1. Vlad (manager Riscani) vede că s-a terminat un produs popular.
2. Deschide ecranul Transferuri → caută produsul → vede stocul disponibil per punct.
3. Inițiază un transfer: 30 buc. de la POS-002 (Botanica) → POS-003 (Riscani).
4. Andrei de la Botanica primește notificare → confirmă (sau refuză cu motiv) că poate trimite.
5. Marfa pleacă fizic → în sistem e transferată pe POS Auto-01 (autoturismul transportator, modelat ca POS mobil cu propriul stoc & jurnal); stocul scade de la POS-002, urcă pe Auto-01, nu încă creditată la POS-003 — vezi natural unde fizic se află marfa.
6. La sosire, Vlad confirmă recepția → transfer Stoc Auto-01 → POS-003; stocul scade pe autoturism, urcă la destinație.
7. Tot procesul e logat: cine a inițiat, cine a aprobat, cine a expediat, cine a recepționat, când.

Cazul transferului centralizat

Pentru lanțuri cu depozit central (vezi Multi-depozit), transferurile pot fi:

• Pull — POS-ul cere de la depozit (workflow de mai sus).
• Push — depozitul împinge automat când stocul POS-ului scade sub minim (configurabil per produs / per POS).

Permisiuni granulare per POS

Fiecare drept poate fi limitat la unul sau mai multe POS-uri. Exemple reale:

casier oxana   → vinde la POS-003 (Riscani), nu poate la altele
manager vlad   → vinde + aprobă transferuri la POS-003
director       → vede rapoarte la toate POS-urile, nu vinde nicăieri
contabil       → vede doar rapoartele financiare consolidate

Sistemul nostru de permisiuni acceptă scoping pe POS direct în textul rolului — exemple:

STOCK_TRANSFER:POS:POS-002:POS-003          → poate transfera DOAR Botanica → Riscani
E_FACTURA_STOCK_SELL:POS:POS-001            → poate emite e-Factura DOAR la Centru
FOLDER_INVOICE__VIEW                         → vede facturile (toate POS-urile)
FOLDER_INVOICE__VIEW:POS:POS-003             → vede facturile DOAR de la Riscani

Drept urmare: fiecare operator are exact ce-i trebuie, nici mai mult, nici mai puțin.

Performanță stabilă cu mulți operatori

În Retail Mare cu 10 POS-uri și 30 de operatori, sistemul a fost gândit să nu se "trezească" niciodată cu un punct de vânzare blocat pentru că alt punct salvează ceva. Modificările pe stocul fiecărui punct se fac independent — nimeni nu așteaptă pe nimeni.
Concret: dacă 5 casieri scanează simultan produse pe 5 puncte diferite, fiecare bon iese în <1 secundă, indiferent de încărcătura celorlalți.

Audit transferuri

Fiecare transfer are propriul jurnal:

• Cine a inițiat (operator + rol).
• Când (timestamp la secundă).
• Ce (produse + cantități).
• De la / către (POS sursă + POS destinație).
• Status la fiecare pas (cerut / aprobat / expediat / recepționat / anulat).
• Comentarii (opțional, pentru context: "marfa pentru Black Friday", "urgent înainte de weekend").

Toate înregistrările sunt inalterabile prin proiectare — interfața normală nu permite ștergerea istoriei sau modificarea retroactivă. Operatorii non-admin nu pot edita istoria în niciun fel. Administratorul contului are acces deplin la propria platformă și răspunde pentru acțiunile lui. Pentru audit / suspectare furt → în 1 click vezi exact ce s-a întâmplat.

Următorul pas

→ Multi-depozit, e-Factura B2B sau roluri & permisiuni.