roafacturare/docs/cercetare/cont_venit_corespondente.md

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:

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):

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.