solduri2roa/docs/review_eng_etapa2.md

Review eng - plan etapa 2 (docs/plan_etapa2_convertor.md, PROPUNERE v2)

Lane: review-eng. Analiza statica, read-only. Nu am modificat planul, nu am scris cod, nu am dat commit. Am aplicat skill-ul plan-eng-review (SKILL.md + sections/review-sections.md) ca analiza: unde skill-ul cere AskUserQuestion, am scris DECIZII DE LUAT (sectiunea 3). Sursa de adevar pentru fiecare afirmatie de mai jos este un fisier citit; unde am presupus, scrie explicit "presupunere".

Fisiere citite: planul; raport_sursa_saga_xlsx.md; raport_exporturi_saga_noua.md; decizii_import.md; plan_solduri2roa.md; config_cont_ireg.md; raport_form_init_balanta.md; conturi_cu_analitice.md; extract_balanta.py; genereaza_xlsx.py; .gitignore; CLAUDE.md; git status/log.

---

0. Step 0 - Scope challenge (rezultat)

• Ce exista deja si e refolosit corect: extract_balanta.py (PDF, nemodificat - bine), genereaza_xlsx.py (constructia BALANTA/FACTURA, ramane), sablonul init_facturi_balanta_note.xlsx, conventiile .TOATE/.RESTUL din conturi_roa.dbf (raport_sursa_saga_xlsx.md 2.1-2.3), regulile validate decizii_import.md. Planul nu reconstruieste ce exista - punct bun.
• Minimum set: planul e rezonabil de minimal (3 cititoare + mapare + integrare + regresie). Nu am gasit scope creep mare. Etapa 3 (baza reala, gbak, Firebird pe retea) e corect lasata afara (plan_etapa2_convertor.md:172-180).
• Complexity check (skill: 8+ fisiere / 2+ clase noi = smell): planul atinge ~6-8 module noi (citire_xlsx, citire_fdb, mapare, extrage, genereaza, test) - la limita, nu peste. Nu declanshez reducere de scope pe acest motiv.
• Completeness check: planul propune varianta completa pe hartie (poarta de identitate CSV, regresie pe productie) - dar doua dintre porti nu sunt executabile cu artefactele actuale (vezi C2, C3). Deci "complet" e declarat, nu livrabil.
• Distribution check: unealta interna, rulata de Marius pe masina lui. Nu necesita pipeline de publicare. Corect lasat afara.

---

1. Scoruri pe dimensiunile skill-ului

Dimensiune (din skill)	Nota	Ce ar aduce-o la maxim
Scope challenge	8/10	Sa declare explicit ce se pierde cand "un singur CSV" nu e suficient (parteneri, totaluri, rollup) - vezi C5, C11
Architecture / data flow	5/10	Contract intern real (balanta + parteneri + facturi), nu un singur CSV; regula de rollup FDB specificata (C2, C11)
Code quality / DRY	6/10	Clarifica cine detine cont/acont (mapare vs genereaza), evita re-encodarea pct. 16 in doua locuri (C4, C9)
Test coverage	4/10	Golden fixtures comise in git + framework de test; altfel poarta de regresie si poarta FDB nu ruleaza (C3, C5, sec. 2.5)
Performance	7/10	Agregare in SQL (GROUP BY pe 3 intervale de data), nu SELECT * in Python; charset WIN1250 (C15)
Failure modes / esecuri tacute	5/10	Trateaza explicit: verificarea Totaluri care dispare tacut, SCADENT NULL, cod fiscal gol (C5, C6)
Diagrame	8/10	Diagrama de pipeline exista (:35-39); lipseste diagrama de forma a datelor per cititor (ce coloane intra/ies)
Outside voice (cross-model)	n/a	Nu am putut rula Codex/subagent in acest lane; nu e o nota, e o limita de mediu

Verdict de ansamblu: plan bun ca intentie, cu 3 gauri de executie care il opresc sa fie "gata" (poarta FDB fara regula, poarta de regresie fara fixture, sursa partenerilor care contrazice productia).

---

2. Constatari

Format: [Px] (confidence N/10) ce e in plan / ce e in neregula / ce propun.

