roafacturare/docs/cercetare/zi_curs_validare.md

# Cercetare: validarea zi_curs la ofacturare.vc2:8076 si impactul asupra S4d

## Verdict (5-10 randuri)

Ascunderea selectorului de zi curs NU va lasa un document fara curs si NU va cadea la salvare,
CU CONDITIA sa se respecte precedentul deja existent in cod: `poDate.zi_curs` primeste un implicit
necondiionat (data documentului) chiar in `oDateFactura.Init`/`Reset`
(`COMUN\programe\ofacturare_comun.prg:247` si `:496`), INAINTE ca formularul sa decida ce ascunde.
Nicaieri codul nu goleste `poDate.zi_curs` cand controlul e ascuns/eliminat. Riscul real de eroare
Oracle (-20005, "Nu este setat cursul...") vine NU din camp gol, ci din faptul ca verificarea
`pack_facturare.verifica_cursuri_valute` (in `cursor_preturi`) ruleaza NECONDITIONAT de `in_valuta`
al documentului curent si exclude doar moneda nationala - deci un `zi_curs` implicit (azi) care nu
are curs setat in tabela CURS pentru o valuta folosita in listele de preturi ale utilizatorului
poate pica oricum, INDIFERENT daca selectorul e vizibil sau nu. Linia :8076 NU apartine formularului
de factura, ci unui formular separat, restrans, pentru AVIZ PE LUCRARE / AVIZ PE NIR
(`frm_date_aviz_lucrare`, tipuri 27 si 30) - fara control de valuta pe el - si valideaza `zi_curs`
strict pentru ca tipul 27 are nevoie de curs pentru articolele din comanda (posibil in valuta),
INDEPENDENT de `poDate.in_valuta`. Precedentul cerut la punctul 6 exista deja, dar in alt formular:
`frm_date_factura`, tipurile 8/9 (retur), unde `clb_zi_curs` e eliminat NECONDITIONAT si documentul
se salveaza corect - motivul principal e ca SQL-ul pentru retur (`cursor_retur`) nici nu foloseste
`poDate.zi_curs`.

## 1. Ce valideaza linia :8076

Index de simboluri: `frm_date_aviz_lucrare.inainte_de_do_termin` = `ofacturare.vc2:8054-8119`
(fisier real: `COMUN\clase\ofacturare.vc2`).

Blocul complet (validare secventiala pe formular, fiecare `Case` opreste salvarea la primul fail):

```
COMUN\clase\ofacturare.vc2:8063-8079
Do Case
Case Empty(poDate.dataireg)
    amessagebox("Nu ati completat data inregistrarii!",48,"Atentie")
    ...
Case Empty(poDate.dataact)
    amessagebox("Nu ati completat data documentului!",48,"Atentie")
    ...
Case Empty(Nvl(poDate.id_fdoc,0))
    amessagebox("Nu ati ales felul documentului!",48,"Atentie")
    ...
Case Empty(Nvl(poDate.zi_curs,{}))
    amessagebox("Nu ati completat ziua cursului valutar!",48,"Atentie")
    This.clb_zi_curs.SetFocus()
    plReturn = .F.
Case Empty(poDate.nract)
    ...
```

Valideaza STRICT prezenta unei date in `poDate.zi_curs` (`Empty(Nvl(...,{}))`), nu existenta unui
curs in baza pentru acea data - acel test se face abia in Oracle, la momentul in care se cere
cursorul de articole (vezi punctul 4).

## 2. Cand ruleaza si pe ce tipuri de document

`inainte_de_do_termin` e apelat la evenimentul butonului "Termina" al formularului (`BUT_TERMIN1`,
vezi lista de obiecte a clasei, `ofacturare.vc2:7674-7679`) - deci la incercarea de a incheia
completarea datelor de antet, inainte de a trece la ecranul de articole.

`frm_date_aviz_lucrare` NU e formularul de factura. E instantiat DOAR pentru doua tipuri de
document, ambele AVIZ (nu FACTURA):

