solduri2roa/docs/review_ceo_etapa2.md

# Review CEO - planul etapei 2 (`plan_etapa2_convertor.md`, PROPUNERE v2)

Review de strategie, aplicat ca analiza (fara intrebari interactive). Nu s-a modificat planul.
Nu s-a scris cod. Scorurile si modurile de mai jos sunt o adaptare a skill-ului `plan-ceo-review`
la un plan intern, cu un singur utilizator (Marius).

Documente citite integral: `plan_etapa2_convertor.md`, `plan_solduri2roa.md`, `decizii_import.md`,
`raport_sursa_saga_xlsx.md`, `raport_exporturi_saga_noua.md`, `raport_form_init_balanta.md`,
`config_cont_ireg.md`, `conturi_cu_analitice.md`, `verificare_FUNDATIA.md`, `CLAUDE.md`,
`extract_balanta.py`, `genereaza_xlsx.py`, `.gitignore`.

## 0. Modul de review propus (Step 0F adaptat)

Skill-ul cere alegerea unui mod. Nu pot intreba, deci il propun si il justific:
**SELECTIVE EXPANSION cu felie de HOLD** - planul e pe directia corecta, dar are 2-3 bucati care
nu-si justifica existenta acum (cititorul FDB fara date reale, complexitatea merge-ului de mapare)
si 1-2 bucati lipsa (contractul intermediar, sursa setului de parteneri). Nu e "go big": produsul
e intern, utilizatorul e unul singur, migrarile sunt rare. Nu e nici "reduction": cateva lucruri
din plan sunt chiar indispensabile (contractul de CSV, maparea per firma, regresia).
Motivul principal de a nu face HOLD pur: planul nu a evaluat nicio alternativa de arhitectura
(vezi C10), deci "scopul e acceptat" nu se poate sustine inca.

---

## 1. Scoruri pe dimensiunile skill-ului

| # | Dimensiune (skill) | Nota | Ce ar duce-o la 10 |
|---|---|---|---|
| 1 | Premisa corecta (0A) | 6/10 | Raspuns explicit la "cat de des migram?" si "PDF e suficient cat timp clientul nu da baza?". Planul presupune ca FDB e drumul viitor fara sa spuna cat de des ajunge acolo. |
| 2 | Refolosire cod existent (0B) | 8/10 | Nume per sub-problema la ce cod exista deja: reader PDF neatins; tot restul vine din `genereaza_xlsx.py`. Lipseste doar explicitarea setului de parteneri hardcodat (C1). |
| 3 | Alternative de implementare (0C-bis) | 3/10 | Planul are o singura arhitectura ("un format intern, trei cititoare"). Lipsesc varianta minima (un script `--sursa`) si varianta "FDB ca sursa primara". |
| 4 | Aliniere cu starea ideal 12 luni (0C) | 7/10 | O comanda `migreaza.py --firma --an --luna --sursa` cu mapare persistenta. Planul merge exact spre ea, dar nu scrie cum arata finalul (interfata, contract). |
| 5 | Arhitectura (S1) | 7/10 | Contractul intermediar este definit complet, negru pe alb (C4). Acum "acelasi CSV + optional doua fisiere" e o intentie, nu o specificatie. |
| 6 | Harta erorilor / rescue (S2) | 4/10 | 3 conditii de stop sunt numite (bun), dar lipsesc clasele de eroare pentru cititoare (fisier lipsa, antet schimbat, FDB blocat) si ce vede utilizatorul (C16). |
| 7 | Securitate / date de client (S3) | 6/10 | `.gitignore` extins pentru `.FDB`, `parteneri_*.csv`, `facturi_*.csv` (C8). Risc mic dar real: datele de partener sunt PII/financiar. |
| 8 | Data flow / edge cases (S4) | 6/10 | Regula de periodizare REGISTRU -> prec/rulaj/fin scrisa si testata pe o luna cu miscari inainte (C3); tratarea `scadent` NULL (C15). |
| 9 | Calitatea codului (S5) | 7/10 | Decizia despre complexitatea merge-ului de mapare (C6); altfel e curat si reutilizeaza ce exista. |
| 10 | Teste / porti de verificare (S6) | 6/10 | Poarta FDB-vs-xlsx declarata ca ceea ce este (nu inchide lane-ul pe date de joaca, C2) + testul de regresie rulat la fiecare lane, nu doar la final (C5). |
| 11 | Performanta (S7) | 8/10 | Nimic de facut; FDB e o copie citita o data, agregare unica. De notat doar ca firma de joaca nu spune nimic despre timp pe o baza reala. |
| 12 | Observabilitate (S8) | 6/10 | Raportul `verificare_<firma>.md` extins cu numar de parteneri/facturi, sursa folosita si invariantul care inlocuieste "Totaluri" pe sursele xlsx/fdb (C9). |
| 13 | Deploy / rulare la client (S9) | 5/10 | Procedura de copiere a bazei (gbak) mutata in Etapa 2 odata cu cititorul FDB, sau cititorul FDB declarat explicit "intern, nefolosibil la client" (C7/C12). |
| 14 | Traiectorie pe termen lung (S10) | 7/10 | E ok. Reversibilitate 5/5 (scripturi interne, git). Singura datorie: `conturi_cu_analitice.md` contrazice `decizii_import.md` pct.15 pe 5125 (C14). |
| 15 | Design / UX intern (S11) | 5/10 | `mapare_<FIRMA>.xlsx` este interfata omului: header congelat, dropdown la `stare`, evidentiere `NOU`/`DISPARUT`. Planul nu spune nimic despre aspectul lui. |

