Verificat pe firma de joaca: ROMFAST (401.00001) nu are COD_FISCAL, deci citire_fdb.citeste_parteneri cade pe contul analitic - exact codul provizoriu pe care etapa 5b il repara. TRANSPORT (401.00002) are CUI real, 1879855. Pasul ANAF nu se scoate pentru sursa Firebird, doar se micsoreaza la partenerii cu cod_fiscal == cont_analitic. Asertiune in test_citire_fdb.py care pica daca setul lor se schimba. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EYeAtVxeS8m4oXekjX8Am2
86 lines
5.1 KiB
Markdown
86 lines
5.1 KiB
Markdown
# Plan: balante SAGA (PDF) -> xlsx de initializare ROA
|
|
|
|
Proiect: `D:\ROA\IMPORT2ROA\solduri2roa`
|
|
Obiectiv prioritar: doua fisiere xlsx gata de importat in ROACONT pentru FUNDATIA si MASTER, luna 12/2025.
|
|
Obiectiv secundar (pasul 2): program reutilizabil de conversie SAGA -> xlsx ROA.
|
|
|
|
Deciziile de mapare: `decizii_import.md`. Semantica formularului de import: `raport_form_init_balanta.md`.
|
|
|
|
## Etapa 1 - extragere fidela din PDF (lane `pdf-extract`)
|
|
`extract_balanta.py` (pdfplumber, pe coordonate) -> `balanta_FUNDATIA.csv`, `balanta_MASTERJOB.csv`
|
|
cu `cont;denumire;prec_d;prec_c;rulaj_d;rulaj_c;total_d;total_c;sold_d;sold_c;este_total`.
|
|
Poarta de trecere (nu se avanseaza cat timp pica):
|
|
- `total_d = prec_d + rulaj_d`, `total_c = prec_c + rulaj_c` pe fiecare cont
|
|
- `sold_d - sold_c = total_d - total_c` pe fiecare cont
|
|
- `SUM(sold_d) = SUM(sold_c)` pe conturile frunza
|
|
- suma analiticelor = parintele, pe fiecare nivel
|
|
Un esec = parser gresit, nu date gresite: se repara parserul, nu cifrele.
|
|
|
|
## Etapa 2 - semantica formularului (lane `form-init-balanta`)
|
|
Analiza `COMUN\ferestre\frm_initializare_facturi_balanta.sc2`: coloane obligatorii, validari
|
|
blocante, crearea partenerului dupa `cod_fiscal` (si daca respinge un "CUI" de forma `401.00027`),
|
|
regula `id_partd`/`id_partc`, lungimi `cont`/`acont`, rolul `CONFIG_CONT_IREG`.
|
|
Risc principal de oprit aici: o validare de CUI care refuza `401.00027`.
|
|
|
|
## Etapa 3 - conturile cu parteneri (lane `config-cont-ireg`)
|
|
`CONFIG_CONT_IREG` din Oracle local -> lista conturilor cu `CU_INREGISTRARI = 1`.
|
|
|
|
## Etapa 4 - maparea in structura ROA
|
|
Pentru fiecare firma, din CSV:
|
|
1. **Conturi fara parteneri**: se pastreaza doar frunzele. `cont` = primele max 4 caractere,
|
|
`acont` = restul cifrelor concatenate (max 4). Un rand `BALANTA` per frunza, cu
|
|
`totdeb = total_d`, `totcred = total_c`. Daca suma frunzelor difera de parinte -> analitic de
|
|
diferenta, raportat explicit.
|
|
2. **Conturi cu parteneri** (din etapa 3): un singur rand `BALANTA` pe sintetic (fara `acont`),
|
|
cu suma `total_d` / `total_c` a analiticelor, plus cate un rand `FACTURA` per analitic-partener:
|
|
`nume` = denumirea analiticului, `cod_fiscal` = `<cont>.<analitic>` din SAGA,
|
|
`numar` = analiticul, `sold` = soldul analiticului (cu semnul dat de natura contului),
|
|
`data` = 01.12.2025, `datascad` = 31.12.2025.
|
|
3. Toate randurile: `an = 2025`, `luna = 12`.
|
|
Iesire: `init_FUNDATIA_2025_12.xlsx`, `init_MASTER_2025_12.xlsx`, generate din sablonul
|
|
`init_facturi_balanta_note.xlsx` cu randurile de instructiuni sterse.
|
|
|
|
## Etapa 5 - verificare inainte de predare
|
|
- `SUM(totdeb) = SUM(totcred)` pe tot xlsx-ul
|
|
- pentru fiecare cont cu parteneri: `SUM(sold FACTURA) = soldul sintetic din balanta`
|
|
- fiecare cont din balanta apare exact o data (frunza) in xlsx; niciun cont pierdut
|
|
- `cont` <= 4 caractere, `acont` <= 4 caractere, fara dubluri `cont+acont`
|
|
Raport: `docs\verificare_<firma>.md`, cu totalurile din balanta alaturi de totalurile din xlsx.
|
|
|
|
## Etapa 5b - codurile fiscale reale ale partenerilor
|
|
Pasul e obligatoriu, nu optional: partenerii intra in xlsx cu cod fiscal provizoriu
|
|
(`<cont>.<analitic>` din SAGA) si trebuie corectati cu CUI-ul real.
|
|
1. Lista partenerilor fara CUI: `parteneri_de_cautat.md`.
|
|
2. Cautare pe demoanaf.ro (denumire -> CUI), rezultat in `parteneri_cui_gasite.md`.
|
|
3. Verificare TVA pe ANAF pentru fiecare CUI gasit (POST
|
|
`https://webservicesp.anaf.ro/api/PlatitorTvaRest/v9/tva`, campul `scpTVA`):
|
|
platitor de TVA -> cod fiscal cu prefix `RO`; neplatitor -> CUI fara prefix.
|
|
4. Scripturile de corectie, per schema: `sql/update_cod_fiscal_<SCHEMA>.sql` (neexecutate,
|
|
se ruleaza manual dupa import).
|
|
5. Partenerii negasiti raman cu codul provizoriu si se raporteaza explicit.
|
|
|
|
**Pe sursa Firebird pasul ramane, nu dispare** (verificat 21.09.2026 pe firma de joaca).
|
|
SAGA permite furnizori/clienti fara `COD_FISCAL`, iar `citire_fdb.citeste_parteneri` cade
|
|
atunci pe contul analitic - acelasi cod provizoriu ca pe drumul PDF. Pe firma de joaca
|
|
ROMFAST (`401.00001`) nu are CUI, TRANSPORT (`401.00002`) are `1879855`: 1 din 2. Ce se
|
|
schimba fata de PDF e doar volumul: se cauta numai partenerii cu
|
|
`cod_fiscal == cont_analitic`, restul vin cu CUI real din baza. Asertiunea din
|
|
`tests/test_citire_fdb.py::test_parteneri_si_facturi` pica daca asta se schimba.
|
|
|
|
## Etapa 6 - git
|
|
`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: **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/`).
|