```
COMUN\programe\ofacturare.prg:187-226 (identic in factureaza2, :697-699)
Do Case
    Case tnTip = 27
        poDate.nIdTipDoc = 6 && AVIZ
    Case tnTip = 30
        poDate.nIdTipDoc = 6 && AVIZ
    Case tnTip < 21 Or Inlist(tnTip, 45, 48, 49, 51, 52)
        poDate.nIdTipDoc = 5 && FACTURA
    ...
Do Case
    Case tnTip = 27
        lcObiect = [frm_date_aviz_lucrare]
    Case tnTip = 30
        lcObiect = [frm_date_aviz_lucrare]
    Case tnTip < 21 Or Inlist(tnTip, 45, 48, 49, 51, 52)
        lcObiect = [frm_date_factura]
    Otherwise
        lcObiect = [frm_date_aviz]
Endcase
```

Titlul formularului confirma: `Lb_titlu_alb_b121.Caption = "AVIZ PE BAZ­ DE LUCRARE"`
(`ofacturare.vc2:7670`), schimbat in `Init` la "AVIZ PE BAZ­ DE NIR" cand `nid_tip = 30`
(`ofacturare.vc2:8154-8161`).

Nu exista o garda mai sus in lant care sa dezactiveze validarea :8076 pe vreun tip - ruleaza
identic pentru tip 27 si tip 30, necondiionat de `poDate.in_valuta`. IMPORTANT: aceasta clasa
NU are deloc control de valuta pe formular - lista de obiecte a clasei (`ofacturare.vc2:7623-7637`)
nu contine niciun `ct_clb_valuta`. Deci validarea de aici nu e legata de "documentul e in valuta",
ci de nevoia formularului AVIZ-LUCRARE de a avea o zi de curs pentru articolele comenzii care pot
fi preturite in valuta (vezi punctul 4, `cursor_lucrare`).

Concluzie: linia :8076 NU intra deloc in fluxul de facturare (FACTURA) vizat de decizia 15 - e un
formular separat, pentru un subset ingust de avize (27 = aviz pe lucrare, 30 = aviz pe NIR).

## 3. Ce se intampla daca zi_curs e gol la :8076

Mesaj de eroare blocant (nu doar avertisment): `amessagebox("Nu ati completat ziua cursului
valutar!",48,"Atentie")`, apoi `This.clb_zi_curs.SetFocus()` si `plReturn = .F.` - `Case`-ul
opreste executia `Do Case` (Otherwise nu se mai atinge), iar `inainte_de_do_termin` returneaza
`.F.`, ceea ce (conform conventiei din restul clasei) blocheaza inchiderea formularului / trecerea
la pasul urmator.

## 4. Cine mai citeste poDate.zi_curs

Cautare `zi_curs` in `.vc2`/`.prg`/`.sc2` si in sursele Oracle
(`docs\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql`):

**a) Validari de formular (camp obligatoriu):**
- `frm_date_aviz_lucrare.inainte_de_do_termin` :8076 - necondiionat (vezi punctele 1-2).
- `frm_date_factura.inainte_de_do_termin`, `ofacturare.vc2:9484`:
  ```
  Case poDate.in_valuta = 1 And Empty(Nvl(poDate.zi_curs,{})) And Type('thisform.clb_zi_curs.visible')<>'U'
  ```
  Aici validarea E DEJA dublu conditionata: pe `in_valuta = 1` SI pe existenta controlului
  (`Type(...)<>'U'` - devine 'U' daca controlul a fost eliminat cu `RemoveObject`). Deci pe factura
  in lei, sau pe orice tip unde controlul a fost eliminat, validarea nu ruleaza deloc. Comentariul
  `*!* modificare v 2.0.56` de langa arata ca exact acest lucru a fost REZOLVAT anterior pentru
  formularul de factura.