C1 [P1] (confidence 9/10) - CONFIG_CONT_IREG nu reproduce setul de parteneri validat

• In plan: :119-122 - "Ce NU se configureaza aici: care conturi merg pe parteneri. Ramane CONFIG_CONT_IREG din Oracle ... e sursa de adevar a ROACONT".
• In neregula: codul validat in productie foloseste alt set. genereaza_xlsx.py:47-53: PARTENER_BANCA={5121,5124}, PARTENER_SINTETIC={401,4092,4111,461,462,4551}, PARTENER_FARA_ANALITICE={5311}. In config_cont_ireg.md:89-91 (CU_INREGISTRARI=1) nu apar 5121, 5124, 5311, iar in lista Oracle apar 404,408,4091-4094,418,419 etc. pe care genereaza NU le trateaza ca parteneri. Deci: daca unealta decide partenerii doar din Oracle, 5121/5124/5311 (decisiuni validate, decizii_import.md pct. 14-15) devin conturi obisnuite -> regresie tacuta pe MASTER (5121.01 PIRAEUS).
• Propun: sursa de adevar operationala = o lista in repo, derivata din setul validat + reconciliata explicit cu CONFIG_CONT_IREG; Oracle ramane consultativ. Documenteaza divergenta (Oracle listeaza trezoreriile ca CU_INREGISTRARI=0, dar decizii_import.md:52-55 arata ca formularul are liste hardcodate separate :1104/:1107).

C2 [P1] (confidence 9/10) - agregarea REGISTRU pentru balanta e sub-specificata; poarta de identitate nu e demonstrabila

• In plan: :62-64 - "balanta: agregare pe REGISTRU la data ceruta" si :75 - "cititorul 3 (FDB) si cititorul 2 (xlsx) trebuie sa produca acelasi CSV".
• In neregula: (a) balanta exportului are 4 marimi, nu una: DEB_INIT/CRED_INIT (inceput de an), DEB_PREC/CRED_PREC (inceput de perioada), RULAJ_* (perioada), FIN_* (sold) - deci sunt necesare doua praguri de data, nu unul (raport_exporturi_saga_noua.md C.4:288-297 o arata pe cazul 641 din 2025-11-30 -> DEB_INIT). (b) exportul ruleaza analiticul in sintetic: REGISTRU are 401.00002, exportul are 401 (C.4:294,298-301), iar C.5:303-304 spune explicit ca "regula exacta de includere sintetic/analitic nu se poate stabili". Fara regula de rollup, agregarea din CONT_D/CONT_C produce 401.00002, iar CSV-ul nu e identic - testul pica din cauza regulii lipsa, nu a unui bug de cititor.
• Propun: specifica algoritmul in plan (nu in cod): grupare pe sintetic (stanga punctului), 3 intervale de data (an, perioada, in perioada) + FIN=PREC+RULAJ; declara explicit ca testul pe firma de joaca dovedeste doar cazul sintetic (:80-82). Adauga in plan un al doilea prag (an).

C3 [P1] (confidence 9/10) - poarta regresie nu are fixture comis in git

• In plan: :167 - "xlsx-urile noi identice cu cele importate deja in productie"; :154-156 - .gitignore ignora init_*.xlsx si "fisierele de productie au fost scoase cu git rm --cached".
• In neregula: git status arata D init_FUNDATIA_2025_12.xlsx, D init_MASTER_2025_12.xlsx, iar .gitignore:6 ignora init_*.xlsx. Criteriul de terminare al lane-ului de regresie compara cu fisiere care nu sunt in repo -> pe alt checkout/masina poarta nu se poate rula, iar rezultatul nu e reproductibil nici de autor peste o luna.
• Propun: comite o copie golden sub tests/golden/ (exceptie in .gitignore), sau un manifest de hash-uri + regulile de numarare; atunci "identice" devine verificabil automat. PDF-urile sunt deja in git (bine), dar output-ul-tinta lipseste.

C4 [P1] (confidence 8/10) - "genereaza ia cont/acont din mapare" se bate cap in cap cu logica pastrata in cod

