comun/docs/cercetare/valuta_si_curs.md

Cercetare: poDate.in_valuta, Clb_zi_curs si cele doua concepte de valuta

Investigatie read-only (fara editari, fara git_sync.ps1/txt2vcx.ps1, fara commit). Sursa: cache text .vc2/.prg din COMUN\clase\ofacturare.vc2, COMUN\programe\ofacturare.prg, COMUN\programe\ofacturare_comun.prg, COMUN\programe\ofacturare_stoc.prg, COMUN\programe\oproceduri_curs.prg, plus pachetul Oracle D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql (copie pe disc, alta numerotare decat baza). Reutilizeaza si confirma cercetari anterioare din docs\cercetare\rec_cale_vanzari_detalii.md si docs\cercetare\rec_consumatori_vanzari.md.

---

1. poDate.in_valuta — unde se seteaza si din ce

Concluzie: in_valuta e determinat o singura data, la Init, exclusiv din tipul documentului (tnTip) plus o lista fixa de id_set — niciodata din alegerea manuala a unei valute in antet si niciodata resetat ulterior. E o proprietate a tipului de factura (Invoice / credit note / retur valuta / factura fiscala valuta pe contract), nu a faptului ca articolele au preturi in valuta.

Dovezi:

• Valoare implicita 0: COMUN\programe\ofacturare_comun.prg:165 (in_valuta = 0, in blocul de proprietati al obiectului poDate).
• Singurul loc care il seteaza pe 1, in Procedure Init:

  ofacturare_comun.prg:248-250
  If Inlist(tnIdSet,223,225,226,227,271) OR INLIST(m.tnTip, 5,6,7,9,10,52)
      .in_valuta = 1
  Endif
  

• Legenda tipurilor (comentariu din frm_date_factura.Init), ofacturare.vc2:9571-9582: 1=lista preturi, 2=contract, 3=comanda, 4=aviz, 5=Invoice lista preturi, 6=Invoice contract, 7=credit note, 8=retur lei, 9=retur valuta, 48=avize valoric, 52=Factura fiscala valuta contract. Tipul 10 nu are comentariu explicit in acest bloc (adaugat separat, v2.0.56, ca variatie de tip 1/5).
• Nicio alta cale de scriere pe in_valuta in .vc2/.prg din COMUN — verificat cu grep (\.in_valuta\s*=\s*[01]) pe intreg ofacturare.vc2 si ofacturare.prg: restul potrivirilor sunt toate citiri (If poDate.in_valuta = 1 ...), nu atribuiri. ofacturare_stoc.prg:549 (poDate.in_valuta = in_valuta) e o cale alternativa (facturare "din stoc") care primeste parametrul in_valuta deja calculat in amonte, cu aceeasi semantica.
• Consecinta directa, confirmata de cod: alegerea manuala a unei valute pentru document (control ct_clb_valuta) nu poate schimba in_valuta — controlul insusi e eliminat din formular cand in_valuta = 0 (ofacturare.vc2:9725-9728), deci userul nu are cum sa-l "aleaga" pe o factura care nu e deja de tip valuta.

---

2. Campul „Data curs valutar" (Clb_zi_curs) — unde e definit si cand e eliminat azi

Concluzie: campul e eliminat doar pentru facturi de retur (tip 8 sau 9), niciodata pe baza de in_valuta. Da, azi campul apare si pe facturile in lei (in_valuta=0) de orice alt tip — comportament confirmat explicit prin simetrie de cod: imediat dupa blocul de retur, exista un bloc separat care elimina ct_clb_valuta cand in_valuta=0, dar echivalentul lipseste pentru clb_zi_curs.

Dovezi (identificarea claselor facuta cu vfp_symbols.ps1 -Where):

Clasa	Interval	Clb_zi_curs definit	Eliminat azi?
frm_date_aviz	ofacturare.vc2:6566-7618	:6727-6740 (caption "Data cursului valutar")	Niciodata — zero RemoveObject/conditionare pe in_valuta in toata clasa (verificat exhaustiv)
frm_date_aviz_lucrare	:7620-8201	:7787-7801	Niciodata; in plus, validare necondiționata: :8076 Case Empty(Nvl(poDate.zi_curs,{})) fara nicio garda pe in_valuta (spre deosebire de frm_date_factura, vezi mai jos)
frm_date_factura	:8482-9869	:8701-8714 (caption "Data curs valutar")	Doar pentru tip 8/9, in Init:

