docs: runda 6 - cercetari, propuneri si conventia mediului Oracle

Cercetarile si propunerile rundelor 4-6 pe editarea facturii emise. Starea
rundei 6 si ce s-a stabilit intra in progres.md.

Nou: docs/conventii_mediu_oracle.md - pe dev/test se lucreaza numai cu
ROA_CENTRAL si schemele CONTAFIN_ORACLE si MARIUSM_AUTO; schema ACN nu se
foloseste. Scripturile de pachet sunt necalificate, deci schema tinta o
decide sirul de conectare, nu fisierul.

roafacturare.pj2 regenerat de git_sync.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013gYCNE26G1G7UoGu2ju7aS

docs/diagnostic_pagina_articole_ux.md

@@ -0,0 +1,109 @@
+# 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.