Modulul de achiziții și furnizori într-un ERP la comandă

Un departament de achiziții care funcționează pe e-mailuri și un Excel cu prețuri vechi de un an nu știe niciodată sigur ce a comandat, ce a primit și cât a plătit în plus față de oferta inițială. Într-un ghid complet al modulelor unui ERP la comandă, achizițiile apar ca fluxul care leagă o nevoie internă de banii care ies din companie: cerere, comandă către furnizor, recepție de marfă, potrivire cu factura. Aici intri în mecanica exactă a acestui flux — cum funcționează three-way match-ul, ce se întâmplă la o discrepanță de preț sau cantitate, cum se construiește un flux de aprobare pe praguri valorice și cum se leagă totul de pragul de reaprovizionare din gestiunea stocurilor.

De ce achizițiile au nevoie de propriul modul, nu de un tabel Excel

Multe firme gestionează achizițiile prin trei canale paralele: un e-mail către furnizor, un mesaj pe WhatsApp către coleg pentru aprobare și un rând nou într-un Excel cu istoricul comenzilor. Funcționează cât timp sunt cinci comenzi pe lună. La cincizeci, nimeni nu mai știe sigur ce comenzi sunt încă deschise, ce marfă a ajuns parțial și care furnizor a trimis o factură cu un preț diferit de cel discutat la telefon.

Un tabel de calcul stochează date; nu impune un flux. Nu blochează o factură care nu se potrivește cu comanda, nu rutează automat o cerere de 30.000 de lei către director și nu declanșează o comandă nouă când stocul unui produs scade sub pragul critic. Toate astea rămân în capul cuiva — de obicei persoana care pleacă în concediu exact când apare o discrepanță de preț.

Modulul de achiziții dintr-un ERP la comandă mută regulile din capul oamenilor în sistem: cine aprobă ce, cât de mare poate fi diferența dintre comandă și factură fără intervenție umană, și ce se întâmplă automat când stocul unui produs se apropie de zero. Rezultatul nu e mai multă birocrație — e mai puțină, fiindcă verificările repetitive (cantitate, preț, unitate de măsură) nu mai trec prin cineva care le face manual de fiecare dată.

Ciclul complet: de la cererea internă la factura furnizorului

Achiziția unui produs sau serviciu trece prin patru etape, indiferent de mărimea companiei. Diferența dintre un flux funcțional și unul haotic nu stă în numărul de etape, ci în ce se întâmplă la trecerea de la una la alta — cine confirmă, ce se validează automat și ce rămâne vizibil pentru toată lumea implicată.

Cererea internă de achiziție

Orice comandă pornește de la cineva care are nevoie de ceva: un responsabil de producție care observă că stocul de materie primă scade, un manager care are nevoie de licențe software noi, un angajat din administrativ care comandă consumabile. Cererea internă de achiziție (purchase requisition) înregistrează ce se cere, cât, pentru ce departament sau proiect și — dacă există deja un furnizor preferat — la ce preț estimat.

Această cerere nu e încă o obligație față de un furnizor extern. E o intenție care intră în flux și, dacă valoarea depășește un anumit prag, așteaptă o aprobare internă înainte să devină comandă.

Comanda către furnizor

Odată aprobată, cererea se transformă în comandă de achiziție (purchase order, PO) — documentul care pleacă efectiv la furnizor, cu cantitate, preț negociat, termen de livrare și condiții de plată. Pentru achiziții recurente de la un furnizor cunoscut, sistemul poate genera comanda direct din pragul de reaprovizionare al stocului (vezi mai jos); pentru achiziții noi sau furnizori noi, comanda pornește de la o ofertă cerută explicit.

Comanda emisă rămâne „deschisă" în sistem până la recepția completă a mărfii. Dacă furnizorul livrează parțial, sistemul urmărește exact cât a mai rămas de livrat din comanda inițială — nu depinde de memoria cuiva.

Recepția de marfă

La sosirea mărfii, gestionarul de depozit înregistrează recepția: ce a ajuns, în ce cantitate, în ce stare. Recepția se leagă direct de comanda deschisă, nu e o înregistrare separată — sistemul scade automat cantitatea primită din cantitatea comandată și marchează comanda ca fiind parțial sau integral onorată.

Acest pas contează mai mult decât pare: fără o recepție înregistrată corect, three-way match-ul de mai jos nu are cu ce să compare factura. O recepție lipsă sau introdusă greșit blochează plata unei facturi corecte la fel de eficient ca o factură greșită.

Factura furnizorului și închiderea ciclului