ofacturare.vc2:9717-9722  (frm_date_factura.Init)
*!*	modificare v 2.0.56
If Inlist(poDate.tip, 8, 9)
    lnHeight = lnHeight - .clb_zi_curs.Height
    laPozitii(.clb_zi_curs.TabIndex, 2) = 1
    .RemoveObject('clb_zi_curs')
Endif
*!*	modificare v 2.0.56	^

ofacturare.vc2:9725-9728  (imediat dupa, in ACEEASI metoda)
If poDate.in_valuta = 0
    lnHeight = lnHeight - .ct_clb_valuta.Height
    laPozitii(.ct_clb_valuta.TabIndex, 2) = 1
    .RemoveObject('ct_clb_valuta')

Cele doua blocuri sunt adiacente si scrise dupa acelasi tipar (inaltime, laPozitii, RemoveObject) — dovada ca autorul original a tratat ct_clb_valuta (selectorul de valuta) ca dependent de in_valuta, dar nu a facut acelasi lucru pentru clb_zi_curs. Validarea de completare e de asemenea asimetrica: ofacturare.vc2:9484 (Case poDate.in_valuta = 1 And Empty(Nvl(poDate.zi_curs,{})) And ...) cere data curs doar cand in_valuta=1, in timp ce frm_date_aviz_lucrare (:8076) o cere mereu — inconsistenta intre cele doua forme, de retinut daca regula noua trebuie aplicata uniform.

Nota: frm_facturare_articole2 (clasa separata, :15741-19355) are propriul label "Curs valutar" (control diferit, :16285-16299), tratat la punctul 3/5 — nu e acelasi camp cu Clb_zi_curs din antet, dar citeste aceeasi poDate.zi_curs.

---

3. Cele doua concepte, in cod — confirmate distinct

Concluzie: da, distinctia exista clar in cod, pe doua axe independente:

• (a) valuta de document: poDate.in_valuta / poDate.Curs / poDate.multiplicator / poDate.id_valuta — un singur curs, al documentului intreg, folosit cand tot documentul e emis in valuta.
• (b) articol cu pret in valuta pe document in lei: poArticol.tip_valuta = 1 (proprietate a politicii de pret a articolului, independenta de poDate.in_valuta), cu preturile brute in valuta pastrate in poArticol.pretftva_val/pretctva_val/pretd + id_valuta_d, convertite in lei client-side, in VFP, folosind cursul zilei poDate.zi_curs.

Dovezi — conversia in lei pentru cazul (b):

ofacturare.vc2:1989   poArticol.pretftva = Round(poArticol.pretftva_val * poArticol.Curs / poArticol.multiplicator, gnPPretV)
ofacturare.vc2:2953   poArticol.pretftva = Round(poArticol.pretftva_val * poArticol.Curs / poArticol.multiplicator, gnPPretV)
ofacturare.vc2:2017   poArticol.pretctva = Round(poArticol.pretctva_val * poArticol.Curs / poArticol.multiplicator, gnPPretV)

poArticol.Curs/multiplicator (nu e alt curs decat cel al zilei documentului) provin din cursorul crscursuri, incarcat explicit cand documentul e in lei — exact pentru articolele cu preturi in valuta:

ofacturare.prg:407-418  (identic si la :941-947)
If poDate.in_valuta = 1
    Select Distinct Curs, nume_val, id_valuta, multiplicator From (lcCursor) ... Where tip_valuta = 1 ... Into Cursor crscursuri
    Select crscursuri
    poDate.Curs = Curs
    poDate.multiplicator = multiplicator
Else
    citeste_cursuri_zi(poDate.zi_curs)
    If Reccount('crscursuri') = 0
        Use In crscursuri
    Endif
Endif

citeste_cursuri_zi (COMUN\programe\oproceduri_curs.prg:113-124) construieste crscursuri cu toate cursurile valabile la tdDataCurs (= poDate.zi_curs):

