# Corespondenta cont de stoc (3xx) -> cont de venit (7xx): ce exista in cod

**Context**: continuare a `cont_venit_articol_fara_politica.md`, care stabilise ca `VANZARI_DETALII.CONT`
e un cont de **gestiune/stoc** (371, 301-303, 357), fara sa gaseasca un cont de venit pe linia de
factura in `pack_facturare`, si lasase neverificat unde se genereaza efectiv contul de venit.
Cercetarea de fata raspunde la cele 4 intrebari, cu corectii fata de raportul anterior.

## Raspuns scurt

1. **Nu exista un tabel de corespondenta "3xx -> 7xx"** (nume de forma `CORESPONDENTA*`,
   `NOM_CONTURI*`, `CONT_VENIT*`, `ARTICOLE_CONTABILE*`) nicaieri in `SCRIPTURI_CLAR`. In schimb
   exista un **mecanism echivalent functional, dar configurat manual, nu derivat automat din contul
   de stoc**: tabelul `NOTE_CONTABILE` (coloane `SCD`/`ASCD` = cont+analitic debitor,
   `SCC`/`ASCC` = cont+analitic creditor), legat de politica de pret a articolului prin
   `CRM_POLITICI_PRETURI.ID_NOTA -> CRM_NOTE_VANZARI.ID_SET -> NOTE_CONTABILE`. Un contabil
   configureaza acest tabel dintr-un ecran dedicat (`frm_config_note_contabile[2007]`), nu se
   calculeaza din `NOM_ARTICOLE.CONT`/`STOC.CONT`.
2. **`NOM_ARTICOLE.CONT` NU e restrans la conturi de stoc (clasa 3).** Validarea la editare
   (`verific_cont`) verifica doar ca respectivul cod exista in planul de conturi al anului curent
   (`vplcont_sintetic`), fara filtru pe clasa. UI-ul trimite explicit catre "Planul de conturi"
   (buton de help general), nu catre un subset de conturi de stoc. Asta confirma afirmatia lui
   Marius: campul accepta orice cont, inclusiv 6xx/7xx.
3. **Nota contabila a vanzarii SE genereaza in `pack_facturare`** — raportul anterior a cautat
   literalii `707`/`704`/`706`/`708` (care nu apar hardcodati nicaieri, corect) si a conchis gresit
   ca lipseste mecanismul. El exista, dar e **indirect**: `pack_facturare.contabilizeaza_articol`
   (`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:7182-7556`) ia `SCD`/`SCC` din `NOTE_CONTABILE` (via
   politica de pret a articolului) si scrie nota cu `pack_facturare.scrie_nota(...)`. `SCC` (contul
   creditor) e contul de venit efectiv al liniei — nu vine din `VANZARI_DETALII.CONT` (care ramane
   contul de gestiune, folosit separat, doar pentru descarcarea de gestiune, in
   `descarca_gestiune`).
4. **`ID_VENCHELT`/`NOM_VENIT_CHELTUIELI` nu are coloana de cont** (nicio `ALTER TABLE
   NOM_VENIT_CHELTUIELI ADD ... CONT` in `SCRIPTURI_CLAR`). E o dimensiune analitica separata
   (clasificare venituri/cheltuieli, posibil pentru raportare/buget), transmisa ca parametru propriu
   catre `scrie_nota`, in paralel cu `SCD`/`SCC` — nu e sursa contului.

## 1. Nu exista tabel de corespondenta 3xx->7xx; exista `NOTE_CONTABILE` + politica de pret

