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?