oproceduri_curs.prg:117-118
lcSql = [select nume_val,curs,id_valuta,multiplicator from ] + gcS + [.vcurs where data <= ... and data2 >= ...]

Cursorul e apoi afisat direct pe grila de selectie a articolelor, cu eticheta construita din poDate.zi_curs, indiferent de in_valuta:

ofacturare.vc2:15097-15098 si 19004-19005 (frm_facturare_articole2)
If !Empty(Nvl(poDate.zi_curs, {}))
    Thisform.lb_cursuri.Caption = "Curs valutar " + Iif(!Inlist(poDate.tip, 8, 9), "(" + Dtoc(poDate.zi_curs) + ")", "")

Grila/eticheta apar doar daca crscursuri are randuri (ofacturare.vc2:15092/19000), ceea ce se intampla si pe un document in lei, daca exista macar un articol cu politica in valuta.

VANZARI vs VANZARI_DETALII — ce se stocheaza:

• VANZARI (document): coloane proprii CURS/ID_VALUTA/MULTIPLICATOR — cursul/valuta doar ale documentului, populate din poDate.Curs/id_valuta/multiplicator (relevante cand in_valuta=1).
• VANZARI_DETALII (linie): nu are coloana CURS — confirmat din all_tab_columns (docs\cercetare\rec_cale_vanzari_detalii.md:171-175) si din SQL-ul live al pachetului, care reface cursul liniei prin JOIN, nu dintr-o coloana proprie:

  PACK_FACTURARE.sql:3773-3778 (identic la :4034-4036, :6393-6396, :6571-6573)
  LEFT JOIN VANZARI_CURSURI B1 ON A1.ID_VANZARE = B1.ID_VANZARE AND A1.ID_VALUTA = B1.ID_VALUTA
  

  Linia stocheaza insa PRET (pretul efectiv, in lei, folosit pe factura) si PRETD + ID_VALUTAD (pretul brut in valuta si valuta originii, pastrate ca referinta/audit) — vezi INSERT-ul din adauga_articol_factura (docs\cercetare\rec_cale_vanzari_detalii.md:59-65, coloanele PRET, PRETD, ID_VALUTAD, ID_VALUTA alaturi). Deci da, se pastreaza si urma valutei originale pe linie, dar valoarea de facturare efectiva e mereu in lei pe VANZARI_DETALII.PRET.

La ce se foloseste VANZARI_CURSURI: e un instantaneu al cursurilor pentru orice valuta straina aparuta printre liniile documentului (nu doar valuta proprie a documentului), scris o singura data la emitere, indiferent de in_valuta:

PACK_FACTURARE.sql:14491-14501
PROCEDURE scrie_cursuri(V_ID_VANZARE IN NUMBER) IS
BEGIN
  INSERT INTO VANZARI_CURSURI (ID_VANZARE, ID_VALUTA, CURS, MULTIPLICATOR)
    SELECT DISTINCT V_ID_VANZARE, ID_VALUTA, CURS, MULTIPLICATOR
      FROM VANZARI_DETALII_TEMP
     WHERE ID_VALUTA <> pack_facturare.nid_moneda_nationala;
END scrie_cursuri;

Rulat necondiționat la fiecare emitere (apelat din scrie_in_vanzari, vezi docs\cercetare\rec_cale_vanzari_detalii.md:98-102) — deci si pe o factura in lei cu articole in valuta se scrie cate un rand VANZARI_CURSURI pentru fiecare valuta straina aparuta pe linii, cu cursul citit la poDate.zi_curs. Tabela e folosita ulterior la reafisare/reprint/retur, ca sursa a cursului per-linie (JOIN-urile de mai sus).

---

4. Ce se strica daca ascundem campul cand "nu are sens"

Concluzie: nu exista risc de "factura fara curs deloc" — poDate.zi_curs primeste mereu o valoare implicita la Init (data documentului) si nu poate ramane NULL. Riscul real e altul: userul pierde controlul asupra datei de curs pentru cazul (b) — o factura in lei cu articole in valuta ar folosi mereu cursul zilei curente/implicite, fara sa poata fi corectat manual, exact in situatia in care lipseste cursul pentru acea data (eroarea Oracle 20005, punctul 5) sau cand userul vrea sa aliniaze cursul cu data unui document sursa (aviz, contract).

