Planificare bazată pe comenzi de vânzare

La confirmarea unei comenzi de vânzare, modulul execută automat:

1. Netting produs finit (proiecție cronologică) — înainte de orice calcul, verifică dacă stocul proiectat la commitment_date acoperă cantitatea din SO:

   projected_qty = qty_on_hand
                 + intrări confirmate cu dată ≤ commitment_date   (PO receipts, MO)
                 − ieșiri confirmate cu dată ≤ commitment_date    (alte SO-uri, mișcări independente)
                 − cerere AP planned ale altor SO-uri `sent`      (fără stock.moves încă)
   

   • SO draft / sale / done: dacă projected_qty ≥ qty_needed → marcat ok, AP sărit.
     • draft: simulare — AP-urile draft nu afectează netting-ul.
     • sale/done: stock.moves deja create de Odoo → cererea vizibilă în Situație Material fără AP suplimentar.
   • SO sent: AP se generează întotdeauna (planned), indiferent de stoc, pentru că Odoo nu creează stock.moves la trimitere (ci doar la confirmare). AP-ul planned face cererea vizibilă în Situație Material și este scăzut din projected_qty al SO-urilor ulterioare via _compute_sent_ap_demand(). Ieșirile după commitment_date nu reduc disponibilul calculat — corect cronologic.

2. Explozie BOM recursivă — descompune produsul finit pe toate nivelurile (subansamblu → componentă → materie primă), colectând necesarul brut per componentă.

3. Netting componente — scade din necesarul brut stocul disponibil și cantitățile așteptate din comenzi de achiziție cu dată recepție ≤ commitment_date (intrările după termenul dorit nu reduc necesarul calculat — corect cronologic), obținând necesarul net de aprovizionat per componentă. La planificarea globală (batch), netting-ul componentelor folosește un dict de alocare globală partajat între toate SO-urile din rulare: SO/002 vede stocul redus cu cantitățile deja consumate de SO/001, prevenind supraplanificarea aceluiași stoc pentru cereri multiple.

4. Backward scheduling cu RCCP — pornind de la commitment_date, calculează înapoi pe calendar de lucru:

   • ✓data finalizare producție (date_planned_production_end)
   • ✓data start producție / disponibilitate materiale (date_planned_production_start)
   • ✓data lansare comenzi de achiziție (date_planned_launch)
   • ✓data recepție componentă (date_po_reception) — garantată ≤ start producție

   ``production_lead_time`` este calculat prin RCCP (Rough-Cut Capacity Planning): operațiile BOM sunt grupate pe workcenter, iar lead time-ul este determinat de workcenter-ul critic (bottleneck):

   qty_factor       = ceil(qty_comandata / bom.product_qty)
   ore_necesare_WC = (setup + Σ time_cycle_manual × qty_factor + cleanup) / 60
   ore_efective_zi = ore_calendar_WC × (time_efficiency / 100)
   zile_WC         = ceil(ore_necesare_WC / ore_efective_zi)
   
   production_lead_time = max(zile_WC)   ← workcenter-ul bottleneck
   

   setup / cleanup (time_start, time_stop) sunt overhead fix per WC și nu se scalează cu cantitatea. time_cycle_manual (min/unitate) se înmulțește cu qty_factor — o comandă de 100 buc durează proporțional mai mult decât una de 1 buc. Dacă produsul are ap_production_lead_time setat manual, RCCP este ignorat.

   Dacă datele ar fi în trecut, planificatorul comută automat pe forward scheduling de la data curentă, marcând comanda ca blocked și propunând cea mai devreme dată realizabilă.

5. SO fără commitment_date — planificatorul calculează forward și propune automat cea mai devreme dată de livrare posibilă (forward + safety buffer), fără să marcheze ca blocat.

6. Validare plauzibilitate — verdict automat în trei stări:

   • OK
     — marjă suficientă față de safety buffer configurat
   • Avertisment
     — marjă sub safety buffer, dar realizabil
   • Blocat
     — data de livrare este imposibilă; se propune cea mai devreme dată realizabilă

7. Comenzi planificate — creează înregistrări advanced.planned.order de tip producție (cu ierarhie BOM) și de tip achiziție (per componentă cu shortage), cu toate datele calculate. Comenzile de achiziție (RFQ) și de producție (MO) nu sunt generate automat — se lansează manual din formularul comenzii planificate, după revizuire.

