roafacturare/docs/cercetare/rec_s4_runda3c3.md

S4 sub-blocul C — corectie decizii 36 si 37

Runda scurta de corectie peste ActualizeazaVerdictActRul (COMUN\clase\omodificari.vc2:12978), livrata si testata in rec_s4_runda3c2.md. Doua reguli schimbate, nimic altceva rescris.

Ce s-a schimbat

Decizia 36 — suma RUL doar pe ID_TIP_RULAJ = 0

Formula veche (SUM(cant*pretvtva) + SUM(cante*pretvtva WHERE id_tip_rulaj<>3)) inlocuita cu:

SUM (Nvl(cant,0) + Nvl(cante,0)) * Nvl(pretvtva,0) ;
    TO lnTotalRul FOR Nvl(sters,0) = 0 AND Nvl(id_tip_rulaj,0) = 0

Randurile ID_TIP_RULAJ = 3 (miscari virtuale de diferenta de pret) nu mai intra deloc in suma — nicio euristica de excludere pe potrivire de valoare, doar filtrul semantic cerut.

Decizia 37 — cont de referinta pe rate/contract accepta 4111/411/461

Adaugat un caz nou in DO CASE pe This.nTipVanzare, pentru tip 2/6/52, care seteaza lcCont la o lista delimitata de conturi in loc de un singur cont; comparatiile Alltrim(...) == m.lcCont au fost inlocuite cu (','+Alltrim(...)+',') $ m.lcCont (echivalent cu INLIST, dar pastreaza o singura variabila lcCont in loc sa ramifice codul de sumare). Restul tipurilor de document (avize 461/418, facturi obisnuite) raman pe un singur cont, neschimbate.

Cod

COMUN\clase\omodificari.vc2, metoda ActualizeazaVerdictActRul (linii 13004-13039 dupa editare):

DO CASE
CASE INLIST(This.nTipVanzare, 28, 29)
    lcCont = ',461,'
CASE INLIST(This.nTipVanzare, 21, 22, 24, 26)
    lcCont = ',418,'
CASE INLIST(This.nTipVanzare, 2, 6, 52)
    lcCont = ',4111,411,461,'
OTHERWISE
    lcCont = ',4111,'
ENDCASE
...
SUM (IIF((','+Alltrim(Nvl(scd,''))+',') $ m.lcCont, Nvl(suma,0), ;
    IIF((','+Alltrim(Nvl(scc,''))+',') $ m.lcCont AND !INLIST(Alltrim(Nvl(scd,'')), '5311','5314','5121','5125','5126'), -Nvl(suma,0), 0))) ;
    TO lnTotalAct FOR Nvl(sters,0) = 0
...
SUM (Nvl(cant,0) + Nvl(cante,0)) * Nvl(pretvtva,0) ;
    TO lnTotalRul FOR Nvl(sters,0) = 0 AND Nvl(id_tip_rulaj,0) = 0

Diff complet: docs\diff_s4_runda3c3_decizii_36_37.patch.

Test actualizat

COMUN\utile\Teste\editare_factura\test_verdict_act_rul.prg:

• Calculul manual (SCAN independent) de Total RUL actualizat la noua formula (doar ID_TIP_RULAJ = 0, cant+cante).
• Asertia care astepta "divergent" pe cod=1140895 a fost inversata: acum verifica explicit Total ACT == 1924.59, Total RUL == 1924.59 si verdict "sincronizat" — nu doar egalitatea celor doua totaluri (o asertie care ar trece si daca ambele ar cadea pe zero).
• Asertii noi, prin mutatie in memorie pe cursoarele deja incarcate (fara scriere in Oracle):
  • un rand ID_TIP_RULAJ = 3 cu cantitatea marita cu 1000 nu modifica Total RUL;
  • un rand ID_TIP_RULAJ = 0 cu cantitatea marita cu 1 modifica Total RUL cu exact pretvtva;
  • pe tip=2, contul mutat pe 411 intra in Total ACT (impreuna cu 4111/461);
  • pe tip=6, contul mutat pe 461 intra in Total ACT (impreuna cu 4111/411);
  • pe tip=1 (fara rata), acelasi rand mutat pe 461 NU mai intra — contul ramane strict 4111, verificand ca extinderea nu s-a scapat pe tipurile obisnuite de factura.

