Marius Mutu
ca3c5d7eea
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
110 lines
6.7 KiB
Markdown
110 lines
6.7 KiB
Markdown
# 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.
|