# S4 — doua defecte pe pagina de articole: culoarea liniei sterse + valuta liniilor noi (09.08.2026)

Doua defecte raportate dupa livrarea sub-blocului B (stergere + adaugare de linii). Ambele in
`COMUN\clase\omodificari.vc2` (`frm_modific2024`, `pgfArticole.PAGE3`); al doilea atinge si
`COMUN\programe\ofacturare_editare.prg`. **Ambele REZOLVATE, dovedite, scrise in binar,
necomise.**

## Defectul 1 — marcajul vizual `DynamicForeColor` nu se aplica pe linia stearsa

### Cauza reala (nu ipoteza de start, confirmata pe cod)

`grdArticoleFactura` e definit ca `ADD OBJECT 'pgfArticole.PAGE3.grdArticoleFactura' AS _grdrow`
(`omodificari.vc2:12306`), unde `_grdrow` (`COMUN\clase\_grd_base.vc2:445-489`) e o clasa a suitei
comune (nu proprietatea acestei livrari — doar citita) care evidentiaza linia curenta a gridului:

```
PROCEDURE Init
	DoDefault()
	If This.nRgbrow = 1
		...
		This.SetAll("DynamicForeColor","iif(RECNO() = This.nRecno,RGB(" + This.cRGB_Font + "),RGB(0,0,0))","Column")
	Endif
ENDPROC
```

`nrgbrow` implicit e `1`. La instantiere, dupa ce `PropValue`-urile clasei (inclusiv
`Column1..14.DynamicForeColor = "IIF(tvd.sters=1,RGB(150,150,150),RGB(0,0,0))"`) sunt aplicate,
`Init` ruleaza si **`SetAll` suprascrie necondiționat** `DynamicForeColor` pe toate cele 14
coloane cu o expresie care ignora `tvd.sters` complet — de-asta linia stearsa avea pixeli negri
puri (0,0,0), nu gri (150,150,150): codul din clasa era corect, dar era deja inlocuit inainte de
primul `Refresh()`.

Ipoteza de start din briefing ("`_grdrow.Init` castiga in fata lui `DynamicForeColor`") s-a
confirmat exact, cu mecanismul precis identificat (`SetAll` in `Init`, nu doar `AfterRowColChange`).

### De ce nu solutia gridurilor surori

`grdRulaje`/`grdRulajeObinv` (`pgfArticole.PAGE1`/`PAGE2`) rezolva coliziunea cu `Init` **gol**
(`*Nu sterge`, `omodificari.vc2:~15659`/`~15926`) — asta taie tot lantul `DoDefault()`, deci si
`_grid.Init()` (cel care seteaza `ReadOnly` pe coloanele text dupa `lcamptextneeditabil`).
`grdArticoleFactura` are nevoie sa ramana editabil pe `cantitate`/`pret`/`pret_cu_tva`
(`lcamptextneeditabil=.F.`, fix din sesiunea anterioara) — un `Init` gol ar fi rupt din nou
editabilitatea.

### Fix

O singura proprietate pe `ADD OBJECT`-ul gridului (`omodificari.vc2:12317`):

```
nrgbrow = 0, ;
```

`nrgbrow=0` scurt-circuiteaza intreg blocul `If This.nRgbrow = 1` din `_grdrow.Init` (deci si
`SetAll`) **fara sa taie** `DoDefault()` -> `_grid.Init()` — editabilitatea ramane intacta.
Tiparul e deja folosit in **20+ griduri** din suita comuna (`COMUN\clase\configurare.vc2`,
`COMUN\clase\onomenclatoare.vc2`), deci nu e o solutie inventata pentru acest caz — e conventia
existenta pentru "grid cu culoare proprie pe randuri, fara evidentierea implicita a liniei
curente".

### Dovada — esantionare de pixeli, nu vizual

Doua capturi noi, sub `vfp_ui_harness.ps1 -SyncDir` explicit (capcana de sincronizare deja
rezolvata in sesiunea precedenta):

