solduri2roa/docs/decizii_import.md

## 11. Trezorerie: banca si casa (512x / 531x) - PARTENERI, nu analitice
Stabilit 20.09.2026.

- **Conturi bancare `512x`** (5121 lei, 5124 devize, 5125 sume in curs de decontare): analiticele SAGA
  **nu** devin analitice in ROA. Pentru fiecare analitic se creeaza un **partener cu numele exact al
  analiticului** (numele contului bancar, ex `RO73 BACX 0000 0008 7243 0001`, `PIRAEUS BANK - RON`),
  cod fiscal = codul SAGA (`5121.01`), si un rand `FACTURA` pe contul sintetic.
- **Casa `531x`**: se creeaza partenerul **`CENTRALA`** (casa centrala), cod fiscal = codul contului
  (`5311`). Contul nu are analitice in balantele astea - un singur rand `FACTURA` pe sintetic.

## 12. Partener fara denumire in balanta
Daca analiticul nu are denumire in PDF (ex MASTERJOB `401.00014`), partenerul se creeaza cu numele
**`FURNIZOR <cod SAGA>`** (`FURNIZOR 401.00014`) si cod fiscal `401.00014`. Contabilitatea il
identifica dupa cod si il corecteaza in ROA. Nu se ghiceste numele.

## 13. Postari directe pe contul sintetic (analitic de diferenta)
SAGA permite inregistrari **direct pe contul sintetic**, fara analitic, si in plus **neteaza** D/C la
sintetice. Importul ROA construieste sinteticul ca **suma analiticelor**, deci partea postata direct
pe sintetic s-ar pierde.

Regula:
1. Diferenta se calculeaza **pe net** (`parinte_D - parinte_C` fata de `SUM(copii_D) - SUM(copii_C)`),
   pentru ca gross-ul parintelui e netat de SAGA si nu e recuperabil.
2. Diferenta **net zero** = doar netare SAGA, se ignora (ex FUNDATIA `1171.01`: -739.831,67 pe ambele
   laturi, net 0).
3. Diferenta **net diferita de zero** = postare reala pe sintetic: se adauga un **analitic nou de
   diferenta**, cu suma pusa pe latura semnului diferentei, si se **raporteaza explicit** in
   `verificare_<firma>.md` (nu se ajusteaza analiticele existente).
4. La conturile devenite PARTENERI, diferenta devine un **partener de diferenta**, nu un analitic.

Cazuri gasite la importul 12/2025:
| Firma | Cont | Diferenta net | Tratament |
|---|---|---|---|
| FUNDATIA | 1171.01 | 0,00 (doar netare) | se ignora |
| MASTERJOB | 117 | +2.635,87 debit | analitic nou de diferenta |
| MASTERJOB | 5121 | +152,16 debit | partener de diferenta (5121 e cont cu parteneri) |

## 14. Trezorerie (512x / 531x): parteneri pe randuri BALANTA, FARA randuri FACTURA
Stabilit 20.09.2026, inlocuieste partea de forma din pct. 11 (regula de continut ramane).

Conturile de banca si casa **au parteneri, dar nu au facturi**: apar in balanta de verificare si in
balanta de parteneri, niciodata in registrul de facturi.

In xlsx:
- **Nu** se genereaza randuri `TIP=FACTURA` pe `512x` / `531x`.
- Se genereaza cate un rand `TIP=BALANTA` **per cont bancar / casa**, pe contul sintetic
  (`acont` gol), cu `nume` = denumirea analiticului SAGA (numele contului bancar, `CENTRALA` la
  casa) si `cod_fiscal` = codul SAGA (`5121.01`, `5311`), `totdeb`/`totcred` = sumele totale ale
  analiticului respectiv.

Confirmare din codul ROA (`COMUN\ferestre\frm_initializare_facturi_balanta.sc2:1104-1107`), la
celalalt flux de import (balanta prin `conturi_roa.dbf`), unde exista doua liste distincte:
- `lcListaConturiBalP` (balanta de parteneri): `401,404,408,409,4091,4092,4093,4111,418,419,461,462,4551,`**`5311,5121,5124`**
- `lcListaConturiIregP` (inregistrari/facturi): aceeasi lista **fara** `5311,5121,5124`

`5125` nu figureaza in niciuna dintre liste - de tratat separat.

