docs: runda 6 - cercetari, propuneri si conventia mediului Oracle

Cercetarile si propunerile rundelor 4-6 pe editarea facturii emise. Starea
rundei 6 si ce s-a stabilit intra in progres.md.

Nou: docs/conventii_mediu_oracle.md - pe dev/test se lucreaza numai cu
ROA_CENTRAL si schemele CONTAFIN_ORACLE si MARIUSM_AUTO; schema ACN nu se
foloseste. Scripturile de pachet sunt necalificate, deci schema tinta o
decide sirul de conectare, nu fisierul.

roafacturare.pj2 regenerat de git_sync.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013gYCNE26G1G7UoGu2ju7aS

docs/progres.md

@@ -4,8 +4,76 @@
 incheie. Planurile (`plan_0*.md`) spun *ce* e de facut; acesta spune *unde s-a ajuns*. Istoricul
 sesiunilor nu se pastreaza aici — doar starea la zi, deciziile, faptele stabilite si datoriile.
 
-Ultima actualizare: **11.08.2026, seara**. **Punctul #6 e practic terminat: S1-S7 si S9 sunt gata si
-comise.** Ramane **S8** — si nu ca lipsa de acoperire, ci cu doua esecuri reale.
+Ultima actualizare: **19.08.2026**.
+
+> **RUNDA 19.08.2026 — butoanele de linie trec pe butoanele laterale ale grid-ului de articole.**
+> Cerere Marius, executata si testata; **fara commit**.
+>
+> **Eroarea raportata** (`gnButon este redefinit ilegal` la „Adauga articol") avea cauza in doua
+> `PUBLIC gnButon` din `omodificari.vc2` (`cmdAdaugaArticol.Click` si
+> `AfiseazaDialogSincronizareArticole`): `gnButon` e declarat **PRIVATE** la nivelul aplicatiei
+> (`Programe\roafacturare.prg:400`), iar restul codebase-ului doar il atribuie. Ambele declaratii
+> au fost sterse.
+>
+> **Ce s-a schimbat**: butoanele late „Adauga articol" / „Sterge / Restaureaza linie" au disparut de
+> pe pagina; comenzile stau acum pe coloana de butoane din dreapta grid-ului — **but_nouR** (nou,
+> clasa `but_nou`, `caction = do_adauga_rul`), `but_copiazaR` (duplica linia), `but_modificaR`
+> (nomenclatorul coloanei curente: articol, gestiune, valuta, cod TVA) si `but_stergeR` (comuta
+> `sters`). Toate dispecerizeaza dupa `pgfArticole.ActivePage = 3`. „Sincronizeaza cu rulaje..." a
+> ramas pe pagina, mutat la stanga (`Anchor = 0`) si evidentiat (fundal galben pal, text bold violet).
+>
+> **Logica noua sta in `.prg`, nu in binar** — clasa `ArticoleNotaEditor` din
+> `COMUN\programe\ofacturare_editare.prg` (`AdaugaLinie`, `ComutaSters`, `DuplicaLinie`,
+> `ModificaNomenclator`, `AreNomenclator`, `Editabil`); metodele din `.vc2` sunt apeluri de 3-4 linii.
+> Preferinta lui Marius, scrisa acum si in `COMUN\docs\reguli_lucru.md`, punctul 3.
+>
+> **Capcana platita**: `Createobject('X', p).Metoda()` **nu e sintaxa valida in VFP** — da „Syntax
+> error" la rulare, prins de `test_efactura_readonly`. Se trece prin variabila.
+>
+> **Defect latent reparat in trecere**: `AdaugaLinieTvdDinArticol` si `calculeaza_valori_articol` erau
+> metode de clasa **fara intrare `*m:`** in `*<DefinedPropArrayMethod>` — mergeau, dar prima salvare
+> din IDE le-ar fi aruncat tacit. Intrarile au fost adaugate.
+>
+> **Teste**: `test_butoane_laterale_articole` (suita noua) 33/0, `test_efactura_readonly` 21/0,
+> `test_s4b_dialog` 35/0, `test_s4b_sincronizare` 42/0, `test_adauga_linie_articol` 20/0,
+> `test_ui_sterge_linie` 8/0, `test_ui_culoare_contrast` 1/0, `test_ui_efactura_readonly` 13/0,
+> `test_page3_articole` 14/2 (**cele 2 = artefactul cunoscut de grid nematerializat headless**, la
+> baseline). Cele patru suite care tinteau butoanele sterse au fost mutate pe butoanele laterale.
+>
+> **Stare**: `omodificari.vc2` are **write-back-ul facut** (fidelity-check trecut de trei ori); cens de
+> octeti >0x7F identic cu baseline-ul (2x`aa`, 2x`e3`, 2x`fe`), zero LF izolati. Patch de review:
+> `docs\diff_runda_butoane_laterale_articole.patch`. Backup-uri:
+> `COMUN\clase\omodificari.pre_runda_butoane.bak.vc2`,
+> `COMUN\programe\ofacturare_editare.prg.pre_runda_butoane.bak`. **Niciun commit, in niciun repo.**
+> Changelog **neatins deliberat**: 2.11.15 n-a ajuns la utilizatori, iar intrarea existenta descrie
+> deja functionalitatea finala.
+>
+> **Ramas deschis**: `AdaugaLinieTvdDinArticol` si `calculeaza_valori_articol` sunt inca logica in
+> binar — de mutat in `ArticoleNotaEditor` la o runda viitoare (rup testele care le apeleaza direct,
+> deci nu s-a facut acum). Pe formularul maximizat, bara de totaluri se suprapune peste randurile 3-4
+> ale grid-ului de articole (grid ancorat 15, totalurile nu) — **preexistent**, nu s-a atins.
+
+**Punctul #6 e terminat pe partea care se poate face fara Marius:
+S1-S9 sunt gata, inclusiv S8.** Ce ramane cere aplicatia pornita, IDE-ul sau o decizie — nu mai e
+lucru de delegat unui agent.
+
+> **PREDARE, 13.08.2026.** Sesiunea a inchis trei lucruri si a deschis zero. **S8** — matricea era deja
+> rulata, „cele doua esecuri" erau o stare pierduta la o curatenie; aserttia prea larga s-a restrans.
+> **Asimetria de garda** — acceptata, fara atingere de cod. **Validarea de cantitate** — negativul
+> (retur, storno, discount) nu mai e respins, iar blocul S4b nu mai deschide un modal pe document gol.
+> Regresia: **10/10 suite headless la baseline**.
+>
+> **Nimic nu e intr-o stare periculoasa.** `omodificari.vc2` are write-back-ul facut si **verificat pe
+> binar** (nu pe mtime); zero procese `vfp9.exe`; pe Oracle numai `SELECT` sub `READ ONLY` cu
+> `ROLLBACK`; **niciun commit** in niciun repo. Documente de test consumate in acest bloc: **niciunul**
+> — matricea S8 nu a fost rerulata, deliberat.
+>
+> **Prima sarcina a sesiunii urmatoare**: nu incepe cod nou. Citeste punctele 1-6 din lista de mai jos —
+> toate cer aplicatia, IDE-ul sau o decizie a lui Marius. **Nu redeschide** asimetria de garda si nu
+> reinvestiga S8: ambele sunt inchise mai jos, cu motivele scrise.
+>
+> **Fire in paralel**: alta sesiune lucreaza pe **#13** (`docs\handoff_13_formular_unificat.md`,
+> `mockup_13_formular_unificat.html`, `plan_13_*.md` — apar modificate in `git status`). **Nu le atinge.**
 
 **PREDAREA CURENTA e chiar acest fisier.** Handoff-urile intermediare intre sesiuni au fost
 desfiintate (11.08.2026, decizia lui Marius) impreuna cu diff-urile deja aplicate; ce era durabil in