• In plan: :143-146 - "singura schimbare de fond este ca ia cont/acont din mapare in loc sa le calculeze"; :103-104 - pre-completarea e generica ("primele max 4 caractere" + "cifrele analiticului concatenate, max 4").
• In neregula: (a) randurile de diferenta NU exista in balanta, deci nu pot veni din mapare; sunt calculate (genereaza_xlsx.py:204-212,243-249) - planul nu spune cine le mai emite. (b) forma acont depinde de categorie: 401 -> acont gol, 5121 -> acont completat identic pe BALANTA si FACTURA (decizii_import.md pct. 16; genereaza_xlsx.py:219-249,252-283). Regula generica de pre-completare ar pune acont pe 401 -> chei diferite -> dublare tacuta (pct. 16).
• Propun: decide cine detine acont: ori pre-completarea din mapare e constienta de categorie (partener -> pct. 16, analitic -> regula generica), ori genereaza ramane singurul care decide forma pentru parteneri, iar maparea doar suprascrie. A doua e mai putin riscanta (codul deja validat).

C5 [P2] (confidence 8/10) - verificarea "Totaluri" dispare tacut pe drumurile xlsx/FDB

• In plan: :54 - este_total = gol pe exportul de foaie de calcul; :56 - xls/xlsx nu au rand de totaluri.
• In neregula: genereaza_xlsx.py:89-94 cauta randul "Totaluri" si :330,381-390 face cross-check-ul net xlsx vs net Totaluri doar daca il gaseste. Pe drumurile noi citeste_totaluri intoarce None, deci cea mai puternica verificare cap-la-cap se omite silentios - exact tiparul de esec tacut pe care planul il interzice in alta parte.
• Propun: inlocuieste verificarea pierduta cu una echivalenta: pe FDB, SUM(REGISTRU) pe latura la data ceruta = netul balantei (cifra de control reala); pe xlsx, re-calculeaza netul din coloanele citite. Daca nu exista echivalent, scrie explicit in verificare_<firma>.md "verificare indisponibila", nu o sari.

C6 [P2] (confidence 8/10) - "cod fiscal real" si "scadenta reala" nu sunt garantate de baza

• In plan: :65-66 - "Codul fiscal real vine de aici" si :134 - FDB da "cod fiscal real si scadenta reala ... nimic lipseste".
• In neregula: in baza de joaca, FURNIZORI are ***('00001','ROMFAST','','401.00001')*** - cod fiscal gol (raport_exporturi_saga_noua.md C.3:264), iar singurul INTRD are SCADENT=NULL (C.3:274). Deci "real" poate insemna gol/NULL pe date reale.
• Propun: pastreaza fallback-urile de azi (cod provizoriu <cont>.<analitic>, scadenta = ultima zi a lunii) ca default cand FDB da NULL/gol, si raporteaza cate randuri au cazut pe fallback.

C7 [P2] (confidence 7/10) - semantica MANUAL in merge e nedeclarata

• In plan: :100 stare e "nu" (need editabila); :114-117 - "randurile MANUAL raman intacte".
• In neregula: nu se spune cine si cum face trecerea AUTO -> MANUAL. Daca utilizatorul editeaza cont/acont, cine observa? Cum se distinge o editare de o re-preluare a aceleiasi valori? La a doua rulare, daca regula auto ar produce exact valoarea editata, randul ramane AUTO si poate fi suprascris mai tarziu. De asemenea: un MANUAL care devine DISPARUT si reapare - ce stare are?
• Propun: defineste regula (ex.: orice modificare a cont/acont/exclus fata de valoarea pre-completata marcheaza MANUAL; stare devine READONLY), si trateaza revenirea DISPARUT -> MANUAL.

C8 [P2] (confidence 8/10) - regula de coliziune se bate cu .TOATE/.RESTUL

• In plan: :148-150 - opreste cu eroare daca "doua randuri produc acelasi (cont, acont) fara sa fie acelasi cont SAGA"; :106-109 - <sintetic>.TOATE = toate analiticele merg pe acelasi (cont, acont) ROA.
• In neregula: .TOATE/.RESTUL sunt agregare intentionata a mai multor conturi SAGA pe aceeasi cheie ROA, exact ce regula de mai sus declara eroare. Asa cum e scris, tool-ul se opreste pe cazul suportat. In plus, pentru conturile-partener acont e irelevant (pct. 16) - nu trebuie sa intre in verificarea de coliziune.
• Propun: scuteste agregarea intentionata (acelasi cont_saga de baza sub .TOATE/.RESTUL) si exclude partenerii din verificarea de coliziune; raporteaza doar coliziunile neintentionate.