Scor mediu (nesponderat): ~6,1/10. Planul este peste media unui plan intern, dar isi asuma prea
mult pe incredere (FDB) si prea putin pe specificatie (contract, sursa parteneri).

---

## 2. Constatari (fiecare: ce e in plan -> ce e in neregula -> ce propun)

### C1. Conturile cu parteneri: planul spune "sursa de adevar = Oracle", dar codul le are hardcodate, iar cele doua liste nu coincid

**In plan** (sectiunea "Pasul de mapare"): *"Ce NU se configureaza aici: care conturi merg pe
parteneri. Ramana `CONFIG_CONT_IREG` din Oracle ... e sursa de adevar a ROACONT ... Programele
vechi aveau lista hardcodata in `.prg`, exact ce nu repetam."*

**In neregula:** planul nu spune NICIODATA cum ajunge configuratia Oracle in unealta. Iar codul de
azi o are hardcodata: `genereaza_xlsx.py:43-53` (`PARTENER_SINTETIC = {401,4092,4111,461,462,4551}`,
`PARTENER_BANCA = {5121,5124}`, `PARTENER_FARA_ANALITICE = {5311}`). Lista din Oracle
(`config_cont_ireg.md:89-91`) are **33 de conturi cu `CU_INREGISTRARI=1`** (403, 404, 408, 409,
4091, 4093, 4094, 4118, 413, 418, 419, 426, 4511, 456, 457, 471, 472, 4754, 542, 8051, 1621, 167,
232, 234, 261, 2678, 2691 ...). Daca unealta citeste fidel Oracle, comportamentul se schimba fata
de ce s-a validat in productie (unde doar lista mica a fost folosita). Nu e o eroare, dar este o
divergenta nerezolvata intre doua surse pe care planul le trateaza ca sinonime.

**Propun:** alege o singura sursa si scrie-o in plan:
(a) snapshot local versionat `config/cont_ireg.csv` (coloanele `cont`, `fel_cont`, `cu_inregistrari`),
generat de un SQL documentat, citit de unealta - fara dependinta Oracle la rulare;
(b) pastrezi setul hardcodat (dar atunci scoti din plan afirmatia "Oracle e sursa de adevar");
(c) citire live Oracle - de evitat (contra "fara alte dependinte").
Recomand (a): o sursa, zero credentiale la rulare, si se vede in git cand se schimba.

### C2. Cititorul FDB e cel mai valoros si cel mai putin verificat; poarta lui de terminare e aproape vida

**In plan** (sectiunea "Poarta de verificare"): *"cititorul 3 (FDB) si cititorul 2 (xlsx) trebuie
sa produca acelasi CSV ... Acesta este criteriul care inchide lane-ul `citire-fdb`, nu 'ruleaza fara
eroare'."*

**In neregula:** planul recunoaste singur (aceeasi sectiune) ca firma de joaca *"are doar conturi
sintetice, niciun analitic... 2 furnizori, 0 clienti, 1 factura"*. Deci poarta care "inchide"
lane-ul nu atinge exact partile riscante: analitice, parteneri, facturi per partener, cod fiscal,
scadenta. Pe 10 randuri sintetice, orice cititor plauzibil trece. Poarta e utila ca fumegatoare,
nu ca definitie de "gata". In plus, dovada din `raport_exporturi_saga_noua.md` C.3/C.5 arata ca
singurul rand din `INTRD` are `SCADENT=NULL` si `NEACHITAT=0` - deci nici "scadenta reala" nu e
demonstrata.

