# Review: diff aplicat (sters) (omodificari.vc2, frm_modific2024)

Status: GATA. Review read-only, fara editari de cod. Nicio tranzactie/proces deschis.

## Scop verificat

diff aplicat (sters) pe `COMUN/clase/omodificari.vc2`:
- insereaza coloana de grid `cPretAchizitieArt` (legata de `tvd.pret_achizitie`) intre
  `cPretArt` (Column6) si fostul `cPretCuTvaArt` (Column7), renumeroteaza Column7..14 -> 8..15;
- adauga campul `id_vanzare_set` in cursorul `tvd`;
- adauga validare noua in `inainte_de_do_termin` (bloc `OFACTURARE_EDITARE`);
- adauga/modifica handlere `When` pe `cCantitateArt.Text1`, `cPretArt.Text1`,
  `cPretAchizitieArt.Text1`, `cPretCuTvaArt._checkbox1`.

## Verificat si confirmat OK (fara regresie)

- Renumerotarea Column7->15: toate proprietatile (`ControlSource`, `Name`, `Format`,
  `InputMask`, `ReadOnly`, `Width`, `Sparse`, `DynamicForeColor`) se pastreaza identic fata
  de valorile pre-diff, verificat linie cu linie in hunk-urile de la
  `omodificari.vc2:12341-12450`.
- Nicio alta parte a fisierului nu refera coloanele `grdArticoleFactura` pe index numeric
  (grep confirmat - singurele hit-uri `Grid1.ColumnN` apartin altui grid, in alta sectiune a
  clasei), deci renumerotarea nu putea sparge tacut o referinta indexata.
- Coloana noua `cPretAchizitieArt` primeste acelasi tratament `DynamicForeColor` ca surorile ei.
- Garda de editare pentru `cPretAchizitieArt` (blocheaza editarea cand `id_vanzare_det<>0`)
  e consistenta cu `COMUN/programe/ofacturare_editare.prg` (`ScrieArticoleFacturaEditate`):
  UPDATE-ul pentru liniile existente NU scrie `pret_achizitie` inapoi, deci blocarea editarii
  exact pe acele randuri e corecta, nu o scapare.

## Findings (3, niciunul cu severitate "blocker" cert, dar merita fix inainte de commit)

1. **omodificari.vc2:14330** - blocul nou de validare (`IF "OFACTURARE_EDITARE" $ ...`) face
   `SELECT tvd` + `SCAN ... RETURN .F.` fara sa salveze/restaureze `Recno()` pe tvd inainte de
   return; restaureaza doar workarea activa (`SELECT (m.lnAreaTvd)`). Toate celelalte metode
   din fisier care fac SCAN pe un workarea (15+ precedente gasite prin grep pe `lnRecno`)
   salveaza `Recno()` inainte si fac `GOTO`/`GO` inapoi. Scenariu: userul incearca sa salveze,
   o linie mai jos pica validarea -> pozitia curenta in tvd ramane unde s-a oprit SCAN-ul (nu
   randul pe care userul lucra), posibil sa sara vizual randul selectat in grid dupa esec.

2. **omodificari.vc2:14350** - avertismentul de `pret_achizitie=0` la salvare exempteaza doar
   `id_vanzare_det<>0`, dar garda de editare `cPretAchizitieArt.Text1.When` (linia 16514)
   exempteaza si `id_vanzare_set<>0`. Un rand nou dintr-un set de articole
   (`id_vanzare_set<>0`, `id_vanzare_det=0`) cu `pret_achizitie` 0/null va primi nag-ul Da/Nu
   la fiecare salvare, fara ca userul sa poata edita campul ca sa-l corecteze (editarea e
   blocata de guard).

3. **omodificari.vc2:16513** - `cPretAchizitieArt.Text1` are `When` (seteaza `oldvalue`) dar nu
   are un `Valid` pereche, spre deosebire de `cCantitateArt.Text1` (16499) si `cPretArt.Text1`
   (16520), care compara oldvalue/newvalue si apeleaza
   `Thisform.calculeaza_valori_articol()` -> `REPLACE lmodificat WITH .T.`. Editarea izolata a
   `pret_achizitie` nu marcheaza randul `lmodificat`. Nu am gasit un consumator cert al
   `lmodificat` care sa depinda de asta pentru persistenta (INSERT-ul de linii noi in
   `ScrieArticoleFacturaEditate` nu filtreaza dupa `lmodificat`), deci impactul functional
   e incert, dar inconsistenta cu patternul stabilit ramane.

## Ce NU s-a facut (in afara scopului acestui review)

- Nu s-a validat `ofacturare_editare.prg` / partea Oracle in detaliu (in grija altor agenti
  din sesiune: s5-helper, s5-oracle, s5-script, s5-view).
- Nu s-a rulat harness-ul de teste headless.
- Niciun fix nu a fost aplicat - doar review, findings-urile de mai sus asteapta decizie
  inainte de commit.