Factura ajunge — azi, în relația B2B din România, aproape întotdeauna electronic, prin sistemul RO e-Factura și Spațiul Privat Virtual (detaliile de conformitate fiscală, cu formatul XML și termenele de transmitere, sunt tratate separat în integrarea ERP cu e-Factura și ANAF). Din perspectiva modulului de achiziții, contează că factura se leagă automat de comanda și de recepția corespunzătoare, pe baza numărului de comandă sau a codului furnizorului, nu manual.

Aici intervine three-way match-ul: sistemul compară comanda, recepția și factura, iar dacă totul se potrivește, factura trece mai departe spre plată fără intervenție. Dacă nu se potrivește, ciclul se oprește — vezi secțiunea următoare.

Three-way match: cum se verifică automat comanda, recepția și factura

Three-way match este controlul care ține achizițiile oneste: verifică, pentru fiecare factură primită, că ce s-a comandat, ce s-a primit efectiv și ce se cere la plată sunt același lucru. E o practică standard în orice departament financiar matur, indiferent de industrie — motivul pentru care rămâne relevantă e simplu: fără ea, compania plătește pe încredere ce declară furnizorul, nu pe ce a verificat ea însăși.

Ce compară exact sistemul

Trei documente intră în comparație:

• Comanda de achiziție — ce s-a convenit: produs, cantitate, preț unitar, termeni.
• Recepția de marfă — ce a ajuns fizic: cantitate confirmată, eventual stare sau calitate.
• Factura furnizorului — ce se cere la plată: cantitate facturată, preț facturat, TVA, total.

Sistemul verifică, linie cu linie, că aceleași produse apar în toate trei, că unitatea de măsură coincide (o factură în cutii pe o comandă în bucăți e o discrepanță reală, nu un detaliu), că prețul unitar de pe factură nu depășește prețul comandat peste toleranța acceptată și că nu se facturează o cantitate mai mare decât cea recepționată.

De exemplu: o comandă cere 500 de cutii de ambalaj la 12 lei/bucată. Recepția confirmă 500 de cutii primite integral. Factura vine însă cu prețul de 12,80 lei/bucată — o diferență de 6,7% față de comandă. Dacă toleranța configurată e de 3%, sistemul nu plătește automat: blochează factura și o trimite spre aprobare de excepție către responsabilul de achiziții, cu comanda și recepția atașate ca referință.

Discrepanțe: aprobare de excepție sau blocare automată

Nu orice discrepanță merită tratată la fel, și aici un modul construit pe structura reală a companiei face diferența față de un flux rigid impus de un software standard. Două tipare de răspuns coexistă, de obicei configurate pe categorii de discrepanțe:

• Aprobare de excepție — diferența e mică sau explicabilă (o taxă de transport adăugată pe factură, o rotunjire), iar o persoană desemnată o poate accepta manual, cu un motiv înregistrat. Factura rămâne blocată pentru plată până la acea aprobare, dar nu se întoarce la furnizor.
• Blocare automată, fără excepție posibilă — diferența depășește un prag considerat inacceptabil (de exemplu, o cantitate facturată mai mare decât cea recepționată), iar factura nu poate trece mai departe fără o recepție suplimentară sau o corecție de la furnizor.

Diferența practică: excepția înseamnă că cineva decide dacă e acceptabil; blocarea automată înseamnă că sistemul nu lasă decizia la latitudinea nimănui până nu există dovada corectă în flux — o recepție actualizată, o factură corectată.

Toleranțe configurabile, nu reguli rigide

Toleranța nu trebuie să fie aceeași pentru toate categoriile de achiziție. Materiile prime cu preț volatil pot avea o toleranță de preț mai mare decât consumabilele de birou, unde orice abatere e suspectă. La fel, o toleranță de cantitate poate fi absolută (maximum 2 bucăți diferență) sau procentuală (maximum 1%), în funcție de cât de predictibil livrează furnizorul respectiv.

Un ERP la comandă permite setarea acestor toleranțe pe categorie de produs sau pe furnizor, nu doar un singur procent global — diferența dintre un three-way match care prinde discrepanțe reale și unul care blochează zilnic facturi corecte pentru rotunjiri nesemnificative stă exact aici.

Fluxul de aprobare pe praguri valorice

Nu orice cerere de achiziție merită același nivel de control. O comandă de 200 de lei pentru consumabile nu are nevoie de semnătura directorului financiar; o comandă de 80.000 de lei pentru echipamente da. Fluxul de aprobare pe praguri valorice există exact pentru asta: rutează automat fiecare cerere către nivelul de aprobare potrivit, în funcție de sumă, nu de cine a apăsat trimite.

Praguri multiple și delegare

Un tipar comun, adaptabil la structura fiecărei companii, arată așa:

• Sub un prag mic (de exemplu 5.000 lei) — aprobare automată sau de la responsabilul direct de achiziții, fără escaladare.
• Într-un interval mediu (de exemplu 5.000–25.000 lei) — aprobare de la managerul de departament care a inițiat cererea.
• Peste un prag ridicat (de exemplu 25.000 lei) — aprobare dublă: managerul de departament și directorul financiar sau administrativ.