Diff complet: docs\diff_s4_runda3c3_test.patch.

Testat

Regresie, headless (vfp9.exe -A -T, watchdog, -AutoDismiss), exit 0, zero dialoguri, rulata DUPA ultima editare de cod (verificat pe mtime: binarele si .prg-ul de test la 18:34/18:39, logurile de test la 18:40-18:42):

Suita	Rezultat	Baseline
test_page3_articole.prg	14 PASS / 2 FAIL	identic (cele 2 = artefact headless cunoscut, datoria 7)
test_incarca_vanzare_din_nota.prg	5 PASS / 0 FAIL	identic
test_adauga_linie_articol.prg	20 PASS / 0 FAIL	identic
test_adauga_linie_valuta.prg	6 PASS / 0 FAIL	identic
test_ui_sterge_linie.prg	8 PASS / 0 FAIL	identic
test_verdict_act_rul.prg	26 PASS / 0 FAIL	(18 inainte de runda; 8 asertii noi)

Pe documentul de test (cod=1140895, descoperit prin DescoperaCazTest('FACTURA_ARTICOLE', ...), deterministic pe schema MARIUSM_AUTO): Total ACT = 1924.59, Total RUL = 1924.59 (dupa excluderea perechilor ID_TIP_RULAJ=3), verdict sincronizat — confirma exact cifra ceruta (121.00 + 2*121.01 + 1259.07 + 302.50 = 1924.59).

Zero scrieri in Oracle (doar SELECT-uri prin goExecutor, mutatii pe cursoare in memorie READWRITE, restaurate la valorile initiale inainte de QUIT).

Cens de octeti si write-back

• Inainte de editare: 2 aa / 2 e3 / 2 fe, zero EF BF BD (verificat pe backup omodificari.vc2.pre_runda3c3.bak, facut inainte de prima editare).
• Editarea cu Edit a stricat din nou cele doua linii cu diacritice ("Renuntare"/"Adaugare"/ "Stergere", liniile 4104 si 8670) — acelasi tipar cunoscut din runda anterioara (FE E3 AA -> 3x EF BF BD). Reparat byte-cu-byte cu Perl, restaurand exact bytes-urile din backup-ul curat.
• Dupa reparare: 2 aa / 2 e3 / 2 fe, zero EF BF BD — identic cu baseline.
• Write-back: txt2vcx.ps1 -AllowComun, OK din prima rulare. .vc2/.vcx/.VCT sincrone (acelasi mtime, 18:34).

Fisiere atinse

• COMUN\clase\omodificari.vc2 (+ .vcx/.VCT, scris in binar) — cele doua reguli din ActualizeazaVerdictActRul.
• COMUN\utile\Teste\editare_factura\test_verdict_act_rul.prg — formula RUL actualizata, asertia inversata pe cod=1140895, 8 asertii noi (excludere ID_TIP_RULAJ=3, includere ID_TIP_RULAJ=0, cele trei conturi rate/contract).
• Backup: COMUN\clase\omodificari.vc2.pre_runda3c3.bak, COMUN\utile\Teste\editare_factura\test_verdict_act_rul.prg.pre_runda3c3.bak (pastrate).

Fara commit (nici git, nici SVN). Zero scrieri in Oracle in toata sesiunea.

Nimic ramas nedovedit

Ambele decizii (36 si 37) sunt implementate exact cum au fost formulate si verificate atat prin recalcul independent (SCAN) cat si prin mutatie directa pe date reale (conturi 411/461 simulate pe un rand existent, cantitati modificate pe rand ID_TIP_RULAJ=3/=0) — nu doar pe "zero cazuri in date".