**Propun:** muta obtinerea unei baze `.FDB` reale + exportul ei din Etapa 3 in Etapa 2, ca
**preconditie** pentru lane-ul `citire-fdb` (nu pentru tot planul). Cat timp nu exista, scrie in
plan ca `citire-fdb` se poate livra doar ca "pregatit, neverificat pe analitice". Nu numi poarta
"criteriu care inchide lane-ul".

### C3. Semantica de periodizare REGISTRU -> prec/rulaj/fin nu este definita (inima corectitudinii FDB)

**In plan** (sectiunea "Cititorul 3 - Firebird"): *"balanta: agregare pe `REGISTRU` la data ceruta.
... nu se citeste `CONTURI.DEB_PREC`, se agrega `REGISTRU`."*

**In neregula:** planul nu defineste ce inseamna "la data ceruta" si cum se separa
`DEB_PREC` (inceput de perioada), `RULAJ_D` (perioada) si `FIN_D` (final). Exportul SAGA are
4 notiuni distincte (`raport_exporturi_saga_noua.md` A.1, C.4): `DEB_INIT` = inceput de an,
`DEB_PREC` = inceput de perioada, `RULAJ` = perioada, `FIN` = final. CSV-ul tinta cere
`prec_d/prec_c, rulaj_d/rulaj_c, total_d/total_c, sold_d/sold_c`. Daca intervalele nu sunt
definite exact, CSV-urile FDB si xlsx **nu vor fi identice pe date reale** - vor coincide doar pe
firma de joaca, unde toate miscarile sunt inainte de perioada (8 note in `REGISTRU`).

**Propun:** scrie in plan formulele exacte, de obicei:
`prec = SUM(suma) unde DATA < prima_zi_a_lunii_cerute`, `rulaj = SUM unde luna_ceruta`,
`total = prec + rulaj`, `sold = total pe net`; si pentru `DEB_INIT` separat, pentru `sold_in`.
Adu ca test o luna cu miscari in 3 locuri: anul precedent, inainte de luna, in luna.

### C4. Contractul intermediar (CSV + parteneri + facturi) nu este specificat

**In plan** (sectiunea "Arhitectura"): *"Toate cele trei cititoare produc acelasi CSV ... plus -
optional - doua fisiere de parteneri."* Si la "Randurile FACTURA": parametrii
`--furnizori <fisier>`, `--clienti <fisier>`, `--facturi <director>`, `--fdb <cale>`.

**In neregula:** nu exista nume de fisiere, coloane si relatia dintre "fisierele de parteneri" ale
pasului de citire si flagurile generatorului. In plus, cititorul 2 propune `TIP` ca "a 13-a
coloana, optionala", in timp ce reader 1 (`extract_balanta.py`) ramane "nemodificat" si scrie
12 coloane (`pagina, cont, denumire, prec_d, prec_c, rulaj_d, rulaj_c, total_d, total_c, sold_d,
sold_c, este_total`). Rezulta doua contracte care trebuie tolerate simultan, fara sa fie scris.

**Propun:** fixeaza in plan:
- `balanta_<FIRMA>.csv` - exact 12 coloane, neschimbat; `TIP` nu se adauga (nu e nevoie in
  generator; `genereaza_xlsx.py` nu citeste `tip`);
- `parteneri_<FIRMA>.csv` - `cont_saga, denumire, cod_fiscal, analitic`;
- `facturi_<FIRMA>.csv` - `cont_partener, numar, data, scadent, neachitat`;
- preconditii de potrivire nume de coloana: **exact, case-insensitive** (nu substring -
  `TOTAL_DEB` este prefix al `TOTAL_DEB_1`, iar un match partial ar lua coloana gresita).

### C5. Regresia pe FUNDATIA + MASTER trebuie rulata dupa fiecare lane care atinge generatorul, nu doar la final

**In plan** (tabelul "Ordinea de lucru"): lane `regresie` depinde de `integrare`; *"Poarta finala:
lane-ul `regresie`. Daca noul flux nu reproduce randurile celor doua xlsx-uri validate in productie,
nu e gata."*

