# 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:

1. testul definea `gnPC`, dar **nu si `gnPPretV`** — suitele surori din `achizitie_import` il pun
   la `4` (`test_adauga_factura_ui.prg:167`);
2. cursorul `trul` construit de `CreeazaTrulTest` avea `pretvtva`, dar **nu si `pretv`/`tvav`` —
   campuri pe care tabela reala `RUL` le are (verificat in Oracle, vezi mai jos) si pe care
   `calculeaza_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.