Marius Mutu
b5a7108f34
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
63 lines
3.8 KiB
Markdown
63 lines
3.8 KiB
Markdown
# 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.
|