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
8.6 KiB
S4b etapa 2 — butonul, dialogul si verificarea la salvare
Continuarea lui handoff intermediar (sters), sectiunea „S4b etapa 2". Diff-ul complet:
diff aplicat (sters) (342 randuri adaugate, 0 sterse, un singur fisier atins:
COMUN\clase\omodificari.vc2).
STARE: WRITE-BACK FACUT, NECOMIS. omodificari.vcx/.vct sunt regenerate (11.08.2026 09:34),
textul e cel canonic FoxBin2Prg. Nimic nu e intr-o stare periculoasa.
| Verificare | Rezultat |
|---|---|
compilare la regenerare (txt2vcx.ps1) |
P1,E0,S1,X0 — 0 erori |
| fidelity check binar -> text -> octeti, in staging | trecut (OK) |
git_sync.ps1 dupa write-back |
0 conversii, 464 la zi, 0 esecuri — text si binar sincrone |
| textul dupa write-back | 342 adaugari, 0 stergeri fata de HEAD |
octeti >0x7F (diacritice cp1250) |
6 inainte, 6 dupa, aceleasi valori (170, 227, 254) |
clasele noi chiar in binar (.vct, nu in text) |
frm_sincronizare_articole x15, propunere_afisata x27, cmdSincronizeazaArticole x3, lblAvertisment x2 |
Prima incercare de write-back a esuat la fidelity check — ordonarea canonica FoxBin2Prg difera
de cea scrisa de mana (intrarile OBJECTDATA ale header-elor de grid se genereaza singure,
ADD OBJECT-urile se sorteaza alfabetic, optDirectie.Click merge dupa Unload). Am adoptat
textul canonic din staging si am reluat — nicio pierdere de continut, diferentele erau doar de
ordine si spatii.
Ce contine
| Piesa | Unde |
|---|---|
butonul cmdSincronizeazaArticole (Left=350, Top=0, W=250, H=22, TabIndex=6) |
ADD OBJECT in PAGE3 |
toggle-ul de Enabled pe lArticoleReadOnly |
frm_modific2024.Show |
cmdSincronizeazaArticole.Click |
frm_modific2024 |
AfiseazaDialogSincronizareArticole |
frm_modific2024 |
| verificarea la salvare | frm_modific2024.inainte_de_do_termin, imediat inainte de RETURN m.llRet |
clasa frm_sincronizare_articole (derivata din frm_termin_renunt) |
la finalul fisierului |
TabIndex 6 e liber in PAGE3 (folosite: 3, 4, 5, 20 — verificat).
Ce am schimbat fata de patch-ul partial al agentului mort
Patch-ul din diff aplicat (sters) era mai complet decat il descria predarea (avea si verificarea la salvare, in metoda corecta). Cinci corectii:
1. Lipsea cmdSincronizeazaArticole.Click — butonul exista, dar nu facea nimic. Adaugat, cu
aceleasi garzi ca la celelalte doua butoane din PAGE3.
2. Gridul ramanea nelegat dupa schimbarea directiei. ConstruiestePropunereSincronizare face
Use In propunere_sincronizare + CREATE CURSOR la fiecare apel (ofacturare_editare.prg:584-589),
deci un grid legat la design-time de acel cursor isi pierde legatura la primul click pe radio.
Solutie: gridul se leaga de propunere_afisata, un cursor cu structura identica creat o
singura data in Load (inainte de instantierea controalelor, ca sa existe cand gridul se leaga) si
doar golit + reumplut la fiecare recalcul. Nicio reasignare de RecordSource la runtime.
3. Declansarea la salvare era pe Reccount(...) > 0 — ar fi deschis dialogul la fiecare
salvare a oricarei facturi cu articole nestocate sau in valuta, pentru ca acelea produc linii N-A
in propunere (contract, punctele 1 si 3). Acum se numara doar
Modificare / Adaugare / Semnalare: divergente reale. N-A inseamna „nu se poate compara", nu
„difera", si nu mai opreste pe nimeni la salvare.
4. Pemstatus(This.oFormArticole, ...) fara garda de tip — oFormArticole are valoarea
implicita .F., iar Pemstatus pe un logic da eroare. Adaugat Vartype(...) == 'O'.
5. Adaugata eticheta de avertisment ceruta de propunere_s4b_sincronizare.md punctul 6
(„Propunere calculata automat - verificati valorile inainte de aplicare"), plus curatarea cursorului
in Unload.
Verificat, nu presupus
| Ce | Cum |
|---|---|
_frmbase.WindowType = 1 (dialogul e modal) |
_frm_base.vc2, blocul PropValue |
do_termin cheama inainte_de_do_termin() si inchide doar pe .T. |
_frm_base.vc2:364-374 |
frm_termin_renunt are But_termin1 + But_renunt1 |
_frm_child.vc2:23-51 |
tiparul apelantului (CreateObject + Show, citirea lui gnButon) |
ofacturare_comun.vc2:4651-4656 |
clasele _optiongrup, _grdrow, _label exista |
_baza.vc2:435, _grd_base.vc2:445 |
InputMask = (get_mask(12,gnPCANT)) e tipar real |
omodificari.vc2:12374 s.a. |
_frm_child.vcx nu are nevoie de SET CLASSLIB |
precedentul frm_modifica_articol_factura |
toate formularele sunt pe DataSession implicit (1) |
niciun DataSession in _frm_base/_baza/omodificari |
SET SAFETY OFF global (pentru ZAP) |
COMUN\programe\proceduri.prg:5 |
| octetii cp1250 din fisier sunt neatinsi | cens >0x7F = 6 inainte si dupa; diff-ul are 0 stergeri |
Netestat: nimic nu a fost rulat. Dialogul e UI, deci nu e testabil -A -T (aceeasi limitare ca
frm_articol_factura, propunere_s4b_sincronizare.md punctul 7). Logica pura din spate ramane
acoperita de test_s4b_sincronizare.prg (35/0), neschimbata de aceasta livrare.
Doua lucruri de confirmat cu Marius
A. Aplicarea la salvare ocoleste validarile deja rulate. Daca utilizatorul apasa „Aplica" in
dialogul deschis la salvare, tvd se modifica dupa ce validarile din
inainte_de_do_termin (pret de achizitie, linii sterse) au trecut deja. Alternativa ar fi
reluarea validarilor dupa aplicare — nu am facut-o, ca sa nu extind scopul.
B. N-A nu mai declanseaza dialogul la salvare (corectia 3). E o alegere de produs facuta de
mine: altfel dialogul ar aparea la fiecare salvare pe documentele in valuta.
B — CONFIRMAT de Marius, 12.08.2026. Ramane cum e, nu se schimba nimic. Numaratoarea de la
omodificari.vc2:14444sta peInlist(Alltrim(actiune),'Modificare','Adaugare','Semnalare'). Pretul acceptat, explicit: pe liniile in valuta si pe cele nestocate o divergenta reala nu mai e semnalata la salvare — se vede in schimb oricand prin butonul manual „Sincronizeaza articole", care le arata in grid.A ramane deschis si si-a schimbat forma — vezi
progres.md, sectiunea despre validarea de cantitate. Plasa de siguranta pe care o propuneam initial nu se mai face: singura validare care ar fi putut pica dupa „Aplica" e cea de cantitate, iar premisa ei e sub semnul intrebarii.
Defect preexistent gasit pe drum — REPARAT (aprobat separat, 11.08.2026)
omodificari.vc2:16495, in frm_modific2024.pgfArticole.PAGE3.cmdAdaugaArticol.Click:
IF !Used('tvd') OR !This.lAreArticoleVanzari OR Thisform.lArticoleReadOnly
This e butonul, nu formularul — lAreArticoleVanzari e proprietate a lui frm_modific2024
(omodificari.vc2:12987, :14788, :14795, :14802 o folosesc corect, toate din metode ale
formularului). VFP scurtcircuiteaza OR: cand tvd exista — adica in exact cazul in care butonul
e activ — primul termen e .F. si se evalueaza al doilea, pe buton, unde proprietatea nu exista.
Nu exista metoda Error in _frmbase/_baza/omodificari care sa inghita eroarea.
Concluzia: „Adauga articol" dadea eroare la orice click real. Suitele existente nu prind asta pentru ca apeleaza metodele formularului, nu simuleaza click-ul.
Nu era una, ci doua. Cautarea sistematica dupa acelasi tipar (proprietati ale formularului
accesate cu This. din metode de obiect) a mai gasit una, in aceeasi metoda, la :16565:
AddProperty(poDate, 'tip', This.nTipVanzare)
Ambele reparate cu Thisform.. In tot frm_modific2024 nu mai exista alta: cautarea a acoperit
lArticoleReadOnly, lAreArticoleVanzari, nIdVanzare, nTipVanzare, pgfArticole,
ActualizeazaBaraTotaluri, AdaugaLinieTvdDinArticol, calculeaza_valori_articol, filtrata pe
metode de obiect (.Click/.Valid/.InteractiveChange/...). Celelalte 4 folosiri ale lui
This.lAreArticoleVanzari sunt in metode ale formularului (ActualizeazaBaraTotaluri, Show)
si sunt corecte.
Nu intra in changelog: 2.11.15 nu e inca in productie, deci e un defect al codului nelivrat.
Changelog
Paragraf nou in blocul 2.11.15 (:nou:), nu versiune noua — 2.11.16 a fost dat inapoi
„pana la punerea in productie" (commit 09f9d47). Descrie butonul, alegerea directiei, liniile
marcate si lasate neatinse, si comparatia de la salvare cu optiunea de a salva fara sincronizare.
Fisierul changelog_roafacturare.txt avea deja un octet stricat in HEAD (EF BF BD, un ©
transformat candva in U+FFFD, in intrarea despre „ROA Romfast SRL"). E preexistent, nu l-am
atins; cenzul ramane 3 octeti >0x7F inainte si dupa editarea mea.
Ce urmeaza
- Rebuild
roafacturare.exedin IDE si testul pe ecran. Metodele.vcxsunt deja compilate detxt2vcx.ps1; EXE-ul nu. - Punctele A si B de confirmat.