- `COMUN\utile\Teste\editare_factura\screenshots_after_fix_culoare\step_0_contrast_gri_vs_negru.png`
  — document cu 4 linii (`cod=1140895`/`id_vanzare=1050`), linia 2 marcata stearsa prin
  `cmdStergeArticol.Click()`, linia curenta a gridului mutata pe linia 3 (`GO 3` +
  `loGrid.SetFocus()`) ca selectia (fundal albastru) sa nu acopere nici linia stearsa, nici o
  linie de control. Esantionare cu `System.Drawing.Bitmap.GetPixel` pe banda de text a fiecarei
  linii (PowerShell, cautare pixel cu luminanta minima in regiune):

  | Linie | Pixel cel mai inchis (RGB) |
  |---|---|
  | Linia 1 (normala, `sters=0`) | `(0,0,0)` |
  | **Linia 2 (STEARSA, `sters=1`)** | **`(150,150,150)`** — exact `RGB(150,150,150)` din `DynamicForeColor` |
  | Linia 4 (normala, `sters=0`) | `(0,0,0)` |

- `COMUN\utile\Teste\editare_factura\screenshots_after_fix_culoare\step_0_linia_grizata.png` —
  document cu 2 linii (`cod=1139934`/`id_vanzare=882`), aceeasi verificare, acelasi rezultat
  (`RGB(150,150,150)` pe linia stearsa).

Capturile "before" (linia stearsa cu pixeli negri puri, dovada defectului inainte de fix), mutate
din sesiunea anterioara: `screenshots_before_fix_culoare\step_0_linia grizata dupa sters.png` +
`step_0_crop_zoom.png`.

### Testat, regresie

`test_ui_sterge_linie.prg` (existent, nemodificat in logica — doar rerulat): **8 PASS / 0 FAIL**,
log complet pana la `REZULTAT`. `test_page3_articole.prg`: **14 PASS / 2 FAIL** (identic cu
baseline, cele 2 FAIL sunt artefactul headless cunoscut de la datoria 7 — `ColumnCount`/`ReadOnly`
nu se materializeaza sub `-A -T`). `test_incarca_vanzare_din_nota.prg`: **5 PASS / 0 FAIL**.

Suita noua `test_ui_culoare_contrast.prg` (dedicata acestui fix, ramane in suita de regresie):
descopera dinamic un document cu minim 3 linii (`DescoperaCazTest('FACTURA_ARTICOLE', ...)`,
nu ancorat pe `cod`), marcheaza a doua linie stearsa, muta linia curenta pe a treia, face captura.
**1 PASS / 0 FAIL** pe asertia functionala (`sters=1` dupa click); dovada vizuala e in captura +
esantionarea de pixeli de mai sus, nu intr-o asertie automata (culoarea nu se poate verifica prin
`EVALUATE` in interiorul testului — eroarea 1929, deja documentata in `rec_s4_runda3b2.md`).

## Defectul 2 — liniile adaugate intrau fortat in RON

### Cauza reala (diferita de formularea initiala din briefing)

Briefingul presupunea ca `AdaugaLinieTvdDinArticol` scrie `tip_valuta = 0` fix — **verificat pe
cod, fals**: `tvd` (structura din `CreeazaCursorArticoleGol`, `ofacturare_editare.prg:268-271`) nu
are deloc un camp `tip_valuta`, `curs` sau `multiplicator` — acele campuri nu exista in view-ul
`VVANZARI_ARTICOLE` (linia stocheaza doar `id_valuta`, o referinta la `nom_valute`, fara factor de
conversie propriu).

Cauza reala e in alta parte: `tip_valuta=0`/`Curs=1`/`multiplicator=1` sunt hardcodate pe
**`poArticol`** in `CreeazaPoArticolNouTvd` (`ofacturare_editare.prg:429-431`), iar
`poDate.in_valuta` e hardcodat `0` in `cmdAdaugaArticol.Click` (`omodificari.vc2:16190`) — asta
tine dialogul `frm_articol_factura` in **modul RON** indiferent de valuta reala a documentului.
Dialogul calculeaza `pretftva`/`pretctva` (campurile RON) pe baza a ce introduce utilizatorul, iar
`AdaugaLinieTvdDinArticol` scria acele valori **neconvertite** in `tvd.pret`/`tvd.discount_unitar`.

Bara de totaluri (`ActualizeazaBaraTotaluri`, decizia 33, `omodificari.vc2:12856-12899`) insumeaza
`tvd.valoare` **brut** (`SUM valoare FOR sters<>1`) si aplica **o singura data**
`tvanz.curs`/`multiplicator` pe suma — asta presupune ca fiecare linie e deja stocata in valuta
documentului, nu in RON. Verificat pe date (schema `MARIUSM_AUTO`):

