roafacturare/docs/cercetare/rec_s4_runda3c2.md

S4 runda 3, sub-blocul C — verdictul de corelatie ACT/RUL (partea 2)

Livrat: doua randuri de control (Total ACT, Total RUL) plus un indicator informativ cu 3 stari (sincronizat / divergent / nu se aplica), pe pgfArticole.PAGE3 din frm_modific2024 (COMUN\clase\omodificari.vc2). Formulele erau deja stabilite si verificate in docs\cercetare\rec_suma_act.md — s-au aplicat direct, fara recercetare.

Ce s-a implementat

COMUN\clase\omodificari.vc2, clasa frm_modific2024:

• Metoda noua ActualizeazaVerdictActRul (apelata din ActualizeazaBaraTotaluri, in acelasi punct in care se recalculeaza azi bara — Show(), calculeaza_valori_articol(), cmdStergeArticol.Click, txtDiscountArt.Valid):
  • Total ACT: sold net debit-credit pe cursorul tact deja incarcat, filtrat sters=0 (tact e deja filtrat cod+an+luna de IncarcaCursoareModificareNota — nicio interogare noua). Contul de referinta se alege pe grupa de tip: 461 pentru avize catre clienti debitori (28,29), 418 pentru restul avizelor (21,22,24,26), 4111 pentru restul (facturi, factura din aviz, rate/contract, ROAACNPRO) — simplificare fata de tabelul complet din rec_suma_act.md (acolo contul pentru rate/contract vine teoretic din NOTE_CONTABILE, dar cercetarea a confirmat empiric ca iese mereu 4111; a deschide o interogare noua doar pentru acest caz ar fi contrazis principiul "nu deschide interogare noua daca sumele se pot calcula din cursoarele deja deschise").
  • Total RUL: SUM(cant*pretvtva) + SUM(cante*pretvtva WHERE id_tip_rulaj<>3) pe trul (deja incarcat), corectat cu valoarea liniilor nestocate din tvd (in_stoc=0), convertita in RON la cursul documentului (acelasi curs/multiplicator ca restul barei, decizia 33). Eticheta randului devine "Total RUL (ajustat):" cand corectia s-a aplicat efectiv (corectie <> 0).
  • Indicator informativ, 3 stari: "sincronizat" (|ACT-RUL| <= 0.02), "divergent (informativ, nu e eroare)" (peste toleranta), sau "nu se aplica (informativ, date de import)" — fortat pe tipul 51 (ROAACNPRO), unde cercetarea a stabilit ca divergenta nu e de formula, ci de calitatea datelor de import (rec_suma_act.md, sectiunea D). Toleranta de 0.02 acopera rotunjirile de genul celei documentate pe cod=1138989 (0.01 lei).
  • Ascundere pe tipurile fara suma comparabila (23,25,27,30,41,42,47, decizia 22): cele 5 controale noi se ascund odata cu restul barei, pe acelasi flag !llAscunde transmis ca parametru — nu se dubleaza lista de tipuri in doua locuri.
• 8 controale existente + 5 noi pe PAGE3: lblTotalActArt/txtTotalActArt, lblTotalRulArt/txtTotalRulArt (Top=132/136, al doilea rand sub bara existenta), si lblVerdictArt (text + culoare setate direct in cod, dupa modelul Visible-urilor existente — Label nu suporta ControlSource pentru Caption).
• Randul 2 a cerut spatiu vertical nou: pgfArticole.Height 142->164, frm_modific2024.Height 508->530 (+22px, acelasi delta pe ambele, ca pageframe-ul sa nu depaseasca formularul), si cele 4 butoane din coloana din dreapta (But_copiazaR, But_modificaR, But_stergeR, but_afiseaza_rulaje) mutate cu acelasi +22px, ca sa ramana la aceeasi distanta vizuala fata de cadrul pgfArticole (Anchor=12, bottom+right, dar editarea e statica — anchor-ul VFP nu recalculeaza pozitia la o simpla schimbare de Height in clasa, doar la un resize la runtime). Verificat pe cod ca nimic altceva nu depinde de valorile vechi (resize_grid1 foloseste 284 fix cand pgfArticole e vizibil, si This.Height - 100 cand e ascuns — ambele raman corecte, a doua chiar beneficiaza de cei 22px in plus). Grid-ul grdArticoleFactura (Height=81) nu s-a atins — 0 linii pierdute, la fel ca la partea 1.