C9 [P2] (confidence 7/10) - redenumirea sinteticului (409 -> 4091) nu vine din noul mapare

• In plan: :106-112 preia doar .TOATE/.RESTUL din conturi_roa.dbf; pre-completarea :103-104 copiaza sinteticul SAGA.
• In neregula: raport_sursa_saga_xlsx.md 2.1/2.3 arata ca conturi_roa.dbf face si redenumire de sintetic (409 -> 4091, 431 -> 4311, 4374 -> 4371). Regula de pre-completare nu o produce, deci o firma cu 409 iese cu cont=409 in loc de 4091. Ramane corectabila manual, dar planul pretinde reutilizare.
• Propun: semeneaza maparea din conturi_roa.dbf cand exista (CONT2/ACONT2), sau adauga tabela de redenumire explicita.

C10 [P2] (confidence 8/10) - selectia foii nu e specificata si difera intre surse

• In plan: :48-56 (cititorul 2) nu spune cum alege foaia; raport_sursa_saga_xlsx.md spune ca foaia VFP se numeste balanta, iar raport_exporturi_saga_noua.md A.2:110 spune xl (xls) vs Sheet1 (xlsx).
• In neregula: un cititor care cauta fix Sheet1 pica pe exportul VFP; unul care ia active pica pe fisiere cu foi ascunse.
• Propun: alege prima foaie, sau cauta dupa nume in lista cunoscuta, cu eroare clara daca nu exista.

C11 [P2] (confidence 7/10) - "un singur CSV intern" nu e suficient pentru nivelul 3-4 de FACTURA

• In plan: :41-42 - "Restul lantului nu stie din ce sursa vine"; dar :136 parametri --furnizori/--clienti/--facturi/--fdb intra in generator, nu in cititor.
• In neregula: numele partenerului, codul fiscal real si detaliul de factura nu stau in CSV-ul de balanta; sunt intrari separate. Diagrama :35-39 sugereaza un singur flux, iar contractul real are 3 intrari. Nu e fatal, dar planul se contrazice si ascunde o dependenta.
• Propun: scrie contractul real: balanta_<FIRMA>.csv + optional parteneri_<FIRMA>.csv + optional facturi_<FIRMA>.csv; genereaza accepta cele doua optionale si degradeaza la nivelul corespunzator (:124-134).

C12 [P3] (confidence 7/10) - coloana TIP (a 13-a) nu are consumator

• In plan: :55 - "Coloana TIP (A/P) se duce in CSV ca a 13-a coloana, optionala".
• In neregula: genereaza_xlsx.py nu citeste niciodata TIP; natura D/C vine din latura hardcodata (:43) si din net. Deci coloana e greutate moarta sau scop nedeclarat.
• Propun: fie o lasi afara, fie ii dai un consumator concret (ex. validare latura/cont de partener).

C13 [P3] (confidence 6/10) - facturile de clienti din FDB sunt speculativ specificate

• In plan: :67-68 - IESIRI/IES_DET -> facturi clienti.
• In neregula: raport_exporturi_saga_noua.md C.3:280 da IESIRI (0 randuri) si IES_DET cu structura "-" (necunoscuta); firma are 0 clienti. Deci SQL-ul de facturi clienti e presupunere.
• Propun: marcheaza partea de clienti ca neverificata si nu o promite ca livrabil pana nu ai o baza reala (Etapa 3, :175).

C14 [P3] (confidence 6/10) - Oracle (retea + credentiale) intr-un flux de fisiere offline

