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
2026-09-03 14:19:16 +03:00
parent d4a9c800ff
commit f9af574877
12 changed files with 2088 additions and 0 deletions
--- a/docs/cercetare/piata_ai_2026_09/COD_EXTRASE_BANCA.md
+++ b/docs/cercetare/piata_ai_2026_09/COD_EXTRASE_BANCA.md
@@ -0,0 +1,250 @@
+# Import extrase de banca si imperecherea partener/factura - cum functioneaza azi
+
+Cercetare de cod, fara nicio modificare. Toate afirmatiile au citat fisier:linie din
+`D:\roa\ROACONT`. Sursa e VFP compilat in `.prg`/`.vcx`; codul citat mai jos e din `.prg`
+(text direct, nu are nevoie de `.vc2`).
+
+## A. Harta fluxului
+
+1. **Pornire**: `Programe\ocont2003.prg:845` (`lans_import_extras`) deschide setul de note
+   `90023` = "IMPORT EXTRAS MT940" (`ocont2003.prg:858`, `ocont2003.prg:964-965`).
+2. `note_fara_predefinire` (`ocont2003.prg:948`) pregateste cursorul `tAct` si apeleaza
+   `import_extras('tAct', ...)` la `ocont2003.prg:1226`.
+3. `import_extras` (`ocont2003.prg:866`) instantiaza clasa fabrica `ImportNote` din
+   `Programe\oproceduri_import.prg:57` si cheama `.Import()`. In functie de fisierul ales,
+   `ImportNote` (`oproceduri_import.prg:120-227`) alege subclasa potrivita: `ExtrasBanca_MT940`
+   (Raiffeisen etc.), `ExtrasBanca_CREDITEUROPE_XML`, `ExtrasBanca_UNICREDIT_CSV`, sau
+   `ExtrasBanca_General` (`oproceduri_import.prg:1415`) - clasa "detectez singur formatul",
+   folosita si pentru fisierele **Banca Transilvania**.
+4. `ExtrasBanca_General::Parse` (`oproceduri_import.prg:1417`) citeste prima linie
+   nevida a fisierului si decide dupa continutul ei ce parser cheama. Pentru CSV sunt
+   ~25 formate bancare/procesatori de plati recunoscute dupa antet
+   (`oproceduri_import.prg:1452-1531`: Stripe, Booking, PayU, Intesa, FanCourier, Cargus, DPD,
+   Garanti, OTP, Raiffeisen, Unicredit, ING, ING Business, **BT** (linia 1502-1507), PayPal,
+   BRD, BCR, First Bank, CEC, MobilPay, Un-Doi, Paypoint, Idea, CreditEurope, Alpha).
+5. Pentru **Banca Transilvania** liniile 1502-1507 detecteaza doua variante de export
+   (lista de tranzactii lunara vs. extras de cont) si cheama `This.csvBT(fisier, 1)` respectiv
+   `This.csvBT(fisier, 2)`. Parserul activ e `csvBT` la `oproceduri_import.prg:2923-3025`
+   (functia veche `csvBT_original`, linia 3027, nu mai e apelata de nicaieri).
+6. Rezultatul parsarii ajunge in cursorul local `c_iex`, apoi `C_IMPORT_TEMP`
+   (`oproceduri_import.prg:1544-1550`), care alimenteaza motorul de imperechere
+   `ExtrasBanca::CreeazaNote` (`oproceduri_import.prg:312-926`) - aici se cauta partenerul si
+   factura pentru fiecare linie.
+7. Rezultatul (`cActTemp` -> `tAct`) e afisat operatorului intr-un formular de corectie
+   manuala, `frm_modific2024` (instantiat la `ocont2003.prg:1229`), unde utilizatorul poate
+   modifica orice camp (partener, cont, factura) inainte de salvare.
+8. La apasarea butonului de salvare (`buton = 1`, `ocont2003.prg:1245-1257`), cursorul corectat
+   e scris in tabela Oracle **`ACTACTAN`** (jurnalul contabil) prin `oscrie_in_fisiere`
+   (`ocont2003.prg:1256`). Coloanele relevante confirmate din `INSERT INTO actactan(...)`
+   real (`Programe\oproceduri_incasari.prg:270-279`, `Programe\oproceduri_inchidere.prg:856-879`)
+   si din vederea `vact_tot`/`xnote` (`COMUN\programe\ocont2003... ` / `Programe\ocont2003.prg:1101-1183`):
+   `nr_nota, an, luna, dataireg, nract, dataact, explicatia, scd, ascd, scc, ascc, suma,
+   suma_val, id_valuta, curs, id_set, id_fact, id_partd, id_partc, id_factd, id_factc,
+   pereched, perechec, id_fdoc`. Liniile provenite din import extras au `id_set = 90023`
+   (`ocont2003.prg:858`), ceea ce le face identificabile ulterior in Oracle.
+9. Nomenclatorul de parteneri e tabela `NOM_PARTENERI` (cautat prin vederea `vnom_parteneri`,
+   coloane `cod_fiscal`, `denumire`, `cont_banca`, `sters`, `inactiv`,
+   `COMUN\programe\oproceduri_comune.prg:6599-6667`). Facturile/documentele de imperecheat
+   sunt in tabela `IREG_PARTENERI` (fisa partener pe cont/an/luna, coloane `id_fact`, `cont`,
+   `acont`, `nract`, `id_part`, `an`, `luna`, `precdeb`, `debit`, `preccred`, `credit`,
+   `id_lucrare`, cautate in `GetDocumentByContPartenerAct`,
+   `COMUN\programe\oproceduri_comune.prg:6984-7057`).
+
+Pe scurt: **(a) manual** = operatorul introduce direct in `frm_modific2024` fara pasii 3-6.
+**(b) import fisier** = pasii 1-9 de mai sus; pasul 7 (formularul) e exact punctul unde
+"operatorul intervine" mentionat de tine.
+
+## B. Cum se identifica azi PARTENERUL (client/furnizor)
+
+Motorul e in `ExtrasBanca::CreeazaNote`, blocul de cautare parteneri
+(`oproceduri_import.prg:433-547`), rulat o singura data per (cod_fiscal, denumire, iban)
+distinct din import (`oproceduri_import.prg:435`), apoi aplicat pe toate liniile
+(`oproceduri_import.prg:542-544`). Ordinea de cautare, in cascada:
+
+1. **Dupa cod fiscal** (`oproceduri_import.prg:453-488`) - doar daca linia are cod fiscal
+   completat. `GetPartenerByCodFiscal` (`COMUN\programe\oproceduri_comune.prg:6599-6621`) face
+   potrivire **exacta** dupa cod fiscal normalizat (fara spatii, fara prefix "RO"),
+   `MAX(id_part)` daca sunt mai multi identici. Daca acelasi CUI normalizat exista pe mai
+   multi parteneri (grup de duplicate, `GetParteneriByCuiNormalizat`,
+   `oproceduri_import.prg:4515-4526`), se alege partenerul din grup cu cele mai multe
+   inregistrari (si cel mai mare sold) in `ireg_parteneri` pentru anul/luna curenta
+   (`oproceduri_import.prg:459-483`, comentariu explicit la linia 52: *"la CUI-uri duplicate
+   aleg partenerul cu facturi in perioada curenta, nu ultimul creat"*).
+2. **Dupa denumire** (`oproceduri_import.prg:490-513`), doar daca pasul 1 nu a gasit nimic.
+   `GetPartenerByDenumire` (`COMUN\programe\oproceduri_comune.prg:6623-6645`) face potrivire
+   **exacta** `TRIM(UPPER(denumire)) = ?pcDenumire` - nu foloseste `LIKE`, nu elimina
+   diacritice, nu normalizeaza forma juridica ("SRL" vs "S.R.L." vs fara sufix). Daca nu
+   gaseste exact, incearca variante de ordine a cuvintelor pentru nume de persoane
+   (`GetNamePermutations`, `COMUN\programe\oproceduri_comune.prg:6789 si urm.`, apelat la
+   `oproceduri_import.prg:500-511`) - util doar pentru "Popescu Ion" vs "Ion Popescu", nu
+   pentru firme.
+3. **Dupa IBAN** (`oproceduri_import.prg:516-523`), doar daca pasii 1-2 au esuat.
+   `GetPartenerByContBanca` (`COMUN\programe\oproceduri_comune.prg:6647-6667`) - potrivire
+   **exacta** pe `cont_banca`.
+4. **Creare automata de partener nou** (`oproceduri_import.prg:527-540`) - doar daca are cod
+   fiscal si optiunea `This.lCreeazaParteneri` e activa; fara cod fiscal, linia ramane fara
+   partener (`id_part = 0`), vizibila operatorului in grid la pasul de corectie.
+
+**Cazul concret Banca Transilvania**: parserul `csvBT` **nu extrage niciodata codul fiscal**
+al platitorului - `mcf = ""` e fixat necondiotionat la `oproceduri_import.prg:3015`. Asta
+inseamna ca pentru singurul format pe care il ai (BT), pasul 1 de mai sus (cod fiscal, cel mai
+sigur) **nu se executa niciodata** - se sare direct la potrivirea exacta dupa denumire (pasul 2),
+care e cea mai fragila. Denumirea partenerului extrasa din linia BT vine din pozitia 3 a
+campului "Descriere", despartit dupa `;` (`mtert = ALLTRIM(syGETWORDNUM(mexplicatie, 3, ';'))`,
+`oproceduri_import.prg:3013`), iar IBAN-ul partenerului din pozitia 4
+(`oproceduri_import.prg:3014`).
+
+## C. Cum se identifica azi FACTURA
+
+Tot in `CreeazaNote`, blocul "asociez document" (`oproceduri_import.prg:701-817`), care ruleaza
+**doar daca** optiunea `This.lFactura` e activa (cautare dupa numar de document,
+`oproceduri_import.prg:710-764`) sau `This.lComanda` (cautare dupa numar de comanda,
+`oproceduri_import.prg:769-817`, logica identica dar cauta si in `nrord`/`explicatia`
+prin `LIKE`).
+
+Comentariul autorului chiar deasupra blocului descrie exact ce ar trebui sa faca si ce NU face
+azi (`oproceduri_import.prg:701-706`):
+> *"Repet pana la epuizarea sumei de plata/incasare... Daca nu mai am documente, dar suma de
+> plata nu este epuizata, imperechez facturile in ordine cronologica..."* - acest TODO nu e
+> implementat.
+
+Ce se intampla efectiv, pas cu pas (`oproceduri_import.prg:719-764`):
+
+1. Se ia lista de numere gasite in text (`documente`, extrase de `GetRegExpAllNumbers`,
+   `oproceduri_import.prg:4480-4510` - ia **toate** numerele intregi din descriere, dupa ce
+   elimina datele de forma zz.ll.aa(aa) si anul curent). Pentru BT, aceasta lista vine din
+   pozitia 2 a campului "Descriere" (`lcDescriereFacturi`, `oproceduri_import.prg:3017-3019`).
+2. Pentru **primul** numar din lista, `GetDocumentByContPartenerAct`
+   (`COMUN\programe\oproceduri_comune.prg:6984-7057`) cauta in `ireg_parteneri` documentul cu
+   acel `nract`, pe acelasi partener si (daca exista) acelasi cont; daca gaseste **mai mult de
+   un rezultat**, renunta si doar scrie in log ("Sunt prea multe rezultate care se potrivesc",
+   linia 7038) - **nu alege niciunul**.
+3. Daca a gasit exact un document (`oproceduri_import.prg:726`), suma din extras e acceptata
+   **doar daca nu depaseste soldul ramas al facturii** (`lnSuma <= solddeb`, liniile 728-734).
+   Dupa acest test, bucla **iese necondiotionat** (`EXIT`, linia 736) - indiferent daca s-a
+   facut sau nu vreo asociere.
+
+**Consecinte directe, cu explicatie**:
+- **Suma exacta pe o singura factura** -> functioneaza (cazul comun, o plata = o factura).
+- **O plata acopera mai multe facturi** (suma > soldul primei facturi gasite) -> testul de la
+  linia 728/731 esueaza, dar bucla oricum iese la `EXIT` (linia 736) fara sa incerce
+  urmatorul numar de document din lista si fara sa distribuie suma pe facturi. Rezulta o linie
+  **fara factura pereche**, desi numarul facturii a fost corect citit din text.
+- **O plata partiala pe o factura** (suma < sold) -> se asociaza, dar factura ramane cu sold
+  neachitat corect in continuare (nu e un bug, e comportamentul dorit).
+- **Avansuri** (plata fara numar de factura in text) -> `documente` ramane gol, se forteaza
+  totusi o cautare cu `'0'` (`oproceduri_import.prg:715-717`), care de regula nu gaseste nimic
+  -> linia ramane fara factura, de corectat manual.
+- **Compensari** -> nu sunt tratate aici; sunt un modul separat (`COMUN\programe\ocompensari.prg`),
+  nu fac parte din fluxul de import extras.
+- **Comisioane bancare** -> sunt recunoscute prin cuvinte cheie in descriere ("comision",
+  "comision-atm", "pachet izi", etc., `oproceduri_import.prg:2998-3012` pentru BT) si duse
+  direct pe cont 627, fara sa treaca prin cautarea de partener/factura - acest caz e deja
+  tratat rezonabil.
+
+## D. Ce e slab si ce s-ar schimba
+
+Defecte reale si confirmate in cod. Ce s-a masurat efectiv pe date de productie e in
+`BACKTEST_BANCA.md` - acolo e si cifra care arata ca schimbarea de la punctul 1 de mai jos nu e
+cea mai buna: `CONT_BANCA` e completat la doar 4,5% dintre parteneri activi, deci cheia de IBAN
+nu are azi pe ce lucra la scara mare.
+
+1. **Pentru BT (singurul format folosit), cautarea partenerului nu foloseste niciodata codul
+   fiscal** - `oproceduri_import.prg:3015` (`mcf = ""` fix) + cascada din
+   `oproceduri_import.prg:453-523`. Se ajunge direct la potrivire exacta de denumire
+   (`COMUN\programe\oproceduri_comune.prg:6623-6645`, fara `LIKE`, fara normalizare diacritice/
+   forma juridica). Extrasul BT contine IBAN-ul platitorului la pozitia 4 din descriere
+   (`oproceduri_import.prg:3014`) - IBAN e mai stabil ca si cheie decat denumirea si e deja
+   extras, dar in cod e incercat abia **al treilea**, dupa cod fiscal (mereu gol pentru BT) si
+   dupa denumire. Nomenclatorul insa nu are `CONT_BANCA` completat decat la 4,5% dintre
+   parteneri (masurat, vezi `BACKTEST_BANCA.md`), deci o simpla schimbare de ordine nu recupereaza
+   mult pe cont propriu - cheia invatata din istoric, masurata in acelasi document, e cea care
+   aduce castig real.
+2. **O plata care acopera mai multe facturi, sau al carei prim numar de factura gasit nu se
+   potriveste cu soldul, ramane azi complet nepereche** - `oproceduri_import.prg:710-764`,
+   `EXIT` necondiotionat la linia 736 dupa primul document gasit, indiferent de rezultatul
+   testului de suma; TODO-ul autorului chiar deasupra (`oproceduri_import.prg:701-706`)
+   confirma ca aceasta e o lipsa cunoscuta, nu o alegere deliberata. Aceasta e cea mai probabila
+   cauza pentru "plata acopera mai multe facturi" mentionata in cerinta ta.
+3. **Cand acelasi numar de document se potriveste pe mai multe randuri in `ireg_parteneri`,
+   sistemul renunta silentios** - `COMUN\programe\oproceduri_comune.prg:7035-7039`
+   (`Reccount('cRezultatTemp') > 1` -> doar log, fara alegere).
+4. **Extragerea numarului de factura ia orice numar din text, nu doar numere plauzibile de
+   factura** - `GetRegExpAllNumbers` (`oproceduri_import.prg:4480-4510`) elimina doar datele
+   calendaristice, nu si alte numere (referinte, telefoane). Combinat cu punctul 2 (se incearca
+   doar primul numar gasit), un numar irelevant aflat inaintea numarului real de factura in
+   text ar putea fi incercat primul si esua fara a mai incerca urmatorul.
+5. **Pozitiile fixe din descrierea BT (cuvintele 3 si 4 despartite de `;`) nu sunt validate** -
+   `oproceduri_import.prg:3013-3014` - daca banca schimba formatul sau tranzactia are alt tip
+   de descriere decat "Incasare/Plata OP", `mtert`/`miban` pot prelua bucati de text gresite,
+   fara nicio verificare (ex: ca IBAN-ul extras chiar arata a IBAN).
+
+## E. Formatul fisierului Banca Transilvania (din cod)
+
+Nu exista niciun fisier exemplu de la Banca Transilvania in `Alte\` (doar
+`Alte\Extras_de_cont_11634808MT 940.txt` si `.xls`, care nu par BT dupa continut/format).
+Descrierea de mai jos vine strict din parserul `csvBT`
+(`oproceduri_import.prg:2923-3025`).
+
+**Detectie format** (`oproceduri_import.prg:1502-1507`), pe baza primei linii nevide a
+fisierului CSV:
+- incepe cu `"tranzactii"` sau `"transactions"` -> `csvBT(fisier, 1)` = "lista de tranzactii"
+  (export lunar din BT24/NeoBT), antet comentat in cod: `Data tranzactie, Data valuta,
+  Descriere, Referinta tranzactiei, Debit, Credit, Sold contabil` (7 coloane).
+- incepe cu `[lista de tranzactii]` sau `"lista de tranzactii"` -> `csvBT(fisier, 2)` = "extras
+  de cont", antet: `Data tranzactie, Data valuta, Referinta, Tip tranzactie, Descriere,
+  Debit, Credit` (7 coloane, ordinea Referinta/Tip tranzactie difera de varianta 1).
+
+**Cont propriu (IBAN al extrasului)**: cautat linie cu linie dupa eticheta `"numar cont:"`,
+primele 24 caractere dupa virgula (`oproceduri_import.prg:2936-2940`); daca nu se gaseste,
+`This.cIBAN = 'BT'` (`oproceduri_import.prg:2942-2944`).
+
+**Curatare text inainte de parsare CSV** (`oproceduri_import.prg:2954-2969`):
+- elimina virgulele din interiorul ghilimelelor si ghilimelele insesi;
+- elimina `LF + "~~"` (artefact de export BT24 cand descrierea trece pe linia urmatoare);
+- reuneste liniile rupte, pastrand un rand nou doar daca urmeaza dupa el o data (mai multe
+  formate acceptate: `AAAA-LL-ZZ`, `ZZ/LL/AAAA`, `ZZ.LL.AAAA`, `ZZ-LL-AAAA`, `AAAA/LL/ZZ`);
+- detecteaza varianta BT24 (are coloana "sold contabil" -> `llBT24`, linia 2966): la BT24
+  sumele de pe Debit sunt negative si se inverseaza semnul (`oproceduri_import.prg:2980-2982`).
+
+**Camp "Descriere"** - text liber, dar cu conventie interna a bancii separata prin `;`.
+Exemplele reale din codul sursa (comentarii, `oproceduri_import.prg:2989,2992` -
+denumiri de firma anonimizate mai jos):
+```
+"30-05-2024","30-05-2024","Incasare OP - canal electronic;f 2024103;XXX SRL;ROXXBTRLXXXXXXXXXXXXXXXX;BTRLRO22;REF: 014ZEXA24151017X","014ZEXA24151017X","","1,184.24 ","2,184.24 "
+2024-06-05,2024-06-05,"Incasare OP - canal electronic;F 2024131;XXX SA;ROXXBTRLXXXXXXXXXXXXXXXX;BTRLRO22;REF: 414ZEXA2415702DU",414ZEXA2415702DU,,"797.30","12,013.14"
+```
+Campurile din "Descriere" (despartite prin `;`), asa cum le foloseste codul:
+1. tip tranzactie (text liber, ex. "Incasare OP - canal electronica");
+2. referinta/numar document - din acest camp `GetRegExpAllNumbers` extrage numerele candidate
+   de factura (`oproceduri_import.prg:3017-3019`);
+3. denumirea partenerului (`mtert`, `oproceduri_import.prg:3013`);
+4. IBAN-ul partenerului (`miban`, `oproceduri_import.prg:3014`);
+5. codul SWIFT al bancii partenerului (necitit de cod);
+6. referinta platii (necitita de cod, ramane doar in text).
+
+**Clasificare tip tranzactie** dupa cuvinte cheie in "Descriere"
+(`oproceduri_import.prg:2998-3012`): `"comision"` (la inceput), `"comision-atm"`, `"comision
+procesare ridicare numerar"`, `"pachet izi"` -> cont 627 (cheltuiala bancara); `"retragere de
+numerar"` -> transfer numerar (cont 581/5311); `"transfer intern"` -> transfer intre conturi
+proprii (cont 581); orice altceva -> tratat ca tert (client/furnizor), cont 4111/401.
+
+## Ce nu am lamurit
+
+- Nu am gasit un fisier CSV real exportat de Banca Transilvania in acest working copy, deci
+  descrierea de la punctul E e dedusa din cod si din exemplele scrise ca si comentarii de
+  dezvoltator - nu am validat-o pe un export proaspat (BT poate sa fi schimbat coloanele intre
+  timp; codul insusi are comentarii separate pentru "BT24" si "NeoBT" ca doua variante usor
+  diferite).
+- Nu exista (cel putin nu l-am gasit) un tabel de audit/log care sa retina *propunerea automata
+  a algoritmului* separat de *starea finala dupa corectia manuala din `frm_modific2024`* - masuratorile
+  de productie (`BACKTEST_BANCA.md`) vad doar rezultatul final, nu cat de mult "salveaza"
+  operatorul azi prin corectii manuale linie cu linie. Pentru a masura exact asta ar trebui
+  adaugata o logare la pasul de import (inainte de afisarea formularului).
+- Nu am verificat daca IBAN-ul partenerului extras de `csvBT` (`miban`,
+  `oproceduri_import.prg:3014`) ajunge sa fie salvat ca atare in `ACTACTAN` sau se pierde
+  la constructia liniei finale (`oproceduri_import.prg:898-909`) - `iban` apare in
+  `C_IMPORT_TEMP`/`cActTemp`, dar nu l-am gasit explicit in lista de coloane a `INSERT INTO
+  actactan` verificata la punctul A.8; ar necesita o verificare suplimentara pe schema reala a
+  tabelei `ACTACTAN` din Oracle (`DESC actactan`), pe care nu am rulat-o (doar SELECT-uri, nu
+  aveam nici conexiune).