COMUN\programe\ofacturare_editare.prg:

• tvd capata coloana noua in_stoc I NULL, in ambele locuri unde structura cursorului se repeta (CreeazaCursorArticoleGol si Load() ramura ELSE din omodificari.vc2).
• IncarcaArticoleFactura extinde interogarea existenta (nu adauga una noua) cu left join nom_articole na on na.id_articol = v.id_articol, proiectand na.in_stoc — view-ul VVANZARI_ARTICOLE nu expune IN_STOC (verificat pe cod, confirmat pe date printr-un probe live).

Verificat pe cod / pe date, nu presupus

• Coloanele reale ale tact/trul/tvd au fost verificate live pe schema (MARIUSM_AUTO, document cod=1140895/an=2026/luna=8, tip=1) inainte de a scrie codul: tact are SCD/ASCD/SCC/ASCC/SUMA/STERS/AN/LUNA/COD, trul are CANT/CANTE/PRETVTVA/ID_TIP_RULAJ/STERS, ambele exact ca in rec_suma_act.md. Scriptul de probe (test_probe_columns.prg) a fost sters dupa verificare — nu face parte din suita permanenta.
• Comparatia de cont foloseste == pe Alltrim(), nu = simplu — VFP cu SET EXACT OFF (implicit) ar fi potrivit '411' ca prefix al lui '4111' cu un = simplu, exact capcana semnalata in cercetare ("411 vs 4111").

Descoperire pe parcurs: randuri RUL "duplicat" schimba verdictul pe documentul de test

Documentul folosit pentru testul dedicat (cod=1140895, descoperit prin DescoperaCazTest) are exact tiparul semnalat ca intrebare deschisa in rec_suma_act.md sectiunea F punctul 3: perechi ID_TIP_RULAJ=3 (diferenta de pret) insotite de randuri ID_TIP_RULAJ=0 cu aceeasi cantitate/pret ca randul-partener din pereche. Aplicand formula exact cum e specificata (SUM(cant*pretvtva) + SUM(cante*pretvtva WHERE id_tip_rulaj<>3), fara nicio excludere suplimentara), rezultatul pe acest document e 3728.18, in timp ce Total ACT (si VANZARI.TOTAL_CU_TVA) e 1924.59 — deci verdictul iese "divergent" desi documentul e, de fapt, corect emis. Cercetarea anterioara (E.4) aratase ca EXCLUDEREA randurilor "duplicat" inchide exact diferenta, dar aceasta excludere nu a fost inclusa in formula finala transmisa (a ramas intrebare deschisa, nu decizie). Am implementat formula asa cum a fost specificata in brief/decizii, fara sa adaug o regula de excludere nedecisa — testul nou confirma ca implementarea calculeaza exact ce scrie formula (verificat prin recalcul independent, SCAN separat de codul din clasa), iar "divergent" pe acest tip de document e comportamentul asteptat si documentat, nu un bug. Ramane o intrebare pentru Marius: se decide excluderea randurilor ID_TIP_RULAJ=0 care dubleaza exact un rand din perechea 3 (ar inchide acest caz), sau ramane asa cum e acum (informativ, divergenta posibila pe documentele cu acest tipar de date)?

Limitare cunoscuta, in afara perimetrului

Liniile adaugate manual in aceeasi sesiune (AdaugaLinieTvdDinArticol, sub-blocul B) nu primesc in_stoc — selectorul caut_articol() (decizia 34) nu carrying stocul articolului. Pana la salvarea si reincarcarea notei, o linie noua e tratata implicit ca stocata (Nvl(in_stoc,1)=1, fara corectie). Nu a fost atins AdaugaLinieTvdDinArticol — in afara scopului acestei livrari.

Testat

Regresie, headless, vfp9.exe -A -T, watchdog, exit 0, zero dialoguri, identic cu baseline-ul de plecare (handoff intermediar (sters)):

• test_page3_articole.prg: 14 PASS / 2 FAIL (cele 2 = artefactul headless cunoscut de la datoria 7, neschimbat).
• test_incarca_vanzare_din_nota.prg: 5 PASS / 0 FAIL.
• test_adauga_linie_articol.prg: 20 PASS / 0 FAIL (linia REZULTAT din log — grep brut pe "PASS"/"FAIL" da 21/1 din cauza ca linia de sumar contine ambele cuvinte; cifra corecta e cea din REZULTAT).
• test_adauga_linie_valuta.prg: 6 PASS / 0 FAIL.
• test_ui_sterge_linie.prg: 8 PASS / 0 FAIL.

