Brief de implementare — runda 7: sincronizarea articole-rulaje

Doua cereri ale lui Marius, 20.08.2026 (dupa proba pe ecran a rundei 6):

sincronizarea sa porneasca doar din buton, nu sa se mai arate la terminarea editarii;
la directia ARTICOLE_SURSA (articole -> rulaj) se copiaza pretvtva, dar nu si pretv si tvav, care raman vechi.

Interdictii (citeste-le inainte de orice)

NU rula git_sync.ps1, roa_sync.bat, svn update, svn commit, svn revert, git commit, git push, git stash, git checkout.
NU atinge COMUN\clase\ofacturare_comun.vc2 — are o livrare separata, verificata, necomisa. Orice scriere acolo distruge munca altcuiva.
NU atinge PL/SQL, nu te conecta la Oracle pentru scriere.
Fisierele tale, singurele: COMUN\clase\omodificari.vc2 (+ binarul prin write-back), COMUN\programe\ofacturare_editare.prg, si raportul docs\raport_r7_sincronizare.md.
Esti singurul scriitor pe ele. Daca gasesti alte modificari necomise acolo, opreste-te si raporteaza.

M1 — sincronizarea porneste doar din buton

COMUN\clase\omodificari.vc2, metoda inainte_de_do_termin a clasei frm_modific2024, blocul de la :14484-14494 (numerele se deplaseaza dupa prima editare — confirma cu vfp_symbols.ps1 -Where):

		*!* al doilea punct de declansare al sincronizarii: enumerarea diferentelor la salvare, cu
		*!* continuarea salvarii daca utilizatorul renunta - de aceea llRet nu se schimba aici;
		*!* pe document fara linii active nu porneste: propunerea ar marca toata sursa ca "Adaugare"
		IF m.llRet AND This.lAreArticoleVanzari AND !This.lArticoleReadOnly AND Used('tvd') AND m.lnLiniiActive > 0
			LOCAL lcSemnaturaAcum
			lcSemnaturaAcum = This.SemnaturaDivergenteSincronizare()
			*!* doar divergentele aparute in sesiunea curenta deschid dialogul; N-A nu intra in semnatura
			IF !Empty(m.lcSemnaturaAcum) AND !(m.lcSemnaturaAcum == This.cSemnaturaSincronizare)
				This.AfiseazaDialogSincronizareArticole()
			ENDIF
		ENDIF

Se sterge integral, cu tot cu cele patru linii de comentariu. RETURN m.llRet de dupa ramane. Nu atinge butonul pgfArticole.PAGE3.cmdSincronizeazaArticole.Click (:16671) — el ramane singura cale de pornire.

Nu sterge metoda SemnaturaDivergenteSincronizare, proprietatea cSemnaturaSincronizare si atribuirea ei de la :14956. Dupa aceasta stergere raman fara consumator — semnaleaza asta in raport, ca decizia de curatare sa fie a lui Marius, dar nu o lua tu.

M2 — `pretv` si `tvav` se recalculeaza la scrierea in rulaj

COMUN\programe\ofacturare_editare.prg, FUNCTION AplicaModificareTrul (:924). Azi:

			lcCampCant = IIF(Nvl(cant,0) <> 0, 'cant', 'cante')
			REPLACE (m.lcCampCant) WITH m.tnCantitateNoua, pretvtva WITH m.tnPretNouCuTva IN trul

Formula corecta exista deja si e sursa de adevar — nu inventa alta: omodificari.vc2, calculeaza_valori_rul, ramura pretvtva (:13566-13587):

lnProcTvav    = IIF(EMPTY(proc_tvav), 1, proc_tvav) - 1                          && 1.19 -> 0.19
lnTVAv        = ROUND(lnPretVtva * lnProcTVAv / (1 + lnProcTvav), gnPPretv)
lnPretv       = lnPretvtva - lnTvav
lnValoarecTVA = ROUND(lnCantitate * lnPretvTva, gnPC)
lnValoareTVA  = ROUND(lnValoarecTVA * lnProcTVAv / (1 + lnProcTvav), gnPC)
lnValoareFTva = lnValoareCtva - lnValoareTVA
REPLACE pretv, pretvtva, tvav, valoarev, valtvav, valoarevcTVA

Atentie la precizii, sunt doua diferite: pretv/tvav/pretvtva se rotunjesc la gnPPretV (precizia pretului de vanzare), iar valoarev/valtvav/valoarevcTVA la gnPC.