Pragurile exacte nu contează la fel de mult ca faptul că sunt configurabile pe companie, nu impuse de furnizorul de software — o firmă de producție cu achiziții mari de materie primă are nevoie de praguri diferite față de un birou de servicii profesionale.

Delegarea rezolvă o problemă reală: aprobatorul e în concediu. Fără un backup configurat, comenzile stagnează până se întoarce persoana respectivă. Cu delegare activă, cererea trece automat către un aprobator de rezervă desemnat dinainte, fără să ocolească regula — doar schimbă cine o aplică.

Trasabilitate: fiecare aprobare lasă urmă

Fiecare aprobare sau respingere rămâne înregistrată: cine a aprobat, când, la ce sumă, cu ce comentariu dacă a existat unul. Nu ca birocrație de dragul birocrației, ci fiindcă la un audit financiar sau la o discuție cu un furnizor despre o comandă contestată, întrebarea cine a aprobat și pe ce bază trebuie să aibă un răspuns imediat, nu o căutare prin e-mailuri vechi.

Legătura cu stocurile: de la pragul de reaprovizionare la comanda de achiziție

CÂND vs. CUM — granița dintre gestiunea stocurilor și achiziții

Gestiunea stocurilor răspunde la întrebarea CÂND: pragul de reaprovizionare (reorder point, ROP) e nivelul de stoc la care sistemul semnalează că un produs trebuie comandat din nou, calculat din consumul mediu zilnic și timpul de livrare al furnizorului — mecanica exactă a calculului, cu FIFO și CMP, e detaliată acolo.

Modulul de achiziții răspunde la întrebarea CUM: cui i se trimite comanda, la ce preț negociat, cu ce termen de livrare așteptat și prin ce flux de aprobare trece dacă valoarea o cere. Cele două module nu se suprapun — se predau ștafeta.

De la comandă-draft la comandă confirmată

Când stocul unui produs atinge pragul de reaprovizionare, sistemul nu trimite automat o comandă fermă către furnizor — generează o comandă-draft, cu furnizorul implicit (de obicei cel mai recent folosit sau cel cu prețul cel mai bun înregistrat) și cantitatea calculată din politica de reaprovizionare. Responsabilul de achiziții primește notificarea, verifică dacă furnizorul și prețul încă sunt cele corecte și confirmă — sau schimbă furnizorul, dacă între timp a apărut o ofertă mai bună.

Acest pas intermediar contează: reaprovizionarea complet automată, fără nicio verificare umană, funcționează pentru produse stabile și furnizori de încredere, dar expune compania la riscul de a comanda automat de la un furnizor care între timp a crescut prețul sau a intrat în întârziere de livrare. Draftul păstrează automatizarea utilă — nimeni nu mai verifică manual zeci de praguri de stoc în fiecare dimineață — fără să elimine complet controlul.

Istoric de preț pe furnizor și comenzi recurente

Istoricul de preț ca pârghie de negociere

Fiecare comandă confirmată se adaugă la istoricul de preț al furnizorului respectiv pentru produsul comandat. Nu doar prețul din ultima comandă — evoluția lui în timp, cu date exacte. Când un furnizor propune o creștere de preț la reînnoirea unui contract, istoricul arată imediat dacă acea creștere e justificată de o tendință generală a pieței sau dacă furnizorul respectiv a crescut prețul mai mult decât alții din același istoric.

Fără acest istoric centralizat, negocierea se bazează pe memoria cuiva sau pe căutarea prin e-mailuri vechi — și, de multe ori, pe acceptarea prețului propus fiindcă verificarea manuală durează prea mult pentru o comandă de rutină.

Contracte-cadru și comenzi recurente automate

Pentru furnizorii cu care compania lucrează constant — materii prime consumate lunar, servicii de mentenanță recurente — un contract-cadru fixează prețul și condițiile pe o perioadă, iar comenzile individuale se generează automat din el, fără renegociere la fiecare livrare. Sistemul verifică doar că fiecare comandă nouă respectă condițiile contractului-cadru activ, nu repetă procesul de aprobare de la zero.

Diferența față de o comandă recurentă setată manual într-un calendar: contractul-cadru din ERP leagă automat prețul contractat de three-way match-ul descris mai sus, deci o factură care încearcă să factureze peste prețul contractual e prinsă automat, nu depinde de cineva care ține minte cifra exactă negociată acum șase luni.

Oglinda comenzilor de vânzare: simetrie, nu coincidență

