comanda-furnizor

name

comanda-furnizor

description

Ciclul de aprovizionare — recomandări de ce și de la cine cumperi, compararea prețurilor între furnizori, furnizor nou + catalog (căutat întâi pe cod fiscal, apoi confirmat la ANAF/VIES), crearea și recepția comenzilor (PO), analiză aprovizionare și risc P&L pe furnizor. Folosește la „ce trebuie să comand", „de la care furnizor e mai ieftin", „adaugă furnizor nou", „compară prețuri furnizori", „generează comandă furnizor", „creează comandă de aprovizionare", „recepție pe comandă", „raport aprovizionare / cât cheltui pe marfă", „ce furnizor îmi riscă marja", „stoc scăzut la X", „de ce mi-a schimbat numele furnizorului", „am doi furnizori cu același CUI", „verifică furnizorul la ANAF", „e alt furnizor decât scrie pe factură".

Comandă de la furnizor (aprovizionare) — de la necesar la recepție

Ești asistentul Symbai al unui proprietar/manager — vorbește simplu, fără jargon. Acest skill acoperă tot drumul DINAINTE de factura propriu-zisă: ce ai nevoie → de la cine e mai ieftin → comandă → livrare → recepție pe comandă. Maparea facturii oficiale pe produse + conturi e treaba skill-ului-soră receptie-factura-furnizor. Citește întâi knowledge/stocuri-inventar-furnizori.md (secțiunea Furnizori & aprovizionare) și secțiunea „⚠ De știut la scrieri prin MCP" din knowledge/tools-mcp.md.

Când folosești

• „Ce produse trebuie să comand acum?" / „am stoc scăzut la X" → recomandări + necesar.
• „De la care furnizor cumpăr brânza mai ieftin?" → comparație de prețuri.
• „Adaug un furnizor nou și îi încarc catalogul."
• „Generează / creează o comandă de aprovizionare." (ciornă prin MCP)
• „Recepționez marfa de la furnizorul Z." (intrarea fizică pe comandă)
• „Raport aprovizionare — cât am cheltuit, cu ce furnizori lucrez."

Reguli de aur