• In plan: :119-122 - partenerii vin din CONFIG_CONT_IREG (Oracle local).
• In neregula: aduce o dependenta de DSN/VPN/tnsnames si de parola din D:\ROA\ROACONT\docs\oracle_parola_standard.secret (config_cont_ireg.md:7,17) intr-o unealta care altfel lucreaza doar pe fisiere. Esti pe acelasi LAN (10.0.20.121), deci e fezabil, dar adauga moduri de esec (DNS, cont SQL*Plus, parola expirata) pentru un pas care se schimba rar.
• Propun: instantaneu versionat (config/cont_ireg.csv) regenerat de un script mic cand Oracle se schimba; unealta citeste instantaneul offline. Vezi si C1.

C15 [P3] (confidence 6/10) - performanta FDB si charset

• In plan: :58-64 nu spune cum se agrega.
• In neregula: la clienti cu REGISTRU mare, SELECT * + agregare in Python e lent si consuma memorie; iar CONT_D/CONT_C si denumirile au diacritice/CP1250.
• Propun: agregare in SQL (GROUP BY cont, CASE pe intervale de data), charset=WIN1250 (raport_exporturi_saga_noua.md C.2:230 foloseste deja WIN1250).

C16 [P3] (confidence 5/10) - potrivirea numelor de coloane trebuie exacta, nu substring

• In plan: :51-53 compara antetul case-insensitive.
• In neregula: exportul are si DEB_PREC si DEB_PREC_1 (setul _1, raport_sursa_saga_xlsx.md 1.1). O potrivire prin in/startswith poate alege coloana gresita tacut.
• Propun: normalizeaza si compara egalitate exacta dupa nume; ignora explicit coloanele _1.

---

2.5 Test review (per lane - ce test automat lasa fiecare)

Azi nu exista niciun test (tests/ lipseste; pytest neinstalat, verificat). Skill-ul cere 100% acoperire; propun concret pentru fiecare lane:

Lane	Test lasat in urma	Observatie
citire-xlsx	tests/test_citire_xlsx.py: CSV produs din exemple/saga-sqlite-balanta-09-2026.xlsx == CSV golden comis; + relatiile total=prec+rulaj, sold=total pe toate randurile	Fixture e deja in git (exemple/)
mapare	tests/test_mapare.py pe functia de merge: MANUAL supravietuieste, analitic nou -> NOU, disparut -> DISPARUT, coliziune neintentionata -> Stop, .TOATE NU e coliziune	Pur logic, fara dependinte
citire-fdb	tests/test_citire_fdb.py: CSV produs din D:\SAGA250909\0001\CONT_BAZA.FDB == CSV golden comis (inghetat o data). Live, doar daca baza exista (skip motivat)	Baza nu e in repo -> testul depinde de mediu; de aceea ingheata CSV-ul
integrare	rulare cap-la-cap pe firma de joaca, comparatie cu xlsx golden	Necesita C3
regresie	tests/test_regresie.py: init_FUNDATIA_2025_12.xlsx si init_MASTER_2025_12.xlsx regenerate == golden comis	Necesita C3 (altfel nu ruleaza)

Problema transversala: fara fixture comis (C3), 2 din 5 lane-uri nu pot demonstra criteriul de terminare. Recomand unittest din stdlib ca sa nu adaugi dependinte (CLAUDE.md: doar pdfplumber, openpyxl, xlrd, firebird-driver), sau pytest acceptat explicit ca dependinta dev-only.

Acoperire estimata azi: 0%. Dupa cele 5 testuri de mai sus, portile reale ale planului devin automate. Cazurile pe care planul insusi le declara neacoperite (:80-83: 0 analitice, 2 furnizori, 0 clienti, 1 factura) raman neacoperite pana la o baza reala (Etapa 3) - corect de raportat, nu de ascuns.

---

2.6 Failure modes (esec + test + eroare vizibila?) - cele fara test SI fara mesaj = critical gap