Suita noua, COMUN\utile\Teste\editare_factura\test_verdict_act_rul.prg, pe documentul descoperit prin proprietate (FACTURA_ARTICOLE, nu ancorat pe cod): 18 PASS / 0 FAIL (REZULTAT in log). Acopera: calculul Total ACT si Total RUL verificat prin recalcul independent (SCAN, cod separat de metoda testata); marcajul "(ajustat)" cand corectia pe linii nestocate s-a aplicat; textul verdictului informativ, niciodata prezentat ca eroare de sine statatoare; starile sincronizat/divergent; tratamentul special tip=51 (verdict fortat "nu se aplica", cifrele raman vizibile); ascunderea celor 5 controale pe transfer (23) si custodie (42); alegerea contului pe grupa de tip (28→461, 21→418); corectia sintetica pe linie fortata in_stoc=0 (creste Total RUL exact cu valoarea liniei convertita in RON).

Zero scrieri in Oracle in toata sesiunea (doar SELECT-uri prin goExecutor si cursoare in memorie). Date de test (MARIUSM_AUTO) — divergenta gasita pe documentul de test e un caz izolat documentat mai sus, nu o dovada ca formula e gresita pe restul datelor.

Cens de octeti si write-back

• Inainte: 2 aa / 2 e3 / 2 fe, zero EF BF BD.
• In timpul editarii: fiecare scriere cu Edit a stricat din nou cele doua linii cu diacritice (Renunțare/Adăugare/Ștergere, censul a urcat la 6 ef/6 bf/6 bd) — reparat byte-cu-byte cu Perl, folosind bytes-urile corecte din backup-ul omodificari.vc2.pre_verdict.bak (facut inainte de prima editare).
• Final: 2 aa / 2 e3 / 2 fe, zero EF BF BD — identic cu baseline-ul.
• Write-back: txt2vcx.ps1 -AllowComun. Prima rulare a picat fidelity check-ul (diferenta era doar formatarea liniilor goale din metoda noua — spatii vs tab-uri, capcana deja cunoscuta), rezolvata prin adoptarea textului regenerat din staging ca sursa canonica (verificat ca are acelasi cens de octeti inainte de a-l adopta). A doua rulare: OK. .vc2/.vcx/.VCT sincrone (acelasi mtime, svn status arata M pe .vcx/.VCT, I pe .vc2 — ignorat de SVN, urmarit doar in git).

Fisiere atinse

• COMUN\clase\omodificari.vc2 (+ .vcx/.VCT, scris in binar) — metoda noua ActualizeazaVerdictActRul, apel din ActualizeazaBaraTotaluri, 5 controale noi pe PAGE3, proprietati noi (ntotalactron, ntotalrulron, lrulajustat), redimensionare pgfArticole + formular + 4 butoane din dreapta.
• COMUN\programe\ofacturare_editare.prg — in_stoc in tvd (structura + interogare).
• COMUN\utile\Teste\editare_factura\test_verdict_act_rul.prg (nou) — suita dedicata.
• Backup: COMUN\clase\omodificari.vc2.pre_verdict.bak, COMUN\programe\ofacturare_editare.prg.pre_verdict.bak (pastrate).

Diff-uri

• diff aplicat (sters) — omodificari.vc2 (fata de .pre_verdict.bak).
• diff aplicat (sters) — ofacturare_editare.prg, izolat.

Fara commit (nici git, nici SVN).

Intrebari ramase pentru Marius

1. Randurile RUL "duplicat" (ID_TIP_RULAJ=0 care dubleaza exact un rand din perechea 3) — se exclud din formula (ar inchide cazuri ca cel gasit pe cod=1140895), sau ramane formula literala asa cum a fost decisa, cu riscul asumat de "divergent" pe aceste documente? Vezi sectiunea dedicata de mai sus.
2. Cont pentru rate/contract (tip 2,6,52 cu id_rata<>0): s-a folosit simplificarea 4111 (empiric confirmat, dar nu derivat din NOTE_CONTABILE). Ramane acceptabil, sau merita o interogare dedicata intr-o runda viitoare?