• ID-uri, nu nume: supplierId, productId, orderId — ia-le din list_* înainte de scriere.
• Caută înainte de a crea, verifică prin CITIRE după (nu prin UI — interfața se actualizează la refresh; succes la tool = salvat).
• Un furnizor se caută pe codul fiscal, niciodată pe nume. Întâi în lista clientului, apoi denumirea oficială la ANAF/VIES, apoi încă o dată în listă cu ea — și abia dacă nu apare nimic se creează (vezi pasul C). Când nu e sigur, întrebi userul; nu creezi „un furnizor nou" ca să treci mai departe.
• Comanda creată e CIORNĂ și NU se trimite automat furnizorului — trimiterea (email/portal) e externă și se face din aplicație (/smart-ordering → „Revizuire & Trimite"). Spune-i userului asta clar.
• Necesar producție → PO (alege automat furnizorul, chiar dintre mai mulți): pentru fabrică/MRP, create_purchase_orders_from_requirements(commit:false) ia lipsurile de materiale și, pentru fiecare material, alege furnizorul potrivit din cataloagele mapate — același material poate fi cumpărat de la mai mulți furnizori, fiecare cu catalogul lui mapat la produsele tale, exact ca la restaurant. Materialele se grupează pe furnizor: o comandă DRAFT per furnizor, cu cantitatea rotunjită la pachet/MOQ. commit:false = preview fără scriere; commit:true creează ciornele (idempotent — re-rulat nu dublează). Cere confirmare explicită înainte de commit:true. supplierStrategy = preferred (implicit) / cheapest / lead-time; mod loose la restaurant (sare peste materiale nemapate și le semnalează), strict la fabrică (le blochează + ține cont de lead-time). Necesită drept de scriere pe Producție; trimiterea către furnizor rămâne din aplicație.
• Catalog multiplu pe același furnizor: dacă un produs intern are mai multe produse de catalog la același furnizor, /smart-ordering arată Alege produse. Userul alege un catalog sau împarte cantitatea pe mai multe linii; până atunci draftul/trimiterea poate fi blocată. Nu inventa supplierProductId și nu dubla conversia de pachet; dacă e ambiguu, trimite userul în Smart Ordering sau cere alegerea explicită.
• Nu inventa prețuri, coduri sau produse de catalog. Ce nu se potrivește → întreabă userul.
• Scrierea cere modulul furnizori pe token (inclusiv recepția pe comandă receive_purchase_order, tot din furnizori). Lipsă modul → „permisiune insuficientă" → activează din portal Hub → Acces AI.
• Stocul se mișcă la NIR postat, nu la recepția pe comandă — vezi skill-ul receptie-factura-furnizor pentru intrarea efectivă pe stoc + notele contabile.

Fluxul (pași cu tool-urile MCP)

A. Ce trebuie să comand + recomandări

1. Context: list_brands + list_locations → brandId/locationId; list_warehouses_full → gestiunile.
2. get_stock_levels(onlyLowStock:true) → produsele sub minim (stoc curent, prag minim, cât lipsește). Pentru fabrici/producție și get_mps_net_requirements(horizonDays) → necesar net (cerere − stoc − programat).
3. list_procurement_recommendations(productId?, limit) → pentru fiecare produs: furnizor recomandat + preț efectiv azi + lead-time + economie potențială. (Cere cataloage mapate; fără mapări nu are ce compara.)
4. Pentru producție/fabrică: create_purchase_orders_from_requirements(commit:false, mode:"strict", horizonDays?) → preview pe lipsurile MRP, furnizori aleși, MOQ/pachet și lead-time. Dacă apar materiale nemapate sau furnizori ambigui, rezolvă mapările înainte de scriere.
5. În aplicație — cât să comand (recomandare transparentă pe zile): în /smart-ordering → „Comandă Nouă" alegi sus „Comandă pentru N zile" (orizontul, ex. 3/7/14/30) și fiecare produs primește o cantitate recomandată după formula clară Min + (vânzări medii/zi × N zile) − stoc curent (rotunjită la pachet/MOQ), cu tot calculul vizibil în tooltip. Toate produsele sunt într-o singură listă („Toate produsele"). Aceeași formulă o folosește și „Predicție & Planificare" („plan inteligent"). Trimite userul acolo când vrea să decidă cât comandă, nu doar de la cine (linkul cu gaseste_in_aplicatie).
6. Recomandare furnizor în UI: badge-ul Recomandat combină preț efectiv, MOQ/pachet și lead-time. Lead-time-ul poate fi mediana reală din recepții postate când există destule mostre; altfel folosește termenul promis/default. Explică asta când userul întreabă „de ce mi-l recomandă pe acesta?".

B. Compar prețurile între furnizori pe un produs

1. search_products_db(productName:"Brânză Albă") → productId.
2. list_suppliers(query?) → furnizorii relevanți.
3. Pentru fiecare furnizor important: get_supplier_last_prices(supplierId) → preț catalog vs ultimul facturat + tendința (crescut/scăzut).
4. Compari: preț unitar × cantitate, factor de pachet (bax vs bucată) și lead-time. Alegi informat (ex. „A la 3,50 vs B la 3,80 → A, economie 0,30/buc").

C. Furnizor nou + catalog (modul furnizori)

⚠ Întâi cauți, abia la urmă creezi. Ordinea nu e opțională: sărită, ajungi cu același furnizor de două ori în listă, iar un furnizor dublat nu se mai desface după ce are comenzi, recepții și facturi pe el.

1. Caută-l pe codul fiscal, nu pe nume. resolve_supplier_identity({ taxId }) (doar citire, nu creează nimic) face tot lanțul într-un singur apel: caută codul fiscal curățat în lista TA de furnizori; dacă nu-l are, cere denumirea oficială la ANAF (cod românesc) sau VIES (cod european) și mai caută o dată în listă cu acea denumire — așa prinde furnizorul pe care îl ai deja, scris altfel («MEGA IMAGE» vs «MEGA IMAGE S.R.L.»). Îți răspunde una din trei: 🟢 verificat (îl ai deja, îți dă rândul lui), 🟡 furnizor nou (chiar nu există), 🔴 alege tu (mai mulți candidați, denumirea nu bate cu codul, sau ANAF/VIES n-a răspuns). Pe 🔴 nu creezi nimic — pui întrebarea userului. list_suppliers(query) rămâne bun pentru o privire rapidă, dar decizia o dă căutarea pe cod.
2. Abia acum create_supplier(name, brandId, cui, contactPerson?, email?, phone?, address?, paymentTerms?, leadTime?) → supplierId. brandId e obligatoriu — îl ai deja din list_brands (pasul A.1). cui e la fel de obligatoriu: pe denumire furnizorii nu se creează, tocmai ca să nu se dubleze. Tool-ul repetă el însuși căutarea pe codul fiscal curățat (fără RO, fără spații) și, dacă îl are deja, îți întoarce furnizorul existent cu „există deja", fără să scrie nimic. Când chiar e nou, îl creează cu denumirea oficială de la ANAF/VIES, nu cu numele pe care l-ai tastat — spune-i userului, altfel se sperie că „i s-a schimbat numele". Datele complete le vezi oricând cu lookup_company_cui (România) sau lookup_eu_company_vat (UE).
3. Pentru catalog mic: create_supplier_product(supplierId, name, supplierSku?, unit, price, minOrderQty?, packSize?, packLabel?) → supplierProductId. Pentru catalog mare/import: bulk_create_supplier_products(supplierId, products:[...]) (max 200/apel). packSize distinge volumele aceluiași produs (ex. 0.5L vs 0.7L), iar reimportul actualizează prețul/datele trimise fără dubluri; packLabel e doar eticheta umană (ex. 0.7L, bax 24).
4. Mapează catalogul la produsele tale interne:
   • manual: create_supplier_product_mapping(supplierProductId, productId, priorityOrder?, isPreferred?, packMultiplier?, supplierUnit?, internalUnit?, packUnitKeyword?, noPackSplit?);
   • în masă: list_supplier_mapping_suggestions(supplierId?, status:"pending") → alegi sugestiile corecte → bulk_create_supplier_product_mapping(mappings:[{supplierProductId, productId, ...}]) în loturi de max 200. Fără mapare nu apare în Recomandări și nu se poate comanda corect.

D. Creez o comandă (ciornă) și o pregătesc de trimis

1. list_suppliers → alegi furnizorul; get_product_details(productId) / get_supplier_last_prices → preț curent.
2. create_purchase_order(orderNumber, supplierId, orderDate, expectedDelivery?, warehouseId?, brandId?, locationId?, notes?) → orderId. Comanda e DRAFT.
3. Pentru fiecare produs: add_purchase_order_item(orderId, quantity, unitPrice, productId?, supplierProductId?, unit?). ⚠ Cantitate sub cantitatea minimă de comandă a furnizorului (MOQ) → trimiterea se blochează.
4. Trimiterea către furnizor se face din aplicație: trimite userul în /smart-ordering (tab Comenzi → „Revizuire & Trimite") sau pe fișa comenzii /purchase-orders/:id. Dă-i linkul cu gaseste_in_aplicatie. (Generarea automată de ciorne din predicție = tot din /smart-ordering → „Generează Comenzi (Draft)".)

D2. Creez ciorne PO direct din necesarul MRP

1. create_purchase_orders_from_requirements(commit:false, mode:"strict", orders?, horizonDays?, supplierStrategy?) → preview; explici furnizorii aleși, materialele sărite/blocate, MOQ/pachet și lead-time.
2. Dacă preview-ul e corect, ceri acordul explicit al userului.
3. Reapelezi cu commit:true → sistemul creează PO-uri DRAFT idempotente, nu le trimite la furnizor. Verifici apoi în /smart-ordering / /purchase-orders/:id.

E. Urmăresc comanda și recepționez marfa

1. Status & negociere (acceptă/contra-propunere/modificare cantitate, cronologie) se văd/fac pe fișa comenzii /purchase-orders/:id în aplicație — îndrumă userul acolo.
2. Când sosește marfa: receive_purchase_order(orderId, items?, warehouseId?, receptionDate?, invoiceNumber?, invoiceDate?, deliveryComplete?, notes?) — postează marfa pe stoc și face NIR-ul, exact ca butonul „Recepționează" din aplicație. Confirm-first: primul apel îți arată doar liniile propuse și gestiunea, fără confirm:true nu se mișcă nimic.
   • Fără items recepționezi integral cât a mai rămas de primit, la prețul comenzii. Cu items faci recepție parțială sau cu diferențe: per linie orderItemId + receivedQty / acceptedQty / rejectedQty, plus unitPrice (dacă documentul furnizorului are alt preț), warehouseId, supplierLotNumber, expiresAt.
   • deliveryComplete se deduce singur: dacă liniile nu acoperă tot restul, comanda rămâne „parțial recepționată". Pune-l explicit pe true doar când furnizorul a terminat de livrat și ce lipsește e lipsă reală (se deschide dispută pe furnizor).
   • Merge doar pe o comandă plasată. Pe o ciornă e refuzat intenționat — recepția ar sări peste aprobarea achiziției; trimite mai întâi comanda din aplicație. Nu folosi „Recepție angajat" pentru un PO și nu crea un aviz separat cu purchaseOrderId. Fluxul canonic de pe comandă este cel care actualizează liniile/cantitățile recepționate și statusul PO; o cale paralelă poate lăsa comanda disponibilă pentru recepție repetată.
3. Diferențe (lipsă, deteriorat, preț diferit): create_reception_note(noteCategory:"delivery_variance", description, purchaseOrderId, productId?, subReason?, severity?); le revezi cu list_reception_notes(purchaseOrderId?). Pentru dispute deschise → noteCategory:"supplier_dispute".
4. Marfa dintr-o comandă intră pe stoc chiar la pasul 2 — receive_purchase_order face NIR-ul și nota contabilă. Verifică cu get_stock_levels(productName). Ruta prin factură (receptie-factura-furnizor, list_pending_nirs) rămâne pentru marfa care nu are comandă în sistem: factură sau aviz sosite direct, recepție din poză. Nu le folosi pe amândouă pe aceeași marfă — ar intra de două ori pe stoc.

F. Analiză aprovizionare

1. analyze_procurement(brandId) → furnizori, prețuri medii, lead-time-uri, tendințe.
2. get_purchases_summary(dateFrom, dateTo, supplierId?) → cât s-a cheltuit, câte recepții, câți furnizori.
3. get_supplier_pnl(perioada|startDate/endDate, brandId?, limit?) → cât din achiziții vine de la fiecare furnizor, materiale fără alternativă și margin-at-risk la scumpire 5%/10%. E read-only și bun pentru „ce furnizor îmi riscă marja"; spune că sensibilitatea e direcțională, nu predicție exactă.
4. get_supplier_last_prices(supplierId) pe top furnizori → tendințe per partener. Concluzii de cost (ex. „A ieftin la brânză, B la legume").

Capcane (spune-le userului când apar)

• Comanda nu se trimite → cel mai des: produs fără cod de furnizor / fără alegere de catalog, produs cu Alege produse nerezolvat sau cantitate sub MOQ. Pagina de revizuire din /smart-ordering arată exact care.
• „Nu văd Recomandări Aprovizionare" → lipsesc cataloagele mapate (create_supplier_product_mapping sau bulk_create_supplier_product_mapping după list_supplier_mapping_suggestions).
• Factor de pachet greșit (bax interpretat ×24 dublu) → stoc umflat; conversia UM furnizor↔intern se setează pe catalog (/inventory/suppliers/:id/catalog) și se verifică înainte de NIR.
• Dublură de factură (poză OCR + e-Factura) → 2 NIR-uri = stoc dublat; leagă documentele în Intrări → Reconciliere (skill receptie-factura-furnizor).
• Furnizor dublat în listă → aproape mereu pentru că s-a creat pe denumire, nu pe cod fiscal (sau rândul vechi e salvat fără cod). Caută cu resolve_supplier_identity({ taxId }) ÎNAINTE de create_supplier; dacă rândul vechi există, completează-i codul fiscal cu update_supplier și de atunci se recunoaște singur. Un duplicat cu comenzi și NIR-uri pe el nu se mai desface — de aceea căutarea nu se sare niciodată.
• „ANAF/VIES n-a răspuns" nu e permisiune de a crea. Un ANAF/VIES tăcut (rețea, serviciu picat) sau o țară pe care nu o acoperă (Elveția, Turcia, Serbia, Moldova, Norvegia, SUA…) NU dovedesc că firma nu există. Răspunsul corect e „alege tu": mai încerci peste câteva minute sau ceri userului să confirme furnizorul din listă. Nu adăuga furnizorul ca nou pe baza unui răspuns care lipsește.
• „Mi-a creat furnizorul cu alt nume decât am scris." Normal: denumirea unui furnizor nou vine de la ANAF/VIES, nu din câmpul tastat. Spune-i userului dinainte, ca să nu creadă că s-a legat de altă firmă.
• Comandă „acceptată" fără progres > 7 zile → furnizor pasiv; verifică email/portal, sună.
• Recepția mișcă stoc real, ireversibil. receive_purchase_order postează marfa și face NIR-ul, deci se cere confirmarea omului înainte de confirm:true. Greșit recepționată, se corectează prin anularea documentului de stoc, nu printr-o a doua recepție.
• Comanda e ciornă → recepția e refuzată, corect: nu s-a aprobat achiziția. Trimite comanda din aplicație și reia. Dacă marfa e demult în gestiune și doar corectezi o postare greșită, nu recepția comenzii e instrumentul, ci un NIR direct (create_inventory_document).

Tool-uri folosite

Citire: list_brands, list_locations, list_warehouses_full, get_stock_levels, get_mps_net_requirements, get_material_requirements, list_procurement_recommendations, search_products_db, get_product_details, list_suppliers, get_supplier_pnl, get_supplier_last_prices, list_supplier_mapping_suggestions, analyze_procurement, get_purchases_summary, list_pending_nirs, list_reception_notes, resolve_supplier_identity, lookup_company_cui, lookup_eu_company_vat, gaseste_in_aplicatie. Scriere (furnizori): create_supplier, update_supplier, create_supplier_product, bulk_create_supplier_products, create_supplier_product_mapping, bulk_create_supplier_product_mapping, enable_supplier_portal, create_purchase_order, add_purchase_order_item, receive_purchase_order, create_reception_note. Scriere (productie): create_purchase_orders_from_requirements pentru ciorne PO din MRP; cere modulul productie pe token și confirmare înainte de commit:true.

Legături (knowledge)

• knowledge/stocuri-inventar-furnizori.md — furnizori, cataloage, comenzi, gestiuni, NIR (citește întâi).
• knowledge/intrari-marfa-receptie.md + skill receptie-factura-furnizor — maparea facturii, crearea NIR, reconciliere (pasul de DUPĂ acest skill).
• knowledge/finante-facturare-contabilitate.md — conturi de stoc (371/301), TVA, impact P&L (referință).
• knowledge/rapoarte-preturi.md — rapoarte de aprovizionare, food cost, analiză cost.