Failure mode	Test?	Eroare clara?	Verdict
Rollup FDB analitic->sintetic gresit (C2)	Nu (poarta nu are regula)	Nu, iese un CSV diferit	CRITICAL GAP
Verificarea Totaluri dispare tacut (C5)	Nu	Nu	CRITICAL GAP
Regresie fara golden -> cineva crede ca a trecut (C3)	Nu	Nu	CRITICAL GAP
Editare MANUAL suprascrisa la a 2-a rulare (C7)	Nu	Nu	CRITICAL GAP
Coliziune .TOATE oprita ca eroare / coliziune reala ratata (C8)	Nu	Da (Stop) / Nu	Risc mediu
fbclient.dll lipsa / cale gresita	Nu	Da (exceptie driver)	Risc mic
Foaie gresita aleasa (C10)	Nu	Depinde	Risc mediu
Cod fiscal gol / SCADENT NULL din FDB (C6)	Nu	Nu (valoare proasta)	Risc mediu
Facturi clienti FDB pe structura necunoscuta (C13)	Nu	Nu	Risc mediu, amanat

---

2.7 Required outputs (cerute de skill)

NOT in scope (plan :16-17, :172-180): import registru jurnal; balante lunare; nomenclator parteneri lunar; baza .FDB reala; procedura gbak pentru client; Firebird prin retea. Corect delimitat. De adaugat explicit: pipeline de distributie (nu exista, unealta interna) si testarea pe analitice reale (amanata la Etapa 3).

What already exists (reutilizat): extract_balanta.py (nemodificat), genereaza_xlsx.py (constructie + verificari), sablonul, decizii_import.md, conturi_roa.dbf (conventii), baza de joaca

• exporturile din exemple/. Planul reutilizeaza bine; singurul lucru reconstruit inutil ar fi TIP (C12) si, potential, setul de parteneri (C1).

Diagrams: exista diagrama de pipeline (:35-39). Lipseste o diagrama de forma a datelor: pentru fiecare cititor, ce coloane intra si ce iese in CSV (utila exact pentru C5/C10/C11/C16).

Worktree parallelization:

Step	Module	Depinde de
citire-xlsx	citire_xlsx	-
mapare	mapare	-
citire-fdb	citire_fdb	citire-xlsx (contract CSV comun)
integrare	extrage, genereaza	toate
regresie	tests, golden	integrare

Lane A: citire-xlsx -> citire-fdb (secvential, contract comun). Lane B: mapare (independent). Apoi integrare, apoi regresie. Fara conflict de module intre A si B. Planul are deja dependenta citire-fdb -> citire-xlsx (:165), corect.

Implementation Tasks (sinteza):

• T1 (P1) - scrie regula de agregare/rollup FDB in plan (C2).
• T2 (P1) - comite golden fixtures pentru regresie (C3).
• T3 (P1) - reconciliaza setul de parteneri cu productia (C1).
• T4 (P1) - decide proprietarul cont/acont si trata diferentele (C4).
• T5 (P2) - inlocuieste verificarea Totaluri pe drumurile noi (C5).
• T6 (P2) - specifica merge-ul MANUAL/coliziuni/.TOATE (C7, C8).
• T7 (P2) - selectie foaie + fallback cod fiscal/scadenta (C6, C10).

---

3. DECIZII DE LUAT DE MARIUS

D1 - Sursa setului de conturi cu parteneri

• A) Interogare Oracle CONFIG_CONT_IREG la fiecare rulare (retea + credentiale).
• B) Instantaneu versionat in repo (config/cont_ireg.csv), regenerat de un script mic; setul operational (5121/5124/5311 etc.) adaugat explicit langa el. (recomandat)
• C) Hardcodeaza setul validat in genereaza_xlsx.py.
• Recomandare: B - offline pentru flux, dar totusi auditat si actualizabil; A aduce esecuri de retea intr-un pas care se schimba rar; C e exact "lista hardcodata in .prg" pe care planul (:121) vrea sa o evite. Motiv: explicitudine + portabilitate.

D2 - Regula de agregare FDB (ca sa treaca poarta de identitate)

• A) Rollup la sintetic (stanga punctului) + 3 intervale de data; test pe firma de joaca dovedeste doar sinteticul. (recomandat)
• B) Pastreaza analiticul ca atare si cere exportul SAGA tot la nivel analitic.
• C) Amaneaza FDB pana ai o baza reala cu analitice.
• Recomandare: A - e singurul mod in care poarta :75 poate pica/trece pe datele existente; C amana tot lane-ul, B muta problema la client.

D3 - Fixture pentru poarta de regresie

