Files
solduri2roa/docs/handoff_etapa2_convertor.md
Marius Mutu 99d9cf0aff Cititorul FDB: sume totale ca SAGA, analitice pastrate, baza oprita acceptata
Proba pe LACERTA (06/2026, firma reala) a gasit doua defecte in citire_fdb:
- precedentul netea si rulajele din an, deci conturile de cheltuieli/venituri
  pierdeau rulajul (CPP gresit). Acum: preluare netata + rulaj an brut;
  potriveste 44/44 sintetice din importul facut din exportul SAGA (inainte 19/44).
- analiticele se rulau in sintetic, deci facturile per document nu se foloseau
  si analiticele nepartener disparea. Acum balanta are toate nivelurile.

Baza primita se copiaza in temporar si copia se repune online (clientul o
trimite si in full shutdown). tests/test_lacerta.py: 48/53 frunze identice cu
REF, restul explicate; se sare fara fisierele clientului, care sunt ignorate
de git. README nou; analiza in docs/analiza_lacerta_fdb.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EYeAtVxeS8m4oXekjX8Am2
2026-09-25 16:14:14 +03:00

143 lines
8.1 KiB
Markdown

# Handoff - etapa 2, convertorul reutilizabil SAGA -> ROA
Actualizat 21.09.2026, la finalul executiei. Versiunea anterioara a acestui fisier descria starea
**inainte** de lansarea lane-urilor; toate lane-urile au rulat intre timp.
**Stare: etapa 2 este terminata.** Toate cele sase lane-uri din plan au trecut portile lor,
33 de teste trec fara niciun skip, totul e comis si impins pe `origin/main`.
---
## 1. Ce exista acum
| fisier | ce face |
|---|---|
| `extrage.py` | punctul de intrare: `--sursa pdf/xlsx/fdb` (dedus din extensie) -> contractul intern |
| `genereaza.py` | punctul de intrare: contractul intern + mapare -> `init_<FIRMA>_<an>_<luna>.xlsx` |
| `extract_balanta.py` | cititorul PDF, **nemodificat** (era validat in productie) |
| `citire_xlsx.py` | cititorul de foaie SAGA `.xls` (xlrd) si `.xlsx` (openpyxl) |
| `citire_fdb.py` | cititorul Firebird: balanta, parteneri, facturi |
| `mapare.py` | propunere automata, `corectii_<FIRMA>.xlsx`, `.TOATE`/`.RESTUL`, redenumire sintetic |
| `genereaza_xlsx.py` | biblioteca de generare, acum parametrizata pe an/luna |
| `config/conturi_parteneri.csv` | conturile cu parteneri - **autoritatea** |
| `tools/divergenta_parteneri.py` | raporteaza divergenta fata de `CONFIG_CONT_IREG`, nu o aplica |
| `tests/` | 33 de teste, `unittest` din stdlib |
| `docs/procedura_copie_fdb_client.md` | cum isi face clientul copia bazei |
| `docs/raport_lane_*.md` | raportul fiecarui lane |
| `date/`, `iesiri/`, `sablon/` | intrari de la client / xlsx-uri generate / sablonul ROA |
Commit-uri: `15bb26a` (plan + etalon), `f23b336` (contract), `ba4cbbf` (citire-xlsx + mapare),
`6b37d37` (citire-fdb), `82511c8` (integrare), `0d0b3e2` (regresie - poarta finala),
`9a83e36` (mutarea in `date/`, `iesiri/`, `sablon/`).
## 2. Portile care au trecut, si ce dovedesc
1. **Regresia pe etalon** (`tests/test_regresie.py`): biblioteca reproduce celula cu celula cele
doua xlsx-uri importate in ROACONT. Verificat ca poarta e reala: scoaterea lui `5311` din
config o face sa pice.
2. **Poarta cititoarelor** (`tests/test_citire_fdb.py`): CSV-ul din `CONT_BAZA.FDB` e identic **la
octet** cu cel din exportul xlsx, pe firma de joaca, 09/2026. Plus `SUM(REGISTRU)` pe fiecare
latura = netul balantei.
3. **Poarta finala** (`tests/test_regresie_capat_la_capat.py`): `extrage.py` + `genereaza.py`
rulate ca **subprocese**, pornind de la PDF-urile originale, reproduc etalonul cu **0 diferente**.
## 3. Ce NU e dovedit - citeste inainte sa duci asta la un client
- **Cititorul FDB e verificat doar pe cazul sintetic.** Firma de joaca are 10 conturi, toate
sintetice, niciun analitic, 2 furnizori, 0 clienti, 1 factura. Rollup-ul analitic -> sintetic si
periodizarea sunt dovedite doar acolo. Scris si in docstring-ul lui `citire_fdb.py`.
**Nu se foloseste la un client fara rerularea portii pe datele lui.**
- Conectarea la Firebird **prin retea** nu merge cu parola implicita: cere credentiale clientului.
- Drumul cu parteneri si facturi reale (un `FACTURA` per document, cod fiscal din `FURNIZORI`) a
fost exersat doar pe o singura factura a firmei de joaca.
## 4. Doua defecte prinse la verificare, nu de lane-uri
Amandoua erau tacute - ar fi trecut testele si ar fi stricat date:
1. **`.xls`-ul SAGA nu are inregistrare CODEPAGE**, deci `xlrd` cadea pe iso-8859-1 si strica
denumirile (`FURNIZORI \x97 DEBITORI`). Reparat cu `encoding_override="cp1250"`, cu asertie in
`tests/test_citire_xlsx.py` care pica daca revine.
2. **Redenumirea unui cont cu parteneri lua primul analitic** ca sa afle contul sintetic. Cu
analitice mapate pe conturi diferite, BALANTA agregat si randurile FACTURA cadeau pe conturi
diferite. Acum ridica `Stop`; colapsarea prin `.TOATE` ramane legala.
Morala pentru sesiunea urmatoare: **raportul unui lane nu tine loc de verificare.** Ambele lane-uri
raportasera "GATA" corect dupa criteriile lor.
## 5. Divergenta fata de Oracle, constatata si scrisa
`CONFIG_CONT_IREG` listeaza 27 de conturi pe care codul validat nu le trateaza ca parteneri, si
**nu** listeaza `5121`, `5124`, `5311`, pe care le trateaza. Confirma decizia din plan: Oracle e
consultativ. Detaliile in `docs/decizii_import.md`.
## 6. Ce urmeaza - de aici incepe sesiunea urmatoare
**Actualizare 25.09.2026 - proba pe client real facuta (LACERTA, 06/2026).** A gasit doua
defecte in `citire_fdb` (sumele totale netate gresit si analiticele aruncate), acum
reparate, cu poarta in `tests/test_lacerta.py`. Detalii si intrebari deschise:
`docs/analiza_lacerta_fdb.md`. Punctul 1 de mai jos e facut pe o firma; punctul 2 ramane
(importul in ROACONT al iesirii LACERTA).
In ordinea in care le-as face:
1. **Proba pe un client real** - singurul lucru care mai conteaza acum. Cere unui client cu SAGA
noua copia bazei (`docs/procedura_copie_fdb_client.md`) **si** exportul lui de balanta pe
aceeasi luna. Ruleaza poarta cititoarelor pe datele lui: daca cele doua CSV-uri coincid pe o
firma cu analitice si cu volum, cititorul FDB inceteaza sa mai fie "verificat partial". Daca
nu coincid, diferenta este livrabilul - nu se ajusteaza nimic ca sa treaca.
2. **Al doilea import real, capat-la-capat**, pe o firma noua: `extrage.py` -> corectii in
`corectii_<FIRMA>.xlsx` -> `genereaza.py` -> import in ROACONT. Asta exerseaza pasul de mapare
pe date pe care nu le-a vazut nimeni si e primul test adevarat al lui `.TOATE`/`.RESTUL`.
3. ~~**Pasul 5b (cautarea pe ANAF)** devine inutil pe drumul FDB~~ - **verificat 21.09.2026,
nu se confirma.** SAGA permite parteneri fara `COD_FISCAL`; `citire_fdb.py:224` cade atunci
pe contul analitic, adica exact codul provizoriu pe care 5b il repara. Pe firma de joaca
ROMFAST (`401.00001`) n-are CUI, TRANSPORT are `1879855`. Pasul ramane, doar se
micsoreaza: se cauta numai partenerii cu `cod_fiscal == cont_analitic`. Detaliile in
`docs/plan_solduri2roa.md`, etapa 5b; asertiune in `tests/test_citire_fdb.py`.
4. Marunt, cand se nimereste: portul **4296** nu e trecut in tabelul din
`D:\ROA\ROACONT\COMUN\docs\opencode_agenti_orchestrare.md` (COMUN cere aprobare
inainte de commit).
**Nu incepe** prin a reface cercetarea sau a redeschide deciziile din sectiunea 5 a planului:
sunt platite si validate. Daca ceva pare gresit, cere dovada, nu reinvestiga.
## 7. Riscuri asumate, nu uitate
- **Firebird prin retea** nu merge cu parola implicita: la un client care nu poate trimite
fisierul, cere credentiale. Nu e rezolvat, e ocolit prin copia locala.
- **Un singur analitic cu sold pe latura opusa** (`5121.01` la MASTER, -20.80 D) trece azi
prin regula de la `decizii_import.md` pct. 15. E validat in productie pe un caz; al doilea
client il va pune la incercare.
- `docs/verificare_*.md` din git sunt cele ale importurilor validate; rularile noi scriu in
`iesiri/` si nu le ating.
## 8. Starea pe disc
Totul comis si impins pe `origin/main`. Nimic periculos: niciun proces ramas viu (serverul opencode
de pe 4296 a fost oprit), `D:\ROA\ROACONT`, `D:\SAGA250909` si `saga2roa*` neatinse, baza firmei de
joaca deschisa numai prin copie in temporar, `tests/_corespondenta_anonimizare.json` ramasa ignorata
de git.
Fisierele `iesiri/init_FUNDATIA_2025_12.xlsx` si `iesiri/init_MASTER_2025_12.xlsx` sunt pe
disc dar nu in git; sunt necesare doar daca vrei sa **regenerezi** etalonul
(`py tests\anonimizeaza_etalon.py`, care le citeste din `iesiri/`).
## 9. Cum rulezi acum unealta
```
py extrage.py --fisier "date\IBB 31.12.2025.pdf" --firma FUNDATIA --an 2025 --luna 12
py genereaza.py --firma FUNDATIA --an 2025 --luna 12
```
Implicit `extrage.py` scrie in `date/`, iar `genereaza.py` citeste din `date/` si scrie in
`iesiri/` (`--dir` / `--dir-iesire` le schimba). Sablonul e in `sablon/`.
Numele intermediarului urmeaza intotdeauna `--firma`: `date/balanta_<FIRMA>.csv`. Firma se
cheama in acte MASTERJOB, dar peste tot in unealta si in ROA e `MASTER`, deci balanta ei e
`date/balanta_MASTER.csv` (redenumita 21.09.2026; inainte era `balanta_MASTERJOB.csv` si
cerea `--balanta` explicit).
Sursa se deduce din extensie (`.pdf`, `.xls`/`.xlsx`, `.fdb`); o extensie necunoscuta da eroare.
Pentru Firebird, da calea catre o **copie** a bazei, niciodata baza vie a clientului.