**In neregula:** planul schimba doua lucruri in zona validata in productie: (1) `cont`/`acont` vin
din mapare in loc sa fie calculate, (2) setul de conturi cu parteneri (C1). Ambele pot muta cifre.
Daca regresia ruleaza doar la final, un bug introdus in lane-ul `mapare` se descopera dupa toate
celelalte lane-uri.

**Propun:** poarta de regresie FUNDATIA + MASTER se ruleaza dupa `mapare` si dupa `integrare`
(de doua ori), nu o singura data la final. Este cel mai ieftin test de siguranta din tot planul:
doua PDF-uri in git, doua xlsx de referinta pe disc.

### C6. Merge-ul de mapare (`MANUAL`/`NOU`/`DISPARUT` + `.TOATE`/`.RESTUL`) este cea mai mare bucata de cod pentru un utilizator unic

**In plan** (sectiunea "Pasul de mapare"): *"Merge la rulare noua, nu suprascriere: randurile
`MANUAL` raman intacte; analiticele disparute din balanta se pastreaza, marcate `DISPARUT` ...;
analiticele noi se adauga cu `NOU`."*

**In neregula:** nu e gresit, dar este cea mai complexa componenta a planului (stare persistenta,
reconciliere pe 3 tranzitii, marcaje) si se justifica doar daca Marius editeaza manual maparea
des. Planul nu spune cat de des se intampla asta. Alternativa: maparea se regenereaza complet la
fiecare rulare, iar corectiile omului traiesc intr-un fisier mic separat
(`mapare_<FIRMA>_manual.csv`, doar randurile atinse), peste care se aplica.

**Propun:** decid: (a) merge complet ca in plan (accepti complexitatea, adaugi testele celor 3
tranzitii - deja in criteriu), sau (b) overlay manual separat (mai simplu de testat, dar doua
fisiere). Nu am o preferinta puternica; depinde de cat de des editeaza Marius maparea.

### C7. Dependinte noi nedeclarate in `CLAUDE.md`

**In plan** (antet): *"Python 3.13, fara dependinte in afara de openpyxl/pdfplumber/xlrd/firebird-driver."*
`CLAUDE.md:6-7`: *"Instalate: pdfplumber, openpyxl. Fara alte dependinte."*

**In neregula:** planul introduce `xlrd` si `firebird-driver` (si `fbclient.dll` dintr-o cale fixa
de masina: `C:\Program Files\Firebird\Firebird30_Saga\fbclient.dll`, `raport_exporturi_saga_noua.md`
C.2). `CLAUDE.md` nu le mentioneaza, iar calea `fbclient` nu e portabila intre masini/clienti.

**Propun:** adauga in `CLAUDE.md` (si intr-un scurt `README`/`--help`) lista de dependinte + pasul
de instalare + faptul ca `fbclient.dll` se descopera la rulare (nu cale fixa). Verificat: pe
masina asta toate cele 4 module se importa.

### C8. `.gitignore` nu acopera copii `.FDB` si fisierele de parteneri/facturi (date de client)

**In plan** (sectiunea "Git"): enumera ignorarea pentru `init_*.xlsx`, `export_*.xlsx`,
`mapare_*.xlsx`, `balanta_*.csv`. `.gitignore` real confirma exact acestea.

**In neregula:** noile artefacte din plan - copii `.FDB`, `parteneri_*.csv`, `facturi_*.csv`,
fisiere `.xls` - nu sunt acoperite. O copie `.FDB` de client contine CUI, denumiri, IBAN, solduri.

**Propun:** adauga in `.gitignore`: `*.FDB`, `*.fdb`, `parteneri_*.csv`, `facturi_*.csv`,
`config/cont_ireg.csv` (daca se decide snapshot-ul, vezi C1 - sau, dimpotriva, comite-l intentionat
daca nu contine date de client). Nu e o urgenta, dar e o scapare concreta.

### C9. Raportul de verificare este orientat pe PDF; pentru xlsx/fdb, verificarea cu "Totaluri" dispare tacit

**In plan** (sectiunea "Cititorul 2"): *"`este_total` = gol (exportul nu are rand de totaluri)"*.

**In neregula:** `genereaza_xlsx.citeste_totaluri` cauta un rand cu "totaluri" in denumire si
intoarce `None` pe sursele xlsx/fdb (`genereaza_xlsx.py:89-94`). Verificarea "NET xlsx vs NET
Totaluri" (una din garzile din `CLAUDE.md`) nu se mai poate rula, fara ca planul sa spuna ce o
inlocuieste. Ramane doar `SUM(totdeb)=SUM(totcred)`, care e necesara dar nu suficienta.

