# 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.