Files
roafacturare/docs/rec_s4b_etapa2.md
Marius Mutu ca3c5d7eea 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
2026-08-20 16:35:03 +03:00

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:14444 sta pe Inlist(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

  1. Rebuild roafacturare.exe din IDE si testul pe ecran. Metodele .vcx sunt deja compilate de txt2vcx.ps1; EXE-ul nu.
  2. Punctele A si B de confirmat.