Erp Ghidul Curiosului (Și Alte Lucruri Care Nu Interesează Pe Nimeni)

E R P - G h i d u l c u r i os u l u i
Ionescu Bogdan
ERP
G h i d u l cu r i o s u l u i
(și alte lucruri care nu interesează pe nimeni)
BUCUREŞTI – 2021
Pagina 1/142
Titlu: ERP - Ghidul curiosului

(și alte lucruri care nu interesează pe nimeni)
Autor: Ionescu Bogdan
Localitate: BUCUREŞTI
An: 2021
ISBN 978-973-0-35754-7
EDIŢIE ONLINE PDF, 2021
Forma de publicare inițială (2021) a fost PDF în format read-only (doar citire conținut) fară
drept de copiere conținut sau printare. Funcțiile CTRL+C și CTRL+P erau dezactivate.
Forma actuală (2024) este free PDF cu CTRL+C și CTRL+P active.
A fost adăugat subcapitolul:
[3.6.4 PPV vs Three Way Matching PO vs Standard cost vs Ap Invoice (factura furnizor)]
Versiunea conținutului inițial: 13-12-2021

Data Publicare on-line: 23-12-2021
Data republicare: 04-01-2024
Pagina 2/142
Pagina 3/142
Cuprins posibil
1. Cuvânt înainte – Cui i se adresează acaestă lucrare? 6
2. Ce tratează acaestă lucrare? 7
3. ERP Generalităţi 8
3. 1. P eri oadă a pari ţ i e – 1 970- 1980 c a apl i c aţ i i l oc al e 8
3. 2. Depa rt aj are a f i rm el or, s ubuni t ăţ i l o r s au f i l i al el or af l at e î n ţ ări di f eri t e î n E RP . 8
3.2.1 Baze de date pentru fiecare firmă versus baza unică cu mai multe firme. 8
3.2.2 Practică folosită pentru raportare în cazul bazelor mari unde Baza1=PROD/REAL și Baza2=Test/Clona/Raportare 11
3.2.4 Tehnica de salvare lunară a tabelei de solduri finale versus soldul/stocul on hand now (acum) 13
3. 3. E RP c a s i s t em i nf orm at i c v ers us s i st em i nf orm aţ i onal 17
3. 4. Cu c i ne s eam ană E RP -ul ?. E rp-ul s eam ăn ă c u [ pări nţ i i ] săi . 18
3.4.1 Primul cobai şi Născătorul de aplicaţie 18
3.4.2 ERP-ul şi verticalele de afaceri versus cheia franceză bună la orice. 20
3.4.3 ERP-ul, sofismele şi viciile de consințământ – DOLUL. 21
3.4.4 Cum aleg un ERP pentru organizația mea? 23
3. 5. T erm eni f undam e nt al i : J I T , A P , A R, I C, P O, GL, GA A P, AP I CS . 25
3.5.1 Să începem puţin cu APICS. Gestionare Stocuri [Inventory] 25
3.5.2 Alţi termeni folosiţi: PO, AP, AR, SO, WO. 29
3. 6. A l t e part i c ul ari t ăţ i s pec i f i c e [ T hree-Way M at c hi n g P O] , Com anda de A pr ov i z i onare ș i v ari aţ i i : 29
3.6.1 Legătura PO>Nir>Final Ap Invoice numită și [Three-Way Matching în Accounts Payable] 29
3.6.2 Variaţiile PO>Nir>Final Ap Invoice [Factura furnizor] 32
3.6.3 Operarea nirului și a facturii [Factura furnizor] în România și în lume 32
3.6.4 PPV vs Three Way Matching PO vs Standard Cost vs Ap Invoice (factura furnizor) 35
3. 7. T ranz ac ţ i i l e î n t i m p real – f al s ă abordar e. E f ec t e î n c ont abi l i t at e. 36
3. 8. Rec unoaș t ere a v eni t uri l o r ş i a c hel t ui el i l or î n E RP [ Cas h v s . Ac c rual A cc ount i ng ] – di f e renț a
f undam ent al ă î nt re GA A p v s m odel f ranc ez . Cont ul 121. 39
3. 9. E RP -ul , penar ul ș i l apt opul s au c u c e di s poz i t iv acc es ăm o apl i c aț i e E RP ? 41
3.9.1 Ciobanul Ghiță și Nelimitat în rețea & Nelimitat Tik Tok, Whatsapp și Facebook 41
3.9.2 Ce legătură are ERP-ul cu penarul și laptopul? 41
3.9.3 Despre utilizarea Tastaturii clasice [IBM 105 keys] 42
3.9.4 Despre utilitatea prezenței monitorului pentru utilizatorul de ERP 43
3.9.5 Recomandare: utilizați tastatura USB externă și monitorul extern. 44
4. Economie introvertită sau extrovertită. Implozie versus explozie. 44
4. 1. Ce l e găt u ră au Ha ns ş i V as i l e c u un E RP adev ărat angl o- s ax on? 45
5. ERP – unealta de control rapidă a fabricilor mele de pe glob. 47
6. Cum arată un ERP – structura de bază pe scurt. 49
6. 1. Le gat ur a Di rec t ă apl i c aț i e>s erv e r>baz ă de dat e 50
6. 2. Le găt ur a i ndi r ec t ă s au c l eș t el e c are apuc ă c l eș t el e c are apuc ă j arul di n f oc 51
7. Aplicaţii economico-financiare versus aplicaţii ERP – diferențe 53
7. 1. Cum rec unoaș t em un E RP ? Not e m anual e GL v s not e di n m odul e. 53
8. Clasificarea aplicaţiilor ERP 57
8. 1. Di f erenț a î nt re u n pro gram E RP ş i o apl i c aţ i e i nf orm at i c ă f i nanc i ar-c ont abi l ă s au una m odul ară. 57
8. 2. Cât ev a c uv i nt e des pre apl i c aţ i i l e di n c l as a s m al l bus i nes s. 60
8.2.1 Avantajele unui soft din clasa "small" sunt următoarele: 60
8.2.2 Dezavantajele unui soft din clasa "small" sunt următoarele: 60
8. 3. Cât ev a c uv i nt e des pre apl i c aţ i i l e di n c l as a E RP : 62
8.3.1 Avantajele unui soft din clasa "ERP" sunt următoarele: 62
8.3.2 Dezavantajele unui soft din clasa "ERP" sunt următoarele: 63
9. Definire posibilă pentru ERP 64
9. 1. Def i ni ț i a m ea pl us c e am m ai prel uat de l a al ț i i 64
9. 2. M et ode ş i t ehni c i de m ana gem ent i m pl em e nt at e de ob i c ei î n i nt eri orul unui E RP a n gl o -s ax on, doar
enum er are f ăr ă c om ent ari i . 67
10. ERP generator de documente sau imitator de documente? 68
11. Structura modulară şi funcţională a unui sistem ERP 70
11. 1. I ni m a s i s t em ul ui E RP : M et oda de ges t i une a p reț ul ui de s t oc f ol os i t ă: S t andard, CM P (A V G), F I F O (c u
i dent i f i c are s pec i f i c ă) 70
11.1.1 Metoda de cost Standard . Prețul de stoc standard în Balanța de stoc 71
11.1.2 Metoda de cost CMP/AVG sau prețul de stoc în timp real. Prețul de stoc CMP în Balanța de stoc. 73
11.1.3 Metoda de cost FIFO sau prețul de stoc cu identificare specifică inclusiv CTA. Prețul de stoc FIFO în Balanța de stoc. 73
12. Nomenclatoare principale. Terți, articole stoc, taxe (GTM), Plan Conturi, centre cost (organigramă), proiecte. 74
13. Structura de nomenclatoare de bază ale unui sistem ERP (Master data). Alte setări necesare. 78
13. 1. E x em pl e c u el em ent e ş i at ri but e c om une m ai m ul t or E RP 78
13. 2. S et ări c om bi nat e î nt re nom enc l at oar el e i m port a nt e pe ba z ă de re gul i c ont ex t ual e 82
14. Implementarea unei aplicații ERP în România. Câteva repere 83
15. Modulul de Postcalcul şi ERP-ul 88
15. 1. Des pre P os t c al c ul aț i a c os t uri l or – gen eral i t ăţ i . E x i s t ă s au nu î n E RP noț i unea de pos t c al c ul ?. 88
15. 2. Ce găs i m az i î n E RP -uri pent ru c al c ul aț i a c os t uri l or ? 88
Pagina 4/142
15. 3. P ro gram ul d e pos t c al c ul c a apl i c aț i e ext ernă E RP 91

16. Funcţionalităţi ce trebuie să existe în interiorul unui ERP în varianta adaptată în conformitate cu legislaţia şi cu practica
(cutuma) managerială din România 94
16. 1. Î nai nt e de a c um păra un E RP ar t re bui s ă s t i ţ i î n pri m ul rând c ă: 94
16. 2. Care s unt punc t el e de c ar e t rebui e s ă ț i nem c ont l a al e ge rea unui E RP : 97
17. Localizarea și adaptarea unei aplicaţii ERP anglo-saxone la specificul unei ţări francofone. Exemple din Franța și România.
104
17. 1. Loc al i z are f ac ut ă de E RP Orac l e J D E dwards pent ru F r an ț a –v eri f i c ări re gi s t re c ont abi l i t at e(2 014) 104
17.1.1 Exemplu extras din localizarea pentru Franța: 105
17.1.2 Verificare conta/modul. Analitic-sintetic. Exemplu concret 106
17.1.3 Comentariul meu ca autor pentru verificarile de mai sus modul>conta, sub-ledger> ledger GL: 107
17. 2. Loc al i z are f ac ut ă de Or ac l eNet S ui t e F ranc e -S pec i f i c Feat ures . F i c hi er d’ E c ri t ures Com pt abl es (F E C)
(2020 ) 109
17. 3. Loc al i z are f ac ut ă de E RP QA D E E (E net erpri s e) pent ru R om âni a (ex M F G/ P RO) – 2015 -201 7 110
18. Închiderea lunii în ERP [Closing month processes]. Reconcilieri 112
18. 1. Ce es t e î nc hi derea de l u nă î n E RP ? 112
18.1.1 Durata activității de închidere: 112
18.1.2 Pași de urmat la închidere [totul în ERP] versus [programe auxiliare apendice] 112
18.1.3 Cheie de verificare în orice aplicaţie. Exemplu: soldul Băncii pe registrul IBAN X-Y-Z (BCR Cont curent LEI ARAD): 115
18.1.4 Module şi activități de închis lunar în ERP: 115
18.1.5 Notă importantă privind rapoartele de Ieșire/Intrare pe Surse și Destinații: 116
18.1.6 Închiderea lui 121 – funcție lipsă în ERP standard. 117
18.1.7 Blocarea fizică a lunii închise – calendare contabile şi de modul 117
19. SAF-T , Declarația D406 şi ERP-ul dvs. 118
19. 1. De c e m enț i onez ac eas t ă dec l araț i e S A F -T (D406 ) î n ac eas t ă l uc rare ? 118
19. 2. Care s unt rap oart el e nec es are î n E RP pent ru a obț i n e S A F -T (D40 6) ? 120
20. Stocuri aflate la terți. Custodii. Consigned inventory în ERP. 123
20. 1. Cons i gnaț i a di n Rom âni a a ni l or ‘ 90 123
20. 2. Des c ri ere pr oc es e Cons i gne d i nv ent ory î n E RP 124
21. Pamflete despre ERP cu iz economic și mai ales informatic… 127
21. 1. Ci z m ări a i nf o rm at i c ă. S au c um s ă v i nz i ș i m ai al es c um s ă c um peri l i ni a de m i ră a u nui E RP (v ers i une a
ori gi nal ă di n noi em bri e 20 11) 127
20.1.1 Epilog, morală (La cizmăria informatică). Rabinul și gâștele bolnave. 131
21. 2. Cu c ot u’ pe t as t at ură. S au c um s ă nu f ac i apl i c aţ i i ec onom i c e t âm pi t e c a s ă nu f i î nj urat de ut i l i z at ori . 132
21. 3. E RP -ul l ui Hans ș i E RP -ul l ui V as i l e – S ec ț i une pam f l et : 135
22. Anexe cu formate de rapoarte utile din diverse module din ERP 137
22. 1. A NE X A 1. Raport c om bi nat Cont abi l i t at e c u anal i z ă p reț d e s t oc (c ost ) vs preț v ânz are f ac t ură. 138
22. 2. A NE X A 2. P ost c al c ul – B al anț a c ont abi l ă anual ă c u rul aj e pe c el e 12 l uni : c l as a 6 c om bi nat c u c ont uri de
c l as ă 9: 921, 922, 923, 924, 925 139
22. 3. A NE X A 3. P os tc al c ul . Raport Cent ral i z at or l u nar c os t uri : Cl as a 9, C ont De bi t (6) , Cent r u C os t . S el ec ț i e
pent ru S ec ț i a_nr _2 140
Bibliografie (scurtă): 141
Pagina 5/142
1. Cuvânt înainte – Cui i se adresează acaestă lucrare?
Cartea se adresează mai ales mediului economic: directorilor economici, contabililor,

utilizatorilor KEY useri, project managerilor, programatorilor, implementatorilor şi analiştilor
din zona ERP, dar simultan și mediului universitar: studenţilor economişti din anii terminali
(master), în principal studenţilor de la ASE de la Contabilitate şi Informatică de Gestiune şi
Cibernetică, studenţilor de la Matematică-Informatică, profesorilor, doctoranzilor.
Cu siguranţă această carte trebuia scrisă de cineva undeva prin 2009 dar nu e târziu nici
azi (2019-2021).
Lucrarea poate fi privită tehnic și funcțional cel puțin din prisma:
- implementatorului (cel ce implementează) adică instalează aplicația și o și pornește
și eventual mai are grijă de ea în următorii ani;
- programatorului care este obligat să facă tot felul de modificări în sursele aplicației;
- contabilului șef ca beneficiar final în capul căruia se sparg toate problemele;
- operatorilor și a KEY userilor, cei care bagă date și scot rapoarte diverse;
- patronului (clientul care a cumpărat ERP-ul).
Îmi cer scuze dacă pe alocuri veţi găsi anumite elemente de jargon sau argou sau dacă
denumiri sau noţiuni care sunt substantive comune (conform gramaticii limbii române) în
lucrare sunt scrise uneori cu litere mari (exemplu: Fişa de Magazie, NIR). Am ales această
formă de prezentare/exprimare inspirată din WORD (Capitalize Each Word) pentru a
scoate în evidenţă mai bine formularul sau noţiunea economică sau informatică folosită.
Nu vom folosi prea des denumiri complicate precum: n-tier, multi-tier, fat client sau rich
client, front-end sau back-end, sau mai nou Cloud (Informatica din Nori). Vom încerca să
explicăm în termeni simpli majoritatea lucrurilor ajutându-ne de termenii uzuali folosiţi în
limbajul economico-informatic curent de la locul de muncă. Să nu căutaţi aici referiri la
CRM1 şi nici la BI2 că nu doresc să vorbesc despre ele.
Cartea a fost scrisă în proporţie de 75% până la data de 15.12.2019. Am continuat
finalizarea ei dupa 19.04.2020 când am inserat informațiile ce ţin de documentele primare
de bază și legătura lor cu documentele de sinteză și control. Nu are nici o legatură cu
Corona Virus, nu am avut timp. Între timp am ajuns cu ea în 2021. Să nu uitaţi să citiţi și
notele din subsol (să nu săriţi peste ele).
1
Customer relationship management (CRM) = este de obicei o aplicaţie externă ERP pentru gestionarea relaţiilor cu
clienţii companiei. Majoritatea ERP-urilor consacrate au modul CRM ca aplicaţie externă independendentă care
comunică indirect prin import/export de date cu ERP-ul principal.
2
Business intelligence (BI) = un set de programe dezvoltate de producătorii ERP ca modul independent prin care se
extrag date din tabelele bazei de date a ERP-ului pentru a oferi rapoarte (format factură, lista intrărilor pe surse, balanţă
clienţi, fişa de magazie etc…) sau plăcinţi şi butoaie (grafice). Azi majoritatea ERP-urilor consacrate au propriul BI
dezvoltat în C++/# /.NET, C1ReportDesigner, Java. Există însă aplicaţii generatoare de rapoarte/BI independente
puternice cum ar fi Crystal Reports sau Qlik care au deja conectoare native prin DLL/JDBC/ODBC la OracleX,
SqlServerX, Progress sau MySql. Una peste alta: te rog să faci tu (clientule de ERP) în BI sau în Report Builder (sau
cum le mai zice) rapoartele importante pe care eu (producător de ERP) nu le am….
Pagina 6/142
2. Ce tratează acaestă lucrare?

Cartea încearcă să facă legatura între (1) ERP ca aplicaţie informatică, (2) organizaţia
(firma) în care se încearcă implementarea lui și (3) factorii externi ai mediului economic
specifici statului (ţării) în care firma își desfașoară activitatea prin intermediul principalelor
instrumente (pârghii) de control și verificare astfel:
a.) Economii [francofone3] bazate pe [normare contabilă4]: planul de conturi legiferat,
ordonanţe, ordine, norme de aplicare, formulare de raportare detaliate (D300, D394,
D390, D112, D205).
b.) Economii [anglo-saxone] bazate pe: cutumă, fără plan contabil general formalizat în
detaliu doar cu cadru conceptual contabil, sistem de raportare anual simplificat (vezi
Profit and Loss Statement - P&L, soldul la data pentru clienţi, furnizori, stocuri la data)
fară accent pe rulaje lunare;
Lucrarea este orientată pe efectele din contabilitate realizate de tranzacţiile
documentelor generate din modulele unui ERP. Scopul principal al contabilului român fiind
“să dea casa cu masa”, casa fiind modulul (în sintetic cum spun unii contabili) iar masa
fiind contabilitatea (în analitic cum spun aceiaşi contabili). În limbajul GAAp veți găsi
[Ledger5 to sub-ledger reconciliation] fiindcă nici la ei “nu bate casa cu masa”.
Model
Francez Model
Anglo-Saxon
Plan de conturi detaliat
și legiferat, ordonanțe, Fără plan contabil
norme de aplicare, general formalizat în
formulare lunare de detaliu (doar cu cadru
ERP
INDIVIDUL
raportare detaliate conceptual contabil),
(D300, D394, D390, cutumă, sistem de
D112, D205). raportare anual
STATUL
Documente primare simplificat (Profit and

obligatorii: Factura, Loss Statement P&L),
Aviz, Nir, ștampilate și soldul la data pentru
semnate. Contabilul clienţi, furnizori, stocuri
este agentul fiscal al fară accent pe rulaje;
statului în firmă. Contabilul este analistul
patronului.
3
Sîrbu Florentina, Sistemul contabil românesc – pagina 50, capitolul: [Sistemul contabil românesc în perioada 1990
– 1997 sau prima etapă a reformei contabile românești]
4
Neamţu Ion-Horia, ASE. Citat: [După cum, la nivel naţional, pilonul de bază al procesului de normalizare a contabilităţii
este reprezentat de planul de conturi general, la fel şi la nivelul întreprinderii pilonul de bază al procesului de normalizare
a contabilităţii de gestiune ar trebui să îl reprezinte planul de conturi….]
5
General Ledger/Subledger = Aici fac o precizare: fiecare modul generează o notă contabilă în tabela subledger 1:1 cu
tranzacția documentului conform setărilor existente. Din tabela subledger notele ajung în final în tabela ledger (Registrul
Jurnal General, Fișa cont, Balanță) prin transfer. Acesta este [călcâiul lui Ahile] deoarece în toate aplicațiile găsim
desincronizări între cele două tabele la mai toate ERP-urile (e de scris o altă carte pe tema asta).
Pagina 7/142
3. ERP Generalităţi
3.1. Perioadă apariţie – 1970-1980 ca aplicaţii locale

Aplicaţiile ERP au apărut în anii 70-80 ca o unealtă de gestiune economică ce încercă
să transpună prin programe informatice în primul rând conceptul managerial de JIT6 şi
MRP7 (Just în time şi Material resource planning) pentru producţia industrială robotizată de
serie mare şi masă. Concentrarea la început s-a făcut pe pregătirea producţiei şi mişcarile
de stoc posibile (inventory) şi apoi s-au extins către celelalte funcţiuni (financiar,
contabilitate, mijloace fixe, salarizare/personal, clienţi, furnizori, distribuţie, aprovizionare).
Toate se bazează pe modele matematice consacrate. Exemple: calcul stoc de siguranţă,
necesar de aprovizionat, durata de aprovizionare, termene scadente. ERP ca noțiune
apare oficial în anii 1990 (vezi Gartner Group) dar ele se trag din “strămoșii” lor adică din
aplicațiile locale (monopost, monofirmă) ale anilor 1970-1980.
3.2. Departajarea firmelor, sub unităţilor sau filialelor aflate în

ţări diferite în ERP.
3.2.1 Baze de date pentru fiecare firmă versus baza unică cu mai multe firme.
Sărind în prezent, ulterior după 2014 axarea s-a extins în zona de control al
sucursalelor aflate la distanţă. Pe românește ar fi: un control total informatic al sucursalei
mele din ţara X de pe glob.
Ce se controlează ? În principiu ar fi cel puţin două aspecte importante de controlat cu
ERP-ul:
a.) Bunurile mișcate (stocurile/inventory),
b.) Fluxurile de numerar respectiv banii în diverse monede (USD, LEI, EUR, GBP
etc…) transpuse în: încasări şi plăți, solduri pe case şi bănci8, solduri de plată
(furnizori) şi solduri de încasat (clienţi).
Erp-urile azi controlează multe alte resurse şi elemente patrimoniale de ACTIV sau
PASIV dar a+b sunt cele mai importante.
6
JIT – Just în Time – metodă de management apărută la Toyota în Japonia dupa anul 1970 odată cu automatizarea
[robotizarea] unde producţia tip parts manufacturing [producţie discretă în limbaj US] se intersecta cu producţia de
masă şi serie mare. Parts manufacturing [producţie discretă] se referă aici la componentele identificabile vizual ce
alcătuiesc un autovehicul. JIT încercă să asigure componentul XYZ exact la timp şi în locul potrivit în fluxul tehnologic
fară a avea costuri de stocare suplimentare. Producătorul va asigura în magaziile proprii doar stocul de siguranță
pentru reperul XYZ între limitele min/max planificate/prestabilite. Premisele JIT se regăsesc la Frederick Taylor aplicate
şi verificate în uzinele lui Henry Ford înainte de 1915. Dar atunci nu exista ERP.
7
MRP – Material Requirements Planning este un sistem complex de planificarie al resurselor dezvoltat iniţial pentru
gestionarea optimă a resurselor materiale (stocurilor/inventory). Principalele obiective urmărite țin de estimarea
cantităților de materie primă necesară în producţie și programarea livrărilor la timp, ținerea prețurilor de aprovizionare
sub control pentru organizarea activității de fabricație (Comenzi WO), de livrare (comenzi SO) și de cumpărare (PO).
8
Case și Bănci, solduri = ne referim la registrul de casă/bancă ca registru unic la nivel de IBAN în cazul băncilor,
corespunde de obicei unui analitic 5121/5124. Registru de casă este registru unic distinct la nivel de locație: [Registru
casă sediu, Registru casă magazin poartă, Registru de casă depozit Craiova]. Corespunde unui analitic pentru 5311.
Pagina 8/142
Aici internetul și mai ales viteza internetului a permis accesul la o bază de date prin
protocolul https între clientul aflat la mii de km. față de server. O a doua facilitate este
preţul în relativă scădere al resurselor hardware (memoriei RAM DDR4/5 + procesor
puternic + HDD SSD/SATA3 de dimensiuni f. mari) ce au permis rularea unor aplicaţii
complicate cu baze de date enorme pe servere partajate virtualizate. Practic ce făceam în
reţeaua locala din fabrică acum 15 ani facem aproape la fel de rapid sau mai rapid pe un
data-center aflat la mii de km. distanţă (sau facem în visele noastre…, vom vedea.).
Pentru a putea identifica şi gestiona tranzacţiile din două sau mai multe firme,
subunităţi, puncte de lucru aflate în ţari diferite se folosesc următoarele abordări:
La nivel de bază de date sunt două abordări mari şi late:
1. Prima veche de peste 30 de ani, clasică şi des răspândită este folosirea unei baze
de date separate pentru fiecare firmă aparţinând aceluiași grup de firme:
Head-quarter Londra (sediul central) - baza date 1
Fabrica de Aragaze Rasnov (Romania) - baza date 2
Fabrica de Frigidere Wroclaw (Polonia) - baza date 3
Depozit warehouse distributie Marsilia (Franta) - baza date 4
Baza date de agregare (9999) - baza date 5
În structura de mai sus marile dezavantaje sunt:

- Pentru a avea o imagine agregată, consolidată a afacerii patronul trebuie să agrege
așa cum poate o parte a informaţiilor din bazele filialelor [2+3+4] + sediul central [1]
în baza numarul 5 care este așa-zisa bază de agregare.
- Această agregare nu se face instant adică tranzacţia din baza de date 3 nu ajunge
în baza 5 imediat ci dupa ore sau zile sau chiar luni dacă a plecat omu’ de bază
din firmă9.
- Sunt necesare tot felul de proceduri de transfer pe bază de scripturi lansate
noaptea în batch pe serverul central care mai dau şi rateuri uneori.
- Întotdeauna un “pitic” stă noaptea şi “face baba-oarba” între bazele de date
1+2+3+4+5 pentru ca să nu se piardă ceva la copiere, agregare sau replicare
informaţii.
- Nomenclatoarele de bază sunt f. greu de întreţinut şi de multe ori sunt redundante
(clienţi, furnizori, plan de conturi, articole de stoc/nomenclator articole)
9
Omu’ de bază din firmă este omul de la IT sau IT manager specialist care este menţionat în pamfletul din capitolul
[Funcţionalităţi ce trebuie să existe în interiorul unui ERP în varianta adaptată în conformitate cu legislaţia şi cu practica
(cutuma) managerială din România]
Pagina 9/142
Avantajele aici sunt:

- Fiecare bază de date este interogată ușor de userii firmei de la director la
magazioner. Rapoartele rulează ușor.
- Independența aproape totală pentru filiale la definirea nomenclatoarelor.
2. A doua variantă puţin mai nouă este folosirea aceleiași baze de date pentru toate
firmele aparţinând aceluiași grup de firme, baza de date este unică.
Aici departajarea pe firme se face pentru toate tabelele bazei de date prin câmp
separat. Dacă avem 800 de tabele sau poate 1500 de tabele în ERP-ul nostru pe
baza de date, fiecare tabelă va avea un câmp separat numit [FIRMA] sau
[Domeniu] sau [Company].
Structura de așezare fizică pe baza de date /tabele este difereită aici şi arată asa:
Head-quarter Londra (sediul central) (firma_1) - baza date 1
Fabrica de Aragaze Rasnov (Romania) (firma_2) - baza date 1
Fabrica de Frigidere Wroclaw (Polonia) (firma_3) - baza date 1
Depozit warehouse distributie Marsilia (Franta) (firma_4) - baza date 1
Firma de agregare (9999) (firma_9999) - baza date 1
Se observă că [Baza date de agregare (9999)] este înlocuită aici de [Firma de

agregare 9999].
Marile avantaje ale acestei variante sunt:

- Nomenclatoarele de bază sunt unice pentru toate firmele şi sunt f. ușor de
gestionat, controlat sau modificat – mai ales nomenclatorul de articole unde
Surub_0001234 este unic pe bază şi la Londra şi la București se vorbește aceiași
limbă, poate face parte din aceleasi structuri de producţie de fabricaţie sau din
aceleași politici de cumpărare /achiziţie [PO] sau de vânzare la client [SO];
- Taxele (TVA, acciza) şi codurile fiscale unice ale furnizorilor şi clienţilor (CUI/CIF la
noi RO12345678 ) se gestionează unic pe bază indiferent de sucursală.
Marele dezavantaj aici este timpul de răspuns pentru interogarea tabelelor:
- Tabelele tranzacţionale cel mai des utilizate cu tranzacţii de stoc (intrări/ieșiri),
jurnale contabile GL, facturi cumpărări (AP/PO), facturi client (AR/SO) şi toate
detaliile acestora pentru toate cele 4 firme/sucursale sunt f.f.mari ajungând în câţiva
ani la sute de milioane de tranzacţii per tabela.
Interogarea prin rapoarte diverse a unor astfel de tabele este f.f. greoaie durând minute
bune sau chiar ore. Un raport complex cum este balanţa de stoc per magazie, fişa de
client, fişa de magazie, fişa sau balanţa de furnizor nu au voie sa depășească 5 minute
Pagina 10/142
ca timp de execuţie. Chiar dacă se iau toate măsurile tehnice de optimizare posibile
acesta rămâne un mare impediment şi consumă ani buni din viaţa dvs. şi a colegilor
dvs. care exploatează aplicaţia chiar dacă:
- Aveţi un super- server cu 8 procesoare intel de ultima generaţie E5-4650-V4,
512GB DDR4 RAM cu discuri SSD;
- implementatorul a optimizat baza de date şi a [balansat] tabelele pe discuri diferite
pentru a obţine canale I/O separate;
- programatorii au forţat folosirea toturor indecșilor posibili.
3.2.2 Practică folosită pentru raportare în cazul bazelor mari unde

Baza1=PROD/REAL și Baza2=Test/Clona/Raportare
Scopul acestui mic sub-capitol este de a discuta care este cea mai bună variantă de
extragerere a rapoartelor cu consum mare de resurse, de unde le extragem, când le
extragem şi care ar fi erorile, blocajele şi disfuncţionalitățile posibile.
Nu discutăm aici despre necesitatea unei clone respectiv a unei copii de siguranță a
bazei reale de producţie. Copiile zilnice, săptămânale, lunare ale bazei de producţie sub
forma mecanismelor de back-up reprezintă o activitate separată pe care nu o tratăm aici.
Una din cele mai des folosite metode în cazul [bazelor mari] este folosirea a cel puţin
două baze de date astfel:
1. BAZA1 = este baza reală cu tranzacţii curente (în timp real). Ea se mai numește şi
baza de producţie sau baza reală sau baza on-line.
2. BAZA2 = este o bază clonă (o copie) a bazei reale BAZA1. Această copie se face
1:1 la intervale prestabilite de timp. În cele mai fericite cazuri copia se face în timpul
nopții pentru fusul orar principal între orele 22.00 PM şi 04:00 AM.
Condiţiile tehnice real recunoscute atât de catre [1]administratorul serverului principal
unde se află bazele BAZA1/BAZA2, [2]clientul care exploatează ERP (dvs.) şi
[3]producătorul/implementatorul acelui ERP ar fi urmatoarele:
- O firmă mare cu multe saituri, puncte de lucru sau cu mai multe firme în cadrul
grupului are şi o bază de date mare. O bază de date mare se consideră a fi peste
10 GB. În practică am întâlnit baze de 100 Gb şi de 200 Gb sau baze mai mari.
- Pentru copierea din baza de real/prod din serverul A pe serverul B (rezervă)
majoritatea clienţilor doresc ca aceasta să se facă cu mecanismul back-up on-line
adică [din mers] fară a opri serverul, adică fară downtime.
- O bază de date de 200 Gb nu se poate copia în 3 minute de pe serverul A pe serverul
de backup B la realizarea backupului on-line (adică fara să oprești serverul de bază de
Pagina 11/142
date). Copierea (backup) durează şi timpul de copiere crește în minute de la un an la

altul odată cu mărirea bazei de date.
- În timpul operației de copiere (backup) tranzacţiile din baza de date A/PROD/Real deși
sunt protejate, nu se mai execută la fel de rapid ca în timpul zilei. Rapoartele durează
mult mai mult în timpul copierii: dacă rulezi rapoarte complicate în timpul operației de
backup (balanța de stoc de exemplu) acestea durează f. mult şi renunți dând [cancel]
la raport sau [ctrl+C] sau închizi browserul Chrome sau Firefox sau dai [Delete] la
program din Task Manager.
În aceste condiţii unele firme renunță să mai facă back-up zilnic sau mută copierea
unedeva în timpul nopții când activitatea e minimă – vezi mai sus.
Cu toate acestea datorită multitudinii de rapoarte importante pe care financiarul le
execută (balanțe şi fise de toate tipurile, jurnale de casă/bancă, fișe de magazie etc..)
este practic necesar să ai datele la zi şi să optezi pentru rularea rapoartelor pe Baza A
/PROD/Real așa cum fac majoritatea firmelor şi să nu aștepți copierea din A în B şi să
rulezi rapoartele pe baza B/clona/test acestea nefiind la zi.
La nivel de tranzacţie atomică în cazul folosirii aributului [Firma/Company/Domeniu],

tranzacţiile arată cam așa în aceiași tabelă. Folosim aici un exemplu din registrul jurnal
general – echivalentul unei tabele GL [general ledger]:
cacc_eff_d cacc_ref Debit FirmaCompany Credit suma gltr_desc
19-10-2018 IC181019001198 6024 HCLondra 3024 19.6 ISS-UNP BC0014895/
19-10-2018 IC181019001199 6024 HCLondra 3024 7.95 ISS-UNP BC0014895/
19-10-2018 IC181019001200 6024 AragazeRasnov 3024 688.82 ISS-UNP BC0014896/149
19-10-2018 IC181019001230 6024 FrigidereWroclaw 3024 228 ISS-UNP BC0014955/PL FRU
19-10-2018 IC181019001231 6024 FrigidereWroclaw 3024 30.5 ISS-UNP BC0014902/240
19-10-2018 IC181019001232 6024 DepozitMarsilia 3024 28.81 ISS-UNP BC0014922/59
19-10-2018 IC181019001258 6024 HCLondra 3024 43.36 ISS-UNP BC0014939/984
19-10-2018 IC181019001264 6024 HCLondra 3024 62.18 ISS-UNP BC0014939/984
19-10-2018 IC181019001292 6024 FrigidereWroclaw 3024 7.95 ISS-UNP BC0014941/
Pagina 12/142
3.2.4 Tehnica de salvare lunară a tabelei de solduri finale versus soldul/stocul on

hand now (acum)
Am inserat acest capitol aici deoarece are mare legatură cu subcapitolele de mai sus
fiind mai potrivit aici decât în subcapitolele în care discut despre formarea prețului de stoc
cu CTA10 sau verificările de tip reconciliation sau activitățile de închidere de lună.
Ce vreau să spun prin această formulare complicată [Tehnica de salvare lunară a
tabelei de solduri finale versus soldul/stocul on hand now (acum)] ?
Există mai multe submodule care au de suferit d.p.d.v. al consistenței și al performanței:
a.) Consitența interogărilor şi aici punctual ne referim la valorile eronate oferite de
verificarea prin rapoarte încrucișate de tip balanța de stoc, balanța/fişa
clienţi/furnizor (terți în general), balanța contabilă cu 4-5-6 egalități, fişa contului,
fişa de magazie a aceluiași set de valori. Ce însemnă asta ? Exemplu concret:
Orice dată din modul sau din contabilitate provenită din orice modul ar trebui să o
verific din cel puţin două rapoarte separate ca să fiu sigur că valoarea respectivă ce
ține de cantitate sau valoare este corectă. Punctual în cazul verificării intrărilor şi
ieșirilor şi al stocului+SOLDUL final la Surub_0001234 ar trebui să verificăm
recapitulația pe documente intrate/ieșite cantitativ valorică care să bată cu nirurile şi
bonul de consum sau notele de transfer şi care să bată valoric apoi pe conturi atât
pe rulaj debit/Credit cât şi pe sold final cu fişa de cont a lui 3011 şi balanța
contabilă. Deoarece f. puţine ERP-uri au posibilitatea filtrării fișei de cont pe
articol de stoc magazie ești obligat să faci tot felul de artificii ca să verifici efectul
în conta al articolului Surub_0001234 […ce e aia să dai fişa de cont pe magazie şi
pe articol şi pe tert ? că fişa de cont se dă pe cont sintetic şi analitic şi atât!... ca așa
am învățat eu la cursuri…] Din tot ce e mai sus singura încrucișată posibilă aici ar
fi între Balanța de stoc (dacă o ai bineînțeles) şi Fişa de magazie pe
Surub_0001234 pe aceiași magazie şi aceiași perioadă şi verifici soldul + stocul
iniţial la intrarea în lună şi soldul final + stocul final, măcar astea să bată între ele.
10
CTA = cheltuieli de transport aprovizionare care împreună cu prețul de furnizor formează [prețul de stoc]. Vedeți
că în majoritatea ERP-urilor nu veți găsi noțiunea de Stoc Price ci de [cost PO] fiind asociat cu costul de pe PO (prețul
de pe comanda de aprovizionare).
Pagina 13/142
NOTA. Observație importantă:

Lipsa atributelor următoare: articolul de stoc, al magaziei şi a terţului care a
participat la acea tranzacţie (client, furnizor, salariat) în tranzacţia contabilă [în nota
contabilă] DEBIT=CREDIT a dus la folosirea diferitelor găselniţe11 de către
producătorii de ERP astfel:
a.) prin apariţia acelor câmpuri suplimentare (user fields) care se completează şi
se interoghează f. greu datorită lipsei de indecși asociați. Exemplu: Utilizatorul
[scoate în față] la facturare/livrare câmpul user_fields_char_1 (sau date_1 sau
number_1) şi pune în el ce vrea contextual pentru acel ecran (numărul auto al
camionului de livrare să zicem) şi după aia vrea ca acel câmp să mai apară
automat şi pe magazia destinație în cazul transferului pe bază de aviz inter-
filiale şi mai vrea apoi şi un raport cu situația camioanelor încărcate la sursa dar
care nu au recepţie în saitul destinație.
b.) O a doua [găselniţă] este îngrămădirea în mai toate ERP-urile în câmpul
descriere al notei contabile a unor elemente de genul:
Numar_NIR/COD_sau_nume_tert/magazie,articol
Sau:
Numar_factura_vanzare_SO/COD_sau_nume_client/magazie,articol
Sau:
Numar_factura_cumparare_PO/COD_sau_nume_Furnizor/magazie,articol
Rezultând ceva în descriere ca mai jos (un fel de ciorbă informatică):
NIR995577/ElectroapratajSA/Mag3011/301225544001
Sau:
FF705001/TimpuriNoiSA/Mag345/345/3459122008
Ambele soluții sunt nefezabile. În condiţiile în care peste 60% din notele contabile
din ERP provin din stocuri (IC/Inventory) şi pot fi lunar de ordinul sutelor de mii la o
firmă mare, soluția notelor contabile cu câmpuri de tip [USER_fields_00n] sau
atribute/câmpuri ascunse în descrierea notei este doar o [găselniţă]. Aceste
câmpuri ar trebui sa fie mandatory [obligatorii] în nota contabila având indecși
asociați lânga: data_efectiva_contabila, nr_document, cod_jurnal, debit, credit,
suma şi nu lăsate haotic la nivelul de interpretare a fiecărui implementator sau client
beneficiar….Mai mult, când vine omul de la vânzari12 să îl vrăjască pe patron “la
prezentare” una din primele propoziții pe care le auzim sunt […aplicația noastră
11
Găselniţă - aici are sensul de solutie tip work-around pentru rezolvarea unei lipse de funcţionalitate native a ERP-ului
prin artificii funcţionale contextuale. Nu ne referim aici la molia-albinelor, molia-stupilor sau omidă.
12
Omul de la vânzări – vezi paragraful cu Omul de la vânzări din capitolul pamflet [Cizmăria informatică de la sfârșit].
Pagina 14/142
ERP este super parametrizată și face orice… Doriți un câmp sau un atribut
suplimentar în unul din ecrane noi vă oferim 5 câmpuri tip char + 5 tip date + 5
number…etc.]
b.) Performanței interogărilor şi aici punctual ne referim la timpii mari de obținere a

rapoartelor de tip balanță de stoc, balanța/fişa clienţi/furnizor (terți în general),
balanța contabilă cu 4-5-6 egalităti, fişa de magazie. Şi aici mă repet că toate
aceste rapoarte trebuie obținute sub un minut de rulare (maxim 5-10 minute)
indiferent de dimensiunea bazei de date.
ERP-ul la care oricare din aceste rapoarte depășește 10 minute şi se duce la 1 oră
sau mai mult are o problemă mare privind:
- server slab sub-dimensionat în raport cu baza de date folosită adică baza de date
a crescut f. mult în ultimii ani iar serverul a rămas ca în 2008 când aveam câteva
tranzacţii.
- configurarea indecșilor pe tabelele importante prost facută de producator (prost
facută de programatorul arhitect de aplicaţie)
- are cod scris prost în zona de raportare în zonele de folosire a comenzilor de tip
Find, Do While, Repeat, For Each + clauzele WHERE, Group BY în conjuncție cu
tratamente inadecvate pe operatorii AND şi mai ales pe OR şi/sau în combinație cu
câmpuri caracter de dimensiune mare sau chiar pe folosirea inadecvată a
funcțiilor STRING > SUBSTR(x,y,z) sau similar (vezi în SQL92 utilizarea LIKE cu
“%nume_string_căutat%” ) .
Întorcându-ne la [Consitența interogărilor] care are mare legatură cu

[performanța interogărilor] să vedeți ce mari invenții şi găselnițe au făcut
producatorii de ERP de-a lungul anilor:
a.) Prima găselniță: Păstrarea soldului, stocului şi a ultimului preț pe ultima
tranzacţie executată. Justificarea folosirii acestei metode ar fi că:
- dacă analizăm fişa de magazie la [Surub_0001234] pentru intervalul
01-05-2021 la 31-05-2021 nu ne ducem să facem soldul+stocul pe istoricul 01-
01-2005 la 30-04-2021 parcurgând toate tranzacţiile de intrări/ieșiri (de la
“facerea lumii”: unde în 01-01-2005 a fost prima tranzacţie că atunci am dat
drumul la ERP la noi în curte şi atunci am încărcat stocul ințial pe magazii şi la
Surub_0001234). Şi atunci folosim [găselnița] adică ne ducem pe ultima
tranzacţie de azi 17-08-2021 identificăm soldul + stocul la zi şi apoi dăm înapoi
Pagina 15/142
folosind index descending pâna la 31-05-2021 unde formăm soldul final al lui
mai 2021 şi apoi dăm înapoi până la 01-05-2021 şi formăm soldul iniţial al lui
mai 2021 şi gata ….Adică: Nu mai parcurgem milioanele de tranzacţii intre 2005
şi mai 2021 că nu avem index optimizat pe data_efectivă+id_articol+magazie!
b.) A doua găselniță: au fost create tabele speciale de solduri lunare cel puţin pe
stocuri, clienţi, furnizori, contabilitate (solduri şi rulaje lunare) sincronizate cu
flagurile de închidere a calendarelor pe module. Asta însemnă că odată ce ai
pus flagul de închis pe modulul de IC (stocuri/inventory) din funcţia de control
calendar pentru martie 2021 atunci programul pune lacătul pe martie 2021
adică nu mai poti băga tranzacţii de nici un fel dar mai face şi o salvare specială
în tabela de solduri/stoc final pentru toate articolele (inclusiv Surub_0001234)
de pe toate magaziile. Astfel sistemul ERP păstrează într-o tabelă specială o
poză completă înghețată cu starea stocului la 31-03-2021 pe toate
articolele/magaziile. Aceast “poză” a stocului la 31-03-2021 este folosită apoi ca
punct de plecare în analize, rapoarte ca bază a tranzacţiilor pentru Aprilie 2021
şi urmatoarele. Justificarea folosirii acestei metode vine din vremuri străvechi de
la [Oficiul de calcul] (şi americanii şi francezii au avut oficii de calcul şi stații de
calcul cu Coral şi Independent şi IBM în 1980-1990). Acolo la Oficiul de calcul
exista o metodă de arhivare a soldurilor şi rulajelor şi când se făcea o analiză pe
istoric de date se pornea de la banda sau discul din arhiva de martie 2021.
Ambele metode de mai sus s-au dovedit a fi nefezabile creând multe confuzii,
deoarece:
- utilizatorii deschid calendarele din urmă şi fac tranzacţii de corecție pe istoric pe
toate meridianele nu numai în România fară a mai rula funcțiile de recalcul;
- soldul/stocul pe ultima tranzacţie şi fișierul special de solduri şi rulaje lunare trebuie
întreținute cu grijă şi dat recalcul la el atunci când apar disfuncţionalități;
- În Romania în martie 2021 încă mai facem corecții şi ajustări de inventare pe
stocurile cu probleme conform bilanț pentru 31-12-2020 adică umblăm masiv pe
istoric.
- O funcție de recalcul oricare ar fi ea pe o baza de date mare de zeci de Giga cu
milioane de tranzacţii nu poate fi rulată în timp optim.
Pagina 16/142
Soldul/stocul on hand now (stocul acum) se referă la o altă tabelă specială de stocuri
care conține stocul cantitativ la ERP-uri detaliat cel puţin la nivel de cod_articol
+magazie+lot. Unele ERP-uri au detaliat mai mult şi stocul se ține şi la nivel de locație
(raft) şi cod_serial şi cod_furnizor. Tabela generică ar fi: lot_detail_on_hand.
Această tabelă are o dinamică f. mare şi la o magazie de tip Warehouse unde toată ziua
intră articole din producţie sau aprovizionare şi se livrează apoi către clienţi, stocurile își
schimbă cantitatea on-hand (stocul acum în secunda asta) după fiecare intrare
/recepţie/NIR şi după fiecare vânzare la client. Americanii folosiesc termenul de shipping
atunci când [Surub_0001234] părăsește cu factură sau aviz magazia de livrare şi pleacă
către client.
În concluzie [Surub_0001234] poate avea on-hand acum 50 de bucăti în această
tabelă iar peste 30 de secunde în urma unui shipping/facturare la client de 12 bucăți să
aibă doar 38 de bucăți. Peste 1 ora în urma unui NIR /recepţie de 100 de bucăți
[Surub_0001234] va avea 138 de bucăți s.a.m.d
3.3. ERP ca siste m i nformatic ve rsus sis tem informaţional

Aplicaţiile ERP încearcă să fie o imagine fidelă a unor subsisteme informaţioale ale
unei firme. Acestea nu fac altceva decât să reproducă fluxurile informaţionale (tehnico-
economico-financiare-contabile) prin intermediul unor bucaţi de cod (programe compilate,
limbaje de programare) scrise în C++/#, Visual Basic, Foxpro, Borland/Delphi/Pascal,
Progress, Java, Cobol, (PHP mai puțin) etc. sau mai nou prin combinaţii ale acestora, totul
legat la o bază de date consacrată care poate suportă sute/mii de conexiuni simultan.
Am spus că “încearcă să fie” deoarece nu întotdeauna ele respectă fluxul real al
succesiunii documentelor sau operațiilor şi chiar dacă respectă, apare o mare rigiditate în
modificarea fluxurilor reale care implicit necesită modificări de funcţii, ecrane, procese.
În timpul implementărilor ERP s-a constatat întotdeauna o rezistenţă justificată din
partea utilizatorilor de la toate nivelurile la noile fluxuri și reguli impuse de noul ERP. Nu
există decât două metode de abordare:
a.) Reengineering în procesele firmei - redefinire a proceselor firmei (Business Process
Reengineering) pentru maparea la noul ERP;
b.) Reengineering aplicaţie ERP - Adaptarea funcţiilor, modulelor, rapoartelor la
cerințele specifice firmei.
Varianta (b) prin care ERP-ul îşi “coboară mintea” la cerinţele firmei este cel mai des
întâlnită în practică, deși nici un producător de ERP nu dorește să recunoască oficial
acest lucru că aplicaţia lui a trebuit să se adapteze la client și nu clientul la aplicaţie.
Pagina 17/142
Întotdeauna se dă vina pe consultantul/analistul de business că nu cunoaște “tainele ERP”

și de aceea nu a fost în stare să îl determine pe clientul cumpărător să înţeleagă ce
nemaipomenit este acel ERP. La fel de vinovat este [clientul cumpărător] de ERP fiindcă
nu vrea să înţeleagă ce mari beneficii va avea dacă va implementa acel ERP renumit care
tocmai s-a oprit la poarta lui doar dacă folosește acel ERP strict pentru ce a fost el
proiectat şi nu pentru alte destinații funcţionale care trec prin mintea [patronului] păcălit de
[omul de la vânzări13]…
3.4. Cu ci ne seama nă ERP- ul ?. Erp-ul se amănă c u [pări nţii] săi.
3.4.1 Primul cobai şi Născătorul de aplicaţie

Marea majoritate a aplicaţiilor ERP sunt gândite după chipul şi asemănarea a două
personaje importante:
1. Primului cobai reprezentat de primele firme la care s-a implementat aplicaţia poate
cu zeci de ani în urma. Putem spune că acest prim cobai este şi iniţiatorul primei
[comenzi sociale].
2. Născătorului de aplicaţie - de obicei un programator ambiţios care a încercat să
creeze primele module ale aplicaţiei pe baza cerinţelor multiple şi eterogene ale
primilor cobai care au dat primele [comenzi sociale]. Mai sunt şi cazuri rare în care
cel ce a născut aplicaţia a fost un contabil sau un economist care a “pus la treabă”
niște programatori dar această variantă este o excepţie.
Totul a pornit de la o funcţiune-modul şi s-a extins către celelalte funcţiuni. Domnul

programator (Născătorul de aplicaţie) nu a pornit niciodată cu toate modulele fiindcă
nu exista posibilitatea tehnică să le dezvolte pe toate simultan şi nici nu ar fi știut ce
trebuie să facă.
Exemple, variante:
- una din aplicaţiile ERP a pornit punctual de la modulul de raportare producţie. Pe
el s-au dezvoltat nomenclatoare specifice de lansare comenzi, tehnologii, reţete,
structuri. Lânga el s-a dezvoltat apoi un mic modul de stocuri (intrări ieșiri), apoi un
simulacru de contabilitate care să imite contabil (clasa 3 la noi) ce se întampla în
stocuri, apoi un modul de cumpărări (aprovizionare, recepţii) care la rândul lui a tras
13
Omul de la vânzări + Clientul cumpărător +Patronul sunt personajele din pamfletul de mai jos [Cizmăria
informatică. Sau cum să vinzi și mai ales cum să cumperi linia de miră a unui ERP (versiunea originală din noiembrie
2011)]
Pagina 18/142
după el modulul de furnizori şi apoi pe cel de plăţi. Mai târziu a venit joncţiunea cu
modulul de facturare/livrare, submodulul de clienţi şi apoi cel de încasări.
- O altă aplicaţie s-a dezvoltat modular aproape în mod egal de la început
încercând din start să acopere: Stocurile cu toate operațiile cunoscute, apoi modul
de mijloace fixe (aveau nevoie şi de mentenanţă utilaje) apoi un modul de terţi
(clienţi+furnizori) cu plăţi şi încasări incluse în același modul şi apoi un capac
contabil care să tragă date din aceste module. În acest caz s-a observat că unele
module “au rămas în urma” modulelor principale fanion.
- O altă aplicaţie Erp a pornit din zona de facturare, clienţi, distribuţie şi se obsevă
din start că nucleul principal a fost dezvoltat pe logica unui mare cobai distribuitor
(care acum 35-40 de ani probabil a acceptat să fie cobai). Pe lângă au apărut apoi
modulul de stocuri, un simulacru de producţie şi modul de furnizori, recepţii,
aprovizionare. Bineînţeles că fiecare modul “aruncă “ date într-un jurnal contabil așa
cum l-au învățat părinţii lui la care trebuie să mai faci tu multe ajustări între module
şi conta (ledger to sub-ledger reconciliation) .
Exemplele pot continua.
De aici rezultă că din “concubinajul” celor doi s-a născut primul nucleu al aplicaţiei
pe care s-a clădit uneori “dezordonat” în continuare până în ziua de azi sau contextual
forțați de împrejurări (cerință piață).
Şi acum:
- dacă concubinajul a pornit prost şi a continuat prost poate zeci de ani, dvs. vă
întrebaţi azi probabil de ce aplicaţia ERP pe care o folosiţi e frumoasă dar uneori vă
umple de nervi şi vă determină lunar să staţi pâna la ora 2200 să faceți închiderea
perioadei financiare (closing month operations - month-end closing).
- dacă concubinajul a pornit bine acum mulți ani atunci sunteţi norocoși fiindcă
aplicaţia ERP permite să vă faceţi închiderea de lună în timp rezonabil şi fară un
consum de nervi inutil. Asta înseamnă că aplicaţia este scalabilă şi ușor adaptabilă
la modificările legislative, cerinţe interne de business sau raportări complexe cu
efort financiar rezonabil - uneori regăsit în costul de mentenanţă, de obicei plătit
producătorului.
În afara celor două cazuri de mai sus mai apare o variantă în care: deși
aplicaţia este foarte bună, ea de fapt nu este bună pentru tine. Asta se întâmplă
de obicei din ambiţia unor patroni sau directori de a implementa cu orice risc în
compania lor un ERP care are o cu totul altă destinaţie funcţională, adică se
Pagina 19/142
adresează din start unei alt tip de companie decât compania lor. Aici iar se ramifică
două cazuri:
1. Varianta 1 - Aplicaţia este impusă de firma mamă (Headquarter-ul grupului de
firme) din care şi filiala dvs. din Romania face parte şi este necesar a fi folosită
în primul rând pentru agregarea şi consolidarea datelor din filialele din lume în
serverul central din City-X şi nicidecum nu este dedicată specificului funcţional
al filialei din Romania. Mulți contabili șefi au fost obligati să își cumpere din
buzunarul propriu o a doua aplicaţie (CIEL, Saga, Winmentor sau similar de la
un producător român) pentru a scoate balanţa cu 4 egalităti (8 coloane).
2. Varianta 2 – cumpărarea şi implementarea aplicaţiei este o ambiţie
nefundamentată a acţionarilor principali fără a verifica dacă aplicaţia se
potrivește specificului lor. Aici se merge pe principiul: “dacă vecinul meu şi-a luat
Mercedes atunci şi eu trebuie să cumpăr unul...”.
Cazurile de mai sus le-am detaliat în pamfletul “Cizmăria informatică” într-un capitol
separat la sfârșit.
3.4.2 ERP-ul şi verticalele de afaceri versus cheia franceză bună la orice.
1. Versiunea cu verticalele de afaceri.

În urmă cu ceva timp producătorii de Erp spuneau că aplicaţia lor se potrivește
următoarelor verticale de afaceri sau că modulul XYZ se potrivește unui anumit segment
de business.
Foarte puţini dintre ei spun şi azi că aplicaţia lor a fost calată şi se potrivește doar la o
singură verticală de afaceri să zicem:
- Doar la construcţii montaj;
- Petrol – reparații sonde, Petrol – extracție, Petrol – rafinare, Petrol – benzinării;
- doar la industria auto (asamblare) sau doar la segmentul de componente auto
(parts, discterete manufacturing) ;
- Sau doar la industria alimentară de masă (bere, suc, lapte, pâine, carne, pește) ;
- Sau doar la segmentul X din industria Y - abatorizare sau doar la tranșare carne
sau doar la producţia de mezeluri.
Producătorii/implementatorii de ERP care vor recunoaște că aplicaţia lor este destinată
doar unui sgement respectiv doar unei verticale de afaceri recunoscând totodată că
aplicaţia poate acoperi în mod rezonabil dar nu suficient şi alte verticale de afaceri sunt
Pagina 20/142
de preferat a fi aleși să vă prezinte aplicaţia lor şi apoi eventual să o şi implementeze la

dvs. în curte.
2. Versiunea cu [Cheia franceză bună la orice].
Se pare că producatorii de ERP azi nu mai recunosc că aplicaţia lor se poate folosi
rezonabil doar la una din verticalele de afaceri şi că doar tangențial pot acoperi şi alte
funcţionalitati de la alte verticale.
Azi ERP-ul este prezentat ca o [cheie franceză] bună la orice cu care putem desface
orice tip de șurub şi de orice dimensiune chiar dacă nu avem chei speciale dedicate
acțiunii sau contextului tehnologic respectiv: tubulare, fixe, inelare.
Grav este că unii vor să ne convingă că cu ajutorul acelei [chei franceze] nu ne rezumăm
doar la desfacerea oricărui tip de șurub ci putem da şi găuri în ziduri de beton sau în
asfalt [lucru posibil doar cu rotopercutanta sau cu picamerul] şi uneori putem să şi
sudăm în argon14 şi dacă suntem puţin atenţi facem şi sudare subacvatică…
3.4.3 ERP-ul, sofismele15 şi viciile de consințământ – DOLUL16.
Ce legătură au DOLUL şi sofismele cu Erp-ul?

Păi cele două reprezintă forma juridică prin care ERP-ul promite că face ce de fapt nu
poate face. La asta intervine naivitatea clientului cumpărător care datorită lipsei de
experiență înghite tot ce spune producătorul fară a testa fluxul dorit în interiorul aplicaţiei
cap-coadă astfel:
- setări necesare, introducere date (operare documente), obținere rapoarte (toate
rapoartele necesare), stornări documente operate eronat şi corecții, verificări
încrucișate între rapoartele de modul cu cele de conta.
La cele de mai sus se adaugă:
- setul de rapoarte obligatorii conform legislaţiei românești;
- introducerea manuală linie cu linie prin copiere manuală de pe alte documente
primare cel puţin a facturilor de furnizor (AP) atât de servicii cât şi de stoc urmate sau
simultan cu recepţia (NIR) atât de la furnizori interni (cu fară TVA) cât şi externi (UE
14
Sudură argon = procedeul TIG WIG. Sudarea TIG/WIG este un procedeu de sudare cu arcul electric în mediu de gaz
protector inert cu electrod nefuzibil.
15
Sofism = SOFÍSM, sofisme, s. n. = Silogism sau raționament corect din punct de vedere formal, dar greșit din punctul
de vedere al conținutului (fiind bazat pe un echivoc, pe utilizarea aspectelor neesențiale ale fenomenelor etc.), adesea
folosit pentru a induce în eroare; p. gener. argument, afirmație etc. false. – Din fr. sophisme, lat. sophisma.Sofismul
este o premisă sau un argument fals, formulat cu scopul deliberat de a înșela pe altul.
16
Dolul împreună cu eroarea, violența şi leziunea reprezintă viciile de consimțământ. Vezi Codul Civil art.1206 NCC.
Pagina 21/142
non ue), facturi diverse de vânzari cu /fară comandă de vânzare asociată pentru clienţi
diverși (interni, UE, NON-UE), încasări şi plăți prin registrele de casă şi bancă;
- rulare reevaluare facturi în sold lunară, rulare amortizare Mfixe (dacă ai şi modul de
mijloace fixe), încărcare note externe de salarii (GL/JL dacă salariile le ții în aplicaţie
separată), închiderea lui 121;
- Toate acestea operate în ERP în moneda documentului: Lei sau valute după caz
(USD, EUR, GBP etc…).
Exemplu: în timpul negocierilor pentru cumpărarea unui nou ERP firma implementatoare
spune că:
- la orice întrebare pusă de clientul cumpărator vânzatorul spune că […DA aplicaţia
permite această funcțiune…..nativ sau cu mici “intervenții”]
- daca totuși clientul cumpărător insistă şi întreabă de exemplu:
Întrebare client cumpărător:
[…vă rog să îmi aratați şi mie cum gestionați dvs. prin ecranele/meniurile aplicaţiei ERP
înregistrarea prețului complet FIFO incusiv CTA în cazul operării mai multor DVI-uri lunar
operate în puncte de lucru aflate la distanță de sediul central …].
Răpuns vânzător: Atunci vânzătorul spune că datorită complexității modulelelor implicate
nu poate să arate acum tot fluxul dar poate acum să arate doar câteva ecrane care ar
avea legatură cu fluxul respectiv.
Sau în varianta 2: va spune că aduce data viitoare (la prezentarea următoare) un flux cap
coadă. Între timp face repede un power-point cu săgeți, plăcinți şi butoaie (grafice) şi
câteva ecrane cu săgeți între ele şi zice că gata pe aici se gestionează Dvi-ul ….
Dolul împreună cu celelalte vicii de consimțămînt (eroarea, violența şi leziunea) sunt

unele din faptele cel mai greu de dovedit.
[….Art. 1214 alin. (1) C.civ. dispune următoarele: „consimțământul este viciat prin dol
atunci când partea s-a aflat într-o eroare provocată de manoperele frauduloase ale
celeilalte părți ori când aceasta din urmă a omis, în mod fraudulos, să îl informeze pe
contractant asupra unor împrejurări pe care se cuvenea să i le dezvăluie….”.]
Sofismele sunt acele raționamente false prezentate ca fiind adevarate în momentul
prezentării aplicaţiei ERP înainte ca clientul să semneze contractul.
Pagina 22/142
3.4.4 Cum aleg un ERP pentru organizația mea?
Azi internetul este plin de sfaturi oferite de consultanți și specialiști independenți și

bineînțeles de firmele din domeniul ERP.
De la începuturi ERP-ul a fost o cutie neagră pentru clientul cumpărător și pentru
utilizator.
Primele Erp-uri au fost scrise sub compilatoare tip DOS/UNIX în format TEXT fără
grafică (ceea ce numim azi WINDOWS /GUI), funcționau pe terminale simple alb-negru
format 80/25 (coloane/linii) (sau verde/negru , alb /verde). La vremea aceea ERP-urile
erau exploatate întotdeauna de persoane școlarizate temeinic privind funcționalitatea de
navigare (meniuri/funcții), de operare pe fluxuri de business cu cascadă de documente
specifice fluxului dar și școlarizări ce țin de funcționalitatea de ansamblu adică cam care
sunt setările necesare, care sunt modulele implicate și “cum vorbesc acestea între ele”.
Asta însemnă că [cutia neagră] este înțeleasă treptat bucată cu bucată și de abia după
mulți ani ne putem pronunța că acel ERP e bun sau rău sau ne-ar folosit la ceva sau nu.
În cazul în care vreți să faceți saltul de la o aplicație small-business financiar contabilă
la o aplicație Erp chiar dacă producatorul este de bună credință atunci când vă prezintă
aplicația sa Erp, dvs. nu puteți distinge corect toate aspectele importante ce țin de acel Erp
decât după luni de zile (de obicei minimum 6 luni), respectiv:
1. Dacă acel Erp se potrivește specificului activității dvs.;
2. Daca acel ERP acoperă majoritatea cerințelor legislative;
3. Daca acel Erp scoate majoritatea rapoartelor operative și de sinteză;
4. Care este efortul total de implementare din partea dvs. și care este costul TCO17
unde în TCO vom cuprinde:
a.) “Pierderile de vreme” anterioare momentului semnării contractului de
implemenentare ce cuprind: prezentări, discuții, vizite, delegații, ședințe;
b.) Costul școlarizării plătit firmei implementatoare (producătorului) la care se
adaugă costul scoaterii din producție a oamenilor tăi importanți care vor fi viitorii
utilizatori ai aplicației. Școlarizarea poate fi atât funcțională ce ține de fluxurile și
meniurile aplicației dar și tehnică ce ține de baza de date folosită și limbajul folosit;
c.) Costul aplicației Erp format minimum din costul BAZEI de date plus costul
aplicației în sine;
17
TCO sau The total cost of ownership, adică costul total real al acelui Erp eșalonat pe minimum 2 ani.
Pagina 23/142
d.) Costul cu elemente hardware noi obligatorii fară de care aplicația ERP nu poate
funcționa cum ar fi: un server nou, PC-uri diverse, imprimante, elemente de
rețea;
e.) Costuri post-operatorii adică după ce aplicația a fost instalată, am facut
școlarizarea și am intrat pe real/producție (suntem live) cum ar fi: costuri noi cu
reluarea școlarizării pentru persoane noi sau reluări. Costuri cu mentenanța
anuală/lunară.
f.) Costuri cu modificări, funcții sau rapoarte noi pe care le dezvoltați dvs. cu colectivul
dvs. IT dacă aplicația permite acest lucru fară intervenția producătorului.
Un caz fericit este acela când cumpărați un ERP care a fost implementat într-o
firmă similară profilului dvs. de activitate (de pe o verticală similară de afaceri în
principiu) și patronul acelei firme vă recomandă că acel Erp este bun și eventual vă
oferă și alte detalii funcționale și de exploatare.
Pagina 24/142
3.5. T ermeni fundame ntali: J IT , AP, AR, IC, PO, GL, G AAP, APICS.
3.5.1 Să începem puţin cu APICS. Gestionare Stocuri [Inventory]
Menționez aici APICS care înceracă să suplinescă prin intermediul ONG-urilor prin termeni
complicați lipsa normalizării în activitățile de mișcare de stocuri din patrimoniul unei
firme din USA, ceea ce în Franța şi România este normată prin planul de conturi,
ordine şi legi punctuale emise de stat. Nu fac aici reclamă lui APICS și nici uneia din
organizațiile (ONG) care oferă cursuri în acest domeniu inclusiv în Romania. Scopul
menţionarii principiilor APICS în acestă lucrare despre aplicaţiile Erp este următorul:
Dacă aveţi acces la oricare din cele 5 cărți/manuale de mai jos veţi observa în interiorul
fiecăreia dintre ele enumerări de sub-principii, acţiuni sau metode înșirate (un fel de
articole de lege enumerate haotic) și cu paragrafe pe care le găsim enumerate 1:1
(aproape identic, unu la unu) la nivel de meniu, funcţie sau tabele în interiorul marilor
aplicaţii ERP.
În concluzie, un principiu din cele 5 de mai jos este spart (divizat ) în alte 7-10 sub-
principii [principii derivate de gradul 1] care la rândul lor pot avea sub-principii de gradul 2
și care fiecare pot avea un corespondent într-un modul, meniu, funcţie sau tabelă din
interiorul aplicaţiei ERP.
Situație posibilă:
Dacă eu fac o aplicaţie simplă în Visual-Basic, Foxpro sau Delphi/Borland repede
cu niște meniuri și scriu pe ele :
[Manufacturing Management] apoi submeniurile:
a.) manufacturing product structures
b.) material requirements planning (MRP)
c.) capacity planning and management
d.) producţion activity control
e.) advanced scheduling
f.) lean production management
Sau poate nici nu mă mai chinui să fac ceva în Visual-Basic, Foxpro sau Delphi/Borland.
Fac direct ceva în PowerPoint ca omul de la vânzari din Cizmăria informatică – vezi
capitolul [Pamflete despre ERP cu iz economic și mai ales informatic].
Pagina 25/142
Acum vin întrebările legitime:

Înseamnă că automat aplicaţia mea este un ERP ?
Înseamnă că ERP-ul meu respectă principiile și sub-principiile APICS din zona
principiului nr. 3 [The APICS Principles of Manufacturing Management] de mai sus
sau altele și trebuie să îl cumpăr neapărat?
Automat voi obţine o balanţă de stoc corectă pe magazia X care va bate cu
conturile de clasa 3 din balanța contabilă ?
Posibile răspunsuri:
După ce am făcut aplicaţia de mai sus, ca ea să devina ERP și eu să pot să vin cu
ea să o implementez în curtea dvs. va trebui să o certific APICS (sau similar) adică să
chem niște experţi de la APICS și să îmi dea o diplomă prin care se certifică că aplicaţia
mea respectă principiile APICS. Ceva similar cu certificările iSO la nivel de firmă pentru a
putea avea acces la unele licitaţii SEAP.
Între timp ar fi bine (și chiar recomandat) să certificăm și toţi consultanţii și project
managerii mei pe module tot APICS și ulterior să certificăm și câţiva din anagajaţii dvs.
importanţi (ai clientului la care se implementează aplicaţia). Am uitat: dacă implementarea
nu o face producătorul de ERP direct și se face prin parteneri atunci desiguri toţi
implementatorii partenerului trebuie să fie certificaţi APICS (măcar pe module).
Concluzie: dacă toţi portarii producătorului, toţi portarii partenerului-implementator și toţi
portarii clientului beneficiar sunt certificaţi APICS atunci nu se va strecura nici o gresală
prin nici una dintre porţi și totul va fi un real succes în implemntarea ERP-ului la dvs. în
curte ?
Iar Balanţa de stoc de pe magazia X va bate cu Balanţa contabilă şi cu Recapitulaţia
intrărilor/ieșirilor pe surse/destinaţii pe documente ?
În urma cu câţiva ani puteai citi că ERP-ul pe care doreai să îl cumperi sau poate chiar l-ai
cumpărat respectă principiile APICS. Sună bine și încă mai sună bine și azi dar nu e
suficient. Pentru că SUA a fost și este statul care încurajează libera iniţiativă și are
probabil cea mai mare producţie robotizată din lume (producţie de masă și serie mare),
ONG-urile au preluat mascat funcţii necesare în care statul nu se implică mai deloc
conform principiului statului minimal (care nu e deloc adevărat pentru SUA). În lipsa
unor norme economice sau organizatorice care să definească activitatea contabilă şi
economică pe un anumit segment, un grup de industriași au format un ONG în care s-a
inventat cadrul funcţional pentru controlul Producției (Production) si al stocurilor (Inventory)
numit: APICS. S-a inventat “un ceva” la nivel de principii funcţionale la care ulterior unele
Pagina 26/142
ERP-uri s-au aliniat. Nevând plan de conturi legiferat18 + norme de aplicare a fost inventat
ceva după care să se ghideze lumea. Aceste principii funcţionale sunt împărţite în 5
categorii și încearcă să îndrume enoriașul care se apucă de business în legatură cu:
- cum să miște el mai eficient stocurile (inventory) provenite de la furnizorul X fară să
le stocheze prea mult în curtea/magazia sa în procesul lui de [supply chain
management / SCM];
- cum să proceseze mai rapid materialul adus (inventory) fară să aibă cheltuieli de
stocare proprii. Dacă poate să aducă șuruburile de la furnizorul X cu 5 minute
înaintea consumului efectiv în producţie (chiar în noaptea asta pe la ora 02:00 AM)
și să le pună pe tractor la 02:05 AM și apoi să livreze tractorul la clientul Y
dimineaţă la 05:00 AM, ar fi foarte bine… sau măcar la 08:00 AM cel târziu!
- Iar în cazul în care nu are producţie (dar are comerţ) să ia șurubul de la X și să îl
trimită direct la clientul Y fară ca acest șurub să treacă eventual prin magazia lui.
Adică să fie un fel de combinator [bișniţar] sau mai nou [drop ship orders guy] ;
- cum să plătească cât mai târziu pe furnizorul X eventual la 90 de zile de la
recepţie;
- cum să încaseze mai repede factura emisă la clientul Y și dacă se poate în avans
cu 30 de zile înaintea livrării;
- Am uitat una importantă: despre folosirea la maxim a resurselor numite angajaţi
(employess) din pool19, muncitori operativi sau TESA (nu contează): dacă una din
resurse stă degeaba din motive obiective sau subiective (strungul s-a stricat, nu
avem materie primă în momentul ăsta de prelucrat, mașinile de la operaţia
următoare sunt oprite și piesa noastră nu poate trece încă de locul îngust din
lanţ20 s.a.m.d) atunci strungarul Vasile să poată fi relocat/anunţat imediat ca fiind
[liber] într-un așa numit pool sau grup la dispoziţia conducerii și apoi refolosit
eficient pe un alt strung, freză sau raboteză libere sau măcar în curte la măturat
frunze sau dat zăpada ca omul să nu cumva să stea degeaba.
Simplist vorbind această folosire la maximum a resurselor prin resources
pool o regăsim explicată în clar în filmul lui Charlie Chaplin [Factory Work / Modern
Times (Timpuri noi21)] din 1936.
18
Plan comptable général (France) sau Planul de conturi general (România).
19
Pool de la resurse umane a nu se confunda cu [pull] de la kanban/lean manufacturing. Pool se referă la un spațiu
virtual în care te anunți singur sau au grija să te anunțe ei automat atunci când nu ai de lucru prin ERP dacă se poate.
Nu se mai respectă fişa postului, atribuții, sarcini, competențe (triunghiul de aur al organizării) și ești trimis acolo unde
patria are nevoie de tine. S-a defectat strungul tău te duci în curte la frunze…
20
Loc îngust = Bottleneck (production) – locul îngust din lanțul de producţie.
21
Timpuri noi Factory Work / Modern Times este un film din 1936 cu Charlie Chaplin în care este surprinsă folosirea
la maximum a timpului de lucru al unui muncitor: nu există noțiunea de TON [Timpul de odihnă şi necesităţi fiziologice].
Chaplin manâncă și lucrează cu mâinile în același timp.
Pagina 27/142
APICS sunt formate din urmatoarele 5 principii cunoscute și ca principii SCM

(Supply chain Management):
1. Principles of Inventory Management
2. Principles of Operations Planning
3. Principles of Manufacturing Management
4. Principles of Distribution and Logistics
5. Principles of Managing Operations
Sunt foarte multe instituţii (ONG-uri în general) care oferă cursuri în zona APICS.
Am ales ca exemplu următoarele care mi s-au părut mai elocvente și sunt structurate
în 5 manuale separate:
https://www.apics.training/courses/apics-principles
https://www.ascm.org/ (fost www.APICS.ORG)

Si de la Edumaritime: ASCM Association for Supply Chain Management:
https://www.edumaritime.net/illinois/apics-chicago
https://www.edumaritime.net/illinois/ascm-association-for-supply-chain-management
Dacă avem curiozitatea să detaliem puţin oricare din cele 5 principii de mai jos, parte din
ele se află în meniurile sau ecranele unor aplicaţii ERP,
Respectiv: Inventory Management+ Operations Planning + Manufacturing
Management+Distribution and Logistics+Operations Management
Pagina 28/142
3.5.2 Alţi termeni folosiţi: PO, AP, AR, SO, WO.

Veţi observa că modulele aplicaţiilor ERP anglo-saxone folosesc termeni existenţi în
economiile din SUA, Marea Britanie sau Olanda. La acestea veţi găsi noţiuni, ecrane,
rapoarte care ne vorbesc despre: Agging, Stoc as of date (stoc la data), AP, AR, SO, PO,
WO (Accounts payable, Acounts receivable, Sales orders, Purchase Orders, Work
Orders), Shop floor (secție atelier – operațional), segregation of duties (separarea
responsabilităților), Acount Statement (lista tranzacţiilor unui cont contabil – şi nicidecum
de Fişa De Operaţii Diverse!), Cost Management (unde baza o reprezintă costul standard
sau mai nou recalculat > periodic costing), Master Data (nomenclatoare), Credit Note,
Pending Invoice (factură client în lucru/așteptare/neterminată) şi multe altele.
Observaţie: jurnalizarea contabilă aici este facută în cel puţin doi pasi în primul rând la
nivel de modul operativ tranzacţional-contabil (numit și subledger) şi apoi reluată prin
postare note (sau similar) numai contabil în zona așa-numită GL (general ledger) doar pe
conturi fără atributele importante din modulul sursă (vom explică această corespondență
modul-conta mai jos). Aici ERP-ul are restricţii operaţionale puternice ce nu permit
modificarea tranzacţiilor contabile din zona finală contabila (fişa cont la noi) provenite din
module (stocuri, M.Fixe, Plaţi/încasări etc.).
3.6. Alte partic ula rităţi specifice [T hree-Wa y Matc hi ng PO],

Comanda de Apro vizio nare și va riaţi i:
3.6.1 Legătura PO>Nir>Final Ap Invoice numită și [Three-Way Matching în

Accounts Payable]
În literatura de specialitate și în practica Erp veti găsi și conceptele surori: Two-Way și
Four-Way matching PO22. Baza la toate trei o reprezintă diferențele de tip ADJ
(adjustments) ce apar între cele trei momente importante respectiv PO>Receipt>Invoice
respectiv ComandaApropvizionare>NIR>FacturaFurnizor generate de cantități și prețuri
aflate în cele 3 stadii. Fizic și informatic cele 3 concepte generează tranzacții de stoc
și/sau simultan tranzacții contabile [note contabile]. Toate cele 3 variante nu au
corespondent în practica contabilă românească desi există 4 conturi în acest sens
(308,378,348,368). Preponderent la noi se utilizează inventarul permanent (cel mai des
22
Two, Three, and Four Way Matching PO = Proces complex de aplicare al facturii furnizor (AP) peste NIR (receipt) și
PO bazat pe generarea de variații valorice în contabilitate cu trei variante funcționale specific contabilității GAAP în
procesele SCM. Vezi și Research Foundation of State University of New York :“…in 4 way matching an invoice is
matched to the corresponding purchase order for quantity and amount, receiving, and inspection information.…”:
https://www.rfsuny.org/media/rfsuny/procedures/ap_2-3-4-way-matching_pro.htm
Pagina 29/142
utilizat impreuna cu metoda cantitativ-valorica) versus inventarul intermitent (rar utilizat

doar la firmele mici). Variațiile de bază sunt generate de cantitate și preț dar apar variații
suplimentare pentru cursurile de schimb folosite între cele 3 momente
[PO>Receipt>Invoice] fiind legate de data documentului și cursul de schimb din acea
dată (în cazul nostru cursul BNR).
Funcțional și operațional la o primă vedere [superficială], pe românește reprezintă

introducerea sau manipularea inutilă de 3 ori a aceluiași document. Exact ca acum 40 de
ani.
Să explicăm puţin termenii și utilitatea lor:
a.) PO – este [purchase order] adică comanda de aprovizionare pe care tu o
lansezi către furnizorul X. Nu poti să sari peste pasul asta că e motoda de
management în ERP.
Preţul de PO (po price sau po cost) este cel care dictează toate notele contabile
din aval precum și modul de încărcare a valorii stocului de magazie.
După confirmarea cu furnizorul de cantintate, preţ, calitate, termeni de livrare, etc. o
introduci manual în ecranul de PO, linie cu linie.
Pâna aici nimic anormal pentru un mare business-man ca tine care are nevoie de
un control și analize al preţurilor de achiziţie versus preţ real de recepţie. Problema
va apare la pașii următori [b] recepţie (NIR) și la [c] aplicare factură AP (Ap invoice)
când 90 la sută din ERP-urile consacrate îţi vor genera variaţii de pret care se vor
duce către diverse conturi de cheltuială sau stoc generând o f. mare confuzie în
contabilitate și confuzie în controlul preţului real de stoc (FIFO cu identificare
specifică). Cel mai grav aici este inconsistenţa valorii de stoc (preţ de stoc) și contul
contabil de clasa 3 implicat (sau 6 dacă s-a dus aiurea pe cheltuială).
Pentru a rezolva acest [viciu funcţional] sau [facilitate] sau [deficienţă] ERP-
urile au găsit o [găselniţă] ca nu știu cum i se mai poate spune care își are
rădăcina tot în anii 70-80 în America când toate preţurile erau judecate ca
[Standard Cost /Price], actualizarea lui Standard Cost se făcea o data la 6 luni/ 1 an
iar variaţiile fată de Ap_Invoice_price erau f. mici și se duceau întotdeauna pe
cheltuială (cum se mai duc și azi).
În contabilitatea românească și franceză nu există o astfel de abordare:
- Prețul real de intrare în patrimoniu începe de la prețul de Factura sau Aviz dacă
există avize multiple care se închid în factura periodică (lunară/săptămânala) dar nu
mai târziu de ultima zi a lunii de calcul.
Pagina 30/142
- Doar eventuala diferenţa între preţul de Aviz din care am făcut linia de NIR și preţul
real de factură finală este acceptat a se duce pe variaţii (direct pe contul cheltuială
+/- debit clasa 6 ) și numai dacă acestea sunt mici și repetabilitatea lor este
constantă lunar. Adică cam în fiecare lună avem cam aceleași variaţii de preț între
avize>factură și stocul lor se descarcă lunar cam în aceiași proporţie pe cheltuială.
În caz contrar ne-ar trebui un sistem de încărcare iniţial în 308,378,348 și apoi
descărcare automată proporţională a contului de variaţie pe cheltuială lunar [ceva
asemănător cu k-ul de la magazinele global valorice 378,371,4428 (butic)] sau cu
descărcarea lunară a lui 348/711din producţie [manufacturing].
- În ERP-urile bazate pe contabilitatea anglo-saxonă / GAPP NU veți găsi noţiunea
de descărcare de gestiune contabilă prin K (308,378,348) și nici un mecanism
funcţional asemăntor. Singurele mecanisme de descărcare de gestiune sunt făcute
de vreun român, ceh sau polonez ca localizare (customizare) separată lânga
“marele” ERP anglo-saxon fiindcă a țipat contabilul șef că ceva e în neregulă pe
acolo….dar nu știe ce.
- Preţul de PO nu există pentru contabil. Prețul PO este doar un reper de
management al aprovizionării. Prețul de factură furnizor este cel acceptat în
încarcarea stocului (clasa 3) precum și în preţul de stoc. Vezi aici corelaţia dintre
preţul de stoc (inclusiv CTA23) din balanţa de stoc și conturile de clasa 3 în rulaje
lunare debit/credit (intrări ieșiri) și soldul final la sfârșit de lună.
Pentru această problemă unele aplicaţii ERP deţin cel puţin două mecanisme:
- La introducerea facturii AP finale ești întrebat dacă variaţia se duce pe STOC
[STOC+ contabilitate simultan] sau numai pe Contabilitate [cont de cheltuiala/6]
- Sau din start ţi se oferă posibilitatea blocării transmiterii variaţiilor către stoc și
trimiterea lor automată către cheltuială.
Exemplu concret:
Ai un NIR de 120 de linii (unasută douzeci de linii sau mai mult) îl vei opera de trei ori:
- O dată la nivel de PO;
- A doua oară la nivel de NIR;
- A treia oară când aplici liniile facturii peste liniile nirului.
Dacă cele 120 de linii provin din recepţia unui DVI care are pe lângă preţul furnizorului în
USD (din China de exemplu) și alte cheltuieli [CTA] cum ar fi taxe vamale, comision vamal,
23
CTA = cheltuieli de transport aprovizionare care împreună cu prețul de furnizor formează [prețul de stoc]. Vedeți
că în majoritatea ERP-urilor nu veți găsi noțiunea de Stoc Price ci de [cost PO] fiind asociat cu costul de pe PO (prețul
de pe comanda de aprovizionare).
Pagina 31/142
factură de transport atunci procesul de alocare al acestor costuri suplimentare este f.

dificil.
Trebuie ţinut cont aici și de toate celelalte implicaţii cum ar fi:
- În nici una din aplicaţiile ERP “serioase” nu scapi de PO adică nu poţi băga NIR-ul +
factura într-un singur pas. Trebuie să faci 3 pasi;
- Formarea facturilor separate [1 Factură furnizor China] , [2 Factură Transportator],
[3 Factură furnizor Vama cu comisioane + TVA] și apariţia lor în Jurnalul de
Cumpărări fiecare la poziţia lui;
- Formarea notelor contabile aferente tuturor acestor facturi;
- Încărcarea valorică a stocului la preţ furnizor inclusiv CTA;
- Cursul de schimb BNR sau de Vamă din ziua Dvi-ului.
b.) NIR, RO= [Nota de Recepţie și constatare de diferenţe], EN = [GRN = Goods
receipt note] – este momentul recepţiei reale manuale linie cu linie în momentul
când camionul descarcă marfa în curte (conturi de clasa 3 discutăm aici că pot fi și
recepţii de clasa 2 [MFixe] pe care nu le tratăm aici), facem recepția organoleptică,
cantitativă și calitativă și încărcăm magazia X. Data PO <> Data NIR.
c.) Factura Fiscală furnizor, EN=[Ap invoice] – este mometul când aplicăm factura
peste NIR și comanda de aprovizionare. Data PO <> Data NIR <> Data factură.
3.6.2 Variaţiile PO>Nir>Final Ap Invoice [Factura furnizor]

Dacă vei întreba un implementator de ERP anglo-saxon despre variaţii vei a afla că el
s-a născut cu variaţiile astea în casă, bunica lui i-a povestit despre variaţii că au fost lăsate
de primii conchistadori Spanioli/Portughezi când au pășit pe tărâm american și că sunt un
tabu, nu poţi scăpa de ele și tu trebuie să le înțelegi “tainele” și trebuie să le duci mai
departe așa cum ni le-au lăsat strămoșii și să le transmiţi urmașilor urmașilor tăi.
3.6.3 Operarea nirului și a facturii [Factura furnizor] în România și în lume

Cum se procedează în realitate?
Acum 40 de ani atât în Romania comunista cât și în SUA capitalistă înregistrările operative
la nivel tranzacţional (recepţie NIR de exemplu) se făceau fizic în “magazia mare24” adică
în magazia de recepţii generale a fabricii unde se recepţiona orice (vezi si nota din
subsol): de la foi de tablă la profile diverse, șuruburi , condensatori, tranzistori, lavete,
lapte pentru vopsitori sau pixuri pentru financiar. Informație suplimentară aici: acesta era şi
24
Magazia Mare = Mărturia că magazia mare se regăsește și acum în marile firme din US ce au implementat un ERP o
găsim aici [Goods or services ordered through a purchase order are received by central receiving or the appropriate
operating location department.] [ https://www.rfsuny.org/media/rfsuny/procedures/ap_2-3-4-way-matching_pro.htm ]
Pagina 32/142
momentul în care se făcea una din verificările obligatorii sau prin sondaj de către CFI25
ca să vadă dacă întreprinderea nu este prejudiciată cu articole nedorite (necomandate),
furnizori neagreaţi, preţuri sau valori speculative în afara bugetului sau alte valori
neaprobate. În firmele serioase indiferent de forma de proprietate sau perioada istorică
CFI-ul funcționa ca un fel de mic birou de contra-informații CI pentru protecția patrimoniului
intern, dar asta e o altă discuție care nu interesează pe nimeni…
Recepţia + inspecţia se făceau cantitativ-calitativă și se inspecta de către comisia de
recepţie care uneori avea și un reprezentant din secţie pentru inspectarea articolelor
delicate cum ar fi un microcontroler. De aia i se mai spune Nir [Nota de recepţie și
constatare de diferențe] și are 4 semnături diferite în subsol și nu doar una (cea a
gestionarului magazioner). Pasul în engleză ar fi [receipt + inspections steps].
Transferul către: magazia specializată, magazia de secţie, direct în producţie sau direct
în cosum (pixurile și colile A4 de la financiar). Acest pas ar avea echivalentul în engleză în
Put-away step or Transfer step.
Ambii pași se făceau acum 40 de ani și se fac și acum identic din punct de vedere
operaţional. Exemplele de mai jos folosesc conturile 401 și 301 care au intrat în vigoare în
1992-1993 odată cu “întoarcerea” domnului Feleagă de la Paris26 și nu conturile
menționate în ordinul 596/1970.
Din punct de vedere contabil acum 40 de ani o fată de la contabilitate lua apoi la mână
fiecare nir, notă de transfer, bon de consum și nota cu creionul pe ele astfel:
a.) Nirul real în magazie + Put away se petrecea pe 13.03.2020 dar ea încadra contabil
undeva pe 25.03.2020 sau chiar pe 05.04.2020 când documentele ajungeau după
multe zile “sus la contabilitate”.
b.) Pentru NIR pe headerul documentului (antet dreapta) se scria 401
- Pentru fiecare linie din nir se scria cu creionul în funcție de încadrarea articolului
(destinație):
Linia 1 - surub = 301
Linia 2 - piulite = 301
Linia 3 - lavete = 3021
Linia 4 - suba portari = 303
Linia 5 -lapte sudori/vopsitori = 3028
25
CFI = Compartimentul de control financiar intern. Acum CFI se ascunde la Audit Intern.
26
Niculae Feleagă: Profesor ASE și decan în perioada 1996-2000. Este cel care între 1990-1994 a armonizat noul
sistem contabil românesc cu cel francez. Asemănător cum colectivul profesorului Antonie Iorgovan a armonizat noua
Constituție românească în 1991 cu Constituția franceză.
Pagina 33/142
Linia6 -rotor piese schimb strung = 3024

s.a.m.d….
c.) Factura de la furnizor aferentă nirului sosea și atunci ca și acum imediat (simultan cu
Nirul) sau după câteva zile adică pe 25.03.2020 ea avea și factura.
Ce mai făcea fata de la contabilitate în plus:
- Verifica dacă preţul de pe factură este unul corect, înmulțea cu calculatorul manual
cantitate x preț și determina totalurile, TVA-ul de azi și ICM-ul27 de ieri
Observaţie importanta [accrual clearing account vs. 408]:

Niciodata pe headerul documentului nu se scria 408 (Furnizori facturi nesosite).
408 se scria numai în cazul în care documentul de recepţie era chiar Avizul de la
furnizor.
408 se închidea apoi cu 401 în momentul facturii.
În ERP-ul anglo-saxon contul de furnizor 408 sau 401 este înlocuit întotdeauna de
un cont special numit [Accrual Clearing Account] cu o funcţionalitate f. complicată
care se închide apoi prin 401 dacă “nimerește”. În 99% din cazuri însă nu nimerește
și se derulează un proces foarte complicat de închidere [Accrual clearing
process] ce se rulează la sfârșitul fiecărei luni (în mod normal) sau (în realitate)
atunci când contabilul își mai aduce aminte sau când observă inadvertențe
(inconsistenţe) între conturile de clasele 4, 3 și 6:
a.) cum a fost PO-ul iniţial și cum s-a finalizat Factura furnizor [Ap Invoice]
(408/401/4426) și cum s-a format obligaţia de plată la furnizor.
b.) Cum s-au înregistrat valorile pe conturile mele de stoc (301…3028,303…)
c.) sau cum s-au dus aiurea prin variaţii (308/378) sau aiurea direct pe cheltuială
(60x) în loc să se ducă pe stoc?
Pentru a evita procesul complicat de [accrual clearing] unele Erp-uri au adoptat

variantele:
- înregistrarea directă a nirului în 401/408 pe partea de furnizor
- transmiterea variaţiilor instant în contul de cheltuială sau în cel de stoc
- oferirea unor rapoarte ce verifică lunar: ce recepţie (de la care PO) nu are factura
Ap invoice aplicată. Adică ce recepţii sunt rămase în 408 și factura de furnizor (401)
27
ICM = impozitul pe circulația mărfurilor valabil până în 1992 când este înlocuit cu TVA.
Pagina 34/142
nu a sosit încă. Veti găsi aici rapoarte sau functii de genul [GRNI = goods received
not invoiced]
- rapoartele de tip [Reconciliation Reports] cu variantele lor per module Stoc/IC,
Furnizori/AP, clienţi/AR existente în Erp în varianta standard nu oferă
întotdeauna diferenţele între modul şi conta deoarece noi ne gândim
[franţunzește] iar ele funcţionează [americanește]….şi aduc diferenţele găsite
conform funcţionalităţii pentru care au fost proiectate. Pe mine mă interesează
să văd diferența între modul și conta iar el îți prezintă diferențele de cantitate
PO>receipt>Invoice, de preț (cost PO vs Invoice Price), de metodă folosită,
diferențe de curs s.a.m.d…
3.6.4 PPV vs Three Way Matching PO vs Standard Cost vs Ap Invoice (factura

furnizor)
Doar pentru această speță (PPV>PO>AP matching>Standard Cost) o nouă carte separată
(nu doar un capitol separat) ar trebui scrisă în limba română de unul din marii profesori
universitari (colonei sau/și doctori) în calitatea lor de unici specialiști în astfel de domenii
(deci nu doar de un simplu enoriaș). Sau măcar o traducere (acceptăm și traduceri).
Ne referim aici la această legatură între noțiunile de mai sus care este tratată identic în
Oracle, SAP, BAAN/Limfor sau QAD/MFG/PRO încă de acum 30 de ani suferind mici
ajustări în noile variante Erp ale acestor aplicații.
Vezi și noțiunea de PPV(Purchasing Price Variance) care completează Two+Three+ Four
Way Matching PO și Standard Cost components (material, labour, burden, overhead
etc…)
Toate aceste noțiuni sunt noțiuni fundamentale ale lanțului SCM bazat pe US Gaap și de
aceea se regăsesc aproape identic în fluxul operațional al ERP-urilor de mai sus.
Reiau baza/fundamentul lanțului SCM (recepție, transfer, shipping/vânzare, consum,
raportare producție, retur [RMA] ) pt. a înțelege puțin noțiunile:
1. Cantitatea/QTY are prioritate și nu valoarea reala. SCM din ERP asigură
mișcarea cantităților în timp real (QTY) Nu și a valorilor reale (preț de stoc
complet). Veți observa că modulele de Inventory din ERP mișcă doar cantități!
2. Mișcarea în timp real în oricare verigă din lanț: (receipt, transfer order, shipping,
Retur/RMA etc…) se face doar la cantități însoțite în permanență de costul PO
(preț din comandă). La recepție Maricica magazionera NU vede prețuri!.
3. Valorile reale la nivel de stoc (preț de stoc) și în conta (308,301x etc…) vin
târziu după multe zile prin rularea unor proceduri de actualizare (recalcul) valori de
tip variație prin ventilarea/distribuția lor pe cantitățile mișcate în lanț. Dacă
procedurile nu sunt rulate la timp (sau deloc) contabilitatea și prețul de stoc sunt
eronate pt. conturile de clasa 3 sau fișa de magazie sau balanța de stoc.
4. Variațiile de cele mai multe ori se duc preponderent pe conturi de cheltuială/60x
(interzis în RO/FR) și de aceea este necesar ca un nou recalcul de stoc să fie
făcut prin localizările românești ale acestor Erp pt. a respecta legislația contabilă.
Aceste proceduri de recalcul NU sunt necesare în US GAPP deoarece variațiile
acolo se duc pe cheltuială nativ (fiind permis acest lucru de GAAP).
Vezi si PPV in SAP: https://erpcorp.com/sap-controlling-blog/6-post-purchase-price-variance-to-purchasing-1
PPV în Oracle: https://support.oracle.com/knowledge/Oracle%20E-Business%20Suite/470956_1.html
https://docs.oracle.com/en/applications/jd-edwards/supply-chain-manufacturing/9.2/eoapm/purchase-price-variance.html#u10027532
Pagina 35/142
3.7. T ranzacţiile în ti mp real – fals ă abordare. Efecte în

contabilitate.
Tratarea modului în care ERP-ul operează sau nu tranzacţiile în timp real se

completează cu capitolul următor de mai jos [ERP generator de documente sau
imitator de documente ?].
Abordarea este f. simplă:
a.) Dacă acțiunea tehnico-economică este pornită din Erp (din
interfață/ecrane/funcții) sau este înregistrata instant (în aceiași secundă în ERp) în
urma unei operații externe de tip movement din Scaner chiar dacă provine dintr-o
aplicaţie externa apendice, atunci vorbim de tranzacţii în timp real şi ERP-ul
este şi generator de documente;
Exemple cu tranzacţii în timp real [a]:
a1) - modulul de facturare din ERP unde operatorul operează linie cu linie factura
provenită dintr-o comandă client sau este introdusă manual acum în fața clientului
(care așteaptă să facă şi plata eventual). În acest caz la finalizarea facturii se
produc mai multe evenimente în timp real care afectează şi celelalte module din Erp
(conta, stoc, clienţi, jurnale, plăți/încasări, registru de casă/bancă).
a2) – deși avem o aplicaţie externă bazată pe scanere şi terminale cu traductoare
(senzori inteligenți) de gestionare a mişcărilor de stoc (stock movement) de la o
operație la alta (10>20>30) sau pentru replenishment28 (înlocuire imediată)
automat în cazul lipsei unui component în magazia A, consum automat conform
rețetă s.a.m.d aceasta transmite nativ prin ODBC sau dacă are acces la alte API-uri
din ERP tranzacţia efectuată în exteriorul ERP imediat (în aceiasi secundă) către
baza de date respectiv tabelele de mişcari de stocuri, stoc on-hand şi tranzacţii
contabile;
Exemple cu tranzacţii care NU sunt în timp real [b]:

b.) Dacă acțiunea tehnico-economică generatoare de tranzacţii este pornită din Erp
sau din afara ERP prin intermediul unei aplicaţii de scanere, facturare, operații
Mijloace fixe, Recepţii PO s.a.md dar în realitate tranzacţiile şi transferul acestor
tranzacţii din aplicaţia externa către tabelele ERP se efectuează prin rularea unor
programe/funcții de import/export la 1 ora sau 1 zi sau 1 saptămâna de la tranzacţia
28
Replenishment = mecanism de înlocuire imediată a unei cantități lipsă în procese de producţie tehnologice. Atunci
când cantiatea necesară lipsește din magazia A este înlocuită instant (în aceiași secundă) cu cantitatea necesară
provenita din magazia de rezervă B pe baza unor reguli.
Pagina 36/142
reală din acea aplicaţie externă atunci ERP-ul nu mai este considerat a fi o
aplicaţie [în timp real] şi mai mult este şi [imitator de documente]. Ce
înseamnă asta ? că tranzacţia şi documentul real s-au ptrecut acum 1 ora (sau
acum o săptamână) în aplicaţia de facturare externă sau scanere/producţie externă
iar eu (omul de la IT) nu fac altceva decât sa imit în tabelele ERP documentul
(factura, comanda, transferul, consumul) şi tranzacţia petrecuta în altă aplicaţie prin
procedura de import/export.
Am întâlnit următoarele afirmaţii false promovate atât de producătorii români de

aplicaţii informatice cât și de marii implementatori sau producatori ai marilor aplicaţii
ERP anglo-saxone. Aceste afirmaţii sună cam asa:
1. Aplicaţia aceasta (ERP) pe care noi o implementăm la dvs. este o aplicaţie în
timp real.
2. Pentru a obţine date consistente sunteţi obligaţi să bagaţi documentele exact în
ordinea efectuarii lor în operativ (NIR, bon consum, factura de vânzare, note
de transfer).
3. Nu aveţi voie să modificati sau să ștergeți notele contabile generate din
modulele programului (ce apare în/din asa-zisa contabilitate de modul AP, AR,
IC, WO, SO)
În realitate în toate țările și cam cu toate aplicaţiile, cele de mai sus sunt de fapt un fals
tehnic ce ascund impotenţa acelui ERP şi denotă neprofesionalism și lipsă de cultură
economică sau este folosit doar în scop de reclamă comercială de către omul de
sales/vânzări ca să îl vrăjească pe cel ce va semna contactul. Cazuri reale:
1. Documentele importante aferente consumului sau vânzarii se înregistrează în Erp
înaintea documentului de recepţie sau de transfer din magazia A în B ca apoi să fac
vânzare din B. Marja de variaţie (probabilitatea de a fi așa) este de la 10% la 90%
în funcţie de procesle de business specifice firmei.
2. Tranzacţiile în timp real sunt doar cele generate de procesele automate din liniile de
producţie automatizate robotizate unde materia primă se consumă la clasicele
operatii 10,20,30 sau semifabricatul se mută de la un post de lucru la altul de la 10
la 20 sau la 30. Acestea se fac de obicei cu ajutorul unor aplicaţii terțe apendice la
Erp pe baza de [Scanere] cu coduri de bare sau terminale de raportare rapidă în
secţie. Asta însemnă că undeva între operaţia 20 și 30 este montat un terminal (ca
în MSDOS pe vremuri) cu 3-4 meniuri/opțiuni simple/scurte/simplificate iar un
muncitor operator mai deștept apasă pe meniul 2 și tastează 57 + enter și
Pagina 37/142
terminalul știe că [cutia de viteze de Mercedes SL200] a fost mutată de la operaţia

20 la 30 și a “înghiţit” (adică s-au consumat pentru ea) 3 șuruburi, 6 piuliţe cu șaibă
Grower și 100 ml de diluant. Cam asta reprezintă “timpul real pentru ERP”, restul
totul e manual adică Maria+Vasile sau Mary+John trebuie să opereze manual în
meniul XYZ din Erp.
Datorită realităţii de mai sus ERP-urile au [lăsat-o mai moale] cu așa-zisul [timp
real/real time] și au inventat artificii precum [over issue locations] sau [allow
negative quantities process] adică magazii unde avem dreptul să facem
tranzacţii de ieșire și apoi când cineva are timp face și recepţii pentru ele sau
transfer. Este un fel de: întâi merg la școală în clasa a II-a și apoi mă nasc la
maternitatea Giulești sau la Polizu (în unele ERP-uri se poate asta).
Operarea doar cantitativă la nivel de NIR/GRN și aplicarea mult mai târziu a preţului
real de stoc. Aici se consideră că magazionerul:
- nu trebuie să cunoască preţul de PO sau real de recepţie (preţul de pe factură);
- magazionerul trebuie să se concentreze la cantitatea și calitatea articolelor
recepţionate și poziţionarea/stivuirea lor în rafturile dedicate;
- Magazionerul nu are competenţe de încadrare valorică a mărfii ci negociatorul
(buyerul) este cel care a stabilit preţul.
În realitate în Romania 99% din recepţii (NIR) se fac astfel:
- cantitativ și valoric simultan bazat pe prețul de factură și niciodată pe cel de PO;
- preţul de PO nu este recunoscut de legislaţie și nu există noţiunea de [variaţie de
preț în conta vs stoc vs PO];
- recepţia în ERP este operată complet în compartimentele de financiar-
contabilitate și aproape niciodată în magazie;
- recepţia este operată de persoane cu multe conostinţe economice care știu să
citeasca documente primare complexe și diverse;
- în 99% din cazuri la momentul real al recepţiei există toate facturile implicate (factura
furnizor+factura transportator cel puţin) sau o copie PDF/ email a acestora chiar dacă
ele nu au ajuns înca fizic.
Aplicaţiile ERP de origine continentală (franceză şi românească) imită în primul rând

functii şi fluxuri de introducere a documentelor de bază (NIR, Factura vânzare, Bon de
consum) în legatură directă cu funcţii de jurnalizare contabilă (fişa cont, carte mare,
Pagina 38/142
balanţa cu 4-6 egalitati), Registrul de casă/bancă, Registrul Jurnal General debit=credit şi

Balanţa de Stoc (ultimile doua inexistente în core29 ERP anglo-saxon, adică nu sunt în
pachetul de bază la livrarea aplicaţiei).
Observatie: jurnalizarea contabilă apare simultan în tandem cu tranzacţiile contabile din
module, fiecărei tranzacţii din modul îi corespunde o notă contabilă atomică Debit=Credit.
Aici jurnalizarea este facută de obicei într-un singur pas simultan cu operarea în modul
(uneori prin contare documente). Notele contabile sunt 1:1 cu gruparea logică a
documentului operativ din modul (vom explica aceste corespondențe şi detalii mai jos).
Pentru adaptarea modelelor anglo-saxone la specificul francofon toate marile ERP-uri au
realizat asa-zisele localizări de ţara (vezi exemplul public în capitolul: Localizare făcută de
ERP Oracle JD Edwards pentru Franța). Sau localizarea facută de firma QAD pentru
România – vezi în continuare.
3.8. Recunoașterea ve niturilor ş i a c helt uielilor în ERP [Cas h vs.

Acc rual Accounting ] – diferența funda mentală înt re G AAp vs
model francez. Cont ul 121.
Începem cu asta: […The main difference between accrual and cash basis accounting
lies in the timing of when revenue and expenses are recognized....] adica principala
diferență între metoda contabilă [accrual] şi metoda contabilă [cash basis] constă în
momentul în care veniturile şi cheltuielile sunt recunoscute şi implicit profitul şi apoi plata
TVA (exigibilitatea TVA). La metoda contabilă [cash] venitul şi cheltuiala sunt recunoscute
când facem încasarea facturii de la client (customer invoice) iar cheltuiala când facem
plata efectivă a facturii de furnizor. De aici au fost inventate şi noțiunile de AR şi AP în
ERP. La buticul din colt sau la Metro (cash an cary) încasarea banilor se face imediat şi
simultan cu bonul fiscal sau factura fiscală şi simultan cu livrarea mărfurilor către client,
aici s-ar justifica utilizarea metodei cash. În multe alte firme (alte situații) plata/încasarea
se face la termen şi nu imediat.
Daca în ERP-ul dvs. nu aveți instrument de închidere (o funcție sau un modul) pentru
închiderea contului 121 însemnă ca Erp-ul e clar anglo-saxon (tipic GAAp) şi el a fost
construit orientat către metoda [Cash accounting].
De exemplu în Erp MFG/PRO (actualmente QAD SE/EE) colectivul de la Crescendo
International condus de Pompei Popescu a facut (a construit efectiv) un modul/funcție de
29
Core ERP = se referă la inima Erp adică componentele de bază ce se livrează standard cu aplicaţia de bază.
Majoritatea ERP-urilor livrează contra cost şi alte sub-module opționale pe lânga [core ERP].
Pagina 39/142
închidere pentru contul 121 încă din 1998 la prima mare implementare de la Dacia.
Funcţia de închidere 121 a fost inclusă apoi în localizarea de Romania a aplicaţiei
MFG/PRO şi a fost instalată nativ pentru toti clienţii Crescendo din 1998 şi funcţioneaza şi
azi (2021) pentru toate versiunile de MFG/PRO respectiv ver 9., EB2 şi apoi QAD SE
2014.
Ca să nu îl laud aici doar pe Pompei Popescu (Crescendo) voi oferi un alt exemplu
similar referitor la necesitatea închiderii lui 121 din alte aplicații ERP. În anul 2003 am
participat la o sedință de proiect la unul din distribuitorii locali de Axapta30 si Navision în
care se punea problema urgentării realizării localizării de România care să cuprindă
obligatoriu (printre altele): închiderea lui 121, Jurnalul de vânzări si cel de Cumpărări și
Registrul Jurnal General în format Debit=Credit. De ce era urgent ? fiindcă tocmai
făcuseră o implementare la o firmă mare cu pretenții pentru acele timpuri și dna contabilă
șefă (clientul de ERP) le-a impus acest lucru.
În Romania metoda [Accrual Accounting] este impusă tacit prin lege şi nu este opțională.
NOTA: Pentru cei care aveți ERP-uri care au instrumente separate (funcții separate) de
acrrual clearing (accrual at period end or accrual at receipt) a nu se confunda metoda
contabilă [Accrual Accounting] cu instrumentul numit accrual clearing method din Erp-ul
dvs.
Pe scurt în România + Franța folosim metoda [accrual accounting] pe când în GAAP se
folosește preponderent [Cash accounting] method sau există ambele și depinde de dvs.
cum veți seta metoda folosită contextual pentru un anumit client. Factura emisă la client
generează venit (7xx) atunci când o emitem şi nu peste 90 de zile… când ne plătesc
clienţii. Factura de furnizor generează cheltuială când o recepţionăm sau se duce pe stoc
(+CTA) când stocurile recepţionate conțin şi facturi de servicii (transport, taxe vamale).
Asta mai însemnă că lunar noi închidem veniturile (7xx) şi cheltuielile lunare (6xx) prin
contul de profit şi pierdere 121 şi mai facem ceva – închidem lunar taxele (TVA în principal
4426/4427) pentru a anunța profitul şi TVA de plată la stat (D100, D300, D394 etc..). Noi
suntem practic un agent fiscal al statului. Impozitul pe profit şi Tva de plată fiind unele
din principalele surse de finanțare la bugetul de stat. Există şi alte implicații, avantaje şi
dezavantaje a celor două metode dar acestea de sus sunt cele mai importante.
30
Axapta si Navision = doua produse ERP diferite ale lui Microsoft care în anii 2002-2004 intraseră cu
versiunea pentru Ms-DOS și la noi în țară prin distribuitorii locali ai Microsoft care au și făcut primele
implementări.
Pagina 40/142
3.9. ERP- ul, pe narul și laptopul sau cu ce dispozitiv accesăm o

aplicație ERP?
Vă invit să citiți cu atenție acest capitol și să nu dați verdictul din prima spunând că
prin acest capitol eu fac [teoria bățului de chibrit] și că tastatura clasică [101-105] și
monitorul sunt caduce, învechite și demodate [deprecated] în 2021.
3.9.1 Ciobanul Ghiță și Nelimitat în rețea & Nelimitat Tik Tok, Whatsapp și
Facebook
În ultimii ani tendința pe care o au majoritatea oamenilor dar mai ales tinerii sub 35 de
ani este [comoditatea] respectiv tendința de a folosi Telefonul Mobil tip Smart Phone numit
de mine și penar31 pentru a se orienta în viață și chiar de a o lua la stânga, la dreapta
sau înainte la prima intersecție sau de a trece din Piața Victoriei 1 în Piața Victoriei 2.
Aproape toți marii furnizori de telefonie mobilă oferă azi la oricare din abonamente sau
la oricie variantă de cartelă preplatită urmatoarele beneficii: [Nelimitat în retea + Nelimitat
Tik Tok, Whatsapp și Facebook]. Iar Waze și Google maps sunt busola noastră de zi cu zi
atât la volan în mașină cât și pe jos [walk waze]. Ciobanul Ghiță ne îndeamnă prin
reclamele făcute la diverși operatori de telefonie mobilă ca netul e nelimitat, netul e wireles
(fără fir) și să nu mai dăm găuri prin pereti s.a.m.d…Asta înseamnă că oamenii sunt tentați
a sta ore întregi zilnic pe aceste aplicații sau similare și a accesa orice.
În acest context oamenii nu mai doresc practic să folosească un PC normal cu
tastatură clasică cu 105 taste și cu monitor de 19 – 24 inch ci doresc ca și aplicația Erp pe
care o accesează ca sarcină de servici să o acceseze de pe penar sau laptop….
3.9.2 Ce legătură are ERP-ul cu penarul și laptopul?

Păi legătura directă este că dacă utilizatorii unui ERP sunt tentați sa acceseze aplicațiile
Erp de pe penar sau de pe laptop, atunci:
Dvs. cititorii veți spune că:
- păi ce e rău în asta să intri pe aplicația Erp de pe penar și mai ales de pe laptop ?
- ce mai suntem în 1990 când aceste dispozitive nu existau ?
- doar suntem în secolul XXI. Ești un învechit și un retrograd dacă ne ceri nouă să nu
folosim tastaura + ecranul laptopului sau să nu intrăm de pe mobil că doar avem
ecrane de peste 6 inch acum! Mai sunt și Siri și Cortana, cu ele ce facem?
În realitate lucrurile nu stau asa.
31
Penar –ne referim aici la un dispozitiv mobil tip Smart Phone, de obicei un telefon inteligent pe ecranul căruia
dăm cu degetul și navigăm prin diverse aplicații care ne-au furat viața în mod real fiindcă nu concepem să nu le accesăm
ore bune zilnic.
Pagina 41/142
3.9.3 Despre utilizarea Tastaturii clasice [IBM 105 keys]

Odată cu Tastatura clasică de 105 taste pe care o regăsim începând cu modelul consacrat
de IBM numit [IBM Model M manufactured în 1986] au fost inventate special următoarele:
1. Separarea activității de editare de text (vechea mașină de scris IBM) brută (zona
tastelor QWERTY) de zona de operare financiar-contabilă [tastatură numerică
specială în dreapta];
2. Facilitarea accesului separat la o tastatură numerică specială în dreapta care are
propriul enter special destinată operatorilor de date de la oficiile de calcul32 și a
operatorilor financiar-contabili;
3. Apariția a două subgrupuri de taste independente de navigare între zona text
(QWERTY/ASDF) și zona numerică specială:
- Subgrupul de navigare cu săgeți poziționat jos și
- Subgrupul de navigare pagină poziționat sus (Home/End/PgDn/PgUp)
https://en.wikipedia.org/wiki/IBM_PC_keyboard
Toate acestea au fost inventate chiar înainte de 1986 și se mențin la toate

tastaturile clasice și azi pentru a înlesni introducerea valorilor numerice (cantități,
poziții, prețuri, sume debit/credit ) de pe documentele primare din zona financiar-contabilă
în terminalele de tip PC precum: bonuri de consum, fișe limită, recepții/niruri,
pontaje/salarii și mai ales pentru facturiștii de depozit care erau obligați să introducă zeci
de linii preponderent cu valori numerice pe documente în intervale scurte de timp și să
navigheze apoi între liniile și headerul (antetul) facturii/avizului/comenzii pentru a verifica
dacă toate datele sunt corecte (adrese, tva, totaluri, articole, cantităti, delegați, camion
s.a.m.d…)
32
Oficiu de calcul = [..iar ne zice ăsta despre Oficiul de Calcul...]. În aceste Oficii de Calcul a început prelucrarea
automatizată a datelor financaiar-contabile si primele ERP-uri acolo s-au născut.
Pagina 42/142
Cineva spunea în anii ‘90 că operatorul (oricare ar fi el) nu are timp să ridice mâna
dreaptă de pe grupul de taste numerice din dreapta tastaturii clasice și la nevoie să poată
accesa imediat tastele imediat următoare de navigare (Home/End, PgUp/PgDown și
săgețile ) pe toată durata sesiunii de lucru de pe un document.
Tastatura specifică laptopului (notebook) este o tastatură cu taste înghesuite
proiectată în urma unui compromis dictat de lipsa de spațiu în care grupurile de taste
importante respectiv tastatura editor de text (QWERTY) + tastatura numerică + tastele de
navigare se suprapun pentru un numar mare de taste rezultând taste fizice cu 3-4
funcții simultan, fiind obligați să apăsăm alte combinații de taste în prealabil cum ar fi Fn
(stânga jos cu albastu de obicei) și alte combinații de taste, lucru care generează confuzie,
întârzieri în prelucrarea datelor și dificultate în operarea cu aplicațiile economico-
financiare.
O tastatură clasică pe USB este ieftină (10USD) și vă scutește de multe neplăceri.
3.9.4 Despre utilitatea prezenței monitorului pentru utilizatorul de ERP
Dacă producatorul de ERP vă recomandă utilizarea penarului și a laptopului pentru a

accesa meniurile aplicației ERP și a lansa/executa comenzi din ecranele ERP și a
consulta rapoarte din meniurile Erp atunci o puteți face fiindcă responsabilitatea calității
introducerii datelor și optimizarea ecranelor pentru astfel de dispozitive a fost facută (și
testată) de producător. Dacă NU au recomandat acest lucru, atunci dvs. nu sunteți decât
un cobai prin care producătorul își testează aplicația pe astfel de dispozitive.
Dacă producătorul de ERP nu v-a comunicat nimic despre utilizarea laptopului și/sau a
telefonului mobil și care ar fi impactul accesării aplicației Erp prin intermediul acestor
dispozitive atunci există urmatoarele riscuri:
1. Datorită dimensiunii fizice reduse a acestor dispozitive respectiv sub 14 inch la
laptop și sub 6 inch la telefoanele mobile (penare) puteți avea surpriza să nu mai
vedeți câmpuri importante din meniurile aplicației în condițiile în care pe un monitor
de 19-24 inch aceleași câmpuri să existe în ecran și să aibă și o dimensiune
corectă pentru a se opera în ele. De exemplu: [în câmpurile de cantiate, preț
inclusiv cu delimitator zecimal și 2-3-4 zecimale în funcție de context].
2. Mesaje f. importante transmise de aplicație către dvs. să nu fie vizibile (sau
incomplete) în cazul unui penar sau ecran de laptop. Același mesaj în cazul folosirii
monitorului (19-24) să apară la locul indicat de producător și în format complet.
Pagina 43/142
3.9.5 Recomandare: utilizați tastatura USB externă și monitorul extern.

Recomandarea noastră este ca o aplicație ERP sau financiar contabilă oricare ar fi
ea să fie accesată numai de pe un PC echipat cu tastatura clasică [IBM 105 sau
similar] și numai cu un monitor de minimum 19 inch [ideal ar fi 24 inch].
În cazul folosirii unui laptop cu ecran incorporat sub 17 inch (15-14 sau 13 inch) să
atașați urgent un monitor extern de 19-24 inch și o tastatură clasică (IBM 105). În caz
contrar există riscul de generare a unor confuzii mari în vizualizarea
ecranelor/câmpurilor și a mesajelor, erori în operare și a pierderilor mari de timp în
introducerea datelor. Rezultatul final poate fi introducerea de date eronate.
La fel ca în cazul tastaturii, este bine să aveți atașat la laptop un monitor mai mare sau
egal cu 19 inch pentru o vizibilitate completă a ecranelor aplicației precum și pentru
sănătatea ochilor dvs. Rezultatul final poate fi luarea unei decizii incorecte
4. Economie introvertită sau extrovertită. Implozie versus explozie.
Îmi permit să aloc un scurt capitol cu o tentă pamfletară legăturii dintre ce s-a dorit prin
construcţia unui ERP în țările anglo-saxone industrializate şi unde s-a ajuns azi prin
implementarea acestor ERP-uri în locuri nepotrivite.
În concepția mea sunt două tipuri mari de economii naţionale:

a.) tipul de economie națională extrovertită care implicit face explozie în exterior
caracteristică țărilor unde predomină producţia de serie mare şi de masă super-
robotizată. Aceste economii fac “explozie” peste ceilalți vecini. Hans la el în ţara lui
este “liniștit” şi se concentrează la cum să facă mai multe pâini pentru a le vinde
mai scump vecinilor (lui Vasile). Aici statul îl incurajază pe Hans să facă multe pâini,
îi acordă şi ceva subvenţii mascate şi nu îi pune nici o barieră comercială
încurajându-l pe Hans din toate părţile. Statul lui știe că dacă Hans face mai multe
pâini şi le vinde mai scump vecinilor, şi el statul va primi o cotă parte importantă și
constantă din afacerea lui Hans dar numai după ce Hans a adus banii în ţara lui.
Paznicii cetății33 lui Hans sunt liniștiți la rândul lor și pot ieși la pensie la 45 de ani cu
o pensie mare.
b.) economia națională introvertită care face întotdeauna implozie adică îi
explodează periodic organele interne: inima, creierul, plămanii respectiv ramurile
33
Paznicii cetății , (Platon- Republica, 360 î.Hr.) = [1] – sunt paznicii cetății lui Hans aici.
Pagina 44/142
economice importante: industria, agricultura, transporturile, turismul, serviciile toate

patronate de paznicii cetăţii34 (Platon- Republica, 360 î.Hr.) respectiv de către
serviciile publice ale statului (armata, vama, poliţia, serviciile secrete, aparat
guvernamental şi ministerial).
Economiile respective (introvertite) se bazează preponderent pe importuri iar
formarea preţului de stoc furnizor pe bază de DVI (declaraţia vamală de import)
sunt predominante. Aici statul îl descurajază continuu pe Vasile să facă pâine sau
orice altceva. Nu îi acordă nici o subvenţie şi îi pune toate bariele comerciale
cunoscute. Vezi și secţiunea pamflet de la sfârșit.
4.1. Ce legătură au Ha ns şi Vasile cu un ERP ade vărat a nglo-

saxon?
Răspuns:
Niciodată funcţiile şi modulele unui ERP adevărat anglo-saxon nu pot fi
implementate corect acolo unde:
- nu există o predictibilitate şi implicit o planificare pe termen mai lung, acolo
unde regulile de management clasice nu pot fi implementate, respectiv în
condiţii de risc şi incertitudine permanente;
- preponderent avem producţie pe unicate/serie mica /loturi fară repetabilitate;
- azi firma face ceva iar mâine vrea să faca altceva în speranţa că noua
comandă (primită aseară de la un “prieten”) total nouă d.p.d.v tehnologie şi
componente poate se va transforma în sfârșit în producţie de serie mare şi că
ne vom scoate banii în viitor.
- marea majoritate a materiilor prime, materiale , componente sunt din import -
asta însemnă costuri mari, probleme cu cursul de schimb la EUR şi USD şi alte
taxe, CTA35.
- nu există un compartiment tip PPUP (Pregătirea, Planificarea şi urmărirea
Producţiei);
În completare vin cu analiza facută de Geert Hofstede36 referitoare la dimensiunea
nr. 5: “Orientarea pe termen lung versus orientarea pe termen scurt” , vezi și tabelul cu
34
Paznicii cetatii , (Platon- Republica, 360 î.Hr.) = [1] clasa conducătoare (înţelepţii sau filosofii); [2] clasa apărătoare
(militarii sau paznicii); [3] clasa producătoare (agricultorii şi meşteşugarii). Sunt paznicii cetății lui Vasile aici.
35
CTA = cheltuieli de transport aprovizionare. Aceste cheltuieli se adaugă la prețul furnizorului și formează prețul de
stoc. Prețul este FIFO cu identificare specifică în România.
36
Geert Hofstede – Vezi: Hofstede dimensions and country scores, Long-Term Orientation (LTO), 5.-Long Term
versus Short Term Orientation, related to the choice of focus for people's efforts: the future or the present and past.
Pagina 45/142
punctajul acordat ţarilor unde veţi face comparația între China – valoare (87) și România –
(52). Dacă statul în calitate de cadru general nu are orientarea pe termen lung (obiective,
planuri, prognoze, strategii, taxe stabile) atunci nici micul SRL sau PFA nu își poate face
un plan.
Concluzionând:
- Un ERP este făcut în general pentru a fi folosit în economii relativ stabile în
codiţii de relativă certitudine a deciziei manageriale unde gradul de repetabilitate
al lansarii în fabricație a unor produse să fie foarte mare. Structura producţiei se
schimbă doar atunci când se schimbă modelul/versiunea de produs cu alta: linia
de fabricație pt. telefon Samsung J6 este pregatită pentru Samsung J6 Plus+.
- Costul standard (preţul de stoc) aplicat tuturor articolelor de stoc (neaplicabil în
Romania) se aplică la iniţializarea articolului în nomenclator şi se
(re)actualizează la 3-6 luni sau poate la 1 an.
- Economiile stabile nu prea au variaţii de stoc (348+378+308 la noi). Dacă
variaţiile există acestea se duc la ei direct pe cheltuială la momentul recepţiei
respective în rezultatul exerciţiului datorită preţurilor constante negociate de
obicei cu furnizorii la început de an odată cu realizarea bugetelor şi a lansării
comenzilor cadru anuale. Preţul stabilit în comenzile cadru anuale de
aprovizionare cam tot ăla este tot anul dar şi la momentul recepţiei (Nir) şi cam
tot alea sunt pe factura de furnizor. La noi nu există așa ceva. Chiar dacă
negociezi 5 lei pe comandă/contract, furnizorul îţi va factura 5,07 în cel mai bun
caz ca să nu zic 5,2 şi niciodată 4,95. La noi se adaugă CTA care ramâne pe
stoc valoric pâna la descărcarea stocului afectat de acel CTA, la ei CTA se duce
direct în rezultatul exerciţiului din luna recepţiei (un fel de 624/628/604 la noi).
- În majoritatea ERP-urilor anglo-saxone nu veti găsi noţiunea sau funcţii de
descărcare de gestiune (k la noi) în cazul folosirii preţului standard.
- Dacă nu aveţi un compartiment tip PPUP (Pregătirea, Planificarea şi Urmărirea
Producţiei) nu puteţi cere ERP-ului sau specialiștilor care vin să îl implementeze
la dvs. să se substituie compartimentului PPUP.
- ERP-ul nu este făcut să te asiste atunci când tu îţi schimbi săptămânal structuri
de produse, tehnologii, rețete. Nu mai discutăm şi de fluctuaţiile de personal atât
operativ cât şi de personalul de tip KEY-user care a asimilat cunostinţe
importnate despre ERP-ul respectiv şi mâine “te lasă baltă” fiindcă a plecat la
Oracle sau la Honeywell sau la Londra….(sau poate la sparanghel în
Germania).
Pagina 46/142
5. ERP – unealta de control rapidă a fabricilor mele de pe glob.

Controlul rapid de la distanță este una din funcțiile de bază ale unui ERP adevărat (mai
ales după 2014). Un ERP azi este și o unealtă facilă care permite controlul tehnic și
financiar-contabil al unor filiale aflate la mii de kilometri de sediul central ale unei
multinaţionale (Headquarter).
De obicei acel Headquarter se află în Europa sau SUA.
Caracteristici funcţionale ce permit “controlul de la distanță” al filialelor:

- baza de date este unica, în ea sunt definite toate filialele firmei mamă sub forma de
companii separate, entităti, locaţii fiecare cu ID-ul ei unic. Fiecare ERP are propriile
denumiri pentru codificarea filialelor;
- Toate nomenclatoarele importante sunt unice pe baza adica un id de client sau
id_furnizor este vazut unic sub același nume de către toate filialele. Diferenţiatorul este
de obicei ţara acelui terț și codul fiscal. Fiecare ţară are un sistem de codificare
fiscală corespondent CUI/CIF la noi (vezi codificăre VIES în UE de ex.), fiecare terţ
poate fi gestionat diferențiat pentru reprezentanțele fiscale cu personalitate juridică din
țări diferite, comportamentul acestuia putând fi văzut atât centralizat cât și contextual în
ţara unde operează (UE, NON-ue). În unele ERP-uri acest mecanism se numește GTM
(Global Tax Management);
- Nomenclatorul de articole este unic sau partajat diferenţiat pe locaţii dar are coduri de
consolidare la grup (mai nou este codul EAN) care identifică unic un BEC de 24 V pe
bază. Efect: codul unic (ID articol) se foloșeste simultan în PO, SO, WO, MRP;
- Meniurile aplicaţiei, helpul, căutătoarele (lupele!), rapoartele și multe altele sunt vizibile
contextual în limba utilizatorului. Utilizatorul Gionging din filiala din Shenzhen (zona
liberă în China) va avea pe ecranul său toate meniurile în chineză simplificată
(中文语言). Utilizatorul Poroșenko din filiala din Kiev/Ucraina va avea meniul în
ucraineană (украї́нська мо́ва), pe când meniul clasic standard va fi văzut în engleză
de către utilizatorii de la Londra s.a.m.d.
Din cele de mai sus rezultă că:
- se pot face comenzi de aprovizionare (PO/furnizori), de producţie (WO) sau de livrare
(SO/clienţi) pe id-uri de terţi sau de articole comune. Firma mamă poate ști imediat
câte sticle de Bere Efes 77 s-au produs în Izmir sau urmeaza să se producă în
urmatoarele 3 zile la noua fabrică din Hanoi sau din Chișinău.
Pagina 47/142
- Între filiale se pot transmite comenzi de transfer (lansare), aprovizionare etc prin
intermediul EDI (electronic data interchange) pe terţi sau articole de stoc comune atât
pentru aprovizionare cât și pentru livrare;
- Toate datele financiar contabile pot fi agregate “în sus” către firma mamă sau pot fi
consolidate în formulare automate din filiale;
- O reţetă de fabricaţie, structură de produs sau tehnologie pot fi definite centralizat la
Londra și pot fi apoi folosite contextual la toate fabricile subordonate de pe glob.
Am mai exagerat și eu puţin…Pentru ca cele de mai sus să funcţioneze “integrat” sunt
necesare operații pregătitoare, configurări, scolarizări și teste ce se întind uneori pe ani de
zile pentru o singură fililială. Între timp producătorul de ERP trece de la o versiune la alta
cum ar fi de la ERP-X-ver-2013 la ERP-Y-ver-2018 sau mai nou trece de la o versiune
locală (server local , americanii zic [on-premise]) la una cloud: ERP-Z-ver-2021_Cloud şi
nu îţi oferă sculă de migrare de la versiunea pe care tu tocmai ai terminat de implementat
pentru cele 5 filiale în 5 ani şi te sperie că dacă nu te muți în cloud vei pierde f. mult că el
nu mai susține versiunea 2013.
Pagina 48/142
6. Cum arată un ERP – structura de bază pe scurt.
Un ERP este o aplicaţie economico-informatică formată din două mari componente:

(1) Baza de date şi (2) Aplicaţia/programul de interfaţare între utilizatori şi acea bază de
date astfel:
(1.)Una sau mai multe baze de date formate din sute (uneori mii) de tabele în care
stocăm informaţii tehnice şi economice – zonă numita de obicei back-end (aproape
invizibilă utilizatorului).
Tabele bazei de date folosite sunt în principiu de două categorii:
a. Tip [Nomenclatoare] (clienţi, furnizori, plan de conturi, centre de cost, meniuri,
articole de stoc, mijloace fixe, centre de lucru, mașini, magazii etc…)
b. Tip [Tranzacţionale] (tranzacţii contabile, tranzacţii de stoc, încasări, plaţi,
comenzi de toate tipurile, recepţii, facturi client, facturi furnizori, amortizări, log-
uri/jurnale interne ale aplicaţiei, etc…)
Bazele de date cel mai des folosite azi în construcţia unor ERP-uri sunt:
SQLServer, Oracle, MySQL şi Progress. Ţinând cont că azi (2021) încă avem pe
glob mii de implementari funcţionale ale unor aplicaţii tehnice şi economice bazate
pe Visual FoxPro6-9 (şi culmea chiar pe FPD26) includem aici la baze de date şi
fișierele de tip [.DBF] asociate unei baze de date [.DBC].
Sistemele de operare ce găzduiesc de obicei aceste baze de date sunt: Linux,
UNIX şi Windows, fiecare cu variantele, restricţiile, limitările şi facilităţile lui în
conjuncţie cu una din bazele de date enumerate.
(2.)Un set de programe tip interfaţa care preiau comenzi şi date de la utilizator şi le
transmit către prelucrare sau/şi stocare acelei baze de date uriase de la pct.1 –
zona numită front-end (partea vizibilă utilizatorului).
Legatura dintre cele doua (1) + (2) se poate face direct/nativ sau indirect prin
intermediul unor programe intermediare aflate uneori pe alte servere/locatii decât baza
de date. În cazul conectarii între (1) + (2) pe platforme Linux găsim setul de subsisteme
de operare de gestiune aplicații si fișiere numite TomCat (majoritar) si WebLogic
(specific implementărilor Oracle), ambele bazate pe Java.
Pagina 49/142
6.1. Legatura Directă aplicație>se rver>bază de date

Legatura nativă/directă (de obicei pe același PC sau în aceiaşi reţea)
(a) Exemplu simplu: Aplicaţiile SAGA sau NaumConsalt bazate pe VisualFoxpro atât
în zona de aplicaţie(2) cât şi în zona bazei de date/tabele(1) sunt instalate la
Firma_XXXX SRL pe 10 PC-uri aflate în rețea (de obicei în aceiaşi cladire). Baza
de date cu toate tabelele aplicaţiei se află pe serverul A – de obicei un WINDOWS
Server 200x cu adresa 192.168.0.100 iar pe PC-urile independente din aceiaşi
reţea (Mariana1, ANA2, Gogu3, Fănel4) se rulează aplicaţia. PC-urile având
adresele diferite: 192.168.0.101 192.168.0.102 pâna la 192.168.0.111. Toate cele
10 PC-uri “atacă” simultan aceiaşi bază de date aflată la adresa 192.168.0.100 din
aceiaşi reţea.
(b) Un alt exemplu puţin mai complicat:
Aplicaţia MFG/PRO se află instalată complet (atât baza de date(1) cât şi
programele(2)) care rulează sub Progress 9.1E pe serverul Y (Redhat Linux 6.x) aflat
în Data-center în Viena la sediul grupului de firme (Company Headquarter). Utilizatorii
aplicaţiiei sunt împrăștiaţi în toată lumea la filialele companiei din Germania, China,
România, Mexic etc. Utilizatorul Marian2 din Timișoara sau Hans44 din Berlin intră în
aplicaţie cu ajutoarul unui emulator de terminal (Anita Terminal, Putty) care deși se
rulează pe PC-ul local al utilizatorului se conectează la serverul de LINUX din Viena
unde dechide o sesiune pe acel server lânga sutele de alte sesiuni deschise de ceilalţi
utilizatori (China, Mexic etc…)).
Descriere legături: Anita Terminal/Putty nu fac decât să emuleze o sesiune a serverului
(din Viena) la dvs. pe PC-ul local (în Timișoara). Sesiunea deschisă pe server
apelează programele compilate Progress(2) care la rândul lor sunt conectate la o
singură bază de date (1) aflate toate pe același server.
Practic PC-ul lui Marian2 se conectează către programele aplicaţiei(2) care la rândul
lor se conectează la baza de date(1) – toate pe același server.
Marele avantaj al acestei metode (uriașul avantaj) este că: între PC Marian2
(Timișoara) și serverul Y traficul este minimal (câțiva zeci de octeți pe secundă) și
totul este pe server (toate procesele se desfășoară pe serverul Y). Traficul este
îngreunat doar în minutul de transport (secundele de transport) al rapoartelor mari de
zeci de mega cum ar fi Balanța de Stoc sau Registrul J. General lunar care rulate pe
server vor trebui pasate înapoi prin rețea către Marian2…
Pagina 50/142
6.2. Legătura indi rectă sau cleștele c are apucă cleștele ca re

apucă jarul din foc
Nu e nici o gresală în titlu prin repetarea unor cuvinte, în realiatate cazul ăsta este cu
mult mai mai mulți clești intermediari până ajungem la jarul din foc(n+1) astfel:
[….cleștele(1) care apucă cleștele(2) care apucă cleștele(3) care apucă cleștele(4)
care apucă cleștele(n) care apucă jarul din foc(n+1).]
Explicație: dacă în Windows/MsDos la Prințul din Persia37 [Prince of Persia] apăsai pe
space să sară Prințul de la fereastra X la fereastra Y (sau sa scoată sabia din teacă)
atunci PC-ul dvs. primea comanda imediat prin systemul de operare local. Acum când
scrii 10.00 la cantitate/preț si dai enter sau apeși cu mausul pe Submit/Ok în
Comanda/factura fact1234, această informație trece prin tot lanțul sintetizat aici:
[EcranMarian2>Firefox>https>Linux> TomCat/WebLogic> server_baza_date> inapoi>
TomCat/WebLogic>Linux> https>Firefox> EcranMarian2]
Legătura indirectă - Exemplu: baza de date se afla pe un super-server în SUA într-o

locaţie de tip data-center, alături de alte 100 de baze de date ale altor multinaţionale
care au filiale în Anglia, Spania, Germania, Cehia, Romania, SUA şi China. Fiecare
filială are câte 50-100 de utilizatori care se conectează simultan la baza de date. Aici
Legatura între PC-ul John77 aflat la Londra şi baza de date se face prin intermediul
unei aplicaţii locale ce oferă partea de interfațare (ecranul de introdus factură de client
sau ecranul cu nir-ul), acesta se conectează la alte aplicaţii/programe aflate pe un
server intermediar (poate în altă locaţie de pe glob) iar acest server intermediar se
conectează la rândul lui la baza de date aflată în data-centerul din SUA.
Prin super-server spunem un server de generaţie actuală cu zeci de procesoare Intel
Intel E5-4650 (sau mai mari), peste 512 GB RAM, sute de GB spatiu de stocare în
baterii de discuri SSD la care se adaugă bandă de trafic nelimitată la peste 100 Mb/s.
Acest ultim exemplu vag şi incomplet (legatura indirectă) încearcă să ne apropie de

varianta 3 numită azi CLOUD, în care totul (baza de date, programe, rapoarte, unităţi
de back-up) se află ascunse într-o cutie neagra în data-centerul din SUA. În varianta
CLOUD utilizatorul deschide cu ajutorul unui WEB-browser (IE11, Firefox, Chrome
etc..) o sesiune obligatoriu prin HTTP/HTTPS pe serverul din data-center iar acesta îi
întoarce diverse ecrane de introducere date, consultare sau rapoarte. Toate procesele
37
Printul din Persia [Prince of Persia]= unul din cele mai populare jocuri de PC pe MsDos/Windows în perioada
1989-2000 [ https://ro.wikipedia.org/wiki/Prince_of_Persia ]
Pagina 51/142
se desfășoară pe server, numai comenzile către server se dau prin interfața WEB din
interiorul unui WEB-Browser de pe PC-ul John77 din Londra.
Simplist vorbind e ca şi cum ai naviga pe net şi în loc de www.yahoo.com
navighezi către www.serverul-de-erp.com/. La varianta asta intervine mereu și un VPN
securizat (Citrix, OpenVpn, SonicWALL, PulseSecure, AT&T, Cisco, FortiClient etc…).
Pagina 52/142
7. Aplicaţii economico-financiare versus aplicaţii ERP – diferențe
7.1. Cum rec unoaștem un ERP? Note manuale GL vs note din

module.
Răspuns:
1. Un ERP se recunoaște prin existența unei metode de conducere implementate.
2. Dacă găsești pe stradă un CD/DVD complet cu ERP-ul_XYZ_ver_2021 cu toate
sursele în clar, bazele de date asociate cu instrucțiuni complete de folosire, fișe
tehnice, help si documentație în limba română NU ai ce să faci cu el – nu poți face
tu instalarea sau implementarea lui ! E ca și cu OZN-urile găsite de americani după
1947 în urma [incidentului OZN de la Roswell] sau a celor din [Hangar 18] sau
[Intâlnire de Gradul 3/Close Encounters of the Third Kind ] la care se uită si azi ca
să le descrifreze tainele…
3. Un ERP nu poate fi implementat de dvs. singur prin download de pe net (sau de pe
CD sau mai nou de pe stickul sau HDD-ul extern de 128GB) prin configurare
module şi introducere date. ERP-ul nu poate fi instalat şi configurat decât de unul
din [părinții lui] (producător) sau un reprezentant al acestuia (de obicei firmă
implementatoare).
4. Proporția Notelor manuale GL/JL vs note provenite din module.
a.) Dacă notele contabile obținute lunar în registrul Jurnal general sunt provenite
din modulele de bază ale aplicaţiei cu markerul specific asociat (AR, AP, WO,
SO, IC, FA etc….) într-un procent de aprox. 80% să zicem atunci însemnă că sigur
mi-am cumpărat un ERP adevărat, am fost în stare să îl înțeleg şi să-l implementez
iar firma implementatoare şi-a făcut treaba.
b.) dacă în Registrul Jurnal General găsim 80% note GL/JL băgate manual prin
funcţia de Manual GL entries (note manuale Debit=Credit) sau din importuri de note
din alte aplicaţii care tot GL/JL sunt şi numai 20% provin din unul din modulele
aplicaţiei (Recepţii PO să zicem cu tranzacţii IC asociate dar fără factură AP) atunci
acela nu este un ERP iar dvs. aţi acceptat să folosiţi acel ERP ca un compromis pe
post de [găleată colectoare] că nu aveați altă soluție sau poate vă obligă cineva să
faceți asta.
5. Obținerea tuturor rapoartelor importante complete cu date neredundante la câteva
secunde/minute de la introducerea tranzacţiei.
6. Acoperirea tuturor funcțiunilor de bază ale unei firme clasice prin intermediul unor
module dedicate acestor funcțiuni pe traseul minimal:
Pagina 53/142
Planificare>recepţii>producţie>transferuri>livrare>încasări>plăţi -> s.a.m.d

Veți spune că: păi toate programele informatice cu care aţi lucrat dvs. fac acest lucru!
Atunci toate sunt ERP-uri ?
Răspunsul este: NU. Încercăm să găsim răspunsul complet în capitolele urmatoare.
Condiţiile minime pentru ca un program să fie Erp ar fi următoarele:
1. Să existe nativ în pachetul standard implementată cel puţin o metodă de conducere
(metoda pe comenzi în toate modulele de bază) şi în subsidiar a altor metode
(bugete, proiecte)
2. Să gestioneze articolele de stoc pe baza unei metode consacrate (FIFO, CMP,
Standard). În subsidiar să știe să gestioneze şi prestațiile şi serviciile cumpărate
de la furnizori şi a celor livrate clienţilor
3. Să gestioneze comenzile de la client cunoscute ca [SO = Sales Orders]
4. Să gestioneze comenzile către furnizor cunoscute ca [PO = Purchase orders]
5. Să gestioneze comenzile lansate în producţie cunoscute ca [WO = Work Orders]
6. Să înregistreze facturi furnizori [AP] şi facturi client [AR] pe baza comenzilor din
module cu sau fară comenzi din module [memo invoice, manual invoice]
7. Să permită plata şi încasarea integrată în registrele de casă/bancă a facturilor
primite de la furnizor şi a celor emise la client.
Simplist vorbind: Veți spune din nou că dvs. aveți deja acasă sau la locul de muncă
programul xyz (Homecont6.x de exemplu) şi că în el puteți marca tranzacţiile cu un prefix
de 2 litere care indică locul, procesul sau categoria economică ca în exemplul de mai jos:
Pagina 54/142
O explicaţie posibilă de ce acest program de contabilitate din exemplul anterior sau mai
bine zis această aplicaţie economico-financiară nu este un ERP ar fi că:
Nu este suficient să avem acele prefixuri prestabilite pentru categoriile economice folosite
în programul nostru de contabilitate pentru ca acest program să pretindă a fi un ERP.
[CU - cumpărări] poate fi asociat de exemplu cu [PO=Purchase order] dar:
a.) nu se respectă alte criterii de legătură cu alte module ce folosesc nomenclatoare
similare cum ar fi [PD=producţie], [VI= Vânzari];
b.) Cumpărarea [CU/PO] ca şi celelalte PD (WO) sau VI(SO) trebuie să aibă comenzi
generate standard anterior recepţiei;
c.) acel tip trebuie generat dintr-un sub-modul al aplicaţiei cum ar fi: recepţii sau intrări de
la furnizori;
d.) trebuie să existe un set de nomenclatoare asociate modulului (clienţi, furnizori, cote
taxe tva [GTM], articole stoc, drepturi pe funcție/modul care trebuie să mă
restricționeze când bag acel NIR din modul;
Se consideră că nu putem face nici una din mişcările importante cu un articol de stoc
[inventory] fară a avea o comandă generată în sistem [în aplicaţia ERP].
Comenzile principale obligatorii aferente mişcărilor de stoc ar fi:
1. Comanda de aprovizionare, [PO- Purchase Order] –Intrarea materialelor din exteriorul
organizației, de obicei de la un furnizor care furnizor poate fi:
a.) local (cumpărări din România) care la rândul lui poate fi cu TVA sau [N] neplatitor
de TVA ([N] “e furat” de la D394);
b.) din UE - achiziţii intrări comunitare cu taxare inversă;
c.) sau din afara UE – fostul import. Exemple SUA, Turcia, China. Aici intervin taxele
vamale;
2. Comanda de lucru, comanda de producţie [WO] cu cele două componente:

a.) Comanda de execuție a finitului sau semifabricatului care se deschide de obicei pe
același cod din nomenclatorul de articole dar cu id-uri diferite pentru fiecare lansare
de lot, sarja.
b.) Consumul efectiv (consumul propriu-zis), ne referim aici la toate materiile prime,
materialele care se consumă treptat pentru finitul X sau semifabricatul Y. În multe
aplicaţii Erp găsim noțiunea de (WIP work în process) cu tratamente diferite. În
Pagina 55/142
Romania WIP ar fi totalitatea materiilor prime consumate pe flux dar pentru care nu
s-a raportat finitul adică un fel de producţie neterminată care [legal] are metoda ei
de calcul şi identificare lunară şi pe care majoritatea o fac din pix fiind f. greu de
identificat şi măsurat. Echivalentul la noi ar fi contul 331. În conceptul GAAP WIP
are formule f. complicate bazate pe cantitatea comandată pentru părinte (finit) la
care intervin variații [variances]. Am adus aceste variații în discuție fiindcă ele din
nou nu sunt recunoscute de legislaţia contabilă românească şi trebueisc atent
setate în ERP să nu genereze note contabile aiurea. De obicei variațiile apar la
închiderea comenzii de lucru. În România producţia în curs de execuție se
calculeză manual din pix şi din excel rezultând contul 331.
Nu doresc nimănui să facă baba-oarba printre notele contabile generate de variațiile de
la comenzile de lucru WO şi nici de variațiile dinspre PO versus factura furnizor [Ap
invoice].
3. O comandă specială de menționat aici ar fi comanda de tip subcontractor pe care mai

toate ERP-urile bătrâne o au. Ea se referă la comanda pe care tu o dai unui
subcontractor ca el subcontractorul să îţi facă ceva la o piesă a ta, de obicei un
semifabricat. Să presupunem că facem un [ax cardanic]. Simplist vorbind tu poți
executa majoritatea operațiilor pe fluxul de producţie la tine în curte cu utilajele tale
(freze, raboteze, mașini găurit, strunguri diverse, abkant, tăietor cu laser, prese injecție
plastic, turnătorie, vopsitorie etc…) dar nu ai instalație de sablare sau cromare sau
zincare sau bronare adică nu ai şi acoperiri galvanice. Dar vecinul tău de peste drum
[Gigel Galvanizatorul SRL] are instalații de acoperiri galvanice. Atunci lansezi o
comandă specială din aplicaţia ta Erp care se numește comandă de colaborare către
furnizorul Gigel Galvanizatorul SRL. Este un fel de WO special dar care știe să facă un
PO către [Gigel Galvan SRL] şi știe să întoarcă în aplicaţie diferența valorică pe care
[Gigel Galvan SRL] a adăugat-o axului tău cardanic când a bronat [axul cardanic].
4. Comanda de transfer cu cele două variante:
1. Transfer intern inter magazii în aceiași unitate teritorială (în aceiași curte) [TRI] să
zicem, adică transfer intern.
2. Transfer extern când articolul pleacă din curte în altă curte – ne referim aici la
transferul între subunități (depozite, secții) aflate la distanță adică în alt oraș. Să o
botezăm [TRE].
Pagina 56/142
5. Comanda de vânzare [SO = Sales Order] – întodeauna este lansată de către client
către tine şi se finalizează cu ieșirea materialelor, produselor, serviciilor, mărfurilor în
exteriorul organizației către un client.
6. Comanda de retur de la client – o puteți găsi sub numele de return order sau RMA
[returned merchandise authorization (RMA)]. Este des folosită pentru returul
produselor neconforme, produse expirate, cu defecte sau pur şi simplu fiindcă așa vrea
clientul să returneze produsul respectiv că nu îi place ceva la el.
8. Clasificarea aplicaţiilor ERP
O clasificare ar putea fi aceasta:

- Aplicaţii economice financiar-contabile
- Aplicaţii economice modulare dedicate
- Aplicaţii ERP
8.1. Diferența î ntre un progra m ERP şi o aplicaţie informatică

financia r-contabilă sau una mod ulară.
Principala componentă care diferențiază un ERP de alte sisteme informatice/aplicaţii este

prezența funcțiilor ce aparțin de: Sistemul „Planificării cererilor de materiale – MRP” – vezi
ce spun prof. Bășanu/Pricop38 în Managementul aprovizionării şi desfacerii despre partea
economică a MRP şi gestiunea stocurilor. Dacă aceste elemente sau o parte importanta
din ele se regăsesc în interirorul aplicaţiei dvs. atunci înseamna ca aceasta e un ERP.
Totuși nu e suficient să regăsim câteva atribute ce țin de MRP asociate undeva
nomenclatorului de articole cum ar fi: timpul mediu de aprovizionare, stocul de siguranță
(în buc.şi Kg), stocul tampon, durata în zile a unui ciclu complet de aprovizionare, stocul
maxim, furnizor principal, categoria ABC, dacă articolul este cumpărat sau fabricat sau e
în tranzit pe la noi şi altele asemenea.
38
Bașanu și Pricop – este vorba de cei doi profesori de la ASE – vezi bibliografie.
Pagina 57/142
Pentru a fi catalogat drept ERP o aplicaţie trebuie să permită modulelor şi funcțiilor de

Planificare, recepţii, producţie, urmărire furnizori, comenzi/facturare clienţi, gestiune stocuri
să “vorbească între ele” adică să transmită ușor şi facil date între ele, ca să nu spunem “în
mod rezonabi” după principiile minimale ce țin de redundanță şi trasabilitate:
- O dată de tip nomenclator: planul de conturi, terți clienţi/furnizori (cui), salariații
(mărci,CNP), centre de cost conform structură organizatorică, activitațile, articolele
de stoc, mijloacele fixe să fie introduse şi gestionate printr-o singura funcție –restul
tuturor modulelor beneficiind de utilizarea lor;
- O tranzacţie dintr-un modul să aibă efecte în cascadă imediat în celelalte module.
Unii “inițiați” spun că MRP trebuie să și genereze documente pe baza unor reguli
clare setate inițial și să declanșeze automat comenzi către furnizor [trigger PO
requisitions] pentru reaprovizionarea magaziilor rămase sub stocul de siguranță
(dar asta nu face obiectul prezentei lucrări).
Exemple:
Nomenclatoare: Nomenclatorul de mărci salariați se gestionează într-un singur loc să
spunem în aplicaţia de salarizare unde se definesc salariații cu identificare unică pe
marcă, cnp, nume. Toate celelalte module vor beneficia de atributul marca_salariat fară
ca salariatul să mai fie redefinit şi în modulul de mijloace fixe, în deconturi salariați, în
obiecte de inventar în folosință, în modulul furnizori sau în modulul clienţi/facturare (când
cumpără ceva de la propria firmă pe datorie), în modulul producţie pentru raportare
manopera (Salariatul X poate fi alocat unei secții, unui utilaj, unei operații) ș.a.m.d….
Tranzacţii: O tranzacţie aferantă facturării va avea imediat efecte în: modul clienţi (apare
obligația de plată la client în fişa client), în stoc (apare tranzacţia de ieșire în fişa de
magazie), în conta (fişa de cont, balanţă - conturile de clasa 3 se creditează şi se
debitează 6 sau 711 dupa caz , încărcare 4111 şi 70x de asemenea), în istoric facturi
(pentru că factura emisă la client să poată fi reprintată/PDF sub formă de duplicat), în
jurnalul de vânzari , D394, D390,D300 ș.a.m.d
Dacă un salariat (marca) se va băga de două ori în două module din aplicaţie sub formă
de nomenclator de modul separat atunci apare o problema.
Dacă o tranzacţie dintr-un modul nu apare imediat şi în modulul aflat în cascadă/conex
atunci avem o altă problemă. Probabil că suntem obligați să rulăm manual funcții de
sincronizare și preluare informaţii din alte module sau să întreținem nomenclatoare de
salariați în mai multe locuri în aplicaţie (incorect).
Pagina 58/142
Completare: Vă mai amintiţi tehnica folosită de multe aplicaţii în anii 90 când se dădea un
cod nou în nomenclatorul de articole pentru fiecare intrare la preț nou de la furnizor deși
articolul tot Bec de 220V/60w era (şi tot de la BADUC venea) pentru că altfel aplicaţia nu
știa altfel să gestioneze prețul FIFO cu identificare specifica? Sau avea câte un cod diferit
al aceluiași articol în magazii diferite? – Acela cu siguranță nu era un ERP.
Pagina 59/142
8.2. Câteva c uvinte despre aplicaţiile din clasa small busi ness.
Programele din clasa "small business" se instalează de obicei "așa cum sunt" adică
furnizorul nu face modificări la aplicaţie doar de dragul unui beneficiar ci îi furnizează
acestuia un pachet standard. Beneficiarul primește de obicei un CD (sau câteva dischete
pe vremuri) şi un manual de utilizare pe care le instalează apoi pe calculatorul "de acasă",
după care i se mai poate face un instructaj la "botu’ calulului", la sediul său sau al
furnizorului.
8.2.1 Avantajele unui soft din clasa "small" sunt următoarele:
Prețul total mic (cu marje relative între 100$ şi 10.000 $) care poate include şi instalare,
documentație, instructaj, mentenață, service şi upgrade periodic şi alte facilități. Dacă
softul a fost cumpărat de la un magazin atunci cumpărătorul trebuie să se descurce cu
documentația care însoțește CD-ul, în preț nefiind incluse de obicei alte facilități precum
instructaj , mentenanță, service. În acest caz prețul de magazin poate fi chiar mic.
 instalare ușoară cu efort minim din partea clientului;
 suport hardware nepretențios 1-2 calculatoare (cu memorie puţină, hard disc mic,
lipsă rețea);
 programele sunt însoțite de module prietenoase şi uneori sunt pline de artificii ce
fac deliciul utilizatorului;
 pentru firmele mici (1-20 angajați) sunt suficiente;
8.2.2 Dezavantajele unui soft din clasa "small" sunt următoarele:
Programele NU acoperă decât un segement restrâns din necesitățile de evidență

financiar-contabilă ale unei firme. Programele sunt specializate doar pe un anumit
domeniu al activității firmei (stocuri sau mijloace fixe sau salarii sau contabiliate generală
sau evidență clienţi sau furnizori) sau sunt super specializate (program de scriere facturi,
program de scriere ordine de plată, program de scriere bonuri fiscale prin casa de marcat
etc.)
Pagina 60/142
Modulele NU "comunică" între ele beneficiarul/clientul fiind obligat să cumpere 4-5

programe diferite care fac lucruri diferite. Uneori cumpărarea se face de la furnizori diferiţi
fiecare program având propria lui "logică" şi "față" generând uneori confuzii;
Numărul mare al aplicaţiilor independente şi specializate face ca beneficiarul să

manipuleze date redundante, uneori fără consistență deoarece este obligat să lucreze cu
mai multe nomenclatoare aflate pe aplicaţii diferite. Imaginați-vă că doriţi să vă codificați
furnizorii sau clienţii atât în aplicaţia de desfacere cât şi în cea de stocuri, doriţi codificarea
salariaților în aplicaţia de salarii dar şi în cea de contabilitate sau de stocuri, doriţi sa vă
codificați conturile în programul de contabilitate generală dar şi în cel de furnizori, stocuri
sau mijloace fixe;
Nesincronizarea tranzacţiilor. Un alt inconvenient apare atunci când firma s-a dezvoltat
are câțiva zeci de salariați, câteva depozite unele aflate la distanță față de sediu, câteva
sute de mijloace fixe cu diferite regimuri de amortizare, un portofoliu mare de clienţi sau de
furnizori. În acest caz apare necesitatea ca unele aplicaţii care înregistrează analitic şi
zilnic diverse activităti "să verse" date periodic către alte aplicaţii care fac închiderea la
sediul central pentru a se putea obține o balanță unică curată.
Efort mare din partea directorilor de urmărire a tuturor acestor tranzacţii fărămițate în ‘n’
locații;
Costuri cu personalul: număr mare de operatori sau suprasolicitarea operatorilor isteți.

Practic un grup de date riscă să fie băgate diferit în aplicaţii diferite de către operatori
diferiţi.
Pagina 61/142
8.3. Câteva c uvi nte despre aplicaţiile din clasa ERP:
8.3.1 Avantajele unui soft din clasa "ERP" sunt următoarele:
a.) Dacă firma are management bun şi afacerile merg bine, costurile iniţiale mari cu
achiziţia aplicaţiei ERP se recuperează clasic în 2 ani. Totodată prezența în curtea
dvs. a unui ERP de calitate se transformă repede într-un sprijin de neînlocuit şi
poate apare în scurt timp "efectul de levier" prin care investiţia iniţială se întoarce
sub formă de profit precum se întoarce profitul dintr-un credit utilizat bine.
b.) Integrarea modulelor clasice într-un tot unitar. Practic aplicaţiile ERP reunesc într-
un singur întreg cel puţin modulele: contabilitate financiară, stocuri, mijloace fixe,
salarii, nomenclatoare, administrare aplicaţie. Suplimentar pot apare modulele:
producţie, costuri, comercial-desfacere, aprovizionare, management, bugete.
c.) Tranzacţiile sunt unice. Practic un eveniment/înregistrare se bagă o singură dată de
o singură persoană într-un singur modul al aplicaţiei nemaifiind necesară nici o
prelucrare;
d.) Totul se desfăsoară în timp real. O înregistrare este "văzută" instantaneu după
introducere în toate celelalte module producând efecte în cascadă, de ea
beneficiază toate stațiile de lucru din rețea. Un "eveniment" petrecut la Baia Mare
poate fi "văzut" la București după câteva secunde;
e.) Directorii/managerii de la toate nivelurile beneficiază de date neredundante şi
corecte;
f.) Teoretic exista o multitudine de rapoarte şi interogări din toate modulele acoperite
de aplicaţie. Spun teoretic fiindcă în realitate majoritatea Erp-urilor sunt sărace în
rapoarte standard şi ești obligat să apelezi la scule externe tip Report Builder dacă
ERP-ul nu are inclus asa ceva cum ar fi Qlik sau Cristal Reports;
g.) Aplicaţia face ordine în curtea dvs., lucru poate nedorit de toată lumea.
h.) Implementarea unei metode sau tehnici de management consacrate - asta trebuia
să o trecem prima dar ne facem că "am uitat". Aici vorbim de o forma de MRP,
managementul comenzilor: comanda client cu trasabilitate prin comanda de
producţie şi apoi comanda către furnizor, gestiune prin conturi de clasa 9,
postcalculație, managementul bugetelor sau proiectelor. Una din aceste metode
este de fapt inima sistemului la care se aliniază toată organizația fară să știe.
Pagina 62/142
8.3.2 Dezavantajele unui soft din clasa "ERP" sunt următoarele:
a.) Costuri iniţiale totale mari. Prețul este ridicat (cu marje cuprinse între 50.000 şi
100.000$) inaccesibil uneori micilor firme. La acestea se adaugă de obicei prețul
licențelor pentru aplicaţiile client şi/sau server de bază de date precum şi costuri
suplimentare cu instructaj şi mentenanță;
b.) Costuri splimentare cu calculatoare mai performante, rețea, dispozitive de
comunicație;
c.) Mai nou dacă ai cumpărat varianta “cloud” a aplicaţiei ERP esti legat de mâini şi de
picioare şi dansezi cum zice producătorul, ești legat practic ombilical de producător.
Dansurile de la tine din sat sunt interzise: [sârba, hora, brâul, călușul şi chiar
brașovenca]. Ești dependent de cutia neagră numită cloud care este de fapt un
server de bază de date + server de aplicaţii accesat de catre dvs prin [https] prin
intermediul unui browser. Adio customizări în termeni rezonabili.
d.) efort fizic şi intelectual mare la analiză, instalare, instruire, startare, configurare atât
din partea clientului cât şi din partea furnizorului;
e.) necesită personal dedicat de supraveghere al aplicaţiei: administrator de aplicaţie,
informaticieni;
f.) necesită personal economic puţin mai calificat şi mai inteligent decât media;
g.) dacă condiţiile privind personalul economic, de administrare şi de supraveghere nu
sunt îndeplinite beneficiarul va apela des la furnizor pentru a-şi astupa aceste
"goluri". Apelarea la furnizor înseamnă costuri suplimentare destul de importante cu
consultanța;
h.) programele au în general interfețe rigide, neprietenoase şi utilizatorul trebuie să
respecte reguli stricte de introducere şi validare a datelor.
Pagina 63/142
9. Definire posibilă pentru ERP
9.1. Definiția mea pl us ce am mai p reluat de la alții

Explicație empirică generală:
Empiric un ERP este acea aplicaţie informatică care reușește să facă legătura
virtuală între patrimoniul clientului meu CLxxx mare vânzător/distribuitor en-gross, prin
patrimoniul meu firmă producatoare de conserve de pește PRxxx către patrimoniul
furnizorului meu firmă producătoare de cutii de tablă specializate de conserve FUxxx , în
condiţiile în care clientul meu nu cunoaște (aproape) niciodată pe niciunul din furnizorii mei
dar are încredere în mine.
Se mai poate spune că facem legătura între curtea clientului meu (vecinul meu din
dreapta) către curtea furnizorului meu (vecinul meu din stânga) prin curtea mea (centru).
Poziţie cadastrala: Vecin stânga Eu Vecin dreapta
Calitate: Furnizor Producător Client
Sens comandă: ← ← ←
Sens distribuție: → → →
Sens Bani/plată: ← ← ←
Cine este firma: Firma producătoare Firma CLxxx mare
de cutii de tabla producatoare de vânzator/distribuitor en-
specializate pentru conserve de pește gross
conserve Fuxx PRxxx
Explicație pe baza funcțiilor/modulelor unui ERP:

Se pornește în principal de la comanda client (CLxxx mare vânzător/distribuitor en-
gross) care îmi lansează mie una sau mai multe comenzi în care sunt indicate în principal
următoarele cerințe:
1. Articole de livrat (conseva tip_1, tip_2 , tip_3, tip_n)
2. Cantitățile necesare de livrat
3. Termen de livrare și
4. Locații în care se va face livrarea
Nu vorbim şi de alte detalii ce țin de condiţiile de livrare, transport sau calitatea a
finitelor livrate ca să nu complicăm descrierea precum: data expirării, ambalare, coduri de
bare, greutate, volum.
Pagina 64/142
Se presupune ca eu (PRxxx):
Nu lucrez pe stoc în afara stocului de siguranță la materii prime şi materiale şi nici
la finite. Nu pierd timpul în procesul de producţie. Lansez comenzi rapide şi eficiente către
toti participanții la procesul de producţie. Este principiul impus de tehnica de management
JIT (just în time) şi a derivatelor sale: Kanban39 şi Lean Manufacturing. Toate acestea sunt
specifice producţiei de serie mare şi masa şi nicidecum producţiei de unicate sau de serie
mică unde:
Loturile lansate au același comportament o lungă perioadă de timp uneori luni sau ani
(exemplu industria alimentară: lactate, băuturi, dulciuri, cafea ) atât la materii prime cât şi
la tehnologii şi linii de fabricație.
Detaliere la expresia “Nu pierd timpul în procesul de producţie” se referă la faptul ca timpii
considerați neproductivi ai procesului de fabricație (Timpul de pregătire–încheiere,
Timpul de întreruperi nereglementate, Timpul de deservire tehnică şi organizatorică,
Timpul de odihnă şi necesităţi fiziologice ) să fie cât mai mici gestionate şi supravegheate
cu ajutorul elementelor de control din cadrul ERP. Adică pe românește: nu trebuie să
schimb matrița de injecție sau capetele de alimentare sticle de trei ori pe zi, materia primă
folosită (faină, lapte, apă, zahăr, pungi, etichete) este cam aceiaşi luni de zile şi nu îmi
înfundă țevile, unitatea de ambalare este cam aceiaşi, utilajul nu se strică zilnic, operatorul
utilajului (strungarul) nu lipsește atunci când am nevoie de el sau sudorul lipsește cu
desăvârșire din România de 15 ani fiind plecat în Germania sau la pensie şi trebuie
înlocuit cu un lacătuș care acum învață să sudeze în cordon şi nu în puncte , … ș.a.m.d.
O să interveniţi din nou dvs. şi veți spune ce treabă are sudorul sau schimbarea matriței
cu un ERP?
Răspuns: ERP-ul este folosit în primul rând pentru gestionarea tranzacţiilor în timp real.
Asta înseamnă că sunt următoarele implicații:
- Tranzacţiile de raportare producţie se fac automat în punctele cheie ale fluxului
tehnologic – cu ajutorul unor cititoare automate – scanere de cod de bară sau alte
cititoare bazate pe senzori şi traductoare ce depistează acțiunea umană sau a
utilajului în procesul de producţie. În multe cazuri se fac şi prin raportare manuală
direct pe ecranul unui terminal aflat în secție de către Vasile sau Costel.
39
Kanban = este un subsistem de producţie în cadrul sistemului JIT, continuu şi la cerere, de furnizare a componentelor
necesare realizării produselor astfel încât muncitorii au ceea ce le trebuie, în locul unde este nevoie de astfel de
componente şi la timpul potrivit. Sistemul încearcă orientarea către PULL (trage) și nu către PUSH (împinge). Sistemul
PULL de producţie ne spune că nu producem nimic pe stoc pâna cineva nu dă o comandă (comandă socială). PUSH
este metoda clasică cu producţia pe stoc chiar dacă nu există acum o comandă de la client. PULL e fară producţie pe
stoc: Când apare comanda socială întreg lanțul de la vecinul din dreapta apoi eu și în final vecinul din stânga (dar și alți
vecini) începem să ne mișcăm trași de vecinul din dreapta.
Pagina 65/142
- ERP-ul este dotat cu alarme care periodic detectează aceste evenimente şi le

raportează grupat sau imediat unui decident.
- Lunar se pot face analize asupra acestor alarme, evenimente care ne pot prezenta
diversele motive de întrerupere a procesului tehnologic cu gradul lor de
repetabilitate şi de risc.
Se presupune că toate cele de mai jos sunt definite corect în aplicaţia ERP:
a.) Din punct de vedere producţie şi stocuri:
Conservele tip_1 la tip_n fac parte din portofoliul meu de produse, sunt definite complet în
nomenclatorul de articole cu toate caracteristiceile/atributele setate corect, au rețete de
fabricație definite, structura arborescentă de fabricație, tehnologie de fabricație (inclusiv
timpi), centre de lucru (mașini, utilaje asociate tehnologiei) definite corect.
De aici rezultă că toate componentele materiale (materii prime şi materiale) şi
nemateriale (servicii necesare funcţionării corecte a secției de producţie ) sunt cunoscute
anterior lansării în fabricație a conservei tip_3 de ex.
Suplimentar în unele ERP-uri vom găsi nomenclatoarele suplimentare de articole_client
și articole_furnizori ce conțin doar pentru clienții si furnizorii f. importanți (ăia de tip A din
clasa ABC) id_ul de identificare din nomenclatorul lor cu dictionar de translatare.
b.) Din punct de vedere aprovizionare/ furnizori:
Sunt cunoscuți toți furnizorii necesari pentru a ne aduce toate componentele materiale şi
nemateriale (servicii) de la pct. (a), avem setați timpii probabili de aprovizionare sau/şi
intervenție. Printre acești furnizori se află şi furnizorul nostru principal (firma producatoare
de cutii de tablă specializate de conserve FUxx).
c.) Din punct de vedere client:
Sunt cunoscute majoritatea comenzilor de la clienţi pe un orizont estimat la 15-30 de
zile (sau mai mult). Printre acestea se află şi comenzile clientului meu CLxxx (mare
vânzator/distribuitor en-gross)
Considerăm că (a)+(b)+(c) sunt suficiente pentru a prezenta funcţionarea MRP în interiorul
unui ERP cu scop didactic.
Dacă (a)+(b)+(c) sunt cunoscute atunci prin una sau mai multe funcții ce se rulează direct
sau în cascadă ordonată, cineva din firma mea (firma producatoare de conserve de pește
PRxxx), o “persoană importantă” bineînteles va rula aceste funcții cărora le spunem
generic funcții MRP care vor da următoarele rezultate în principiu sub forma unor rapoarte:
Pagina 66/142
a.) Ce finite ar trebui să produc? Stabilesc ce produse finite (conserve tip_1-tip_n) ar

trebui să produc şi în ce cantităti, la ce termene grupându-le pe acestea pe clienţi,
zile, trasee etc…
b.) Prin analiza lui (a) se trece la analiza materiilor prime, materiale şi a serviciilor
directe conexe producţiei pe care eu trebuie să le cumpar.
O întâmplare care îmi confirmă ce este scris mai sus este că această abordare
presupusă de mine cândva prin 2011 odată cu pamfletul [Cizmăria informatică. Sau
cum să vinzi și mai ales cum să cumperi linia de miră a unui ERP (versiunea originala
din noiembrie 2011)] formată din comanda client +comanda furnizor ce trec prin
patimoniul meu am întâlnit-o la una din marile aplicații ERP în 2020. Această aplicație
ERP are un portal separat WEB de clienți si un portal WEB pentru furnizori. Atât
comenzile clientului cât si cele ale furnizorului se gestionează numai pe acolo. Dacă
nu s-au introdus comenzile pe acolo de cei doi (furnizor+client) nici eu si nici ei nu
putem să lansăm sau să facem nici o recepție sau livrare din sau dinspre client/furnizor
în interiorul ERP-ului. Bineînțeles că aplicația este flexibilă și poți să dezactivezi funcția
de portal WEB si să bagi comenzile SO/PO și manual.
9.2. Metode şi tehnici de manageme nt i mpleme ntate de obicei în

interio rul unui ERP a nglo-saxon, doar enumera re fără co menta rii.
1. Metoda pe produs (echivalent comanda) cu variantele concrete:
a.) Repetitive manufacturing – producție repetitivă
Fabricarea repetitivă este producția în curs de desfășurare a aceluiași produs pentru o
perioadă extinsă de timp. Produsul este de obicei asamblat pe o linie de producție, unde o
serie de sarcini sunt finalizate în aceeași ordine de către angajați și / sau roboți.
b.) Discrete manufacturing – producția discretă sau parts manufacturing
Producția discretă este un termen industrial pentru fabricarea produselor finite care sunt
elemente distincte capabile să fie ușor de numărat, atins sau văzute. Producția discretă
implică piese și sisteme cum ar fi: ventilator, volane, nituri și șuruburi, fire/cablaje alte
ansambluri și produse individuale identificabile.
2. Metoda conducerii prin buget

3. Metoda conducerii prin proiecte
Metode şi tehnici de management implementate de obicei în interiorul unui ERP

românesc, doar enumerare fără comentarii.
1. Metoda urmăririi contului contabil (nu veți găsi în literatura economică)
2. Metoda pe produs – pe comenzi
3. Metoda conducerii prin proiecte amestecate cu activităti
Pagina 67/142
10. ERP generator de documente sau imitator de documente?
Nu uitați că ERP-urile consacrate sunt generatoare de documente şi nicidecum

imitatoare de documente. Ce înseamnă asta?
Exemplu simplu cu Bonul de consum - descriere stare de fapt/cerință/eveniment:

În ziua de 22.03.2019 maistrul Mitrea de la compartimentul “Mecanicul Șef” primește o
solicitare la ora 14:45 prin telefonul interior fix din biroul său pentru a merge repede în
Atelierul 2 injecție mase plastice să intervină la repararea urgentă a utilajului nr_35 (presa
injecție mase plastice) care acum are montată pe ea matrita specială pentru cutii XYZ.
Funcţionarea utilajului s-a oprit datorită unui furtun de presiune care refulează. Dl. Mitrea a
mai făcut de mai multe ori aceast tip de intervenție anul acesta şi stie că pentru această
intervenție neplanificată la acel utilaj este nevoie de 2 garnituri mici G1, două garnituri mari
G2, 3 lavete, 1L diluant D1, 500g ulei U1, 4 siguranțe S1 şi … trusa de scule. Toate
acestea se găsesc în două magazii: magazia M1 din clădirea principală şi magazia M2 din
capătul secției 2 aflată la 300 m de blocul turn administrativ.
Se va duce să ia componentele şi apoi se va duce să repare imediat utilajul pentru că
toate cutiile produse de matrită să fie trimise la secția montaj SM pentru a fi terminată
ultima tranșă de 800 de bucăți din cele 5000 de aparate de tip A1. Urgența e mare fiindcă
ambalarea trebuie facută simultan la toate cele 5000 de aparate tip A1 care apoi trebuie
să fie gata de livrare la schimbul 3 la ora 4:00 dimineața pentru ca apoi marfa să fie livrată
imediat (camioanele transportatorului sunt în curte de ieri şi plătim taxă de staționare
aiurea la ele). Am uitat să spun ca dl. Mitrea a sunat şi la electricieni ca la intervenția
aceasta să participe şi Marian (noul electrician) care se pricepe la panoul de siguranțe.
Intervenția a durat 3 ore la dl Mitrea şi 2 ore la Marian – total 5 ore de repartizat pe regie
CFIU (cheltuieli cu funcţionarea şi întreținerea utilajelor) probabil.
În cazul unei firme ce NU are implementat un ERP, bonul de consum deși se completează
atunci când Mitrea ridică materialele din magazii: toate tranzacţiile informatice (mai ales
cele contabile) ce ţin de stoc, contabilitate şi pontaj-salarii se fac undeva la multe zile de la
petrecerea acestui eveniment. Acestea se fac de obicei în perioada 1-10 luna următoare
lunii evenimentului. Concrect între 01-10 aprilie 2019 operăm în realitate acele bonuri de
consum care s-au petrecut în realitate în ziua de 22.03.2019.
Între 22.03.2019 şi 10.04.2019 șefii, directorii doar “au auzit” că s-a întâmplat din nou ca
presa (utilajului nr_35) să dea rateuri, dar nu cunosc exact cuantumul şi implicaţiile
Pagina 68/142
pagubei deoarece acestea nu au fost consemnate/jurnalizate complet sau deloc în

registrele firmei pâna în data de 10.04.2019. La asta se adaugă şi alte evenimente.
Aceasta este cazul unei firme imitatoare de documente deoarece deși toate faptele s-au
petrecut şi lucrarea s-a executat cu succes (datorita lui Mitrea care e băiat deștept), o
parte din documentele de pe hârtie s-au scris/emis la multe zile distanţă de la petrecerea
faptei sau informaţiile de pe documente emise sunt reluate în diverse registre/jurnale.
În cazul unei firme care are implementat un ERP, evenimentele pe flux ar trebui să fie
următoarele:
- Unul din detectorele/traductoarele X de pe presa (utilajului nr_35) lansează un
semnal către aplicaţia ERP (se poate consemna şi manual de operator acest pas);
- Aplicaţia ERP lanseză o alarmă pe ecran (poate fi şi SMS mai nou) pe unul din
traseele prestabilite – în principal către: șeful de secție/atelier, inginerul șef firmă
sau directorul tehnic, mecanicul șef;
- șeful de schimb din secție face constatarea vizuală şi lansează o cerere de
intervenție la mecanicul șef prin ERP;
- șeful de tură de la mecanicul șef face la rândul lui încadrarea intervenției (o califică
zic șmecherii), verifică disponibilitatea de stoc a componentelor aflate în magazii
(tot în ERP) şi lansează către magazii cerereile pentru bonurile de consum;
- maistrul Mitrea se deplasează la magazii pentru ridicarea materialelor. Aici bonul de
consum este aproape completat – se face doar validarea la eliberarea din magazie
către secție.
- La sfârșitul intervenției Mitrea va completa în ERP fişa de intervenție utilaj în care
va trece consumurile materiale efective (poate nu a folosit toate cele luate de la
magazie și a făcut retur) şi orare (3 ore el şi 2 ore Marian).
Aceasta este cazul ideal al unei firme generatoare de documente deoarece totul se
întamplă în timp real – aproape toate documentele de pe hârtie s-au scris/emis
aproape imediat cu petrecerea evenimentelor. Documentul este emis din ERP de
obicei.
O parte din efectele în/din ERP:
- Stocul este descărcat imediat din magaziile M1,M2, consumul se face imediat.
Tranzacţiile apar imediat în fişa de magazie, balanţa de stoc, situația consumurilor
pe centre de cost, copia bonului de consum electronica ș.a.m.d;
- Dacă avem implementată o metodă de gestiune stocuri corectă FIFO cu identificare
specifică fiecare element de stoc se va descărca la prețul de stoc specific prețului
Pagina 69/142
real de aprovizionare (furnizor+CTA) al acelui lot şi nicidecum la un preț tip

“găleată” : Standard, CMP sau CMR (recalculat sau periodic costing).
- articolele de stoc consumate apar în listele de necesar de aprovizionat pentru viitor
dacă am intrat sub stocul de siguranță (MRP);
- toate tranzacţiile contabile pe conturile de clasa 3 şi 6 implicate apar în fişa cont,
balanţă, bilanț, reg. jurnal general, carte mare;
- timpii/ orele consumate de cei doi apar pe fişa lor de pontaj;
- rapoartele de analiză din producţie indică timpii suplimentari consumați cu
reparațiile, toate intervențiile nedorite/neplanificate apar în listele de control unde
vedem atât repetabilitatea cât şi cauzele opririlor. Prin analiza de istoric putem să
luăm şi decizii de înlocuire sau de reparație capitală a utilajului.
- Prin rapoartele de analiză se mai cunosc ora şi minutul întreruperilor, participanții
executanți sau decidenții care au rezolvat incidentul, timpii de răspuns.
11. Structura modulară şi funcţională a unui sistem ERP

Module de bază :
a.) Format american: AR, AP, SO, PO, GL, WO, IC, FA, RE, HR
b.) Format francez (continental – implicit aplicabil în România): Cumpărări,
achiziţii, recepţii, transferuri, producţie, stocuri, vânzări/facturare, încasări-
plăți, furnizori, clienţi, contabilitate , mijloace fixe, reevaluare documente
în sold şi conturi devize, salarizare
11.1. Inima sistemul ui ERP: Metoda de gestiune a prețului de stoc

folosită: Standard, CMP ( AVG), F IF O (cu identificare specifică)
Din nou acest subcapitol ce face legatura între ERP ca aplicaţie integrată, metoda
gestiune a stocurilor setată şi contabilitate ar trebui tratate profesional într-o lucrare
separată de 200-300 de pagini A4.
Am enumerat aici cele trei metode de stoc [Standard, CMP (AVG), FIFO cu identificare
specifică] foarte des folosite deoarece ele se regăsesc atât în viața reală din firmă dar şi
ca metode de bază în aplicaţiile ERP (nu în toate).
Pagina 70/142
Totuși încerc aici în câteva cuvinte să ating principalele probleme cu care aplicaţiile ERP
se confruntă în gestionarea stocurilor.
Lumea serioasă îsi cumpară un ERP tocmai ca să gestioneze eficient stocurile indiferent
dacă suntem un mare distribuitor engross, suntem un mare retailer (adică avem mai multe
magazine de tip supermarket sau hipermatket), suntem o firmă de producţie de serie mare
(masă) sau ne ocupăm cu producţia la comandă de unicate sau loturi mici fară
repetabilitate tehnologica (avioane, vapoare).
În oricare din situațiile de mai sus (producţie sau comerț) avem multe articole unice de
stoc (zeci de mii) care intră de la diverși furnizori cu diverse prețuri de factură furnizor la
care se adaugă de obicei CTA40 (în cele mai multe cazuri).
Veți observa în interiorul aplicaţiei ERP că există un grup de setări specificice în zona de
gestionare a stocurilor de unde veți alege metoda de cost (americanii zic cost = [what cost
method you are using ?]). Noi pe aceste meleaguri zicem preț de stoc care preț de stoc
e format din prețul de furnizor (prețul din factură de furnizor) la care se adaugă
proporțional valoric cota de CTA ce revine acelui reper/ linie/articol din factura de furnizor.
CTA majoritar este format de factura de transport la care se pot adăuga alte facturi de
servicii şi comisione pe care noi le plătim terților pentru a aduce articolul în curtea noastră.
Practic în momentul recepţiei [NIR] în “magazia mare” șurubul, laveta, pixul, diluantul sau
microcontrolerul conțin pe lângă prețul de furnizor şi acele cheltuieli CTA ce se regăsesc
în facturi separate. Aceste facturi de servicii şi comisioane pot fi comisioanele şi taxele
vamale pe care noi le achităm separat în Vama Pitești sau Constanța Sud şi se regăsesc
în declarația DVI.
Implicații în ERP pe tipuri de metode de stoc folosite Standard, CMP (AVG), FIFO (cu
identificare specifică):
11.1.1 Metoda de cost Standard . Prețul de stoc standard în Balanța de stoc
Metoda de cost Standard este metoda cu care s-au născut majoritatea ERP-urilor acum
40 de ani. Motivele utilizării au fost acestea:
1. Relativa stabilitate a prețurilor în USD în principal pe un orizont de 6 luni – 1 an.
Adică eu setez în ERP per articol 0.25 cenți în ianuarie la șurubul M16 şi pâna în
40
CTA = cheltuieli de transport aprovizionare care conform lgislației trebuie să facă parte din prețul de stoc pâna la
descărcarea completă a articolului prin consumul în producţie sau vânzarea mărfii către client. Veți găsi referiri la CTA de
mai multe ori în această lucrare.
Pagina 71/142
decembrie nu mă doare capul că nu apare nici o variație de preț pe factura furnizor

şi tranzacţiile de stoc şi cele contabile se vor face corect la 0.25 cenți X cantitatea
intrată.
2. Negocierea drastică la nivel de cent pentru comenzi cadru ce se întindeau uneori
pe mai mult de un an. Asta înseamna că prețul negociat de 0,25 cenți pentru un
șurub M16 rămânea bătut în cuie atât la nivel de preț PO (comandă cadru PO
iniţială făcută în ianuarie) iar prețul de factură legată la acel PO era tot 0,25 cenți
pentru toate șuruburile sosite în aprilie, iulie sau decembrie. La anul în ianuarie
negociem din nou prețul la 0.27 şi apoi schimbăm şi noi prețul standard în ERP la
reperul șurub M16 (costul cum zic americanii) şi toată lumea e mulțumită.
3. Posibilitatea aruncării eventualelor diferențe de preț pe cheltuială dacă ele apar
între prețul PO (cel negociat ) şi prețul de factură. Aici americanii spun PO price
variance sau Invoice price variances….adică zic preț. La noi nu există așa ceva.
4. Interesul pentru rezolvarea intrărilor de stoc cu cheltuieli de stocare cât mai mici în
condiţiile în care [tu erai Dumenezeu] pentru furnizorul tău fiindcă îi asigurai o
desfacere constantă pe o periodă lungă de timp– vezi APICS şi JIT mai sus.
5. Contabilitatea reală a stocurilor se făcea la începutul lunii următoare (01-10 Aprilie
pentru 01-31 Martie) prin preluări de date şi de fișiere din diverse module, postări
de note şi importuri de fișiere.
6. Componenta specială a prețului de stoc STANDARD special pentru finite şi
semifabricate format din preț materiale + cotă regie 1 + cotă regie 2 + colaborări
+ salarii (manoperă). Această componetă specială o veti găsi în ERP de obicei
sub numele de cost elements: material + burden + overhead + labor/salary
Şi atunci poate utilizarea prețului de stoc standard ar fi putut fi justificată.

Dacă ne uităm la punctele de mai sus observăm însă că prețul standard este destinat ca şi
în contabilitatea francofonă gestionării unui preț fix destinat finitelor şi semifabricatelor şi
nicidecum materiilor prime sau mărfurilor.
Unul din efectele negative pe care această metoda de gestiune a stocurilor îl are este şi
existența prețului de stoc standard în Balanța de stoc. La analiza Balanței de stoc pe care
o rulăm la 30-06-2021 vom găsi șurub M16 în stoc final de 500 bucăți cu un sold final de
125 USD. Cu siguranță cele 500 bucăți rămase în stoc la 30.06.2021 au fost afectate de
niște cote de CTA şi cu siguranță unele au intrat la 0.24 USD iar altele la 0.26 USD
Pagina 72/142
11.1.2 Metoda de cost CMP/AVG sau prețul de stoc în timp real. Prețul de stoc CMP
în Balanța de stoc.
Metoda de cost CMP/AVG sau prețul de stoc în timp real sau cost mediu ponderat în timp
real [americanii zic costul în timp real sau perpetual average costing] este metoda imediat
apărută după Standard Costing. CMP/AVG se referă la un calcul continuu pe care
programul îl face după fiecare intrare de stoc în magazie:
- De obicei calculul este făcut pe combinația cod_articol/sait adică pentru un articol
ce se plimbă între magaziile aceleiași curți/fabrici/amplasament.
- Sunt considerate intrări orice recepţii din PO adică NIR/receipt pe baza comenzii de
aprovizionare, recepţiile din notele de transfer (interne sau din avize externe),
retururile de orice fel (retur tip RMA din Sales Order/factură storno sau retur din
comanda de producţie), intrările din reglajele de inventar.
Balanța de stoc în cazul folosirii metodei CMp/AVG este plină de cantități în stoc initial
pozitive(+) dar cu sold inițial cu minus(-) sau sold final cu minus(-) dar cantiate zero (stoc
final= 0).
11.1.3 Metoda de cost FIFO sau prețul de stoc cu identificare specifică inclusiv CTA.
Prețul de stoc FIFO în Balanța de stoc.
Încep prin explicarea noțiunii de FIFO în contextul mişcărilor de stoc care este un context
economic şi contabil în același timp.
Majoritatea oamenilor fac confuzie aici cu metoda FIFO de alegere din stiva în așteptare
din automatică care se referă la ordinea mişcării (scoaterii din stivă) adică cine se va
mișca primul într-un anumit context tehnic şi acesta poate fi de obicei FIFO (adică primul
intrat în acea stivă se va mișca) iar la LIFO se va mișca ultimul intrat.
Da într-adevar la FIFO din automatică + matematică + programare vom mișca FIFO pe
primul intrat în stiva. Aici în contabilitate vom mișca tot FIFO acea cantitate dar cu
amprenta sa valorică. Adică nu mișcăm doar cantitățile cum ne păcălesc unii “iniţiați” ci
mișcăm şi componenta valorică a acelei cantități. Adică îl vom scoate spre consum din
stoc atât cantitativ dar şi valoric conform prețului de stoc de intrare cu care el s-a format
în momentul recepţiei. Prețul de stoc de intrare este unul simplu bazat doar pe prețul din
factura furnizor sau unul complex (complicat) bazat pe preț_furnizor (coloana 5 de mai jos)
la care se adaugă cota de CTA proporțională din factura (facturile) de servicii (cel puţin
transport - coloana 7) ambele formând prețul de stoc (coloana 9) pe care îl vom regăsi în
balanța de stoc şi fişa de magazie cantitativ-valorică.
Pagina 73/142
Prețul FIFO sau prețul de stoc cu identificare specifică inclusiv CTA se referă la faptul că
sistemul este obligat să țină evidența fiecărei intrări pentru același ID de articol
(cod_articol = Surub_0001234) la un preț format din prețul de furnizor +CTA aferent
punctual acelei intrări. Pe scurt prețul de stoc ar trebui să arate așa – vezi coloana 7 de
mai jos:
-LEI-
Poz Reper, Data_Intrare_NIR Pret CTA Preț de stoc unitar inclusiv Cantitate/QTY Valoare intrată - ar
cod_articol factura (transport,taxe, CTA în balanța de stoc şi intrată trebui să apară pe
furnizor comisione, fişa de magazie cantitativ- debit cont 3011 sau
valorică similar
1 2 3 4 5 6 7 8 9
1 Surub_0001234 13-06-2021 5.25 0.12 5.37 12 64.44
2 Surub_0001234 19-06-2021 5.37 0.08 5.45 240 1,308.00
3 Surub_0001234 27-07-2021 4.98 0.13 5.11 50 255.50
4 Surub_0001234 10-08-2021 5.09 0.11 5.20 144 748.80
TOTAL 2,376.74
12. Nomenclatoare principale. Terți, articole stoc, taxe (GTM), Plan

Conturi, centre cost (organigramă), proiecte.
Fară a intra prea mult în detalii încercăm să sintetizăm care ar fi nomenclatoarele de
bază f. importante fară de care un Erp nu ar fi ERP:
Acestea sunt:
Nomenclatorul de clienţi + nomenclatorul de furnizori, - terții firmei. Acestea sunt
nomenclatoare ce țin de gestionarea terților cu care firma dvs. intră în relaţii economice şi
de la care primiţi sau emiteţi facturi fiscale sau avize.
Nomenclatorul de mărci – aici discutăm de salariați care trebuie tinuți pe marcă (cod
unic) şi pe CNP (ca așa e în Romania).
Nomenclatorul de Plan de conturi - conform Plan de conturi Mfinanțe specific ramurii
dvs. (firme, bănci, ONG-uri, instituții publice cel puțin)
Nomenclator centre de cost – de obicei conform Organigramă pentru a putea obține un
postcalcul şi o repartizare /ventilare a cheltuielilor şi a veniturilor pe structură.
Nomenclatorul de TAXE (TVA/GTM)– format din mai multe sub-nomenclatoare pentru
cote de TVA, ţări , zone fiscale, moduri de livrare/achiziţie (vezi AIC, LIC de la intrastat).
Nomenclatorul de articole de stoc – sunt coduri unice interne alocate fiecărui articol de
stoc (clasa 3 la noi) de la șurub, lavetă, gumă şi diluant la șuba portarului, telefonul din
Pagina 74/142
secretariat şi finitele sau semifabricatele din procesul de producţie. Acesta a fost primul
nomenclator inventat în primele ERP-uri.
o O particularitate la nomenclatorul de articole de stocuri: acesta poate avea o
extensie pentru gestinoarea prestațiilor şi a serviciilor (articole non stoc
numite şi MEMO items în unele aplicaţii) . Extensia de obicei constă în flagul
STOCK/Non-stoc sau Inventory /Non-Inventory41.
o Unele aplicaţii ERP au nomenclator de prestații şi servicii distinct [separat]
de nomenclatorul de stoc. Această variantă încurcă însă puţin (puţin mai
mult chiar) definirea fluxurilor din zona de purchasing (achizition PO)
Nomenclatorul de proiecte – se referă la coduri unice interne alocate fiecărui proiect în
lucru. O să spuneți că proicet putem spune la orice pe lumea asta adică: şi la un proiect
finanțat de UE, Banca mondială sau Sapard, în proiecte putem să ne ascundem şi
mijloacele fixe, la proiecte punem şi urmărirea pe sonde/utilaje de foraj, în concluzie
câmpul de proiect din tranzacţie şi modulul de proiecte din Erp este ceva ce nu e nici cal şi
nici măgar (dar nici catâr) adică e struțo camilă. Încercăm mai jos să exemplificăm pentru
ce a fost gândit modulul de proiecte din ERP.
Să detaliem puţin despre proiecte (projects):
- Gestionarea proiectelor reprezintă activitatea din ERP care încercă sa gestioneze
activitățile pe bază de proiect deschis pentru o anumită lucrare complexă în cele
trei(3) stadii ale unui proiect: [1] la nivel de bugetare (previziune), [2] execuție
(consum resurse materiale, umane şi servicii) şi [3] analiză (postoperatorie prin
rapoarte).
- Activitatea de gestionare proiecte este activitate distinctă şi nu poata fi suplinită,
înlocuită sau simulată prin modulul de producţie (WO) cum încercă unii diverse
[soluții de fugă] sau prin câmpurile user_fields (câmpuri utilizator) şi alte liste ad-
hoc.
- Un exemplu concret f. aproape de realitate şi pe care eu nu l-am gasit optimizat în
nici un ERP cunoscut dar nici în aplicaţiile economico-financiare românesti (ERP-
urile nu îl acoperă cu instrumente usor de gestionat) este activitatea de comandă
pe bază de proiect. Exemplu: firma de automatizări ProjectSysXYZ face panouri
de autoamatizare complexe care se instalează în șantiere, porturi, aeroporturi,
metrou, rafinării, termocentrale, hidrocentrale. Aceste panouri sunt formate din
41
Non- inventory items (non-stock) în nomenclatorul de articole este “varianta de fugă” prin care unele aplicaţii
ERP au încercat să rezolve problema prestațiilor şi a serviciilor în același nomenclator cu cel de articole de stoc. Unii le
mai spun acestora şi activități. În unele ERP vom găsi altă “găselniță”: noțiunea de MEMO item cu urmărire doar pe
descriere. Ambele sunt un mod periculos de a gestiona prestațiile/activitățile şi necesită multă atenţie în operare şi pot
genera confuzii în analize şi rapoarte.
Pagina 75/142
multe piese electronice şi mecanice care se montează contextual la beneficiar de

către o echipa trimisă de ProjectSysXYZ formată din ingineri, tehnicieni şi
muncitori în curtea beneficiarului (în aeroport să spunem). De obicei instalarea este
echivalentă cu punerea în operă a unei noi construcţii (vezi construcţii montaj),
durează de la 1 săptămână la 3 luni în funcție de complexitate. Acei oameni sunt în
permanentă delegaţie sau chiar în detașare uneori. Numărul pieselor diferite per
panou (electice, mecanice, furnituri) poate depăși 1000. Montajul se face contextual
la botu’ calului. Acel panou are nevoie de cele 3 stadii de de mai sus ([1]bugetare,
[2]execuție/consum effectiv, [3]analiză post-operatorie) pe care modulele de proiect
din cadrul ERP încearcă să le acopere. Dar mai au nevoie iniţial de proiectarea
tehnică facută de ingineri în care se stabilește BOM42 (bill of material). Pe lânga
BOM la proiecte avem nevoie de resurse umane (ore om per operații) şi f. multe
facturi de servicii externe cu cheltuielile aferente activităților prestate de alți furnizori
care ne ajută pe noi punctual să punem în operă panoul de automatizări. Serviciile
externe pot fi, exemple: o macara care mută panoul montat pe sol la etajul 3 sau în
groapa/pivnița din dreapta clădirii. Un trailer care ne aduce un postament uriaș gata
montat pe care o să punem noi cu macaraua panoul după ce îl montăm pe sol. Un
excavator cu cupa mică îngustă pentru săpat șantul de alimentare cu tensiune de
380V pe o distanță de 200 m.
- Un alt exemplu: Proiectul ca exemplu concret (şi ca metodă de management) se
mai folosește şi în activitatea de mentenanță utilaje complexe cum este industria
de mentenantă /servicii pentru instalațiile petroliere. Fiecare utilaj (sondă, instalație)
poate fi definită ca proiect [ai 2000 de sonde = 2000 de id-uri de proicet separat].
O problemă des ridicată de ingineri în cazul folosirii modului de proiecte din Erp ar fi
ușurința (sau rigiditatea) de a modifica o resursă definită din stadiul de proiectare. Ce
însemnă asta:
- În urma proiectării panoului de automatizare cu 1000 de repere diferite de la șurub,
condensatori, siguranțe, micro-controlere, relee, șine/culise etc… vom observa că
în piață avem furnizori diferiţi sau furnizori unici, prețurile sunt mari sau mai mici iar
disponibilitatea (timpul de aprovizionare) este discutabil – în aceste condiţii după
definirea proiectului tehnic şi copierea BOM-ului şi resurselor în ERP constatăm că
diverse repere nu mai pot fi aprovizionate de la furnizori şi este necesară înlocuirea
rapidă a acestora. Uneori înlocuirea nu se face cu un component compatibil [similar
42
BOM – Cunoscut ca [bill of materials or product structure] este lista tuturor materialelor necesare realizării unui
finit şi se folosește şi la realizarea unui proiect nou după faza de proiectare inginerească.
Pagina 76/142
identic] şi suntem nevoiţi să înlocuim 5 sau 10 componete din jurul uneia principale
adică să facem în realitate o modificare de soluție. Aceste modificări de soluție
duc apoi la modificarea şi /sau înlocuirea BOM-ului din Erp pentru proiectul X şi a
resurselor aferente (ore om sau ore utilaj extern). ERP-ul trebuie să permită facil
aceste modificări. În caz contrar modulul de proiecte din ERP devine o povară
pentru clientul ce îl exploatează.
Concluzionând pentru Nomenclatorul de proiecte şi pentru Modulul de proiecte
oferit de Erp acesta trebuie să permită gestionarea rapidă a urmatoarelor activități:
- Definirea rapidă a proiectelor în lucru cu atribute specifice (data start, valabilitate,
tip);
- Manipularea ușoară a stucturii de proiect BOM respectiv înlocuirea resurselor
materiale sau servicii;
- Ușurința marcării proiectului în momentul efectuării oricărei cheltuieli care aparține
acelui proiect. În limbaj popular asta înseamnă că atunci când bag factura de
servicii (macara, excavator, trailer) de la furnizorul XYZ…1234 să pot marca imediat
în același ecran cu liniile facturii proiectul la care se duce cheltuiala fără a mai face
alte artificii inutile şi stupide generatoare de confuzii. Cheltuiala resursei
om/salariat/marcă din bonul de manoperă sau pontaj, deviz de lucrari,
delagație/detașare să fie înregistrate direct pe proiectul X;
- Consumul de materii prime, materiale (bonul de consum în principal) să fie
înregistrat exact pe proiectul X;
- Ștergerea unei facturi de furnizor (AP Invoice) sau stornarea uneia să opereze
exact pe proiectul vechi și să îl reîncadreze pe cel nou fară să rămână “scame” în
tranzacții.
Întrebări:
A1.) Ce se întâmplă dacă un client este şi furnizor în același timp ?
Răspuns – este o poveste veche cu multe implicații ce țin de mecanismul taxelor
(cote de TVA, acciză), conturi folosite contextual pentru notele contabile în funcție
de acțiunea economică înregistrată, moduri de listare în jurnalele de
cumpărări/vânzări, interogări complexe (rapoarte) ce țin de întrebarea care ar fi
soldul terţului X în raport cu mine în condiţiile în care el este şi furnizor şi client ?
Pagina 77/142
O să spuneți că amestec lucrurile şi nu respect principiile contabile, că 4111 şi

4011/4041 sunt “mâncăruri diferite” dar în realitate eu ca director economic ar trebui
să am şi o Fişă a Terţului finală.
Referitor la fişa Terţului: puţine ERP-uri au așa ceva (să nu zic că de fapt nimeni nu
are) şi aceasta trebuie construită în generatorul de rapoarte al ERP-ului [dacă el
există şi e bun de ceva] sau afară prin extragere prin ODBC sau alte API-uri.
A2.) Ce se întâmplă dacă un salariat nu este înregistrat într-un singur nomenclator
de salariați unic pe aplicaţia ERP astfel încât în orice modul as fi (Obinv43., Mfixe44.,
Salarii, Deconturi, Debitori diverși) eu să pot interoga care este situația acelui
salariat în raport cu obiectele de inventar, mijloacele fixe, debite existente (a spart
geamul de la etajul 3 sau a delapidat din gestiune sau nu depune banii din
încasări…), deconturi neînchise, salarii cuvenite sau neridicate, proiecte în lucru,
Purchasing (PO/buyer), utilizator aplicaţie etc ….Dacă în toate aceste cazuri eu
trebuie să definesc în acel ERP renumit salariatul ba ca marcă sau şi ca CNP în
fiecare modul după “cum bate vântul” atunci cu siguranță acela [este cel mai bun
ERP din lume…] şi trebuie neapărat sa îl cumpar.
13. Structura de nomenclatoare de bază ale unui sistem ERP (Master

data). Alte setări necesare.
13.1. Exemple c u eleme nte şi atrib ute comune mai multor ERP
Vom enumera doar câteva atribute f. importante de la câteva nomenclatoare pe care le

regăsim sub o formă sau alta în mai multe ERP-uri consacrate atât în US cât şi în Europa.
Aceasta denotă o relativă abordare comună a diverșilor producători pentru acel
nomenclator. Motivele ar fi urmatoarele:
- Specificațiile de proiectare iniţiale din 1970-1980 au fost relativ comune deși la
vremea respectivă nu existau Standarde în domeniu cu excepția recomandărilor
APICS sau a studiilor de la unele universități;
- Oameni de bază în general proiectanţi sau arhitecţi de aplicaţie sau chiar
programatori experimentaţi au migrat de la un producător la altul.
43
OBINV = Prescurtare pentru modulele ce gestionează Obiectele de inventar în depozit sau în folosință indiferent
dacă sunt în bilanț sau în afara bilanțului.
44
MFIXE = ne referim la modulul de mijloace fixe din ERP care trebuie să permită gestionarea simultană a numerelor de
inventar pe mărci (salariați), locații (secții, birouri) si regimuri de amortizare (liniară la noi).
Pagina 78/142
1. Nomenclatorul de articole de stoc

Codul_de_articol sau part_id sau part_number – este un identificator unic în ERP pe
tabela de articole de stoc. Este un fel de CNP al articolului prin care acesta se identifică
apoi în toate celelalte tabele importante:
tabela_de_tranzacţii_de_stoc, tabelele_de_recepptii_furnizor,
tabelele_de_vinzari_la_client, tabelele_de_structuri_BOM_WO.
Descriere1, Descriere2 – sunt câmpuri alfanumerice prin care noi numim exact articolul
respectiv. Se poate scrie orice în acele câmpuri dar noi avem obligația de a scrie exact
denumirea oficială a acelui articol de stoc aprovizionat, vândut sau produs de firma
noastră.
TIP_articol – este primul indicator de departajare care poate avea markerul
A=Aprovizionat, V=Vândut, P=Produs – are o f. mare importanță în legatura sau restricțiile
din modulele de recepţii sau producţie sau vânzări.
Planificabil_DA_NU = atribut (Yes/No) care indică dacă articolul va fi luat în calcul de
funcțiile de Planificare şi mai ales de procesele MRP în stabilirea necesarului de
aprovizionat.
DATA_stop sau ACTIV_Status = sunt două câmpuri care indică data contabilă
(accounting_date and NOT transaction_date ) la care articolul nu mai poate fi folosit în
module. În unele ERP DATA_stop este validată cu data serverului respectiv
transaction_date şi nu cu data_contabilă (data înregistrării documentului în patrimoniu).
CONT_master_folosit = simplist vorbind unele ERP permit să scrieți aici direct contul
principal al articolului cum ar fi: 3011, 345, 341, 303 etc… de aici se divid mai multe
variante cu tratament diferit în funcție de ERP:
a.) În unele ERP avem o așa zisă machetă de stoc>contabilitate unde pentru fiecare
acţiune importantă a acelui articol desi el a fost definit ca 3011 sau 345 în
nomenclatorul de articole, el să poată fi folosit contextual când își schimbă starea,
când trece dintr-o magazie în alta sau ce conturi de descărcare de gestiune se vor
folosi dacă el este marfa sau finit sau ce conturi vom folosi pentru el dacă cumva
devine obiect de inventar în folosință sau devine rebut sau devine marfă ș.a.m.d.
Pentru toate aceste cazuri unele ERP oferă o machetă specială de setări în care
este indicat contul principal şi apoi conturi specifice contextului folosirii acelui
articol. Dacă articolul își schimbă starea din material sau din finit/semifabricat este
transferat la obiecte de inventar în magazie şi apoi pe răspândiri este dat pe marcă
atunci el automat conform setării existente în machetă se va schimba prin nota
Pagina 79/142
contabilă 303 = 345. Dacă o materie prima devine marfa şi este vânduta, macheta
ne permite sa facem asta: 371 = 3011
b.) Alte ERP-uri au asociat contul la nivel de definire acțiuni per documente iar
fiecare acțiune în parte are propria ei machetă contabilă. Setarea permite
combinații de atribute contextuale pentru cel puţin următoarele:
ID_articol_folosit + magazie_de_intrare + acțiune_pe_document [transfer, recepţie,
vânzare, retur, consum, etc…]
Cod_EAN și COD_nc8 și/sau comodity_code = sunt trei câmpuri/atribute separate

fiecare cu implicația lui în comportamentul articolului în fluxurile aplicației.
EAN se refera la identificarea EAN a acelui articol în standardele internaționale de comert.
Este cel care este folosit și la identificarea prin codurile de bare de obicei.
COD_nc8 și/sau comodity_code = sunt două câmpuri separate care identifică exact
codul NC8 (combined nomenclature) în comerțul intrastat UE sau codul vamal specific.
2. Nomenclatorul planul de conturi = acesta trebuie să conțină cel puțin atributele:

- Tipul de cont (activ/pasiv/bifuncțional)
- Dacă este de tip cheltuială sau venit (6 sau 7 în România)
- Dacă este un cont master (sintetic conform plan Mfinanțe) sau e un analitic specific
firmei. Dacă e un analitic trebuie indicat părintele său.
- Dacă lucrează doar în moneda de bază a firmei/statului (lei) sau este definit special
în alte monezi și apelează la conversii.
3. Nomenclatoare de Clienţi şi Furnizori. Fiind f. similare numai sensul diferă.

Acestea ar trebui să conțină cel puțin:
- Id-ul unic care în România ar trebui sa fie chiar codul fiscal fară RO al acelui terț;
- ȚARA terțului: [RO,DE,FR,BG,US,TR,GB…] – foarte important pentru generarea
declarațiilor D394, Saf-T/D406, D390, Intrastat, valute/curs valutar și DVI, jurnale
Vânzări/Cumpărări;
- Câmpurile de adresă specifice la mai toate ERP-urile (strada, oras, judet etc..);
- Codurile de CUI și J/Registrul comerțului pentru marcarea documentelor (facturi
și avize la clienti în special) și pentru declarații (D394 și SAF-T/D406);
- Contul principal contabil pe care se desfășoară preponderent activitatea cu
posibilitatea de reîncadrare le nivel de document: 4011 (de ex.) să poată fi
Pagina 80/142
reîncadrat în 404 în cazul cumpărării de mijloace fixe de la același furnizor de la

care cumpărăm de obicei castraveți;
- Contul bancar (IBAN) și banca cel mai des folosite (pot fi și altele asociate);
- Teremene scadente sau zile scadente specifice acelui terț care pot fi reîncadrate
în cazul unei facturări / emitere de document contextuală /specifică (cu alt termen);
- Stare blocaj pe tipuri de documente Yes/No pentru a restricționa generarea de
documente pentru clienți/furnizori cu probleme la plată;
- Limite de credit (pentru clienți de obicei);
4. Nomenclatoarele de TAXE numite şi nomenclatoare GTM

Sunt niste nomenclatoare speciale care funcționează în tandem pentru a facilita
funcționarea operațională a tuturor clienților și furnizorilor (terții de mai sus).
Aceste nomenclatoare conțin :
- Toate cotele de TVA folosite pentru firma atât cele de la cumpărare (furnizori) cât
și cele de la livrare (clienți) precum 0, 5, 9, 19 etc…valabile în Romania pe o
perioadă fiecare cu valabilitatea ei astfel încât când se trece la o nouă cotă de TVA
cota veche (19%) să fie inhibată cu 31-12-2021 și să poată fi folosită cota nouă de
(24%) începând cu 01-01-2022 de exemplu.
- Toate combinațiile /excepțiile posibile necesare deductibilitații taxei cum ar fi
bonuri de benzină nedeductibile, bonuri fiscale de natura facturilor simplificate
(5,9,19)
- Combinațiile pe surse și destinații interne sau externe țării (export/import) ce
țin de spațiul european cu taxare inversă (AIC/LIC) sau exportul/importul în spațiul
non-UE ce se fac prin DVI/DVE
- Țările – teoretic aici sunt toate țările de pe glob [RO,DE,FR,BG,US,TR,GB…] cu
marcajul necesar de UE / NON-UE pentru a fi recunoscute în tranzacțiile cu
taxe/TVA
Pagina 81/142
13.2. Setări combi nate între nome nclatoarele importa nte pe bază
de reguli context uale
Nomenclatoarele de TAXE (GTM) în combinație cu Nomenclatoarele de Clienți și
Furnizori la care se adaugă nomenclatoarele de Articole și/sau Prestații reperezintă
baza setărilor necesare care se efectuează prin intermediul unor alte tabelele speciale de
regului ce dau comportamentul contextual al funcționării și calculului punctual (cotextual)
al cotelor de TVA (și alte taxe) la nivel de linie de document (factura fiscală de
vânzare/cumpărare Ap/AR invoice ). Combinațiile posibile stabilite pa baza acestor reguli
se fac de obicei pe combinațiile de mai jos:
- Heder (antet) factură : cod_client/furnizor (cui) / cod_ship_from/ship_to (livreaza la)/
country (țara)/cota_tva
- La nivel de linie document (invoice line):
cod_client/cod_articol_stoc/cod_prestatie/cota_tva
Aceste combinații de nomenclatoare + reguli permit setarea comportamentului
aplicației ERP și pentru:
a.) Stabilirea conturilor contabile asociate momentului generării taxei (TVA) cum ar
fi: [4426/4427/4428]
b.) Stabilirea modului de calcul al TVA = varianta clasică în care se calculează
procentul [%] aplicat bazei impozabile sau varianta 2 numită [procent din care]
așa cum se făcea acum 20 de ani la chitanța fiscală. Exemplu model chitanță
fiscală cu calcul [din care]. Total valoric inclusiv TVA = 100 ; tva 19% din 100
astfel :
Total document cu TVA: 100
Cota deducere 1,19
Bază farăTVA 84,0336
Tva [din care] 15,9664
c.) Daca este sau nu tip de tranzacție cu taxare inversă sau normală sau e cu Tva
la plată:
Adică dacă avem 4426 = 401 și 411 = 4427
Sau e 4426 = 4427
Sau e 4428 = 401 / 411 = 4428
d.) Stabilirea poziției în coloana specifică Jurnalului de Cumpărări sau al
Jurnalului de Vânzari. Aici se stabilește exact numărul coloanei corespondente.
După cum se știe începând cu anul 2007 odată cu intrarea în UE jurnalele de
Vânzări și cumpărări nu mai au 10 coloane ca pe vremuri ci pot avea 20-30 de
coloane care să cuprindă toate tipurile de bază+TVA în funcție de complexitatea
activității. Fiecare din aceste coloane are un număr de la 1 la 30 să zicem. În
fișierul de combinații/setări/reguli TVA vom indica cărei coloane și cărui jurnal îi
aparține acea combinație de taxe [TVA]
Am întâlnit în practică cel puțin două ERP-uri importante care au aceste
mecanisme de mai sus incluse de mai mult de 20 de ani (fiecare cu nuanțele
lui). Asta însemnă că s-a mers pe o abordare aproximativ similară.
Pagina 82/142
14. Implementarea unei aplicații ERP în România. Câteva repere

Un șef de proiect (sau similar) care nu a făcut ucenicie ca simplu implementator de cel
puțin 2 ani pe o aplicație ERP unde 2 ani este insuficient pentru a înțelege măcar parțial
aplicația, NU poate face față la un proiect nou. Un șef de proiect trebuie să aibă minim 2
implementări parțiale/complete ca implementator și nu ca șef înainte de a deveni șef.
Toate lacunele (lipsa de experiență) ale unui implementator sau șef sunt transferate către
ceilalți mebrii ai echipei de implementare și încarcă excesiv pe cei mai buni membri ai
echipei și generează insuccesul acelui proiect.
Premisele de la care pornim sunt: Sunt un absolvent de matematică-informatică,

automatică sau cibernetică (mai rar), “am geacă și blugi, olecuță de bătaie stiu, deci hai la
București45”…adică în limbaj ERP-ist “ești băgat la înaintare” ca un simplu implementator
de modul sau ai fost făcut direct șef de proiect de implementare sau analist de
business (ca să dai soluții) sau altă titulatură pompoasă cum ar fi [Project manager].
Pentru a implementa o aplicație ERP și sărind peste faza cu omul de la vânzări care l-a
păcălit deja pe clientul patron spunâd că aplicația lui face de toate, rămâne ca tu
implementator să dai drumul la proiect în curtea patronului.
Calitățile/competențele sau părțile “nasoale” ce te privesc direct în această implementare
sunt:
1. Nu cunoști complet aplicația și aici vorbim măcar de bazele funcționale ale sub-
modulelor importante: recepții/PO/Ap, livrări/facturare/SO/AR, producție/WO. Nu am
enumerat aici și încasările și plățile (chiar dacă americanii le bagă la AP/AR) și nici
formarea notelor contabile din module [nota contabilă SLA - sub-ledger] sau
[nepostatele] în limbaj românesc și jurnalizarea lor finală GL adică [postatele].
2. Nu cunoști nici măcar funcționalitatea unui modul cap-coadă măcar din
folclorul economic preluat poate de pe unde ai lucrat înainte: pe la aprovizionare,
vânzări sau într-o secție de producție sau depozit și ulterior ai făcut saltul
profesional la ERP ? Sau poate ai fost secretară sau consilier pe la vreun șef?
Aici ai o scăpare: dacă te fac ăia director de departament ERP direct fară să treci
prin implementator sau măcar șef de echipă [manager sau team leader] atunci ai
scăpat și vina insuccesului va cădea pe implementatori fiindcă tu ai fost la cele
1000 de ședinte din care nimeni nu a priceput nimic…nu? Sau poate ești o
45
[…am geacă și blugi, olecuță de bătaie stiu, deci hai la București....]= Expresie colocvială informală folosită curent în
anii industrializării 70-80 când toți specialiștii de la ASE si Politehnică doreau repartiție în București.
Pagina 83/142
absolventă de portugheză și proiectul e patronat de niște tipi din Portugalia și

Brazilia deci e domeniul tau?
3. Ai în schimb tot felul de diplome și cursuri care certifică că nici nu bănuim noi la
câte te pricepi tu.
4. Cunoști în schimb pe de rost (ca un papagal) meniurile aplicatiei Erp ce o
implementezi fiindcă mentorul tău a avut răbdarea să-ți enumere aceste meniuri și
apoi ți-a pus în brațe niște documente interne scrise de alți colegi în trecut pe
care să le citești și “să te descurci în viață”. Apropo, de obicei colegii ăia de au scris
documentele sunt în Canada parcă acum?!
Tehnic vorbind după semnarea contractului se trece la implementare cam așa:
1. Se face o instalare a aplicației ERP pe serverele beneficiarului cu o bază de
date de test fiindcă urmează școlarizarea utilizatorilor. Baza de date e goală
(empty) în cele mai multe cazuri și nu vine cu setarile necesare adică să pornești și
tu de la ceva încolo. O iei de la zero. Este o bază mută, slută, surdă și urâtă la care
tu vei interveni la fiecare ecran/funcție de tip setare sau de tip nomenclator.
2. O iei de la capăt cu fiecare implementare adică tu bagi nomenclatoarele
importante: clienți, furnizori, nom. de articole de stoc, planul de conturi, salariații,
nom. de mijloace fixe, centre de cost (ca să îți iasă și un postcalcul și să meargă
eventual și producția) și multe alte setări specifice ERP-ului în ansamblu sau
specifice fiecărui modul.
3. Dacă clientul de Erp (beneficiarul proiectului) este mare și de obicei este mare,
apar discuții despre cum să preiei soldurile și rulajele atât contabil (conturi)
cât și operațional respectiv încărcarea magaziilor de stocuri, facturi furnizor în sold,
facturi client în sold (depinde în ce lună startezi proiectul). Recomandat este să se
pornească întotdeauna cu 01 ianuarie al anului imediat (următor) finalizării etapei
de școlarizare> dacă ai făcut scolarizare pe o bază de test în anul 2021 și s-au
semnat testele de acceptanță adică beneficiarul a fost de acord cu aplicația
fiindcă întrunește cerințele legislative și de business atunci treci pe real la
01.01.2022 de exemplu. O altă variantă este să se înceapă la 30.06.2022 dar aici
trebuie să bagi rulajele contabile pentru 01.01.2022 la 30.06.2022. Un start pierdut
sau amânat pe real al aplicației în anul următor școlarizării duce la RATAREA
PROIECTULUI deoarece oamenii uită ce au învățat la școlarizare, KEY-useri
importanți care au priceput ceva din ERP-ul tău pleacă la altă multinațională și cel
mai grav este că clienților “le vin idei” adică se deșteaptă f. mult în timpul
școlarizării și văd infirmitățile aplicației tale. Asta însemnă că dacă startul de
Pagina 84/142
01.01.2022 se amână la 01.01.2023 atunci tot anul 2022 vei repeta școlarizarea și
clientul va veni cu noi cerințe ce vor modifica costurile proiectului.
Și acum având toate cele 4 “calități” de mai sus ești trimis la “înaintare” [așa zicea un
mentor din Pitești cândva pe care nu îl numesc aici ca să nu se supere ceilalți mentori]
unde te întâlnești cu următoarele situații descrise mai jos.
1. Situație negativă: Doamna contabilă șefă care apare f.f. târziu în filmul
evenimentelor implementării fiindcă până atunci toată lumea l-a vrăjit doar pe patron
între două deplasări ale acestuia prin țară sau străinătate va întreba câte ceva despre
documentele obligatorii conform ANAF46:
- Balanța mea cu 4,5 sau 6 egalități din CIEL/SAGA sau Winmentor sau aia făcută la
oficiul de calcul de dl.Gogu acu’ 20 de ani unde se regăsește ?
- Nirul sau un simulacru al acestuia pe unde este ?
- Dar Registrul Jurnal General, Fișa de Cont și Fișa de Operații diverse?
- De ce avem tranzacții (note contabile) în 01.01.1900 sau în 31.12.2200?
Ne vom uita în stânga și în dreapta, vom da niște telefoane și între timp poate suntem
chiar concediați sau în cel mai bun caz suntem “retrogradați“ sau penalizați la salariu
că am cutezat să punem în discuție documentele operative și financiar contabile
obligatorii cerute de dna. Contabil Șef.
Nu mai discutăm de obligativitățile rezultate din alte acte normative ce privesc Jurnalul
de Vânzări, Jurnalul de Cumpărări, Jurnalul de Cumpărări tip Tva la plată (Tva la
încasare) și declarația D394. Vom da și pentru acestea niște telefoane, vom face
niște ședințe cu clientul…. în care tu implementator nu știi “pe unde să scoți cămașa”.
Ar mai fi câteva întrebări despre avizele de marfă inter depozite aflate în localitați diferite,
contul 4811 în așteptare, transferul prețului de stoc din depozitul A în B dar mă abțin și
consider că nu o să vă întrebe nimeni despre asta.
Apropo de întrebări în timpul școlarizării – parcă am văzut undeva funcția de reevaluare a
facturilor furnizor/client în sold emise în USD/EUR ?
46
Documente financiar-contabile obligatorii conform ORDIN Nr. 2634/2015 din 5 noiembrie 2015 și ORDIN nr. 3.512
din 27 noiembrie 2008 în care regăsim și formatul cerut al acestora
Pagina 85/142
2. Situație Pozitivă: Spre sfârșitul școlarizării când mai toți userii de la toate
modulele au făcut câteva teste cu documentele operative specifice modulului lor
apar și situațiile pozitive:
După ce toată lumea a băgat câteva facturi de furnizor, s-au emis câteva facturi de
vânzare, s-au făcut recepții (NIR cu fară DVI), s-au făcut câteva transferuri inter
depozite pe bază de aviz, s-au făcut structuri de produse+tehnologii și s-au și lansat
câteva comenzi de producție (WO), s-a și consumat ceva pe ele (WIP) și poate le-ați și
închis, s-au făcut încasări și plăți atât din CASA Lei cât și din câteva IBAN-uri (BCR
Cont curent LEI ARAD de exemplu) pentru încasarea sau plata unor facturi și poate
am făcut și câteva deconturi cu salariații atunci scandalul este maxim.
Adică toată lumea e disperată acum că:
- ba nu își găsește documentul introdus,
- ba documentul are cantități sau valori inexacte că a bătut virgulă în loc de punct
(10000 lei /zecemii în loc de zece 10,000 ???)
- ba conturile de stoc din conta sunt aiurea setate și marfa în loc de 371 s-a dus în
308 dar noi nu avem adaos comercial că nu suntem butic?
- ba nota de taxare inversă 4426 = 4427 arată 4111= 4427 ???
- ba factura de transport s-a dus pe variații în loc să se ducă pe stoc, în DVI se
vede doar factura de marfă dar lipsesc taxele vamale,
- contul 4811 din transferuri e mereu închis când el trebuia să prezinte sold că doar
avem mereu avize pe drum nerecepționate la destinație (marfă pe drum);
- fișa de magazie arată stoc inițial -153 (minus unasutacincizecisitrei) la toate
șuruburile M6, M10 , M24 de exemplu,
- ba de ce în balanța de stoc am stoc final cantitativ pozitiv și valoare (sold final)
negativ la 200 de poziții de șuruburi diferite?
Când toată lumea e disperată punând întrebările de mai sus și tu te ascunzi ba pe
la secretariat (ca te-ai împrietenit cu secretara) ba te faci bolnav în camera de hotel
sau pur și simplu îți închizi telefonu’ care sună într-una iată că apar și situații
fericite:
Știți cine sunt primii fericiți după implementatrea noului ERP ?
Sunt băieții de la proiectare, producție, aprovizionare și cei de la desfacere (ăia
de fac comenzi seara după ora 19:00 și fură/blochează cantitățile noaptea de nu
poate facturista să factureze dimineața la 4:00 când trebuie să iasă pe poartă la
client camionul cu: pâine, lapte, bere sau înghețată ….)
Pagina 86/142
De ce sunt ei fericiți ? Explic pentru toți de mai sus la pachet câteva beneficii
apărute. Iată motivele faptului că acești utilizatori sunt mulțumiți, mai jos.
Pentru că odată cu școlarizarea și implementarea noului ERP s-au întâmplat
următoarele:
- Nomenclatorul de articole este unic în aplicație și nu își mai bagă nimeni mâna
aiurea să definească ceva decât după ce au primit niște aprobări. Până acum
nomenclatorul de articole mergea pe descriere și [Pătura maro de lână 90x220] sau
[Șuba portar albastră cu glugă] putea să scrie toată lumea în 10 exceluri și alte 3
aplicații disparate de 5 ori fiecare pe limba lui.
- listele de prețuri de la vânzări sunt unice și nu ne mai încurcăm când facem o
cotație la client, când facem o livrare/factură inclusiv rabaturile și discounturile
specifice clienților pe tipuri de clienți (ABC de ex.) sau când facem o comparație de
costuri versus prețuri pe istoric ….
- Listele de preț de furnizor sunt controlabile și nu mai apar confuzii de preț pentru
furnizorii mari și mai avem și istoric pentru analize.
- Există control al datei scadente atât pe factura/comanda de furnizor cât și pe
comanda /factura de client precum și pe comenzile de producție.
- Dacă Nu există cantitate raportată (produsă) de produs finit prin producție [WO] și
transferată apoi la desfacere atunci nici cei de la desfacere nu pot livra/factura
fiindcă stocul e 0 sau insuficient….
- Plățile nu se pot face fară existența Facturii de furnizor iar încasările nu se pot
face fără existența facturii emise la client pentru a-și calcula agenții de vânzări
comisioanele pentru facturile emise și încasate s.a.m.d…
Toate acestea de mai sus îi fac pe cei de la [proiectare, producție, aprovizionare

și cei de la desfacere] fericiți și se vor duce la patron și îi vor spune că totuși
aplicația ERP cumparată are și părți bune…
Pagina 87/142
15. Modulul de Postcalcul şi ERP-ul
15.1. Despre Postcalculația costurilor – g eneralităţi. Ex istă sau nu

în ERP noțiunea de postcalcul?.
Probabil că noțiunea de postcalculație există doar în aplicațiile dezvoltate de programatorii

francezi pentru piața de aplicații informatice din Franța + țările francofoniei. Și aici ne
referim direct la folosirea conturilor de gestiune internă (analitice de gestiune spun ei) de
clasă 9 în contabilitatea franceză pentru anumite firme din industrie de obicei, simultan cu
tranzacțiile din conturile bilanțiere (clasele 1-7).
În Franța conturile de clasa 9 din care ne-am inspirat și noi (când dl. Feleagă a adus
lumina de la Paris în 1994) ne spun cam așa:
[....Analiza veniturilor și cheltuielilor în funcție de destinație (către ce serviciu al companiei sau către ce
produs este destinată cheltuiala?) Și nu după natura cheltuielii. Scopul ar fi ca să vă permită să aflați unde
este creată marja companiei (adică un fel de profit real în limitele căruia putem jongla în sus/jos). Utilizarea
clasei 9 nu este obligatorie (nici în Franța și nici în Romania), este recomandată; contabilitatea costurilor
fiind complexă și costisitoare, se găsește mai ales în sectoarele cu procese economice complexe, cum ar fi
industria, distribuția în masă....]
15.2. Ce găsim azi î n ERP- uri pe ntru calculația costurilor ?

În ERP-urile care au modul specializat de urmărire a producției (WO) pe comandă/loturi și
discretă (parts manufacturing) găsim următoarele activități și elemente de calculație și
colectare a costurilor:
1. Spargerea elementelor de cost la nivel de finit/semifabricat pentru Coamanda,
produsul și/sau id_ul comenzii lansate pe cel puțin 5 elemente:
a. Material – aici intră toate materiile prime și materialele ce se vor consuma
conform BOM pe acel finit (lavete, șuruburi, diluant, etichete) – este elementul
de cost utilizat 100% de către toți clienții de Erp,
b. Manopera – cunoscută ca și Labour respectiv costul cu salariile directe [direct
labor costs],
c. Subcontract – se referă la costurile cu subcontractorii externi (sablare, bronare,
cromare sau alte acoperiri galvanice de exemplu).
d. Burden – ar fi echivalentul regiei nr. 1 de secție în care s-ar include regii
indirecte de nivelul 1 (variabile) în funcție de material+manoperă,
e. Overhead – ar fi echivalentul regiei nr. 2 sau CGI (cheltuieli generale de
intreprindere),
Pagina 88/142
Dacă [a+b+c] sunt relativ clare ca noțiune și utilizare, [d+e] care ar fi echivalentul
regiilor cu implicații contextuale în politica de costuri a firmei trebuiesc discutate și
stabilite punctual cu contabilul șef/director economic în funcție de structura
costurilor indirecte variabile și fixe ale fiecărei firme la startarea modulului de
producție (WO).
2. Coamanda, produsul și/sau id_ul comenzii lansate. De obicei acesta este un id-
unic (un fel de CNP) al semifabricatului sau al finitului care se va produce în 1-1000
sau “n” bucăți în unul sau mai multe loturi de obicei în cadrul aceleiași luni
financiare. Sunt cazuri de produse lansate în luna X dar raporate și în luna x+1. În
exemplul de mai jos vom folosi finitul cu id_inic [CNP]
(cutie_viteze_Mercedes_SL200).
Acest id-unic (CNP de lansare) va colecta pe o periodadă determinată de viață a
comenzii (până la închiderea comenzii) toate resursele raportate (consumate pe
acel finit): materiile prime+materiale+ore manoperă/salarii+ore_utilaj etc…Toate
aceste resurse sunt raportate automat sau manual de operatorii aflați în producție
prin ecranele de raportare ale aplicației sau în alte aplicații externe (bar code
scanere sau alte dispozitive ce transmit informații din fluxul de producție către acel
ERP).
Toate cheltuielile de mai sus sunt f. precise atât ca volum/valoare/cantitate cât și ca
dată efectivă ce va fi înregistrată și în contabilitate. Astea sunt chiar tranzacții pe
care le putem numi oficial ca tranzacții în timp real.
Majoritatea tranzacțiilor de mai sus au următorul corespondent în clasele 6/3 în
contabilitate [6xxx= 3xxx] (sau orice echivalent de cheltuială din secție per produs)
Numai că aceste cheltuieli nu sunt suficiente pentru a calcula costul complet pe
următoarea combinație: produs_finit_semifabricat/secție/perioadă. Ele oferă doar o
imagine parțială a structurii costului per finit/lună/secție.
Acestea sunt doar cheltuielile directe cu materii prime + o_cotă_utilaj_prestabilită +
o_cotă_prestabilită_de_regie_secție. Toate acestea există dacă au fost definite în
structura de cost și tehnologia de calculatie a acelui finit atunci cănd s-a făcut
47
cost_roll_up_ul pentru acel finit/semifabricat. Deci costul se oprește undeva să
47
COST ROLLUP = funcție specializată în ERP de calculație a costurilor pe structura BOM pentru un produs finit pentru
toată cascada părinte-fiu pe mai multe niveluri. Este o determinare a tuturor elementelor de cost în cadrul costului total
per finit. Calculul acesta al costurilor (COST ROLLUP) vă permite, în mod normal, dar nu întotdeauna, disecția costurilor
în funcție de material pe un lanț în care este utilizat ca componentă individuală + forța de muncă operațională și
cheltuielile generale aplicate. Componentele de bază sunt structurate pe cel puțin 5 componente în funcție de ERP
[material, salarii, overhead (regie2), burden (regie1), colaborări (externe) ]. Funcția de cost rollup este echivalentă
exploziei de costuri pe BOM care se făcea la oficul de calcul acum 30 de ani.
Pagina 89/142
spunem la costul de secție fără a avea imaginea costului TOTAL cu toate regiile de
secție+CGI+desfacere. Acest cost este standard (antecalculat) si nu cel real
(postcalculat). În analize avem nevoie de costul POSTCALCULAT care se
colectează din bonuri de consum, manoperă/pontaje, facturi reparații, facturi utilități,
facturi servicii, amortizări etc….colecate pe luna financiară de calcul.
O altă problemă a acestui calcul este că depinde f. mult de momentul închiderii
comenzii principale lansate generând tranzacţii de tip WOCLOSE cu multe variații
(neaceptate în contabilitatea românească). Am menționat aici doar WO-close dar
ele sunt numeroase ca tip și număr și am hotărât să le prindem pe toate în
conceptul de “WO-close”.
Aceste variații țin de:
a.) Diferențele între cantitățile propuse pentru comanda respectivă și totalul
cantităților raportate pentru comanda respectivă. Adică comanda a fost definită
[creată] în 02.03.2021 cu o cantitate de 1200 de bucăți de
cutii_viteze_Mercedes_SL200 pentru toată luna martie 2021. În realitate s-au
produs trei loturi: 600 bucăți de [cutii_viteze_Mercedes_SL200] în 13.03.2021,
200 bucăți în 17.03.2021 și 175 de bucăți în 28.03.2021. Total cantități produse
pe comandă = 600+200+175 = 975 buc. [cutii_viteze_Mercedes_SL200]. De aici
rezultă că la momentul închiderii comenzii (există un buton special/meniu în mai
toate ERP-urile care face închidere a unei comenzi de producție WO) vor rezulta
automat note de diferențe pe (-225) bucați (1200-975).
b.) Tot atunci pe 28.03.2021 la închiderea comenzii vor apare și alte note generate
automat de program aferente diferențelor între cantitatea de materie primă
aferentă acelei comenzi conform BOM/tehnologie/cost_estimat la definirea
comenzii în 02.03.2021 și totalul cantitatilor raportate/consumate pînă la
28.03.2021 de la șuruburi la lavete și diluanți. Adică pe românește: ai prevăzut
pe consumul comenzii de 1200 bucați pentru [cutie_viteze_Mercedes_SL200]
aferentă martie 2021 100 de lavete, 50L diluant și 500 de șuruburi dar în urma
consumului efectiv (la raportarea producției) ai consumat 135 de lavete, 45L
diluant și 607 șuruburi vei avea note de variație pentru diferențele de +107
șuruburi, -5L diluant și +35 de lavete.
Pentru ca aceste note de variație (a+b) de mai sus să nu mai apară în

contabilitate la închiderea comenzilor, ERP-urile au găsit soluții de fugă
[găselnițe] de genul:
Pagina 90/142
- Inhibarea notelor de variații din procesul de producție prin bifa/buton/setare specială

- Generarea notelor pe alt registru contabil decât cel oficial sau generarea notelor pe
conturi în afara bilanțului (clasele 8/9)
Bineînțeles că există și un set de rapoarte în fiecare ERP prin care putem vedea situația
comparativă la nivel de comandă/produs pentru:
- Ce cantitate s-a comandat și ce cantitate s-a produs efectiv pentru acel produs?
- Ce ore/manoperă s-au raportat?
- Ce cantități de materii prime, materiale s-au consumat și care e diferența față de ce
ne-am propus?
- Rapoarte cu Diferențe și consumuri pe toate elementele de cost de mai sus
(material, manoperă, burden, overhead, sub-contractor).
Dar toate astea nu arată costul total real acumulat din toate cheltuielile ocazionate în
firmă în luna martie 2021. Ele reprezintă doar niște consumuri parțiale (incomplete) și
nicidecum costul TOTAL cu toate regiile repartizate la nivel de unitate de produs.
15.3. Progra mul de postcalcul ca aplicație externă ERP
Când discutăm despre postcalcul ca aplicație externă Erp ne vom referi întâi la activitatea
de producție și apoi la posibilitatea gestionării altor activități cum ar fi comerțul sau
activitatea de servicii cum ar fi închirierea spațiilor. Un program de postcalcul ar trebui
să fie adaptabil și pentru calculul costurilor activităților de Property Management respectiv
Facility Management specific închirierii de spații şi utilități dacă specificul firmei nu este
producția sau comerțul și este de exemplu închirierea de spații pentru biroruri sau
magazine.
Sfatul meu este:
Nu vă chinuiţi să căutaţi pe net (saituri web) sa faceți download la un program de
postcalcul "perfect" care să acopere specificul firmei dvs. Nu veți găsi așa ceva. Programul
de postcalcul este "capacul" care se pune pe o oală care fierbe în continuu. Capacul nu se
pune decât după ce am ales oala potrivită acelui capac (sau invers), am pregătit
ingredientele, am folosit rețeta cuvenită, avem aptitudinile unui bucătar, cunoaștem
intensitatea focului, cunoaștem câte ceva din tabieturile invitaților ce se vor așeza la masă,
știm când aceștia vor servi acel fel de mâncare s.a.m.d.
Nu uitați că: O treime (1/3) din munca de realizare a programului de postcalcul o veți face
dvs. împreună cu colegii dvs.! (Nu e de râs şi nici de mirare).
Pagina 91/142
Fară a avea intenția să fiu vulgar știm cu toții că toată lumea se pricepe la fotbal, politica
şi mașini, iar în zilele noastre toți informaticienii se pricep la FoxPro (sau mă rog se
pricepeau cândva ca acum toți știu Java) iar economiștii se pricep la Postcalcul (adică la
contabilitatea de gestiune şi calculația costurilor). Dacă firma e mică, calculația o face de
obicei patronul din condei în agenda personală ajutat uneori de doamna contabilă. Dacă
firma este mare iar produsele sunt multe, au structuri complicate, materiile prime variază
ca preț în funcție de furnizor, procesele tehnologice absorb multă regie invizibilă şi
necontrolabilă, atunci cu siguranță postcalculul se face într-un birou specializat unde
câteva contabile muncesc destul de anevoios între 10 şi 25 luna curentă pentru "a închide"
luna precedentă. Scopul muncii lor este de a comunica în final domnului director (sau
acționarului principal) cât ne costă în realitate 1 bucată de produs finit respectiv o sticlă de
bere, 1 Kg de vopsea, o sticlă de sana , un aragaz, o mașină de tuns iarba şi de ce nu un
vapor sau un avion?. Se fac calcule anevoioase din pix şi din excel şi se refac de mai
multe ori. Între timp mai apar facturi importante "uitate" într-un sertar şi refacem calculele.
Rezultatul apare târziu - uneori în cel mai fericit caz pe 25 luna următoare adică la multe
zile de la încheierea lunii de calcul. Între timp lumea se mișcă, furnizorii au modificat
prețurile iar o parte din clienţi nu mai vor să cumpere de la noi deoarece pot cumpăra de la
concurență mai ieftin sau clienţii "ne forțează mâna" să le mai dăm discounturi fiindcă altfel
nu mai cumpără de la noi.... Apare întrebarea legitimă a patronului: de ce oare se întâmplă
acestea?
Pentru a putea lua o decizie în timp optim asupra producţiei, postcalculul trebuie să ne
asigure informația postcalculată a prețului de producţie deci la costul real şi nu la cel
estimat-antecalculat . Această informație trebuie să fie calculată maxim pe data de 10
luna următoare lunii de calcul – așteptăm în principiu factura de lumină, gaz, apă, salariile
şi eventualele facturi de servicii/transport nesosite încă. Sunt unii viteji care promit că obțin
această informație consistentă mai devreme - mă îndoiesc.
În continuare apare priceperea şi dexteritatea personalului şi f. important: deținerea unei
aplicaţii integrate de tip ERP care să permită o trasabilitate a tranzacţiilor financiar
contabile a.î. acestea să poate fi agregate, ventilate şi grupate rapid pe criteriile de bază
pentru a identifica toate palierele de cost necesare analizelor (aici v-am pierdut nu-i
asa?).
Pagina 92/142
O completare la cele de mai sus facută de cineva în anul 2019 (pe net desigur) care ne
spune multe despre care ar fi interesul firmelor pentru postcalcul:
- 90% din firmele mari nu folosesc o aplicaţie de postcalcul ci folosesc diverse rapoarte
customizate în BI (sau similar) și fișiere exportate din aplicația ERP în excel ;
- foarte multe firme mari nu folosesc încă un sistem integrat de tip ERP sau chiar dacă au
un sistem ERP acesta nu oferă şi partea finală de închidere a contului 121, jurnalizarea
notelor contabile, carte mare , fişă șah s.a.m.d fiind obligate să închidă în clasicele SAGA,
CIEL, Winmentor.
- multe firme dețin în continuare 4-5 aplicaţii separate din care se "trag datele" pentru
obținerea situațiilor finale cum ar fi: program de mijloce fixe, program de salarii, program
de facturare, program separat de contabilitate, program de evidență stocuri.
Beneficiile unei aplicaţii de postcalcul independente şi obiective urmărite:
Indiferent dacă sunteți o firmă de prestări de servicii, comert sau de producţie principalul
beneficiu pe care îl veți avea dacă implementați o aplicaţie de postcalcul este că veți avea
datele contabile ordonate. În mod special veți avea cheltuielile + veniturile ordonate şi
ventilate pe purtători de cost: secții, centre de cost, produse, clienţi, paliere de cost
(respectiv regii 923,924, directe 921, aux. 922 sau desfacere/marketing 925). Veți vedea
profitul brut la nivel de unitate de produs ca diferență între total cheltuieli (921-925) și
prețul de vânzare cunoscut. Acesta e numit și marja pe americănește.
Pagina 93/142
16. Funcţionalităţi ce trebuie să existe în interiorul unui ERP în

varianta adaptată în conformitate cu legislaţia şi cu practica (cutuma)
managerială din România
Doriţi să vă cumpărati un ERP? - atunci să stiţi că un ERP costă mult (printre altele…)
Acestea sunt elementele de care trebuie să tineţi cont când întocmiţi un caiet de sarcini
sau participați la o prezentare de produs ERP cu adaptare la practica din România.
Dacă vei întreba pe stradă un contabil: Ce este acela un ERP? Ţi se va răspunde că este
un program de contabilitate cum ar fi CIEL, SAGA sau WinMentor.
La aceiaşi întrebare un inginer va spune că este o aplicaţie care trebuie neapărat să îi
rezolve lui producţia şi planificarea.
Un patron va răspunde că un ERP este acela care îi arată lui niște butoaie şi niște plăcinţi
(grafice) o dată la 3 luni când se mai uită prin aplicaţie.
Un director îţi va spune că un ERP este o aplicaţie care trebuie să facă de toate de la
recepţii, producţie, facturare şi că trebuie să țină mult, fară reparații (scalabilă) adică în
următorii 10 ani să nu aibă bătaie de cap cu ea indiferent ce se întamplă cu economia țării
sau tehnologia IT s.a.m.d.
Un om de la vânzări îți va spune că un ERP este chiar aplicaţia pe care el o vinde şi că
este cea mai ieftină din lume iar tu trebuie să o cumperi neaparat că te ajută în business şi
îți vei mări cifra de afaceri dacă o cumperi.
Un om de la IT îți va spune că un ERP este acea aplicaţie din cauza căreia el își va pierde
locul de muncă fiindcă i-a spus lui cineva că aplicaţia face de toate şi de el NU va mai fi
nevoie (același lucru pe care îl crede şi dl. Director).
16.1. Înainte de a cumpă ra un ERP ar treb ui să stiţi în primul râ nd

că:
0. Deși un ERP consacrat prin definiţie are ca fundament cel puţin o metodă sau
tehnică de management (cum ar fi MRP cu JIT, urmărirea pe comandă/produs,
Proiecte sau BUGET s.a.m.d) în Romania nu veți scăpa de contabilitate -
contabilitatea fiind principala metodă de conducere.
1. Contabilitatea din România este 100% soră cu contabilitatea aplicabilă în

FRANȚA cu diferența că fracenzii mai au 100 de analitice pe la cheltuieli pe care
noi nu le avem. Contabilitatea FRANCEZĂ este total diferită de contabilitatea anglo-
Pagina 94/142
saxona (GAAP). Planul contabil în Franța/România este reglementat prin lege şi

este actualizat și întreținut de Min. Finanțe prin norme de aplicare precise. De câte
ori apare o problemă nouă de atâtea ori se introduce un cont nou. Exemplu actual:
Prin OMFP nr. 2.844/2016 a fost introdus contul 463 „Creanțe reprezentând
dividende repartizate în cursul exercițiului financiar”, introducerea acestui cont a
fost însoțită de o serie de raportări asociate (formulare obligatorii – Bilanț și Anexe).
Pe românește ar fi că dacă firmei tale îi merge bine în cursul anului 2021 și tu
patron vrei să scoți 5000 de lei dividende în mai 2021 trebuie să folosești contul 463
și să dai toate raportările acelea complicate la ANAF, altfel scoți banii în februarie
2022. Planurile de conturi anglo-saxone nu există sub formă de listă ierahizată
reglementată de stat, sunt orientative. Firmele se aliniază la ele prin cutumă şi
principii. Identificarea contului se face de multe ori nu prin număr ci prin
denumirea care ne dă sensul (Gain and loss, expences, incomes, Fixed Asset
etc…)
Completare: La începutul anilor 90 dl. Feleagă împreună cu o delegaţie de la
Min.Finanțelor a plecat la Paris ca să aducă “lumina contabilă” şi așa s-a născut
Legea Contabilității (Cartea Verde) iar dl. Iorgovan tot de la Paris ne-a adus lumina
constituțională şi așa s-a născut Constituția din 1992. A fost o decizie corectă în
ambele cazuri. Nici teoretic și nici practic România anilor 90 nu putea adopta și
implementa în timp rezonabil alte modele.
2. Contabilitatea franceză pune pe primul loc statul şi pe locul doi

firma/managerul şi acționarii pe când contabilitatea anglo-saxonă (GAAP) are în
centru firma+acționarii şi necesitațile lor şi apoi statul şi fiscalitatea.
3. Principalul instrument/tehnică de management în firmele din Romania este
tehnica/metoda urmăririi contului contabil prin solduri şi componența de rulaje
spre deosebire de contabilitatea anglo-saxonă unde este urmărit soldul la data.
4. Balanţa contabilă GAAP (anglo-saxonă) este o balanţă de solduri cu 2 coloane
(sold iniţial – sold final) pe când balanţa franco-româna este o balanţă care are cel
puţin 8 coloane unde f. importante sunt coloanele de rulaj lună DEBIT/CREDIT şi
Total/SUME (rulaj cumulat). În contabilitatea anglo-saxonă GAAP nu exista
noțiunea de DEBIT=CREDIT pe o linie, conturile funcţionând independent în nota
contabilă mixtă N_DEBIT = X_Credit neputând să se facă împerecherea acestora.
Preponderent nota contabilă este spartă in linia 1 Debit si linia 2 Credit. Neavând
împerechere la nota contabilă atunci nici Registrul Jurnal General (ăla care trebuia
Pagina 95/142
șnuruit la Circa Financiară cândva) nu poate fi scos deoarece 401 nu știe cu cine a
lucrat iar 4111 se uită ca curca în lemne când caută pe 707,704,701 etc…
5. Contabilitatea franco-romană este o contabilitate a statului şi nu a
managerului acesta fiiind obligat să țină pentru stat contabilitatea financiar-fiscală
cu sute de conturi de cheltuieli şi venituri (cartea verde) şi apoi să transpună prin
postcalcul (să ventileze) aceste venituri şi cheltuieli către conturile de clasa 9 adică
către contabilitatea de gestiune pentru a vedea conturile de calculație şi purtătorii
de cost. Contabilul este un agent fiscal al statului platit de patron…
6. Finanțarea întreprinderilor în România este calată preponderent pe împrumutul
bancar (împrumut care se obține și f. greu!). Finanțarea în sistemul anglo-saxon
este bazat preponderent pe finanțarea bursireă (acțiuni/obligațiuni) și pe fonduri de
investiţii (indivizii investesc și finanțează direct alți indivizi).
7. Contabilitatea de gestiune (conturile de clasa 9) este opțională și recomandată la
noi și funcţionează în tandem cu contabilitatea financiară (clasa 6+7 în special). În
sistemul anglo-saxon nu există contabilitate paralelă de gestiune.
Alte câteva elemente ce diferențiază contabilitatea franco-română de cea

anglo-saxonă:
Prețul de stoc în România este 100% FIFO cu identificare specifică pe lot/preț
cu formarea prețului complet de aprovizionare (nu va gândiţi la stiva FIFO din
automatică că sunteți în eroare). Economia instabilă + inflația + cursul de schimb +
importurile masive au forțat existența acestei metode.
Prețul de stoc în SUA este 100% standard (ăla pe care îl folosim noi doar la finite)
cu actualizări periodice (lunare /anuale) datorită economiei stabile cu fluctuații mici.
Diferențele de pret (şi la ei există diferențe de pret) ajung direct în rezultatul
exerciţiului (121 la noi) prin cheltuială/venit fiindcă la ei se permite acest lucru – la
noi nu – diferențele de preț în România ajung întotdeauna în soldul stocului de
clasă_3: 308,378,348 etc.. şi apoi se descarcă doar când produsul a fost consumat
în producţie sau vândut (ești obligat să faci k la descărcare).
Instumentul managerial (sunt chiar tehnici de management în acest sens) în
contabilitatea anglo-saxonă sunt BUGETUL şi PROIECTUL (și COMANDA în cazul
producției) spre deosebire de România unde principalul instrument de conducere
este CONTUL CONTABIL şi comanda de fabricație şi apoi celelalte instrumente.
Registrul de casă/bancă la noi este un instrument de gestiune și control f.
important. Controlul delegaţiilor și al plăților directe din casă fiind f. mare în
Pagina 96/142
comparație cu modelele anglo-saxone (pentru analiza delegaţiilor ar trebui un

capitol separat să nu zic o carte separată).
16.2. Care s unt p unctele de care t rebuie să ținem co nt la alegerea

unui ERP:
1. Datele (NIR, facturi, transferuri etc…) se introduc în timp REAL simultan şi
concomitent de la mai multe puncte de lucru aflate la distanță. Datele sunt scrise
instant în baza de date unică. Ceilalti utilizatori beneficiază imediat de: balanţe,
solduri, fișe cont, stocuri on-hand, contabilitate. Nu mai sunt necesare alte
prelucrări periodice suplimentare off-line/on-line sau de preluare a tranzacţiilor
distribuite sau rularea de joburi manuale sau în batch.
2. Formarea costului complet la aprovizionare pe metoda FIFO prin alocarea
costurilor suplimentare simultan pe stoc şi contabilitate (contul de clasa 3x trebuie
să bată ca sold şi rulaj cu valoarea articolelor din magaziile afectate).
- se alocă costuri din facturi de servicii diverse şi facturi de transport,
- se alocă costuri din DVI (taxe vamale + comision),
- se formează automat factura /obligația de vamă ce conține TVA vamă + taxe
vamale.
Efectul este urmatorul:
- Recepţiile din NIRURI sunt blocate şi așteaptă a fi completate cu toate costurile
suplimentare,
- Consumul nu se poate face pâna când costul nu este complet – aici intervine
maiestria ERP-ului să permită consumul la costul de AVIZ (minim) dacă factura
înca nu a venit.
- Se așteaptă confirmarea recepţiei,
- Valoarea de încărcare a stocului /magazie/articol (cont clasa 3 ) este la cost
complet şi este identică cu suma din contabilitate pe conturile sursa 401x (mai
puţin TVA 4426)
- Orice Articol de stoc aprovizionat încărcat la cost complet traversează patrimoniu
la acest cost prin consum, transfer, producţie, vânzare, retur (RMA) etc.
EFECTE:
- Balanţa contabilă pe cont (301…345…381) bate cu balanţa de stoc pe
magazine/cont/articol (în cutumă se spune ca analiticul să bată cu sinteticul);
- nu există stocuri cu cantitate = 0 şi valoare (+/-)
Pagina 97/142
3. AVIZE la Transfer de stocuri/marfă către punctele de lucru prin funcţionalitate de

tipul: AVIZE către punctele de lucru proprii pentru controlul stocurilor şi avizelor la
transfer către punctele de lucru.
Modulul trebuie însoțit de:
- posibilitatea evidențierii mărfii aflate în tranzit (cont 481-482) şi blocării stocului la
destinatar până la confirmarea recepţiei la destinatar. Contul 481x trebuie să
prezinte sold dacă marfa a plecat din filiala noastra din Port Constanța dar nu a fost
recepţionata încă la Cluj.
- Confirmare recepţie la primire (cu evidențiere diferențe)
- Listare AVIZ la transfer
- Listare NIR din transfer
4. AVIZE către clienţi altele decât punctele de lucru la livrare cu factură
ulterioară
Acest tip de operare a livrărilor are o utilizare mare în practica livrărilor către supermaket-
uri gen Carrefour / Metro / Lidl/ Brico/Leroy unde facem lunar 5-10 avize şi apoi le
închidem la sfârșitul lunii într-o singură factură ce va cumula avizele menționate. Contul
418 va conține sold corespunzător avizelor nefacturate.
Funcții: Comandă+listare AVIZ+facturare ulterioară finală
5. Facturare. Mecanisme de facturare care să cuprindă cel puţin:

 Emiterea/listarea fizică a facturii la imprimantă;
 Gestionarea clienţilor pe puncte de lucru chiar dacă avem un singur cod fiscal cu
sediul în București dar mai multe puncte de livrare (cazul Metro de ex.)
 Gestionarea unor plaje multiple de numere facturi şi avize / per user / per punct de
lucru
 Gestionare liste de PREȚ active pe client/articol etc.
 Gestionare prestații specifice facturabile distinct sau împreună cu articole de stoc
(taxa încărcare, taxă manipulare, taxă ambalare, taxă cântărire, taxă spalare)
 Liste sau metode de acordare a discount-urilor global pe client/articol sau punctual
pe factură
 Stornare facturi cu identificare factură iniţială sau fară.
6. Factura emisă de tip storno (cu echivalent RMA) cu variantele:
 Totală/integrală cu original – programul face stornarea automat si aduce înapoi
același preț de stoc folosit la ieșirea originală la client,
Pagina 98/142
 Parțială cu original – programul face stornarea automat la câteva linii,

 Fară original – unde articolele se introduc manual linie cu linie – prețul de stoc
trebuie băgat manual de dvs.
7. Control avansuri furnizori/clienţi
 Să putem gestiona avansurile la furnizori /409 şi clienţi /419 prin generarea de
documente specifice care se vor stinge cu facturi ulterioare
 gestionarea rapoartelor specifice
8. Control deconturi cu salariații
Pilonul principal trebuie să fie marca salariatului care trebuie să fie unică în
aplicaţie şi să fie aceiaşi cu cea de la: Personal, din ștatul/programul de salarii şi
modulele de gestiune a debitorilor, mijloace FIXE, obiecte de inventar aflate în
folosință.
 se pot gestiona avansurile la salariați 542 şi se pot închide ulterior cu facturile
aduse de aceștia de la alti terți. Exemplu: salariatul X primește un avans pe 542 de
1000 lei. El aduce un bon de benzină/Petrom (401), O factură de hotel (401) şi
două diurne. Avansul se va închide cu facturile aduse. Se închide 542 şi 401.
Efect:
 Facturile apar în J. Cumpărări pe furnizorii lor,
 Avansul se gestionează separat (542) şi se închide ulterior. Sumele apar
concomitent fără a fi operate de două ori în module diferite și în Reg. de Casă
și/sau Bancă (dacă am dat avansul prin cardul salariatului).
9. Registru de casă:
 Identificare registru zilnic la nivel de cod dată calendaristica și IBAN / ZI
 îmbinarea în același registru a încasărilor şi a plăților
 plata şi/sau încasarea extinsă cu: marcă salariat, număr document/chitanță, tip
document
 listare registru de casă cu toate atributele necesare
10. Alte Instrumente de plată la termen client Trată/CEC/BO.
Trebuie să existe modul de gestionare a instrumentelor de plată/încasare la termen
mai ales în zona de clienţi care să permită:
 Evidențierea CEC-ului/BO
 Asocierea la CEC/BO a unui număr de facturi prin blocarea lor la alte încasări
accidentale şi mutarea soldului din 411 în contul de BO în așteptare 413 / 5112
Pagina 99/142
 Stornarea/Anulare CEC/BO înregistrat eronat sau neplătit la termen de către

clientul rău platnic şi mutarea lor în litigiu şi eliberarea facturilor agățate pt. a putea
fi plătite sau stinse ulterior (anulare trată/CEC cu refacere sold facturi asociate).
Ca o paranteză aici: în ultimii 30 de ani cecurile neacoperite din Romania au
reprezentat un instrument facil de fraudare a furnizorilor, clientul lua marfa și
venea la plată cu un CEC fals sau venea cu un cec bun dar până la scadență
clientul dispărea efectiv.
11. Analiză clienţi şi furnizori. Prezența unor rapoarte de analiză şi pe clienţi şi pe

furnizori separate astfel:
 BALANŢA Client cu analiza pe punct de lucru, cont, cod_tert
 Fișe CLIENT cu analiză pe punct de lucru, cont, cod_tert
 Scrisori de avertizare (sau notificări de sold cum zic unii) către clienţi emise
automat cu formate predefinite diverse (marii distribuitori suferă de lipsa unui astfel
de instrument deoarece pierd f. mult timp cu “scrisorile de amenințare” către
clienţii rău platnici)
 Situația facturilor emise cu plați asociate pe tipuri de plăți şi date de încasare/plată
 Situația încasărilor pe case_bănci /clienţi /agent /perioadă_emitere
/perioadă_încasare /facturi/ document_încasare/puncte_de_lucru
 AGING (Aging Report = îmbătrânire pe perioade ) – Raport complex privind situația
soldurilor scadente pe clienţi / furnizori pe termene scadente, dată efectivă
(contabilă), dată factură cu analiza dinamică pe mai mult de 3 intervale
calendaristice (30,60,90,120 zile)
12. STOCURI:
FUNCȚII de bază operare STOC:
Intrări: Nir de la FURNIZOR LA PREȚ COMPLET pe bază de factură (408/401), Nir de
la puncte de lucru din cadrul grupului pe bază de aviz (481), Retur la furnizor, intrări
ocazionale cu preț , reglaje inventar
Ieșiri: Vânzare cu factură pe bază de comandă, vânzare pe bază de aviz la client, ieșiri
ocazionale, ieșiri pe bază de aviz la TRANSFER în cadrul grupului (481), retur de
marfă de la client (cu factură sau fară)
Rapoarte:
a.) Stocuri de materii prime, materiale, produse finite:
Balanţa de stoc (STOC_Iniţial/SOLD_iniţial, Intrări, Ieșiri, Sfinal, preț) în cutuma
contabilă românească se mai numește balanţa de stoc Si_iN_iE_sF.
Pagina 100/142
Listare NIR la preț complet (cu posibilitatea listării la preț de furnizor)

Raport confirmare nir cu toate componentele (Preț_furnizor + taxe_dvi + alte_servicii)
Bon de consum
Situația intrărilor pe surse: tipuri de intrări/conturi/magazii + documente/furnizori;
Situatia ieșirilor pe destinații: tipuri de ieșiri/conturi/magazii + documente/clienți.
b.) Gestionare Obiecte inventar/angajat (OBINV).
Cumpărare OBINV, dare în consum OBINV (pe marcă), transfer între mărci (salariați)
Rapoarte – balanţă de stoc a OBINV, fişa OBINV pe salariat
13. Contabilitate:
Funcţionalități de bază:
1. Control şi verificare a notelor din toate sub-modulele (Mfixe, Clienţi, Furnizori,
încasări, plați, STOC, Salarii, Producţie);
2. Preluare ușoară şi facilă prin funcție separată de import a notelor manuale prin
intermediul EXCEL provenite din alte sisteme cum ar fi un program de salarii sau alte
note gestionate prin alte programe apendice externe;
3. Validare note contabile şi control la nivel de utilizator, un fel de audit/spion (cine şi
când a contat ?, a modificat sau a sters ?);
4. Operare tranzacţii manuale direct pe cont contabil – altele decât cele provenite din
module (GL/JL manual journal entries);
5. Functie de reevaluare periodică a conturilor de valută provenite din modulele de
clienţi, furnizori valută şi încasări şi plăți:
- Funcții de reevaluare în module cu transmiterea automată a notelor contabile de
diferențe de curs valutar şi evidențierea lor pe factură / cont;
- plațile/încasările ulterioare reevaluarii țin cont de emiterea notei iniţiale de curs
valutar şi de noua rată de evaluare.
6. Generare şi gestionare diferențe de curs valutar (665/765) la plata/încasarea facturilor
în valută provenite de la furnizori şi clienţi externi.
7. Mecanism de gestionare ACCIZE şi Taxă verde necesar în industria de petrol,
alcool/bere şi electronice cu evidența pe cont contabil şi tip acciza.
8. Închidere cont 121 – cu generare / regenerare pâna la închiderea completă a lunii
9. Lucru cu calendare contabile pe perioade financiare şi pe module care se
închid/deschid de către administratori.
Pagina 101/142
14. Alte Rapoarte:

1. registru jurnal detaliat (toate notele din luna cu sute de pagini) – se poate exporta în
PDF sau excel și se păstreaza în arhiva electronică a firmei ca martor.
2. registru jurnal cumulat prin debitul şi creditul conturilor – poate înlocui registrul
jurnal general detaliat care poate avea sute/mii de pagini
3. Carte mare; Fişă cont
4. Balanţa contabilă cu 8-10 coloane cu sumar pe cont sau detaliat pe analitic:
detaliu/cont, sintetic/analitic, detaliere pe centre de cost cu posibilitatea emiterii în
EXCEL/PDF.
5. Balanţa contabilă pe puncte de lucru (fabrici sau filiale sau depozite)
6. Declarația 390
7. Declarația 394 – mai nou va apare și D406/Saf-T
8. Jurnale de Cumpărări şi Jurnale de vânzări dinamice, configurabile cu număr de
coloane variabil conform modificărilor din 2007 – jurnalele să fie independente şi să
fie dinamice putând fi configurate în funcție de numărul de coloane necesare (AIC,
LIC, operații interneRomania: TVA 5%, 9%, 19%, 24%, servicii, TAXARE inversă
etc.. )
15. Mijloace fixe

Funcţionalitate standard de înregistrare MF, calcul amortizare pe
registre/locații/conturi/numere de inventar.
Rapoarte: diverse rapoarte de analiză Balanţa MF, sit. amortizărilor, fişa MF, situația
intrărilor/ieșirilor/transferurilor
16. Alte Programe diverse asociate sistemului care trebuie "să fie legate" de ERP în
mod opțional:
 Intrastat
 BILANȚ cu anexe – opțional, de obicei preluăm manual date din balanța contabilă
 Postcalcul – necesită analiză şi configurări specifice – miniproiect separat
întotdeauna deoarece postcalculul de la clientul X nu se potrivește niciodată cu
clientul Y
17. MRP 2 :
Dacă gestionati stocuri diverse şi în cantități mari atunci MRP este unul din
instrumentele ERP de gestiune şi conducere (management) pt. care aţi cumpărat
sistemul – ăsta face practic toți banii. Dacă ăsta nu există atunci nu putem discuta
despre un ERP şi înseamnă că doriţi o altă aplicaţie.
Pagina 102/142
Ce face MRP? . – MRP este mecanismul de planificare stocuri (inventory) prin

care putem stabili:
- ce comenzi de vânzare (cu ce articole pe ele) de la clienţi sunt înregistrate şi
sunt posibile a fi onorate pe perioadă analizată (orizont de timp 1-2 luni poate 6
luni);
- ce comenzi de lucru trebuie lansate în producţie pe baza comenzilor client?
- ce capacitați de producţie se vor încărca şi cum le gestionăm, care sunt locurile
înguste?
- ce materiale/materii prime ne lipsesc acum pentru alimentarea fabricației şi
de la ce furnizori şi în cât timp putem face aprovizionarea - aproape JIT (Just
în Time)?
18. Antecalculația completă a prod. finite şi a semifabricatelor (în strânsă legatură cu
MRP) ce cuprinde:
- costul complet ANTECALCULAT la nivel de produs finit
- costul ANTECALCULAT detaliat pe componente semifabricate
- costul ANTECALCULAT detaliat pe componente materiale şi materii prime
Pagina 103/142
17. Localizarea și adaptarea unei aplicaţii ERP anglo-saxone la

specificul unei ţări francofone. Exemple din Franța și România.
17.1. Localizare facută de ERP Oracle JD Edwards pentru Fra nța –

ve rificări registre contabilitate(2014)
Se observă că pentru Franța, ORACLE a depus efortul considerabil de a realiza
localizarea aplicaţiei sale pentru cea mai importanta secțiune a repartizării contabile
respectiv jurnalizarea datelor și verificarea inter-module versus contabilitate (modul>sub-
ledger>ledger). Numai pentru aceasta sectiune ar trebui scrisa o carte separata format A4
de cel puţin 300 pagini. Din acest motiv ne rezumăm aici doar la preluarea datelor din
documentația produsului așa cum a fost expusă de producator în 2011. În sinteză, în
interpretarea autorului, Oracle a făcut conversia metodologica, legislativă și
tranzacţionala prin maparea sistemului GAAP la sistemul francez continental prin
acest sub-modul. Fiindcă în realitate este “o aplicaţie în aplicaţie” dacă ne putem exprima
așa. Vezi și (Guide de mise en oeuvre de localisation pour la France, Version 9.1.x E60270-01,
Juillet 2014).
https://docs.oracle.com/cd/E39124_01/doc.91/e60270/fr_understand_cs_func_fr.htm#EOAFR3706
Pagina 104/142
17.1.1 Exemplu extras din localizarea pentru Franța:

Am extras mai jos din tabelul original câteva funcții și rapoarte din localizarea pentru
Franța. Am preluat tabelul folosind fontul original al proprietarului.
Am marcat cu galben elemente specifice modelului de verificare contabil francez.
4.12 Utilisation de rapports additionnels pour la France
En plus des rapports précisés dans le cadre du traitement à d'autres sections de ce guide de mise en
oeuvre, ces rapports existent en France.
Code et nom du Description Navigation

rapport
R09473 Vérification de la précision des transactions dans les livres de comptes Rapports - France
individuels. Lorsque toutes les transactions sont exactes, les totaux dans ce (G093151), Balance
(FRA, ITA, USA) rapport sont les mêmes que les totaux dans les rapports du G/L et le rapport du générale par objet et sous-
Balance générale de G/L Registration Report (R09404). compte
débit/crédit par objet
R70470 Validation de l'information contenue dans les rapports juridiques et utilisation Rapports - France
possible comme base de la vérification interne. Vous pouvez également utiliser le (G093151), G/L par code
(ESP, FRA, ITA) rapport comme base de la vérification externe par un tiers, par exemple une de catégorie
G/L par code de autorité fiscale ou un cabinet de vérification comptable.
catégorie
R70472 Vérification de la précision des transactions dans les livres de comptes Rapports - France
individuels. Lorsque toutes les transactions sont exactes, les totaux dans ce (G093151), Balance
(FRA, ITA) Balance rapport sont les mêmes que les totaux dans les rapports G/L par code de catégorie générale par code de
générale par code de (R09470) et G/L Registration (R09404). catégorie
catégorie
R7403B026 Le rapport Livre stock clients indique le montant non soldé total pour chaque Etats - France (G093151),
client, par entreprise. Și un client a des montants ouverts dans plus d'une Livre stock clients
(FRA, ITA) Livre entreprise, le montant non soldé pour chaque entreprise est indiqué de façon
stock clients distincte.
R7404026 L'état Livre stock fournisseurs indique le montant non soldé total pour chaque Etats - France (G093151),
fournisseur, par entreprise. Și un fournisseur a des montants ouverts dans plus états - France
(FRA, ITA) Livre d'une entreprise, le montant non soldé pour chaque entreprise est indiqué de
stock fournisseurs façon distincte.
R74099A Utilisez cet état pour vérifier que les numéros de documents sont en ordre Rapports - France
séquentiel sans interruption; le système imprime un rapport en se basant sur le (G093151), état Chiffres
(FRA, ITA) Etat fichier Taxes (F0018). séq.- Taxes
Chiffres séq. - Taxes
R74099B Utilisez cet état pour vérifier que les numéros de documents sont en ordre Etats - France (G093151),
séquentiel sans interruption; le système imprime un rapport en se basant sur le état Chiffres séq. - Livre
Pagina 105/142
Code et nom du Description Navigation

rapport
fichier Grand Livre comptes fournisseurs (F0411). CF
(FRA, ITA) Etat
Chiffres séq. - Livre
CF
R74099C Utilisez cet état pour vérifier que les numéros de documents sont en ordre Etats - France (G093151),
séquentiel sans interruption; le système imprime un rapport en se basant sur le état Chiffres séq.- CF
(FRA, ITA) Etat fichier Grand livre clients (F03B11).
Chiffres séq. - CC
R7409C1 Validation de l'information contenue dans les rapports juridiques et utilisation Rapports - France
possible comme base de la vérification interne. Vous pouvez également utiliser le (G093151), G/L par objet
(ESP, FRA, ITA) rapport comme base de la vérification externe par un tiers, par exemple une et sous-compte
G/L par objet et autorité fiscale ou un cabinet de vérification comptable.
sous-compte
R7409C3 Vérification de la précision des transactions dans les livres de comptes Etats - France (G093151),
individuels. Lorsque toutes les transactions sont exactes, les totaux dans ce Balance générale par objet
(FRA, ITA) Balance rapport sont les mêmes que les totaux dans les états G/L et Enregistrement G/L. et sous-compte
générale par objet et
sous-compte
R7409C5 Impression des transactions par ordre chronologique selon la date de Rapports - F
comptabilisation des écritures dans le Grand Livre. Pour une même date, les
(FRA) Journal écritures apparaissent dans l'ordre suivant :
général 1. Heure à laquelle les écritures ont été saisies ou
comptabilisées;
2. Type de transaction, par exemple achat , vente et dépenses

diverses;
3. Ordre de numéro de compte.
17.1.2 Verificare conta/modul. Analitic-sintetic. Exemplu concret

R7409C3 Vérification de la précision des transactions dans les livres de comptes individuels.
Lorsque toutes les transactions sont exactes, les totaux dans ce rapport sont les mêmes Etats - France (G093151),
(FRA, ITA) Balance que les totaux dans les états G/L et Enregistrement G/L. Balance générale par objet et
générale par objet et sous-compte
sous-compte
Interpretare cu traducere din franceză:

[...Verificarea exactității tranzacțiilor din jurnalele de cont individuale (fişa cont, carte mare,
reg. Jurnal general). Când toate tranzacțiile sunt corecte, totalurile din acest raport sunt
aceleași cu totalurile din rapoartele G / L și tranzacţiile G / L (din module)...]
Pagina 106/142
17.1.3 Comentariul meu ca autor pentru verificarile de mai sus modul>conta, sub-
ledger> ledger GL:
Ce poate fi mai clar decât faptul că Franța a impus în această localizare instrumente
concrete de verificarea exactă a consitenței datelor între conta si modul ?, între așa-
zisul Sub-Ledger și General Ledger ?, între contabilitatea modulului si contabilitatea finală
reală GL, aia de se raportează la fisc în cazul României prin Bilanț48 cod F10, F20, F30 și
F40?
Aceste instrumente nu fac decât să armonizeze verificarea între prima verigă a lanțului
(prima zală) si ultima zală a lanțului informațional contabil reprezentat de bilanțul contabil.
Schema traseului informației se face după următorul model și flux:
A. Prima zală: Tranzacția atomică provenită din documente de bază (Nir, bon consum,
factură client, bon transfer, ștat de plată, avans delegație, decont delegație etc…)
Poate conține: cantitate, preț, valoare, marcă și/sau client/furnizor, articol, dată,
locație/centru cost, descriere, camion,sofer, UM, lot etc...
B. A doua zală: Contabilitatea de modul sau sub-ledger formată din imaginea 1:1 pentru
fiecare linie/tranzacție atomică din pasul [zala A] de mai sus. În majoritatea ERP-urilor
conține imaginea contabilă a tranzactiei [A] dar exprimată în conturi contabile
conform setări specifice modulului. Dacă setările sunt proaste sau incomplete atunci și
aceste conturi din sub-ledgerul de modul sunt proaste. Acestea sunt de obicei așezate
în formatul 1 linie = 1 cont și nicidecum în formatul DEBIT-Credit. Exemplu cu sub-
ledger generat pentru o factură complexă de vânzare la client ce conține și marfă și
finite și servicii (nu am pus și discount/rabat):
Cont Suma_DEBIT Suma_CREDIT
4111 (client) 119 lei
707 (marfă) 50 lei
701 (finite) 20 lei
704 (servicii) 30 lei
4427 (TVA) 19 lei
48
Bilanțul contabil = formular obligatoriu anual /semestrial format din minimum: F10 - BILANT PRESCURTAT,
F20 - CONTUL PRESCURTAT DE PROFIT ŞI PIERDERE, F30 - DATE INFORMATIVE, F40 - SITUATIA ACTIVELOR
IMOBILIZATE.
Pagina 107/142
C. A treia zala: Contabilitatea nepostată formată pe baza a ce a găsit în pasul [B sub-

ledger] formată din imaginea 1:1 pentru fiecare cont de mai sus și asezarea lui în forma
DEBIT-CREDIT conform carte mare (Grand Livre), fișa de operații diverse și registrul jurnal
general. Aceasta e o contabilitate în așteptare, în verificare care așteaptă să fie postată
respectiv tranferată către pasul următor [D] (zala următoare) astfel:
Cont_debit Cont_Credit SUMA
4111 = 707 50 Lei
4111 = 701 20 Lei
4111 = 704 30 Lei
4111 = 4427 19 Lei
D. A patra zală: Contabilitatea POSTATĂ finală formată în urma acțiunii de postare care
preia datele așa cum le găsește din tabela de nepostate în așteptare de la pasul [C] și le
transferă în fișierul/tabela de postate finale. Această tabelă [D] de postate finală este
sursa unică pentru Fișa de cont, Cartea mare (Grand Livre), Fișa de operații diverse,
Balanța contabilă cu 4,5,6 egalități și Bilanțul contabil.
Aceste rapoarte din [D] nu citesc niciodată date din [A] sau [B] sau [C] , citesc numai din
tabelele finale [D].
Rolul reconcilierilor contabile, al verificărilor conta/modul, ledger to sub-ledger
reconciliation este ca valorile provenite din [A] să ajungă în [D] corect și așezate pe
conturile care trebuie. [B] + [C] sunt etapele care necesită cea mai mare atenție în
verificare și pentru acestea avem nevoie de scule inteligente de verificare (rapoarte și
funcții de ajustare/modificare) pentru ca în final să avem în [D] date corecte.
Pagina 108/142
17.2. Localizare facută de OracleNetSuite Fra nce-Specific

Features. Fichie r d’Ec ritures Co mptables (FEC) (2020)
Menționăm aici o a doua localizare făcută pentru Franța de un alt produs Oracle numit
Oracle NetSuite.
Documentația acestei localizări este publică la adresa:
https://docs.oracle.com/pdf/F35081_01.pdf
vezi și:
https://docs.oracle.com/search/?q=France-Specific+Features
și se mai numește [NSFFF.pdf]:
[...France-Specific Features September 9 2020 2020.2 pdf document
September 30, 2020 • This guide provides setup and usage instructions relating to
NetSuite features specific to a French business setting…]
De ce menționez această localizare aici?

Această localizare conține una din cele mai actuale cerințe legislative obligatorii numită
[France Fichier d’Ecritures Comptables (FEC)] care este un model proprietar adoptat de
Franța pentru declarația SAF-t.
Acestă declarație [France Fichier d’Ecritures Comptables (FEC)] conține printre altele
Registrul Jurnal General detaliat Debit-Credit aproape identic cu cel cerut în România.
Franța a avut grijă (ca întotdeuna de altfel) să ignore formatele propuse de standardul
SAF-T și să dezvolte propriul sistem de raportare [sistem proprietar] numit [Le Fichier des
Écritures Comptables] sau FEC.
Pentru Franța puteți extinde analiza de aici:
Fichiers des écritures comptables (FEC) de pe saitul Ministerului Francez de Finanțe
[Direction générale des Finances publiques]
Vezi aici: https://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-
comptables-fec
Aici veți găsi detaliat toate cele 5 sub-declarații specifice Franței /FEC:
https://snitechnology.net/fec-france/
sau aici:
https://www.runview.fr/tout-savoir-fec
Ca bonus pentru programatori avem aici o analiză EXCEL/VBA facută de o firmă din
Franța (pasionați chiar de informatică economică). Aici avem analiza celor 18 câmpuri
principale din FEC de Franța echivalentul sub-declarației: Registrului jurnal general din
România.
Vezi aici: https://www.auditsi.eu/?p=6512
Declarația saf-t pentru România este cunoscută ca D406 si va începe implementarea ei

începând cu 01.01.2022.
Pagina 109/142
17.3. Localizare facută de ERP QAD EE (Eneterprise) pentru

România (ex MFG/PRO) – 2015-2017
În continuare prezentăm o imagine de pe saitul oficial al QAD Inc. de la adresa publică:

https://www.qad.com/documentation/Int/Romania/index.html#page/Romania_Int_UG_v21/02_Romania_Reports.3.01.html#
Vezi si:
https://documentlibrary.qad.com/documents/2370665/2370931/I19_Romania_UG_v31.pdf
https://documentlibrary.qad.com/documents/2370665/2370931/Romania_Int_UG_v30.pdf
Se observă că pentru Romania, QAD a depus efortul considerabil de a adapta ultima

versiune a aplicaţiei sale numita azi QAD EE (Enterprise edition) prin integrarea și
adaptarea funcţională a următoarelor funcții și rapoarte de bază specifice României.
Am listat prin traducerea direct în limba româna în ordinea apariţiei în imaginea de mai jos.
Am inserat și un mic comentariu funcţional.
Declarația 390 – ieșire XML pentru format PDF (soft A);

Declarația 394 – ieșire XML pentru format Duke Integrator (s-a ales formatul Duke/Soft_J
necesar firmelor cu mii de facturi furnizori și clienţi, formatul PDF/ Soft A lucrând f. greoi).
Fişa de magazie – pe articol /magazie cantitativ valorică.
Balanţa de stoc pe magazie (cu 8 coloane) – cu stoc intiţial, sold iniţial, intrări
cant./valorice, ieșiri cant./valorice, stoc final, sold final (Stoc = cantitate si sold = valoare);
Registrul jurnal general
Registrul de CASĂ/BANCĂ
Jurnalul de Vânzări – cu toate coloanele importante inclusiv vânzări UE/LIC, Export non-
UE;
Jurnalul de Cumpărări – cu toate coloanele importante inclusiv cumpărări UE/AIC, Import
non-UE;
Registru control tranzacţii contabile – o detaliere a registrului jurnal pe tranzacţii
contabile de stoc;
Fişa de cont;
Balanţa de verificare contabilă cu 4 egalități/ 8 coloane;
Jurnalul de cumpărări tip TVA la plată/încasare – jurnal de cumpărări specializat doar
pe operațiile ce țin de cumpărările/facturile marcate ca fiind tva la plată cu detaliere pe
plăți lunare și sold 4428.
Pagina 110/142
Jurnalul de cumpărări tip TVA la plată/încasare

– jurnal de cumpărări specializat doar pe operațiile
ce țin de cumpărările/facturile marcate ca fiind tva
la plată cu detaliere pe plăți lunare și sold 4428.
Pagina 111/142
18. Închiderea lunii în ERP [Closing month processes]. Reconcilieri

Numai pentru acest capitol referitor la închiderea lunii în ERP cineva va trebui să scrie o
altă carte separată cu multe pagini, capitole structurate şi anexe.
18.1. Ce este înc hiderea de lună î n ERP?

Închiderea de lună în ERP trebuie să cuprinda toate activitățile necesare obținerii de date
curate [solduri şi rulaje] contabile în principiu pentru luna încheiată în balanţa contabilă cu
4,5, sau 6 serii de egalități. Rulajele şi soldurile fiecărui cont din balanţă ar trebui să bată
cu un raport din unul din sub-module adică cu sub-ledgerul sursă. Principalele verificări
sunt detaliate mai jos.
Un profesionist adevarat (nu e cazul meu) ar spune că zalele lanțului SCM (tabelele
tranzacționale SCM) să fie transpuse corect în format contabil în tabelele finale GL din
care vom lista: Balanța, Reg. Jurnal General, Cartea mare și Bilanțul specific după caz
modelului Francofon sau GAAP al țării în care s-a făcut implementarea.
18.1.1 Durata activității de închidere:

Activitatea se întinde de obicei între 01 (întâi) luna următoare lunii de închis şi durează în
funcție de calitatea ERP-ului folosit, complexitatea activităților economice de închis şi
istețimea contabillilor pâna pe 10 sau 25 luna următoare.
Există însă multe firme mari care nu reușesc să închida complet o lună datorită lipsurilor
funcţionale din ERP şi se întind cu închiderile la 30.06.2021 pentru ianuarie-iunie 2021 şi
ianuarie 2022 pentru iulie-decembrie 2021 (de exemplu).
18.1.2 Pași de urmat la închidere [totul în ERP] versus [programe auxiliare

apendice]
A. Se încearcă iniţial o verificare dacă toate documentele lunii de închis au fost

introduse în aplicaţia ERP şi dacă cumva din greșală am uitat să operăm ceva
(facturi furnizor, facturi client, bonuri de consum, transferuri, raportări de producţie,
calcul salarii, amortizări, încasări +plăți pe fiecare registru casă/bancă (IBAN)).
Teoretic aici fiecare operator important din aplicaţie trebuie să verifice recapitulațiile
de pe modulul ce îl are în responsabilitate.
Pagina 112/142
B. Pentru început trebuie stabilit dacă toate operațiile sunt gestionate din ERP sau se
folosesc şi programe apendice adică alte programe auxiliare care vor trimite date
către ERP prin intermediul unor note contabile GL ce vor fi importate.
C. Pentru închiderea de lună trebuie urmăriţi următorii pași:
1. Se vor finaliza şi verifica toate modulele/aplicaţiile externe care vor trimite date către
ERP. De obicei cele mai uzuale programe externe folosite pot fi:
- O aplicaţie de salarizare şi resurse umane. Aici trebuie facută închiderea completă
a ștatelor de plată pentru luna calculată. Se vor avea în vedere ca toate calculele
de brut, net per salariat şi centru de cost precum şi toate impozitele către stat să fie
calculate corect (impozit salarii, CAS, CASS şi altele în funcție de context).
Acestea vor trimite notele de cheltuială cu salariile către ERP prin import/export
note. Dacă aveți şi o aplicaţie de postcalculație a costurilor va trebui verificat dacă
notele de salarii pleacă către ERP la nivel total (global) pe cont_debit=Cont_credit
sau se duc la nivel de angajat (marcă) sau/și la nivel de centru de cost. În cazul
urmăririi în postcalcul la nivel de marcă+centru de cost atunci notele de salarii
transmise vor fi de ordinul miilor sau sutelor în funcție de numărul de angajați.
Acuratețea postcalculului va fi mai mare dacă notele sunt la nivel de angajat şi nu la
nivel de centru de cost sau global ștat de plată (loc de plată).
- Putem avea o aplicaţie de Mijloace fixe separată. Nu toate Erp-urile au modul de
Mfixe sau chiar dacă au, acesta nu acoperă modul de calcul al amortizării lunare
sau de reevaluare. Această aplicaţie va trimite şi ea note contabile catre Erp prin
import/export.
- O aplicaţie de facturare la client care emite facturi. Această aplicaţie va transmite
înapoi către ERP nu numai notele contabile ce privesc 4111, 4427, 607, 345, 711,
371 etc…(după caz) dar şi documentele ce vor fi importate în modulul de AR
(facturi client) precum şi toate documentele de stoc de descărcare (comanda de
vânzare Sales order şi detaliile SO şi detaliile facturii/linii factură).
2. Se vor finaliza şi verifica toate modulele şi jurnalele (rapoartele) din ERP:

- Verificare clasa 3 (3xx) încrucișat cu Balanţa de stoc contextual pe magazii/articole
- Verificare 4111x,418x şi 4118x încrucișat cu Balanţa de clienţi
- Verificare 4011x,404x,408 încrucișat cu Balanţa de furnizori
- Unele ERP-uri au rapoarte speciale numite [comenzi PO fară obligații la data de ..]
sau GRNI (goods received not invoiced) care pot ajuta la stabilirea corectă a lui
408x dacă acesta e setat corect în aplicaţie.
Pagina 113/142
- Verificare 4426/4427: Jurnalul de Cumpărări pe cote şi surse (import, AIC, taxare

inversă, 5, 9, 19 etc..precum şi bonuri fiscale simplificate (legătura cu D394 aici pe
literele A,N,L,AI,V şi tipuri de parteneri 1/2 )
- Verificare 4427:Jurnalul de Vânzari pe cote şi destinații (Export, LIC, taxare
inversă, 5, 9, 19 etc..precum şi bonuri fiscale simplificate dacă există (legatura cu
D394 aici pe litere)
- Suplimentar pentru România avem noul raport inventat pe vremea lui Ponta pentru
detectarea stării documentelor cu TVA la plată (recepţii sau vânzări). De obicei
ERP-urile sunt instalate la firme mari care nu folosesc Tva la plată pe partea de
client dar primesc facturi de recepţie de la furnizori “săraci” care încă mai folosesc
TVA la plată (TVA la încasare). În acest context unele ERP-uri au creat o localizare
numită Jurnal de cumpărări pentru TVA la plată (TVA la încasare) care prezintă
starea TVA-ului 4428 “în așteptare 90 de zile” şi trecerea lui treptată pe 4426.
- Verificarea tuturor registrelor de casă şi de bancă. O firmă trebuie să aibă atâtea
registre de bancă câte IBAN-uri active are şi atâtea registre de casă câte case reale
are pe monezi si locații (CASA Sediu LEI, CASA Magazin Poartă LEI, Casa Sediu
EUR etc…).
- Verificare deconturi cu salariații (5311.casaX, 5311.casaY, 542). În cazul unui
număr mare de deplasări este necesară verificarea rapoartelor cu recapitulațiile
avansurilor spre decontare şi a registrelor de casă/bancă în care se urmăresc
simultan: avansuri date şi nerestituite (deconturi neînchise), solduri pe
mărci/salariați care pleacă des în delegaţii, facturi furnizor (Hotel, Benzină,
mâncare sau chiar cumpărări în numele firmei). Facturile de furnizor aduse de
salariați pe decont în luna de calcul vor trebui să apară în Jurnalul de Cumpărări
înregistrate pe furnizorul exact (Metro, Dedeman, Petrom, Hotel Reghina) şi pe
coloana cu cota de TVA exactă (5,9,19 etc…)
- Verificare modul de mijloace fixe. Calcul amortizare lunară. Operare deprecieri,
intrări, transferuri, casări. Transfer note contabile către ERP.
- Verificare consum şi transferuri obiecte de inventar în folosință (303,603,8035).
În funcție de complexitatea firmei obiectele de inventar date per marcă/salariat pot
avea o pondere importantă în activitatea firmei DVS. De obicei ERP-urile nu știu să
gestioneze corect obiecte de inventar în folosință. Din acest motiv ca şi la Salarii
sau Mijloace Fixe se apelează la programe/aplicaţii externe.
Pagina 114/142
18.1.3 Cheie de verificare în orice aplicaţie. Exemplu: soldul Băncii pe registrul IBAN
X-Y-Z (BCR Cont curent LEI ARAD):
Registrul de casă /Bancă este una din cele mai importante chei de verificare într-o
aplicaţie ERP, este soldul pe registrul de BANCA. Folosim aici ca exemplu IBAN
RO55RNCB12345678xxx care este unul din conturile noastre bancare la BCR
ARAD botezat contabil ca 5121.BCRArad. În limbaj contabil fișa sah prin Debitul lui
5121.BCRArad și separat prin Creditul lui 5121.BCRArad. prin punctaj cu conturile
corespondente ne rezolvă o mare parte din verificările încrucișate cu alte module și
alte conturi importante (4011, 4111, 542, 5121.x, 5311.x, 421.x, 431.x etc…).
Dacă majoritatea încasărilor de facturi clienţi +majoritatea plăților salariilor
către salariați prin card + majoritatea plăților la marii furnizori se fac prin acest
cont şi dacă am operat absolut toate operațiile în ERP pe acel registru de bancă şi
acesta prezintă soldul de 12.510 lei la sfârșitul lui iunie 2021 şi este identic cu
ultimul extras real oferit de bancă la 30.06.2021 atunci cu siguranță:
- Şi rulajul creditor + soldul contului 4111 ar trebui să fie bune pe relația cu
5121.BCRArad,
- Şi rulajul debitor + soldul contului 401x +404x ar trebui să fie bune pe
5121.BCRArad,
- La fel pentru 542.x, 431.x si 421.x.
Cu cât avem mai multe conturi IBAN la BCR (sau BRD sau BT ), poate câte unul la
fiecare sucursală din Pitești, Sibiu, Constanța putem să facem aceste verificări
încrucișate cu încasările şi plațile pe conturile bancare respective încrucișat cu
4111x, 401x etc….
18.1.4 Module şi activități de închis lunar în ERP:
Principalele activități economice de închis și de verificat la sfârșitul lunii sunt:

Stocurile cu sub-activitățile lui:
Recepţii de la furnizor
Transferuri inter-magazii în cadrul aceleiași secții sau în aceiași curte
Transferuri către magazii ale subunităților aflate la distanță–prin aviz (cont 481/482)
Pagina 115/142
Consumuri proprii – către producţie

Consumuri proprii – catre activități auxiliare
Consumuri proprii – către birouri TESA
Vânzări către clienţi de produse finite şi mărfuri (inclusiv vânzări la salariați)
Principalele instrumente folosite aici sunt:
Recapitulația documentelor de intrare pe Surse/magazii /articole/conturi;
Recapitulația documentelor de Iesire pe Destinații/magazii /articole/conturi;
Balanţa de stoc pe magazie, cont contabil, articol, perioadă (lună);
Fişa de magazie cu varianta ei cantitativ valorică pentru identificarea erorilor fine;
Pentru reconciliere Ledger-Subledger adică verificare modul stocuri încrucișat cu
contabilitatea se folosesc:
Registrul Jurnal General Debit=Credit filtrat pe cont_contabil, magazie, articol, terț
(client furnizor), document.
Selecții sau totaluri din acestea trebuie să bată cu:
- Recapitulația documentelor de intrare pe Surse/Destinații;
- Balanţa de stoc intrări_valorice pe magazia X încrucișat cu rulaj Debit cont 3024
(de exemplu).
Se verifică dacă toate documentele ce afectează stocul au fost operate în ERP.

Dacă se lucrează cu alte aplicaţii externe apendice ERP-ului se verifică dacă toate
documentele au fost introduse în acele programe apendice prin listingurile şi rapoartele
oferite de acele programe.
18.1.5 Notă importantă privind rapoartele de Ieșire/Intrare pe Surse și Destinații:

Recapitulația documentelor de Ieșire/Intrare pe Surse și Destinații reprezintă un set
de listinguri (rapoarte) care se listează lunar pentru a putea face următoarele
verificări:
4. Dacă s-au operat toate documentele de orice tip ce afectează intrarea în stoc sau
ieșirea din stoc?. Aici vor apare toate facturile, avizele, note de trasnfer, bonuri
etc… cu recapitulații pe pe conturi, surse (furnizori), destinații (clienți), magazii;
5. Care au fost sursele si care au fost destinațiile?. Sursele sunt de obicei externe
(4011, 481, 408 furnizori ) sau interne (altă magazie internă /cont de clasa 3).
Destinațiile pot fi: clienții externi firmei (4111, 418 ) sau altă magazie internă pentru
transfer (3xxx) sau sucursală (aviz/481/482) sau consumul intern (cont cheltuială
6xxx);
Nu vom găsi un format obligatoriu sau recomandat pentru recapitulația documentelor de
Ieșire/Intrare pe Surse și Destinații din stocuri:
6. Legislativ nu avem un corespondent al acestor recapitulații în Ordinul nr.
3512/2008 privind documentele financiar-contabile sau în Ordinul nr. 2634 din 5
noiembrie 2015 privind documentele financiar-contabile.
Pagina 116/142
7. Aceste recapitulații se regăsesc în principal în aplicațiile financiar-contabile

românești create de foști angajați ai fostelor oficii de calcul din anii 1990.
8. Fară aceste recapitulații pe surse/destinații, închiderea contabilă cantitativ-
valorică a stocurilor pe magazii este foarte greu de realizat la sfârșit de lună. Fară
aceste rapoarte de sinteză contabilul este obligat (trebuie) să apeleze la liste
multiple din diverse alte părți ale aplicației pentru a face verificările încrucișate de
reconciliere ledger/sub-ledger respectiv conta/modul.
În Ordinul 3512/2008 găsim totuși o “urmă” pentru noțiunea de SURSE scăpată de

metodologii din M.finanțe: [….În contabilitate, documentele privind mișcarea stocurilor
se grupează pe gestiuni, surse de aprovizionare (de la furnizori, din prelucrare la terți,
consum intern etc.) și, în cadrul acestora, pe conturi de materiale și gestiuni, iar în
cadrul gestiunilor, pe grupe sau subgrupe de materiale, după caz….]
18.1.6 Închiderea lui 121 – funcție lipsă în ERP standard.

După ce se verifică cele de mai sus contabilul poate da o închidere a lui 121. Dai
închidere la 121 dacă aplicaţia ERP are acest instrument. Dacă ERP-ul nu are
creată prin localizare funcție pentru închiderea lui 121 atunci o faci tu contabil
manual în Excel afară şi o copiezi sub forma de note manuale (prin import dacă
poți) înapoi în ERP.
a.) De obicei nu are şi ești obligat din nou să apelezi la două metode:
9. Faci închiderea 121=6xxx şi 7xx = 121 într-o aplicaţie externă şi întorci notele sub
formă de import GL în ERP,

10. Sau te muți cu totul în aplicaţia contabilă externă şi exporți notele din ERP în
aplicaţia contabilă românească şi închizi acolo.

b.) Daca ERP-ul pe care îl detineți are localizarea de închidere cont 121 facută de o
echipă din România atunci faci închiderea lui 121 în acel Erp de mai multe ori
succesiv pâna iese bine.
18.1.7 Blocarea fizică a lunii închise – calendare contabile şi de modul

Un instrument important în aplicaţiile Erp îl reprezintă calendarul de operații care se poate
configura la nivel de lună calendaristică de lucru. Mai sunt unii care folosesc două
calendare (model USA) în aceiași lună dar modelul Francez consacrat în Europa folosește
luna calendaristică = luna financiar contabilă.
Calendarul lunii poate fi divizat apoi pe module şi sub-module importante cum ar fi în
exemplele generice de mai jos:
Calendaul IC = Inventory = Stocuri = Open/Close [Yes/NO]

Calendaul SO = Comenzi la client = Open/Close [Yes/NO]
Pagina 117/142
Calendaul PO = Comenzi de la furnizor = Open/Close [Yes/NO]

Calendaul AP = Facturi de la furnizor = Open/Close [Yes/NO]
Calendaul AR = Facturi catre client = Open/Close [Yes/NO]
Calendaul WO = Comenzi de producţie = Open/Close [Yes/NO]
Calendaul IM = Import Note şi tranzacţii = Open/Close [Yes/NO]
Calendaul GL = Note contabile manuale = Open/Close [Yes/NO]
În concluzie, administratorul poate interzice partial la nivel de modul stocuri, facturare,

producţie, recepţii sau la nivel de contabilitate generala [GL] operarea pe module.
Daca toate sub-calndarele pentru 01-06-2021 la 30-06-2021 sunt în starea CLOSE atunci
nimeni nu mai poate introduce date pe luna iunie 2021 în nici un modul şi nici nu mai
poate importa note sau tranzacţii din alte aplicaţii.
19. SAF-T , Declarația D406 şi ERP-ul dvs.

Pentru că m-a apucat luna decembrie 2021 şi eu tot înca mai scriu la această carte trebuie
să menționăm aici şi noua declarație D406 numită şi SAF-T.
Mfinante.ro (ANAF) a publicat stadiul proiectului declarației SAF-T (D406) în 09 iulie 2021
si apoi Ordinul nr.1783 din 04.11.2021 cu termene de implementare, norme, anexe,
validator Duke –soft j si structuri XML.
Declarația va fi obligatorie pentru marii contribuabili începând cu declarația lunii ianuarie
2022 ce se va putea depune teoretic în intervalul 01-28 februarie 2022 dar cu termen de
grație = 31.07.2022. Cotribuabilii mici şi mijlocii inclusiv neplătirorii de TVA vor depune
SAF-T (D406) la termene ce vor fii communicate pe parcursul anului 2022 şi 2023.
19.1. De ce menționez această declarație SAF-T (D406) în această

lucra re ?
Deoarece ea conține în formatul comunicat de ANAF în ver.15.11.2021 un set de sub-
declarații ce acoperă exact principalele instrumente de gestiune menționate în această
lucrare. Este vorba de un set de [rapoarte] obligatorii pe care trebuie să le dețină orice
ERP. Ele se regăsesc detaliat şi în capitolul: [
Pagina 118/142
Funcţionalităţi ce trebuie să existe în interiorul unui ERP în varianta adaptată în

conformitate cu legislaţia şi cu practica (cutuma) managerială din România]
În concluzie, dacă ERP-ul sau aplicaţia financiar-contabilă pe care o detineți nu oferă o
parte din aceste instrumente [rapoarte] va fi foarte greu să furnizați către ANAF prin
intermediul SAF-T (D406) aceste informaţii.
Pagina 119/142
19.2. Care s unt rapoartele necesa re î n ERP pent ru a obține SAF-T

(D406) ?
Conform fișierului detaliat [SAF-T_Romania_SchemaDefinitionCodes_actualizata.xlsx]

versiunea 09-07-2021 (reluat în Ordinul nr.1783 / nov. 2021) rapoartele obligatorii sunt:
1. Registrul jurnal general al perioadei raportate (adică toate notele contabile
DEBIT/Credit). În cazul firmelor f. mari acesta poate conține sute de mii sau milioane de
note atomice DEBIT=CREDIT. Dacă ținem cont de faptul că ANAF merge pe GAAP în
D406 şi nu pe modelul francez adică cere linia 1=DEBIT şi linia 2=CREDIT separate
atunci dacă dvs. aveți 900.000 de note pe lună în Registrul Jurnal veți lista către Anaf prin
SAF-t 1.800.000 de linii (unmilionsioptsutedemii).
Pentru exemplificare am extras din documentația oficială doar o parte din câmpurile
prevăzute la Registrul jurnal General [3. GeneralLedgerEntries]:
TransactionID Cross-reference to GL posting. It can contain many different levels to Referință încrucișată la înregistrarea GL. Poate conține mai multe
identify the transaction. It could include cost centres such as company, niveluri diferite pentru a identifica tranzacția. Acesta ar putea include
division, region, group and branch/department. centre de cost, cum ar fi societatea, divizia, regiunea, grupul și
sucursala /departamentul.
Period Accounting Period Perioada contabilă
PeriodYear The year of the Accounting Period. Anul perioadei contabile.
TransactionDate Document date Data documentului
Description Description of Journal Transaction Descrierea tranzacției în jurnal
SystemEntryDate Date captured by system Data capturată de sistem
GLPostingDate Date posting to GL Data înregistrării în GL
CustomerID Unique client code consisting of: type (two decimal places) followed by Cod unic pentru client este format astfel: tip (două cifre zecimale)
the unique client code, as follows: urmat de codul unic al clientului, după cum urmează:
1. 00 followed by CUI - where the type is 00, and CUI is the unique 1. 00 urmat de CUI - unde tipul este 00, iar CUI este codul unic de
identification code for economic operators registered în Romania. identificare pentru operatorii economici înregistrați în România.
The code is an integer, with 1 to 9 digits, followed by a control digit - Codul este un număr întreg zecimal, cu 1 până la 9 cifre, urmat de o
Example: 004221306 - for the Ministry of Public Finance cifră de control - Exemplu: 004221306 - pentru Ministerul Finantelor
Attention! The fiscal attribute "RO" for VAT payers is not included Publice
Atenție! Nu se trece și atributul fiscal ”RO” pentru plătitorii de TVA
2. 01 followed by the country code (according to ISO 3166-1 - 2
letters) and the unique VAT Identification Code of the respective 2. 01 urmat de codul de țară (conform ISO 3166-1 - 2 litere) și de
Member State - for the economic operators from the EU Member Codul unic de identificare pentru TVA din statul membru respectiv-
States, except Romania, verified according to the VIES system (VAT pentru operatorii economici din statele membre ale UE, mai puțin
Information Exchange System) - Example: 01GR123456789 or România, verificate conform sistemului VIES (VAT Information
01HU12345678 Exchange System) - Exemplu: 01GR123456789 sau 01HU12345678
3. 02 followed by the country code and the unique identification 3. 02 urmat de codul de țară și de codul unic de identificare din statul
code of the respective state, which is neither Romania nor EU respectiv, care nu este nici România, nici stat membru UE - pentru
member state - for economic operators from other states than operatorii economici din alte state care nu sunt România sau membre
Romania or EU members - Example: 02TK123005284 UE - Exemplu: 02TK123005284
4. 03 followed by CNP for individuals Romanian citizens or 03 4. 03 urmat de CNP pentru persoane fizice cetățeni români sau 03
followed by the unique personal code for individuals resident în urmat de codul unic personal pentru persoane fizice rezidente în
Romania (same format as CNP, but with the first digit being 7 or 8) România (același format cu CNP-ul, dar la care prima cifra este 7 sau
Pagina 120/142
8)
5. 04 followed by the customer code uniquely associated by the
economic operator, for individuals who do not declare their CNP on 5. 04 urmat de cod client asociat în mod unic de către operatorul
transactions (example: online commerce). economic, pentru pers. fizice care nu își declară CNP-ul pe tranzacții
(exemplu: comerț online).
6. 05 followed by the country code and the customer code
uniquely associated by the economic operator - for the economic 6. 05 urmat de codul de țară și de cod client asociat în mod unic de
operators that are not registered for VAT, from the EU Member States, către operatorul economic - pentru operatorii economici care nu sunt
except Romania înregistrați în scopuri de TVA din statele membre ale UE, mai puțin
România
7. 06 followed by the country code and the customer code
uniquely associated by the economic operator - for the economic 7. 06 urmat de codul de țară și de cod client asociat în mod unic de
operators that are not registered for VAT from non-EU states către operatorul economic - pentru operatorii economici care nu sunt
înregistrați în scopuri de TVA din statele non-UE
Description Description of the Journal Line. Descrierea liniei de jurnal.
DebitAmount Debit amount information for transaction Informații despre suma debitului pentru tranzacție
CreditAmount Credit amount information for transaction Informații privind valoarea creditului pentru tranzacție
TaxInformation Tax information for the accounting line. Informații fiscale pentru linia contabilă.
AccountID This is the analytical account ID based on the standard defined by the Acesta este ID-ul contului analitic creat pe baza standardului definit
Romanian authorities, according to the accounting accounts chart for de autoritățile române, conform planului de conturi pentru societăți
comercial companies (PlanConturiBalSocCom), accounting accounts generale (PlanConturiBalSocCom), planului de conturi aplicabil
chart for credit institutions and non-banking financial institutions pentru instituțiile de credit şi instituțiile financiar nebancare
(PlanConturiBanci), or the accounting accounts chart for insurance (PlanConturiBanci) sau planului de conturi aplicabil pentru societățile
companies (PlanConturiSocAsigurari) de asigurări (PlanConturiSocAsigurari).
2. Balanţa contabilă simplificată la nivel de cont cu sold iniţial /sold final pentru luna
de raportare în formatul conturilor standard conform planului de conturi sintetice publicat
de Mfinanțe. Este vorba de balanţa simplă cu două egalități [4 coloane]. Nu sunt cerute
rulaj lună, total sume etc…
3. Balanţa stocurilor cantitativ valorică pe magazie şi articol. Aici avem o mare
provocare. În documentația ANAF este impropriu trecută Fişa de Magazie dar “îi iertăm”
fiind vorba de Balanţa de Stoc.
Extras din documentația ver.09-07-2021 pentru balanţa de stoc aici:
PhysicalStockEntry Mandatory
WarehouseID Depozitul în care sunt păstrate mărfurile - posibil și pentru identificarea Warehouse card (Fişa de Mandatory
producției în curs sau a stocurilor în tranzit magazie)
LocationID Amplasarea mărfurilor în depozit. N/A Optional
ProductCode Codul produsului Warehouse card (Fişa de Mandatory
magazie)
StockAccountNo Lot de stocuri, lot, serie de identificare. Nu se utilizează atunci când N/A Optional
există exact 1 intrare de stoc fizic per cod de produs
ProductType Pentru a determina dacă produs/contul de stocuri este materie primă, Warehouse card (Fişa de Mandatory
producție în curs de execuție, produs finit, marfă etc. magazie)
ProductStatus Pentru a determina dacă produs/contul de stocuri este scos din Optional
exploatare, deteriorat, învechit, activ etc.
StockAccountCommodityCode Clasificarea pentru import / export NC code Mandatory
OwnerID Referință la Fisier Master Proprietari Mandatory
Pagina 121/142
UOMPhysicalStock Unitate de măsură pentru această poziție PhysicalStock Warehouse card (Fişa de Mandatory
magazie)
UOMToUOMBaseConversionFactor Factorul de conversie a UOM la UOMBase Mandatory
UnitPrice Prețul unitar de bază pentru acest cont de stoc în valuta implicită a Warehouse card (Fişa de Mandatory
antetului. magazine – pret unitar)
OpeningStockQuantity Stocul fizic în UOM pentru perioada de selecție -STOC intial Warehouse card (Fişa de Mandatory
magazine)
OpeningStockValue În codul valutar al antetului pentru perioada de selecție Warehouse card (Fişa de Mandatory
magazine)
ClosingStockQuantity Stocul fizic în UOM pentru perioada de selecție, STOC FINAL Warehouse card (Fişa de Mandatory
magazine)
ClosingStockValue Valoarea finală a stocului în moneda implicită a antetului pentru Warehouse card (Fişa de Mandatory
perioada de selecție magazine)
4. Balanţa Furnizorilor pentru perioada raportată. Aici avem: [2.4 Suppliers] =

Balanţa FURNIZORILOR pentru perioada raportată (lună, trimestru) cu Id furnizor
(CUI/CIF) + cont contabil (4011x) + sold iniţial [OpeningCreditBalance]+ sold final
perioadă [ClosingCreditBalance]
5. Balanţa Clienţilor pentru perioada raportată. Aici avem: [2.3 Customers] =
Balanţa CLIENŢILOR pentru perioada raportată (luna, trimestru) cu Id client
(CUI/CIF) + cont contabil (4111x) + sold iniţial [OpeningDebitBalance]+ sold final
perioadă [ClosingDebitBalance]
6. Toate facturile emise la Clienţi pentru perioada de raportare la nivel de linie
de factură. (În D394 se raportează la nivel de total facturi per client/ per cota tva)
7. Toate facturile primite de la Furnizori pentru perioada de raportare la nivel de
linie de factură. (În D394 se raportează la nivel de total facturi per Furnizor/ per
cotă tva) Vezi: 4. SourceDocuments > 4.1 SalesInvoices [4.2 PurchaseInvoices]>
Invoice structure>InvoiceLine
8. Situația mijloacelor fixe la nivel de nr_inventar [2.12 Assets] [Identificator unic
de inventar al activului] ,cont contabil , PIF [Data punerii în functiune a activului.],
sold iniţial, final inclusiv amortizări perioadă. Se va raporta doar annual şi nu lunar.
Un aspect important în dezvoltarea D406/SAF-T îl reprezintă obligativitatea impusă
producatorilor de software ERP pentru maparea a 22 de nomenclatoare obligatorii
specifice ANAF/SAF-t/D406. Nomenclatoarele sunt cele din excelul de proiect din sheetul
[Centralizator_Nomenclatoare] din:
[SAF_T_Ro_SchemaDefinitionCodes_v414_101121.xlsx] unde găsim 22 de nomenclatoare
obligatorii din 34. Unele sunt ușor de integrat altele sunt f. greu de integrat:
Vezi aici schema nomenclatoarelor:
https://static.anaf.ro/static/10/Anaf/Informatii_R/SAF_T_Ro_SchemaDefinitionCodes_v414_101121.xlsx
Pagina 122/142
20. Stocuri aflate la terți. Custodii. Consigned inventory în ERP.
Din tot lanțul SCM doresc să evidențiez modulul de Consigned inventory deținut de către
ERP-urile mari. Mi se pare un modul inteligent și foarte necesar în ziua de azi.
Din nou doar pentru acest capitol ar trebui să scriem o lucrare separată detaliată.
Modulele de [Consignment] din ERP au o funcționalitate f. complicată dar ajută foarte mult
procesele de descărcare finală a stocului.
În ziua de azi multe din firmele ce au instalat un ERP folosesc module de [Consigned
inventory] pentru a gestiona stocurile aflate în custodie la client, client aflat de obicei peste
mări și țări.
Dacă cauți pe net, Google si frații lui (Yahoo si Bing) îți vor sugera o definiție sumară a
procesului de [Consigned inventory] cam așa:
[…Consignment inventory is a supply chain model in which a product is sold by a retailer, but
ownership is retained by the supplier until the product has been sold. Because the retailer does not
actually buy the inventory until it has been sold, unsold products can be returned...].
Însă funcționalitatea în sine este complexă și implicațiile pe partea de stocuri, contabilitate
și financiar sunt f. mari.
20.1. Consignația din Româ nia a nilor ‘90
O să încep cu ce reprezenta noțiunea de consignație pentru noi ca variantă primitivă de

comerț acum 25 de ani. În limbaj românesc [clasic] procesul economic din anii 90 era
acesta: erau blugii aduși din Turcia de la Istambul de colega noastră de servici Maricica
(cu soțul ei Vasile) în 1995 pe care îi plasa apoi spre vânzare la consignația din colțul lui
Sebastian cu Rahova să zicem la magazinul Sebastian1 care avea în geam blugi printre
napolitane și săpun.
- Maricica plasa 50 de perechi de blugi în consignația Sebastian1 pe bază de proces verbal
de predare primire în consignație la prețul de 1500 lei perechea:50x1500=75.000lei.
- Consignația Sebastian1 făcea un NIR de recepție cu conturi în afara bilanțului [8033 de ex.]
fiindcă mărfurile recepționate (blugii) aparțineau lui Maricica la prețul de 1500. Și mai
completa un Bon de primire în consignație cod 14-3-2 în care se trecea prețul lui Maricica
1500 dar și prețul propus la vânzare de 2000 lei.
- Proprietarul mărfurilor era Maricica până în ziua în care un cumpărător (Dorel, Gigel, Fănel)
cumpăra perechea de blugi de la consignația din colț de la Sebastian1. Blugii erau deținuți
de Maricica pe toată durata procesului până în ziua vânzării;
- Lunar consignația din colț de la Sebastian1 verifica câți blugi a vândut , să zicem că a
vândut 30 perechi x 2000 lei = 60000 lei.
- Periodic (lunar de obicei) Maricica primea valoarea blugilor vânduți până în ziua respectivă
să zicem 30 perechi x 1500 lei = 45000 lei.
- Odată cu cei 45000 lei, consignația Sebastian1 era obligată să facă înregistrarea
comisionul de vânzare 500 x 30 perechi = 15000 ce reprezenta VENIT si TVA-ul aferent
dacă era plătitior de TVA.
- Dacă blugii nu erau vânduți, Maricica putea să îi ia înapoi cam după o lună.
Pagina 123/142
20.2. Descriere p rocese Consig ned inve ntory î n ERP
Exemplu generic. În ERP [Consigned inventory] se folosește mai ales pentru produsele
finite prin care eu producător de [cutii de tablă] de conserve trimit 10000 de cutii la fabrica
de conserve de pește și le depun acolo într-o magazie specială numită pentru mine
magazia client1 iar pentru el (client) magazia furnizor1.
Procesul complet se desfășoară în mare cam așa fără să intrăm f. mult în detalii:
Eu mare producător de cutii de tablă de conserve de pește de diverse dimensiuni și
formate am contracte ferme de distribuție de mii de conseve metalice către clientul:
[fabrica de conseve de pește] pentru anul în curs. Eu (furnizor de cutii) am fabrica la Arad
iar Clientul meu are [fabrica de conseve de pește] în Polonia. Cutiile produse de mine
pentru a fi cât mai aproape de procesul lui de producție am hotărât de comun acord prin
contract să le depozităm în curtea lui și nu în curtea mea. Livrările se vor face periodic
pe măsură ce el mă anunță că a consumat cantități mari și a intrat sau urmează să intre
sub stocul lui de siguranță. Are și el instalat un ERP, poate chiar același ERP pe care îl
am și eu (mai rar).
F.f. interesant și important în acest proces: vom avea o magazie comună care este
magazie comună atât pentru el cât și pentru mine: acea magazie de stocuri în custodie la
client.
Rolul final al ERP-ului meu este să gestioneze cantitativ-valoric acea magazie de custodie
client aflată fizic în Polonia (deci nu în ARAD) dar virtual este stocată în tabele ERP-ului
meu alături de celelalte magazii din ARAD (recepție, producție, obiecte inventar, materii
prime, mărfuri etc…).
Pentru ca și el (client) să poată avea acces în timp real la acea magazie comună am
hotărât ca acea magazie de custodii la client să o gestionăm prin intermediul ERP-ului
meu dar și el va avea acces printr-o interfață WEB, EDI, email și niște declanșatoare
(trigerre) și niște rapoarte la tot ce se întâmplă în acea magazie.
În funcție de natura stocului aflat la terți sunt obligat să folosesc unul din conturile:
351 „Materii şi materiale aflate la terţi”, 354 „Produse aflate la terţi”, 356 „Animale aflate la terţi”,
357 „Mărfuri aflate la terţi”, 358 „Ambalaje aflate la terţi”.
Pagina 124/142
Procesul fizic bazat pe docuemnte și acțiuni se desfășoară cam așa:

1. Eu aprovizionez periodic conform contactului și al comenzilor lansate de clientul meu
acea magazie de custodii [magazia client1] cu cantitățile cerute în zilele stabilite cu
tirul (camion). Eu mut din 345 (finite) de la mine în 354 (stocuri aflate la terți) cutiile
livrate. Eu sunt în continuare proprietar pe acele cutii. Nu am făcut vânzare. Să zicem
ca i-am trimis 10000cutii;
2. El consumă zilnic/săptămânal diverse cantități din [magazia client1] aflată la el în
curte dar pe care el o vede/numește [magazia furnizor1] fiindcă eu sunt furnizorul lui.
Dacă pentru mine cutiile stau în [354] pentru el cutiile stau în afara bilanțului fiindcă el
nu este proprietar [8033 „Valori materiale primite în păstrare sau custodie”]. Să zicem
că a consumat 6000 de cutii;
3. Pe masură ce consumă, el trebuie să treacă totul prin procesul de recepție PO/NIR
301=401, să scadă proporțional 8033 și apoi să dea consumul către producție 601=301
pentru 6000 de cutii. Nu uitați că în exemplul ăsta eu trimit către el finite (345) care
devin temporar (354) și care pentru el în final devin materii prime (301);
4. Periodic mă va anunța pe mine despre ce a consumat și ce trebuie să îi mai livrez
fiindcă a intrat sub stocul de siguranță. Lunar (sau săptămânal) clientul mă va anunța
pe mine furnizor printr-un proces electronic (EDI49, WEB, EMAIL) că a consumat 6000
de cutii;
5. După ce mă anunță, eu trebuie să fac următoarele:
a.) Să îi livrez din nou alte 6000 de cutii pe bază de aviz;
b.) Să fac factură de export/intrastat LIC UE pentru cele 6000 de cutii consumate de el
în producție;
c.) Să descarc stocul lui 354 pentru cele 6000 de cutii consumate.
6. Bineînțeles că ciclul de mai sus trebuie încheiat cu plata/încasarea efectivă a facturii
generate, gestionarea unui/unor avansuri dacă există, Avize și facturi de stornare și
toate notele contabile pentru toți pașii care trebuie să ajungă corect în contabilitate.
Nu vreau să vă spun nimic despre identificarea loturilor cantitativ-valorică pentru

fiecare articol livrat (FIFO cu identificare specifică la ieșire), punctajul pe loturi livrate
prin AVIZ/SO, loturi consumate efectiv de client în procesul lui de producție și loturi
facturate efectiv pe factura finală emisă de mine. Nu uitați că eu trimit loturile precis
identificabile care intră în găleata numită [magazia client1] în mai multe tranșe
succesive. Clientul la rândul lui extrage ce lot vrea din aceiași găleată pentru consumul
propriu prin identificare specifică și nu prin ordinea intrării FIFO/LIFO. Factura mea
finală/lunară se face doar pentru loturile consumate exact de client din [magazia
client1].
49
EDI = Electronic data interchange este un procedeu de schimb de date între două aplicații ERP. La bază are un
fișier plat TXT cu virgulă între câmpuri. Este un procedeu neuniform și proprietar specific fiercărui ERP deși există
“mulți viteji” care ne zic că e un standard. În realitate “fiecare Mărie are pălăria ei” adică fiecare ERP are propriul format
și îl obligă pe celălalt care intră în interacțiune cu el să se alinieze la acel format proprietar. În zilele noastre EDI format
TXT este înlocuit treptat de formate XML. Transmiterea fișierului de obicei se declanșează din ERP-ul sursă care trimite
prin FTP, SCP, Http/curl un fișier direct în “cuibul” destinație adică într-un loc exact (directorX/folderY) aflat pe serverul
Linux al destinatarului. Dstinatarul (beneficiarul) citește periodic (directorulX/folderulY) și culege mesajul EDI primit.
Pagina 125/142
În Erp [Consigned inventory] reprezintă lanțul de funcții, procese și setări ce trebuiesc

executate pentru ca:
a.) procesul de mai sus să se desfășoare corect atât pe partea de stocuri (inventory)
cât și pe partea de documente și contabilitate;
b.) toate documentele necesare să poata fi listate și procesate corect: comenzile
PO/SO, Aviz de expediție cu transfer, consum, retur (mai există și retur pentru
neconforme).
Am adus mai jos o imagine pentru setările posibile pentru Consignment Accounts ce
reprezintă conturile principale prezente în momentele de execuție ale procesului de
consignment așa cum arată ele într-o aplicație ERP. Se observă că în cazul materialelor
aflate la terți pentru combinația de conturi de custodie la client avem contul 351.
O altă setare f. interesantă este bifa [Automatic replenishment] prin care clientul se poate
“servi la discreție” în procesul lui de producție. E bine să fie pusa pe NU.
Pagina 126/142
21. Pamflete despre ERP cu iz economic și mai ales informatic…
21.1. Cizmă ria informatică. Sau c um să vi nzi și mai ales cum să

cumpe ri linia de miră 50 a unui ERP (ve rsi unea o riginală di n
noiembrie 2011)
Toate asemănările cu personaje și întâmplări reale sunt pur întâmplătoare...

Când eram în armată circula un banc cu Bulă care tot trimitea scrisoare acasă din armată
către tatăl său rugându-l să îi trimită bani fiindcă a pierdut din nou linia de miră1 .
Suntem aproape trecuți în 2012 și unii dintre dvs. probabil că

vă întrebați cine e vinovatul în povestea asta ? :
1. Am grersit eu ca șef de proiect ?. De ce oare mă aflu la a III-a (a treia)

implementare nereușită de produs ERP? Și vorba aia nu sunt bugetar deci nu am
luat șpagă de la nici una din firme. Ce să mai vorbim... Eu le-am ales pe toate trei
aproape.
2. O fi greșit patronul ?. Când la nunta verișoarei a aflat că ginerele cumnatului
tocmai se afla în negocieri cu o firmă importantă din capitală care este
reprezentantul unui concern din VEST cu mii de implementări în Antarctica,
Argentina, Angola, Algeria și chiar Papua Noua Guinee și atunci m-a pus să îi
contactez discret pe unii de la noi din cartier care cică și ei sunt foarte multumiţi de
acel ERP renumit ?. Că doar țările enumerate mai sus au sistemul contabil, fiscal și
de gestionare a documentelor identic cu cel din România - cu mici excepții care se
vor corecta fară eforturi mari în timpul implementării desigur.
3. Sau poate nu am fost atenţi la toate detaliile interesante din POWER-POINT-ul pe
care omul de la vânzări ni le-a explicat cu lux de amănunte la cele 5 prezentări ale
produsului (2 la noi și trei la capitală). La una din prezentările din capitală chiar nu a
adormit nimeni fiindcă veniseră și cei de la fabrica de dulciuri și țin minte că ei au
întrebat dacă programul scoate facturi și are liste de prețuri și li s-a răspuns clar că
ăsta e un ERP: "el se ocupă cu MRP (1+2), DRP, EDI, CRM, BPM și multe alte
lucruri cu 3 litere" - deci o factură ar fi un lucru banal. Dar ei au insistat spunând că:
50
Linia de miră = Linie imaginară virtuală. Distanţa dintre aparatele de ochire se numeşte linia de miră iar împreună cu
prelungirea ei până la punctul pe care se doreşte a îl lovi formează linia de ochire. Aparatele de ochire mecanice sunt
formate din înălţător (aflat în partea dinapoi a manşonului) şi cătare (aflată în partea din faţă a manşonului). De regulă,
înălţătorul are forma literei “U” iar cătarea “I”. Pentru o ochire corectă cuiul cătării trebuie să fie centrat la mijlocul
înălţătorului iar vârful lui trebuie să fie pe aceeaşi linie cu umerii foiţei înălţătorului.
Pagina 127/142
au 30 de depozite, 5 facturiste pe depozit, se lucrează în două schimburi, se face și

aviz și factură, se vinde și la persoane fizice, iar mai multe avize se pot închide într-
o factură, marile lanțuri de hipermarket-uri returnează săptămânal multe produse
neconforme etc... Atunci s-a iscat o controversă și din acest motiv nu am putut să
închidem un ochi. Au mai zis ceva de unele facturiste care trebuie să facă și
casă+bancă pe depozitul respectiv, să listeze și nirurile și să avizeze și comenzile
emise din PALM. Li s-a răspuns ca noul ERP rezolvă asta prin "Segregation of
Duties" și să nu fie îngrijorați. Toată lumea a fost de acord aici.
4. Poate e de vină contabila șefă ?. Cred că ea poartă toata vina fiindcă la primul a
zis că dacă produsul scoate balanţa cu 5 coloane e mulțumită pentru început și e
conștientă că se va adapta la raportările românești în cel mult 6 luni. Până atunci ea
scoate în continuare balanţa în programul național - MIEL. La al doilea a zis că în
afară de balanţă ar trebui și cartea mare ca să vadă cum s-au împerecheat
conturile, iar la al III-lea acum a zis că fară fișe cont, fișe de magazie, NIR, Balanţă
de stocuri, carte mare și balanţă cu 5 coloane nici nu discută cu ăștia pe care i-a
adus patronu' (de la nunta cu verișoara). Poate mai târziu o să avem și o balanţă de
clienţi, una de furnizori și până în martie mai mult ca sigur registrul de casă.
5. Sigur a greșit și șefa de la financiar . Fiindca nu a zis nimic niciodată. Doar la a
doua implementare nu i-a plăcut că programul nu lista Registrul inventar al
mijloacelor fixe cu grupare pe locații+deținători și să afișeze și valoarea ramasă.
Mai spunea că reevaluarea trebuia să o faci pt. fiecare număr de inventar în parte și
noi cică avem 5200 inclusiv clădiri, utilaje. Din cauza ei cei cu a doua firmă
furnizoare de ERP au renunțat. A, să nu uit: parcă zicea ceva și de leasing - am
avut vreo 480 de contracte cu 3 firme diferite prin 2007-2008 și toate trebuiau
evidențiate și în EURO.
6. A greșit și omul de la IT. El e bine mersi acum - are firma lui. Poate dacă insista
atunci când au venit primii cu ERP-ul se înțelegea cu ei și făcea el rapoartele alea
de nu le făcea sistemul fiindca era posibilitatea prin ODBC. Dar s-a ținut în gură cu
ei și nu a primit schema logică a bazei de date.
7. Cred totuși că Șeful de depozit de la București a fost unul din artizanii
implementărilor nereușite. Este un bun inginer dar nu are cultură economică
deloc și de aceea nu s-a apropiat deloc de nici unul din cele 3 ERP-uri. Nici nu a
trimis toți oamenii la școlarizare la Vâlcea anul ăsta în august. Și acum ține
evidențele alea în EXCEL+ Acces și are acum un băiat care i-a făcut ceva în FOX
(stocurile parcă.) Zicea ceva de declarația vamală de import (DVI), prețul complet
Pagina 128/142
de aprovizionare, ieșire FIFO sau cu identificare specifică la scoatere, identificare

loturi?!. Nu putea să știe el toate astea. Numai gacica aia pe care a angajat-o prin
2009 l-a învătat. Mai zicea ceva de diferența între prețul de stoc și prețul de
vânzare pe fiecare articol și pe fiecare client - cică asta nu a iesit în nici unul din
programele pe care le-am adus din 2004 și până azi. Dar cred că exagerează.
Patronul nu s-a putut certa cu el fiindcă pe la București se fac 95% din importurile
din Turcia și Japonia - aproape 80% din total produse aprovizionate.
8. Sunt și câţiva din firmă care au fost de acord de fiecare dată când se punea
problema introducerii unui nou ERP. Doar ca noul ERP să fie mai bun decât celălalt
- asta era condiţia. Ăștia sunt băieții de la Plan și cei de la Tehnic. A ! și băieții de la
distribuiţie - cei care fac comenzile pt. Hipermarket-uri parcă au fost multumiţi de
fiecare dată.
9. Cred că am omis pe cineva - este șeful de la Recepţii-Aprovizionare - un mare
nemulțumit: omul ăsta a participat la toate prezentările din 2002 și până azi, a
participat la toate implementările, a fost personal la școlarizare și nu îi convine
nimic: are toată ziua probleme cu inventarele și se puncteză săptămâmal cu șefa
contabilă (o conduce mereu seara după ce fac punctajele) - parcă sunt vorbiţi.
Omul ăsta zice că niciodată scripticul nu a bătut cu fapticul decât la produsele noi
aprovizionate de curând, are mereu în balanţa de stoc din ERP cantitatate ZERO
cu sold negativ. Fişa de magazie nu bate cu recapitulațiile pe documentele
intrate/ieșite ce le ține el în EXCEL. Mai mult: pe contul 371 și 301 niciodată nu au
putut să compare rulajul debitor cu intrările valorice din balanţa de stoc și rulajul
creditor cu ieșirile pe fiecare magazie în parte. Zice că la fiecare inventar trebuie să
stea și sâmbăta și duminica până la 23:00 să facă tot felul de punctaje. A insistat că
la noul ERP să se poată lista recapitulația cantitativ-valorică pe
documente/magazii/conturi și articole - unde o fi văzut el asta ? și la ce i-o trebui ?-
nici unul din ERP-uri nu a avut asa ceva. Eu știu că un ERP știe să primească
comenzi de la clienţi și să lanseze comenzi către furnizor și nici decum să facă
recapitulația documentelor. A ! am uitat - cică are f. multe avize între depozitele din
țară și nu știe niciodată cât este emis, cât este pe drum (contul 481 ) și cât s-a
recepţionat efectiv. Trebuie să aștepte sfârșitul de lună ca să facă asta și a zis ca e
imposibil - lui îi trebuie de azi pe mâine cel târziu. O avea și el parțial dreptate - dar
alții de la firme cu același profil ca și noi parcă nu se plâng așa!
10. Mai sunt câteva fete la contabilitate care sunt nemulțumite: noroc că pe astea
nu le ascultă nimeni. Vor ca să vadă nu știu ce facturi în sold la data cerută de ele
Pagina 129/142
(doar facturile nu și avansurile și cecurile), mai vor cecurile+biletele la ordin

încasate precum și cele aflate pe drum și cele refuzate. Și mai vor să vadă analiza
facturilor pe tipuri de încasări - eu cred că sunt nebune. Ziceau ceva și de registrul
de casă și de deconturile cu salariații - dar EU cred ca NU e o problema asta fiindcă
noi avem doar 30 de case în lei, 14 în valută , 260 de conturi bancare și 1800 de
salariați dintre care doar 350 pleacă în delegaţie - cam 15 pe sucursală. Oricum
fetele astea s-au uitat urât la noi de fiecare dată când am venit cu un nou ERP - nu
știu de ce?
11. Mai avem și operații făcute prin cele 10 magazine proprii - dar de asta se ocupă
una care e cam dusă - nu putem să o dăm afară fiindcă e prietenă cu șefa
contabilă și cică e bună meseriașă - a ținut 23 de firme acasă până să vină la noi
dar acum nu mai are decât 12 că restul au dat faliment și mai cunoaște și pe unii de
la control. Se pricepe la chestia aia cu recepţii în pret de vânzare (inclusiv TVA și
adaos comercial) - ca la butic. Știe să facă și descărcările. Urlă toată ziua că trebuie
să adune nirurile făcute de mână în magazine pe hârtie și a zis că dacă nu suntem
în stare să adaptăm nici ERP-ul ăsta la mecanismul de magazin ea se duce la
patron să îl determine să aduca un program în Fox de la una din firmele ei.
12. Contabila de la postcalculația costurilor e o doamnă - nu a zis nici da nici ba la
nici una din implementări. Ea face și mai toate declarațiile (100, 300, intrastat, 390,
394). Ei i se extrag lunar niște listinguri din program undeva pe 10-15 ale lunii
următoare. EA ia datele, le amestecă în niște exceluri, trage amortizările și salariile
separat și apoi scoate niște situații. Patronul e mulțumit de ea dar nu înțelege de ce
se obțin situațiile de postcalcul la 20-25 de zile de la terminarea efectivă a lunii ? Nu
știm dacă actualul ERP ne poate oferi aceste situații mai devreme. Ne mai gândim.
13. Era și o firmă de informatică locală care ne-a promis ceva prin 2002-2003 -
parcă îl chema GOGU pe domnul acela. Știam că el are deja 4 module
independente: conta, salarii, mijloace fixe+ stocuri care funcţionau atunci la 140 de
firme dintre care 2 ca a noastră și că le va integra pe toate. Urma să facă partea de
facturare și clienţii imediat și un postcalcul la maximum un an de la startarea
implementării. Patronul și contabila șefă nu au vrut fiindcă li s-a părut mult atunci:
30.000 USD + 3000 USD mentenață anuală. Azi dacă ne uitam în urmă am dat:
40.000 pe primul ERP cu tot cu școlarizare, 80.000 pe al doilea la care s-au
adăugat licențele de bază de date vreo 20.000. Se pare că sub 200.000 pentru cel
care se află în derulare acum nu scăpam. Dar o să facem credit pt. hala nouă, intra
niște bani de la UE și o să ne descurcăm. S-ar putea să ne mai ceara 30.000 pe
Pagina 130/142
modificări. La banii aștia nu am trecut sutele de ore muncite de noi în afara

programului și ce a mai suportat patronul pe lângă (mese, cazări, deplasări).
Mai sunt câteva chestii de zis dar mă opresc aici. Eu zic că vina e împărțită. Cel puţin cei
de la firma asta care a venit acum par a fi serioși. Unii dintre consultanți au multă
experientă. Unii au lucrat la Oţelul Galați, Hunedoara și Resiţa deci sunt “oameni grei”, alții
au două facultăţi: matematică + automatică (deci se pricep automat și la economie) iar unii
dintre ei știu engleză (lucru foarte necesar ca să îți iasă balanţa sau fişa clientului). Cred
că putem avea încredere. Au fost drăguți și chiar ne-au atenţionat că dacă băgam
documentele în ordine o să avem balanţă de stoc mai mult ca sigur și o fișă de magazie
curată. Despre ăia de la producţie, auto, obiectele de inventar, salarii și mecanicul șef nu
zic nimic că nu prea îi cunosc - poate în numărul următor. Poate facem și o ședintă când
vin din concediu... PS: în noiembrie am fost la un simpozion la Viena fiindcă m-au invitat
cei cu ERP-ul al doilea (mai ținem încă legătura) și am văzut scris cu markerul pe peretele
din toaletă ceva despre SAAS și Clouding dar momentan țin doar pentru mine.
20.1.1 Epilog, morală (La cizmăria informatică). Rabinul și gâștele bolnave.

În loc de morală am ales un banc care se potrivește cu Cizmăria Informatică:
Iţic avea o sută de gâște. Într-o zi, câteva se îmbolnăvesc și mor. Disperat, Iţic se duce la Rabin:
Rabi, dă-mi te rog un sfat, că-mi mor toate gaștele și mor și eu de foame.
Iţic, uite ce ai dă făcut: dă-le în fiecare zi câte o lingură de apă.
Se apucă Iţic, se chinuie și le dă apă cu lingura, dar degeaba, tot mai mureau.
Se duce iar la rabin.
Rabi, ce mă fac, le-am dat apă cu lingura, dar tot mor.
Mai Iţic, dă-le apă calduță.
Fuge Iţic repede acasă și le dă apă calduță cu lingura, dar tot mureau.
Disperat , se duce iar la rabin.
Oi, oi, rabi ce mă fac ? Îmi mor toate gaștele și mor și eu de foame.
Mai Iţic încearcă cu apă calduță și puţin sărată.
Fuge bietul Iţic acasă și le dă gaștelor apă calduță și puţin sărată, chinuindu-se, cu
lingura.Tratamentul nu are nici un efect și îi mor toate gaștele.
Disperat, se duce la rabin.
Oi, oi , oi vis mir, ce mă fac, mi-au murit toate gaștele, am să mor și eu de foame.
Mai Iţic, eu sfaturi mai am , dar nu mai ai tu gâște.
Pagina 131/142
21.2. Cu cotu’ pe tastatură. Sau c um să nu faci aplicaţii economice

tâmpite ca să nu fi î nj urat de utilizat ori.
( Cizmăria informatică 4 ) - Acesta e un pamflet în care toate personajele sunt reale.
Era în luna octombrie 1996 la TIB, la Romexpo. Trăgeam cu ochiul la unul din puţinele
ștanduri cu profil de informatică economica ale acelor timpuri. La ștandul respectiv un
reprezentant al firmei făcea o prezentare live a programului de contabilitate în fața unui
vizitator pe un PC 486. Ștandul era "open space" (deschis), drept pt. care m-am apropiat
la 1 metru de ei și am urmărit probabil 10 minute prezentarea. Eram chiar invidios pe cei
doi (că aveau servici bun) deoarece cu două săptămâni în urmă depusesem un CV prin
fax la firma prezentatorului.
Înainte de a trece la subiect încerc să explic puţin contextul acelor
timpuri referitor la programele de contabilitate:
- Toate programele de contabilitate de pe piața româneacă la acea vreme erau scrise sub
compilatoare de MS-DOS (FoxPro2.x, DbaseIV, Clipper, Paradox, TurboC,
TurboPASCAL);
- Toti producătorii de software economic din gama programelor de contabilitate erau 99%
ingineri automatiști, matematicieni sau rar, absovenți de cibernetică. Aceștia proveneau
din centrele de calcul ale marilor întreprinderi și imediat după 1990 au găsit această
oportunitate în mediul privat. Puţini dintre ei racolaseră însa și un contabil care să le arate
calea cea dreaptă și să le "deseneze" puţin cum e cu debit=credit, cum e cu NIR-ul cu
bonul de consum, cu balanţa sau cu registrul de casă. Învățaseră economie și contabilitate
cot-la cot cu utilizatorii cărora le instalaseră programele și la fiecare instalare nouă exista
un prilej de a-și îmbogați cunoștințele - era o descoperire continuă (discovery approach)
care se practică și azi;
- Nu existau la vânzare decât module independente care nu comunicau în timp real între
ele (fiind necesare prelucrari pt. transfer). Cele mai populare module erau: Contabilitate
Generala, Stocuri, Mijloace FIXE, Registru Casa, Salarii. Programe precum Facturare
Clienţi și Gestiune facturi Furnizori erau "suplimente";
- Nu existau pagini de WEB de net unde în 5 minute să îţi dai sema că softul există sau
NU, dacă e bun de ceva sau să ceri părerea cuiva pe un forum (adică să întrebi dacă te
apucă noaptea până bagi o factură în aplicaţia X sau Y). Nu aveai de unde să afli dacă
firma producătoare este abonata ministerelor, a dat țepe la licitații unde caietul de sarcini e
Pagina 132/142
cu dedicație, dacă softul a fost făcut PROST în 5 ani pe 100.000.000 de USD în loc să fie
făcut BINE în maxim 2 în doar 10 milioane s.a.m.d. Nu aveai de unde să ști că softul este
pe o concepție anglo-saxonă venit de undeva din vest și nu vei vedea în viața ta o balanţă
de stoc, balanţă contabilă cu 4-5 egalități, carte mare sau registrul jurnal general. Totul era
"o taină" pe care numai "iniţiații" o stăpâneau. Totul circula pe cale orală la o bârfă;
- de "afară" intraseră puternic CIEL și WIZROM cu variante traduse și încercau localizarea

pt. Romania.
- dintre producătorii români care intraseră pe piață la acea vreme enumerăm câţiva:
NaumConsalt (București), Crisoft (Brașov), Emsys (Prodinf Pitești), Buzău Soft (Sava);
- Nu exista nici o implementare de produs ERP completă nici la stat și nici la particular.
ERP-urile au intrat mai tarziu;
- la Universitate și la Sf.Gheorghe bișnițarii vindeau de zor CIEL-ul spart de hackeri pe 3

dischete;
- Oficiile de calcul și Centrele de Calcul încă mai existau și întrețineau programe scrise in-
house și aici menționez mai ales programele de salarii, mijloace fixe și cele de urmărire a
producţiei tip PPUP.
Să ne întoarcem acum la cele două personaje din ștandul de la TIB.
Gazda stătea jos pe scaun iar vizitatorul stătea degajat în dreapta lui în picioare punctând
cu degetul direct pe ecran către diverse căsuțe ce apăreau pe măsură ce gazda naviga de
la un ecran la altul. Dacă nu te prindeai ai fi zis chiar că sunt prieteni sau colegi de firma.
La un moment dat se iscă dialogul următor (am mai băgat puţin și de la mine):
Vizitatorul: Am vazut ca aveți modulele de bază ce trebuie unei firme din RO și că

majoritatea ecranelor sunt traduse în Româna. Totuși navigarea lasă de dorit.
Gazda: Haideți dom'le cum lasă de dorit? - v-am aratat că avem ecrane de introdus date
pentru toate problemele de care m-aţi întrebat. Ce nu vă place?
Vizitatorul: …ia ramâneți puţin aici la ecranul cu bonul de consum.
Gazda: Aici e bine? Spuneți ce să fac!
Vizitatorul: Vă rog să apăsați succesiv pe tastele F1, F2 și F10
Gazda: La... la F1 o să apară helpul în Engleză.
Pagina 133/142
Gazda apasă apoi pe F1 apoi pe F2 și apoi repede pe F10. După F1 (HELP), la apăsarea
lui F2 și apoi F10 pe ecran apar mesaje de eroare și de avertisment în engleză cu
diverse semnificații și fară opțiune de închidere (adică fară OK, CANCEL, IGNORE
s.a.m.d)
Vizitatorul: Păi de asta v-am pus să apăsați pe F2-F10. Ce ar trebui să facă utilizatorul
acum ?
Gazda: Păi utilizatorul nu apasă pe F2 sau F10 dom'le, el apasă numai pe ce zicem noi. Și
uite dacă a apăsat aiurea trebuie să apese pe CTRL+F7 apoi pe ESC iar apoi pe ALT+F2
și iar pe ESC și gata se rezolvă. Apasând pe F2 și F10 au fost activate rutinele de salvare
forțată!
Vizitatorul: Și după aia se duce să se culce nu ? Ce îl interesează pe utilizator de

rutinele dvs. de salvare forțată? El trebuia să introducă un prăpădit de bon de consum.
Gazda: Faceți mișto ? Utilizatorul va fi instruit de către consultanții nostri la școlarizare.
Vizitatorul: A! și văd că acum după ce aţi închis ferestrele, programul nu s-a întors înapoi
pe linia bonului de consum ci pe final și te întreabă dacă salvezi datele? Păi ce să salvezi
dacă tu nici nu ai terminat bonul? Trebuia să te întoarcă pe linia bonului!
Gazda: Nu e nimic - o să iasa din bon, o să listeze bonul cu liniile de pâna acum apoi o să
îl storneze și apoi o să-l mai introducă o dată.
Vizitatorul: - Deci dacă am 50 de linii pe fişa limita și greșesc că am apăsat din greșală
pe F2/F10 după primele 30 mă duc și stornez și apoi le mai bag o dată?
Gazda: Hai dom'le că asta se întâmplă doar la început că după aia lumea știe ce are de
făcut!
Vizitatorul: Bine. Mai facem un test?
Gazda: Da dar nu mai apăsăm pe tastele funcţionale.
Vizitatorul: Intrati într-un nou bon de consum. Tot în bonul ăla vechi sau creați altul.
Gazda: Nu mai pot intra în cel vechi - fac altul acum. Gata am făcut unul nou - ziceţi ce să
mai fac.
Vizitatorul: Pot să fac eu ceva?
Gazda: Da faceți.
Vizitatorul deschide larg degetele de la mana dreaptă și apasă cu toate simultan pe

tastatură: cu mijlocul palmei fiind pe ENTER, degetul mare acoperă literele K-L, arătătorul
acoperă BACKSPACE/=, mijlociul acoperă HOME/END iar degetul mic+inelarul se duc
peste tastatura numerică din dreapta. Efectul imediat a fost că pe ecran au început să
joace două ferestre una albastră și alta roșie succedândus-se una după alta însoţite de un
piuit lung și de unul scurt.
Pagina 134/142
Gazda: Hai dom'le că nimeni nu e nebun să facă tâmpenia asta să apese cu palma pe
tastatura! Oamenii sunt atenţi că lucrează cu cifre...Și apoi au răspundere. Pot fi daţi afară.
Vizitatorul: Mai aveți de lucrat la interfață. Noi la oficiul de calcul nu am ajuns la

performanța dvs. privind succesiunea funcțiilor și a ecranelor dar pe ce apeși e sfânt.
Dacă stai cu cotu’ pe tastatură (indiferent pe ce tastă îti scapă cotul) programul îți va da un
mesaj de eroare spunandu-ți exact în ce casuță te afli ce trebuia să introduci acolo. Îţi
apare o fereastră de avertisment cu aceste mesaje cu un buton de revenire în centru care
te va reîntoarce exact în ultima căsuță din care s-a declanșat eroarea.
Și fiindcă lumea e mică sau în loc de PS:
Despre GAZDĂ: Firma unde am depus CV-ul nu m-a chemat. Am luat contact însa cu
programul lor la alte implementări în ţară de mai multe ori. Dacă în programele lor stai cu
cotul pe tastatură și acum apar fereastra roșie și cea albastră (sunt rău aici: azi în 2016
nu prea mai sunt implementări pe MS-DOS active, dar prin 2009 încă erau);
Despre Vizitator: M-am intersectat cu el în 1999 la un interviu (un fel de casting în

informatică) unde m-am și angajat. I-am adus aminte de momentul din 1996 - el nu și-a
mai adus aminte. El nu a rămas să se angajeze cu mine după casting fiindcă a spus că
știe sigur că și programul ăstora la care urma să ne angajăm la ei, dacă stai cu cotu' pe
tastatură intră în bălării…
21.3. ERP- ul l ui Ha ns și ERP- ul l ui Vasile – Secțiune pamflet:
Vă mai aduceți aminte de Hans și Vasile, cele două personaje care fac pâine din
capitolul cu cele doua tipuri de economii: introvertită și extrovertită? Copii lui Vasile
mai au ceva de făcut în anii următori - vezi în continuare.
Statul lui Vasile stie că dacă Vasile s-a născut trebuie neapărat impozitat fiindcă
respiră, dacă casa lui Vasile are un coș de fum (chiar dacă nu are bani să cumpere
lemne) îi va pune impozit pe fum (vezi fumăritul- impozitul pe fum din Evul Mediu şi
taxa lui Pogea: impozit minim de 550 lei/trimestru din 2009). Vasile nu va fi în stare să
producă nici o pâine, dacă va produce o pâine, statul i-o va lua. Vasile va fi obligat să
ascundă pâinea produsă şi să se împrumute de cele mai multe ori de la Hans (import).
Dar ce facem cu paznicii cetății51 fiindcă vor şi ei o pâine?. Dacă cumva Vasile doar se
gândește să nu dea o pâine şi “paznicilor cetății” sau cumva a sărit gardul la Hans să
împrumute o pâine atunci e de rău: Vasile va primi amendă sau va face poate şi
închisoare. La proces Vasile va spune: dar nu am apucat să fac nici o pâine deci nu
am cum să vă dau şi vouă o pâine (paznicilor).
51
Platon – Republica
Pagina 135/142
Despre frații lui Vasile: unul a plecat în Spania, altul joacă toți banii la păcănele. Fratele
cel mare a încercat cu un magazin de cartier (butic), apoi cu termopane, a avut şi o
mică firmă de TAXI dar nici una nu a supraviețuit, acum se ascunde de portărei la
mama ca să nu plătească ratele de la împrumutul de la bancă. Şi azi îi pare rău că a
refuzat “intrarea” la “paznicii cetății” când i s-a propus asta de către un “civil” când a
terminat liceul cu 20 de ani în urma.
Rezolvarea ecuației economice de mai sus prin antamarea viitorului copiilor lui
Vasile: Dacă Hans vine în vizită la Vasile şi uită din greșală geanta cu bani în tren sau
aeroport aceasta este scoasă la licitație. La licitație nu participă decât copiii paznicilor
cetații. Copiii lui Vasile nu află decât după mulți ani de la copiii lui Hans că tatăl lor
(Hans) a uitat cândva o geantă cu bani pe peron şi ca ei (copiii lui Vasile) ar trebui să le
dea măcar ceva din suma aia în rate mulți ani de acum încolo. Copiii și nepoții lui
Vasile vor trebui să plătească în anii următori împrumuturile făcute de “paznicii cetății”.
În concluzie:
ERP-ul facut de Hans nu este potrivit pentru Vasile deoarece viața lui Vasile este ocupată
preponderent de activitățile specifice nivelului 1+2 din piramida lui Maslow52 (economie de
supraviețuire)
ERP-ul se implementează greu la Vasile deoarece acestuia nu îi stă mintea la “tainele”
ERP-ului ci la viața de zi cu zi şi la cum să amâne sau sa eludeze taxele şi impozitele.
Totuși dacă reușește să plătească ceva din taxe şi impozite acestea se duc direct la copiii
paznicilor cetății.
52
Abraham Maslow (n. 1 aprilie 1908 – d. 8 iunie 1970) a fost un psiholog umanist american. Este cunoscut pentru
bazele teoriei privind ierarhia nevoilor umane sau piramida lui Maslow ce conține în varianta originală 5 niveluri.
Ulterior cele 5 au fost rafinate de epigonii acestuia şi au devenit 7 niveluri.
Pagina 136/142
22. Anexe cu formate de rapoarte utile din diverse module din ERP
Declarație de confidențialitate.
Anexele prezentate în continuare au scop didactic si informativ pentru a prezenta forma și
fondul acestor rapoarte.
Ele sunt extrase din aplicațiile ERP sau de postcalcul instalate la diverși clienți.
Pentru a menține confidențialitatea datelor numele firmelor, unele conturi, centre de cost
și/sau valori sunt înlocuite cu denumiri fictive de test.
Fiecare ANEXA este prezentată pe câte o pagină separată.
Toate rapoartele din ANEXELE de mai jos se pot rula filtrat pe majoritatea câmpurilor
prezentate contextual în fiecare raport.
Exemple:
Putem filtra doar contul 601 cu sau fară contul de clasa 9: [921] sau numai centrul de cost
Sectia_2 sau numai articolul surub [Surub_0001234]. Raportul ne va prezenta în subsol
recapitulațiile valorice și Totalul General doar pentru selecția facută.
Pagina 137/142
22.1. ANEXA 1. Raport combinat Co ntabilitate cu analiză preț de

stoc (cost) vs preț vânzare factură.
Analiza preț stoc (cost) vs preț vânzare Facturi.
În majoritatea aplicațiilor ERP anglo-saxone bazate pe principiile GAAP și SCM vom găsi în tabela specifică
liniilor de factură livrate la client (de obicei după shipping și postare finală factură/aviz) pe lângă câmpul
specific prețului real de vânzare (fară TVA) și un câmp special numit cost articol (prețul de stoc pe
românește). Raportul este generat automat dintr-o aplicație ERP. El poate fi listat în: PDF, HTML, Ecran sau
direct în EXCEL. Am ales varianta excel pentru a înțelege mai ușor conținutul acestuia.
Ce însemnă asta generic? Că articolul vândut la client cu prețul de 5 lei s-a descărcat din stocul nostru cu
valoarea de 3 lei. Adică am cumpărat (sau am produs ceva) cu 3 lei și am vândut altuia (client) cu 5 lei
rezultând un profit (marjă zic americanii) de 2 lei per unitate.
Exemplu din raportul de mai jos cu explicații. Raportul de mai jos ne spune că: - în
ziua de [03-06-21] a fost livrată comanda [COMA3112] cu factura [FACT913662 ], pe linia nr.
[1] avem articolul vândut [CALOR1056748066] cu descărcarea de gestiune contabilă
[711=345] , contul de venit folosit [701] , cantitatea descărcată/vândută [10] la preț de stoc
[40,71], preț de vânzare [112,27] , diferență per unitate [71,56], diferență valorică pentru 10
bucăți [715,61], către clientul [PLEIADE IMP.EXP.Ilfov SRL], punct de lucru (livreaza_la): [ Sucursala
OLT] cod fiscal [916001] de către agentul nostru de vânzări [MARIAN] din magazia [LIV99].
Nota: În unele ERP-uri costul articolului descărcat este adus instant de program în momentul postării facturii
(blocare) pe linia de factură/SO alături de prețul de vânzare din una din sursele prețului de stoc posibile în
funcție de metoda de stoc folosită (Standard, CMP/AVG sau Fifo cu identificare specifică) astfel: din prețul
de stoc stocat pe lotul respectiv, din costul curent pe sait/magazie principală, din costul PO, din costul ultimei
tranzacții de recepție etc… În alte ERP-uri este necesară rularea unor funcții complicate târziu după ore/zile
de la petrecerea ieșirii efective din stoc spre vânzare pentru completarea acestui câmp de tip [SO_cost] care
inițial poate fi ZERO/0. Depinde aici și dacă magazia de vânzare/livrare e pusă/setată pe negativ [oversissue
locations = Yes = întâi ieșiri și apoi intrări].
Pagina 138/142
22.2. ANEXA 2. Postcalcul – Bala nța cont abilă anuală cu rulaje pe

cele 12 luni: clasa 6 combinat c u conturi de clasă 9: 921, 922,
923, 924, 925
Exemplu de balanță contabilă detaliată pe rulajele conturilor de clasă 6 ventilate simultan
pe conturile de clasă 9 pe fiecare din cele 12 luni ale anului 2017 (Rulaj1, rulaj2…rulaj12 ).
Rulajul anual din dreapta este suma rulajelor contului 6/9 pe fiecare din cele 12 luni.
Rulajul lunar trebuie să bată cu debitul contului de clasa 6 din rulajul lunar al contului din
Balanța contabilă lunară (4,5,6 egalitati) sau din Fișa Contului lunară.
Zona de Detaliu pe combinatia conturile de clasa_6/clasa_9/Luna1…12/Rulaje_AN
Zona de Total cu grupare pe conturile de clasa 9/Luna1…12/Rulaje_AN
Pagina 139/142
22.3. ANEXA 3. Postcalcul. Raport Ce ntralizator l una r costuri:

Clasa 9, Cont Debit(6) , Cent ru Cost. Selecție pentru Secția_nr_2
Total Sectia2,
centru cost 51
Cheltuieli
directe 921
Total Sectia2,
centru cost 51
Cheltuieli indirecte
923
Total Sectia2,
centru cost 51
Cheltuieli indirecte
923 - alte
Total GENERAL
Sectia2, centru
cost 51
Cheltuieli
921+923
Pagina 140/142
Bibliografie (scurtă):
Economie, organizare, contabilitate:
Bașanu Gheorghe, Pricop Mihai - Managementul aprovizionării şi desfacerii, litografiat ASE 1992 şi Ed. Economică – 2004,2012
Bologa Razvan, Lupu Ana Ramona, Sisteme Enterprise Resource Planning (ERP). Elemente introductive, Editura ASE – 2012
Dragan C. M., Noua contabilitate manageriala, Ed. Hercules – 1992
Dumbravă Partenie, Pop Atanasiu, Contabilitatea de gestiune în comert şi turism, Intelcredo Deva -1995
Feleagă Niculae, Sisteme contabile comparate, Vol. I, Vol. II, Vol. III, Editura Economică – 1999, 2000
Feleagă Niculae, Dincolo de frontierele vagabondajului contabil. Contabilitatea franceză între tradiţie şi modernitate, Editura
Economică, Bucureşti, 1997
Hofstede Geert, Managementul structurilor multiculturale: software-ul gândirii, Editura Economică - 1996
Nicolescu O., Burdus E.,Zorlentan T., Caprarescu G., Verboncu I., Cochina I – Management – Ed. Didactica şi Pedagogica – 1992
Nicolescu Ovidiu, Management comparat, Editura Economică – 2006
Posler Ladislau, Lambru Gheorghe, Lambru, Bogdan - Contabilitatea Întreprinderii , Editura: Fundaţia Andrei Saguna – 2010
Radu Ioan, Ursăcescu Minodora, Ioniță Florin - Informatica Pentru Managementul Firmei - Ver. 1996-1998.
Informatica:
Dima Mihai, Dima Gabriel, - Foxpro (Foxpro/LAN 2.0) – Teora 1995 (seria Calculatoare personale)
Dumitrascu Liviu, Sperlea Traian, Marinoiu Cristian - dBase II, III, III+, IV, Editura Tehnica – 1991
Long Jeb - FoxPro 2.6 pentru Windows. Ghidul programatorului - Teora -1994
Microsoft Press - Microsoft Visual FoxPro 6.0 : Ghidul programatorului (Programmer's Guide 1998) – Teora - 2000
Tamas Ilie, Popa Ghe., Berbec F., Vrîncianu M., Glavan N. - Sisteme de gestiune a bazelor de date : Visual FoxPro –Cison- 2000
Welling Luke, Thomson Laura - Dezvoltarea aplicaţiilor Web cu PHP şi MySQL, editia a II-a, Teora – 2005
Wynkoop Stephen - Totul despre Microsoft SQL Server 7.0, Teora – 2001
Legi, Ordine:
Ministerul Finantelor, Sistemul contabil al agentilor economici, 1994 republicat şi actualizat.
Ministerul Finantelor, Ordinul nr. 3512/2008 privind documentele financiar-contabile.
Ministerul Finantelor, Ordinul nr. 2634 din 5 noiembrie 2015 privind documentele financiar-contabile.
Ministerul Finantelor, Ordinul preşedintelui ANAF nr.1783 din 04.11.2021, declarația SAF-T/D406
Alte Documentații electronice publice (pdf, doc,html):

Atkinson Ray, Enterprise Resource Planning (ERP) The Great Gamble An Executive’s Guide to Understanding an ERP Project,
XLIBRIS Australia (June 26, 2013)
Autorité des normes comptables (ANC), Plan comptable général (France) [versiunea ianuarie 2019, Règlement n° 2014-03 du 5
juin 2014 , https://www.anc.gouv.fr/sites/anc/accueil.html ]
Chunhui Liu - International Review of Business Research Papers Vol. 5 Sep. 2009 – (SEC release no. 33-8879)
Fotache Doina, Hurbean Luminiţa - Platforme integrate pentru afaceri. ERP – 2013
Fotache, D., Hurbean, L., Păvăloaia V., Dospinescu O. – Soluţii informatice integrate pentru gestiunea afacerilor – ERP, 2004
Neamţu Ion-Horia, Teiuşan Sorin-Ciprian, ASE, 2006 - Normarea Şi Normalizarea Contabilităţii De Gestiune La Nivelul
Întreprinderii
Petrache R.,Amohnoae S., Cucuruzac M.,Moldovanu V., Contabilitatea anglo – saxonă versus contabilitatea continentală:
asemănări şi deosebiri, UAIC - Iași, Facultatea EAA, CEA, SCC
Savu F.M., Scarlat A.M., Sobe Mira I., Evoluţia Contabilităţii Româneşti după 1989 – Repere Cronologice, Coord. ştiinţific:
Marian Săcărin, ASE Facultatea CIG, anul II, grupa 637 - aprilie 2013
Sîrbu Florentina, Sistemul contabil românesc, curs, Universitatea Tehnică “Gheorghe Asachi” Iaşi , 2013
Oracle Corporation, Applications JD Edwards EnterpriseOne,Guide de mise en oeuvre de localisation pour la France,
Version 9.1.x, E60270-01, Juillet 2014, Copyright © 2014, Oracle et/ou ses sociétés affiliées. Tous droits réservés.
Oracle Corporation, Applications JD Edwards EnterpriseOne Guide de mise en oeuvre de localisation pour la France,
ORACLE help center, Documentation, https://docs.oracle.com/cd/E39124_01/doc.91/e60270/fr_work_w_func_france.htm#EOAFR3748 , Copyright © 1995,
2019, Oracle and/or its affiliates.
QAD Inc., MFG/PRO eB2 Technical Reference Entity Diagrams, Copyright © 2002 by QAD Inc.,78-0554A, Santa Barbara
QAD Inc., QAD Enterprise Applications Enterprise Edition - Technical Reference Entity Diagram, Santa Barbara
QAD Inc., User Guide MFG/PRO eB2.1 New Features - 2005, Copyright © 2005 by QAD Inc.78-0608C, Santa Barbara
QAD Inc., User Guide QAD Romania Internationalization Extension, QAD Enterprise Applications 2014 and higher Enterprise
Edition, June 2018, 70-3317-2.1, Copyright © 2018 by QAD Inc.
Pagina 141/142
ERP - Ghidul curiosului (și alte lucruri care nu interesează pe nimeni) - EDIŢIE ONLINE PDF, 2021
ISBN978-973-0-35754-7
Pagina 142/142

Erp Ghidul Curiosului (Și Alte Lucruri Care Nu Interesează Pe Nimeni)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Erp Ghidul Curiosului (Și Alte Lucruri Care Nu Interesează Pe Nimeni)

Încărcat de

Drepturi de autor:

Formate disponibile

E R P - G h i d u l c u r i os u l u i

Titlu: ERP - Ghidul curiosului

Autor: Ionescu Bogdan

EDIŢIE ONLINE PDF, 2021

Versiunea conținutului inițial: 13-12-2021

15. 3. P ro gram ul d e pos t c al c ul c a apl i c aț i e ext ernă E RP 91

1. Cuvânt înainte – Cui i se adresează acaestă lucrare?

Cartea se adresează mai ales mediului economic: directorilor economici, contabililor,

2. Ce tratează acaestă lucrare?

Documente primare simplificat (Profit and

3.1. Perioadă apariţie – 1970-1980 ca aplicaţii locale

3.2. Departajarea firmelor, sub unităţilor sau filialelor aflate în

În structura de mai sus marile dezavantaje sunt:

Avantajele aici sunt:

Se observă că [Baza date de agregare (9999)] este înlocuită aici de [Firma de

Marile avantaje ale acestei variante sunt:

3.2.2 Practică folosită pentru raportare în cazul bazelor mari unde

date). Copierea (backup) durează şi timpul de copiere crește în minute de la un an la

La nivel de tranzacţie atomică în cazul folosirii aributului [Firma/Company/Domeniu],

3.2.4 Tehnica de salvare lunară a tabelei de solduri finale versus soldul/stocul on

NOTA. Observație importantă:

b.) Performanței interogărilor şi aici punctual ne referim la timpii mari de obținere a

Întorcându-ne la [Consitența interogărilor] care are mare legatură cu

3.3. ERP ca siste m i nformatic ve rsus sis tem informaţional

Întotdeauna se dă vina pe consultantul/analistul de business că nu cunoaște “tainele ERP”

3.4. Cu ci ne seama nă ERP- ul ?. Erp-ul se amănă c u [pări nţii] săi.

3.4.1 Primul cobai şi Născătorul de aplicaţie

Totul a pornit de la o funcţiune-modul şi s-a extins către celelalte funcţiuni. Domnul

3.4.2 ERP-ul şi verticalele de afaceri versus cheia franceză bună la orice.

1. Versiunea cu verticalele de afaceri.

de preferat a fi aleși să vă prezinte aplicaţia lor şi apoi eventual să o şi implementeze la

3.4.3 ERP-ul, sofismele15 şi viciile de consințământ – DOLUL16.

Ce legătură au DOLUL şi sofismele cu Erp-ul?

Dolul împreună cu celelalte vicii de consimțămînt (eroarea, violența şi leziunea) sunt

3.4.4 Cum aleg un ERP pentru organizația mea?

Azi internetul este plin de sfaturi oferite de consultanți și specialiști independenți și

3.5.1 Să începem puţin cu APICS. Gestionare Stocuri [Inventory]

Acum vin întrebările legitime:

APICS sunt formate din urmatoarele 5 principii cunoscute și ca principii SCM

https://www.ascm.org/ (fost www.APICS.ORG)

3.5.2 Alţi termeni folosiţi: PO, AP, AR, SO, WO.

3.6. Alte partic ula rităţi specifice [T hree-Wa y Matc hi ng PO],

3.6.1 Legătura PO>Nir>Final Ap Invoice numită și [Three-Way Matching în

utilizat impreuna cu metoda cantitativ-valorica) versus inventarul intermitent (rar utilizat

Funcțional și operațional la o primă vedere [superficială], pe românește reprezintă

factură de transport atunci procesul de alocare al acestor costuri suplimentare este f.

3.6.2 Variaţiile PO>Nir>Final Ap Invoice [Factura furnizor]

3.6.3 Operarea nirului și a facturii [Factura furnizor] în România și în lume

Linia6 -rotor piese schimb strung = 3024

Observaţie importanta [accrual clearing account vs. 408]:

Pentru a evita procesul complicat de [accrual clearing] unele Erp-uri au adoptat

3.6.4 PPV vs Three Way Matching PO vs Standard Cost vs Ap Invoice (factura

3.7. T ranzacţiile în ti mp real – fals ă abordare. Efecte în

Tratarea modului în care ERP-ul operează sau nu tranzacţiile în timp real se

Exemple cu tranzacţii care NU sunt în timp real [b]:

Am întâlnit următoarele afirmaţii false promovate atât de producătorii români de

terminalul știe că [cutia de viteze de Mercedes SL200] a fost mutată de la operaţia

Aplicaţiile ERP de origine continentală (franceză şi românească) imită în primul rând

balanţa cu 4-6 egalitati), Registrul de casă/bancă, Registrul Jurnal General debit=credit şi

3.8. Recunoașterea ve niturilor ş i a c helt uielilor în ERP [Cas h vs.

3.9. ERP- ul, pe narul și laptopul sau cu ce dispozitiv accesăm o

3.9.2 Ce legătură are ERP-ul cu penarul și laptopul?

3.9.3 Despre utilizarea Tastaturii clasice [IBM 105 keys]