Consumatori confirmati ai poDate.zi_curs (grep exhaustiv poDate\.zi_curs, fisiere ofacturare.vc2, ofacturare.prg, ofacturare_stoc.prg — singurele 3 din COMUN):

Loc	Ce primeste	Conditionat de in_valuta?
ofacturare.vc2:6105-6107, :13994-13996, :18030-18032	parametru to_date(...) catre pack_facturare.initializeaza_date_factura(...) la fiecare finalizare de antet	Nu — trimis pentru orice tip
ofacturare.prg:272,276,281,297,303	primul parametru al pack_facturare.cursor_articole_k / cursor_preturi / cursor_gestiune / cursor_lucrare — SQL-ul care aduce lista de articole/preturi afisata userului	Nu — inclusiv pentru tip=1 (lista de preturi, lei)
ofacturare_stoc.prg:79,335	acelasi rol, pe calea alternativa "facturare din stoc"	Nu
ofacturare.vc2:15097-15098, :19004-19005	eticheta grilei "Curs valutar (data)" din frm_facturare_articole2	Nu — apare oricand crscursuri are randuri
ofacturare.vc2:9484	validare "Nu ati completat ziua cursului valutar"	Da, doar in_valuta=1 (frm_date_factura)
ofacturare.vc2:8076	aceeasi validare	Nu, necondiționata (frm_date_aviz_lucrare)

Riscul concret: daca regula noua ascunde/dezactiveaza campul strict cand poDate.in_valuta=0, pe frm_date_factura (tip 1, lista de preturi) userul nu va mai putea edita zi_curs inainte de a deschide grila de articole — dar ofacturare.prg:279-282 tot va trimite acel poDate.zi_curs (neschimbat, ramas pe data initializata la Init) catre cursor_preturi, iar daca acolo Oracle ridica eroarea 20005 (curs lipsa pentru acea data/valuta), fluxul de recuperare (vizualizeaza_curs, punctul 5) va porni oricum, dar userul nu va (mai) avea camp pe antet ca sa retina/corecteze data dupa ce inchide formularul de curs. Pe frm_date_aviz_lucrare, ascunderea ar intra chiar in conflict cu validarea necondiționata de la :8076, care ar bloca finalizarea antetului cerand un camp care nu mai exista pe ecran — de reparat impreuna, nu doar ascuns.

---

5. Formularul de curs valutar din antet — localizare si traseu

Concluzie: nu exista niciun buton/dblclick pe Clb_zi_curs care sa deschida formularul de curs (verificat exhaustiv — zero hit pentru Clb_zi_curs.DblClick/RightClick/Click sau but_curs in ofacturare.vc2). Formularul se deschide automat, ca recuperare de eroare, dupa ce antetul (frm_date_factura/frm_date_aviz) s-a inchis deja si codul incearca sa incarce lista de articole.

Traseu:

1. ofacturare.prg:228-235 — ofrmceredate = Createobject(lcObiect, toFactura) (lcObiect = frm_date_factura sau frm_date_aviz), .Show() modal; la inchidere, Release ofrmceredate (:248).
2. ofacturare.prg:266-308 — pe baza tipului, se construieste apelul catre pack_facturare.cursor_preturi(?poDate.zi_curs, ...) (sau cursor_articole_k/cursor_gestiune/ cursor_lucrare) si se executa (:311 goExecutor.oExecute(lcSqlCursor, lcCursor)).
3. Daca esueaza cu eroarea Oracle 20005 (curs lipsa pentru data/valuta ceruta):

   ofacturare.prg:313-317 (identic la :828-832)
   If lnSucces < 0
       AMESSAGEBOX(goExecutor.oPrelucrareEroare(), 16, "Eroare")
       If goExecutor.nEroare = 20005
           vizualizeaza_curs(poDate.zi_curs)
       ENDIF
   

