solduri2roa/docs/analiza_lacerta_fdb.md

# Analiza LACERTA - drumul FDB comparat cu importul facut din exportul SAGA

25.09.2026. Prima proba a cititorului FDB pe o firma reala, cu analitice si volum.

Intrari (in `exemple/`, **nu in git** - contin nume de persoane si CNP-uri):
- `lacerta_CONT_BAZA-20-08_2026.FDB` - copia bazei, facuta la 20.08.2026;
- `lacerta_init_facturi_balanta_note-20-08_2026.xlsx` - xlsx-ul de initializare facut din
  exportul de balanta SAGA, perioada **06/2026** (56 BALANTA + 46 FACTURA). Mai jos: **REF**.

Rulare (copie in scratchpad, `date/` si `iesiri/` neatinse):
```
gfix -online normal <copie>.FDB -user SYSDBA -password masterkey   # vezi constatarea 1
py extrage.py --fisier <copie>.FDB --firma LACERTA --an 2026 --luna 6 --dir <tmp>
py genereaza.py --firma LACERTA --an 2026 --luna 6 --dir <tmp> --dir-iesire <tmp>\out
```
Rezultat: 54 de randuri, 4.323.688,60 pe ambele laturi, verificarile interne trec.
Verificarile trec, dar **iesirea e gresita** in doua moduri (constatarile 2 si 3).

---

## Constatari despre unealta noastra

### 1. Copia clientului vine in stare `full shutdown` - cititorul nu o deschide
`gstat -h` arata `Attributes: force write, full shutdown`; conectarea da `database ... shutdown`.
Clientul (sau SAGA) a oprit baza inainte de copiere - corect din partea lui. Pe **copia
noastra** `gfix -online normal` o repune; originalul ramane neatins.

### 2. Sumele totale sunt calculate gresit - afecteaza CPP-ul (defect)
`citire_fdb.py:84` neteaza **impreuna** soldul de preluare si rulajele lunilor anterioare din an:
`prec = net(init + an)`. SAGA (si REF) calculeaza `prec = net(init) + rulaj an`, **brut**.

| regula | conturi sintetice din REF potrivite |
|---|---|
| actuala: `net(init + an) + luna` | 19 / 44 |
| propusa: `net(init) + an + luna` | **44 / 44** |

Netul iese la fel in ambele cazuri, de aceea verificarile interne trec. Dar pe conturile de
cheltuieli si venituri rulajele Ian-Mai se anuleaza: `6022`, `6123`, `6231`, `6232`, `635`,
`667` ies cu `0 / 0` in loc de rulaj, iar `704` iese cu 684,68 in loc de 14.139,64.
Contul de profit si pierdere din ROA ar iesi gresit.

Pe firma de joaca regulile dau acelasi rezultat pe toate conturile. De aceea poarta a trecut,
si tot de aceea schimbarea nu o strica.

### 3. Cititorul arunca analiticele - pierde facturile si analiticele nepartener (defect)
`citire_fdb` ruleaza orice analitic in sintetic (`401.00002` -> `401`, `215.1` -> `215`). Baza
are planul analitic complet in `CONTURI`: 12 sintetice cu analitice in `REGISTRU`, inclusiv
`215.1-3` / `2815.1-3`, `4551.1-3`, `5121.1-2`, `542.01-02`, 15 furnizori, 26 clienti.

Consecinte:
- **Facturile nu se folosesc deloc.** `facturi_LACERTA.csv` are 74 de documente, dar generatorul
  le cauta dupa analiticul partenerului (`genereaza_xlsx.py:265`), care nu mai exista. Rezultatul
  e un singur `FACTURA` agregat pe cont, fara nume si fara cod fiscal real.
- **Analiticele nepartener dispar.** REF are `215` pe trei analitice; noi avem un singur rand.
- Facturile se potrivesc cu balanta: la **29 / 29** parteneri 401/4111, suma facturilor din baza
  este egala cu netul analiticului. Deci, daca pastram analiticele, drumul "un FACTURA per
  document" functioneaza fara nicio ajustare.