@@ -15,18 +83,24 @@ ele a intrat in antetele fisierelor de test sau in mesajele de commit. Nu mai ca
 
 1. **Stergerea celor sase documente parazite** (`1051`, `1056`, `1057`, `1058`, `1059`, `1060`) prin
    aplicatie — ramasa din blocul de creare documente pentru S8.
-2. **S8 — doua esecuri reale.** Pe „factura din aviz" (tip 4), din **ambele** puncte de intrare,
-   rulajele nu se refac pe nota noua (`Reccount(trul)=0`): `test_s8_matrice_surse.prg` da
-   **42 PASS / 2 FAIL**. Tot acolo, trei tipuri de sursa au fost sarite la ultima rulare (lista de
-   preturi `1048`, aviz `1052`, factura din contract `1055`), iar harnessul
-   `COMUN\utile\Teste\editare_factura\creeaza_documente_s8.prg` **nu a scris inca niciun document** —
-   capcanele de mediu (plaja de serii care chiar prinde, ordinea lui `mock_amessagebox`) sunt scrise
-   in antetul lui.
+2. ~~S8 — doua esecuri reale.~~ **INFIRMAT pe 12.08.2026. S8 e gata, n-a fost niciodata un esec** —
+   vezi sectiunea „S8 INCHIS" de mai jos. Nu relua investigatia.
 3. **Rebuild `roafacturare.exe`** din IDE si verificarea pe ecran, pe `1140895` / `1140921` — ambele
    contin `IV93900901` (`id_articol = 3598545102`), adica exact cazul corectat pe 11.08.
-4. **Punctele A si B** din `docs\rec_s4b_etapa2.md` — **deja implementate**, asteapta doar
-   confirmarea lui Marius. Nu sunt lucru ramas.
+4. **Punctul B** din `docs\rec_s4b_etapa2.md` — **CONFIRMAT 12.08.2026**, ramane cum e.
+   **Punctul A s-a transformat** intr-o intrebare mai mare, despre validarea de cantitate — vezi
+   sectiunea de mai jos. **Deschis.**
 5. **`git push` nefacut** in ambele repo-uri (remote `romfast`) — decizia lui Marius.
