# 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: diff aplicat (sters).

## 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: diff aplicat (sters).

## 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".