8. Replanificare automată la modificarea SO — când commitment_date se schimbă pe un SO confirmat (state == 'sale') și opțiunea ap_auto_replan_on_so_change este activată, planificatorul re-rulează automat, fără intervenție manuală. Un guard de context (ap_skip_replan) previne recursivitatea cu scrierile interne ale motorului.

9. Detecție abateri zilnică (Cron) — un job programat zilnic detectează automat abaterile față de planul inițial:

   • PO nelansat
     date_planned_launch a trecut și AP-ul nu are PO asociat (→ warning / blocked după 2 zile)
   • PO întârziat
     un PO confirmat asociat unui AP copil are date_planned > date_po_reception (→ warning / blocked după 5 zile)
   • MO blocat
     MO confirmat cu date_start în trecut și producție neîncepută (→ blocked)
   • Avertizare preventivă
     lansare PO iminentă (< 2 zile) fără RFQ generat (→ warning)

   La detectare: actualizează planning_status, setează ap_deviation_reason, postează notă în chatter SO, creează activitate Odoo atribuită responsabilului SO. Câmpul ap_blocked_since înregistrează prima dată a tranziției în blocked.

10. Escaladare automată a activităților — dacă un AP rămâne în starea blocked mai mult de N zile (configurabil din Setări — Escalation threshold), planificatorul actualizează scadența activităților expirate la azi și postează o notă de escaladare în chatter-ul SO. Dezactivat când pragul = 0.

11. Consolidare automată RFQ-uri — la generarea unui RFQ dintr-un AP de tip achiziție, dacă există deja un draft PO pentru același furnizor cu date_order în fereastra ±ap_rfq_consolidation_window_days față de date_planned_launch, se adaugă o linie nouă la PO existent în loc să se creeze un PO separat. Relația AP ↔ PO este Many2many (ap_purchase_order_rel), permițând unui PO consolidat să fie legat de multiple AP-uri. Fereastra se configurează din Setări; valoarea 0 dezactivează consolidarea.

12. Sincronizare mișcări de livrare — pentru comenzile de vânzare confirmate, planificatorul actualizează automat mișcările de stoc de tip livrare (outgoing):

    • ✓stock.move.advanced_planned_order_id ← legătura directă la comanda planificată AP
    • ✓stock.move.date ← data efectivă de livrare calculată (ap_effective_date)
    • ✓stock.picking.scheduled_date ← sincronizată cu data efectivă de livrare Astfel, data promisă clientului reflectă imediat rezultatul planificatorului în documentele operaționale de stoc, iar traseul SO → AP → livrare este complet vizibil în Situație Material.

13. Log execuție — fiecare rulare generează înregistrări detaliate în advanced.planner.log, cu pas, severitate și detalii tehnice, accesibile din formularul comenzii planificate.

Reaprovizionare independentă (mișcări fără SO)

Planificatorul global analizează și mișcările de stoc de ieșire care nu sunt legate de o comandă de vânzare (ex: transferuri, consum intern, ajustări planificate). Dacă stocul proiectat devine negativ, se generează automat AP-uri de reaprovizionare.

Algoritmul:

pentru fiecare produs cu mișcări outgoing confirmate fără SO:
    running_stock = qty_on_hand + intrări_confirmate_PO_MO
    pentru fiecare mișcare în ordine cronologică:
        running_stock -= move.product_uom_qty
        dacă running_stock < 0:
            generează AP pentru shortage_qty = -running_stock
            running_stock = 0   (AP-ul acoperă deficitul)

AP-urile de reaprovizionare:

• ✓is_replenishment = True — distinse de AP-urile SO-based
• ✓sale_order_id = False — nu sunt legate de nicio comandă de vânzare
• ✓replenishment_picking_id — picking-ul care cauzează primul deficit
• ✓Tip manufacture dacă produsul are BOM, purchase dacă nu
• ✓Backward scheduling de la data mișcării deficitare; forward fallback dacă data e în trecut
• ✓state = draft — necesită revizie manuală înainte de conversie în PO/MO
• ✓Regenerate complet la fiecare rulare (cele nefixate sunt șterse și recreate)

Probleme rezolvate față de planificarea Odoo nativă

Fluxul de bază în 4 pași

SO confirmat
    ↓
Backward scheduling (commitment_date → date_start, date_launch)
    ↓