4. vizualizeaza_curs(tdDataCurs) — COMUN\programe\oproceduri_curs.prg:8-42 — construieste cursorul crscurs si deschide loFrmCurs = Createobject("frm_curs", tdDataCurs) / .Show(1) (modal).
5. Clasa frm_curs e definita in COMUN\clase\onom_curs.vc2:537 (DEFINE CLASS frm_curs AS _frmbase ...), cu formulare-satelit pentru adaugare curs: frm_curs_nou (onom_curs.vc2:1066) si frm_curs_nou_multiplu (onom_curs.vc2:1330, apelat de la onom_curs.vc2:941).
6. A doua cale catre acelasi formular: citeste_cursuri_stoc (oproceduri_curs.prg:45-110, folosit pe fluxul de facturare din stoc) cheama vizualizeaza_curs() fara parametru de data (oproceduri_curs.prg:94) cand gaseste valute fara curs pentru ziua ceruta, in bucla Do While llVerificare (retry pana userul completeaza sau renunta).

Aceasta e exact situatia din COMUN\docs\todos.txt:45 (punctul 16): "la finalizare se verifica cursul valutar necesar pentru politicile de preturi care se factureaza [...] la revenire din formularul de curs valutar, focusul revine [...] pe TIP DOCUMENT, si la iesire din serie se regenereaza numar act" — confirmat ca fenomenul are loc dupa ce antetul (frm_date_factura) e deja inchis si eliberat (Release ofrmceredate, pasul 1), deci orice regenerare de numar/focus vizibila dupa inchiderea frm_curs tine de ecranul/starea care ramane activa in spate (nu s-a localizat mai departe — cere depanare separata, in afara scopului "doar localizare" cerut aici).

---

Cand are sens campul „Data curs valutar" — propunere de regula

Campul are sens de aratat/editabil pe antet exact cand exista vreo sansa ca cursul zilei sa fie folosit la facturare — nu doar cand documentul insusi e in valuta:

Arata (si activeaza) Clb_zi_curs cand poDate.tip NU e retur (!Inlist(poDate.tip,8,9)) SI (poDate.in_valuta = 1 SAU exista macar o politica de pret in valuta accesibila tipului curent de document — adica exact conditia care astazi populeaza crscursuri cu randuri, verificata deja empiric la ofacturare.vc2:15092/:19000: Used('crscursuri') And Reccount('crscursuri') > 0 dupa incarcarea listei de articole). Pe retur (8/9) ramane ascuns ca azi.

Pe frm_date_aviz/frm_date_aviz_lucrare, unde crscursuri nu e inca disponibil la momentul antetului (se incarca dupa, la fel ca la factura), regula echivalenta practicabila pe antet (nu dupa) ar fi: arata campul daca tipul documentului admite politici de pret in valuta pentru sucursala/gestiunea curenta (verificare care azi nu exista pe antet, doar mai tarziu pe grila de articole) — necesita fie mutarea verificarii mai devreme, fie acceptarea ca antetul nu poate sti cu certitudine inainte de a incarca articolele, caz in care campul ramane vizibil implicit si doar eticheta/relevanta lui se clarifica ulterior (ca azi, in frm_facturare_articole2).

---

Necunoscute ramase

• Nu s-a confirmat daca exista si alte politici (CRM_POLITICI_PRET*) sau reguli de sucursala care determina inainte de deschiderea grilei de articole daca vor exista linii tip_valuta=1 — utile pentru a decide vizibilitatea campului chiar pe antet, nu doar reactiv dupa incarcarea articolelor.
• Nu s-a urmarit complet "focusul sare pe tip document / regenerare numar act" (punctul 5/todos #16) dupa inchiderea frm_curs — s-a localizat doar traseul de deschidere, nu si ecranul/handler-ul care ramane activ in spate si cauzeaza simptomul; cere sesiune separata de depanare (posibil in poGeneratorNumere/clb_serie_act, cf. ofacturare.vc2:9735-9737, needatate aici).
• Layout-urile .frx (neconvertite) care afiseaza poDate.Curs/cValuta pe hartie nu au fost verificate — gap deja semnalat in rec_consumatori_vanzari.md (risc posibil #3), ramane valabil.
• Nu s-a confirmat empiric (interogare Oracle) daca exista azi in productie facturi tip=1 (lei) cu linii ID_VALUTA <> moneda_nationala in VANZARI_DETALII — dovada ar intari direct concluzia punctului 3, dar cercetarea a fost strict pe cod (fara conexiuni DB, conform mandatului).