roafacturare/docs/diagnostic_pagina_articole_ux.md

Diagnostic - pagina "Articole factura" in formularul de modificare

Sursa: raport Marius, 19.08.2026, cu captura pe formularul MODIFICARE maximizat ({A97AED0C-...}.png). Doua probleme distincte, fara legatura intre ele.

Problema 1 - continutul paginii 3 nu se intinde la maximizare

Simptom. Pe formularul maximizat, gridul de articole ramane la dimensiunea de design si bara de totaluri (Total linii / Discount / Total net / Total salvat / Total ACT / Total RUL / verdict) apare la mijlocul paginii, cu spatiu gol dedesubt.

Geometrie la design (COMUN\clase\omodificari.vc2):

Obiect	Linie	Top	Height	Anchor
pgfArticole	8709-8712	361	164	15
PAGE3.grdArticoleFactura	12324-12341	26	81	15
PAGE3.cmdSincronizeazaArticole	12306-12320	0	22	0
PAGE3.lbl/txt Total linii, Discount, Total net, Total salvat	12791-12951	110-114	17/21	absent (0)
PAGE3.lbl/txt Total ACT, Total RUL, verdict	12803-12873	132-136	17/21	absent (0)

Formularul are Height = 530 (:6868), deci pagina are inaltime utila ~140px la design. Randul al doilea de totaluri se termina la 153 - sub marginea paginii: la dimensiunea de design nu e vizibil deloc. Bara a fost pozitionata presupunand implicit ca pagina va fi mai mare.

Cauza. Doua lucruri, ambele necesare pentru simptom:

1. Bara de totaluri nu are Anchor deloc - la crestere ramane la Top fix, adica sus, in timp ce pagina creste in jos. Asta e sigur, se vede direct in definitie.
2. Gridul are Anchor = 15, deci ar fi trebuit sa creasca si sa acopere bara - dar nu creste. Formularul se maximizeaza in Show() (:14874, This.WindowState = 2) cat timp pagina activa e PAGE1. VFP reasaza pe Anchor doar controalele paginii active in momentul redimensionarii; PAGE3, nefiind activa atunci, ramane la geometria de design si nu se mai corecteaza niciodata, pentru ca formularul nu mai e redimensionat dupa aceea. Acelasi lucru se vede si in captura: PAGE1 (grdRulaje, tot Anchor = 15) arata corect.

Consecinta a aceleiasi cauze - valorile din bara sunt vechi. In captura, Total ACT si Total RUL arata amandoua 0.00, dar verdictul spune "divergent". Cele doua nu pot fi adevarate simultan: ActualizeazaVerdictActRul (:13123-13126) scrie "divergent" numai cand Abs(nTotalActRon - nTotalRulRon) > 0.02. Deci proprietatile formularului au valori reale, iar casutele afiseaza altceva: ActualizeazaBaraTotaluri se cheama o singura data, din Show() (:14864), si se termina cu This.pgfArticole.PAGE3.Refresh() (:13025) - executat tot cat timp PAGE3 e inactiva. txtDiscountArt si txtTotalSalvatArt, legate de tvanz.*, apar goale, ceea ce duce in aceeasi directie.

Ce lipseste, structural. PAGE3 nu are niciun Activate. Nimic nu ruleaza cand utilizatorul intra pe pagina: nici reasezare, nici recalcul, nici refresh. Toate celelalte doua pagini isi fac treaba in Show(), cand sunt (PAGE1) sau nu conteaza (PAGE2, doar grid ancorat) active.

Reparatie propusa (nu aplicata):

1. PROCEDURE pgfArticole.PAGE3.Activate nou, care cheama o metoda de asezare a paginii si Thisform.ActualizeazaBaraTotaluri().
2. Metoda aseaza_pagina_articole() in frm_modific2024, care pozitioneaza explicit, din cod, nu prin Anchor: gridul de la Top = 26 pana la inaltime_pagina - 52, apoi cele doua randuri de totaluri lipite de marginea de jos. Explicit, pentru ca Anchor s-a dovedit exact aici nesigur - nu are rost sa reparam bara cu acelasi mecanism care a picat pentru grid.
3. Aceeasi metoda se cheama si din Resize(), ca redimensionarea manuala a ferestrei sa mearga.

Atinge un singur fisier, COMUN\clase\omodificari.vc2; nicio schimbare de logica de calcul.

Problema 2 - dialogul de sincronizare apare la iesirea din editare

Nu e o eroare, e comportamentul proiectat - dar proiectarea nu tine cont de cazul din captura.

Declansatorul e in frm_modific2024.inainte_de_do_termin, omodificari.vc2:14434-14451: la fiecare salvare, daca documentul are articole si nu e blocat de eFactura, se recompara rulajele cu articolele si, daca ies divergente, se deschide dialogul. Numaratoarea (:14444) socoteste Modificare, Adaugare si Semnalare.

De ce apare desi nu s-a modificat nimic. Verificarea compara starea documentului, nu modificarile utilizatorului. Un document care era deja desincronizat inainte de deschidere - si captura arata exact asta, verdictul ACT/RUL e "divergent" pe un document neatins - produce divergente la fel ca unul stricat acum. Nu exista nicaieri o comparatie cu starea de la intrare.

De ce e neclar ce cere dialogul. "Cantitate veche / Cantitate noua / Pret vechi / Pret nou" nu inseamna istoric. Inseamna (ofacturare_editare.prg:696-701):

• vechi = ce e acum in cursorul-tinta, adica ce s-ar salva daca apesi Salveaza fara sa sincronizezi;
• nou = ce rezulta din cursorul-sursa, adica din partea aleasa cu butoanele radio de sus.

Cu optiunea implicita ("Rulajul e sursa"), "vechi" = articolele facturii, "nou" = valorile calculate din rulaje. Nimic nu se scrie in Oracle din dialog; "Aplica" muta valorile doar in cursoare, iar "Renunta" nu lasa nimic in urma - salvarea continua oricum (omodificari.vc2:14435-14436, comentariul explica de ce llRet nu se schimba).

Ce mai lipseste in dialog, pe langa declansare: titlul si butoanele sunt cele generice (frm_termin_renunt), nu scrie nicaieri de ce s-a deschis si ce se intampla daca renunti.

Optiuni - decizie de produs, ceruta lui Marius:

#	Varianta	Efect
A	Declansare doar cand divergentele s-au schimbat fata de deschiderea documentului (semnatura calculata o data, in Show)	Documentele deja desincronizate nu mai deranjeaza; ce strici acum se semnaleaza
B	Fara declansare la salvare; ramane doar butonul manual	Cel mai linistit, dar se pierde plasa de siguranta
C	Intrebare simpla da/nu inainte de dialog	Pastreaza semnalarea, scoate formularul din drum
D	Ramane cum e, doar se explica in dialog	Minimul

In toate variantele: text explicativ in capul dialogului ("Articolele facturii difera de rulaje. Vechi = ce se salveaza acum, Nou = ce rezulta din sursa aleasa mai sus. Poti renunta, salvarea continua.") si etichete de butoane pe intelesul actiunii.

Ce nu s-a verificat

Nimic nu a fost rulat. Punctul 2 e citit integral din cod si e sigur. La punctul 1, faptul ca bara de totaluri nu are Anchor e sigur; explicatia pentru grid (reasezarea sarita pe pagina inactiva) e cea singura compatibila cu captura, dar nu a fost confirmata pe ecran - reparatia propusa nu depinde de ea, pentru ca renunta cu totul la Anchor pe PAGE3.