Netting componente (cu filtrare pe dată și alocare globală)
    ↓
Verdict: OK / Warning / BLOCKED + data alternativă dacă e blocată

Ce rămâne în afara modulului

Modulul nu face optimizare de secvență (setup-uri, campanii, penalizări, JIT) și nu are motor de simulare what-if. Pentru aceste cerințe sunt necesare soluții dedicate APS (APS4MFG, frePPLe). Modulul este complementar acestora, nu concurent.

2.1 Activarea planificării per produs

Pe fiecare produs care trebuie inclus în analiză:

Produs → tab Planificare Advanced Planner

• Inclus în planificare
  (ap_include_in_planning): bifat → produsul apare în Situația Material și este luat în calcul la netting
• Lead time producție manual
  (ap_production_lead_time): completați doar dacă doriți să suprascrieți RCCP calculat din operațiile BOM; lăsați 0 pentru calcul automat
• Note planificare
  text liber vizibil în comenzile planificate generate

2.2 Lead time furnizori (MOQ și delay)

Pe fiecare materie primă/componentă cumpărată:

Produs → tab Achiziție → Prețuri furnizori

Dacă un produs cumpărat nu are furnizor configurat cu Vendor Lead Time, planificatorul folosește parametrul global „Lead time achiziție implicit”.

2.3 Structuri de produs (BOM) cu operații RCCP

Pentru calculul automat al lead time-ului de producție prin RCCP:

Producție → Produse → Structuri de produs → tab Operații

Adăugați câte o operație per post de lucru (workcenter) implicat:

RCCP determină production_lead_time = cel mai lent workcenter (bottleneck):

qty_factor = ceil(qty_comandata / bom.product_qty)
ore_WC = (wc.time_start + op.time_cycle_manual × qty_factor + wc.time_stop) / 60
zile_WC = ceil(ore_WC / (ore_calendar_zi × eficienta%))
production_lead_time = max(zile_WC pentru toate WC-urile)

time_start / time_stop (setup/cleanup) sunt overhead fix per WC — nu se scalează cu cantitatea. time_cycle_manual (min/unitate) se înmulțește cu qty_factor — o comandă de 100 buc durează mult mai mult decât una de 1 buc; ignorarea acestui factor ducea la subestimarea lead time-ului.

Flux

1. Creați o comandă de vânzare (draft) cu produsul și cantitatea dorită
2. Setați Data livrare dorită (commitment_date) — dacă este lăsată goală, planificatorul calculează cea mai devreme dată posibilă (forward scheduling)
3. Pe formularul SO, apăsați butonul „Recalculează planificarea” (sau deschideți wizardul din acțiunile SO)
4. Planificatorul calculează și afișează:
   • Statusul (OK / WARNING / BLOCKED) pe bannerul colorat din header-ul SO
   • Data efectivă calculată (ap_effective_date) — data la care produsul poate fi livrat
   • Comenzile planificate generate în starea draft (nu afectează netting-ul celorlalte comenzi)

Ce se întâmplă la trimiterea ofertei (SO → sent)

Când trimiteți oferta clientului, planificatorul comută automat AP-urile din draft → planned. Din acel moment, cererea acestui SO intră în netting și este vizibilă în Situație Material pentru celelalte comenzi.

Dacă retrageți oferta (SO → înapoi în draft), AP-urile nefixate revin automat în draft.

AP-urile fixate (is_fixed = True) sunt excluse din tranzițiile automate — rămân în starea curentă indiferent de starea SO.

Recalculare manuală după confirmare

Dacă s-au schimbat stocurile sau termenul clientului, recalculați fără a reconfirma comanda:

SO → buton „Recalculează planificarea” (sau din lista SO: Acțiune → Recalculează planificarea)

Replanificare automată la modificarea datei

Dacă opțiunea „Replanificare la schimbare dată SO” este activată în Setări, modificarea câmpului Data livrare dorită pe un SO confirmat declanșează automat recalcularea planificatorului — fără a apăsa niciun buton. Statusul și comenzile planificate se actualizează imediat.

Bannerul de status pe SO

Câmpuri cheie pe SO (header)

Câmpuri cheie pe liniile SO

Logica marjei

margine = (data_lansare_comanda_achizitie - azi).zile

