sync SVN r18068
This commit is contained in:
124
docs/cercetare/rec_directie_roacont_2026_09.md
Normal file
124
docs/cercetare/rec_directie_roacont_2026_09.md
Normal file
@@ -0,0 +1,124 @@
|
||||
# Propuneri de directie ROACONT (09.2026)
|
||||
|
||||
Propunerile finale dupa cercetarea de piata si backtestul pe 23 de scheme de productie. Cifrele
|
||||
marcate "masurat" vin din backtest cronologic pe date reale, comparat cu ce a confirmat operatorul;
|
||||
restul sunt marcate "nemasurat". Dovezile si metoda: `ROACONT\docs\cercetare\piata_ai_2026_09\`.
|
||||
|
||||
Premisa: fara clienti noi, fara rescriere, datele raman in Oracle-ul clientului.
|
||||
|
||||
## 1. Import eFactura primite
|
||||
|
||||
Ecranul `frm_import_efactura` (`COMUN\clase\anaf_efactura.vcx`, lansat din
|
||||
`COMUN\programe\import_efactura.prg:167`). Aici e concentrata munca manuala repetitiva a lunii:
|
||||
13.418 facturi de intrare si 33.844 linii de articol pe an la un cabinet de 21 de firme, din care
|
||||
15.565 linii primesc cont de la operator. Restul fluxului lunar e deja automatizat.
|
||||
|
||||
**1.1 Cheie de articol normalizata.** `GetArticolEFByPartDenumire`
|
||||
(`COMUN\programe\oproceduri_comune.prg:7362`) cauta in `ANAF_VEFACTURA_DETALII` cu
|
||||
`TRIM(UPPER(d.articol)) = ?pcDenumire` - litera cu litera, deci orice cifra din denumire strica
|
||||
potrivirea ("Abonament 08/2026" vs "09/2026"). Propunere: cheie fara cifre + prefix configurabil per
|
||||
firma. Masurat: 52,0% -> 72,3% recunoscute, ~3.150 linii/an in plus; precizia scade 95,0% -> 93,4%.
|
||||
|
||||
**1.2 Contabilizare in lot.** Semafor pe factura (verde = ultimele 5 facturi ale furnizorului contate
|
||||
identic; galben = istoric variabil; rosu = furnizor nou), buton pentru tot ce e verde, anulare in
|
||||
bloc. Masurat pe cont sintetic: 41,3% din facturi pe verde cu 93,8% precizie, nicio firma sub 85% -
|
||||
circa 5.200 facturi/an fara interventie. Anularea in bloc nu e optionala.
|
||||
|
||||
**1.3 LLM doar pe rest.** ~28% din linii nu au precedent, plus 7% furnizori noi. Se trimite doar
|
||||
textul articolului si lista de conturi - fara sume, fara parteneri. Sub 20 USD/luna pentru toti
|
||||
clientii. Obligatoriu: eticheta vizibila ca sugestia vine de la AI (regula UE, august 2026).
|
||||
|
||||
## 2. Import extrase de banca
|
||||
|
||||
Flux: `Programe\ocont2003.prg:845` -> fabrica `ImportNote` (`Programe\oproceduri_import.prg:57`) ->
|
||||
parser per format -> imperechere in `ExtrasBanca::CreeazaNote` (`oproceduri_import.prg:312-926`) ->
|
||||
corectie manuala in `frm_modific2024` -> scriere in `ACT` cu `id_set = 90023`.
|
||||
|
||||
**2.1 Cheie de partener invatata din istoric.** Azi partenerul se ia de pe o pozitie fixa in
|
||||
descriere (`oproceduri_import.prg:3013`) si se cauta exact in nomenclator
|
||||
(`oproceduri_comune.prg:6623-6645`). Nu exista cheie disponibila la toate formatele: codul fiscal
|
||||
lipseste la majoritatea (la BT e fixat gol, `oproceduri_import.prg:3015`), iar IBAN-ul nu are pe ce
|
||||
lucra - doar 4,5% din parteneri au `CONT_BANCA` completat. Propunere: se retine din istoric ce
|
||||
partener a fost confirmat pentru un IBAN si pentru un text de descriere normalizat, si se propune
|
||||
doar cand acea cheie a dus **de fiecare data** la acelasi partener.
|
||||
Masurat pe 3.490 de linii, 7 firme, 12 luni: **4,6% -> 28,5% acoperire la 97,9% precizie**.
|
||||
Pe firme: 79,5% (BT) ... 10,5% (banci care trimit doar numere de referinta) - regula tace singura
|
||||
acolo unde textul nu spune nimic, deci nu cere configurare per banca.
|
||||
**Garda de unicitate e esentiala**: fara ea, 58,3% acoperire dar 56,4% precizie.
|
||||
|
||||
**2.2 Salvarea IBAN-ului pe partener.** Parserul extrage IBAN-ul (`oproceduri_import.prg:3014`, scris
|
||||
in `explicatia4` la `:902`) dar nu ajunge in baza: gol la 878 din 879 de linii. Daca s-ar salva pe
|
||||
partener la confirmarea operatorului, nomenclatorul s-ar umple singur si cheia cea mai sigura ar
|
||||
deveni utilizabila.
|
||||
|
||||
**2.3 Factura: nu se automatizeaza, se scurteaza cautarea.** Masurat pe 3.074 de linii legate de o
|
||||
factura: numarul acelei facturi apare in textul bancii doar in **25,0%** din cazuri (0% - 56,6% pe
|
||||
firma). Potrivirea dupa suma pe documentele deschise acopera 21,2% cu 89,9% precizie, prea slaba
|
||||
pentru completare automata. Plafonul e structural - informatia lipseste din fisier. Efortul merita
|
||||
mutat pe: dupa ce partenerul e cunoscut, arata lista scurta a documentelor lui deschise ordonate
|
||||
dupa potrivirea sumei.
|
||||
|
||||
**2.4 Defecte confirmate (de reparat oricum, independent de propuneri).**
|
||||
- Pozitiile fixe din descrierea BT nu sunt validate (`oproceduri_import.prg:3013-3014`): la "Plata OP
|
||||
inter" si "Comision plata OP" descrierea are un camp in plus, deci denumirea se citeste ca numar de
|
||||
OP si IBAN-ul ca denumire. Dovedit prin test headless pe fisiere reale.
|
||||
- Bucla de asociere document iese neconditionat dupa primul numar incercat
|
||||
(`EXIT`, `oproceduri_import.prg:736`), contrar comentariului de la `:701-706` - o plata care acopera
|
||||
mai multe facturi ramane nepereche.
|
||||
- La numar de document ambiguu, `GetDocumentByContPartenerAct` doar scrie in log
|
||||
(`oproceduri_comune.prg:7038`) fara sa arate operatorului candidatii.
|
||||
- **`VerifIBAN` (`COMUN\programe\oproceduri_comune.prg:7885`) intoarce raspuns gresit** cand apelantul
|
||||
are selectat un cursor cu camp `iban`: variabilele nu sunt declarate si citirile neprefixate se
|
||||
rezolva la CAMP, nu la parametru. Afecteaza si validarea IBAN-ului la introducerea partenerului
|
||||
(`onomenclatoare.vcx`, `oparteneri.vcx`). Corectie: `LOCAL` + prefix `m.` pe toate referintele.
|
||||
|
||||
**2.5 Adoptie.** Doar 7 din 21 de firme au linii venite din import de extras. Inainte de a imbunatati
|
||||
algoritmul, merita aflat de ce nu se foloseste la celelalte.
|
||||
|
||||
## 3. Restul, in ordinea recomandata (nemasurate)
|
||||
|
||||
1. **Drepturi in modulul web** - blocant: pana nu se rezolva, nimic nu se poate arata unui client.
|
||||
2. **Punte MCP peste Oracle** - intrebi in Claude Code, el ruleaza interogari pregatite; modelul
|
||||
primeste rezultatul, nu baza. Singura cale prin care AI-ul intra adanc in ROA fara rescriere.
|
||||
3. **Tablou de bord multi-firma cu alerte** (luna neinchisa, token SPV expirat, facturi
|
||||
necontabilizate) - **singurul candidat de abonament nou** din toata cercetarea.
|
||||
4. **Inchiderea de luna ca flux unic** - azi 13 comenzi in doua meniuri, fara ordine si fara bifare.
|
||||
5. **Sablon de import la preluarea unui client** - maparea de conturi produsa o data si refolosita.
|
||||
6. **Asistent de suport pe documentatie** - butonul de chat exista, ii lipseste continutul.
|
||||
7. **e-Transport** - azi nu exista nimic.
|
||||
|
||||
## 4. Respinse, ca sa nu fie repropuse
|
||||
|
||||
- **Bon fiscal digital**: QR-ul contine doar identificatori (data/ora, numar, seria AMEF, optional CUI
|
||||
cumparator), nu valoare/TVA/cote; nu exista serviciu ANAF pentru descarcarea bonurilor **primite**;
|
||||
obligatiile cad pe producatorii de case de marcat. Zero efort in ROACONT.
|
||||
- **Codul de articol din eFactura**: furnizorii nu-l trimit (34 linii din 4.426).
|
||||
- **GPU local pentru AI**: costa cat 30 de ani de abonament la volumele actuale.
|
||||
- **Rescriere in alt limbaj / mutare in browser**: un an fara actualizari legislative = pierderea
|
||||
clientilor. Nici SAGA nu face asta.
|
||||
- **Cloud propriu cu datele clientilor**: cost de operare imposibil pentru doi oameni si sterge
|
||||
singurul avantaj fata de SmartBill/Oblio/Keez.
|
||||
- **Intrebari in limbaj natural direct pe baza de date**: 31% raspunsuri corecte pe baze reale.
|
||||
|
||||
## 5. Capcane de masurare (platite)
|
||||
|
||||
- Numarul de linii cu `ID_FACTD/ID_FACTC` completat **nu** masoara automatizarea - imperecherea o face
|
||||
operatorul. Nu exista tabel de audit: corectiile din `frm_modific2024` se fac inainte de scrierea in
|
||||
`ACT` (`ocont2003.prg:1245-1257`). Singurul backtest valid: se reia regula cronologic pe
|
||||
`ACT.EXPLICATIA` al liniilor cu `id_set = 90023` si se compara cu ce e inregistrat pe linie.
|
||||
- Pe o linie de banca, partenerul se ia **de pe latura contului 401/411**, nu cu
|
||||
`nvl(id_partd, id_partc)` - pe latura 512 partenerul e contul bancar propriu si cifrele ies fals
|
||||
de bune.
|
||||
- Subinterogarile corelate peste `ACT` omoara serverul; se scriu cu JOIN si hint `materialize`.
|
||||
|
||||
## 6. Surse externe pentru afirmatiile de piata
|
||||
|
||||
Verificate 03.09.2026.
|
||||
|
||||
- SmartBill a livrat preluarea si prelucrarea automata a eFacturilor primite din SPV la 28.08.2026:
|
||||
ajutor.smartbill.ro/article/1256 si /1128. Extrase bancare prin open banking: /article/1073.
|
||||
- Obligatia de transparenta AI (Regulament UE, Art. 50) se aplica din 02.08.2026 - utilizatorul trebuie
|
||||
informat ca interactioneaza cu AI: bchlaw.eu/articles/regulamentul-european-privind-ia-etapa-de-la-2-august-2026/
|
||||
- Pret GPU la 08.2026: RTX 5090 ~28.000 lei, RTX PRO 6000 96GB ~76.000 lei (techpowerup.com/351549).
|
||||
- Intrebari in limbaj natural pe baze de date: 82% pe BIRD, 31% pe Spider - de aceea e respins.
|
||||
- Bon fiscal digital: sursele legale, in `ROACONT\docs\cercetare\piata_ai_2026_09\BON_FISCAL_DIGITAL.md`.
|
||||
Reference in New Issue
Block a user