# 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_.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 `.`, 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` - `.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_.csv` + optional `parteneri_.csv` + optional `facturi_.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.