**Propun:** pentru sursele xlsx/fdb, invariantul de inlocuire se scrie in plan si in raport:
pe fiecare rand din CSV `total_d = prec_d + rulaj_d`, `total_c = prec_c + rulaj_c`,
`sold_d - sold_c = total_d - total_c` (exact verificarile deja rulate in cercetare, 10/10 pe
exportul nou; vezi `raport_exporturi_saga_noua.md` A.1).

### C10. Planul nu evalueaza nicio alternativa si nu spune cat de des se migreaza (premisa)

**In plan:** o singura arhitectura ("Arhitectura: un format intern, trei cititoare"), 5 lane-uri.

**In neregula:** pentru un utilizator unic si 2 migrari facute pana acum, "5 lane-uri + 3 cititoare
+ mapare persistanta + parteneri/facturi din FDB" poate fi supradimensionat. Exista o varianta mult
mai mica: un singur script care citeste PDF sau xlsx (`--sursa`), fara FDB, fara mapare
persistanta, cu partenerii si cod fiscal provizoriu ca azi (etapa 5b ANAF exista deja si a
functionat). FDB-ul aduce valoare reala (cod fiscal real, scadenta, facturi per partener, dispare
etapa 5b) - dar numai dupa ce exista o baza reala de validat (C2).

**Propun:** raspunde la doua intrebari in plan: cat de des se face o migrare si cat de des vine
clientul cu baza `.FDB`. Daca migrarile sunt rare sau FDB-ul e rar, varianta minima acopera cazul
real mai repede si mai sigur.

### C11. Ordinea lane-urilor poate fi paralelizata, iar `citire-fdb` depinde de prea putin

**In plan** (tabelul "Ordinea de lucru"): `citire-xlsx` fara dependinte, `mapare` fara dependinte,
`citire-fdb` depinde de `citire-xlsx`, `integrare` depinde de toate.

**In neregula:** `citire-xlsx` si `mapare` nu depind una de alta si pot rula in paralel (planul le
pune amandoua "fara dependinte", deci e ok, dar nu o spune). `citire-fdb` depinde de `citire-xlsx`
pentru ca exportul e oracolul - corect ca tehnica, dar slab ca dovada pe date de joaca (C2).

**Propun:** numeste explicit `citire-xlsx` + `mapare` ca lane-uri paralele si muta `citire-fdb`
dupa ce exista date reale sau dupa decizia D2.

### C12. Etapa 3 contine procedura de client, fara de care cititorul FDB nu se poate folosi la client

**In plan** (sectiunea "Etapa 3"): *"procedura pentru client: cum isi face copia bazei (`gbak` ...
) si ca trebuie sa opreasca SAGA daca trimite fisierul direct"*.

**In neregula:** daca `citire-fdb` se livreaza in Etapa 2, dar procedura de obtinere a bazei ramane
in Etapa 3, unealta nu poate fi folosita la un client. Planul nu spune daca Etapa 2 FDB e "intern,
pe baza proprie" sau "folosibil la client".

**Propun:** fie muti procedura `gbak`/opreste-SAGA in Etapa 2 odata cu cititorul, fie declari
explicit ca Etapa 2 FDB este doar pe baza proprie si procedura ramane in Etapa 3.

### C13. Testul de regresie: "identice" trebuie definit pe date, nu pe octeti

**In plan** (tabelul): *"xlsx-urile noi **identice** cu cele importate deja in productie"*.

**In neregula:** `genereaza_xlsx.scrie_xlsx` re-salveaza sablonul cu `openpyxl`; metadate/formatari
pot diferi, deci "identic bit-cu-bit" e fragil ca test. Ce conteaza sunt valorile celulelor.

**Propun:** defineste poarta ca "identic pe toate celulele de date (rand >= 2), pe toate coloanele",
nu pe hash de fisier. Compara cu `openpyxl.load_workbook` valorile celula cu celula.

### C14. `conturi_cu_analitice.md` contrazice decizia finala pentru 5125

**In plan:** planul nu mentioneaza 5125.
**In neregula:** `conturi_cu_analitice.md:29,105` propune `5125 = PARTENER`; `decizii_import.md`
pct.15 (revizuit 20.09.2026) decide `5125 = doar analitice, fara parteneri`. Codul respecta pct.15
(5125 nu e in `PARTENER`, `genereaza_xlsx.py:53`). Un om care citeste docul de conturi rămâne cu
informatia veche. Planul nu spune care doc castiga.