Nu apela toForm.calculeaza_valori_rul() in locul calculului: metoda alege cursorul din This.pgfArticole.ActivePage (:13532-13533) — trul doar cand pagina activa e 1. Sincronizarea porneste de pe pagina 3, deci ar nimeri trul_obinv. Calculeaza in AplicaModificareTrul, unde esti deja pozitionat pe randul corect din trul.

Ordinea conteaza: cantitatea se scrie inainte de a citi cant/cante pentru valori, altfel valorile ies pe cantitatea veche.

Include si valoarev, valtvav, valoarevcTVA. Marius a numit doar pretv si tvav, dar sincronizarea schimba si cantitatea, iar cele trei valori depind de cantitate x pretvtva; lasate nescrise raman la fel de vechi ca pretv. E semnalat lui ca depasire fata de cerere.

Actualizeaza si comentariul-antet al lui AplicaSincronizareArticole (:787-794), care azi spune "ARTICOLE_SURSA scrie doar cant/pretvtva pe randul RUL deja existent" — a devenit fals.

Teste — obligatoriu, nu optional

Exista suite care acopera exact zona atinsa:

COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg (42 cazuri; sectiunea C e chiar AplicaSincronizareArticole pe directia ARTICOLE_SURSA, care scrie in trul)
COMUN\utile\Teste\editare_factura\test_s4b_dialog.prg (35 cazuri)

Ruleaza-le pe amandoua dupa modificari. Reguli platite deja, respecta-le:

sterge .fxp-ul inainte de fiecare rulare, altfel se executa bytecode vechi;
o singura suita per apel de comanda — doua rulari inlantuite in acelasi apel atarna;
cifra se ia numarand liniile PASS/FAIL din log, iar dovada ca rularea a ajuns la capat e linia de REZULTAT; fara ea rularea a fost taiata, indiferent ce zice orice raport. (Linia de REZULTAT contine ea insasi cuvintele PASS si FAIL — un Select-String naiv raporteaza cu unu mai mult din fiecare.)

Daca sectiunea C pica pentru ca astepta vechiul comportament (doar cant/pretvtva), asta e asertiune invechita, nu regresie: actualizeaz-o si spune explicit in raport ce ai schimbat si de ce. Daca pica altceva, nu modifica testul — raporteaza.

Detalii de mediu si capcane: COMUN\docs\depanare_testare_vfp.md, COMUN\docs\testare-ui-vfp.md.

Encoding si write-back (doar pentru `.vc2`)

.vc2 e CRLF pe toate liniile si are diacriticele in cp1250. Numara octetii >0x7F inainte si dupa; trebuie acelasi numar, si zero EF BF BD. .prg se editeaza normal.
Dupa editarea .vc2: txt2vcx.ps1 imediat (se ruleaza direct, fara aprobare):

powershell -ExecutionPolicy Bypass -File D:\ROA\UTIL\foxbin2prg\txt2vcx.ps1 `
  -TextFile 'D:\ROA\ROAFACTURARE\COMUN\clase\omodificari.vc2' `
  -ProjectRoot 'D:\ROA\ROAFACTURARE' -CacheRoot 'D:\ROA\ROAFACTURARE' -AllowComun

daca fidelity-check-ul pica pe ordine, adopta textul din <staging>\verify\;
dovada de sincronizare: reconverteste binarul intr-un cache temporar cu vcx2txt.ps1 -Source ... -CacheRoot <temp> -Force si fa diff cu textul din arbore -> 0 linii diferenta. mtime nu dovedeste nimic.
Inainte de write-back verifica sa nu ruleze vfp9.exe (Get-Process vfp9) — tine binarul blocat. Daca ruleaza, nu-l omori: opreste-te si anunta-ma.

Ce raportezi

Scrie pe disc, la D:\ROA\ROAFACTURARE\docs\raport_r7_sincronizare.md, si raspunde in chat doar cu GATA <cale>. In raport: inventarul cu fisier:linie pe numerotarea finala; confirmarea write-back-ului cu numarul de linii diferenta la reconversie; octetii >0x7F inainte/dupa; cifrele de test luate din log (PASS/FAIL + prezenta liniei REZULTAT), pe fiecare suita; ce asertiuni ai schimbat si de ce; ce n-ai putut face.

Daca te apropii de ~200-250k tokens de context, opreste-te la o stare consistenta pe disc (write-back facut), scrie raportul cu ce ramane, si anunta.

7.3 KiB Raw Blame History