Files
roafacturare/docs/review_s5_grid_articole.md
Marius Mutu d9f5ca4226 docs: planurile, proiectarile si rapoartele de lucru intra in versionare
Folderul docs\ era pana acum in afara oricarui control de versiuni - nici git,
nici SVN - desi contine planurile pe puncte, proiectarile si rapoartele de
cercetare pe care se sprijina modificarile din cod. O stergere acolo era
definitiva.

Fisierele intermediare (handoff-uri intre sesiuni, diff-uri deja aplicate) au
fost sterse inainte, nu versionate: ce era durabil in ele a intrat in antetele
fisierelor de test la care se refereau.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
2026-08-11 22:17:17 +03:00

63 lines
3.8 KiB
Markdown

# Review: diff_s5_grid_articole.patch (omodificari.vc2, frm_modific2024)
Status: GATA. Review read-only, fara editari de cod. Nicio tranzactie/proces deschis.
## Scop verificat
`docs/diff_s5_grid_articole.patch` 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.