Modulul de vânzări și comenzi tratează comenzile primite de la clienți; modulul de achiziții tratează comenzile trimise către furnizori. Structural, cele două sunt aproape oglindă una față de cealaltă: o cerere sau comandă cu produse și cantități, un flux de aprobare pe valoare, o confirmare de livrare (recepție la achiziții, expediere la vânzări) și o factură care închide ciclul.

Simetria nu e doar o observație arhitecturală — are consecințe practice. Aceleași componente tehnice (motorul de aprobare pe praguri, potrivirea automată a documentelor, legătura cu stocul) se reutilizează în ambele direcții, în loc să existe două sisteme separate de aprobare cu reguli diferite. Pentru o companie care e simultan client și furnizor pe piețe diferite — cumpără materie primă, vinde produs finit — coerența dintre cele două fluxuri simplifică și raportarea financiară: aceeași logică de validare, aplicată de ambele părți ale bilanțului.

Diferența reală nu e tehnică, ci de direcție a banilor: la vânzări, compania așteaptă plata; la achiziții, compania o face. Restul mecanicii — comandă, confirmare fizică, factură, potrivire — se repetă aproape identic.

De ce contează varianta „la comandă"

Un sistem ERP standard vine cu un singur flux de aprobare predefinit și câteva variante configurabile din meniu. Dacă structura companiei se potrivește cu una dintre variantele oferite, funcționează. Dacă nu — și majoritatea companiilor au particularități reale (un departament care aprobă altfel decât restul, o categorie de achiziții care cere un pas suplimentar de verificare tehnică, un furnizor strategic cu toleranțe diferite de restul) — compania fie își schimbă procesul ca să se potrivească software-ului, fie renunță la o parte din control și lucrează cu excepții manuale în afara sistemului.

Un modul de achiziții construit la comandă pornește invers: de la fluxul real al companiei, nu de la un tipar generic. Pragurile valorice reflectă structura organizatorică existentă, nu o presupunere a furnizorului de software despre cum ar trebui să arate. Toleranțele de three-way match variază pe categorie de produs, nu sunt un singur procent global. Contractele-cadru și comenzile recurente se configurează pe relațiile reale cu furnizorii existenți, nu pe un model generic de furnizor preferat.

Costul acestei personalizări nu e neapărat un timp de implementare mai mare — deseori e mai mic, fiindcă nu mai există etapa de a forța procesul companiei într-un tipar străin și apoi de a construi excepții peste excepții ca să repare diferența.

Întrebări frecvente

Ce diferență este între o cerere de achiziție și o comandă către furnizor?

Cererea de achiziție (requisition) e internă — cineva din companie semnalează o nevoie și, dacă valoarea o cere, așteaptă aprobare. Comanda către furnizor (purchase order) e documentul extern, emis abia după aprobare, cu efect contractual asupra furnizorului.

Ce se întâmplă când factura furnizorului nu se potrivește cu comanda?

Depinde de mărimea discrepanței. O diferență mică, în limita toleranței configurate, poate primi o aprobare de excepție de la responsabilul de achiziții. O diferență mare blochează automat plata până la o corecție a facturii sau o recepție suplimentară care să justifice cantitatea facturată.

Poate un ERP la comandă genera automat comenzi de achiziție din pragul de reaprovizionare?

Da — sistemul generează o comandă-draft când stocul unui produs atinge pragul de reaprovizionare (ROP), cu furnizorul și cantitatea calculate automat. Comanda rămâne draft până la o confirmare umană, ca să evite comenzi automate către un furnizor care între timp a crescut prețul sau întârzie livrările.

Cine aprobă o comandă de achiziție și în cât timp?

Depinde de pragurile valorice configurate pentru compania respectivă — de obicei aprobare directă sub un prag mic, aprobare de manager de departament pentru sume medii și aprobare dublă (manager plus director financiar) peste un prag ridicat. Delegarea către un aprobator de rezervă evită blocajele când persoana titulară e indisponibilă.

De ce nu ajunge un modul de facturare pentru gestionarea achizițiilor?

Facturarea (vezi modulul de contabilitate) înregistrează și procesează documentul financiar final. Achizițiile gestionează tot ce se întâmplă înainte de factură — cererea, aprobarea, comanda, recepția — și fac posibilă verificarea automată a facturii primite prin three-way match. Fără acest flux amonte, un modul de facturare primește pur și simplu ce declară furnizorul, fără nimic de comparat.

Dacă blocajele de mai sus — comenzi fără evidență clară, aprobări pe e-mail, facturi plătite fără verificare — se regăsesc în fluxul curent de achiziții, pasul următor e o discuție despre cum arată un modul construit exact pe structura ta de aprobare și pe relațiile reale cu furnizorii. Vezi și celelalte servicii ERP la comandă care se leagă direct de achiziții: gestiunea stocurilor, contabilitatea, vânzările și raportarea operațională, care agregă costurile reale din toate astea într-un singur loc.