# 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_.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_.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 `, `--clienti `, `--facturi `, `--fdb `. **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_.csv` - exact 12 coloane, neschimbat; `TIP` nu se adauga (nu e nevoie in generator; `genereaza_xlsx.py` nu citeste `tip`); - `parteneri_.csv` - `cont_saga, denumire, cod_fiscal, analitic`; - `facturi_.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__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_.csv (12 col) --> genereaza -------> init___.xlsx xlsx/xls SAGA -----> citire-xlsx (NOU) -> balanta_.csv CONT_BAZA.FDB -----> citire-fdb (NOU) -> parteneri_.csv [nume/coloane ?] + mapare_.xlsx facturi_.csv [nume/coloane ?] + docs/verificare_.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.