**Propun:** o linie in plan ("pct.15 din `decizii_import.md` prevaleaza; `conturi_cu_analitice.md`
se actualizeaza") plus corectarea tabelului la urmatoarea atingere a acelui fisier.

### C15. `scadent` din FDB poate fi NULL; planul il trateaza ca "scadenta reala"

**In plan** (tabelul "Randurile FACTURA"): randul "baza `.FDB`" -> *"cu cod fiscal real si scadenta
reala"*.
**In neregula:** dovedit in `raport_exporturi_saga_noua.md` C.3, singurul rand din `INTRD` are
`SCADENT=NULL`; iar `NEACHITAT=0`. Deci "scadenta reala" si "facturi cu sold" nu sunt garantate de
baza.
**Propun:** in plan, regula pentru `SCADENT` NULL (fallback pe ultima zi a lunii, ca la exporturi)
si pentru selectia facturilor (ex. `NEACHITAT <> 0`), plus raportarea cazurilor.

### C16. Harta erorilor nu numeste ce vede utilizatorul la esec de citire

**In plan** (sectiunea "Ce se pastreaza neatins"): 3 conditii de oprire ("analitic fara rand in
mapare", "cont/acont > 4", "doua randuri cu acelasi (cont,acont)"). Bun, dar sunt doar in generator.
**In neregula:** nu exista erori numite pentru cititoare: fisier lipsa, foaie inexistenta/redenumita,
antet fara coloana asteptata, `cont` citit ca numar, FDB blocat/versiune greșita/`fbclient`
negasit. `raport_form_init_balanta.md` arata ca formularul insusi e lax (rand fara `an` = ignorat
tacut), deci un CSV gresit poate produce un xlsx "valid" dar incomplet.
**Propun:** tabel de erori in plan (codepath | ce poate merge prost | clasa/exceptie | ce vede
Marius). Minim: fiecare cititor valideaza antetul prin nume exacte si se opreste cu mesaj care
spune fisierul, foaia si coloana lipsa.

---

## 3. DECIZII DE LUAT DE MARIUS

### D1. Cat de mare e etapa 2: planul complet (5 lane-uri, 3 cititoare) sau o felie minima intai?
- A) **Felia minima intai**: un script cu `--sursa pdf|xlsx`, fara FDB si fara mapare persistanta
  (cod fiscal provizoriu + etapa 5b ca azi); FDB cand apare un client cu baza. (uman: ~1 zi / CC: ~1h)
- B) **Planul complet ca acum** (5 lane-uri, inclusiv FDB + parteneri/facturi).
- C) **Planul complet, dar FDB ultimul si conditionat** de o baza reala (hibrid cu D2).
- **Recomandare: C** - pastrezi valoarea FDB, dar nu blochezi livrarea pe cea mai putin verificata
  bucata. Rezultatul il simti imediat pe PDF/xlsx, iar FDB se adauga cand ai dovada. (Daca
  migrarile sunt rare si clientii nu dau baza, A devine alegerea corecta.)

### D2. Cititorul FDB: il construim acum sau dupa o baza reala?
- A) Mutam obtinerea unei baze `.FDB` reale + exportul ei in Etapa 2, ca preconditie. (recomandat)
- B) Il construim acum pe firma de joaca si acceptam ca "verificat, nu pe analitice".
- C) Il scoatem din etapa 2 complet (revine in etapa 3).
- **Recomandare: A** - poarta FDB-vs-xlsx pe 10 randuri sintetice nu poate inchide un lane care
  promite analitice, parteneri, cod fiscal si scadenta reala.

### D3. Sursa setului de conturi cu parteneri (C1)
- A) Snapshot local `config/cont_ireg.csv` generat de SQL, citit de unealta. (recomandat)
- B) Pastram setul hardcodat din `genereaza_xlsx.py` si scoatem afirmatia "Oracle e sursa de adevar".
- C) Citire live Oracle la rulare.
- **Recomandare: A** - o singura sursa, fara credentiale si fara client Oracle la rulare, si se
  vede in git cand se schimba. Important: decide daca snapshot-ul include toate cele 33 de conturi
  `CU_INREGISTRARI=1` sau doar setul validat - altfel rezultatul pe FUNDATIA/MASTER se poate schimba.