Aceasta este exact limita scrisa in docstring-ul lui `citire_fdb.py` ("NU dovedeste nimic despre
conturile analitice"). Acum e dovedita, si nu tine.

### 4. Analitice care nu intra in `acont` de 4 caractere
`419.NETOPIA`, `4428.M`, `4428.TI`, `4428.TP`, `461.SGR`. Dupa constatarea 3 vor ajunge la
mapare. `mapare.py` trebuie sa se opreasca pe ele si sa ceara o corectie (REF a pus `419.2`).

---

## Constatari despre REF (xlsx-ul deja facut din exportul SAGA)

Le scriu pentru ca REF a fost folosit la initializarea din ROA:

1. **REF nu e echilibrat**: are 6.315.365,48 pe debit si 5.043.406,14 pe credit. Cauza:
   `215`, `2815` si `4091` apar si cu randul sintetic, si cu analiticele, adica de doua ori
   (+1.530.528,54 D, +265.716,75 C, +7.810,92 D). Incalca regula "in xlsx intra doar frunzele".
   **De verificat in ROA daca soldurile acestor conturi au intrat dublu.**
2. Pe **`4092` lipsesc 1.563,37, iar pe `419` lipsesc 900,00.** Sunt note inregistrate direct pe
   sintetic, nu pe analitic (5 x 230 Starlink + 183,37 Netopia + 230 in iunie; 900 in februarie).
   REF a luat doar analiticele. Regula noastra de "analitic de diferenta" le prinde.
3. Randurile `FACTURA` pe 401 insumeaza 9.220,75, fata de un net de 48.261,67. Multe au `sold`
   gol, iar una are data `1910-05-13`.

Pe restul, REF si FDB coincid: 44 / 44 de sintetice pe sume totale, iar netul pe fiecare cont.

---

## Propuneri, in ordinea in care le-as face

| # | ce | marime | dovada ca a mers |
|---|---|---|---|
| P1 | `citire_fdb.py:84`: `prec = net(init) + an`, brut | ~2 linii | 44/44 pe LACERTA; testele pe firma de joaca raman verzi |
| P2 | `citire_fdb` emite si randurile analitice (sintetic + analitic, ca exportul SAGA "cu analitice"); poarta pe firma de joaca compara doar sinteticele | mediu | FACTURA per document pe 401/4111; `215.1-3` ca frunze |
| P3 | `extrage.py` pe drumul fdb copiaza baza in temporar si ruleaza `gfix -online` pe copie; procedura clientului mentioneaza ca oprirea bazei e acceptata | mic | LACERTA se deschide fara pas manual |
| P4 | test de regresie LACERTA: BALANTA pe frunze = REF, cu exceptiile de mai sus scrise explicit; se sare daca fisierele lipsesc (nu sunt in git) | mic | pica daca revine P1 sau P2 |
| P5 | `exemple/lacerta_*` in `.gitignore`: xlsx-ul are CNP-uri, iar acum nu e ignorat (FDB-ul este) | 1 linie | `git check-ignore` |

**Decizii care sunt ale tale, nu ale mele**, si nu le-am atins:
- `542` (decontari din avansuri): REF il trateaza ca cont cu parteneri (2 persoane); config-ul nostru nu.
- `461` si `4092`: config-ul le trateaza ca parteneri, REF nu.
- `config/conturi_parteneri.csv` descrie `4092` ca "Furnizori de imobilizari", dar 4092 e
  "furnizori-debitori pt. prestari servicii" (furnizorii de imobilizari sunt 404). Verifica daca
  e doar descrierea gresita sau si contul.
- Coloana `data` la BALANTA: noi scriem `01.06.2026`, REF are `30.06.2026`. Etalonul importat
  foloseste forma noastra, deci probabil ambele sunt acceptate, dar confirma.

## Ce s-a facut (25.09.2026)

P1-P5 sunt facute. Rulare pe LACERTA dupa ele (`tests/test_lacerta.py`):

- `extrage.py` citeste direct fisierul oprit din `exemple/`; originalul ramane `full shutdown`;
- 97 de randuri de balanta (sintetice + analitice), 79 de randuri in xlsx, echilibrat
  (4.775.134,59 pe ambele laturi), verificarile interne OK;
- **48 din 53** de frunze BALANTA sunt identice cu REF; restul diferentelor sunt listate
  in test (`DIFERENTE_ASTEPTATE`), fiecare cu cauza;
- 401: 12 randuri FACTURA, cate unul per document nesoldat, cu numar, data, scadenta si
  CUI real; suma e 9.220,75, cat in REF. Restul de 39.040,92 (preluarea postata direct pe
  401, fara partener) ramane pe `NEREPARTIZAT`, ca in regula stabilita;
- poarta e reala: fara P1 testul pica pe sume, fara P2 pica la generare.

Corectiile folosite (in test, ca in REF): `419.NETOPIA -> 419 / 2`, `4428.TOATE -> 4428`.

## Intrebari - raspunse 26.09.2026

1. 4428 -> corectia `4428.TOATE -> 4428 / 01`; doua frunze curate, `01` si `99`.
2. `.fbk` e acceptat: `extrage.py` il restaureaza cu `gbak -c` in temporar
   (`tests/test_citire_fdb.py::test_fbk_identic_cu_fdb`).
3. `542` e adaugat in config (acum identic cu REF: BALANTA 2.243,57 / 1.824,07 si 2 FACTURA
   care insumeaza 129,44). Descrierea lui `4092` e corectata.
4. Coloana `data` = ultima zi a lunii.

Frunze BALANTA identice cu REF dupa aceste decizii: **49 din 53**.

**Ramas deschis:** `461` si `4092` sunt conturi cu parteneri, dar pot avea analitice
functionale sau geografice (`461.SGR` "AMBALAJE SGR", `4092.1`). Azi un astfel de analitic
devine un pseudo-partener cu cod fiscal provizoriu (`461.SGR`).

## Starea pe disc
Cod: `citire_fdb.py` (P1-P3), `tests/test_citire_fdb.py` (poarta restransa la sintetice),
`tests/test_lacerta.py` (P4), `.gitignore` (P5). Suita: `py -m unittest discover -s tests`,
38 de teste, toate trec. Fisierele LACERTA din `exemple/` sunt ignorate de git.