Raport runda 7 — sincronizarea articole-rulaje

Scris 20.08.2026, 22:40. Acopera M1, M2 (dupa corectia de perimetru), rularea celor doua suite si raspunsul la intrebarea de fapt ramasa deschisa.

M1 — sincronizarea porneste doar din buton — GATA

Blocul "al doilea punct de declansare" a fost sters din frm_modific2024.inainte_de_do_termin. Metoda se termina acum la RETURN m.llRet, imediat dupa validarile pe tvd; nu mai exista niciun apel de sincronizare pe drumul salvarii.

AfiseazaDialogSincronizareArticole are un singur apelant ramas: omodificari.vc2:16665, adica butonul pgfArticole.PAGE3.cmdSincronizeazaArticole.Click. Definitia metodei e la :13184.

Ramase fara consumator, semnalate, NEsterse (conform deciziei):

membru	unde
`SemnaturaDivergenteSincronizare` (metoda)	`omodificari.vc2:14829`, declarata `*m:` la `:6820`
`cSemnaturaSincronizare` (proprietate)	declarata `*p:` la `:6831`, valoare initiala `:6870`
atribuirea care le leaga	`:14945`, in `IncarcaArticoleFactura`-ul din ramura cu articole

Proprietatea e scrisa o data si citita niciodata; metoda e apelata doar ca sa alimenteze acea scriere. Ambele sunt acum cod mort, dar functional inofensiv.

Write-back — FACUT si dovedit

txt2vcx.ps1 ... -AllowComun a esuat prima data la fidelity check: subagentul rundei precedente lasase linia 14485 goala, desi in original era \t\t (o linie de spatiere pe care stergerea n-ar fi trebuit s-o atinga). Restaurata la \t\t; diff-ul fata de HEAD e acum exact blocul de 11 linii sters, nimic altceva.

Dovada pe binarul din proiect, nu pe mtime: reconversie vcx2txt.ps1 intr-un cache temporar, md5 identic (d23691466b7017380fe36099943b3208), diff 0 linii. Binare la 22:20:09, text la 22:20:10. Encoding: 6 octeti >0x7F (0xAA, 0xE3, 0xFE — cp1250), zero EF BF BD, CRLF pe toate cele 17 145 de linii.

M2 — `pretv` si `tvav` in rulaj — GATA, perimetru corectat

AplicaModificareTrul (COMUN\programe\ofacturare_editare.prg:926) scrie acum:

REPLACE (m.lcCampCant) WITH m.tnCantitateNoua IN trul
REPLACE pretv WITH m.lnPretv, pretvtva WITH m.lnPretvtva, tvav WITH m.lnTvav IN trul

Cele trei campuri de valoare (valoarev, valtvav, valoarevcTVA) pe care subagentul apucase sa le adauge din varianta initiala a brief-ului au fost scoase, impreuna cu liniile care le calculau (lnValoarecTVA, lnValoareTVA, lnValoareFtva) si cu lnCantitate, ramas nefolosit. LOCAL-urile si comentariile-antet ale ambelor functii (AplicaModificareTrul si AplicaSincronizareArticole) au fost aduse la zi.

Formula e cea canonica din calculeaza_valori_rul, ramura pretvtva (omodificari.vc2:13573-13575), cu gnPPretV pentru preturi — reutilizata, nu reinventata.

.prg, deci fara write-back. Fisierul e ASCII curat, CRLF.

Teste — ambele suite verzi

O suita per apel, .fxp sters inainte de fiecare rulare.

suita	rezultat
`test_s4b_sincronizare.prg`	44 PASS / 0 FAIL, zero erori in log
`test_s4b_dialog.prg`	35 PASS / 0 FAIL, zero erori in log

Prima rulare a picat — fixture, nu cod

test_s4b_sincronizare a dat initial 40 PASS / 2 FAIL, cu erori in log:

EROARE 12 [APLICAMODIFICARETRUL:942] Variable 'GNPPRETV' is not found.
EROARE 12 [APLICAMODIFICARETRUL:947] Variable 'PRETV' is not found.

Ambele vin din harness, nu din codul de productie:

