# S5 — acoperirea de teste pentru scrierea articolelor (decizii 38-41)

Raport de testare pentru functionalitatea S5 (`docs\handoff_s5.md`), care nu avea niciun test la
inceputul acestei lucrari. Trei fisiere de test atinse, toate in
`COMUN\utile\Teste\editare_factura\`, plus diff-ul: `docs\diff_s5_teste.patch`.

Niciun fisier de productie nu a fost atins (`omodificari.vc2`, `ofacturare_editare.prg`,
`ofacturare_comun.vc2`, `comun.vc2`, `ofacturare.vc2` — toate neschimbate de acest agent). Nu s-a
scris in Oracle (sectiunea B din suita noua foloseste un mock pe `goExecutor`, nu conexiunea
reala) si nu s-a dat commit.

## A. `test_page3_articole.prg` — asteptari actualizate

`verifica_editare_grid` verifica acum realitatea de azi: `ColumnCount=15` (era 14),
`Type('tvd.pret_achizitie')=='N'`, `Type('tvd.id_vanzare_set')=='N'`, iar `ReadOnly` la nivel de
coloana acopera si noua coloana 7 (`pret_achizitie`) si coloana 8 devenita `pret_cu_tva`
(checkbox-ul `_checkbox1` mutat odata cu ea).

Suita ramane la **14 PASS / 2 FAIL** (numarate ca ocurente literale `PASS`/`FAIL` in log, nu prin
regexul `raport_teste.ps1`, care pentru aceasta suita specifica subraporteaza — vezi sectiunea D).
Cele doua FAIL sunt aceleasi doua asertii de dinainte (`llStructuraOk`, `llReadOnlyOk`), acum cu
continut actualizat. **Gasit un motiv suplimentar de esec**, dincolo de artefactul headless deja
cunoscut: vezi sectiunea D.

## B. `test_s5_validari_articole.prg` — suita noua, headless, 35 PASS / 0 FAIL

Doua sectiuni.

**Sectiunea A** — cele 5 validari noi din `inainte_de_do_termin` (`omodificari.vc2:14328-14366`),
apelate DIRECT pe o instanta reala de `frm_modific2024` (document real, descoperit prin
`descopera_caz_test.prg`, cazul `FACTURA_ARTICOLE`):
- caz de control (document valid) → `.T.`, nicio validare declansata;
- `cantitate<=0` → blocheaza, mesaj cu "cantitatea";
- `id_articol` nul/0 → blocheaza, mesaj cu "articol";
- zero linii active + document cu rand in `tvanz` → confirmare (ambele ramuri Da/Nu verificate);
- linie noua cu `pret_achizitie` 0 SAU NULL → confirmare (ambele ramuri verificate, plus varianta
  NULL separat de varianta 0).

Un singur caz **nu s-a putut testa asa cum era planificat** — vezi constatarea de mai jos
(`pret NULL`).

**Sectiunea B** — garda de no-op si SQL-ul generat de `ScrieArticoleFacturaEditate`, complet
headless, pe cursoare construite in test (`crstvdtest`/`crstvanztest`, structura identica cu
`CreeazaCursorArticoleGol`), cu `goExecutor` inlocuit temporar de un mock (`dummyexecutor`) care
doar inregistreaza textul comenzilor si intoarce o valoare configurabila — conexiunea reala la
`MARIUSM_AUTO` ramane neatinsa tot timpul acestei sectiuni.
- garda de no-op, patru cazuri, toate verificate sa returneze `.T.` **fara niciun apel**
  `goExecutor.oExecuta`: `tnIdVanzare<=0` (0 si -5), alias articole neinchis, alias vanzare fara
  exact 1 rand (0 si 2 randuri), **`Reccount(alias articole)=0`** (cazul critic din handoff —
  protectia impotriva golirii facturii la un esec de incarcare Oracle);
- clasificarea liniilor, verificata prin SQL-ul EFECTIV generat pe un cursor cu cate un rand din
  fiecare categorie (pastrata-modificata, pastrata-nemodificata, stearsa, noua, noua-si-stearsa,
  componenta de set): exact 1 comanda "marcheaza tot sters", exact 3 `UPDATE` (liniile pastrate
  555/556/558 — inclusiv cea nemodificata si componenta de set, conform deciziei 38 "invie TOATE
  liniile pastrate"), exact 1 `INSERT` (linia noua), 0 comenzi pentru linia stearsa si pentru cea
  noua-si-stearsa ("se ignora"), exact 1 recalcul;
- `INSERT`-ul verificat pe continut: `pret_achizitie` citit din cursor, `explicatie` cu apostrof
  escapat corect (`OracleSpecialCharacters`), `id_vanzare`/`id_articol` corecte;
- recalculul: `discount` NULL in cursor → parametru `NULL` (pastreaza valoarea din baza, decizia
  41); `discount=5` → parametru `5.0000`;
- oprirea la primul esec Oracle: mock configurat sa esueze exact la a doua comanda (in mijlocul
  SCAN-ului de `UPDATE`) → functia intoarce `.F.` si **nu mai incearca a treia comanda** (2 comenzi
  total, nu 3+) — confirma ca bucla se opreste la primul esec, nu doar la primul pas.

### Constatare: validarea `Isnull(pret)` e cod neatingibil pe fluxul real

Planul initial testa si "pret NULL pe o linie activa → blocheaza". Incercarea de a forta
`tvd.pret` la `.NULL.` (fie pe o linie persistata, fie pe una noua adaugata prin `APPEND BLANK` pe
ACELASI cursor) arunca **eroarea VFP 1581 "Field PRET does not accept null values"** — verificat
empiric, nu presupus. Cauza: `tvd`, populat de `IncarcaArticoleFactura` din `VVANZARI_ARTICOLE`
(singura cale reala cand `ofacturare_editare.prg` e incarcat), mosteneste structural restrictia
`NOT NULL` a coloanei `VANZARI_DETALII.PRET` din Oracle — restrictia e la nivel de COLOANA a
cursorului, deci se aplica si liniilor noi adaugate ulterior, nu doar celor citite din baza.

Concluzie: **validarea `IF Isnull(pret) ... blocheaza` din `inainte_de_do_termin`
(`omodificari.vc2:14340-14344`) nu poate fi declansata pe fluxul real** — nici pe o linie
existenta, nici pe una noua construita prin fluxul aplicatiei (`AdaugaLinieTvdDinArticol`/
`CreeazaPoArticolNouTvd`, care oricum populeaza mereu `pret`). Nu e un bug care sa piarda date sau
sa produca un comportament gresit — e o garda defensiva care, in conditiile de azi, nu se poate
declansa niciodata. Marcat in log ca **`FAIL asteptat`** (exclus de `raport_teste.ps1` din
numaratoarea de regresii), cu explicatia inclusa in linie. **Raportat, nu reparat** — in afara
mandatului acestui agent.

## C. `test_ui_s5_grid_pret_achizitie.prg` — verificare UI, 14 PASS / 0 FAIL

Coloanele gridului nu se materializeaza sub `-A -T` (memoria recurenta), deci verificarea vizuala
s-a facut cu formular REAL, vizibil (`vfp_ui_harness.ps1`), pe documentul deja folosit de
`test_ui_sterge_linie.prg`/`test_ui_grid_articole.prg` (cod=1139934, an=2021, luna=12,
id_vanzare=882 — are rulaje, altfel `Show()` ascunde tot `pgfArticole`).

Verificat:
- gridul are **15 coloane**, coloana `cPretAchizitieArt` exista, legata pe `tvd.pret_achizitie`,
  eticheta "Pret achizitie";
- linie existenta (`id_vanzare_det<>0`): `pret_achizitie` **nu** primeste focus;
- **linie de SET (caz sintetic)**: `cantitate`/`pret`/`pret_achizitie`/checkbox `pret_cu_tva`
  **niciunul** nu primeste focus, si marcajul vizual (`DynamicForeColor`) e albastru
  `RGB(0,70,153)`, exact formula din cod;
- marcajul de linie **stearsa** (gri `RGB(150,150,150)`) e **neregresat**;
- linie **noua** (`id_vanzare_det=0`, `id_vanzare_set=0`): `pret_achizitie` **primeste** focus,
  iar `cantitate`/`pret` raman editabile ca inainte.

Captura: `COMUN\utile\Teste\editare_factura\screenshots\step_0_grid_s5.png` — se vede coloana
"Pret achizitie" in grid si prima linie grizata (sters=1).

**Caz sintetic, explicit**: documentul real nu are linii de set (in toata schema `MARIUSM_AUTO`
exista doar 4 randuri in `VANZARI_SETURI` — insuficient ca sa descopere un caz real prin
proprietate, si oricum absenta/prezenta pe atat de putine documente nu ar fi dovada in niciun
sens). Cazul de set a fost construit prin marcarea manuala a unui rand real din `tvd`
(`id_vanzare_set = 777`), tiparul deja folosit in `test_adauga_linie_valuta.prg` pentru cazul de
valuta. Verificarile de focus s-au facut prin apel DIRECT al metodei `.When()` a controlului
(echivalentul programatic al "celula primeste focus"), nu prin input real — masina e partajata cu
Marius.

## D. Constatare separata: `loGrid.ColumnN` nu functioneaza pe acest grid (nu doar headless)

La scrierea testului UI, prima varianta folosea acelasi tipar ca `test_page3_articole.prg`
(`loGrid.Column1.DynamicForeColor`) si a picat cu **eroarea VFP 1925 "Unknown member COLUMN1"** —
desi gridul era complet materializat (`ColumnCount` citea corect 15, `Show()` real, nu headless).
Cauza: coloanele acestui grid sunt redenumite explicit (`Column1.Name = "cDenumireArt"`,
`Column7.Name = "cPretAchizitieArt"` etc.) — in VFP, o coloana de grid redenumita asa **nu mai
raspunde la accesul numeric implicit** (`.Column1`), accesul valid ramane DOAR pe numele nou
(`.cDenumireArt`). Corectat in `test_ui_s5_grid_pret_achizitie.prg` (`loGrid.cDenumireArt...`).

Consecinta pentru `test_page3_articole.prg`: cele doua asertii ramase FAIL (`llStructuraOk`,
`llReadOnlyOk`) nu pica *doar* din artefactul headless cunoscut (grid nematerializat) — **ar pica
oricum**, chiar si intr-un rulaj cu formular vizibil, din cauza tiparului de acces
`loGrid.Column1`/`.Column5`/`.Column6`/`.Column7`/`.Column8`/`.Column14`/`.Column15`, folosit deja
in codul S4 preexistent (nu introdus de aceasta lucrare). Nu am corectat acest tipar in
`test_page3_articole.prg` — mandatul explicit a fost sa actualizez ASTEPTARILE (numarul de
coloane, semantica de editabilitate), nu sa repar accesul la obiect, iar suita trebuia sa ramana la
14/2 fara sa "iasa alt numar". Semnalat aici ca sa nu se piarda: daca cineva vrea vreodata sa faca
`verifica_editare_grid` sa treaca real (nu doar sa esueze "cunoscut"), trebuie schimbat atat
harnessul (formular vizibil, nu `-A -T`) CAT SI accesul la coloane (`loGrid.cDenumireArt` etc., nu
`loGrid.Column1`).

## E. Regresie finala

`raport_teste.ps1 -Dir COMUN\utile\Teste\editare_factura -Tot`, dupa ultima editare (verificat pe
mtime):

| Suita | PASS | FAIL |
|---|---|---|
| test_adauga_linie_articol | 20 | 0 |
| test_adauga_linie_valuta | 16 | 0 |
| test_incarca_vanzare_din_nota | 5 | 0 |
| test_page3_articole | 10*/14** | 0*/2** |
| test_s5_validari_articole (nou) | 35 | 0 |
| test_ui_s5_grid_pret_achizitie (nou) | 14 | 0 |
| test_ui_sterge_linie | 8 | 0 |
| test_verdict_act_rul | 26 | 0 |

\* cifra `raport_teste.ps1` (regex pe inceput de linie — subraporteaza pentru aceasta suita
specifica, vezi mai jos). \*\* cifra reala, numarata ca ocurente literale `PASS`/`FAIL` in log —
aceasta e conventia din `docs\handoff_s5.md` ("test_page3_articole 14/2"), verificata identica
inainte si dupa editarea mea.

**Atentie separata pentru viitor**: `raport_teste.ps1` numara doar liniile care incep cu
`PASS`/`FAIL` dupa spatii (`^\s*PASS`); `test_page3_articole.prg` scrie o parte din verdicte ca
`eticheta = PASS/FAIL` (verdictul la finalul liniei, nu la inceput) — pentru ACEASTA suita specifica,
raportul automat arata 10/0 in loc de 14/2 reale. Nu e o problema introdusa acum (tiparul exista
deja in cod dinainte), dar inseamna ca **pentru `test_page3_articole`, raportul automat nu e de
incredere** — verificarea trebuie facuta manual (`grep -o PASS/FAIL`, cum s-a facut aici), nu doar
cu `raport_teste.ps1`.

Toate celelalte suite: identice cu baseline-ul din `docs\handoff_s5.md`, nicio regresie.

## F. Ce nu s-a acoperit si de ce

- **Test cu scriere reala in Oracle** (aprobat de Marius pentru S5, dar separat de mandatul acestui
  agent — interzis explicit sa scrie in baza) — ramane pentru o lucrare ulterioara, dupa modelul
  `test_writeback_buton1.prg`.
- **R5** (linie cu valuta fara rand in `VANZARI_CURSURI`) — ramane deschis din `handoff_s5.md`, nu
  s-a adaugat un test nou pentru el, in afara mandatului de "validari + helper + grid".