| `id_vanzare` | `VANZARI.in_valuta` | `VANZARI.id_valuta` | `curs` | linia (`VANZARI_DETALII.pret`) |
|---|---|---|---|---|
| 1037 | 1 | 2 (EURO) | 5.2688 | `pret=200` — 200 EUR brut, nu 200 RON |

O linie noua scrisa in RON (ex. utilizatorul intentioneaza 1053.76 RON) ar fi ramas `pret=1053.76`
in `tvd`, iar bara de totaluri ar fi calculat `1053.76 * 5.2688 = 5551.6` RON — de peste 5 ori
valoarea reala.

### Fix — scopat strict pe stocare, fara sa ating dialogul

`frm_articol_factura`/`ofacturare.vc2` **nu sunt in proprietatea acestei livrari** (partajate cu
tot restul suitei), si a face dialogul sa accepte pret direct in valuta ar cere
`poDate.id_valuta`/`poDate.zi_curs` populate corect (altfel validarea interna a dialogului
respinge la "Terminare" cu mesaj — verificat pe cod, `ofacturare.vc2:9484,9490`) — netestabil
headless (`Show()` e modal) si risc pe o clasa mare, necunoscuta. Fix ales, minim si sigur:

1. **`tvanz` extins** cu `in_valuta`, `id_valuta`, `nume_val` (join nou pe `nom_valute` in
   `IncarcaVanzareNota`, `ofacturare_editare.prg:150-176`; `CreeazaCursorTvanzGol` la fel).
2. **`AdaugaLinieTvdDinArticol` (`omodificari.vc2:12901-12934`) converteste** pretul/discountul
   calculate de dialog (RON) in valuta documentului, inainte de a le scrie in `tvd`:
   `pret = pretRON * tvanz.multiplicator / tvanz.curs` (si simetric pentru `discount_unitar`) —
   inversul exact al formulei din bara de totaluri, deci **no-op pe documente RON**
   (`curs=multiplicator=1`, verificat neregresat pe suita existenta).
3. **`id_valuta`/`nume_val` ale liniei noi preiau valorile de pe `tvanz`** (`tvanz.id_valuta`,
   `tvanz.nume_val`) in loc de `.Null.`/gol — simetric cu liniile existente, care le au populate
   din `VVANZARI_ARTICOLE`.

**Limitare ramasa, de raportat explicit**: dialogul **tot lucreaza in RON** — utilizatorul introduce
pretul in RON chiar si pe un document in valuta, iar conversia se face "in spate", la scriere.
STOCAREA e acum corecta valutar (bara de totaluri calculeaza corect regardless de valuta
documentului), dar UX-ul de introducere a pretului direct in valuta nu e implementat — ar cere
atingerea `ofacturare.vc2`, in afara scope-ului primit ("nu era ceruta multi-valuta in briefing" —
decizie mostenita din sub-blocul B partea 2, `rec_s4_runda3b2.md`).

### Testat

- `test_page3_articole.prg`: **14 PASS / 2 FAIL** (identic cu baseline).
- `test_incarca_vanzare_din_nota.prg`: **5 PASS / 0 FAIL**.
- `test_adauga_linie_articol.prg` (existent, caz RON): **20 PASS / 0 FAIL** — confirma ca
  conversia e no-op cand `curs=multiplicator=1`, nicio regresie pe calea deja acoperita.
- **Suita noua** `test_adauga_linie_valuta.prg`: foloseste un document real cu articole
  (descoperit dinamic, nu ancorat pe `cod`), dar suprascrie manual `tvanz.curs=5.2688`,
  `multiplicator=1`, `in_valuta=1`, `id_valuta=2`, `nume_val='EURO'` dupa `Show()` — nu exista in
  schema un caz descoperibil simultan "cu articole" si "in valuta reala" (`id_vanzare=1037`, EURO,
  are o singura linie, nefolosibila pentru un test de "adaugare langa liniile existente" fara
  ambiguitate). Construieste `poArticol` cu `pretftva=1053.76` (echivalentul RON a 200 EUR la
  cursul testat) si verifica: **6 PASS / 0 FAIL** —
  `tvd.pret` convertit la `200.00`, `id_valuta=2`, `nume_val='EURO'`, `tvd.valoare=200.00`, iar
  bara de totaluri creste cu exact `1053.76` RON (echivalentul corect, nu suma bruta).

## Cens de octeti si write-back

