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.