### D4. Contractul intermediar (C4)
- A) Il fixezi in plan acum: 3 fisiere, nume si coloane exacte, fara `TIP`, match exact de antet.
  (recomandat)
- B) Lasi cititoarele sa produca ce vor si adaptezi generatorul.
- **Recomandare: A** - e cel mai ieftin lucru de scris din tot planul si elimina cea mai frecventa
  sursa de buguri tacite (potrivire de coloane).

### D5. Merge-ul de mapare (C6)
- A) Merge complet (`MANUAL`/`NOU`/`DISPARUT` + `.TOATE`/`.RESTUL`) ca in plan.
- B) Overlay manual separat peste o mapare regenerata complet. (mai simplu de testat)
- **Recomandare: B** daca Marius editeaza maparea rar; A daca o editeaza des. Neutral - decizia
  tine de cat de des corecteaza manual.

### D6. Poarta de regresie (C5, C13)
- A) Rulezi regresia FUNDATIA + MASTER dupa `mapare` si dupa `integrare`, comparand valori de
  celule (nu hash de fisier). (recomandat)
- B) Ramane o singura rulare la final, pe hash de fisier.
- **Recomandare: A** - cel mai ieftin test de siguranta, si protejeaza exact zona validata in
  productie pe care planul o atinge.

### D7. Procedura de client pentru baza FDB (C12)
- A) O muti in Etapa 2 odata cu cititorul FDB. (recomandat daca D2 = A/B)
- B) Ramane in Etapa 3; declari Etapa 2 FDB "intern, nefolosibil la client".
- **Recomandare: A** - altfel livrezi un cititor pe care nu-l poti folosi in teren.

### D8. Cine e "adevarul" pe 5125 si pe docurile contradictorii (C14)
- A) `decizii_import.md` pct.15 prevaleaza; actualizezi `conturi_cu_analitice.md`. (recomandat)
- B) Lasat asa, se rezolva la urmatoarea atingere.
- **Recomandare: A** - o linie in plan si o corectie mica elimina o capcana pentru viitor.

---

## 4. Ce am verificat si ce NU am putut verifica

**Verificat (cu dovada):**
- Structura celor doua exporturi SAGA (VFP si Firebird) identica pe 35 de coloane si maparea
  1:1 pe cele 8 sume - `raport_sursa_saga_xlsx.md` 1.5/1.6 si `raport_exporturi_saga_noua.md`
  A.1/B.2 (relatii de sume 341/341 si 10/10).
- `CONTURI` cu solduri 0, cifrele din agregarea `REGISTRU` - `raport_exporturi_saga_noua.md` C.4.
- Firma de joaca: FDB exista (`D:\SAGA250909\0001\CONT_BAZA.FDB`, 21 MB), exporturi in `exemple\`,
  0 analitice, 2 furnizori, 0 clienti, 1 factura - planul si raportul C.3 confirma.
- Setul hardcodat de parteneri din cod vs lista Oracle `CU_INREGISTRARI=1` (33 conturi) - C1:
  `genereaza_xlsx.py:43-53` vs `config_cont_ireg.md:89-91`.
- `5125`: codul respecta `decizii_import.md` pct.15, docul `conturi_cu_analitice.md` nu - C14.
- `.gitignore` real nu acopera `.FDB`/`parteneri_*.csv`/`facturi_*.csv` - C8.
- Dependintele pe masina asta: `pdfplumber`, `openpyxl`, `xlrd`, `firebird.driver` se importa toate.
- `genereaza_xlsx.py` citeste `totaluri` din CSV, deci pe sursele xlsx/fdb verificarea scade - C9.
- `extract_balanta.py` scrie 12 coloane, deci `TIP` ca a 13-a coloana ar rupe contractul - C4.

**NU am putut verifica (afirmatii neacoperite de un fisier citit):**
- Cat de des se face o migrare si cat de des vine clientul cu baza `.FDB` (premisa pentru D1).
  Nu exista niciun document cu volumul de migrari.
- Daca `REGISTRU` permite reconstruirea exacta a `DEB_PREC`/`RULAJ`/`FIN` pe analitice pe o baza
  reala - nu exista decat firma de joaca (8 note). C3 ramane o cerinta, nu o dovada.
- Daca vreun client are baza `.FDB` pe o versiune Firebird diferita (aici 3.0.7, `fbclient` dintr-o
  cale fixa) - nerezolvat, risc de deploy nenumit in plan.
- Ordinea exacta de prioritate dintre `conturi_cu_analitice.md` (PARTENER pe 5125) si
  `decizii_import.md` pct.15 (analitic) din partea lui Marius - am presupus ca pct.15, mai nou si
  revizuit, este cel corect.
- Outside voice (Codex / subagent) NU a fost rulat: skill-ul il cere implicit, dar acest task este
  o analiza fara aprobare interactiva, iar rezultatul ar fi informational. De reluat manual daca
  Marius vrea a doua voce.

**Anexa A - diagrama de arhitectura (cum e acum in plan; `[?]` = nespecificat)**

```
  SURSE                 CITITOARE                 CONTRACT                    GENERATOR            IESIRE
  PDF balanta  ------>  citire-pdf (exista)   ->  balanta_<F>.csv  (12 col) --> genereaza -------> init_<F>_<a>_<l>.xlsx
  xlsx/xls SAGA ----->  citire-xlsx (NOU)     ->  balanta_<F>.csv
  CONT_BAZA.FDB ----->  citire-fdb (NOU)      ->  parteneri_<F>.csv  [nume/coloane ?]         + mapare_<F>.xlsx
                                                facturi_<F>.csv    [nume/coloane ?]         + docs/verificare_<F>.md