### Forma concreta in xlsx: randuri FACTURA (decis 20.09.2026)
Formularul de import xlsx **nu suporta parteneri pe randurile `BALANTA`**:
- `:828` goleste `denumire` cand `tip = 'BALANTA'` (o muta in `explicatia`)
- `:867` construieste nomenclatorul de parteneri doar din randurile `WHERE ALLTRIM(tip) = 'FACTURA'`

Ca sa nu modificam formularul, trezoreria se pune **pe randuri `FACTURA`**, ca orice cont cu
parteneri: partenerul se creeaza corect, `id_partd`/`id_partc` se completeaza, iar
`balanta_parteneri` se reconstruieste din `ireg_parteneri` (`:1685-1695`), deci cifrele ies exact.

Efect secundar acceptat: pe conturile de trezorerie raman documente de tip FACTURA
(`id_fdoc = 42`, `:528`) care nu sunt facturi reale. Nu deranjeaza balanta de parteneri.

Regula de continut ramane cea de la pct. 11: un partener per cont bancar, cu numele analiticului
(`RO45 PIRB ...`, `PIRAEUS BANK - RON`), iar la casa partenerul `CENTRALA`.

### Sensul soldului la trezorerie
Randurile FACTURA primesc latura dintr-o **lista fixa in cod** (`:379`):
`401, 404, 462, 419, 408, 4551` -> credit; **tot restul -> debit**.
Un cont bancar cu sold creditor (descoperit de cont) nu se poate exprima printr-un rand FACTURA:
se lasa fara rand FACTURA, iar randul `BALANTA` il duce pe credit, unde formularul ii pune automat
partenerul `NEREPARTIZAT` (`:415-431`). Se raporteaza cazul, ca sa fie corectat manual in ROA.
Caz gasit: MASTER `5121.01 PIRAEUS BANK - RON`, sold creditor 20,80.

## 15. 512x: analitice SI parteneri; 5125 doar analitice
Revizuit 20.09.2026 (inlocuieste forma din pct. 11 si 14 pentru aceste conturi).

- **`5121`, `5124`** (conturi bancare): analiticele **raman analitice** in planul de conturi si in
  balanta, **si in plus** fiecare analitic primeste un partener. Concret, pentru fiecare analitic
  se scriu DOUA randuri, pe acelasi `(cont, acont)`:
  - un rand `TIP=BALANTA` cu `acont` completat si `totdeb`/`totcred` = sumele totale ale analiticului;
  - un rand `TIP=FACTURA` cu **acelasi `acont`**, `nume` = denumirea analiticului (numele contului
    bancar), `cod_fiscal` = codul SAGA (`5121.01`), `sold` = soldul analiticului.

  `acont` trebuie sa fie acelasi pe ambele randuri: formularul scade randurile FACTURA din randul
  BALANTA care are acelasi `(cont, acont, latura)` (`:415-431`). Cu `acont` diferit suma s-ar
  dubla si ar aparea un rest negativ pe `NEREPARTIZAT`.
- **`5311`** (casa, fara analitice): rand `BALANTA` pe `5311` (acont gol) + rand `FACTURA` pe
  `5311` (acont gol), partener `CENTRALA`.
- **`5125`**: **doar analitice**, fara parteneri. Se trateaza ca orice cont obisnuit cu analitice.
- Un analitic cu soldul pe **latura opusa** laturii fixate in cod (`:379` - trezoreria merge pe
  debit) primeste totusi rand FACTURA: suma se scrie **cu semn negativ pe latura formularului**,
  atat in randul `BALANTA` (`totdeb = -20,80`, `totcred` gol) cat si in `sold`-ul randului
  `FACTURA` (`-20,80`). Soldul ramane pe latura corecta, balanta ramane inchisa
  (`SUM(totdeb) = SUM(totcred)`), randul FACTURA consuma exact randul BALANTA si nu mai ramane
  nimic pe `NEREPARTIZAT`. Pretul: nota contine o suma negativa - acceptat (decis 20.09.2026).
  Caz gasit: MASTER `5121.01 PIRAEUS BANK - RON`, sold creditor 20,80.

## 16. Regula generala: randul FACTURA trebuie sa aiba acelasi `acont` ca randul BALANTA pe care il consuma
Confirmat 20.09.2026.