Baseline la inceputul sesiunii: `2 aa / 2 e3 / 2 fe`, zero `EF BF BD`. Primul `Edit` pe
`omodificari.vc2` (adaugarea `nrgbrow = 0`) a reencodat tot fisierul, stricand din nou cele doua
linii `Caption = "CTRL+F = Terminare; ESC = Renunțare; CTRL+N = Adăugare; CTRL+D = Ștergere"`
(capcana deja cunoscuta, lovita si in sesiunile precedente) — cens dupa: `6 ef / 6 bf / 6 bd`.
Reparat byte-cu-byte cu Perl (pozitional: octetul 1 din fiecare tripleta `EF BF BD` -> `0xFE`
(ț), octetul 2 -> `0xE3` (ă), octetul 3 -> `0xAA` (Ș), ciclic pe cele 2 linii x 3 caractere).
Cens final, verificat inainte si dupa `txt2vcx.ps1`: **identic cu baseline, `2 aa/2 e3/2 fe`, zero
`EF BF BD`**.

`ofacturare_editare.prg` e ASCII pur (verificat, zero octeti >0x7F) — fara risc de encoding, nu
necesita reparare.

**Fidelity-check trecut din prima incercare** (`txt2vcx.ps1 -AllowComun`, un singur fisier
regenerat) — spre deosebire de sesiunile precedente, nu a fost nevoie sa adopt textul regenerat
din `<staging>\verify\`.

## Fisiere atinse, stare write-back

| Fisier | Stare |
|---|---|
| `COMUN\clase\omodificari.vc2` | Editat (`nrgbrow=0` pe grid + `AdaugaLinieTvdDinArticol` rescrisa), write-back FACUT, fidelity check OK din prima, cens OK |
| `COMUN\clase\omodificari.vcx` / `.VCT` | Scrise, mtime sincron cu `.vc2` (16:59) |
| `COMUN\clase\omodificari.vc2.pre_fix_culoare.bak` | Backup, luat la inceputul sesiunii |
| `COMUN\programe\ofacturare_editare.prg` | Editat (`CreeazaCursorTvanzGol` + `IncarcaVanzareNota` extinse cu valuta documentului, antet rescris), ASCII pur |
| `COMUN\programe\ofacturare_editare.prg.pre_fix_culoare.bak` | Backup, luat la inceputul sesiunii |
| `COMUN\utile\Teste\editare_factura\test_adauga_linie_valuta.prg` | Nou, testat, 6/6 PASS |
| `COMUN\utile\Teste\editare_factura\test_ui_culoare_contrast.prg` | Nou, testat, captura + esantionare pixeli |
| `COMUN\utile\Teste\editare_factura\screenshots_after_fix_culoare\` | Nou — 2 capturi, dovada pe pixeli |
| `COMUN\utile\Teste\editare_factura\screenshots_before_fix_culoare\` | Capturile "before" din sesiunea anterioara, mutate din `screenshots\` ca sa nu se piarda |
| `docs\diff_s4_fix_culoare_valuta.patch` | Nou — `omodificari.vc2` |
| `docs\diff_s4_fix_culoare_valuta_ofacturare_editare.patch` | Nou — `ofacturare_editare.prg` |
| `docs\progres.md` | Actualizat |

**Fara commit** — asteapta review, conform regulii.

## Ce NU e acoperit

1. **Dialogul `frm_articol_factura` tot lucreaza in RON** — utilizatorul introduce pretul in RON
   chiar si pe un document in valuta; conversia se aplica la scriere, nu la intrare. A schimba
   asta ar cere atingerea `ofacturare.vc2` (`poDate.in_valuta=1` + `id_valuta`/`zi_curs`
   populate), in afara proprietatii/scope-ului acestei livrari.
2. **`Show(1)` (dialogul modal chiar deschis)** — netestat automat (netestabil headless), ca in
   sesiunile precedente; acoperit doar prin analiza de cod si testare manuala recomandata.
3. **Editarea unei linii existente prin acelasi dialog** (dublu-clic) — ramane nefacuta, in afara
   scope-ului primit in aceasta sesiune.
4. **Decizia de arhitectura despre `_grd_base.vc2`**: fixul defectului 1 s-a facut fara sa ating
   `_grd_base.vc2` (clasa comuna) — `nrgbrow` era deja o proprietate expusa pentru exact acest caz,
   nu a fost nevoie de nicio modificare acolo.