**b) Populare implicita / sincronizare (fara conditie de in_valuta):**
- `oDateFactura.Init`, `COMUN\programe\ofacturare_comun.prg:247`: `.zi_curs = ldData` -
  necondiionat, seteaza mereu data documentului curent (ldData = azi, ajustat la luna/anul
  curent de facturare) INAINTE de blocul care seteaza `.in_valuta` (linia 248-250).
- `oDateFactura.Reset`, `ofacturare_comun.prg:496`: `.zi_curs = .Data` - la fel, necondiionat.
- `frm_date_aviz.Clb_dataact.Text_simplu1.LostFocus` (:7603-7604) si
  `frm_date_aviz.Clb_dataireg...LostFocus` (:7610-7611): `poDate.zi_curs = poDate.dataact`,
  necondiionat (formularul aviz general nu are guard, dar si nu are RemoveObject pe zi_curs).
- `frm_date_aviz_lucrare.Clb_dataact...LostFocus` (:8186-8187) si
  `...Clb_dataireg...LostFocus` (:8193-8194): idem, necondiionat - zi_curs NU e niciodata
  eliminat in aceasta clasa, deci sincronizarea merge mereu.
- `frm_date_factura.Clb_dataact...LostFocus` (:9805-9808) si `...Clb_dataireg...` (:9824-9827):
  ACESTEA SUNT deja conditionate: `If Type('thisform.clb_zi_curs.visible')<>'U' ... zi_curs =
  dataact ... Endif` (comentariu `*!* modificare v 2.0.56`). Cand controlul e eliminat, sincronizarea
  se opreste - dar valoarea RAMASA de la Init/Reset nu se sterge, ramane cea de la creare.

**c) Consum efectiv in SQL (trimis catre Oracle, cursoare de articole):**
`COMUN\programe\ofacturare.prg:266-308` (identic in `factureaza2`, :751-816) - alegerea SQL-ului de
populare a articolelor se face pe `tnTip`, NU pe `in_valuta`:
```
Case Inlist(tnTip, 48, 49)        -> cursor_articole_k(?poDate.zi_curs, ...)
Case tnTip = 45                   -> cursor_preturi(?poDate.zi_curs, ...)
Case Inlist(tnTip, 1,22,5,29,7,10,23) -> cursor_preturi(?poDate.zi_curs, ...)
Case Inlist(tnTip, 2,26,6,52)     -> cursor_contract(?poDate.zi_curs, ...)
Case Inlist(tnTip, 3,21,25,28,42,47) -> cursor_comanda(?poDate.zi_curs, ...)
Case tnTip = 4                    -> cursor_avize(...)                [FARA zi_curs]
Case Inlist(tnTip, 41)            -> cursor_gestiune(?poDate.zi_curs, ...)
Case tnTip = 30                   -> cursor_aviz_nir(...)              [FARA zi_curs]
Case tnTip = 27                   -> cursor_lucrare(?poDate.zi_curs, ...)
Case Inlist(tnTip, 8,9,24)        -> cursor_retur(?poDate.in_valuta, ...) [FARA zi_curs]
```
Descoperire cheie: pentru tipurile 8, 9, 24 (retur) SI 30 (aviz pe NIR), SQL-ul NU trimite deloc
`poDate.zi_curs` catre Oracle - `zi_curs` gol sau completat nu are niciun efect pentru aceste
tipuri. Acesta e motivul real pentru care eliminarea controlului la tip 8/9 e sigura (mai puternic
decat simpla existenta a unei valori implicite).