margine ≥ safety_buffer  → OK
0 ≤ margine < safety_buffer → WARNING
margine < 0              → BLOCKED (data_lansare_comanda deja în trecut)

Stări posibile

Tipuri de comenzi planificate

Ierarhia AP

Un AP de producție (produs finit) are copii (sub-AP) pentru fiecare componentă în deficit:

AP/00007 — Manufacture PF-001 × 5         (produs finit)
  ├── AP/00008 — Purchase MP-02 × 10      (sticlă, 28 zile lead time — critică)
  ├── AP/00009 — Purchase MP-01 × 108     (celule, 10 zile lead time)
  └── AP/00010 — Purchase MP-03 × 12      (profil aluminiu, 10 zile lead time)

Ierarhia este vizibilă în vizualizarea Gantt (Advanced Planning → Production Plan — Gantt).

Fixarea comenzilor planificate

Bifați „Fixat” (is_fixed) pe un AP pentru a-l proteja de recalculări automate ulterioare. AP-urile fixate:

• ✓Nu sunt șterse la recalculare globală
• ✓Nu schimbă starea la modificarea SO-ului (nu urmăresc draft ↔ planned)
• ✓Contribuie la netting ca stoc virtual (cantitatea lor este scăzută din necesarul net)

AP Purchase → Request for Quotation

Buton „Creează RFQ”

• Consolidare automată
  — înainte de a crea un PO nou, planificatorul caută un draft PO existent pentru același furnizor cu date_order în fereastra ±N zile (configurabil în Setări, implicit 3).

  • Dacă găsit: adaugă o linie nouă la PO existent; AP-ul e legat la acel PO prin relația Many2many
  • Dacă nu găsit: creează PO nou ca de obicei
• ✓AP trece în starea done în ambele cazuri
• ✓Mesajul din chatter AP indică dacă s-a creat un PO nou sau s-a consolidat într-unul existent
• ✓Setați fereastra la 0 în Setări pentru a dezactiva consolidarea și a crea mereu PO-uri separate

AP Manufacture → Manufacturing Order

Buton „Creează MO”

• ✓Creează un mrp.production cu produsul, cantitatea și data start din AP
• ✓Verifică duplicatele similare
• ✓AP trece în starea done după confirmare MO

Atenție: Generarea PO/MO este intenționat manuală — planificatorul nu lansează automat comenzi. Revizuiți AP-urile înainte de conversie, mai ales cele în stare WARNING sau BLOCKED.

Deschidere

Opțiunea 1 — Din meniu: Advanced Planning → Material Situation → selectați produsul → „Reîmprospătează”

Opțiunea 2 — Din comanda planificată: Pe formularul AP → buton „Situație Material (Situație Material)” → se deschide direct filtrat pe produsul AP

Cum se citește Situație Material

Liniile sunt sortate cronologic. Fiecare linie arată:

Cod culoare rânduri

• Verde
  — intrare în stoc (PO, MO, AP, recepție)
• Roșu
  — ieșire din stoc (SO, livrare)
• Rând roșu
  — stocul proiectat a intrat în negativ (deficit)
• Rând portocaliu
  — stocul proiectat este exact zero

Deschidere

Opțiunea 1 — Din meniu: Advanced Planning → Stoc Proiectat → selectați produsul → „Reîmprospătează”

Opțiunea 2 — Din comanda planificată: Pe formularul AP → buton „Stoc Proiectat” → se deschide direct pentru produsul AP

Coduri Element MRP

Coloane principale

Algoritm Pegging FIFO

Fiecare cerere (sortată cronologic) este acoperită mai întâi din stocul disponibil, apoi din prima ofertă disponibilă cronologic. Rezultatul apare în coloana Pegging:

• pe cerere: „acoperit de PO/00003, Stoc”
• pe ofertă: „pentru SO/00012, SO/00015”

Export Excel

Butonul „Export Excel” (vizibil când există linii) descarcă un fișier .xlsx cu 11 coloane inclusiv pegging, ATP, shortage, coduri element MRP — gata de analiză.

Filtre disponibile

Rapoarte disponibile

PO → AP (linie comandă achiziție)

Când data de recepție planificată (date_planned) se modifică pe o linie de PO:

