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.

docs/conventie_encoding_cp1252.md

@@ -1,6 +1,20 @@
-# Capcana: corupere diacritice la editarea .sc2/.vc2
+# Capcana: corupere diacritice la editare (.sc2/.vc2 si orice fisier non-ASCII)
 
-Comun tuturor proiectelor ROA* - tine de formatul .sc2/.vc2 (FoxBin2Prg), nu de un proiect anume.
+Comun tuturor proiectelor ROA*.
+
+## Regula generala (orice fisier)
+
+Orice fisier care contine octeti non-ASCII (>= 0x80) se editeaza numai byte-safe -
+PowerShell `[IO.File]::ReadAllText`/`WriteAllText` cu `GetEncoding(<codepage>)` - niciodata cu
+Edit-ul agentului: acesta rescrie fisierul ca UTF-8 si inlocuieste octetii non-ASCII cu `EF BF BD`
+(caracterul de inlocuire), inclusiv in zone neatinse si inclusiv in `.prg` obisnuite, nu doar
+`.sc2`/`.vc2`. Cens obligatoriu inainte SI dupa editare: numarul si secventa octetilor >= 0x80
+trebuie sa fie identice (citire ca bytes; comparatie cu `git show HEAD:<cale>` cand fisierul e
+urmarit).
+
+## Specific .sc2/.vc2 (FoxBin2Prg)
+
+Tine de formatul .sc2/.vc2, nu de un proiect anume.
 
 ## Faptul
 

docs/depanare_testare_vfp.md

@@ -127,6 +127,11 @@ Cand un bug apare "de azi", compara cu clasa veche fara sa atingi SVN:
 - **`SET PROCEDURE TO x.prg`**: in `.exe` se rezolva din modulele compilate (orice `.prg` din
   `.pjx`), din IDE doar prin `SET PATH`. O cale lipsa din `SET PATH` se vede deci doar necompilat,
   iar in `Try` trece tacut.
+- **`INKEY(0, ...)` nu e un poll, e asteptare NELIMITATA a unei taste.** Pentru "a apasat
+  utilizatorul ESC?" fara sa blochezi, foloseste timeout mic (`INKEY(0.01, 'H')`). Cat timp
+  `INKEY(0)` asteapta, timerele VFP nu se declanseaza, deci un dialog/o bucla blocata asa nu poate
+  fi deblocata din interiorul procesului - in rulare headless arata ca un proces viu care nu mai
+  scrie in log.
 
 ## 7. Capcane la SCRIEREA scriptului de test
 
@@ -166,3 +171,10 @@ Cand un bug apare "de azi", compara cu clasa veche fara sa atingi SVN:
   folosesti efectiv: `TYPE('loO.Objects.Count') = 'N'` e `'U'` daca lantul punctat nu exista,
   deci e si suficient, si independent de litera de tip. Aceeasi prudenta la `TYPE('loO.Value')`
   (tipul variaza cu continutul) si `TYPE('loO.Visible')`.
+- **Optiunile citite ca globali (`gn<NUME>`/`gc<NUME>`) nu se reimprospateaza din `scrie_optiune()`.**
+  `scrie_optiune()` + `actualizeaza_optiuni()` scriu tabela `OPTIUNI` si cache-ul `crsOptiuni` (de unde
+  citeste `citeste_optiune()`), dar globalii sunt creati o singura data, la login/schimbare de firma
+  (`oinit_optiuni.prg`, `actualizeaza_optiuni_program`/`optiuni_firma`). Un test care schimba o optiune
+  si apoi apeleaza cod care citeste globalul masoara valoarea veche, fara niciun semn de eroare.
+  Verifica intai pe ce cale citeste codul testat; daca e globalul, seteaza-l direct in test (si
+  restaureaza-l la final), nu prin `scrie_optiune()`.

docs/flux-editare-vfp-text.md

@@ -60,6 +60,12 @@ Pasul 3 loveste si definitii `*m:` **deja existente si corecte** (patit pe ROAGE
 `Createobject` cu "Data type mismatch" raportat la linia apelanta). Deci dupa ORICE sesiune IDE pe
 o clasa atinsa: `git_sync` + compara lista `*p:`/`*m:` cu starea de dinainte.
 
+**`Column` nu are `When`, `Valid` sau `Click`** - apartin controlului din coloana (masurat:
+`PEMSTATUS(grid.Column1,'When',5)` da `.F.`, pe `Column1.Text1` da `.T.`). O
+`PROCEDURE <grid>.<coloana>.When` scrisa in text ajunge in binar si chiar ruleaza, dar prima
+salvare din IDE o sterge tacit, ca la pasul 3. Se scrie pe `CurrentControl`-ul coloanei:
+`<grid>.<coloana>.<control>.When`.
+
 Verificare inainte de write-back: `grep -n '\*[pm]: <nume>' <fisier>.vc2`.
 Pozitia in fisier nu e libera — FoxBin2Prg regenereaza membrul la pozitia lui alfabetica din
 `*<DefinedPropArrayMethod>` (cu `_` dupa litere); o intrare sau o metoda scrisa in alta parte pica