Pentru tipurile care TRIMIT zi_curs, comportamentul in Oracle e diferit:
- `cursor_preturi` (`docs\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:2138+`) apeleaza NECONDITIONAT
  `pack_facturare.verifica_cursuri_valute(V_DATA_CURS, V_ID_UTIL)` (linia 2153). Aceasta procedura
  (`:16247-16274`) verifica cursul pentru TOATE valutele distincte din `FACT_VPRETURI_UTILIZATOR`
  ale utilizatorului curent (nu doar valuta documentului!) si arunca
  `RAISE_APPLICATION_ERROR(-20005, 'Nu este setat cursul din data de ... !')` daca oricare dintre
  ele nu are curs care sa acopere `V_DATA_CURS` - EXCLUDE explicit moneda nationala
  (`AND A.ID_VALUTA <> pack_facturare.nid_moneda_nationala`). Deci: chiar pe un document in LEI
  (`in_valuta=0`), daca utilizatorul are liste de preturi in valuta configurate si data trimisa
  (implicita sau nu) nu are curs setat, apelul PICA cu -20005 - INDIFERENT de vizibilitatea
  selectorului pe formular. Riscul nu vine din camp gol, ci din "camp cu o data pentru care nu
  exista curs in tabela CURS".
- `cursor_articole_k` (`:3595-3701`) si `cursor_lucrare` (`:3173-3593`, foloseste `V_DATA_CURS`
  pentru comenzi_elemente) - `cursor_articole_k` NU apeleaza `verifica_cursuri_valute`, doar face
  `LEFT JOIN CURS ... WHERE DATA <= V_DATA_CURS AND DATA2 >= V_DATA_CURS` - daca nu gaseste, cade
  silentios pe `NVL(D.CURS,0)` (pret gresit, nu eroare). `cursor_lucrare` (:3186-3218) INSA face
  o verificare proprie, similara: daca articolele comenzii au valute fara curs pe `V_DATA_CURS`,
  arunca acelasi `-20005`.
- Exista deja o rutina de recuperare la acest cod de eroare: `ofacturare.prg:313-317`
  ```
  If lnSucces < 0
      AMESSAGEBOX(goExecutor.oPrelucrareEroare(), 16, "Eroare")
      If goExecutor.nEroare = 20005
          vizualizeaza_curs(poDate.zi_curs)
      ENDIF
  ```
  Deci sistemul ANTICIPEAZA deja cazul "curs lipsa la data respectiva" si deschide un ecran de
  gestiune a cursurilor - independent de validarea din formularul de date.

**d) Afisare / etichetare (fara risc):**
- `frm_facturare_articole.Init` (:15097-15098) si `frm_facturare_articole2.Init` (:19004-19005):
  `If !Empty(Nvl(poDate.zi_curs,{})) Then Thisform.lb_cursuri.Caption = "Curs valutar (" +
  Dtoc(poDate.zi_curs) + ")"` - deja tolereaza gol (nu afiseaza nimic), fara eroare.
- `frm_date_factura.do_cauta_valuta` (:9344-9359) - dupa alegerea valutei, muta focusul pe
  `clb_zi_curs` DACA exista (`Type(...)<>'U'`), altfel pe `clb_serie_act`. Deja conditionat.
- `onom_curs.vc2` (`ck_zi_curs`, `tx_zi_curs`) - ecran DIFERIT, de administrare a cursurilor
  valutare in sine (nu are legatura cu `poDate.zi_curs`; e o cautare "dupa ziua cursului" generica).

## 5. Valoarea implicita azi si de unde vine

Vine din `oDateFactura.Init`/`Reset`, necondiionat de tip sau de `in_valuta`:
- `Init` (`ofacturare_comun.prg:235-247`): `ldData = Ttod(get_ora())`, ajustat la luna/anul curent
  de facturare (`gnAn`/`gnLuna`) daca `get_ora()` cade in alta luna; apoi `.zi_curs = ldData`.
- `Reset` (`ofacturare_comun.prg:486-496`): `.zi_curs = .Data` (unde `.Data` a fost deja setat tot
  din `ldData`-ul curent).

