Files
roafacturare/docs/review_s5_grid_articole.md
Marius Mutu b5a7108f34 docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi
Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge
in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a
planului aflat in lucru. Impartirea:

- 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs,
  TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12,
  watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt
  ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele.
- 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse.
- 91 raman, neatinse.

Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au
fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri
aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase.

progres.md preia rolul de predare: ce ramane din #6 (cele sase documente
parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test
citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in
locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp.

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

3.8 KiB

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.