+6. **Necomis din 12-13.08.2026, asteapta review.** In `COMUN`: `clase\omodificari.vc2` — validarea de
+   cantitate (`:14386`) si garda pe blocul S4b (`:14438`), **write-back facut si verificat pe binar**,
+   diff `docs\diff_cantitate_negativa_garda_s4b.patch`; plus aserttia relaxata din
+   `utile\Teste\editare_factura\test_s8_matrice_surse.prg`, diff `docs\diff_s8_aserttie_rulaje.patch`.
+   In `ROAFACTURARE`: `docs\cercetare\rec_s8_matrice.md` (**recuperat** din `fc9c378`, fusese sters din
+   greseala), `rec_s8_rulaje_tip4.md`, `rec_cantitate_negativa_date.md`, `rec_regresie_cantitate.md`.
+   **Backup-uri de revenire**, de sters la curatenie: `omodificari.pre_cantitate.bak.vc2` si
+   `omodificari.pre_garda.bak.vc2`.
+   **Changelog: nefacut** — de decis daca schimbarea de cantitate intra in `2.11.15` (nu e inca in
+   productie, deci `:modificare:`, nu `:eroare:`).
 
 **Comis pe ramura `punct6-s4-runda3`, 11.08.2026**: `COMUN` `40a112a` (S4b etapa 2 — butonul,
 dialogul `frm_sincronizare_articole`, `id_articol` de la `I` la `N(20)` in toate cele 6 locuri, si
@@ -37,7 +111,8 @@ doua `This.` -> `Thisform.` care faceau butonul „Adauga articol" sa dea eroare
 **Cifre de test, citite din log, nu din rapoarte**: `test_s4b_sincronizare` **42/0** (include cazul de
 regresie `id_articol = 3598545102`, dovedit cu control negativ — cu campul `I` iese perechea
 `Adaugare`+`Semnalare` in loc de `Modificare`), `test_s4b_dialog` **35/0**, `test_s7_rotunjire` **6/0**,
-`test_s8_matrice_surse` **42 PASS / 2 FAIL**.
+`test_s8_matrice_surse` pe cele patru felii **44/0, 44/0, 26/1, 42/2** (vezi „S8 INCHIS" — cele 3 FAIL
+sunt asteptate si explicate, nu defecte).
 
 **Doua capcane de mediu platite pe 11.08, valabile pentru orice sesiune viitoare:**
 
@@ -58,9 +133,182 @@ trans-proiect au trecut in `COMUN\docs\cercetare\` (valuta si curs, TVA/VANZARI,
 `VANZARI` in suita, integrarile #10/#11/#12, watchdog VFP, proiectarea Oracle a lui S5, view-ul
 `VVANZARI_ARTICOLE`), iar 20 de rapoarte de executie ale lui #6 au fost sterse.
 
-**Starea la incheierea sesiunii — verificat, nu presupus**: zero procese `vfp9.exe`, zero tranzactii
-Oracle deschise (in acest bloc nu s-a atins Oracle), niciun fisier binar editat fara write-back,
-ambii arbori git curati fata de commituri.
+**Starea la incheierea sesiunii din 13.08.2026 — verificat, nu presupus**: zero procese `vfp9.exe`;
+pe Oracle numai `SELECT` sub `SET TRANSACTION READ ONLY` incheiat cu `ROLLBACK`, zero tranzactii
+deschise; **`omodificari.vc2` e singurul fisier de cod de productie atins, si are write-back-ul facut
+si dovedit pe binar** (condiitile noi apar in `omodificari.VCT`, cele vechi zero) — deci niciun binar
+in urma textului; **niciun commit** in niciunul din cele doua repo-uri.
+
+**De verificat pe ecran de Marius** (netestabil headless): mesajul „are cantitatea 0" pe o linie cu
+cantitate 0, si salvarea reusita a unei facturi reale cu linie de retur (cantitate negativa).
+
+## DESCHIS — validarea de cantitate din `inainte_de_do_termin` respinge returul si storno-ul?
+
+**Ridicata de Marius, 12.08.2026**, ca observatie la punctul A din `rec_s4b_etapa2.md`: *„pot exista
+articole cu cantitate negativa (retur, storno) sau cu pret 0"*.
+
+Ce spune codul, verificat la sursa (`frm_modific2024.inainte_de_do_termin`,
+`COMUN\clase\omodificari.vc2:14331-14599`, blocul de validari `:14378-14430`):
+
+| Ancora | Verifica | Efect |
+|---|---|---|
+| `:14386` | `Nvl(cantitate,0) <= 0` | **BLOCHEAZA** — „are cantitatea 0 sau negativa" |
+| `:14394` | `Isnull(pret)` | blocheaza doar `NULL`, **nu** si `0` |
+| `:14402` | `Nvl(id_articol,0) = 0` | blocheaza |
+| `:14410` | linie noua cu `pret_achizitie = 0` | doar confirmare |
+
+**Pretul 0 nu e o problema** — `:14394` testeaza `Isnull`, deci `0` trece. (E si ramura moarta
+cunoscuta: `tvd.pret` vine `NOT NULL` din view.) **Cantitatea negativa insa cade pe `:14386`**, si nu
+doar dupa „Aplica" din dialogul S4b — pe **calea normala de salvare**, la orice editare a unui
+document cu articole de vanzari.
+
+**Consecinta asupra punctului A**: plasa de siguranta propusa initial (reluarea validarilor blocante
+dupa „Aplica") **nu se mai face**. Din cele trei, `Isnull(pret)` e ramura moarta si `id_articol` vine
+mereu completat din sursa, deci singura care ar fi putut pica e chiar cea de cantitate — a carei
+premisa e sub semnul intrebarii. O plasa din doua verificari care nu pot pica ar fi cod fara efect.
+
+**REZOLVAT — decizia lui Marius, 12.08.2026: se permite negativul, 0 ramane blocat.** Aplicat pe
+`omodificari.vc2:14386-14387`: conditia `Nvl(cantitate,0) <= 0` a devenit `= 0`, mesajul „are
+cantitatea 0 sau negativa" a devenit „are cantitatea 0". **O singura linie de logica**, plus mesajul.
+
+**Datele care au sustinut decizia** (`docs\cercetare\rec_cantitate_negativa_date.md`, Oracle
+read-only): **65 de linii active cu `cantitate < 0` pe 52 de documente** — grosul pe tipurile `-6`
+(25 linii / 24 doc) si `41` (4/4), adica **retur-transfer**, dar si pe `tip 3` (comanda) 10 linii pe 4
+documente, care sunt linii **`DISCOUNT`** cu cantitate negativa, cea mai recenta din 26.03.2026. Deci
+negativul e si mecanismul de discount pe linie, nu doar retur/storno. `pret = 0`: 19 linii pe 17
+documente, toate cu articol — **trec deja**, `:14394` testeaza `Isnull(pret)`, nu `= 0`; iar
+`pret IS NULL` da **0 linii**, ceea ce reconfirma ramura moarta.
+
+**Write-back FACUT si verificat pe binar**, nu pe mtime: `txt2vcx.ps1` a dat `P1,E0,S1,X0` cu fidelity
+check `OK`; in `omodificari.VCT` conditia noua si mesajul nou apar o data, iar cele vechi **zero**.
+Editarea s-a facut **pe octeti** (`perl`, `binmode`), nu cu tool-ul Edit — cens `>0x7F` identic
+inainte si dupa (`2 aa / 2 e3 / 2 fe`), zero `EF BF BD`, diff exact 2 linii. Backup:
+`COMUN\clase\omodificari.pre_cantitate.bak.vc2`.
+
+> ### DESCOPERIT LA REGRESIE — S4B FACE `test_s5_validari_articole` SA ATARNE HEADLESS
+>
+> **Nu e cauzat de schimbarea de mai sus** — dovedit din cod, nu presupus. Suita se opreste la cazul
+> **A5** (`test_s5_validari_articole.prg:186-194`), care face `REPLACE ALL sters WITH 1 IN tvd`: cu
+> toate liniile sterse, `SCAN FOR Nvl(sters,0) <> 1` are **zero iteratii**, deci verificarea de
+> cantitate nici nu e atinsa. Lantul real: `lnLiniiActive = 0` -> confirmarea „toate liniile au fost
+> sterse" -> mock-ul raspunde Da -> `llRet` ramane `.T.` -> intra in blocul S4b (`omodificari.vc2:14438`)
+> -> cu toate liniile sterse fiecare articol-sursa iese `Adaugare`, deci `lnDivergente > 0` ->
+> `AfiseazaDialogSincronizareArticole()`, **formular modal** -> headless, atarna. Cazurile A2/A3/A4 trec
+> pentru ca dau `RETURN .F.` inainte de `:14438`; cazul de control A1 ajunge acolo dar n-are divergente.
+>
+> **De ce abia acum**: suita a rulat ultima oara **10.08 22:13**, iar S4b etapa 2 a intrat **11.08
+> 09:34**, si `rec_s4b_etapa2.md` declara explicit „Netestat: nimic nu a fost rulat".
+>
+> **Cifre partiale ale rularii intrerupte** (12.08 21:36): 8 aserttii, **toate PASS**, inclusiv
+> `cantitate<=0 -> blocheaza` — testul foloseste `REPLACE cantitate WITH 0` (`:130`), deci **schimbarea
+> de azi ii pastreaza comportamentul**. Plus linia documentara „FAIL asteptat" despre `Isnull(pret)`,
+> care nu e o aserttie picata. Procesul a fost oprit de garda de timp; **zero procese `vfp9.exe`** dupa.
+>
+> **REZOLVAT — decizia lui Marius, 12.08.2026: varianta (a), garda in cod.** Conditia de la
+> `omodificari.vc2:14438` a primit `AND Used('tvd') AND m.lnLiniiActive > 0`, plus o linie de comentariu
+> care explica ramura. `Used('tvd')` sta **inaintea** lui `lnLiniiActive` intentionat: VFP
+> scurtcircuiteaza `AND`, deci variabila (declarata in blocul `IF ... Used('tvd')` de la `:14378`) nu se
+> evalueaza cand blocul acela n-a rulat.
+>
+> **Write-back facut si verificat pe binar**: `P1,E0,S1,X0`, fidelity `OK`; garda apare o data in
+> `omodificari.VCT`, conditia veche fara garda **zero**. Editare pe octeti, cens `>0x7F` neschimbat
+> (`2 aa / 2 e3 / 2 fe`), zero `EF BF BD`. Backup: `omodificari.pre_garda.bak.vc2`.
+>
+> **Efectul, masurat**: `test_s5_validari_articole` trece iar integral — **35 PASS / 0 FAIL, exit 0**
+> (log proaspat, 13.08 02:43). Inainte de garda atarna la cazul A5 dupa 8 aserttii.
+
+> ### DOUA CAPCANE DE MEDIU NOI, platite pe 12-13.08 — de stiut inainte de orice rulare de regresie
+>
+> **1. Lansarile consecutive de `vfp9.exe` atarna.** Doua suite rulate una dupa alta in aceeasi bucla
+> `for` / aceeasi comanda: a doua **atarna la pornire, inainte sa scrie orice in log**. Aceleasi suite,
+> rulate cate una per comanda, merg. Se ruleaza **o suita per apel**, cu omorarea proceselor ramase
+> intre ele.
+>
+> **2. Logul stat da cifre plauzibile si false.** Fiecare suita isi **rescrie** logul la pornire (ex.
+> `test_page3_articole.prg:24`, inaintea conectarii Oracle de la `:30`). Daca rularea atarna inainte,
+> logul ramane cel vechi. Combinat cu capcana 1, doua suite au raportat `20 PASS / 0 FAIL` si
+> `16 PASS / 0 FAIL` **din 10.08**, la trei zile distanta, cu `exit=124`. **Verifica mereu mtime-ul
+> logului fata de ceasul curent inainte sa citesti o cifra.**
+>
+> **3. Numararea** (reconfirmare a capcanei vechi): `grep -c "^PASS"` **subnumara** — unele linii au
+> `PASS` la mijloc. Pe `test_page3_articole` a dat `10/0` in loc de `14/2`. Se numara cu
+> `grep -o "PASS" <log> | wc -l`, iar unde exista linia `REZULTAT` aia e autoritara.
+
+**REGRESIA E LA BASELINE PE TOATE CELE 10 SUITE HEADLESS**, 13.08.2026 02:43-03:07. Cifrele au fost
+**recitite de orchestrator direct din loguri**, dupa ce a verificat mtime-ul fiecaruia fata de ceasul
+curent — nu preluate din raportul agentului:
+
+| suita | obtinut | baseline |
+|---|---|---|
+| `test_s5_validari_articole` | 35 / 0 | 35 / 0 |
+| `test_page3_articole` | 14 / 2 | 14 / 2 |
+| `test_adauga_linie_articol` | 20 / 0 | 20 / 0 |
+| `test_adauga_linie_valuta` | 16 / 0 | 16 / 0 |
+| `test_verdict_act_rul` | 26 / 0 | 26 / 0 |
+| `test_incarca_vanzare_din_nota` | 5 / 0 | 5 / 0 |
+| `test_efactura_readonly` | 23 / 0 | 23 / 0 |
+| `test_s4b_sincronizare` | 42 / 0 | 42 / 0 |
+| `test_s4b_dialog` | 35 / 0 | 35 / 0 |
+| `test_s7_rotunjire` | 6 / 0 | 6 / 0 |
+
+Singurul log cu linie `EROARE` e `test_page3_articole`: `EROARE 1925 [VERIFICA_EDITARE_GRID:366]
+Unknown member COLUMN5` — **artefactul headless cunoscut** (sub `-A -T` coloanele de grid nu se
+materializeaza), care produce chiar cele 2 FAIL din baseline. Nu e regresie.
+
+**Nerulate deliberat**: suitele `test_ui_*` (cer formular vizibil pe un ecran partajat, iar schimbarile
+nu ating ce verifica ele) si `test_s8_matrice_surse` (ar consuma documente de test ireversibil).
+
+**Diff consolidat pentru review**: `docs\diff_cantitate_negativa_garda_s4b.patch` — 4 randuri schimbate
+in `omodificari.vc2` (2 de logica, 2 de comentariu).
+
+## S8 INCHIS — 12.08.2026. Matricea era rulata integral; „cele doua esecuri" erau o stare pierduta
+
+**Matricea S8 a fost rulata pe toate cele patru documente, fiecare de doua ori, din ambele puncte de
+intrare, inca din 10.08.2026.** Cifrele, din log, felie cu felie: `1048` (lista de preturi) **44/0**,
+`1055` (factura din contract) **44/0**, `1052` (aviz) **26/1**, `1054` (factura din aviz) **42/2**.
+Cele 8 verificari cerute de `plan_06_editare_factura.md:286-288` au verdict explicit in raport.
+
+**Cele 3 FAIL sunt asteptate, niciunul nu e defect:**
+- `1052` — garda `ReferinteDocumenteNota` **a blocat corect** intrarea ROAFACTURARE: avizul are deja o
+  factura emisa din el (`ACT.id_factc = 8009677` pe nota lui `1054`). Testul presupusese, mostenit din
+  modelul S5, ca orice document e editabil.
+- `1054`, de doua ori — `Reccount(trul)=0`. Documentul **n-avea rulaje nici inainte** de editare, deci
+  aserttia cerea ca editarea sa *creeze* rulaje care n-au existat.
+
+**De ce `RUL=0` e corect pe tip 4 — stabilit din cod, nu din tipar de date** (`rec_s8_rulaje_tip4.md`):
+`RUL` retine exclusiv miscari pe cont de stoc. Avizul (tip 22) scoate marfa din gestiune si scrie
+rulajele — pe `1052`, 4 randuri, toate pe contul `371`. Factura emisa din aviz nu mai atinge `371`:
+transforma doar creanta provizorie in creanta ferma si TVA neexigibila in TVA colectata (`ACT` pe
+`1054`: `4111/418` si `4428/4428`, niciun `371`). N-are, structural, ce rand de stoc sa scrie.
+Editarea doar **conserva** ce exista — `trul` se incarca din `vrul_tot` (`ofacturare_editare.prg:76`)
+si se scrie inapoi neconditionat (`ofacturare_comun.vc2:3821`, `OSCRIE_IN_FISIERE(0,.T.,.T.)`).
+Verdictul ACT/RUL are trei stari, **toate informative** (`omodificari.vc2:13129-13139`); „nu se aplica"
+e rezervat lui `tip=51`, deci tip 4 cade legitim in „divergent (informativ, nu e eroare)".
+Cele trei ancore sunt **verificate la sursa de sesiunea principala**, nu preluate din raport.
+
+**Aserttia a fost restransa** la ce voia de fapt sa apere — ca editarea nu pierde rulaje:
+`test_s8_matrice_surse.prg:313-314`, `Reccount(trul)` pe nota noua `>=` cat era inainte, cu linia de
+baza dusa prin `tnNrRulBaseline` de la ambele puncte de intrare. Rulare de compilare cu lista de cazuri
+goala: **0 PASS / 0 FAIL, exit 0, fara `EROARE`**, zero documente consumate.
+
+**Rularea completa pe date NU se face — decizia lui Marius, 12.08.2026.** Ar consuma inca 8 generatii
+de `cod` pe cele patru documente, pentru un rezultat previzibil: relaxarea e stricta (`>= linia de
+baza` in loc de `> 0`), deci muta `1054` de la 42/2 la 44/0 si lasa `1048`/`1052`/`1055` neschimbate.
+**Deci logul de pe disc ramane cel al rularii de compilare, nu al matricei** — cifrele matricei se
+citesc din `rec_s8_matrice.md`, iar felia `1054` asa cum a rulat inainte de relaxare e pastrata in
+`COMUN\utile\Teste\editare_factura\test_s8_matrice_surse_log.1054.txt`.
+
+> **Cum s-a pierdut starea, ca sa nu se repete.** Commit-ul `b5a7108` (curatenia din 11.08) a **sters
+> `docs\cercetare\rec_s8_matrice.md`** — incadrat drept „raport de executie al lui #6, nereferit de
+> nimic viu", desi e referit din `test_s8_matrice_surse.prg` — **si in acelasi commit** a scris in
+> `progres.md` starea dedusa din `test_s8_matrice_surse_log.txt`. Dar logul **se rescrie la fiecare
+> rulare**, deci pastra doar ultima felie (`1054`): de acolo au aparut „cele doua esecuri reale" si
+> „trei tipuri de sursa sarite". Raportul e **recuperat pe disc** din `fc9c378`. Aceeasi curatenie a
+> sters si `mockup_v7/v8_modificari.md`, care erau ale lui **#13**, nu ale lui #6.
+>
+> **Regula**: un log care se rescrie nu e sursa de stare. Starea sta in raport; daca raportul dispare,
+> starea dispare cu el. Inainte de a sterge un raport, cauta-i numele in `COMUN\utile\Teste\` si in
+> `docs\`, nu doar in `plan_*.md`.
 
 ## S8 — VERIFICAT PE VENDING PRODUCTIE, 10.08.2026: nu deblocheaza avizul
 
@@ -165,9 +413,12 @@ de `TRY/CATCH` imediat dupa ce driverul apeleaza `.do_termin()` pe `frm_alte_dat
 Harness-ul si investigatia completa de cod (cu `fisier:linie`) raman pe disc in
 `docs\cercetare\rec_s8_creare_variante.md` — utile daca se reia candva, dar **scopul e atins altfel**.
 
-**Ce ramane din S8**: matricea propriu-zisa — fiecare din cele patru documente editat **de doua ori**,
-o data din ROAFACTURARE si o data din registrul jurnal ROACONT, cu verificarile din
-`plan_06_editare_factura.md:282-291`.
+**Matricea propriu-zisa e RULATA** — fiecare din cele patru documente editat de doua ori, o data din
+ROAFACTURARE si o data din registrul jurnal ROACONT, cu verificarile din
+`plan_06_editare_factura.md:282-291`. Cifre si verdict: sectiunea „S8 INCHIS" de mai sus; detaliile pe
+document, in `docs\cercetare\rec_s8_matrice.md`. **Documentele sunt consumate** (coduri realocate,
+note vechi sterse ireversibil): `1048` -> `1140918`, `1052` -> `1140921`, `1054` -> `1140923`,
+`1055` -> `1140920`.
 
 ## Firele rundei (10.08.2026, dupa-amiaza)
 - `s8-creare-exec` — **executia** planului: creeaza avizul, factura din aviz si factura din contract in
@@ -297,11 +548,26 @@ Registrul Jurnal, `afisjurcom.do_modifica` (`comun.vc2:2222-2572`), **nu are nic
 restrictia de luna curenta, preexistenta pentru orice nota. Deci o factura deja trimisa la ANAF se
 poate edita din ROACONT, dar nu din ROAFACTURARE. Verificat de orchestrator cu `vfp_symbols.ps1`, nu
 din raport: hitul `ReferinteDocumenteNota` de la `comun.vc2:2620` e in `afisjurcom.do_sterge`
-(2574-2733), **alta metoda** — deci nu infirma constatarea. Variante: (1) se lasa si se documenteaza
-(deja documentat); (2) garda eFactura se muta in `PregatesteArticoleFacturaEditare`, deci se aplica
-doar cand documentul chiar e factura de vanzare, fara sa atinga notele obisnuite; (3) se dubleaza
-explicit in `do_modifica`. **Nefacut** — `comun.vc2` e livrare inchisa, iar calea din jurnal serveste
-orice tip de nota. Atinge si S8, care cere fiecare caz rulat din ambele puncte de intrare.
+(2574-2733), **alta metoda** — deci nu infirma constatarea. Reconfirmat pe 12.08.2026 cu
+`vfp_symbols.ps1 -Where`: in tot `comun.vc2` functia apare **o singura data**, la `:2620`, deci
+`do_modifica` (2222-2572) n-o are deloc.
+
+**INCHISA — decizia lui Marius, 12.08.2026: asimetria se accepta, nu se repara.** Nu se atinge nici
+`comun.vc2`, nici `omodificari.vc2`. Motivele care sustin decizia:
+- **jumatatea eFactura nu se putea dubla oricum** — decizia 42 spune explicit ca notele si rulajul se
+  modifica *doar* din ROACONT, deci o garda eFactura pe calea din jurnal ar fi anulat chiar decizia 42;
+- **absenta lui `ReferinteDocumenteNota` din `do_modifica` e voita**, nu o scapare: garda protejeaza
+  incasarile legate de `id_fact` la **stergerea** notei, unde legatura chiar se rupe; la modificare,
+  legatura structurala trece prin `id_fact`/`id_vanzare`, niciodata prin `cod` (S6, inchis), deci
+  realocarea `cod`-ului nu o strica;
+- **`comun.vc2` serveste orice tip de nota** din toate cele trei aplicatii — o garda acolo ar fi blocat
+  editarea oricarei note cu referinte de incasari, mult peste cazul semnalat.
+
+**Ce ramane adevarat si de stiut**: pe calea din registrul jurnal nimic nu opreste editarea unui
+document-sursa care are deja o factura emisa din el (dovedit pe `1052` in S8, unde intrarea
+ROAFACTURARE a blocat si cea din ROACONT a scris pana la `COMMIT`). Pe reeditare fara modificari de
+continut e inofensiv; o modificare reala de continut pe un asemenea document nu e oprita de nimic.
+**Acceptat ca atare.**
 
 ## #6 / S7 — rotunjirea la reeditare, GATA 10.08.2026: NU E DEFECT
 
@@ -1986,3 +2252,62 @@ pareau sa infirme o corectie s-au dovedit, la verificare, altceva decat pareau.
   textul regenerat din `<staging>\verify\*.vc2`**, nu incerca sa ghicesti ordinea.
 - **`InputMask` cu literal se ghilimeleaza** (`"9.99"`, nu `9.99`) — altfel VFP il ia numeric.
   Fidelity-check-ul **nu** semnaleaza asta separat.
+
+## Runda 6 - 20.08.2026: grid Articole (nomenclatoare, zecimale, aspect), meniu, punctul 6
+
+Livrat si aplicat, cu write-back facut si verificat prin reconversie independenta (0 linii
+diferenta pe ambele fisiere):
+
+- **`COMUN\clase\omodificari.vc2`** — cinci metode `DblClick` noi pe coloanele cu nomenclator
+  (`:16706`, `:16729`, `:16747`, `:16829`, `:16846`); `cPretArt` (`:12391`) si `cPretCuTvaArt`
+  (`:12408`) trec pe `get_mask(12,gnPPretV)`, `cPretAchizitieArt` (`:12400`) ramane pe `gnPPRET`;
+  cele cinci coloane cu nomenclator trec pe verde `160,255,205` (`Text1.ReadOnly` ramane `.T.`);
+  `cSerieArt`/`cLotArt`/`cExplicatieArt` trec pe alb `255,255,255` + `Text1.ReadOnly = .F.`
+- **`COMUN\clase\ofacturare_comun.vc2:4930`** — optiunea din `xmenu` devine
+  `Editare \<factura (note, rulaje, articole)`
+
+Ce s-a stabilit, ca sa nu se rediscute:
+
+- `cExplicatieTvaArt` are `ControlSource` **expresie** (`omodificari.vc2:12467`), nu camp. Intr-un
+  grid VFP tastarea intr-o celula read-only declanseaza cautarea incrementala pe campul legat;
+  fara camp nu are pe ce face seek, deci `InteractiveChange` nu porneste niciodata acolo. `DblClick`
+  se sprijina pe `Thisform.pccontrol` (pus explicit in `GotFocus`, `:16722-16726`) si de aceea
+  acopera uniform toate cele cinci coloane.
+- `gnPPret` = precizie pret **achizitie**, `gnPPretV` = precizie pret **vanzare**
+  (`oinit_optiuni.prg:515`). Model: `ofacturare.vc2:3490` vs `:3497`. Scrierea in Oracle a lui
+  `VANZARI_DETALII.PRET` foloseste `gnPPretV` (`ofacturare_stoc.prg:367`).
+- Conventia de culoare (de pe pagina Rulaje a aceluiasi formular): alb = se tasteaza direct,
+  verde `160,255,205` = se editeaza prin dialog, gri `225,225,225` = nu se editeaza.
+- Inainte de runda 6, serie/lot/explicatie **nu erau editabile pe nicio cale**: garda `.When` fusese
+  relaxata in runda 5, dar `Text1.ReadOnly` ramasese `.T.`, iar `but_modificaR` se activeaza doar pe
+  coloanele cu `GotFocus` (`:16678-16682`).
+- **NU** schimba `Text1.ReadOnly` pe cele cinci coloane cu nomenclator: calea de tastare merge
+  tocmai fiindca sunt `.T.`.
+
+### Punctul 6 - explicatie TVA in butonul de modificare din `frm_facturi`
+
+Decizia finala a lui Marius: **fara recalcul**, lista **filtrata pe cota salvata a liniei**, iar
+`taxcode` se sincronizeaza dupa explicatia aleasa. Varianta cu recalcul a fost propusa, aleasa
+initial, apoi **respinsa** — nu se reintroduce.
+
+- Script scris, **NERULAT** pe schema `MARIUSM_AUTO` (`ROA_CENTRAL`):
+  `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_20_02_COMUN_PACK_FACTURARE.sql`
+- Proiectarea completa: `docs\propunere_runda6_punct6_plsql.md`
+- `UPDATE`-ul scrie exact trei coloane: `EXPLICATIE`, `TAXCODE`, `ID_JTVA_COLOANA`. `PROC_TVAV` nu
+  se atinge, totalurile nu se recalculeaza.
+- Garda de neutralitate e in PL/SQL: `FACT-029` daca cota explicatiei difera de a liniei, plus
+  `FACT-026` (linie inexistenta), `FACT-027` (explicatie inexistenta/fara cota), `FACT-028`
+  (cota liniei NULL, verificata **separat**, inainte de comparatie).
+- Semantica verificata pe date: `PROC_TVAV` e **multiplicator** (1.19, 1.09...), `COTA_TVA` e
+  **procent** (19, 9...), deci comparatia e `(COTA_TVA+100)/100`. Cele 8 cote folosite azi pe linii
+  active au toate explicatie corespunzatoare — cazul "lista goala" e teoretic.
+- **Partea VFP nu a pornit.** Ce trebuie scris: sectiunea "Ce ramane de facut in VFP" din propunere.
+  `taxcode` se deriva **in VFP** prin `GetTaxCodeIdPart` si se trimite prin parametrul existent
+  `V_TAXCODE` — verificat ca lantul ei e inregistrat neconditionat in toate trei produsele
+  (`roafacturare.prg:187,189`, `roacont.prg:277,279`, `roagest.prg:239,241`), spre deosebire de
+  `ofacturare_editare.prg`, pe care doar ROAFACTURARE il inregistreaza.
+- `ff_2026_08_20_01` (garda `FACT-025`, runda 5) e **deja aplicat** pe `MARIUSM_AUTO`; scriptul 02 il
+  contine. **Nu se re-aplica 01** — ar sterge punctul 6.
+
+Ramase: proba pe ecran a punctelor 1-5, aplicarea scriptului pe `MARIUSM_AUTO`, partea VFP a
+punctului 6, si intrarea de changelog pentru runda 6 (nu exista inca).