• A) Comite copiile init_FUNDATIA_2025_12.xlsx / init_MASTER_2025_12.xlsx sub tests/golden/ (exceptie in .gitignore). (recomandat)
• B) Manifest de hash-uri + un CSV golden al continutului.
• C) Renunta la poarta de regresie.
• Recomandare: A - e poarta finala a planului (:167-170); fara fixture nu exista; continutul e date de test validate in productie, nu secrete.

D4 - Cine detine cont/acont si randurile de diferenta

• A) Maparea pre-completeaza constient de categorie (partener pct. 16 vs analitic), genereaza doar citeste. (planul de azi)
• B) genereaza ramane singurul care decide forma pentru parteneri; maparea doar suprascrie; randurile de diferenta raman calculate in cod. (recomandat)
• C) Reescrie genereaza complet pe mapare, inclusiv diferentele (rescriere mai mare).
• Recomandare: B - codul de parteneri e deja validat in productie (decizii_import.md pct. 16, genereaza_xlsx.py:219-303); re-encodarea lui in generatorul de mapare dubleaza regula (DRY) si risca regresia pe MASTER.

D5 - Verificarea echivalenta "Totaluri" pe drumurile xlsx/FDB

• A) Adauga un check real: SUM(REGISTRU) pe latura la data ceruta = netul balantei generate. (recomandat)
• B) Doar avertizare explicita in raport ca verificarea nu e disponibila.
• C) Ignora.
• Recomandare: A - planul declara ca nu ajusteaza cifre ca sa treaca verificari (CLAUDE.md); verificarea trebuie inlocuita cu una reala, nu doar scoasa.

D6 - Framework de test

• A) unittest stdlib (fara dependinte noi). (recomandat)
• B) pytest (dependinta dev-only).
• C) Scripturi shell/py ad-hoc, fara framework.
• Recomandare: A - respecta "fara alte dependinte"; C nu da raportare de totaluri/esecuri.

---

4. Ce am verificat si ce NU am putut verifica

Verificat (dovada in fisier):

• genereaza_xlsx.py citeste din CSV doar cont/denumire/total_d/total_c/este_total; nu citeste sold_*, nu citeste TIP, iar cross-check-ul Totaluri depinde de un rand care exista doar in PDF (:65-94,196-304,321-390).
• extract_balanta.py scrie 12 coloane; pagina/este_total sunt coloanele care nu au echivalent in export (:232-237, plan :54).
• Setul de parteneri din cod (5121/5124/5311) contrazice CU_INREGISTRARI din Oracle (genereaza_xlsx.py:47-53 vs config_cont_ireg.md:89-91).
• Baza de joaca: 0 analitice in export, FURNIZORI.COD_FISCAL gol pentru ROMFAST, INTRD.SCADENT=NULL, regulile de rollup analitic->sintetic declarate necunoscute (raport_exporturi_saga_noua.md A.1, C.3, C.4, C.5).
• .gitignore ignora init_*.xlsx; git status arata xlsx-urile de productie scoase din index.
• Mediu: xlrd 2.0.2 si firebird-driver instalate; pytest NU; tests/ NU.

Nu am putut verifica (si nu am inventat):

• Daca 409 -> 4091 sau alte redenumiri sunt necesare pe firmele viitoare (nu apar in FUNDATIA/MASTER).
• Structura IES_DET din Firebird (raportul o da ca necunoscuta) - partea de facturi clienti e presupunere pana la o baza reala.
• Daca CONFIG_CONT_IREG s-a schimbat fata de dump-ul din config_cont_ireg.md (nu am interogat Oracle).
• Regula exacta de includere sintetic/analitic in exportul SAGA (C.5 o declara nedeterminabila).
• Comportamentul real al formularului pe combinatia "acont gol pe FACTURA + acont completat pe BALANTA" pe alte conturi decat cele deja tratate (am luat de bun decizii_import.md pct. 16).

Nu am rulat Codex/outside voice (mediu de subagent, fara Codex) si nici testul real de identitate CSV (nu am voie sa rulez VFP/cod in acest lane; oricum planul nu are inca cititoarele).

---

Stare: niciun fisier modificat in afara acestui raport; fara commit; fara procese pornite; fara date de test consumate.