roacont/docs/cercetare/piata_ai_2026_09/BACKTEST_VENDING.md

Backtest pe productie: schemele VENDING si ROMFAST, 12 luni reale

Subiectul "banca" (identificare partener/factura la import extras) e tratat separat, cu masuratori valide, in BACKTEST_BANCA.md.

Sectiunile 1-5 sunt masurate pe VENDING. Sectiunea 6 repeta acelasi backtest pe ROMFAST (alt server, alt profil de firma) si compara.

Data: 03.09.2026. Instanta: XEPDB1 (Oracle 18c XE), schema VENDING, prin tunel SSH (D:\roa\BITVISE\vending.tlp, alias TNS VENDING). Strict read-only - doar SELECT. Interval: 01.09.2025 - 31.08.2026 (12 luni incheiate). Scripturile care au produs fiecare cifra sunt in sql\bt_*.sql din acest folder si se pot rula din nou.

Aceasta e prima masuratoare pe date reale din toata cercetarea. Rundele anterioare foloseau MARIUSM_AUTO, o schema de proba cu 1174 de linii si campuri "TEST" - cifrele de acolo nu insemnau nimic.

---

1. Cat de mare e clientul

Marime	Valoare
Linii in ACT, total istoric	1.309.438
Documente in ultimele 12 luni	~39.300
Facturi de intrare (credit 401) in 12 luni	1.864 (~155 pe luna)
Furnizori distincti in 12 luni	263
eFacturi primite in 12 luni	1.672 (~140 pe luna)
Linii de banca in 12 luni	26.894 (~2.300 pe luna)
Linii de casa in 12 luni	~3.240

Facturile de intrare sunt simple: 1.195 din 1.864 au exact 2 linii, 263 au 4 linii. Doar 11 documente depasesc 15 linii. Concentrarea pe furnizori: top 20 acopera 38,9% din facturi, top 50 acopera 62,4%, top 100 acopera 84,9%.

---

2. Backtestul de contare pe istoricul furnizorului

Metoda. Pentru fiecare factura de intrare din ultimele 12 luni se construieste o semnatura: lista sortata a conturilor de debit distincte ale documentului, fara conturile de TVA (442x). Se prezice semnatura din documentele anterioare ale aceluiasi furnizor (fereastra de istoric: 36 de luni), niciodata din viitor. Se compara predictia cu ce s-a contat efectiv.

2.1 Regula simpla: cel mai frecvent tipar anterior al furnizorului

Verdict	Documente	Procent
Potrivit, cu cel putin 3 documente anterioare	1.294	69,4%
Gresit, cu cel putin 3 documente anterioare	358	19,2%
Potrivit, cu 1-2 documente anterioare	68	3,6%
Gresit, cu 1-2 documente anterioare	54	2,9%
Furnizor nou, fara istoric	90	4,8%

2.2 Cu poarta de incredere: cat de strict trebuie sa fie "verde"

Se exclud documentele a caror semnatura de debit e chiar 401 (compensari si corectii, nu facturi de cheltuiala): raman 1.817 documente. "Verde" inseamna ca ultimele N documente ale furnizorului au avut toate aceeasi semnatura.

Prag	Acoperire	Precizie
ultimul document	95,0%	81,9%
ultimele 2 identice	75,7%	91,9%
ultimele 3 identice	67,8%	94,9%
ultimele 5 identice	59,2%	96,2%

Impartirea pe zone la pragul de 3: verde 65,2% din facturi cu precizie 93,4% (119 furnizori), galben 29,9% cu precizie 51,3% (153 furnizori), rosu 4,8% (90 de furnizori noi).

2.3 Ce se greseste, de fapt

Erorile din zona verde nu sunt aleatorii: sunt schimbari de un singur cont, intre conturi inrudite - 371 in loc de 401 (13 cazuri), 6241 in loc de 6041 (7), 6281 in loc de 62321 (3), 6221 in loc de 303 (3). Intr-un ecran de lot cu semafor, astea se corecteaza dintr-un clic, nu cer reintroducerea documentului.

Concluzia masurata: o regula invatata din istoricul propriu al furnizorului, fara niciun LLM, propune corect contarea pentru doua treimi din facturile de intrare, cu precizie de aproape 95%. Nu e suficient pentru postare tacuta. Este suficient pentru propunere in lot cu confirmare, adica exact tiparul pe care il livreaza Xero, Visma si SmartBill.

