Import eFactura in lot: borderou cu ce lipseste, coada de contabilizare, alegerea contului

Borderoul tine per factura ce mai are de completat si daca are articole de gestiune
(camp gest, coloana si filtru), coada contabilizeaza in serie facturile bifate si
incheie cu un rezumat, iar contul de furnizor/client se alege din planul de conturi.
Cheia normalizata de articol, rezolvarea automata a partenerului si anularea in bloc
intra tot aici. Pozitia in lista se pastreaza peste reaplicarea filtrului.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Aroafxp4z8bmM5oVECZRXY

docs/cercetare/rec_precompletare_efactura.md

@@ -0,0 +1,233 @@
+# Precompletarea la importul de eFacturi
+
+Directia, dupa masuratorile din 07-08.09.2026 pe toata productia (cabinetul `ROA_ROMFAST`, 21 de
+scheme, si `VENDING`), read-only, backtest cronologic fata de ce a facut operatorul in realitate.
+
+Principiul, si singurul criteriu de acceptare a oricarei propuneri de aici: **liniile vin completate,
+fara niciun click, ecran sau formular nou.** Importul nu e adoptat pentru ca nu aduce inca un
+beneficiu; orice adaugam trebuie sa scada munca, nu s-o mute.
+
+Dovezile: `ROACONT\docs\backtest_precompletare_cont.md`, `backtest_precompletare_runda2.md`,
+`inventar_campuri_de_retinut.md`, `masuratori_romfast_efactura.md`, `masuratori_vending_efactura.md`,
+`profilare_semafor_vending.md`. Scripturi: `ROACONT\docs\cercetare\piata_ai_2026_09\sql\bt_26*`, `bt_27*`.
+
+## 0. Ce se arunca
+
+**Unde**: `COMUN\programe\semafor_contabilizare_ef.prg`, coloana de semafor din `frm_import_efactura`.
+
+**Cum e azi**: o interogare mare calculeaza per factura o culoare (verde/galben/gri/articol nou) din
+stabilitatea istoricului de conturi al furnizorului.
+
+**Ce se schimba**: dispare, cu totul.
+
+**Ce se castiga**: 36s per rulare la VENDING, 4,2s pe cabinet, la deschiderea ecranului si la fiecare
+cautare (`masurat`). Profilarea arata ca timpul nu vine din scanarea lui `ACT` (0,6s) ci din combinatia
+catalog + cascada normalizata din aceeasi interogare (35,3s izolat).
+
+**Ce risc**: niciunul functional. Culoarea nu schimba nicio decizie a operatorului: pe cabinet 77,7%
+din facturi ies "articol nou" si doar 3,8% verzi, iar relaxarea pragului de stabilitate de la 5 la 3
+documente aduce +13 facturi din 924 (`masurat`).
+
+Ramane din runda 18 doar verificarea locala a lipsurilor (`CoadaContabilizareEF.LipsuriDetalii`, fara
+Oracle), ca sa nu iasa tacit documente cu cont gol pe ruta `ImportGeneral`.
+
+**Coada de import ramane**, dar numai pentru facturile complet completate: o factura careia ii lipseste
+ceva nu intra in lot, se debifeaza singura si motivul se vede pe rand. Regula e deja scrisa (runda 18) si
+nu depinde de semafor - lipsurile se calculeaza local, pe liniile facturii. Dupa precompletare lotul
+devine util de la sine: 9,0% -> 66,5% din facturi fara nicio lipsa pe cabinet (`masurat`).
+
+## 1. Contul si analiticul pe linie
+
+**Unde**: `COMUN\programe\recunoastere_articol_ef.prg`, folosit din
+`frm_import_efactura.completeazaDetaliiFactura` (`COMUN\clase\anaf_efactura.vc2`).
+
+**Cum e azi**: contul se cauta in catalogul de articole (denumire/codbare/codmat/codmatf,
+`oproceduri_comune.prg:7267`) si in istoricul **aceluiasi furnizor pe acelasi articol**, text exact si
+cheie normalizata. Ce nu prinde, ramane gol.
+
+**Ce se schimba**: doua surse noi, dupa cele existente, doar pentru liniile ramase goale:
+1. **articolul contat oriunde in firma**, indiferent de furnizor, pe cheia normalizata, cu garda de
+   unicitate la 70% si fereastra **ultima factura**;
+2. **contul dominant al furnizorului**, indiferent de articol, cu garda la 90%, fereastra **ultimele
+   trei facturi**, si **doar contul sintetic** - analiticul ramane al operatorului;
+3. ce mai ramane ia **contul majoritar al celorlalte linii ale aceleiasi facturi**, fara prag.
+
+Analiticul liniei (`3xxx.xxx`, `6xxx.xxxx`) se propune doar din sursa 1 (94,3% precizie), niciodata din
+sursa 2 (79,3%).
+
+Analiticul contului de furnizor si de client din antet (`401.xxxx`, `4111.xxxx`) nu intra: exista ca
+mecanism (`IREG_PARTENERI`/`BALANTA_PARTENERI`, cu partener + cont + analitic), dar nu e folosit - vezi
+respinse.
+
+**Ce se castiga** (`masurat`, cabinet, 15.828 linii/an): acoperire pe linie 77,8% -> 97,7%; facturi fara
+nicio lipsa de cont 9,0% -> 66,5%; la VENDING 2,5% -> 69,2%. Fereastra conteaza mult: pe sursa 1,
+ultima factura da 85,0% acoperire cu 93,7% precizie, fata de 60,5% / 90,1% la 36 de luni, iar castigul
+e cel mai mare la furnizorii care factureaza lunar (>=8 facturi/an).
+
+**Ce risc**: precizia propunerilor scade de la 89,5% la 84,9% (`masurat` cu ferestrele vechi; de
+recalculat la implementare, cifra e un plafon pesimist - treptele noi masurate cu fereastra corecta dau
+93-94%). Practic: din 100 de linii precompletate circa 15 se corecteaza, fata de 22 care azi se scriu
+de la zero. Mitigare fara UI nou: `sursa_cont` exista deja pe linie si arata de unde vine propunerea.
+
+## 2. Gestiunea pe linie
+
+**Unde**: aceeasi cascada; azi gestiunea vine doar din istoricul (furnizor, articol), altfel din optiunea
+globala `EFACTURA_ID_GESTIUNE_P`.
+
+**Cum e azi**: la firmele cu mai multe gestiuni, optiunea globala e practic inutila - niciuna din cele
+21 de firme nu are o singura gestiune activa (au intre 2 si 467), deci nu exista implicit cinstit.
+
+**Ce se schimba**: gestiunea trece prin aceleasi surse noi, cheia fiind partener+articol, fereastra
+ultima factura.
+
+**Ce se castiga** (`masurat`): facturi complet rezolvate la VENDING 23,3% -> 86,0% (acoperire 97,2%,
+precizie 98,1%); pe cabinet 53,0% -> 89,1%. Conteaza aproape numai la firmele cu stoc: acolo gestiunea
+e 38,7% din blocaje, la cabinet 4,2%.
+
+**Ce risc**: stabilitatea per (partener, articol) e 64% - mai mica decat la cont. Ramane peste alternativa
+de azi (o gestiune unica pe toata firma), dar merita marcata ca propunere, nu ca certitudine.
+
+## 3. Data scadentei
+
+**Unde**: `crsFacturi.data_scad`, `frm_import_efactura.completeazaFactura`.
+
+**Cum e azi**: se scrie de mana la fiecare factura.
+
+**Ce se schimba**: se propune scadenta de pe ultima factura a aceluiasi partener.
+
+**Ce se castiga** (`masurat`): se completeaza la 86,1% din facturi si coincide cu ultima factura a
+aceluiasi partener in 87,3% din cazuri.
+
+**Ce risc**: cel mai mare din tot pachetul. O scadenta gresita nu se vede pe ecran, dar ajunge in balanta
+si in raportarile de plati. Se propune doar cand campul din eFactura e gol, niciodata peste o valoare
+venita din XML.
+
+## 4. Contractul
+
+**Unde**: `crsFacturi.Id_Ctr`.
+
+**Cum e azi**: ales de mana, cand se foloseste.
+
+**Ce se schimba**: se propune contractul de pe ultima factura a aceluiasi partener.
+
+**Ce se castiga** (`masurat`): se completeaza rar (16,8% din facturi), dar cand se completeaza e acelasi
+in 93,8% din cazuri - deci ieftin si sigur, pentru firmele care lucreaza pe contracte.
+
+**Ce risc**: mic; camp fara efect contabil direct.
+
+## 5. Alegerile din antet care azi se pierd: deducerea, discountul, contul si analiticul partenerului
+
+**Unde**: `cboDeducere` (`COMUN\clase\anaf_efactura.vc2:9672`, folosit la `:13153`),
+`chkDistribuieDiscount` (`:12254`), si campurile de antet `Cont`/`ACont` (`txtCont`/`txtAcont`,
+cursorul `vizImportEFactura` in `COMUN\programe\import_efactura.prg:44`).
+
+**Cum e azi**: toate patru sunt **tranzitorii**. `Cont` si `acont` vin goale din interogare (`'' as Cont,
+'' as acont`), se completeaza la rulare si nu se scriu inapoi; deducerea si discountul merg direct in
+nota contabila. In DDL (`anaf_efactura.sql`) nu exista nicio coloana pentru ele. Deci la fiecare factura
+de la acelasi furnizor se aleg din nou: analiticul lui `401`, deducerea 50%, distribuirea discountului.
+
+**Ce se schimba**: patru coloane noi pe `ANAF_EFACTURA` in care se salveaza ce a ales operatorul la
+import (`cont`, `acont`, deducerea, distribuirea discountului), si repropunerea valorilor de la ultima
+factura a aceluiasi partener - furnizor sau client, cu aceeasi cheie.
+
+Asta acopera si analiticul `401.xxxx` / `4111.xxxx`: nu se deduce din balanta (vezi respinse), ci se
+**tine minte ce a scris operatorul** si se repropune la acelasi partener. Nu depinde de faptul ca azi
+nimeni nu foloseste analitice pe aceste conturi - daca operatorul scrie unul, se retine.
+
+**Ce se castiga**: `nemasurat` - stabilitatea nu se poate masura azi, pentru ca valoarea nu se salveaza.
+Se masoara dupa prima luna de date.
+
+**Ce risc**: cere script de migrare si versiune noua de `.exe`. Deducerea gresita are efect fiscal, deci
+se propune, nu se aplica tacit: valoarea propusa ramane vizibila in acelasi loc in care se alege azi.
+
+## 6. Facturile emise (importate din SPV)
+
+**Cum e azi**: masuratorile s-au facut doar pe primite; 15 din 20 de scheme au si emise importate
+(1.680 linii / 1.456 facturi pe 12 luni).
+
+**Ce se schimba**: aceeasi cascada, cu clientul in locul furnizorului. Codul e deja simetric
+(`lPrimite`, perechile de optiuni `_E`/`_P`).
+
+**Ce se castiga** (`masurat`): acoperire 98,8%, precizie 97,7% - dar spatiul de conturi de vanzare e
+foarte ingust (unele firme folosesc un singur cont pe an), deci cifra e reala si usoara, nu comparabila
+cu achizitiile. La VENDING sunt 22.457 de facturi emise, dar prin alt flux, fara conturi pe linii -
+nemasurabil.
+
+## 7. Configurarea, care azi nu se deschide niciodata
+
+**Unde**: `frm_import_efactura.Cmd_executa2.Click` si `frm_configurare_efactura`
+(`COMUN\clase\anaf_efactura.vc2:14615`). Analiza completa:
+`ROACONT\docs\analiza_configurare_import_efactura.md`.
+
+**Cum e azi**: 15 optiuni `EFACTURA_*`, dintre care doar patru schimba cu adevarat rezultatul importului
+(contul implicit de articole si gestiunea implicita, pe primite si pe emise). Restul fie umplu un camp
+fara nicio verificare, fie sunt comutatoare ale cascadei al caror raspuns corect e mereu acelasi.
+Masurat pe cabinet: `EFACTURA_CONT_ART_P` e setata la **0 din 21** de firme, gestiunea implicita la 0
+efectiv (trei firme au valoarea 0), iar comutatoarele cascadei n-au fost atinse de nimeni. Ecranul de
+Configurare nu se deschide, deci singurele optiuni care conteaza sunt goale peste tot.
+
+**Ce se schimba**, in aceasta ordine si abia **dupa** precompletare, pentru ca ea sterge cea mai mare
+parte a nevoii de configurare:
+1. **Ecranul se subtiaza**: raman doar cele patru optiuni care conteaza; cele fara efect dispar din
+   interfata, iar comutatoarele cascadei devin constante in cod (raman citite, ca sa nu se strice
+   singura firma care si-a oprit manual preluarea din facturi anterioare).
+2. **Ce ramane urca pe ecranul de import**, pe randul liber deja masurat (`Left 130-530`, `Top 57-84`),
+   cu tiparul de camp + buton de cautare deja folosit pe forma. Dispare motivul de a deschide un ecran
+   separat.
+3. **Optiunea se naste din lucru**: cand operatorul completeaza manual un camp pentru care exista o
+   optiune, langa el apare "foloseste asta de fiecare data", care scrie optiunea prin `scrie_optiune`
+   (`oinit_optiuni.prg:827`). Nu se cere nimic inainte si nu apare niciun ecran nou.
+
+**Ce se castiga**: gestiunea implicita globala devine inutila dupa precompletare - nicio firma din 21 nu
+are o singura gestiune activa, deci un implicit global nu putea fi corect (`masurat`); ramane doar contul
+implicit, ca plasa de siguranta pentru liniile pe care nimic altceva nu le rezolva, si acolo se aplica
+punctul 3.
+
+**Ce risc**: un implicit scris din greseala se propaga tacit. Se previne cu eticheta explicita pe
+alegere si cu faptul ca valoarea e mereu la vedere pe ecranul de import, nu ascunsa.
+
+## Respinse, cu motivul
+
+- **Potrivirea fuzzy a articolelor** (Jaro-Winkler, edit distance, `UTL_MATCH`): 80% precizie la
+  acoperire mica, sub cascada actuala (93-95%), si batuta de regula fara text "ultimele trei conturi ale
+  furnizorului", care e chiar sursa 2 de mai sus.
+- **Deducerea analiticului `401.xxxx` / `4111.xxxx` din datele existente**: mecanismul exista
+  (`IREG_PARTENERI`/`BALANTA_PARTENERI`), dar e nefolosit - la cabinet doar 2 din 21 de firme au analitic
+  pe aceste conturi, si acolo e o categorie sau un proiect, nu identitatea partenerului (la una, un
+  singur cod acopera 98,6% din linii); la VENDING completarea e 0% si nici nu exista coduri analitice
+  definite pentru ele. Nu exista legatura partener -> analitic din care sa se deduca ceva.
+  **Respinsa e doar deducerea din balanta**; retinerea valorii scrise de operator si repropunerea ei la
+  acelasi partener sunt in plan, la punctul 5.
+- **Valori implicite propuse din date pentru Configurare**: nicio firma din 21 nu are o singura gestiune
+  activa, iar contul de achizitie dominant e in medie 37,8% si niciodata peste 50%.
+- **TVA la incasare**: nu e o decizie a operatorului, se verifica la ANAF; o valoare memorata ar putea
+  fi gresita.
+- **Explicatia documentului**: completata la 18,1% din facturi si stabila doar in 50,9%.
+- **Sectia, venitul/cheltuiala, responsabilul, lucrarea, felul documentului**: constante ale firmei, nu
+  decizii per factura - locul lor e in Configurare.
+- **Un ecran de completare grupata pe articol** (macheta din 07.09): ar fi dus lotul de la 9% la 62%,
+  dar cu pretul unui formular in plus. Precompletarea de mai sus ajunge la 66,5% fara niciun ecran.
+- **Index nou pe `ACT`** pentru semafor: bucata care scaneaza `ACT` costa 0,6s din 36s, deci nu ea e
+  problema; iar semaforul dispare.
+
+## Capcane de masurare platite
+
+- Facturile de test nu se recunosc doar dupa numar: 16 facturi aveau `TEST=1` si numar gol, si faceau ca
+  lunile recente sa para pline de date reale.
+- `TRIM(x) = ''` e mereu fals in Oracle - a falsificat o prima rulare a backtestului.
+- Fereastra de istoric e un parametru cu efect mare, nu un detaliu: 36 de luni fata de ultima factura
+  inseamna 25 de puncte de acoperire in minus pe sursa de articol.
+- Timpul unei interogari nu se judeca dupa volumul de date: pe VENDING citirea costa nimic, iar 35 din
+  36 de secunde vin din combinarea a doua bucati care, separat, ruleaza sub 4s fiecare.
+
+## Ordinea de implementare
+
+1. Scoaterea semaforului (castig imediat de viteza, sterge cod).
+2. Contul si analiticul pe linie, cu ferestrele masurate. Se masoara timpul de deschidere a unei
+   facturi inainte si dupa: **precompletarea trebuie sa fie instantanee**, altfel nu s-a rezolvat nimic.
+3. Gestiunea, pe aceleasi surse.
+4. Data scadentei si contractul.
+5. Deducerea si distribuirea discountului (cer script de migrare).
+6. Configurarea: subtiere, urcarea pe ecranul de import, alegerea care scrie optiunea. Abia acum, cand
+   se stie ce a mai ramas necesar dupa precompletare.
+7. Emise, dupa ce primitele sunt livrate si verificate.