Formularul grupeaza randurile `FACTURA` pe `(cont, acont, latura)` si **scade** suma lor din randul
`BALANTA` cu exact aceeasi cheie; restul ramane pe partenerul `NEREPARTIZAT`, iar daca randul
`BALANTA` lipseste, il creeaza el (`frm_initializare_facturi_balanta.sc2:415-431`).

Consecinte:
- `acont` gol pe `FACTURA` + `acont` completat pe `BALANTA` = cheie diferita: suma **se dubleaza**
  (analiticul ramane intreg in balanta si se mai adauga un rand negativ pe sintetic, pe
  `NEREPARTIZAT`). Greseala tacuta, nu da eroare.
- De aceea: cont cu parteneri **fara** analitice in ROA (401, 4092, 4111, 461, 462, 4551) ->
  ambele randuri cu `acont` gol. Cont cu parteneri **si** analitice in ROA (5121, 5124) ->
  ambele randuri cu acelasi `acont`.
- Latura conteaza si ea: un rand FACTURA pe debit nu atinge randul BALANTA de pe credit.

## 17. Decizii din proba LACERTA (26.09.2026)

- Coloana `data` = **ultima zi a lunii** (inainte, prima zi). Etalonul de regresie a fost
  actualizat doar pe aceasta coloana.
- `542` (avansuri de trezorerie) este cont cu parteneri: BALANTA pe sintetic + FACTURA per
  persoana.
- Analitice nenumerice stranse pe sintetic (`4428.M/TI/TP` prin `.TOATE`) primesc un acont
  (`01`), ca sa nu stea langa analiticul de diferenta (`99`) un rand fara acont.
- `461` si `4092` raman conturi cu parteneri, desi pot avea si analitice functionale sau
  geografice (`461.SGR`, `4092.1`). Acestea se pastreaza prin corectii, de exemplu
  `461.SGR -> 461 / SGR` si `461.RESTUL -> 461 / 1` pentru parteneri. Cand analiticele unui
  cont cu parteneri primesc `acont` prin corectii, generatorul scrie cate un BALANTA per
  `(cont, acont)`. FACTURA are acelasi `acont` (pct. 16), iar partenerul unui analitic
  functional poarta numele analiticului. Postarile direct pe sintetic merg pe acontul de
  diferenta, ca la banca. Fara astfel de corectii, comportamentul e cel de dinainte.
- Pe drumul FDB postarile direct pe sintetic intra cu D si C **brute**, nu pe net: acolo
  sinteticul e suma bruta a notelor, deci rulajul iese ca in SAGA (401 LACERTA: 8.991,55 /
  57.253,22). Daca o latura ar iesi negativa, se revine la net. PDF/xls raman pe net
  (pct. 13), pentru ca SAGA neteaza deja sinteticul in raport.
- Conturile nepartener cu 0 / 0 (fara sold si fara rulaj, ex. `891`) nu intra in xlsx.

## Divergenta fata de CONFIG_CONT_IREG (constatata 21.09.2026)

Setul operational de conturi cu parteneri este `config/conturi_parteneri.csv` (10 conturi; `542` adaugat 26.09.2026), validat
in productie. `CONFIG_CONT_IREG` din Oracle este doar **consultativ**; divergentele se raporteaza,
nu se aplica. Comparatia se reface oricand cu:

```
py tools/divergenta_parteneri.py config/config_cont_ireg_snapshot.csv
```

Rezultatul de azi (snapshot: conturile cu `CU_INREGISTRARI = 1` din `docs/config_cont_ireg.md`):

- **In Oracle, nu la noi (27):** `1621, 167, 232, 234, 261, 2678, 2691, 403, 404, 408, 409, 4091,
  4093, 4094, 4118, 413, 418, 419, 426, 4511, 456, 457, 471, 472, 4754, 542, 8051`
- **La noi, nu in Oracle (3):** `5121, 5124, 5311`

Interpretare: Oracle listeaza conturi de parteneri pe care codul validat nu le trateaza ca parteneri
(inclusiv 404, 408, 409, 419 si derivatele 409x). Invers, `5121`, `5124` (banca) si `5311` (casa)
sunt tratate ca parteneri de `genereaza_xlsx.py` desi Oracle nu le listeaza (pct. 11-15). Daca vreodata
se schimba setul operational, se schimba constient in CSV, nu pe baza acestui export.