1. Planificatorul actualizează date_po_reception pe AP-urile asociate aceluiași produs
2. Postează o notă automată în chatter-ul AP cu vechea și noua dată
3. Dacă noua dată de recepție depășește date_planned_production_start al AP-ului parent:
   • AP parent → planning_status = warning (întârziere ≤ 2 zile) sau blocked (> 2 zile)
   • Se salvează motivul în ap_deviation_reason
   • Se postează notă în chatter AP și în chatter SO (dacă AP e root)
4. Cascada continuă recursiv upstream: componentă → parent → bunic → rădăcină BOM

MO → AP (ordin de producție)

Când data de start sau finalizare (date_start / date_finished) se modifică pe un MO:

1. Planificatorul actualizează date_planned_production_start / date_planned_production_end pe AP-ul asociat
2. Postează notă în chatter AP cu detaliile modificării
3. Dacă date_finished depășește ap_effective_date (data livrare planificată):
   • AP → warning (întârziere ≤ 2 zile) sau blocked (> 2 zile)
   • Se postează notă și în chatter-ul SO

Protecții

• AP fixat (is_fixed = True): exclus din sincronizare — nu este modificat automat
• Guard anti-recursie: cheia de context ap_skip_sync previne bucle infinite între hook-uri

Comparație directă

Fluxul de date

Planificare globală (Global Planning)
       │
       │ generează automat
       ▼
advanced.workcenter.load   ← date brute, una per AP per WC
       │
       │ Wizard „Nivelare CRP" → Actualizează CRP → _run_crp()
       │ agregă per (workcenter × săptămână × companie)
       ▼
advanced.crp.slot          ← agregat, cu capacitate și status
       │
       │ Wizard „Nivelare CRP" → Actualizează + Nivelează
       ▼
AP-uri mutate cu +7 zile (doar cele neFixate)

Când să folosești fiecare raport

Workcenter Load — răspunde la întrebări de tip drilldown:

• ✓„Ce AP-uri exacte generează supraîncărcarea pe WC-ul X în săptămâna 20?”
• ✓„Câte ore planifică SO/00042 pe WC-ul de sudură?”
• ✓„Care sunt AP-urile blocate asociate cu WC-ul de asamblare?”

CRP — Capacitate — răspunde la întrebări de tip management:

• ✓„Avem supraîncărcare undeva în orizont de 8 săptămâni?”
• ✓„Pe WC-ul de vopsire, care săptămâni depășesc 100% din capacitate?”
• ✓„Dacă nivelăm supraîncărcările, câte AP-uri trebuie reprogramate?”

Ordinea corectă de utilizare:

1. Rulați Global Planning (generează / actualizează Workcenter Load)
2. Deschideți Nivelare CRP → apăsați „Actualizează CRP” (creează/actualizează sloturile CRP)
3. Vizualizați CRP — Capacitate pentru overview și nivelați dacă e necesar
4. Reveniți la Workcenter Load pentru drilldown pe AP-urile specifice

Ce reprezintă o înregistrare

Fiecare rând din Workcenter Load este o pereche (AP × workcenter):

• AP/00007 — producție produs X — utilizează WC Sudură → 12h planificate săptămâna 20
• AP/00007 — producție produs X — utilizează WC Vopsire → 8h planificate săptămâna 21

Același AP generează atâtea înregistrări câte workcenter-e folosesc operațiile din BOM-ul său.

Vizualizări disponibile

Cod culoare load%

Filtre rapide

• „Supraîncărcat”
  — afișează doar înregistrările cu load% > 100%
• „Critic”
  — afișează load% > 80%
• „Blocat”
  — afișează doar AP-urile cu status blocked

Datele de Workcenter Load sunt regenerate automat la fiecare rulare a planificatorului. Nu editați manual înregistrările — ele vor fi suprascrise la următoarea planificare.

Deschidere

Advanced Planning → CRP — Capacitate

Lista afișează câte un rând per (workcenter × săptămână), cu colorare automată:

• Roșu
  — load > 100% (supraîncărcat)
• Galben
  — load 80–100% (critic)
• Verde
  — load ≤ 80% (normal)

Ce arată un slot CRP

Formularul fiecărui slot afișează lista AP-urilor individuale cu orele respective.

Vizualizări disponibile

Acțiunile disponibile din CRP și impactul lor

Există trei acțiuni distincte, cu efecte și consecințe diferite asupra replanificării.

Fluxul complet recomandat după nivelarea efectivă