---

3. Descoperirea care conteaza mai mult decat backtestul

91,4% dintre eFacturile primite ajung ca document contabil (1.529 din 1.672 se potrivesc cu un document din ACT pe cod fiscal furnizor, suma identica si data in +/-15 zile). Deci XML-ul exista deja in baza de date pentru aproape fiecare factura care se conteaza.

Dar legatura dintre eFactura si documentul contabil nu se scrie aproape niciodata. Pe cele 12 luni, campul ANAF_EFACTURA.ID_FACT la facturile primite e completat astfel: zero in fiecare luna pana in iunie 2026, 2 in iulie 2026, 28 in august 2026.

Codul de scriere a legaturii exista si e apelat din importul de eFactura: COMUN\programe\import_efactura.prg:229, chemat din COMUN\clase\anaf_efactura.vc2:12480 si :13110. Deci nu lipseste functionalitatea - calea de import nu e folosita. Aproximativ 1.500 de facturi pe an se introduc de mana, desi datele lor structurate sunt deja in Oracle.

Asta muta prioritatea: inainte de orice AI, castigul e sa faci din import calea normala de introducere, nu o optiune paralela.

---

4. Ce nu masoara acest backtest

• Un singur client, profil de comert cu automate. 155 de facturi de intrare pe luna, dar 2.300 de linii de banca - un cabinet cu 40 de firme mici arata altfel. Cifra de 68% acoperire la 95% precizie trebuie reconfirmata pe inca doua scheme inainte de a fi tratata ca proprietate a produsului.
• Semnatura de conturi, nu suma pe fiecare linie. Backtestul verifica ce conturi se folosesc, nu cum se repartizeaza sumele intre ele. La facturile cu mai multe linii de cheltuiala, repartizarea ramane de facut.
• Decalajul factura - inregistrare nu s-a putut masura: 1.855 din 1.864 de documente au dataireg egal cu data actului, deci campul e data contabila, nu momentul tastarii. Timpul real de lucru se poate obtine doar din DATAORA/ID_UTIL, de masurat separat.
• Nu s-a masurat calitatea propunerii pe articol (ANAF_EFACTURA_DETALII are deja CONT/ACONT), doar la nivel de document.

---

5. Ce decid cifrele

1. Coada de contabilizare in lot merita construita. Cu prag de 3 documente identice, doua treimi din facturile de intrare intra in verde cu 95% precizie, iar erorile sunt de un cont, vizibile. Tinta de raportat: procentul din lot care nu cere atingere, nu "acuratete".
2. Inainte de coada, importul de eFactura trebuie sa devina calea implicita. Fara asta, coada nu are ce sa proceseze: azi legatura se scrie pe sub 2% din facturile primite.
3. LLM-ul nu e necesar pentru 68% din volum. Ramane relevant exact pentru zona rosie (90 de furnizori noi pe an, 4,8%) si pentru galben (30% din volum, unde regula simpla nimereste doar jumatate din cazuri) - acolo se testeaza, cu date minimizate.

---

6. Replicare pe schema ROMFAST (03.09.2026)

Instanta ROA pe 10.0.20.36 (Oracle 19c SE2, alias TNS ROA_ROMFAST, retea interna, fara tunel), schema ROMFAST - firma proprie, profil de servicii. Acelasi interval, aceleasi scripturi.

Marime	ROMFAST	VENDING
Linii in ACT, total istoric	121.584	1.309.438
Facturi de intrare in 12 luni	135	1.864
Furnizori distincti in 12 luni	40	263
eFacturi primite in 12 luni	92	1.672
Linii de banca in 12 luni	907	26.894

6.1 Backtestul de contare da acelasi rezultat

Prag	ROMFAST acoperire	ROMFAST precizie	VENDING acoperire	VENDING precizie
ultimul document	85,9%	89,7%	95,0%	81,9%
ultimele 2 identice	74,8%	97,0%	75,7%	91,9%
ultimele 3 identice	68,1%	97,8%	67,8%	94,9%
ultimele 5 identice	62,2%	98,8%	59,2%	96,2%