@@ -135,3 +141,6 @@ fidelity-check-ul. Sursa de adevar pentru ordine si pozitie: textul din `<stagin
   trebuie sa dea 0. Semnal secundar: daca `git diff --numstat` arata brusc tot fisierul schimbat
   (nu doar liniile atinse), capetele de linie sunt gresite. Reparare (doar dupa ce ai confirmat ca
   fisierul n-are deja niciun `\r`): `perl -pe 's/\n/\r\n/' < f > f.tmp`.
+- `txt2vcx.ps1` si `vfp_symbols.ps1` fara `-ProjectRoot`/`-CacheRoot` explicit cad pe default-ul lor,
+  care arata spre `ROAACNPRO` - pe alt proiect esueaza cu "Cannot find path" sau, mai rau, citesc alt
+  arbore. Paseaza-le mereu explicit, si in prompturile subagentilor.

docs/reguli_lucru.md

@@ -1,5 +1,14 @@
 # Reguli de lucru agent (comune proiectelor ROA VFP)
 
+0. **Contextul sesiunii principale: te opresti la maxim 250k si salvezi progresul.** Nu e
+   optional si nu se negociaza cu "mai termin o banda". La 250k opresti lucrul, scrii in fisierul
+   de progres starea exacta - ce e gata si testat, ce e scris dar neverificat, ce fisiere sunt
+   lasate intr-o stare intermediara (in special text `.vc2`/`.sc2` fara write-back in binar) si
+   care e primul lucru de facut - si predai unei sesiuni noi. Limita absoluta 275k.
+   Nu estima contextul, masoara-l (`monitorizare-context.md`); daca nu ai masuratoare, opreste-te
+   mai devreme, nu mai tarziu. Orchestrarea multor benzi paralele consuma context mai repede
+   decat pare: fiecare raport de agent, fiecare verificare si fiecare decizie se aduna.
+
 1. Modificari de cod: diff ca FISIER `docs\diff_runda<N>_<subiect>.patch`
    (`git diff --no-index <baseline.bak> <editat>`), nu in terminal. **COMMIT-ul** e singurul pas
    care asteapta aprobarea patch-ului. Write-back-ul in binar (txt2vcx) si testele se fac IMEDIAT
@@ -43,6 +52,26 @@
    propune COMPLETAREA unei functii/tabele/view comune, nu o varianta paralela. 80/20: solutia cea
    mai simpla care rezolva cazul real. Completeaza `inventar-comun.md` la orice descoperire/creare
    de element comun nedocumentat.
+   **Scara (ponytail), te opresti la prima treapta care tine** - se aplica si de subagenti, nu doar
+   de sesiunea principala: (1) trebuie sa existe? nevoie presupusa, nu ceruta = nu se scrie, se
+   spune intr-un rand; (2) exista deja in cod (`inventar-comun.md`, `COMUN\`, clasa/procedura din
+   acelasi modul)? refoloseste; (3) o face limbajul (VFP, SQL Oracle) sau o biblioteca deja
+   incarcata in `roacont.prg`? foloseste-o - dependinta noua, niciodata pentru ce tin cateva linii;
+   (4) intra intr-o linie? o linie; (5) abia apoi minimul care merge.
+   Scara scurteaza SOLUTIA, niciodata cititul: intai urmaresti fluxul real prin toate fisierele
+   atinse, apoi alegi treapta. Diff mic in locul gresit nu e economie, e a doua eroare.
+   La eroare: repari cauza in functia comuna prin care trec toti apelantii (`-Grep` pe apelanti
+   inainte de a edita), nu doar calea din raport - o garda intr-un loc e diff mai mic decat o garda
+   in fiecare apelant, si nu lasa fratii stricati.
+   Interzis din oficiu: clasa/interfata cu o singura utilizare, optiune de configurare pentru o
+   valoare care nu se schimba, schele "pentru mai tarziu", generalizare pentru un al doilea caz
+   care nu exista.
+   Nu se simplifica NICIODATA: validarea datelor venite din exterior (XML eFactura, import,
+   raspuns web), tratarea erorilor care pot pierde date, drepturile de utilizator, si ce s-a cerut
+   explicit.
+   Scurtatura deliberata cu plafon cunoscut (blocare globala, scanare O(n2), euristica naiva) se
+   marcheaza cu un singur comentariu `*!* ponytail: <plafonul> - <cum se creste daca deranjeaza>`;
+   e singura exceptie de la regula 2, care interzice justificarile in cod.
    **Cod nou: clase in `.prg`, nu metode in `.vcx`/`.scx`.** Logica se incapsuleaza intr-o clasa
    (`Define Class ... As Custom`) dintr-un `.prg`; formularul sau clasa vizuala doar instantiaza
    obiectul (`Createobject`) si il apeleaza, metoda din binar ramanand un apel de o linie. Sablon:

docs/todos.txt

@@ -101,3 +101,6 @@ DONE 21. ROACONT - in formularul de verificare coduri fiscale, ar trebui sa fie
 - definire serii numere facturi
 - completare optiuni document factura, aviz, documente incasare, bon fiscal, bon pos
 Poate un wizzard
+43. ROACONT - sa se poata genera xml efactura stornare si sa se trimita in SPV. Acum se poate face manual prin Borderou eFactura > Listare > Editare in browser > Stornare > Salvare xml stornat > meniul eFactura > Trimite xml efactura > trimitere in SPV xml storno salvat anterior.
+Vreau sa fie operatia mai simplificata pentru utilizatori, pentru cazul in care s-a trimis in SPV o factura eronat (exemplu - client gresit). Sa se poata genera si trimite xml stornat. Utilizatorul poate apoi sa stearga factura originala din contabilitate si sa o reemita corectata (ex cu clientul corect) si sa o trimita din nou in eFactura.
+In felul acesta se rezolva, chiar daca nu oficial, imposibilitatea de anulare a unei facturi trimise in SPV. O stornez doar cu xml, si o sterg din contabilitate.