Deci implicit `zi_curs` = data curenta (get_ora, ajustata la perioada de facturare deschisa), NU
`Date()` brut si nu neaparat `dataact`/`dataireg` (desi acestea pornesc de la aceeasi `ldData`).
Ulterior, cat timp controlul `clb_zi_curs` exista pe formular, orice editare a `dataact`/`dataireg`
resincronizeaza `zi_curs = dataact` prin evenimentele `LostFocus` (vezi punctul 4b). Daca formularul
ar ascunde controlul FARA sa elimine obiectul si fara sa goleasca proprietatea, campul ar ramane
la valoarea implicita de la Init/Reset (sau la ultima valoare sincronizata inainte de ascundere).

## 6. Precedent: tip cu campul ascuns care se salveaza corect

DA, exista deja, dar in `frm_date_factura` (formularul de FACTURA), nu in `frm_date_aviz_lucrare`:

```
COMUN\clase\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 ^
```

Pentru tip 8 si 9 (facturi de retur - care pot fi chiar in valuta, vezi `ofacturare_comun.prg:248`:
`INLIST(m.tnTip, 5,6,7,9,10,52) -> .in_valuta = 1`), controlul `clb_zi_curs` e eliminat COMPLET de
pe formular, necondiionat de `in_valuta`, si documentul se salveaza corect. Motivele, in ordine de
robustete:
1. Validarea din `inainte_de_do_termin` (:9484) e deja garda cu `Type(...)<>'U'`, deci se
   auto-dezactiveaza cand controlul nu mai exista.
2. SQL-ul de populare articole pentru tip 8/9 e `cursor_retur(?poDate.in_valuta,...)`
   (`ofacturare.prg:306-307`) - NU trimite deloc `poDate.zi_curs`, deci nu poate cauza -20005 din
   cauza acestui camp.
3. Chiar daca ar fi trimis, `poDate.zi_curs` tot ar avea valoarea implicita de la Init/Reset
   (punctul 5) - nimic nu-l goleste la `RemoveObject`.

Aceasta e "reteta" cerinta de punctul 6: eliminarea vizuala e sigura pentru ca (a) validarea are
deja garda pe existenta controlului, si (b) proprietatea `poDate.zi_curs` nu e niciodata golita -
ramane pe implicitul din Init/Reset.

Pentru `frm_date_aviz_lucrare` (linia :8076) NU exista un tip cu campul ascuns - `clb_zi_curs` nu e
eliminat pentru nici tip 27, nici tip 30. Motivul plauzibil: tip 27 (aviz pe lucrare) chiar
foloseste `zi_curs` in `cursor_lucrare` pentru articolele comenzii (posibil in valuta), independent
de `poDate.in_valuta` al documentului-aviz insusi - deci acolo campul NU e un candidat sigur pentru
ascundere pe baza lui `in_valuta`. Pentru tip 30, SQL-ul (`cursor_aviz_nir`) nu foloseste `zi_curs`
deloc, deci validarea de acolo e superflua dar inofensiva (campul e mereu populat implicit).

## Ramas de verificat

- Nu am gasit inca daca decizia 15 / S4d intentioneaza sa includa si `frm_date_aviz_lucrare` in
  formularul unificat, sau doar `frm_date_factura`/`frm_date_aviz`. Din cod, `frm_date_aviz_lucrare`
  e un formular de sine statator, fara control de valuta, folosit doar pentru tnTip 27 si 30 - daca
  planul S4d nu-l tinteste explicit, linia :8076 e in afara scopului imediat.
- Nu am verificat ce se intampla in `cursor_articole_k` (tip 48/49) si `cursor_gestiune` (tip 41)
  fata de `verifica_cursuri_valute` - din citire, `cursor_articole_k` nu apeleaza acea procedura
  (cade silentios pe curs 0), dar nu am verificat `cursor_gestiune`.
- Nu am verificat cum decide `frm_date_factura.Init` ce alte tipuri (in afara de 8,9) ar putea fi
  candidate pentru ascunderea lui `clb_zi_curs` conform deciziei 15 - doar am confirmat mecanismul
  existent si conditia dubla deja implementata la validare (in_valuta + Type<>'U').