### Cautare tabel dedicat — negativa
Cautari in `D:\ROA\DATABASE\SCRIPTURI_CLAR` (`CREATE TABLE`/`ALTER TABLE`, case-insensitive) pentru
`CORESPONDENT*`, `NOM_CONTURI*`, `CONT_VENIT*`, `PLAN_CONTURI*`, `ARTICOLE_CONTABILE*`: niciun
rezultat relevant — singurele hituri pe `CORESPONDENT` sunt cuvantul romanesc generic ("banca
corespondenta" etc.) in sute de fisiere fara legatura, iar `CONT_VENIT` nu apare deloc ca nume de
tabel/coloana.

### Mecanismul real: lant de 4 tabele, configurat pe politica de pret
`pack_facturare.contabilizeaza_articol` (`ff_...:7227-7280`) foloseste acest cursor pentru a afla
contul debitor/creditor al liniei de vanzare:

```sql
CURSOR cursor_articol IS
  SELECT A.ID_POL_ART, A.ID_POL, A.ID_ARTICOL, A.PRET, ...
         NVL(pack_facturare.nid_venchelt, NVL(A.ID_VENCHELT, C.ID_VENCHELT)) AS ID_VENCHELT,
         NVL(pack_facturare.nid_sectie_stoc, C.ID_SECTIE) as ID_SECTIE,
         C.ID_SET, D.EXPLICATIE, D.SCD, D.ASCD, D.SCC, D.ASCC, D.CU_TVA, ...
    FROM CRM_POLITICI_PRET_ART A
    LEFT JOIN CRM_POLITICI_PRETURI B ON A.ID_POL = B.ID_POL
    LEFT JOIN CRM_NOTE_VANZARI C ON B.ID_NOTA = C.ID_NOTA
    LEFT JOIN NOTE_CONTABILE D ON C.ID_SET = D.ID_SET
   WHERE A.ID_POL = detalii_articol.id_pol AND A.ID_ARTICOL = detalii_articol.id_articol;
```
(`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:7227-7280`)

Lantul e: **articol + politica de pret** (`CRM_POLITICI_PRET_ART`, deja documentat in raportul
anterior ca avand `PRET`/`PROC_TVAV`/`ID_VALUTA`, fara `CONT`) `->` **antetul politicii de pret**
(`CRM_POLITICI_PRETURI.ID_POL`, care are `ID_NOTA`) `->` **nota de vanzare CRM**
(`CRM_NOTE_VANZARI.ID_NOTA`, care are `ID_SET`) `->` **sablonul de nota contabila**
(`NOTE_CONTABILE.ID_SET`, care are `SCD`/`ASCD`/`SCC`/`ASCC`/`EXPLICATIE`/`CU_TVA`/`IN_VALUTA`).

Apoi, la scriere (`ff_...:7405-7437`):
```sql
CASE
  WHEN pack_facturare.ntip <= 20 or pack_facturare.ntip IN (...) THEN
    -- factura, factura roahotel
    V_SCD  := crs_rand_articol.scd;
    V_ASCD := NVL(crs_rand_articol.ascd, PACK_FACTURARE.GetAnaliticByGrupUtilizatori(...));
  WHEN pack_facturare.ntip in (28, 29) THEN
    -- aviz catre clienti debitori
    V_SCD  := '461'; ...
  ELSE
    -- aviz
    V_SCD  := '418'; ...
END CASE;

V_SCC  := crs_rand_articol.scc;
V_ASCC := NVL(crs_rand_articol.ascc, PACK_FACTURARE.GetAnaliticByGrupUtilizatori(...));
```
(`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:7407-7437`)

Pentru o factura normala (`ntip <= 20`), `V_SCD` e contul debitor din nota (tipic un cont de
creante, 411/etc.), iar `V_SCC` e contul creditor din nota — **acesta e efectiv contul de venit**
al liniei (707/704/706/708, in functie de cum a configurat contabilul nota respectiva), preluat
**direct din `NOTE_CONTABILE.SCC`**, fara nicio derivare din contul de stoc al articolului. Perechea
`V_SCD`/`V_SCC` (plus `ID_VENCHELT`, `ID_SECTIE`, `EXPLICATIE`, cota TVA) e trimisa la
`pack_facturare.scrie_nota(...)` (`ff_...:7452-7476`), care scrie randul in nota contabila
efectiva a vanzarii.

**Concluzie fata de ipoteza lui Marius**: mecanismul exista si rezolva exact problema — "de unde
stiu contul de venit al unei linii de vanzare, indiferent daca articolul e gestionabil sau nu" —
dar **nu e o corespondenta automata cont-stoc -> cont-venit**. E o **configurare manuala per
politica de pret**: fiecare politica de pret (`CRM_POLITICI_PRETURI`) e legata la o "nota de
vanzare" CRM (`CRM_NOTE_VANZARI`), care la randul ei e legata la un sablon de nota contabila
(`NOTE_CONTABILE`) cu perechea SCD/SCC fixata de un contabil. Politica de pret aplicata articolului
decide, indirect, contul de venit — nu clasa/valoarea contului de gestiune al articolului.

### Ecranul de configurare (unde se seteaza SCD/SCC)
`D:\ROA\ROAFACTURARE\COMUN\ferestre\frm_config_note_contabile.sc2` (+ varianta
`frm_config_note_contabile2007.sc2` pentru anii >= 2007, selectata in
`COMUN\programe\omeniu_initializari.prg:257-282`) e formularul din meniu "Configurare note
contabile". Clasa e `onote_contabile.vc2`, cu un grid `gridInregistrari` avand coloanele
`cScd`/`cAscd`/`cScc`/`cAscc` (`onote_contabile.vc2:2401-2435`) legate direct de
`cnote_contab.scd`/`.scc`/`.ascd`/`.ascc`, si salvare prin INSERT/UPDATE direct pe
`note_contabile(explicatie,scd,ascd,scc,ascc,ordine,cu_tva,ptva,id_set,in_valuta,...)`
(`onote_contabile.vc2:315-322`, `:486-493`). Deci **contabilul e cel care scrie manual perechea
SCD/SCC** (inclusiv contul de venit `SCC`) pentru fiecare `id_set`/nota, nu exista automatism care
sa deriveze `SCC` din contul de gestiune al articolului.

## 2. `NOM_ARTICOLE.CONT` — nu e restrans la clasa 3

- **Camp**: `Clb_tx_cont.Text_simplu1.ControlSource = "porec.cont"`, `MaxLength = 4`, eticheta
  `"Cont*"` (obligatoriu), buton de help cu tooltip `"Help - Planul de conturi (CTRL+ H)"` —
  `COMUN\clase\onom_articole.vc2:1058-1087`. Trimiterea catre "Planul de conturi" (nu catre un
  subset "conturi de stoc") sugereaza ca formularul asteapta orice cont valid, nu doar clasa 3.
- **Validare la Valid() al campului** (in alt formular generic de conturi, `onomenclatoare.vc2`, nu
  in cel de articole, dar foloseste aceeasi functie globala):
  ```
  PROCEDURE clb_cont.Text_simplu1.Valid
      IF !EMPTY(this.Value)
          lnVerificat = verific_cont(thisform.orec.cont)
          IF lnVerificat < 0
              RETURN 0
          ENDIF
      ENDIF
  ENDPROC
  ```
  (`COMUN\clase\onomenclatoare.vc2:3251-3258`)
- **`verific_cont`** (`COMUN\programe\oproceduri_comune.prg:2389-2415`):
  ```
  Procedure verific_cont
      Parameters tcCont, tlNoMessage
      lcSel = [SELECT cont from ] + GCS + [.vplcont_sintetic WHERE TRIM(cont) = ?pcCont and an = ?gnAn ]
      ...
      If Reccount('crs_verific') = 0
          lnSucces = -1
      Endif
      If lnSucces < 0 And !tlNoMessage
          amessagebox('Acest cont nu este definit in planul de conturi!', 0 + 48, 'Atentie')
      Endif
  Endproc
  ```
  Singura conditie e ca `cont` sa existe in `vplcont_sintetic` (planul de conturi sintetic al
  anului curent, `gnAn`) — **fara `LIKE '3%'`, fara `SUBSTR(cont,1,1) = '3'`, fara nicio alta
  restrictie de clasa**. O varianta identica exista si in
  `COMUN\programe\ooperatii_comune.prg:1307` (nu am comparat corp cu corp, dar semnatura e aceeasi).
- Nu exista `CHECK CONSTRAINT` pe `NOM_ARTICOLE.CONT` in `SCRIPTURI_CLAR` (cautare
  `CHECK.*CONT`/`constraint.*CONT.*check` — zero rezultate relevante), deci nici la nivel de
  baza de date nu exista o restrictie de clasa.
- Nu am gasit nicaieri in `COMUN` sau `ROAFACTURARE` o ramificare pe `Left(cont,1)`/
  `SUBSTR(cont,1,1)` aplicata specific campului `NOM_ARTICOLE.CONT` (cautare in
  `D:\ROA\ROAFACTURARE` si `D:\ROA\ROAFACTURARE\COMUN`) — singurul loc cu `SUBSTR(cont,1,1)` gasit e
  in `onomenclatoare.vc2:3647`, un filtru de grid pe planul de conturi general (tab-uri "1", "2",
  "3"... pentru navigare in plan), fara legatura cu articolele.

**Concluzie**: campul e validat generic (orice cont din planul de conturi al anului), fara
restrictie de clasa la nivel de UI sau DB. Asta confirma ce a spus Marius: un articol negestionabil
poate avea legitim un cont 6xx/7xx in `NOM_ARTICOLE.CONT`.

## 3. Unde se genereaza efectiv nota contabila a vanzarii

Raportul anterior cauta gresit literalii `707`/`704`/`706`/`708` (niciunul nu apare hardcodat — corect)
si a conchis ca nu exista mecanism in `pack_facturare`. De fapt **exista, dar e in `pack_facturare`,
nu intr-un pachet separat de contabilitate**:

- **Functia**: `pack_facturare.contabilizeaza_articol(detalii_articol VANZARI_DETALII_TEMP%ROWTYPE)`
  (`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:7182-7556`), apelata pe fiecare rand din
  `VANZARI_DETALII_TEMP` — vezi apelul `V_INCASAT_CALCUL := V_INCASAT_CALCUL +
  pack_facturare.contabilizeaza_articol(tab_detalii(i));` in `scrie_aviz_retur`
  (`ff_...:7148-7150`); acelasi tipar se repeta si in fluxul principal de facturare (nu doar in
  aviz-retur — semnatura si structura functiei arata ca acopera si `ntip <= 20`, adica factura
  propriu-zisa, prin `CASE ... WHEN pack_facturare.ntip <= 20 ...` la `ff_...:7409-7421`).
- **Sursa `SCD`/`SCC`**: vezi sectiunea 1 — cursorul `cursor_articol` (`ff_...:7227-7280`), pe baza
  politicii de pret a articolului (`detalii_articol.id_pol`), nu pe `VANZARI_DETALII.CONT`.
- **`VANZARI_DETALII.CONT` ramane folosit separat, doar pentru gestiune**: in aceeasi functie,
  `descarca_gestiune(...)` primeste explicit `detalii_articol.cont` ca parametru
  (`ff_...:7485-7507`, apelat cand `nscadere_stoc = 1 AND id_gestiune <> -1000 AND in_stoc = 1`) —
  acesta e contul de gestiune/stoc (371/301-303/357 etc., documentat in raportul anterior),
  folosit pentru randul de descarcare de gestiune (marfa iesita din stoc), complet independent de
  `V_SCD`/`V_SCC` calculate mai sus pentru randul de venit al vanzarii. **Cele doua conturi
  coexista pe aceeasi linie de vanzare, cu surse complet diferite**: unul (gestiune) vine din
  `NOM_ARTICOLE.CONT`/`STOC.CONT`/`NOM_GESTIUNI.CONT` (cf. raport anterior), celalalt (venit) vine
  din `NOTE_CONTABILE.SCC` via politica de pret.
- **Nu exista fallback/hardcodare** pentru `SCC`: daca `NOTE_CONTABILE` nu are un rand pentru
  `ID_SET`-ul politicii, `LEFT JOIN`-urile din `cursor_articol` produc `NULL` pe `SCC`/`SCD`
  (fara eroare explicita in acest cursor — spre deosebire de cazul `V_COMPUS`/politica lipsa la
  `ff_...:7293-7311`, care ridica `FACT-024`).

## 4. `ID_VENCHELT` / `NOM_VENIT_CHELTUIELI`

- **Nu are coloana de cont**: nicio `ALTER TABLE NOM_VENIT_CHELTUIELI ADD ... CONT` in
  `SCRIPTURI_CLAR` (cautare directa, zero rezultate) si nicio `CREATE TABLE NOM_VENIT_CHELTUIELI`
  in arhiva (tabelul predateaza 2009, inceputul arhivei `SCRIPTURI_CLAR` — la fel ca
  `NOTE_CONTABILE`, `CRM_NOTE_VANZARI`, `CRM_POLITICI_PRETURI`, pentru care nu exista `CREATE TABLE`
  in arhiva din acelasi motiv).
- **Structura vazuta din uz**: `NOM_VENIT_CHELTUIELI.ID_VENCHELT%TYPE` (tip declarat repetat in
  `pack_facturare`, ex. `ff_...:191`) si `ACT.ID_VENCHELT%TYPE` (`ff_...:6725`) — deci
  `ID_VENCHELT` e o coloana FK pe `ACT` (tabelul de note contabile efective) si pe `CRM_NOTE_VANZARI`
  / `CRM_POLITICI_PRET_ART` (vezi `NVL(B.ID_VENCHELT, D.ID_VENCHELT)` la `ff_...:7205`, unde `B` =
  `CRM_POLITICI_PRET_ART`, `D` = `CRM_NOTE_VANZARI` in cursorul comentat din pachet).
- **Cine il consuma**: `pack_facturare.contabilizeaza_articol` il rezolva cu prioritate similara
  contului: `NVL(pack_facturare.nid_venchelt, NVL(A.ID_VENCHELT, C.ID_VENCHELT))` (override global de
  sesiune -> articol/politica -> nota de vanzare) si il trimite ca parametru propriu catre
  `scrie_nota(...)` (`ff_...:7461`), **separat** de `SCD`/`SCC`. E deci o **a treia dimensiune**
  (clasificare venituri/cheltuieli) atasata randului de nota contabila, nu sursa contului insusi —
  raportul anterior avea dreptate sa il caracterizeze ca "o clasificare, nu un cont", desi nu
  urmarise consumatorul pana la capat.
- Numele `NOM_VENIT_CHELTUIELI` si folosirea alaturi de `SCD`/`SCC`/`ID_SECTIE` sugereaza un
  centru de venituri/cheltuieli pentru raportare (posibil situatii financiare pe sectii/centre de
  cost), nu un mecanism alternativ de determinare a contului 7xx.

## Neverificat

- **Structura completa (toate coloanele) a `NOTE_CONTABILE`, `CRM_NOTE_VANZARI`,
  `CRM_POLITICI_PRETURI` si `NOM_VENIT_CHELTUIELI`**: niciuna nu are `CREATE TABLE` in
  `SCRIPTURI_CLAR` (arhiva incepe 2009, tabelele sunt mai vechi). Coloanele folosite in cod sunt
  confirmate (`SCD`/`ASCD`/`SCC`/`ASCC`/`EXPLICATIE`/`CU_TVA`/`IN_VALUTA`/`ID_SET` pe
  `NOTE_CONTABILE`; `ID_NOTA`/`ID_SET` pe `CRM_NOTE_VANZARI`; `ID_NOTA`/`ID_POL` pe
  `CRM_POLITICI_PRETURI`; `ID_VENCHELT` pe `NOM_VENIT_CHELTUIELI`), dar lista completa ar necesita
  interogarea schemei Oracle live (`DESC NOTE_CONTABILE` etc.) sau un export DDL mai vechi decat
  2009, in afara bugetului acestei cercetari.
- **Continutul efectiv al `NOTE_CONTABILE.SCC`** pentru notele configurate curent (adica ce conturi
  707/704/706/708 sunt de fapt setate, si daca fiecare politica de pret are o nota configurata) —
  ar necesita interogarea datelor din schema Oracle live, nu doar codul static.
- **Daca `contabilizeaza_articol` e chiar apelata pe fluxul principal de facturare** (nu doar din
  `scrie_aviz_retur`) — am dedus asta din `CASE ... ntip <= 20 ...` (factura normala tratata explicit
  in functie), dar nu am urmarit *toti* apelantii ei in fisier (fisierul are 17000+ linii; cautarea
  `pack_facturare.contabilizeaza_articol` ar trebui repetata exhaustiv daca se doreste certitudine
  completa pe toate punctele de intrare — facturare avans, deviz, retail etc.).
- **Comportamentul cand `NOTE_CONTABILE`/`CRM_NOTE_VANZARI` lipsesc pentru o politica de pret**:
  cursorul foloseste `LEFT JOIN`, deci `SCD`/`SCC` ar ajunge `NULL` fara eroare explicita in acest
  punct — nu am verificat daca exista o validare ulterioara (la `scrie_nota` sau la commit-ul notei)
  care sa blocheze o nota cu cont `NULL`.