Balanta intermediara urmeaza --firma; handoff-ul actualizat pentru sesiunea urmatoare

date/balanta_MASTERJOB.csv -> date/balanta_MASTER.csv: numele intermediarului
urmeaza intotdeauna --firma, deci `py genereaza.py --firma MASTER` merge acum fara
--balanta explicit. Firma se cheama in acte MASTERJOB, dar in unealta si in ROA e
MASTER; documentele care vorbesc despre firma pastreaza numele real.

Handoff: sectiune noua "Ce urmeaza", cu proba pe un client real ca prim pas, si
sectiunea de riscuri asumate in locul listei de lucruri ramase.
plan_solduri2roa.md: pasul 2 marcat terminat, cu trimitere la handoff.

33 de teste trec, zero skip-uri.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EYeAtVxeS8m4oXekjX8Am2
This commit is contained in:
2026-09-21 16:46:20 +03:00
parent 9a83e367d8
commit bbd7225c9f
4 changed files with 52 additions and 20 deletions

View File

@@ -27,7 +27,8 @@ Actualizat 21.09.2026, la finalul executiei. Versiunea anterioara a acestui fisi
| `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), plus commit-ul final de regresie.
`6b37d37` (citire-fdb), `82511c8` (integrare), `0d0b3e2` (regresie - poarta finala),
`9a83e36` (mutarea in `date/`, `iesiri/`, `sablon/`).
## 2. Portile care au trecut, si ce dovedesc
@@ -70,15 +71,38 @@ raportasera "GATA" corect dupa criteriile lor.
**nu** listeaza `5121`, `5124`, `5311`, pe care le trateaza. Confirma decizia din plan: Oracle e
consultativ. Detaliile in `docs/decizii_import.md`.
## 6. Ce ramane pentru mai tarziu
## 6. Ce urmeaza - de aici incepe sesiunea urmatoare
- o baza `.FDB` **reala** + exportul ei de balanta, ca sa se reruleze poarta pe date cu analitice
si cu volum;
- portul **4296** al acestui proiect nu e inca trecut in tabelul din
`D:\ROA\ROACONT\COMUN\docs\opencode_agenti_orchestrare.md` (COMUN cere aprobare inainte de commit);
- `docs/plan_solduri2roa.md` descrie inca etapele 1-6; nu a fost rescris dupa etapa 2.
In ordinea in care le-as face:
## 7. Starea pe disc
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, unde codul fiscal e real.
Verifica pe date reale si, daca se confirma, scoate-l din flux pentru sursa Firebird.
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
@@ -89,7 +113,7 @@ Fisierele `iesiri/init_FUNDATIA_2025_12.xlsx` si `iesiri/init_MASTER_2025_12.xls
disc dar nu in git; sunt necesare doar daca vrei sa **regenerezi** etalonul
(`py tests\anonimizeaza_etalon.py`, care le citeste din `iesiri/`).
## 8. Cum rulezi acum unealta
## 9. Cum rulezi acum unealta
```
py extrage.py --fisier "date\IBB 31.12.2025.pdf" --firma FUNDATIA --an 2025 --luna 12
@@ -99,9 +123,10 @@ 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/`.
**Capcana de nume**: balanta firmei MASTER se numeste `balanta_MASTERJOB.csv`, nu
`balanta_MASTER.csv`, deci pentru ea trebuie dat explicit
`--balanta date\balanta_MASTERJOB.csv`. Eroarea e clara, nu tacuta.
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.

View File

@@ -63,8 +63,15 @@ Pasul e obligatoriu, nu optional: partenerii intra in xlsx cu cod fiscal provizo
`git init`, commit, push pe `gitea.romfast.ro:romfast/solduri2roa.git` (push-to-create).
Se comit: scripturile, `docs\`, CSV-urile si xlsx-urile generate. PDF-urile: da (sunt sursa, 30 KB).
## Pasul 2 (dupa import) - convertorul reutilizabil
Generalizarea etapelor 1 + 4 intr-un singur script cu parametri (firma, an, luna, sursa PDF sau
xlsx SAGA), cu regulile din `decizii_import.md` scoase intr-un fisier de configurare
(conturi cu parteneri, maparea analiticelor). Nu se porneste inainte ca cele doua importuri sa
fie validate in ROA.
## Pasul 2 (dupa import) - convertorul reutilizabil: **TERMINAT 21.09.2026**
Planul detaliat: `plan_etapa2_convertor.md`. Starea de final si ce nu e dovedit:
`handoff_etapa2_convertor.md` - **acela e documentul de citit, nu acesta.**
Livrat: `extrage.py` / `genereaza.py` cu parametri, trei cititoare (PDF, foaie SAGA, Firebird),
pasul de mapare cu corectii, `config/conturi_parteneri.csv`, 33 de teste.
Poarta finala: fluxul nou, pornit de la PDF-urile originale, reproduce identic xlsx-urile
importate in ROACONT.
Etapele 1-6 de mai sus raman ca istoric al primului import; caile s-au schimbat de atunci
(`date/`, `iesiri/`, `sablon/`).

View File

@@ -32,7 +32,7 @@ GOLDEN = TESTS / "golden"
FIRME = [
("FUNDATIA", "balanta_FUNDATIA.csv", "golden_FUNDATIA_2025_12.xlsx"),
("MASTER", "balanta_MASTERJOB.csv", "golden_MASTER_2025_12.xlsx"),
("MASTER", "balanta_MASTER.csv", "golden_MASTER_2025_12.xlsx"),
]
MAX_DIFERENTE_RAPORTATE = 20

View File

@@ -12,7 +12,7 @@ reguli si ACEIASI tabela ca tests/anonimizeaza_etalon.py si se compara cu
tests/golden/ pe VALORI DE CELULA, nu pe hash de fisier.
Asocierea PDF -> firma nu se presupune: fiecare balanta extrasa se compara cu
balanta de referinta din date/ (balanta_FUNDATIA.csv / balanta_MASTERJOB.csv),
balanta de referinta din date/ (balanta_FUNDATIA.csv / balanta_MASTER.csv),
care e cea folosita la constructia etalonului.
Daca iesirea difera de etalon, etalonul are dreptate: se raporteaza, nu se ajusteaza.
@@ -51,7 +51,7 @@ MAX_DIFERENTE_RAPORTATE = 20
FIRME = [
("FUNDATIA", "IBB 31.12.2025.pdf", "balanta_FUNDATIA.csv",
"golden_FUNDATIA_2025_12.xlsx"),
("MASTER", "MJC 31.12.2025.pdf", "balanta_MASTERJOB.csv",
("MASTER", "MJC 31.12.2025.pdf", "balanta_MASTER.csv",
"golden_MASTER_2025_12.xlsx"),
]