```

**Anexa B - registru de erori propus (S2)**

| Codepath | Ce poate merge prost | Tratament propus (acum lipseste) |
|---|---|---|
| citire-pdf | PDF fara text (scanat) | Stop, mesaj "PDF fara strat de text" |
| citire-xlsx | fisier lipsa / foaie redenumita / antet schimbat | Stop cu numele foii si coloanei asteptate |
| citire-xlsx | `cont` citit ca numar (`401.00002`) | citire ca text, verificat deja in cercetare |
| citire-fdb | `fbclient.dll` negasit / versiune Firebird diferita | Stop cu calea cautata si versiunea |
| citire-fdb | `CONTURI` cu solduri 0 (folosire gresita) | agregare `REGISTRU`, cu invariant de sume; de numit explicit |
| generator | analitic fara rand in mapare | deja in plan: Stop |
| generator | `(cont,acont)` duplicat | deja in plan: Stop |
| generator | rand fara `an` (formular il ignora tacit) | validare proprie, nu te baza pe formular |

**Anexa C - registru de failure modes (S4)**

| Codepath | Failure mode | Prins? | Test? | Marius vede? | Logat? |
|---|---|---|---|---|---|
| citire-fdb | CSV "corect" dar fara analitice (agregare sintetic) | N (C2) | N (date de joaca) | **Silent** | raport |
| citire-fdb | `SCADENT` NULL tratat ca data valida | N (C15) | N | partial | nu |
| citire-xlsx | antet cu coloana lipsa -> 0 pe toate | N (C16) | partial | posibil Silent | nu |
| generator | `Totaluri` absent -> verificare sarita | partial (C9) | da | notat in raport | da |
| deploy | `fbclient` lipsa la client | N (C7) | N | Stop (daca mesaj clar) | nu |

Rândurile `RESCUED=N, TEST=N, USER SEES=Silent` sunt golurile critice: primul si al treilea.

**Anexa D - "ce exista deja"**

- `extract_balanta.py` = cititorul PDF (reused, nemodificat; corect).
- `genereaza_xlsx.py` = toti pasii de mapare si constructie a randurilor BALANTA/FACTURA, cu
  verificarile din etapa 5 (reused; planul il extinde corect cu maparea si `exclus`).
- `decizii_import.md` pct.11-16 = regulile validate in productie (nu se redeschid; corect).
- Sablonul `init_facturi_balanta_note.xlsx` (rand 1 = cap de tabel, import incepe de la rand 2).

**Anexa E - "NOT in scope" (confirmat de plan, cu o exceptie)**

- importul registrului jurnal, balantele de verificare lunare, nomenclatorul de parteneri lunar
  (programele `saga2roa*` vechi) - corect in afara scopului;
- planul de conturi syntetic generat de SAGA (`PLANCONT`) - corect nepreluat;
- conectarea Firebird prin retea - corect amanata.
- **Exceptie de re-verificat:** "procedura de client pentru copia bazei" este scoasa in Etapa 3,
  dar daca FDB se livreaza in Etapa 2 (D2/D7), ea este in scop.