Doua firme cu volume care difera de 14 ori, din ramuri diferite, dau aceeasi acoperire la pragul de 3: 68%, cu precizie intre 95% si 98%. Cifra nu mai e o proprietate a unui client, e o proprietate a metodei. Zona rosie e mai mare la ROMFAST (14,1% furnizori noi, fata de 4,8%), pentru ca firma are putini furnizori si multi ocazionali.

6.2 Diferenta care conteaza: importul de eFactura chiar se foloseste aici

La ROMFAST, legatura eFactura - document contabil e completa: 13 din 13 in septembrie 2025, 7 din 7 in octombrie, si asa mai departe pentru toate cele 12 luni; 96,7% dintre eFacturile primite au corespondent in ACT. La VENDING, aceeasi legatura e zero pana in iunie 2026.

Deci functionalitatea merge; ce lipseste e adoptia la client. Diferenta dintre cele doua scheme nu e de cod, e de obicei de lucru. Asta muta primul livrabil dinspre "mai scrie cod" spre "fa din import calea implicita si vezi de ce nu o foloseste clientul".

---

7. Cabinetul de contabilitate: 21 de firme de pe serverul ROMFAST (03.09.2026)

Pe aceeasi instanta ROA (10.0.20.36) stau 65 de scheme de firma, dintre care 21 au activitate reala in ultimele 12 luni. Sunt clientii cabinetului, plus CARAPETRU (firma cabinetului). Interogarile s-au facut conectat ca ROMFAST, cu nume calificate de schema (drepturi de citire incrucisata exista). Scripturi: sql\bt_11_cabinet.sql, bt_12_cabinet_sintetic.sql, bt_13_cabinet_efactura.sql.

Volumul cabinetului: 13.418 facturi de intrare pe an, 10.712 eFacturi primite pe an.

7.1 Backtestul da un rezultat mai slab si mult mai imprastiat decat la firma singura

Agregat pe cele 21 de firme, cu semnatura pe cont plus analitic (varianta din sectiunile 2 si 6): acoperire 48,7% la precizie 87,9%, fata de 68% la 95-98% masurat pe VENDING si ROMFAST.

Imprastierea pe firme e mare, si asta conteaza mai mult decat media:

Firma	Acoperire	Precizie
CUX	84,9%	97,8%
CARAPETRU (firma cabinetului)	78,3%	96,3%
LEV	68,2%	93,7%
VADECO	60,6%	94,1%
TURQUOISE	45,6%	85,6%
WERT	36,5%	77,9%
VIDD	32,5%	83,4%

7.2 Analiticul e o parte din problema

Repetand backtestul cu semnatura pe contul sintetic, fara analitic (sql\bt_12):

Prag	Acoperire	Precizie	Din tot volumul, corect
ultimele 3 identice	51,9%	89,5%	46,5%
ultimele 5 identice	41,3%	93,8%	38,7%

La pragul de 5 documente identice si cont sintetic, nicio firma din cele 21 nu coboara sub 85% precizie. Asta e configuratia pe care se poate construi o coada cu semafor la un cabinet: propune contul sintetic, lasa analiticul pe seama regulilor existente si a omului.

7.3 Ce inseamna in ore

La un prag prudent (5 documente identice, cont sintetic), circa 5.200 din cele 13.418 facturi anuale ale cabinetului ar veni cu contarea corecta deja propusa. Restul se imparte in aproximativ 7,3% furnizori noi, unde nu exista istoric, si un rest cu istoric instabil, unde propunerea trebuie privita.

7.4 Importul de eFactura e deja adoptat, cu doua exceptii

Din 10.712 eFacturi primite in 12 luni, 6.639 (62,0%) au legatura scrisa catre documentul contabil. Media e trasa in jos de doua firme: VADECO (0 din 1.305) si TURQUOISE (24 din 995). Fara ele, adoptia e 78,6% (6.615 din 8.412), iar CARAPETRU, CUX, PASS, CLINIDERMA, CERAMOTERM sunt practic la 100%.

Deci intrebarea "de ce nu se foloseste importul" are un raspuns pe firma, nu pe produs: la VENDING importul a intrat in uz abia din iunie 2026 (confirmat de Marius), iar la cabinet doua firme au ramas in urma. Nu e un defect de cod.

---

8. Concluzia finala peste cele trei masuratori

Masuratoare	Facturi de intrare/an	Acoperire	Precizie
VENDING (comert cu automate)	1.864	67,8%	94,9%
ROMFAST (servicii)	135	68,1%	97,8%
Cabinet, 21 de firme	13.418	48,7%	87,9%
Cabinet, cont sintetic, prag 5	13.418	41,3%	93,8%