1. [Dry Run]       Actualizează + Nivelează (Doar vizualizare bifat)
                   → verificați statisticile: câte AP-uri vor fi mutate, câte sloturi irezolvabile

2. [Revizuire]     Deschideți Workcenter Load sau Planned Orders
                   → identificați AP-urile cu margin_days redus care ar urma să fie mutate
                   → fixați (is_fixed = True) cele pe care NU vreți să le mutați automat

3. [Nivelare]      Actualizează + Nivelează (Doar vizualizare debifat)
                   → AP-urile eligibile primesc date_start/date_end/ap_effective_date + 7 zile
                   → AP-urile copil neFixate primesc automat același +7 zile (cascadă recursivă)

4. [Verificare]    Planned Orders → filtrați după SO-urile afectate
                   → verificați că noile date_end nu depășesc commitment_date al SO
                   → AP-urile al căror ap_effective_date a depășit commitment_date trebuie
                     analizate manual (comunicare cu clientul sau redistribuire manuală)

5. [Replanificare completă]  Global Planning (rulare completă) — recomandat după nivelare
                   → reface backward scheduling pentru toate SO-urile
                   → recalculează netting-ul cu noile date (stoc proiectat, deficit/surplus)
                   → actualizează statusul SO-urilor (OK / WARNING / BLOCKED)
                   → actualizează scheduled_date pe mișcările de picking

6. [Re-actualizare CRP]   Actualizează CRP (Acțiunea 1)
                   → sloturile CRP reflectă starea exactă după replanificare
                   → verificați că supraîncărcările au dispărut sau s-au redus

Regula de aur: Nivelarea CRP deplasează AP-urile (inclusiv copiii BOM) dar nu recalculează netting-ul și nu actualizează statusul SO. Urmați întotdeauna nivelarea cu o rulare de Global Planning pentru a reface coerența completă a planului (netting, status SO, date livrare).

Raport statistici post-nivelare (wizard)

Protecții nivelare

• AP fixat
  (is_fixed = True): niciodată mutat — marcat explicit de utilizator ca imuabil
• AP done / cancelled
  exclus din nivelare indiferent de load%
• Dry run
  niciun AP nu este modificat; statisticile sunt pur informative

Când se activează

Rulați Global Planning → planificatorul analizează, după procesarea SO-urilor, toate mișcările outgoing confirmate fără SO sursă.

Cum să identificați AP-urile de reaprovizionare

Advanced Planning → Planned Orders → filtru „Reaprovizionare”

Caracteristici:

• ✓Câmpul „Reaprovizionare” (is_replenishment) = bifat
• Comandă de vânzare
  = gol (nu sunt legate de niciun SO)
• Picking sursă
  (replenishment_picking_id) = transferul care a generat primul deficit
• ✓Stare: draft — necesită revizie înainte de conversie în PO/MO

Activare

Inventar → Configurare → Setări → Advanced Planner → „Detecție abateri zilnică” → bifați

La activare, cronul Planificator avansat — detecție abateri zilnică devine activ și rulează zilnic.

Ce verifică cronul

Ce face la detectare

1. Actualizează planning_status → warning sau blocked pe AP și pe SO
2. Salvează motivul abaterii în câmpul Deviation Reason (vizibil pe formularul AP, banner portocaliu)
3. Înregistrează data primei tranziții blocked în câmpul Blocked Since
4. Postează o notă automată în chatter-ul SO: ⚠️ sau 🔴 + detalii abatere
5. Creează o activitate Odoo pe SO, atribuită responsabilului SO (user_id):
   • Scadență 1 zi dacă status = blocked
   • Scadență 3 zile dacă status = warning
   • Nu creează duplicate dacă există deja o activitate cu același AP

Escaladare automată

Dacă un AP rămâne în starea blocked mai mult de N zile (configurabil în Setări — „Prag escaladare”, implicit 3 zile):

• Scadența activităților expirate (nerezolvate) pe SO este actualizată la data de azi
• Se postează o notă 🚨 de escaladare în chatter-ul SO cu numărul de zile blocate

Pentru a dezactiva escaladarea, setați pragul la 0.

Câmpuri noi pe AP

Grupuri disponibile

Configurare utilizatori

Setări → Utilizatori → utilizatorul dorit → secțiunea Advanced Planner

Selectați User sau Manager din dropdown.

Acțiuni disponibile per rol