testul definea gnPC, dar nu si gnPPretV — suitele surori din achizitie_import il pun la 4 (test_adauga_factura_ui.prg:167);
cursorul trul construit de CreeazaTrulTest avea pretvtva, dar **nu si pretv/tvav`` — campuri pe care tabela reala RULle are (verificat in Oracle, vezi mai jos) si pe carecalculeaza_valori_rul` le scrie de ani de zile.

Modificari in COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg:

PUBLIC gnPPretV = 4 daca nu exista deja, dupa blocul identic al lui gnPC;
pretv N(14,4) si tvav N(14,4) adaugate in CREATE CURSOR trul;
asserturile C1 1300/1400 verifica si pretv/tvav (pe proc_tvav = 1, adica TVA 0);
caz nou C1 1600, cu TVA 19% real, ca defalcarea sa fie efectiv acoperita: 238 / 2 buc = 119 cu TVA -> pretv 100 + tvav 19. Fara el, toate cazurile din sectiunea C aveau proc_tvav = 1 si tvav ar fi iesit 0 orice s-ar fi scris in formula.

De aici cresterea 42 -> 44 de cazuri.

Intrebarea de fapt: cine recalculeaza `valoarev`/`valtvav`/`valoarevcTVA` dupa sincronizare?

Nimeni. A treia concluzie din cele trei posibile. Se raporteaza ca defect, nu s-a reparat.

Lantul complet, verificat cap-coada:

pas	unde	ce face cu cele trei campuri
incarcare nota	`ofacturare_editare.prg:96-104`	`valoarev`/`valtvav` vin din `vrul_tot`, completate doar daca sunt goale (`WHERE EMPTY(NVL(...,0))`); `valoarevcTVA` e calculat o singura data, `valoarev + valtvav AS valoarevctva`, la construirea `RUL_TEMP` -> `trul`
sincronizare	`ofacturare_editare.prg:947`	scrie `cant`/`cante`, `pretv`, `pretvtva`, `tvav`. Nu le atinge
dupa "Aplica"	`omodificari.vc2:17097`	`ActualizeazaBaraTotaluri()` + refresh grid. Bara doar insumeaza `tvd.valoare` (`:13009`) — nu atinge `trul`
salvare, pas 1	`omodificari.vc2:14379`	`inainte_de_do_termin` pune doar `id_set` pe `trul` si valideaza `tvd`
salvare, pas 2	`ofacturare_comun.vc2:3812-3814`	`Select * From trul Into Cursor RUL_TEMP`, apoi `Replace All id_util..., sters With 0`. Copie verbatim
salvare, pas 3	`oscrie_in_fisiere.prg:131`	`sql_temp_insert('rul_temp','RUL_TEMP')` — bulk insert, fara calcul
salvare, pas 4	`PACK_CONTAFIN.pck:2013`	`INSERT INTO <schema>.RUL (<lista>) SELECT <lista> FROM RUL_TEMP`, lista fiind coloanele reale ale lui `RUL` (`LISTA_CAMPURI`, `:3287`). Fara recalcul
post-procesare	`PACK_CONTAFIN.pck:8601`	`finalizeaza_modificare_nota` renumeroteaza `cod`, atinge `atasamente_vanzari`/`nom_lucrari`. Nimic pe valori

Ce ajunge efectiv gresit in Oracle

Interogat pe MARIUSM_AUTO / ROA_CENTRAL, coloanele reale ale tabelei RUL:

CANT, CANTE, PRETV, PRETVTVA, TVAV, VALOAREV, VALTVAV   (7 din 8 cerute)

VALOAREVCTVA nu e coloana in RUL. Exista doar in cursorul Fox, calculat la incarcare pentru grid si pentru bara de totaluri (csumcolumns) — nu se salveaza nicaieri.

Deci, concret:

VALOAREV si VALTVAV ajung invechite in Oracle. Dupa sincronizare, cantitatea si pretul de pe rand sunt cele noi, iar cele doua valori raman cele dinainte. La o reincarcare ulterioara a notei nu se repara singure: back-fill-ul de la incarcare are garda WHERE EMPTY(NVL(...,0)), deci prinde doar valorile zero, nu si pe cele nenule dar gresite.
VALOAREVCTVA nu ajunge in Oracle deloc, dar ramane invechit in ecran pana la reincarcarea notei: gridul de rulaje si bara de totaluri arata suma veche.

Iesirea manuala exista: daca utilizatorul atinge randul de rulaj in gridul de pe pagina 1, calculeaza_valori_rul recalculeaza toate cele sase campuri deodata (omodificari.vc2:13587). Sincronizarea insa porneste de pe pagina 3 si nu poate apela acea metoda direct — isi alege cursorul din pgfArticole.ActivePage (:13532-13533) si ar scrie in trul_obinv.

Decizia daca se repara si cum e a lui Marius. Nu s-a atins nimic.

7.3 KiB Raw Blame History