Cifra de planificare nu e 68%, ci ~40-50%. La o firma cu furnizori stabili metoda merge foarte bine; la un portofoliu de firme diferite, jumatate din facturi vin de la furnizori cu istoric prea scurt sau prea variat. Asta nu anuleaza coada de contabilizare - 5.200 de facturi pe an contate fara gandire, la un singur cabinet, raman ore reale - dar schimba ce se promite.

Aici isi gaseste LLM-ul locul, si acum se poate spune exact unde: in cele ~50% care nu intra in zona verde. Nu ca sa inlocuiasca regula, ci ca sa acopere furnizorii noi (7,3% din volum) si istoricul instabil, unde regula simpla nimereste sub 60%.

---

9. Unde e de fapt munca manuala: linia de articol, nu documentul

Observatia lui Marius (03.09.2026): operatorii mapeaza articol -> cont la nivel de linie de eFactura. Articolele care nu au un articol gestionabil mapat, sau al caror text variaza de la o luna la alta (de exemplu contine perioada), nu se recunosc si se completeaza manual de fiecare data.

Masurat pe 18-19 firme ale cabinetului, liniile de eFactura primite in ultimele 12 luni. Scripturi: sql\bt_15_articole_normalizat.sql...bt_18_prefix.sql.

9.1 Volumul real

Marime	Valoare
Linii de eFactura primite pe an (19 firme)	33.844
Linii carora operatorul le pune cont	15.565 (46,0%)
Furnizori distincti pe firma	200-230

Deci munca nu se masoara in 13.418 documente, ci in peste 15.000 de linii pe an care primesc cont.

9.2 Cheia de potrivire: cat castiga fiecare varianta

Regula testata: pentru fiecare linie, se ia contul de pe ultima linie anterioara a aceluiasi furnizor care are aceeasi cheie de text. Se compara cu ce a pus operatorul.

Cheia de potrivire	Linii recunoscute	Din cele contate	Precizie
text exact (ce face programul azi)	8.088	52,0%	95,0%
text fara cifre	10.030	64,5%	94,1%
text fara cifre, primele 25 de caractere	10.436	67,1%	93,9%
text fara cifre, primele 12 caractere	11.243	72,3%	93,4%

Doar stergand cifrele din denumirea articolului si comparand primele 12 caractere, recunoasterea urca de la 52% la 72%, cu o pierdere de precizie de 1,6 puncte. In cifre absolute, la un singur cabinet: circa 3.150 de linii pe an care azi se completeaza manual ar veni deja completate.

Exemple de texte care azi rup potrivirea, luate din date: ROVIGNETA AUTOTURISME_12 LUNI_TIP A, GARANTIE SGR 12X0.5LEI FZ22509, Cafea 8000070024441, BUCOVINA PLATA*2L SGR.

9.3 Codul de articol al furnizorului nu e o solutie

S-a testat si potrivirea pe codul trimis de furnizor in XML (CODFURNIZOR, CODBARE, CODNC8). Practic nu exista: la WERT, 34 de linii din 4.426 au cod de furnizor; la CIAO, DOMINUS si CERAMOTERM, zero. Textul denumirii ramane singura cheie disponibila.

9.4 Ce ramane pentru LLM, acum cu tinta clara

Dupa cea mai buna cheie de text, raman 27,7% din liniile contate - circa 4.300 pe an la un cabinet - care nu se pot recunoaste din istoric. Acolo, si numai acolo, are sens un model: text scurt, fara sume, fara parteneri, cu lista de conturi folosite de firma pentru acel furnizor ca variante. Restul de 72% se rezolva cu o schimbare de cheie de potrivire, fara niciun apel extern.

9.5 Ordinea corecta a livrabilelor, revizuita

1. Schimba cheia de potrivire a articolului (normalizare + prefix), cu pragul si lungimea configurabile, si arata operatorului de unde vine propunerea. Efort mic, castig masurat: +20 puncte procentuale de recunoastere, ~3.150 de linii pe an la un cabinet.
2. Coada in lot peste documentele ale caror linii sunt toate recunoscute - acolo se aplica cifra de 41-52% din sectiunea 7.
3. LLM pe restul, cu masurare inainte si dupa.