Dovezile masurate pentru propunerile de directie (09.2026)
Backtest read-only pe productie: recunoasterea articolului la importul de eFactura, contarea pe istoric de furnizor, identificarea partenerului la importul de extrase, plafonul potrivirii facturii din textul bancii. Include harta codului de import extrase, testul care confirma eroarea de parsare BT si scripturile SQL reproductibile. Propunerile care se sprijina pe ele: COMUN/docs/cercetare/rec_directie_roacont_2026_09.md Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T8jmGHs29e9eyLgoMiLBHW
This commit is contained in:
309
docs/cercetare/piata_ai_2026_09/BACKTEST_VENDING.md
Normal file
309
docs/cercetare/piata_ai_2026_09/BACKTEST_VENDING.md
Normal file
@@ -0,0 +1,309 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user