comun/docs/cercetare/rec_integrari.md

# Cercetare: integrare CONTRACTE, politici de preturi, nomenclator ca lista de preturi

Metoda: `vfp_symbols.ps1` (cache text ROAFACTURARE deja la zi) + Grep pe `.prg`/`.vc2`/`.mn2`.
Fapte cu `fisier:linie`; ipoteze marcate `IPOTEZA:`.

## SUBIECT A - Integrare pagina CONTRACTE (todo #10)

### 1. Unde exista azi contractele

Produs separat, working copy completa: `D:\ROA\ROACONTRACTE` (`.git` + `.svn`, `roaContracte.pjx`,
`roacontracte.exe`). Structura: `Clase\` (`ofundal.vcx`, `onom_clienti.vcx`, `oOptiuni.vcx`,
`roaclienti.vcx`, `ferestre_contracte.vcx` - probabil formularele CRUD de contracte),
`Ferestre\`, `Programe\`, `Rapoarte\`, `Meniuri\`, `COMUN\` (propria copie a librariei partajate),
`Teste\`, `docs\`.

**Important**: ROAFACTURARE NU e izolat de contracte azi - are deja o integrare de facturare
partiala "pe baza de contract" (vezi punctul 4), care citeste direct din schema Oracle a
ROACONTRACTE prin view-uri (`vcontracte`, `fact_vcontracte`, `tipuri_contracte`), fara pagina de
editare. `ferestre_contracte.vcx` din ROACONTRACTE contine probabil formularele CRUD care ar
trebui aduse in ROAFACTURARE (nu au fost deschise/citite - binar, necesita conversie separata daca
se trece la implementare).

Exista deja urme ale unei integrari partiale de UI in ROAFACTURARE:
- `Meniuri\contracte.mnx`/`.mn2` (`D:\ROA\ROAFACTURARE\Meniuri\contracte.mn2:1`) - NU e un meniu de
  administrare contracte, ci un shortcut-popup cu 3 optiuni de facturare ("Factura fiscala lei /
  Invoice / Factura fiscala valuta") - cf. continut citit integral.
- `Grafice\icon_contracte1.png`, `icon_contracte2.png`, `Grafice\Originale\contracte.png` -
  iconite deja pregatite in ROAFACTURARE.

### 2. Cum e integrata azi COMENZI in ROAFACTURARE (sablonul de urmat)

COMENZI **nu** e produs separat legat prin exe, ci cod montat direct in ROAFACTURARE din
`COMUN\` (librarie partajata `gitea.romfast.ro:romfast/comun.git`, cf. CLAUDE.md). Exista si un
produs stand-alone `D:\ROA\ROACOMENZI` (cu `.pjx` propriu), dar in ROAFACTURARE comenzile sunt
o **pagina/panou montat direct in formularul principal (fundal)**, nu un exe separat lansat.

Reteta pas cu pas (comenzi ca model pentru contracte):

1. **Clasa container** `ct_comenzi` din `COMUN\clase\ocomenzi.vcx` (`.vc2` cache:
   `COMUN\clase\ocomenzi.vc2`) - contine formulare/containere CRUD comenzi
   (`frm_optiuni_comenzi`, cursoare `vcomenzi_elemente` etc.).
2. **Montare in formularul principal**: containerul e plasat ca obiect copil in
   `Clase\ofundal_facturare.vc2` (form fundal), cu comentariul `< END OBJECT:
   ClassLib="..\comun\clase\ocomenzi.vcx" BaseClass="container" />` in jurul liniei
   `Clase\ofundal_facturare.vc2:831`; obiectul se numeste `lb_comenzi`
   (`Clase\ofundal_facturare.vc2:824`).
3. **Butoane de actiune** ("Cw" = clase de tip buton-cu-drept, vezi punctul 3) legate la proceduri
   business, ex. `Page2.Cw3.do_actiune` -> `DO facturare_comenzi IN oproceduri_facturare.prg`
   (`Clase\ofundal_facturare.vc2:899-902`).
4. **Inregistrare in `Programe\roafacturare.prg`** (entry point):
   - `SET CLASSLIB TO ocomenzi ADDITIVE` sub comentariul `*** COMENZI`
     (`Programe\roafacturare.prg:180-181`);
   - `SET PROCEDURE TO orap_comenzi.prg / onom_comenzi.prg / update_comenzi.prg ADDITIVE`
     (`Programe\roafacturare.prg:239-242`), tot sub `*** COMENZI`;
   - variabile module: `PRIVATE pocomenzi,pocomenzielemente,polucrari,pocomenzi2,polucrarielemente`
     (`Programe\roafacturare.prg:246-247`).
   - Toate cele 3 `.prg` (`orap_comenzi.prg`, `onom_comenzi.prg`, `update_comenzi.prg`) si clasa
     `ocomenzi.vcx`/`.vct` locuiesc fizic in `COMUN\programe\` / `COMUN\clase\`, dar sunt
     inregistrate ca membri ai proiectului `roafacturare.pjx` (confirmat prin Grep pe `.pjx`:
     `COMUN\clase\ocomenzi.vcx`, `COMUN\programe\orap_comenzi.prg` etc. apar in el).
5. **Business logic de facturare din comenzi**: `Procedure facturare_comenzi` in
   `COMUN\programe\oproceduri_facturare.prg:139-141` - un simplu `factureaza(3)` (tip document 3
   = "din comanda", motorul central `factureaza()` face restul).
6. **Meniu**: nu exista `Meniuri\comenzi.mnx` separat in ROAFACTURARE - comenzile nu au intrare de
   meniu proprie, ci doar butonul `Cw3` de pe pagina fundal (Page2 = "Facturare"). Contractele au
   deja `Meniuri\contracte.mnx` dar cu alt continut (shortcut factura), deci pentru pagina noua de
   contracte ar trebui fie extins acest fisier, fie creat altul.

Concluzie sablon: pentru CONTRACTE ar insemna (a) o clasa container tip `ct_contracte` (posibil
adaptata din `ferestre_contracte.vcx` al ROACONTRACTE, mutata/duplicata in `COMUN\clase\`), (b)
montarea ei ca obiect in `ofundal_facturare.vc2` langa `lb_comenzi`, (c) inregistrare `SET
CLASSLIB`/`SET PROCEDURE` in `roafacturare.prg` sub un bloc nou `*** CONTRACTE`, (d) adaugare in
`roafacturare.pjx`.

### 3. Mecanismul de DREPTURI pe obiecte

Sursa: `COMUN\programe\acces_meniu.prg` (fisier citit integral).

- **Sursa de date**: view Oracle `contafin_oracle.vdef_util_obiecte`, interogat cu
  `select cheie,id_firma from contafin_oracle.vdef_util_obiecte where id_util=?gnIdUtil and
  id_program=?gnIdProgram and id_firma=?gnIdFirma` (`acces_meniu.prg:29-31`), rezultat in cursorul
  `crsdrepturi` (o singura coloana cheie relevanta: `cheie`, string).
- **Codificarea cheii**: concatenare de "caractere de nivel" - `Chr(lnKey)` pentru fiecare nivel de
  pageframe/pagina (`dezactiveaza_obiecte_pageframe`, `acces_meniu.prg:103-165`, recursiv pe
  subpageframe-uri), plus un cod de 2 cifre pentru fiecare buton `Cw*`:
  `lcCheie = lcKey + Padl(Alltrim(Str(.Objects(l).nid_cw)), 2, '0')` (`acces_meniu.prg:138`).
  Fiecare obiect `Cw*` are proprietatea `nid_cw` (numarul lui in cadrul paginii) si la runtime i se
  seteaza `ccheie` (`acces_meniu.prg:140`) si `coptiuni_active` (lista de operatii CRUD permise,
  citita din caracterele urmatoare cheii - `acces_meniu.prg:141-149`). Butonul apeleaza
  `.Objects(l).activeaza()` / `.dezactiveaza()` in functie de gasire (`acces_meniu.prg:150-152`).
- **Pentru imagini/iconite** (nivel diferit, folosit pe alte forme): proprietate `ccod` pe obiect
  (`acces_meniu.prg:48`), aceeasi logica de cautare in `crsdrepturi`.
- **Cod de meniu (pad-uri)**: `GetAccesByCod(tcCod, tcAccesDefault)` (`acces_meniu.prg:236-276`)
  cauta o cheie explicita (cod optiune meniu, ex. "ZA01") in `crsdrepturi` si intoarce lista de
  operatii permise (ex. "1;2;3;4").
- **Punct de intrare**: `verifica_drepturi(tcObiectFundal, tcPageFrame)`
  (`acces_meniu.prg:9-15`) apelat din formularul fundal (`Ferestre\fundal.sc2:699`:
  `verifica_drepturi('gofundal','_pgfrmbase1')`), care incarca `crsdrepturi` o singura data per
  firma (cache in memorie, `citeste_drepturi`, `acces_meniu.prg:17-37`) si dezactiveaza in cascada
  paginile/butoanele/meniurile fara drept.
- **Administrare drepturi** (unde se declara catalogul de obiecte si se atribuie pe grupuri):
  `COMUN\clase\drept_grupuri.vc2` - `frm_grupuri`, apel catre pachetul Oracle
  `PACK_DREPTURI.grupdreptmodproc` (`COMUN\clase\drept_grupuri.vc2:39`) si `citeste_drepturi
  (loRec.id_grup)` (`COMUN\clase\drept_grupuri.vc2:205`).

IPOTEZA: catalogul efectiv de "obiecte disponibile pentru ROAFACTURARE" (denumirile/codurile
`nid_cw`/`ccod`/coduri de meniu, ex. cele pentru COMENZI) e definit **partial in designerul VFP**
(proprietatea `nid_cw` seteaza pe fiecare buton la design-time in `.scx`/`.vcx`) si **partial
server-side** in schema Oracle `contafin_oracle` (tabelul din spatele view-ului
`vdef_util_obiecte`, populat probabil printr-un script de instalare/migrare, nu vazut in sursa
VFP). Pentru "comasarea" drepturilor ROACONTRACTE + ROAFACTURARE mentionata in cerere, ar trebui
inspectat acest tabel server-side (in afara sursei VFP disponibile aici) plus alocarea de noi
`nid_cw` pentru butoanele noi de contracte, fara sa coincida cu cele deja folosite de COMENZI/
lista de preturi/avize pe aceeasi pagina.

Exemplu concret COMENZI: butonul `Page2.Cw3` (facturare din comenzi) foloseste automat cheia
`<cheie_pagina>+'03'` (Cw3 => `nid_cw=3`); pentru un buton nou de contracte pe aceeasi pagina ar
trebui un `nid_cw` neutilizat (ex. 11+, dat fiind ca Page2 are deja Cw1..Cw9 conform
`Clase\ofundal_facturare.vc2:882-926`).

### 4. Facturarea pe baza de comanda / pe baza de contract

**Comanda -> factura**: `Procedure facturare_comenzi` (`COMUN\programe\oproceduri_facturare.prg:
139-141`) => `factureaza(3)`. Cautarea comenzii disponibile pentru facturare:
`Function caut_comanda_gestiune` (`COMUN\programe\oproceduri_facturare.prg:1961-1983`), citeste
din view-ul `vcomenzi` (`... FROM ] + gcS + [.vcomenzi`), filtru
`facturat = 0 and interna = 3 ... ` (linia 1977).

**"Pe baza de contract" EXISTA DEJA**, mai complet decat comenzile pe alocuri:
- `Procedure facturare_contracte(tcTip)` (`COMUN\programe\oproceduri_facturare.prg:119-136`) -
  primeste tipul de document ("FACTURA LEI"/"INVOICE"/"FACTURA VALUTA") si apeleaza
  `factureaza(2)`/`factureaza(6)`/`factureaza(52)`.
- Buton pe pagina fundal: `Page2.Cw2.do_actiune` (`Clase\ofundal_facturare.vc2:886-897`) - meniu
  `xmenu` cu cele 3 optiuni, cheama `facturare_contracte`.
- **Cautare contract**: `Function caut_contract_facturare(tnIdPart, tcSirTipFacturare)`
  (`COMUN\programe\oproceduri_facturare.prg:1986-2021`) - citeste din view-ul `fact_vcontracte`
  (`select id_ctr, contract, numar, data, denumire, scadenta_incasare, opt_facturare,
  text_standard, afisare_scadenta FROM fact_vcontracte`, linia 2001), filtrat pe
  `opt_facturare in (...)` si `id_part`.
- **Alegerea contractului la factura**: `frm_date_factura.do_cauta_contract`
  (`COMUN\clase\ofacturare.vc2:9067-9115`) si `frm_date_aviz.do_cauta_contract`
  (`COMUN\clase\ofacturare.vc2:7049-7051`) apeleaza `caut_contract_facturare`.
- **Editorul de articole pe factura** are un tab/grid dedicat contractelor:
  `frm_facturare_articole` cu controale `grd_contracte`, `cb_contracte` (combobox cu ratele /
  contractele), populate din cursorul `crscontracte` (`COMUN\clase\ofacturare.vc2:15069-15107` si
  in jur). Optiunea `opt_facturare` din `fact_vcontracte`/`crsfactura` marcheaza randurile "din
  contract" (`COMUN\programe\oproceduri_facturare.prg:176-177`, `Inlist(opt_facturare,1,2)` in alt
  context legat de seturi).
- **Aviz pe baza de contract**: exista si un tip de aviz "26 - catre clienti din contract"
  (`COMUN\programe\oproceduri_facturare.prg:207`, enumerat si in `caut_avize`,
  `COMUN\programe\oproceduri_facturare.prg:2045`), apelat din `emitere_aviz_clienti(tnTip=3)`.

Concluzie: **motorul de facturare din contract e deja complet functional** in ROAFACTURARE (citire
din schema ROACONTRACTE prin view-uri Oracle `vcontracte`/`fact_vcontracte`/`tipuri_contracte`).
Ce lipseste conform cererii e (a) o **pagina de editare CRUD a contractelor** in ROAFACTURARE
(azi doar in exe-ul separat ROACONTRACTE) si (b) **rapoarte de contracte** in ROAFACTURARE, plus
(c) unificarea drepturilor. Nu a fost gasit niciun raport de contracte in
`ROAFACTURARE\Rapoarte\` (glob `*contract*` nu a dat `.frx` in Rapoarte, doar meniu/iconite).

---

## SUBIECT B - Politici de preturi (todo #11)

### 5. Unde sunt azi definite/editate

Produs separat, mic, dedicat: `D:\ROA\ROAPRETURI` (`.pjx` propriu, `roapreturi.exe`). Structura:
`Programe\onom_preturi.prg`, `Programe\update_preturi.prg`, `Programe\update_nomenclator.prg`,
`Clase\opreturi.vcx`, `Clase\onom_preturi.vcx`, `Clase\ofundal_preturi.vcx`,
`Clase\ofundal_roapreturi.vcx`, `Ferestre\fundal.scx`. (Continutul acestor clase nu a fost convertit
in text - ROAPRETURI nu are un cache text propriu generat in aceasta sesiune; doar structura de
fisiere a fost inspectata.)

Interfata de editare pare sa fie un produs desktop de sine statator, distinct de ROAFACTURARE si de
ROACONT, focalizat strict pe politici/liste de preturi si pe actualizarea nomenclatorului
(`update_nomenclator.prg` sugereaza ca ROAPRETURI scrie si in nomenclatorul comun de articole).

### 6. Tabele/view-uri implicate (identificate din ROAFACTURARE)

Din codul ROAFACTURARE care CITESTE politici de preturi (nu editeaza), gasite:
- `vcrm_politici_preturi` - view folosit in cautare dupa drepturi utilizator
  (`COMUN\clase\baza.vc2:10087`, `:10157`, `:10502-10512`). Interogare efectiva:
  `select nume_lista_preturi, id_pol from crm_vpolpretcurutil` (`COMUN\clase\baza.vc2:10504`) -
  deci exista si view-ul `crm_vpolpretcurutil` ("politica de pret curenta pentru utilizator"),
  cheie `id_pol`.
- `vvanzari_detalii` - contine coloana `nume_lista_preturi` folosita in rapoarte de marfa
  (`COMUN\clase\configurare.vc2:3915-3972`, `frm_raport_marfa`).
- Meniu dedicat facturarii pe lista de preturi: `Meniuri\politica.mnx`/`.mn2`/`.MPR` in
  ROAFACTURARE; procedura `facturare_lista_de_preturi` = `Do politica.mpr`
  (`COMUN\programe\oproceduri_facturare.prg:113-116`), buton `Page2.Cw1.do_actiune`
  (`Clase\ofundal_facturare.vc2:882-884`).
- Prefixul `crm_`/`CRM` in numele tabelelor/view-urilor (`vcrm_politici_preturi`,
  `crm_vpolpretcurutil`) sugereaza schema/modul Oracle numit "CRM", separat de schema principala
  de facturare (`gcS`). IPOTEZA: politicile de pret sunt un modul Oracle transversal (folosit si
  de ROAGEST, ROAPRETURI, ROACONTRACTE), nu proprietatea exclusiva a unui singur produs VFP.
- Comenzile (ROACOMENZI/`ocomenzi.vcx`) au propriul mecanism de asociere pret-din-comanda:
  globale `gnIdPoliticaPret`, `gnId_lista_preturi_PV` (`Programe\roafacturare.prg:467,469`),
  folosite si in `frm_optiuni_comenzi` (`COMUN\clase\ocomenzi.vc2:6488-6686`, variabila
  `gnID_LISTA_PRETURI_PV` = politica de pret "de productie" folosita la generarea automata a
  comenzilor). Cursorul de articole al comenzii are coloanele `id_pol`, `nume_lista_preturi`,
  `pret`, `pret_cu_tva`, `ptva` direct in el (`COMUN\clase\ocomenzi.vc2:1227-1229`, cursor creat
  din view-ul `vcomenzi_elemente`).

Nu a fost gasita nicio schema DBF/DDL explicita pentru "politici de preturi" / "liste de preturi"
in sursa VFP (tabelele reale sunt Oracle, definite server-side; VFP le vede doar prin view-uri
enumerate mai sus). N-a fost identificat un tabel separat de "note contabile asociate politicii de
pret" in codul cercetat - contul contabil de vanzare pare sa vina din nomenclatorul de articole
(`nom_articole.cont`, vezi punctul 10), nu dintr-o tabela separata legata de politica.

### 7. Ce foloseste ROAFACTURARE azi din aceste date

- **Facturare pe lista de preturi** (`Do politica.mpr`) - flux complet de vanzare pe baza unei
  politici de pret selectate (analog cu vanzarea din stoc/comenzi/contract), tip document
  distinct in motorul central `factureaza()`.
- **Cautare/afisare politica dupa drepturi utilizator** (`COMUN\clase\baza.vc2:10502-10512`) -
  ROAFACTURARE citeste `crm_vpolpretcurutil` pentru a limita politicile vizibile la cele pe care
  utilizatorul are drept (alt strat de drepturi, distinct de `acces_meniu.prg` - specific pe
  politici de pret, posibil gestionat tot server-side prin pachetul `PACK_DREPTURI`).
- **Rapoarte de vanzari pe lista de preturi** (`frm_raport_marfa`,
  `COMUN\clase\configurare.vc2:3915-3972`) - grupare/însumare pe `nume_lista_preturi`.
- Nu editeaza politici/liste - doar le CITESTE si le foloseste ca sursa de pret la facturare/
  raportare. Editarea (adaugare politica, adaugare articole in politica, preturi) ramane in
  ROAPRETURI.

Concluzie pentru migrare: ce ar trebui **mutat efectiv in ROAFACTURARE** (conform cererii - "se
folosesc numai in programul ROAFACTURARE") e interfata de editare (`opreturi.vcx`/
`onom_preturi.vcx` din ROAPRETURI), nu structura de date (Oracle, deja partajata/citita corect).
Rapoartele si drepturile pe liste de preturi trebuie de asemenea aduse ca pagina/panou in
ROAFACTURARE, dupa acelasi sablon COMENZI descris la punctul 2.

---

## SUBIECT C - Nomenclatorul de articole ca lista de preturi virtuala (todo #12)

### 8. Structura tabelei de nomenclator

Tabela Oracle **`catalog_articole`**, expusa prin view-ul **`vnom_articole`** (si `vnom_articole2`
pentru un al doilea tip - vezi `nom_articole2_nou`, `COMUN\programe\onomenclatoare.prg:1376-1396`,
tabela `catalog_articole2`).

Coloane identificate din interogari/scatter (nu e o lista exhaustiva - vin din SELECT-uri
punctuale, nu din DDL):
`id_articol, denumire, codmat, codmatf (cod furnizor), codbare, um, grupa, subgrupa, id_grupa,
id_subgrupa, dnf, cont (cont contabil, 3-4 caractere), acont, inactiv, sters, in_stoc, in_crm,
tip (ex. 1 = manopera pt. ROAACNPRO), id_part/partener (pt. articole legate de furnizor/client)`.
Surse: `COMUN\clase\ocriterii.vc2:1531` (`select denumire, codmat, um, grupa, subgrupa, id_grupa,
id_subgrupa, dnf, cont, acont, inactiv, id_articol from vnom_articole`),
`COMUN\programe\onomenclatoare.prg:1345-1353` (`in_crm`, `in_stoc`, `tip`),
`COMUN\clase\ointroduceri.vc2:9631` (`in_stoc, cont`).

**Nicio coloana de pret** nu a fost gasita direct pe `nom_articole`/`catalog_articole` (grep
`pret_v|pretv|pret_lista` in `onomenclatoare.prg` = fara rezultate; scatter-ul din
`nom_articole_nou` nu populeaza niciun camp de pret). Confirma punctul 11 mai jos.

**Formular de editare**: `frm_catalog_articole` (grid/cautare) si `frm_catalog_articole_nou`
(fisa), ambele in `COMUN\clase\onom_articole.vc2` (`:531-599`, `:1655-1733`), salvare prin
`cus_odata_catalog_articole.salvare` si `Adauga_Modifica_Inregistrare('catalog_articole', ...)`
(`COMUN\programe\onomenclatoare.prg:1367,1443`). Deschidere din meniu:
`Procedure viz_catalog_articole` (`COMUN\programe\oproceduri_articole.prg:62-122`).

**Important pentru subiectul B/C**: `nom_articole_nou` (`COMUN\programe\onomenclatoare.prg:
1343-1353`) marcheaza acelasi articol cu `in_crm = 1` cand programul curent e ROAPRETURI sau
ROACONTRACTE, respectiv `in_stoc = 1` in rest (inclusiv ROAFACTURARE) - **nomenclatorul de
articole e deja UNIC/PARTAJAT** intre ROAFACTURARE, ROAPRETURI, ROACONTRACTE si ROAACNPRO (aceeasi
tabela `catalog_articole`), flagurile `in_stoc`/`in_crm`/`tip` fiind doar clasificari de
utilizare, nu tabele separate. Asta simplifica mult todo #12: nomenclatorul nu trebuie replicat,
doar completat cu campuri de pret/tva/cont-vanzare si folosit direct ca sursa de pret la
facturare.

### 9. Mecanismul actual de "lista de articole din stoc ca lista de preturi virtuala"

Confirmat: e mecanismul de **"vanzare din stoc/gestiune"**, un tip de facturare paralel cu
"lista de preturi"/"contract"/"comanda", identificat prin variabila globala `gnTipGest`:
- `Procedure vanzare_materii_prime` -> `gnTipGest = 2`, `Do vanzare1.mpr`
- `Procedure vanzare_produse` -> `gnTipGest = 4`, `Do vanzare2.mpr`
- `Procedure vanzare_marfa_pret_achi` -> `gnTipGest = 5`, `Do vanzare3.mpr` (marfa la pret de
  achizitie)
- `Procedure vanzare_marfa_pret_vanz` -> `gnTipGest = 6`, `Do vanzare4.mpr` (marfa la pret de
  **vanzare**)
- `Procedure vanzare_marfa_pret_achi_vanz` -> `gnTipGest = 7`, `Do vanzare5.mpr`
(toate in `COMUN\programe\oproceduri_facturare.prg:1505-1534`; butoane `Page2.Cw5..Cw9` in
`Clase\ofundal_facturare.vc2:908-926`).

Gestiunile disponibile per tip se filtreaza prin `Procedure selecteaza_gestiuni`
(`COMUN\programe\oproceduri_facturare.prg:1536-1565`), pe view-ul `vnom_GESTIUNI` filtrat
`nr_pag = ?gnTipGest`, plus un al doilea nivel de drept pe gestiuni (view-urile
`vgest_coresp_grupe_gestiuni` / `vgest_coresp_util_grupe`, linia 1552-1555) - deci "lista de
preturi virtuala" = stocul unei gestiuni, cu control de acces pe gestiune (nu pe politica de
pret).

Motorul de scriere: `Function oscrie_vanzare_din_stoc` in `COMUN\programe\ofacturare_stoc.prg:
104-...`, apelat din `initializeaza_vanzare_din_stoc` (`ofacturare_stoc.prg:31-99`). Comentariu
explicit in cod: *"in vanzari_detalii scriu pretul cu tva daca am marfa la pret de vanzare, daca
nu scriu pretul de vanzare fara tva"* (`ofacturare_stoc.prg:107`), cu
`lnPretCuTva = Iif(INLIST(gnTipGest,6,7), 1, 0)` (linia 111) - deci flagul "pret cu TVA" e
determinat de TIPUL de vanzare din stoc ales (6/7 = la pret de vanzare), nu citit dintr-o coloana
a nomenclatorului.

Cursorul-cheie `crsvanztemp` (`ofacturare_stoc.prg:137-139`) are coloanele:
`id_articol, Pret, proc_tvav, id_jtva_coloana, cantitate, discount_unitar, id_gestiune, Cont
(c4), pret_cu_tva, serie, id_valuta, codmat, Curs, multiplicator, pret_achizitie, pretd,
id_valuta_d, id_rul_aux, taxcode, lot`.

### 10. Lantul de cod: pret, valuta, %TVA, pret_cu_tva, cont vanzare - la facturare "din stoc"

Din structura `crsvanztemp` (punctul 9) rezulta explicit lantul folosit azi cand se factureaza
"virtual" din stoc (echivalentul cerut pentru nomenclator-ca-lista-de-preturi):
- **Pret**: coloana `Pret` in `crsvanztemp`, luata din inregistrarea de gestiune/stoc (miscarea de
  intrare), nu din nomenclator - `pret_achizitie` separat pentru pretul de achizitie.
- **Valuta**: `id_valuta`, `Curs`, plus varianta in alta valuta `pretd`/`id_valuta_d` (pret dublu,
  pentru afisare in a doua valuta).
- **%TVA**: `proc_tvav` + `id_jtva_coloana` (coloana de defalcare TVA in jurnal) + `taxcode` (cod
  fiscal pt. integrari, ex. eFactura).
- **Flag pret_cu_tva**: `pret_cu_tva` in cursor, calculat din `gnTipGest` (`ofacturare_stoc.prg:
  111`), NU citit dintr-o coloana persistenta a articolului.
- **Cont vanzare (echivalent 4111=7xx)**: coloana `Cont c(4)` in `crsvanztemp` - cont contabil pe
  4 caractere (ex. "707x"/"701x"), scris explicit in cursor la nivel de linie de vanzare. Sursa lui
  cea mai probabila (nu confirmata cu linie exacta de SELECT in aceasta cercetare, cursorul e
  populat mai jos in fisier, dincolo de zona citita) e coloana `nom_articole.cont` (confirmata ca
  existenta la punctul 8) sau contul gestiunii (`nom_gestiuni`) - **IPOTEZA**: trebuie verificat
  punctual restul lui `oscrie_vanzare_din_stoc` (fisierul continua dupa linia 140, necitit
  integral in aceasta trecere) pentru sursa exacta linie-cu-linie a lui `Cont`.

Pentru comparatie, la facturarea pe **lista de preturi/politica** (nu pe stoc), pretul/valuta/TVA
vin din politica de pret (view `crm_vpolpretcurutil`/`vcrm_politici_preturi`, punctul 6), deci
lantul e diferit dupa tipul de facturare ales (`gnTipGest` vs. `id_pol`).

### 11. Coloane de pret existente/partial folosite in nomenclator

**Nu exista azi nicio coloana de pret pe `nom_articole`/`catalog_articole`** (cautare explicita
fara rezultate). Exista insa deja doua campuri reutilizabile direct pentru scenariul din cerere:
- `cont` (cont contabil de vanzare/achizitie, deja pe articol - vezi punctul 8) - poate fi folosit
  ca "nota contabila" fara tabel separat.
- Flagurile `in_stoc` / `in_crm` - clasifica deja fiecare articol dupa modul de utilizare (stoc
  vs. politica de pret / CRM), un precedent direct pentru un viitor flag suplimentar de tipul
  "articol cu pret propriu in nomenclator" daca se implementeaza todo #12.

Nu au fost gasite coloane de tipul `pret`, `pret_vanzare`, `valuta_pret`, `ptva` direct pe
nomenclator - toate preturile de vanzare vin azi fie din politici de pret (Oracle, schema CRM),
fie din miscarile de gestiune/stoc (nu din articolul insusi). Implementarea todo #12
("nomenclatorul direct ca lista de preturi, fara politica + nota contabila asociate") ar necesita
adaugarea a cel putin: pret (+valuta), procent TVA, flag pret_cu_tva pe `catalog_articole`/
`nom_articole` - camp nou, nu o coloana ascunsa deja existenta.

---

## Rezumat surse cheie (fisier:linie)

- Sablon COMENZI: `Programe\roafacturare.prg:180-181,239-247`; `Clase\ofundal_facturare.vc2:
  760-926`; `COMUN\clase\ocomenzi.vc2`.
- Drepturi: `COMUN\programe\acces_meniu.prg` (tot fisierul, 306 linii).
- Facturare contract: `COMUN\programe\oproceduri_facturare.prg:119-136,1986-2021`;
  `COMUN\clase\ofacturare.vc2:9067-9115,15069-15107`.
- Politici de pret: `COMUN\clase\baza.vc2:10087,10157,10453-10512`;
  `COMUN\programe\oproceduri_facturare.prg:113-116`.
- Vanzare din stoc (lista virtuala): `COMUN\programe\oproceduri_facturare.prg:1505-1534`;
  `COMUN\programe\ofacturare_stoc.prg:31-140`.
- Nomenclator articole: `COMUN\programe\onomenclatoare.prg:1302-1373`;
  `COMUN\clase\onom_articole.vc2:531-599,1655-1733`.