roafacturare/docs/progres.md

# Progres implementare — ROAFACTURARE, punctele 6, 7, 8, 13 (10, 11, 12 amanate)

**Fisierul curent de stare.** Orice sesiune il citeste primul si il actualizeaza inainte sa se
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: **21.08.2026**.

> **RUNDA 21.08.2026 — #13 S2 implementata si comisa pe branch.**
> Cerere Marius, aprobata azi: **fara teste manuale, commit pe branch, continuare in alta sesiune.**
>
> **Ce s-a schimbat**: `COMUN\programe\ofacturare.prg` — procedura duplicata `factureaza2` (fork mort
> din 2017, zero utilizatori reali) a fost stearsa; alegerea formularului se face acum in
> `factureaza`, dupa flagul `Private plFacturareNoua`. `Clase\ofundal_facturare.vc2` — butoane noi
> `Page2.Cw10` „Facturare (nou)" (4 optiuni: lista de preturi, contract, comanda, aviz) si
> `Page3.Cw5` „Avize (nou)" (4 optiuni), ambele seteaza `plFacturareNoua` si deschid
> `frm_facturare_articole2`.
>
> **Decizia 67** (Marius, 20.08.2026): intrare separata in meniu, nu comutator/dialog; ambele cai
> facturare vechi si noua raman accesibile simultan. Perimetru: vanzarile din stoc (`Cw5..Cw9` ->
> `initializeaza_vanzare_din_stoc`) **nu** trec prin `factureaza` — raman in afara #13.
>
> **NETESTAT MANUAL** — decizia explicita a lui Marius, 21.08.2026. Ramane datorie de verificat cel
> tarziu la S6 (test pe flux real, planificat dupa S5).
>
> **Commis pe branch `plan13-s2`** in ambele repo-uri (ROAFACTURARE + COMUN), **fara SVN** — SVN
> ramane neatins pana la aprobarea finala si testele manuale. Detalii si hash-uri:
> `docs\handoff_13_s2.md`.
>
> **Urmatoarea story: S3** — portarea logicii de antet in formularul unificat.
>
> **Capcana platita**: FoxBin2Prg ordoneaza obiectele si metodele **ASCII-lexicografic**, nu numeric —
> `Cw10` cade intre `Cw1` si `Cw2` in textul `.vc2`, nu dupa `Cw9`. De verificat cu `vfp_symbols.ps1`
> inainte de orice cautare pe pozitie in fisier.

> **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
ele a intrat in antetele fisierelor de test sau in mesajele de commit. Nu mai cauta `handoff_*.md`.

**De facut, in ordine:**

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.~~ **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. **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
doua `This.` -> `Thisform.` care faceau butonul „Adauga articol" sa dea eroare la orice click real) si
`93a2718` (harnessul S8 intra in versionare); `ROAFACTURARE` `40933df` (changelog 2.11.15) si
`d9f5ca4` (`docs\` intra in git). In SVN: **r18011** si **r18012**.

**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` 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:**

- **`.FXP` vechi.** `vfp9.exe -A -T test.prg` poate executa **bytecode vechi** si „reusi" degeaba — o
  rulare a reprodus identic logul dinainte de o editare deja scrisa pe disc. **Sterge `.FXP`-ul suitei
  ca parte din comanda de rulare.** `SET PROCEDURE TO ...prg ADDITIVE` recompileaza corect, deci
  suspiciunea priveste `.FXP`-ul suitei, nu al modulelor.
- **`GETFONT()`.** Un formular instantiat headless fara `goApp` ajunge in `_frmbase.Init` la
  `goApp.ReadIni`; eroarea e doar logata, parametrul cade pe `.F.` si `accessibility` deschide un
  dialog modal care atarna procesul si apare pe ecranul lui Marius. Fixul e **in harness**
  (`PUBLIC goApp, gcAcces` + `Createobject("wzApplication")`), **nu** in `_frm_base.vc2` — clasa e
  partajata de toata suita, iar in productie `goApp` exista mereu. Ruleaza mereu cu garda de timp.

**Documentatia, dupa curatenia din 11.08.2026**: `docs\` e acum versionat in **git si SVN** — era in
afara oricarui control de versiuni. In `docs\cercetare\` au ramas **91** de rapoarte: sunt baza de
dovezi a planului #13 (85 de trimiteri din `plan_13`), **nu le sterge**. Alte **14** cercetari
trans-proiect au trecut in `COMUN\docs\cercetare\` (valuta si curs, TVA/VANZARI, consumatorii
`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 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

Conectare **read-only** la baza de productie `VENDING` (tunel SSH Bitvise cu profilul
`D:\GoogleDrive\vending.tlp` -> `79.119.86.134:22122`, forward `127.0.0.1:1521`; schema `VENDING`).
Toate interogarile sub `SET TRANSACTION READ ONLY`, incheiate cu `ROLLBACK`. **Tunelul a fost inchis
la final**, portul 1521 eliberat. Zero scrieri.

**Distinctia care conteaza**: `tip = 4` inseamna **factura emisa din aviz**, nu aviz. Avizele
propriu-zise sunt `tip = 22`. Productia **are** avize (22), dar **nu emite facturi din ele** de ani.

| `tip` | Ce e | Total nesters | Cel mai recent | In luna curenta |
|---|---|---|---|---|
| 3 | comanda | 5751 | 10.08.2026 | **390** |
| 1 | lista de preturi | 112091 | 10.08.2026 | **84** |
| 43 | (in afara celor 4 tipuri) | 13694 | 07.08.2026 | 13 |
| 8 | (in afara celor 4 tipuri) | 1191 | 07.08.2026 | 10 |
| 22 | **aviz propriu-zis** | 185 | 06.08.2026 | 3 |
| **4** | **factura din aviz** | **7** | **19.10.2021** | **0** |
| 2, 6 | contract | **absent complet** | — | 0 |

**Concluzii**:
1. **Avizul ca sursa de factura e practic mort** — 7 documente in tot istoricul productiei, ultimul in
   octombrie 2021. Nu e o lipsa a schemei de dev: nu se mai emite asa nicaieri.
2. **Contractul nu exista deloc in vending** (zero documente `tip in (2,6)`).
3. **Matricea pe 4 tipuri din plan nu corespunde utilizarii reale.** Tipurile vii sunt **lista de
   preturi** si **comanda**; in schimb apar masiv doua tipuri **din afara** matricei (43 si 8).
4. Productia **nu se poate folosi pentru executie** oricum: e read-only prin decizie, iar obiectele
   migrarii #6 (`VVANZARI_ARTICOLE`, `RECALCULEAZA_TOTALURI_VANZARI`) **nu exista acolo** — #6 nu e
   deployat in productie.

**CORECTIE, dupa verificarea pe `ROMFAST` si explicatia lui Marius (10.08.2026)**: concluzia „factura
din aviz e practic moarta" era **prea larga** — dedusa dintr-o singura firma. La vending se emit avize,
**se sterg**, si abia apoi se factureaza direct; de aceea `tip=4` nu apare acolo. Nu e o functie
abandonata.

Verificat read-only pe `ROMFAST@ROA_ROMFAST` (`10.0.20.36`, retea locala, fara tunel):

| `tip` | Ce e | Total nesters | Cel mai recent | In luna curenta |
|---|---|---|---|---|
| 2 | **contract** | **6976** | 03.08.2026 | **21** |
| 1 | lista de preturi | 318 | 21.05.2026 | 0 |
| 3 | comanda | 6 | 08.11.2022 | 0 |
| 4 | factura din aviz | **0** | — | 0 |

Deci **factura din contract e vie si masiva pe `ROMFAST`** — se emite curent. `tip=4` lipseste si acolo,
consistent cu explicatia de mai sus.

**Decizia lui Marius: toate variantele trebuie sa existe si sa functioneze**, inclusiv factura din
contract si factura din aviz. Se **creeaza in dev**, prin fluxul real de emitere (aviz -> factura din
aviz; contract -> factura din contract). **Regula ferma pe aceasta lucrare**: documentele se emit prin
fluxul aplicatiei, **niciodata cu `INSERT` direct** — un document cusut de mana n-are note, rulaje si
legaturi, deci un test S8 pe el nu dovedeste nimic.

**Planul de creare LIVRAT** (10.08.2026, 11:17): `docs\cercetare\rec_s8_creare_variante_plan.md` — intrarea
reala (`Procedure factureaza`, `COMUN\programe\ofacturare.prg:81-560`), tehnica de ocolire a dialogurilor
de antet prin setare directa `poDate` (scrierea ramane 100% in `PACK_FACTURARE`), driverul pentru modalul
`frm_alte_date`, datele de referinta din `MARIUSM_AUTO` (delegat 256, `id_fdoc` 5, client 463, contract
`id_ctr=235` — **`222` se evita**, are un rand cu `id_pol_art` NULL) si ordinea 22 -> 4 -> 2. Planul
declara explicit ce **nu** a verificat: garda proprie a lui `frm_date_aviz`, semnatura `oDateFactura` si
generatorul de serii, restul proprietatilor cerute de `do_scrie_factura`.

## S8 — DOCUMENTELE EXISTA, emise manual de Marius, 10.08.2026

Automatizarea emiterii s-a abandonat dupa un blocaj reproductibil (vezi mai jos). **Marius a emis cele
trei documente din aplicatie**, prin fluxul real — ceea ce satisface regula „niciodata `INSERT` direct"
mai bine decat orice harness. Verificate de orchestrator prin `sqlplus`:

| Tip sursa | `id_vanzare` | `cod` | `id_fact` | serie/numar | partener | totaluri | linii / `ACT` / `RUL` |
|---|---|---|---|---|---|---|---|
| **aviz** (tip 22) | **1052** | 1140908 | 8009677 | SSS/100037 | 108 | 271.17 / 56.94 / 328.11 | 2 / 12 / 4 |
| **factura din aviz** (tip 4) | **1054** | 1140910 | 8009679 | SSS/100037 | 108 | 252.07 / 52.93 / 305.00 | 1 / 2 / 0 |
| **factura din contract** (tip 2) | **1055** | 1140911 | 8009680 | SSS/549 | 614 | 200.00 / 42.00 / 242.00 | 2 / 7 / 1 |

Toate trei: `data_act = 10.08.2026` (luna curenta, deci trec garda de editare), `sters = 0`.
`id_vanzare = 1053` lipseste din secventa — numar ars, normal la un document abandonat.

**Impreuna cu `1048` (lista de preturi), matricea S8 are acum toate cele patru tipuri de sursa.**

> ### SASE DOCUMENTE PARAZITE — `1051`, `1056`, `1057`, `1058`, `1059`, `1060`
> Harness-ul `creeaza_documente_s8.prg` a fost rulat repetat de un agent **din alta sesiune**
> (`s8-creare-variante`, care depana blocajul fara sa stie ca scopul fusese deja atins). Fiecare rulare
> a lasat un document **malformat**: `total_cu_tva = 0`, o singura linie, `RUL` gol. Toate pe clientii
> de test `463` / `598`, cu numerele `SSS/13` … `SSS/17` — din care **`SSS/14` e duplicat** pe `1056`
> si `1057` (harness-ul aloca acelasi numar la toti pasii unei rulari).
>
> | `id_vanzare` | tip | numar | partener |
> |---|---|---|---|
> | 1051 | 22 | SSS/13 | 463 |
> | 1056 | 22 | SSS/14 | 463 |
> | 1057 | 2 | SSS/14 | 598 |
> | 1058 | 22 | SSS/15 | 463 |
> | 1059 | 22 | SSS/16 | 463 |
> | 1060 | 22 | SSS/17 | 463 |
>
> **De sters prin aplicatie** (nu prin SQL), decizia lui Marius. Matricea foloseste **exclusiv**
> `1048 / 1052 / 1054 / 1055`. Banner de oprire pus in capul raportului
> `docs\cercetare\rec_s8_creare_variante.md`, de unde isi ia sarcina agentul celeilalte sesiuni.

**Blocajul care a oprit automatizarea** (consemnat, nu se reia): procesul VFP moare fara eroare prinsa
de `TRY/CATCH` imediat dupa ce driverul apeleaza `.do_termin()` pe `frm_alte_date`. Reproductibil.
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**.

**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
  `MARIUSM_AUTO`, prin fluxul real, si le verifica in Oracle dupa terminarea procesului VFP. Harness nou
  in `COMUN\utile\Teste\editare_factura\`; zero cod de productie atins. Raport:
  `docs\cercetare\rec_s8_creare_variante.md`. **Matricea de editare propriu-zisa NU intra in acest bloc.**
- `dec42-proiectare` — proiectarea deciziei 42, **strict read-only** (fara editari, fara rulari). Raport:
  `docs\cercetare\rec_dec42_proiectare.md`.

## DECIZIA 42 (Marius, 10.08.2026) — ce se blocheaza dupa trimiterea in eFactura

**Textual**: „notele contabile si rulajul se pot modifica in continuare, doar articolele din factura
nu se mai pot modifica daca este trimisa eFactura."

Deci garda eFactura **nu opreste editarea notei** — suprima **pagina de articole**. Forma de
implementare care rezulta: garda intra in `PregatesteArticoleFacturaEditare`
(`COMUN\programe\ofacturare_editare.prg`), adica exact acolo unde se decide daca `PAGE3` se pregateste
si se arata. Notele obisnuite din registrul jurnal raman **complet neatinse** (helperul nici nu se
apeleaza pentru ele), iar `comun.vc2` **nu se modifica** — suprafata de regresie cross-project minima.
**Neimplementat inca.**

**Sub-intrebarea a primit raspuns (Marius, 10.08.2026)**: pe calea din ROAFACTURARE ramane **blocaj
total** pentru documentul trimis in eFactura — `frm_facturi.do_editare_factura` (`ofacturare_comun.vc2:3764`)
**ramane exact cum e azi, nu se atinge**. Notele si rulajul se modifica **doar din ROACONT**.

**CORECTIE (Marius, 10.08.2026), obligatorie — prima varianta de implementare era gresita**:
articolele din vanzari **trebuie sa ramana VIZIBILE** pe pagina de articole; doar **editarea** lor se
opreste cand documentul a fost trimis in eFactura. Deci **NU** se suprima `PAGE3` si **NU** se blocheaza
`PregatesteArticoleFacturaEditare` — pagina se pregateste si se afiseaza normal, iar gridul devine
**doar-citire**. Butoanele de adaugare/stergere linie se dezactiveaza in aceeasi conditie.

Mecanismul de editabilitate per rand exista deja din S5 in `omodificari.vc2` — se adauga peste el o
conditie la nivel de formular.

**IMPLEMENTATA SI VERIFICATA, 10.08.2026** (agent `d42-efactura`, din alta sesiune; verificata pe disc de
orchestratorul acestei sesiuni). **Necomisa.** Diff: diff aplicat (sters). Raport:
`docs\cercetare\rec_d42_efactura.md`. Forma implementata: flag `lArticoleReadOnly` pus in
`frm_modific2024.Show` (`:14789-14813`), impins peste `.When`-urile existente din S5
(`:16550`, `:16557`, `:16571`, `:16588`), `cmdAdaugaArticol`/`cmdStergeArticol.Enabled` plus garda
duplicata in `Click` (`:16494`, `:16533`), si eticheta `lblArticoleReadOnly`.

**Fisiere atinse**: `COMUN\clase\omodificari.vc2` (write-back **facut**) si
`COMUN\programe\ofacturare_editare.prg`. In afara arborelui: `D:\ROA\ROAGEST\Programe\roagest.prg`
(`SET PROCEDURE TO ofacturare_editare.prg` la `:260`, necomis) — fara el garda n-ar exista pe ROAGEST.

**Verificat de orchestrator pe disc, nu din raport**:
- **Write-back dovedit prin reconversie + comparatie octet cu octet**, nu pe mtime: binarul reconvertit
  intr-un cache temporar da un text **identic octet cu octet** cu `.vc2` din arbore (540636 octeti).
- **Cens de octeti** pe `omodificari.vc2`: `2 aa . 2 e3 . 2 fe`, **zero** `EF BF BD` — identic cu
  reperul. Fara corupere de diacritice.
- **Cifrele numarate din loguri**: regresie la baseline exact — `test_page3_articole` **14/2** (cele 2 =
  artefactul headless cunoscut, coloanele de grid nu se materializeaza sub `-A -T`),
  `test_adauga_linie_articol` **20/0**, `test_adauga_linie_valuta` **16/0**, `test_ui_sterge_linie`
  **8/0**, `test_verdict_act_rul` **26/0**, `test_incarca_vanzare_din_nota` **5/0**,
  `test_s5_validari_articole` **35/0**. Suite noi: `test_efactura_readonly` **21/0** (headless, pe
  document real trimis in eFactura — `id_vanzare=1013`, `id_fact=8008013`) si
  `test_ui_efactura_readonly` **14/0** (formular vizibil, citeste direct cele 4 `.When`).
- **Toate rularile (11:45-11:51) sunt DUPA write-back** (binar 11:37:22) — golul de acoperire care a
  aparut de doua ori in sesiunile trecute nu s-a repetat.
- Zero procese `vfp9.exe`, zero commituri.

*Capcana de numarare, de retinut*: un regex `^\s*PASS` da cifre false pe aceste loguri — suitele scriu si
`... = PASS` la capat de rand, iar `test_s5_validari_articole` are o linie „FAIL asteptat" care e o **nota
documentara** despre ramura moarta `Isnull(pret)`, nu o asertie picata. Doua suite vechi
(`test_page3_articole`, `test_incarca_vanzare_din_nota`) se termina cu `done`, nu cu `REZULTAT`.

**DEFECTUL CRITIC PRINS SI CORECTAT INAINTE DE LIVRARE** (gasit de `dec42-proiectare` pe review, confirmat
independent de orchestrator):
`omodificari.vc2:14798` cheama `EsteInEFactura(This.nIdVanzare)`, dar functia
(`COMUN\programe\ofacturare_editare.prg:16-25`) primeste **`id_fact`** si interogheaza
`anaf_efactura where id_fact = <param>`. `This.nIdVanzare` primeste `tvanz.id_vanzare` la `:14796` —
coloane **distincte** pe `VANZARI`, cu valori diferite pe orice document real. Consecinta: **garda nu se
declanseaza niciodata pe date reale**, adica exact esecul pe care decizia 42 il previne, si **tacit**.
Apelul corect exista ca precedent: `ofacturare_comun.vc2:3764` trimite `lnIdFact`.
**Corectia e APLICATA** (varianta B din `docs\cercetare\rec_dec42_proiectare.md` §8): `id_fact` intra pe
`tvanz` — `v.id_fact` in `SELECT`-ul din `IncarcaVanzareNota` (`ofacturare_editare.prg:179`) **si** in
`CreeazaCursorTvanzGol` (`:155`, altfel calea de fallback ar da eroare) — apoi
`EsteInEFactura(Nvl(tvanz.id_fact,0))` (`omodificari.vc2:14798`). Toate trei confirmate pe disc.

**De ce conteaza tiparul**: un test scris tot pe `id_vanzare` ar fi trecut si ar fi ascuns defectul.
Regula care l-a prins e cea din memorie — **deschide `RETURN`-ul functiei inainte sa accepti semantica
sugerata de nume**; aici, contractul scria `id_fact` chiar in antet (`ofacturare_editare.prg:15`).

**Confirmat, nu mai e intrebare deschisa**: `EsteInEFactura` e apelabila din toate cele trei aplicatii —
`ofacturare_editare.prg` e in `SET PROCEDURE` la `roafacturare.prg:214`, `roacont.prg:212` si
`roagest.prg:260`. Suprafata de regresie pe notele obisnuite din ROACONT/ROAGEST e **zero prin
constructie**: totul e sub gatingul `lAreArticoleVanzari`, existent din S4/S5 si neschimbat.

**DISCOUNTUL DE ANTET INTRA SUB GARDA — decis de Marius 10.08.2026, IMPLEMENTAT SI VERIFICAT.**
Textual: „Da, se blocheaza si el." Motivul: schimba totalurile unui document deja depus la ANAF, chiar
daca nu atinge nicio linie. Cod: `omodificari.vc2:14813` —
`txtDiscountArt.ReadOnly = This.lArticoleReadOnly`, prin acelasi flag, fara mecanism nou.
A doua cale de scriere **cautata si exclusa**: `txtDiscountArt.Valid` (`:16592`) doar recalculeaza
afisajul (`ActualizeazaBaraTotaluri`), nu scrie discountul nicaieri — deci garda dubla necesara la
butoanele de articole nu isi are rostul aici.

> **Agentul `d42-efactura` a cazut pe limita de sesiune imediat dupa write-back, INAINTE de
> verificare.** Orchestratorul a preluat si a dus-o la capat: write-back dovedit prin reconversie +
> diff octet cu octet (540712 octeti, identic), cens `2 aa . 2 e3 . 2 fe` zero `EF BF BD`, regresia
> rerulata integral pe starea de pe disc (**fara nicio regresie**), si suita `test_efactura_readonly`
> extinsa cu doua asertii — **23 PASS / 0 FAIL**, garda verificata in ambele sensuri (blocat pe
> documentul din eFactura, editabil pe cel netrimis).
> **Gol declarat**: suita UI vizibila (`test_ui_efactura_readonly`, 14/0) **nu a fost rerulata** dupa
> aceasta completare — verifica `.When`-urile de celula, neatinse de ea.

## DECIZIA 43 (Marius, 10.08.2026) — S4b se INCHIDE fara enumerarea „vechi -> nou"

**Textual**: „la S4b nu ma intereseaza sa ii arat utilizatorului ce s-a modificat, este de ajuns
totalurile de control."

Deci partea ramasa din S4b — actiunea explicita de sincronizare cu enumerarea liniilor vechi -> nou —
**se abandoneaza deliberat**, nu se amana. Totalurile de control pe cele trei surse si verdictul
`ACT`/`RUL`, deja livrate si comise, sunt suficiente. **S4b devine GATA.**

Propunerea de proiectare ramane pe disc doar ca istoric —
`docs\propunere_s4b_sincronizare.md` (cursor de instantaneu `tvd_init`, dialog modal de confirmare).
**Nu se implementeaza.** Daca cineva o redeschide candva, sa stie ca a fost respinsa pe scop, nu pe
calitate: proiectarea era verificata pe disc (ancorele `:14788` in `Show`, `:14329-14386` in
`inainte_de_do_termin`, ambele confirmate cu `vfp_symbols.ps1`).

## Intrebarea care a generat decizia 42 (istoric, inchisa)

**Ridicata de S9**: garzile de la editare sunt **asimetrice intre
cele doua puncte de intrare**. `frm_facturi.do_editare_factura` refuza documentul trimis in eFactura
(`EsteInEFactura`) si pe cel cu referinte de incasari/plati (`ReferinteDocumenteNota`); calea din
Registrul Jurnal, `afisjurcom.do_modifica` (`comun.vc2:2222-2572`), **nu are niciuna din ele** — doar
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. 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

**Verdict: corectiile de rotunjire NU se acumuleaza la editari repetate. Nu se repara nimic.**
Raport: `docs\cercetare\rec_s7_rotunjire.md`.

Argumentul care sustine verdictul e **structural**, nu statistic:

1. **`ACT_TEMP` e global temporary table cu `DURATION = SYS$TRANSACTION`** — se goleste singura la
   finalul fiecarei tranzactii. **Verificat independent de orchestrator** in `ALL_TABLES`
   (`ACT_TEMP` = `Y` / `SYS$TRANSACTION`, `ACT` = `N`), nu preluat din raport. Fiecare editare ruleaza
   intr-o singura tranzactie incheiata cu COMMIT (decizia 38), deci `ACT_TEMP` porneste mereu goala si
   nu poate purta randuri dintr-o editare anterioara.
2. `verifica_total_document` se apeleaza **o singura data pe generatie** (`cumuleaza_note_act:14095`).
3. Insereaza **cel mult 2 randuri** pe generatie — un `INSERT` per `IF` (ftva, tva); al treilea `IF` e
   doar pentru `ntip in (48,49)`, deci nu pe factura (tip=1).
4. **Blocul vechi se retrage integral** (`STERS=1`) la fiecare editare, nu doar linia de corectie —
   confirmat pe **8 generatii reale** ale documentului, cu numar de randuri active constant (10).

**Limita, declarata explicit de raport si acceptata**: pe compozitia documentului de test mecanismul
**nu se declanseaza niciodata** (`ntotftva = V_TOTFTVA_VER` exact la toate cele 8 generatii), deci
cifra `0 / 0 / 0` pe cele trei treceri arata doar ca randurile nu cresc — **nu** dovedeste prin ea
insasi ce s-ar intampla daca s-ar declansa. Criteriul din plan e indeplinit, dar **vacuu pe partea
empirica**; greutatea o duc punctele 1-4. Consecventa cu regula „zero cazuri in date nu e dovada".

**Confirmare ca mecanismul chiar functioneaza in productie**: `cod=1140709` (an 2026, luna 3) are o
corectie reala de `0.02` lei, cu semnatura exacta a INSERT-ului (`id_act = max+1`, restul coloanelor
copiate de pe randul-ancora). Documentul **nu a fost reeditat**, deci nu arata direct acumularea — dar
arata ca se insereaza **exact un rand** cand se declanseaza.

**Ce nu s-a acoperit**: niciun document din productie care sa declanseze corectia **si** sa fie editat
de mai multe ori; neconcordanta n-a fost fortata artificial (ar fi cerut modificarea `scrie_nota`);
ramura `ntip in (48,49)` neexercitata.

**Capcana prinsa in propria masuratoare, de retinut**: prima interogare de numarare a dat fals-pozitiv
„3 corectii" — semnatura prea larga prindea perechi `(scd,scc)` duplicate legitim de doua linii de
detaliu diferite. Filtrul corect cere si **diferenta mica** intre sume
(`abs(max-min) < 5 AND max <> min`). Agentul l-a corectat **inainte** de rularea raportata.

**Verificat de orchestrator pe disc**: log `6 PASS / 0 FAIL` cu linia `REZULTAT` prezenta (numarat din
log, nu din raport), zero tranzactii Oracle deschise, zero procese `vfp9.exe`.

**Date de test consumate**: `cod` pe `id_vanzare = 1049` a mers `1140900 -> ... -> 1140906`
(**cel curent**) — sapte generatii, din care prima serie de trei cu interogarea de numarare gresita.
Niciun `det` schimbat sau sters suplimentar fata de S5; totaluri neschimbate
(`747.96 / 157.06 / 905.02`). `id_vanzare` `1050` si `1037` **neatinse**.
**Fisier nou, necomis**: `COMUN\utile\Teste\editare_factura\test_s7_rotunjire.prg` + log.

## #6 / S9 — documentatia fluxului, GATA 10.08.2026, NECOMISA

Ultima parte ramasa din S9 (changelog-ul si commit-urile git erau deja facute). In
`D:\ROA\ROAGEST\COMUN\docs\flux-modificare-stergere-nota-jurnal.md`: sectiune noua „Ramura noua:
editare factura de vanzare" + 2 puncte in „Implicatii practice". Acopera conditia de activare
(`ofacturare_editare.prg` in `SET PROCEDURE`, inregistrat de toate cele trei aplicatii), cele doua
puncte de intrare cu garzile lor, secventa de scriere in tranzactia manuala unica, cei 4 pasi din
`ScrieArticoleFacturaEditate`, `recalculeaza_totaluri_vanzari`, view-ul `VVANZARI_ARTICOLE` si
comportamentul gridului. Regula deciziei 38 e scrisa **ca regula**, fara numarul deciziei, conform
conventiei de comentarii. Diff: diff aplicat (sters). Raport:
`docs\cercetare\rec_s9_documentatie.md`.

**Verificat de orchestrator pe disc**, nu din raport: modificat **doar** fisierul de documentatie
(`svn status` pe `ROAGEST\COMUN\docs` — restul, `PACK_DIAG_SPATIU.pck` modificat, `bash.exe.stackdump`
neversionat si conflictul de arbore pe `email-thunderbird.md`, sunt **preexistente, straine de noi**);
zero fisiere de cod atinse in ambele arbori git; zero procese `vfp9.exe`; zero commituri.

**O afirmatie din raportul agentului e gresita ca formulare** (concluzia rezista): a raportat „grep
zero rezultate pentru `EsteInEFactura`/`ReferinteDocumenteNota` in `comun.vc2`", dar `comun.vc2:2620`
chiar apeleaza `ReferinteDocumenteNota` — doar ca in `do_sterge`, nu in `do_modifica`. Textul scris in
documentatie e corect. **Tipar de retinut**: constatarea „nu exista X in metoda Y" se verifica cu
`vfp_symbols.ps1 -Where`, nu cu un grep pe fisier.

**Ramane netestat pe ecran**: nimic — e documentatie. **Ramane de decis**: asimetria de garzi de mai sus.

## #6 / S5 — scrierea sumelor editate in Oracle, TERMINAT SI COMIS 10.08.2026

**Starea completa a blocului e in handoff intermediar (sters)** — se citeste inaintea acestei sectiuni.
Aici doar ce trebuie sa stie o sesiune noua din prima:

- **Codul e scris integral si write-back-ul e facut** pe toate cele patru fisiere atinse:
  `ofacturare_editare.prg` (helperul `ScrieArticoleFacturaEditate`), `omodificari.vc2` (coloana
  `pret_achizitie`, editabilitate per rand, validari), `ofacturare_comun.vc2` si `comun.vc2`
  (agatarea). **Necomis.**
- **Doua scripturi Oracle APLICATE in `MARIUSM_AUTO`**: `ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql`
  (procedura `recalculeaza_totaluri_vanzari`) si `ff_2026_08_09_02_COMUN_VVANZARI_ARTICOLE.sql`
  (view-ul, cu `ID_VANZARE_SET` si `PRET_ACHIZITIE`). Pachetul e `VALID`, zero erori.
  `versiune_db.txt` = **`2026_08_09_02`**. Scripturile sunt in `docs\`, **nu** in `SCRIPTURI_CLAR`.
- **Deciziile 38-41** (ordonarea scrierii, liniile de set, `PRET_ACHIZITIE`, discountul ca parametru)
  sunt in handoff intermediar (sters). **Decizia 38 corecteaza planul S5**: recalculul se apeleaza din VFP, nu
  din `finalizeaza_modificare_nota`, altfel ar calcula totalurile pe liniile dinainte de editare.
- **Runda 2 pe grid, INCHISA** (`s5-grid`, 09.08.2026 tarziu): cele trei corectii de code-review sunt
  in binar. **Write-back verificat prin reconversie si diff, nu pe mtime** — textul regenerat din
  binar e identic octet cu octet cu `.vc2` (`txt2vcx.ps1:300` rescrie mtime-ul textului, deci mtime
  nu dovedeste nimic). O a patra constatare s-a dovedit **nerealizabila** pe codul de acum si nu se
  repara — detalii si conditia care ar activa-o, in handoff intermediar (sters).
- **Regresia e la baseline pe toate cele sase suite**, cifre numarate din loguri de orchestrator,
  toate rulate **dupa** write-back (binar 23:15:50): `test_page3_articole` **14/2** (23:19:52),
  `test_adauga_linie_articol` **20/0**, `test_adauga_linie_valuta` **16/0**, `test_ui_sterge_linie`
  **8/0**, `test_verdict_act_rul` **26/0**, `test_incarca_vanzare_din_nota` **5/0** (23:27:52).
- **Acoperirea cu teste, LIVRATA** (`s5-teste`, `docs\cercetare\rec_s5_teste.md`,
  diff aplicat (sters)): suita noua headless `test_s5_validari_articole.prg` **35 PASS / 0 FAIL**
  (validarile din `inainte_de_do_termin`, garda de no-op, SQL-ul din `ScrieArticoleFacturaEditate` cu
  mock pe `goExecutor`, fara Oracle) si suita noua pe formular vizibil
  `test_ui_s5_grid_pret_achizitie.prg` **14 PASS / 0 FAIL** (15 coloane, linie de set needitabila cu
  marcaj, `pret_achizitie` primeste focus doar pe linie noua). Cifre numarate din loguri de
  orchestrator; suita UI se termina in `GATA`, deci a trecut de handshake.
- **Ramura moarta consemnata, NU se repara**: validarea `Isnull(pret)` (`omodificari.vc2:14340`) e
  neatingibila pe fluxul real — `tvd.pret` vine `NOT NULL` din view, orice `REPLACE` cu `.NULL.` da
  eroare VFP 1581. Guard redundant, inofensiv; `omodificari.vc2` e livrare inchisa si verificata si nu
  se redeschide pentru asta.
- **TESTUL CU SCRIERE REALA IN ORACLE, GATA — 25 PASS / 0 FAIL** (`test_s5_scriere_reala.prg`,
  raport `docs\cercetare\rec_s5_scriere_reala.md`). **Premisa deciziei 38 e dovedita direct, in
  tranzactie**, pe `id_vanzare = 1049`: dupa `finalizeaza_modificare_nota` linia marcata stearsa
  (`det=1582`) revine cu `STERS = 0` — resetul din `actualizeaza_vanzari` chiar o invie — iar dupa
  `ScrieArticoleFacturaEditate` e din nou `STERS = 1`. **Trecerea 2** (reeditare fara nicio
  modificare) reproduce exact acelasi tipar, deci **stergerea e definitiva la reeditare** —
  consecinta 2 din decizia 38, dovedita. In plus: linia noua inserata cu `ID_VANZARE_DET` alocat de
  trigger (`det=1588`) si `PRET_ACHIZITIE = 77.77` exact cat s-a tastat; `PRET_ACHIZITIE` pe linia
  existenta editata **neatins** (10 -> 10); totalurile recalculate coerente (`747.96 + 157.06 =
  905.02`, egal cu suma liniilor active). **Verificat independent prin `sqlplus`** dupa terminarea
  procesului VFP, cu rezultatele in raport — nu doar din logul testului.
- **Date de test consumate ireversibil**: `cod` `1140887` -> `1140896` -> `1140897` pe
  `id_vanzare = 1049`; `det=1582` ramane sters definitiv; `det=1588` e linie noua creata de test.
  Documentul **nu** e cel folosit de suitele de regresie (`1050`).
- **Ce NU acopera testul** (din raport, de stiut inainte de livrare): validarile din
  `inainte_de_do_termin` (`buton = 1` fortat direct — dar sunt acoperite separat de suita headless
  35/0), `frm_modific2024` neinstantiat, **liniile din seturi neatinse** (documentul n-are
  `id_vanzare_set` nenul), al doilea punct de intrare (`comun.vc2:2491`) nerulat, documentele **in
  valuta** si cu **discount nenul** netestate (parametrul de discount doar cu `0`, niciodata `NULL`
  sau nenul), si calea de **esec partial / ROLLBACK** neprovocata.
- **DISCOUNT + VALUTA, GATA — 46 PASS / 0 FAIL** (`test_s5_discount_valuta.prg`, raport
  `docs\cercetare\rec_s5_discount_valuta.md`). Inchide doua din golurile declarate mai sus.
  **Verdictul pe decizia 41: `NULL` PASTREAZA discountul curent, nu-l zeroeaza** — dovedit pe date
  prin apeluri succesive in aceeasi tranzactie (`0 -> recalc(12.5) -> 12.50 -> recalc(NULL) -> inca
  12.50, totaluri identice pana la a 4-a zecimala -> recalc(0) -> 0`), deci `0` explicit si `NULL`
  **nu se confunda**. Codul concorda: `SELECT NVL(V_DISCOUNT, discount) ... FROM vanzari`
  (`ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:16043`, verificat de orchestrator). **Niciun defect in
  procedura.** Valoarea nenula scade totalurile exact (`747.96-12.50=735.46`,
  `discount_tva=Round(12.5*0.21,2)=2.63`). Verificat separat pe lantul real: `finalizeaza_modificare_nota`
  **nu atinge** `DISCOUNT`, deci riscul „orice salvare ulterioara sterge discountul" **nu se produce**.
- **PREMISA VECHE INFIRMATA, nu o mai repeta**: afirmatia ca „nu exista in schema un document
  descoperibil simultan cu articole si in valuta reala" e **gresita**. Verificat de orchestrator prin
  `sqlplus`: **28** randuri `VANZARI` cu `IN_VALUTA = 1`, dintre care **25 cu linii active**, si 8
  complet formate (curs + rand in `VANZARI_CURSURI`). Recalculul Oracle a fost acoperit pe
  `id_vanzare = 1037` (curs 5.2688), cu **ROLLBACK** la final — documentul e arhiva si ramane neatins.
  *Limita reala, alta decat cea presupusa*: niciun document in valuta nu e din luna curenta (cel mai
  recent 05.2026), deci **lantul complet de editare** nu poate fi rulat pe valuta — doar recalculul.
- **Consumat aici: un singur `cod`, `1140897 -> 1140898`.** Verificat de orchestrator dupa rulare:
  `id_vanzare = 1049` are `discount = 0` si totalurile restaurate exact (`747.96 / 157.06 / 905.02`),
  liniile neschimbate (`1581` cant=2, `1582` sters, `1583`, `1588` cu `pret_achizitie = 77.77`).
- **Ce NU e facut**: **verificarea pe ecran de Marius**, diff-urile consolidate, changelog `:nou:`,
  si decizia de commit / push / SVN. Din golurile de acoperire raman: **liniile din seturi**, **al
  doilea punct de intrare** (`comun.vc2:2491`) si **calea de ROLLBACK la esec partial**.
- **Capcana platita, sa nu se repete**: exportul `all_source` cu `linesize` prea mic **rupe linii
  lungi prin mijlocul identificatorilor** si corupe tacut orice script construit din el. Un script
  de pachet se face de la **ultimul script aplicat din `SCRIPTURI_CLAR`**, nu de la un export.
  Detalii in handoff intermediar (sters); `COMUN\docs\oracle_export.md` a fost corectat.

## COMIS PE BRANCH `punct6-s4-runda3` — 09.08.2026, NEIMPINS, NEINTRAT IN SVN

| Repo | Commit | Ce contine |
|---|---|---|
| `COMUN` (`comun.git`) | `b9eba29` | tot #6 / S4 runda 3: `omodificari.vc2`, `ofacturare_editare.prg`, `ofacturare_comun.vc2`, `comun.vc2`, `anaf_efactura.vc2`, cele doua `.sc2` de import, docs, 13 suite de test noi |
| `ROAFACTURARE` | `97d1613` | `roafacturare.pj2` — `omodificari.vcx` intra in proiect |

`git_sync.ps1` rulat inainte de commit: **0 convertite, 463 la zi, 0 esuate** — textul comis
corespunde binarelor. **`push` nefacut** si **SVN neatins** (ramane la r18006/r18007) — amandoua sunt
decizia lui Marius, dupa review. Lasate deliberat necomise: backup-ul
`ofacturare_comun.pre_s4butoane.bak.vc2` si `test_nume_coloana_modificat.log`. `docs\` din
ROAFACTURARE ramane neversionat. Commit-ul din `COMUN` include si `docs\todos.txt` cu editarile lui
Marius la punctele 13 si 20.

## #6 / S4, decizia 35 — intrare directa in valuta la adaugarea de linii, GATA 09.08.2026

Cand documentul e in valuta (`tvanz.in_valuta = 1`), dialogul `frm_articol_factura` deschis din
`cmdAdaugaArticol` primeste acum `poArticol.tip_valuta = 1` + `Curs` / `multiplicator` / `nume_val` /
`id_valuta` luate **de pe `tvanz`** (fara interogare Oracle noua), deci utilizatorul introduce pretul
**direct in valuta documentului**, nu in RON. `AdaugaLinieTvdDinArticol` ramifica: pe
`tip_valuta = 1` citeste direct campurile `_val` (`pretftva_val`/`pretctva_val`/`discount_unitar_val`/
`discount_unitar_ctva_val`), pe `tip_valuta = 0` pastreaza conversia existenta
(`* multiplicator / curs`). Ramura RON e neatinsa.

**`COMUN\clase\ofacturare.vc2` NU a fost atins** — verificat pe mtime (`.vc2`/`.vcx`/`.vct` toate la
07.08.2026 22:18, nemodificate). Asta era conditia care conta: `frm_facturare_articole` si
`frm_facturare_articole2` folosesc **activ, in productie**, aceeasi ramura `tip_valuta = 1`, deci
orice atingere a codului dialogului ar fi fost o regresie potentiala pe formularul de compunere.
Premisa initiala a deciziei 35 (ca ar fi nevoie de `poDate.in_valuta`/`zi_curs`/`id_valuta`) era
gresita — vezi corectia de la decizia 35 si handoff intermediar (sters).

**Verificat de orchestrator pe disc** (cifre numarate din loguri): `test_adauga_linie_valuta.prg`
extins la **16 PASS / 0 FAIL** — acopera **ambele** ramuri, scenariul A (intrare in RON, conversie la
stocare, comportamentul vechi neregresat) si scenariul B (intrare directa in valuta). Asertia care
conteaza: **200 EUR introdus pe un document cu curs 5.2688 ramane `200.00` in `tvd.pret`** — nu
1053.76 (dubla conversie inversa) si nici 37.96 (`200/5.2688`) — iar bara de totaluri recompune
corect 1053.76 RON. Regresie neschimbata: `test_page3_articole` **14/2** (cele 2 = artefactul
headless de la datoria 7), `test_incarca_vanzare_din_nota` **5/0**, `test_adauga_linie_articol`
**20/0**, `test_ui_sterge_linie` **8/0**, `test_verdict_act_rul` **26/0**. Rulari 18:57-18:59, toate
**dupa** ultima editare de cod (`omodificari.vc2` 18:53:21, `ofacturare_editare.prg` 18:52:59).
Cens de octeti `2 aa / 2 e3 / 2 fe`, zero `EF BF BD`. Text si binar sincrone, **necomis**.
Diff: diff aplicat (sters) + diff aplicat (sters) +
diff aplicat (sters). Raport: `docs\cercetare\rec_s4_valuta_dialog.md`.

**Ramas de verificat pe ecran de Marius** (netestabil headless, dialogul e modal `Show(1)`): tastarea
reala in caseta de pret pe un document in valuta, eticheta de valuta afisata, si interactiunea cu
bifa „pret cu TVA" in timp ce se editeaza pretul in valuta.

**Datorie mica de stil, preexistenta**: comentariul de metoda de la `AdaugaLinieTvdDinArticol`
(`omodificari.vc2:13081-13085`) are 5 randuri si contine o justificare de proiectare („separata de
`Click` ca sa fie testabila..."), peste regula „o linie, strict functional" din decizia 29. **Nu a
fost introdusa de aceasta livrare** — venea din sub-blocul B partea 2, iar runda de acum doar i-a
actualizat continutul, la aceeasi lungime. De curatat cand se mai atinge metoda.

## #6 / S4 sub-blocul C, partea 2 — verdictul de corelatie ACT/RUL, GATA 09.08.2026

Pe `pgfArticole.PAGE3` (`COMUN\clase\omodificari.vc2`): doua randuri noi (`Total ACT`, `Total RUL`)
plus un indicator informativ cu 3 stari (sincronizat/divergent/nu se aplica), calculate in metoda
noua `ActualizeazaVerdictActRul` (apelata din `ActualizeazaBaraTotaluri`). Formulele erau deja
verificate in `cercetare\rec_suma_act.md` — s-au aplicat direct. `tvd` capata coloana `in_stoc`
(`ofacturare_editare.prg`, extinde interogarea existenta, nu deschide una noua) pentru corectia
liniilor nestocate din `RUL`. Randul 2 a cerut spatiu vertical nou: `pgfArticole.Height`/
`frm_modific2024.Height` +22px, 4 butoane din dreapta mutate cu acelasi delta; grid-ul de articole
**nu s-a atins** (0 linii pierdute). Detalii, cens de octeti, teste: `cercetare\rec_s4_runda3c2.md`.

**Descoperire pe parcurs**: pe documentul de test folosit pentru suita noua, randurile `RUL`
"duplicat" (`ID_TIP_RULAJ=0` care dubleaza exact un rand din perechea `ID_TIP_RULAJ=3`, semnalate ca
intrebare deschisa in `rec_suma_act.md` F.3) fac ca formula **aplicata exact cum a fost specificata**
sa dea "divergent" desi documentul e corect emis (`ACT`=1924.59, `RUL` literal=3728.18). Nu s-a
adaugat o regula de excludere nedecisa — ramane intrebare pentru Marius (vezi raportul).

**Testat**: regresie neschimbata (`test_page3_articole.prg` 14/2, `test_incarca_vanzare_din_nota.prg`
5/0, `test_adauga_linie_articol.prg` 20/0, `test_adauga_linie_valuta.prg` 6/0,
`test_ui_sterge_linie.prg` 8/0), suita noua `test_verdict_act_rul.prg` **18 PASS / 0 FAIL** (calcul
verificat prin recalcul independent SCAN, marcaj "(ajustat)", text informativ, tip=51 fortat "nu se
aplica", ascundere pe transfer/custodie, alegere cont pe grupa de tip, corectie sintetica pe linie
nestocata). Cens de octeti: stricat si reparat (acelasi tipar cunoscut), identic cu baseline la
final. **Scris in binar** (write-back OK dupa un fidelity-check picat pe formatarea liniilor goale,
rezolvat prin adoptarea textului regenerat), **necomis**. Diff:
diff aplicat (sters) + diff aplicat (sters).

**Reverificat de orchestrator pe starea de pe disc** (nu din raportul agentului): cifrele numarate
din loguri, nu citite din raport — toate se confirma, inclusiv cele 18/0 ale suitei noi. Rularile
(18:03-18:08) sunt **dupa** ultima editare de cod (`omodificari.vc2` 17:59:38,
`ofacturare_editare.prg` 17:50:48), deci nu se repeta golul de acoperire de ieri. Text si binar
sincrone; `ActualizeazaVerdictActRul`, `lblTotalAct`, `lblTotalRul`, `lblVerdict`, `lRulAjustat`
**confirmate prezente in `.VCT`**. Cens de octeti pe `omodificari.vc2`: **`2 aa / 2 e3 / 2 fe`, zero
`EF BF BD`** — identic cu baseline. Testul de garda (`ofacturare_editare.prg` scos din
`SET PROCEDURE` -> `PageCount = 2`) trece, deci ROACONT/ROAGEST raman intacte. Zero procese ramase,
zero scrieri in Oracle, zero commituri.

**CELE DOUA INTREBARI AU PRIMIT RASPUNS** (Marius, 09.08.2026) — deciziile **36** si **37**, si
**amandoua cer o runda de corectie pe cod**:
1. **Suma `RUL` se face doar pe `ID_TIP_RULAJ = 0`** (decizia 36) — perechile `3` sunt miscari
   virtuale, tin locul procesului verbal de schimbare de pret. Asta inlocuieste formula aplicata,
   inchide fals-pozitivul de pe `cod=1140895` (suma pe `0` da exact 1924.59) si **elimina complet**
   nevoia de euristica pe potrivire de valoare.
2. **Contul pe rate/contract**: se accepta **`4111`, `411` si `461`** (decizia 37), nu doar `4111`.

**Corectia deciziilor 36 si 37, GATA 09.08.2026** (`cercetare\rec_s4_runda3c3.md`): formula `RUL`
schimbata la `SUM((cant+cante)*pretvtva) FOR id_tip_rulaj=0`; contul de referinta pe tip 2/6/52
extins la o lista (`4111,411,461`) prin `$` pe string delimitat, in loc de `==` pe o singura
valoare. Pe `cod=1140895`: `Total ACT` = `Total RUL` = **1924.59**, verdict **sincronizat**
(asertia veche care astepta "divergent" a fost inversata, cu verificare explicita a cifrei).
Regresie neschimbata + suita dedicata **26 PASS / 0 FAIL** (18 vechi + 8 noi: excludere
`id_tip_rulaj=3`, includere `id_tip_rulaj=0`, cele trei conturi rate/contract). Scris in binar,
necomis. Diff: diff aplicat (sters) + diff aplicat (sters).
**Reverificat de orchestrator pe disc**: cifre numarate din loguri (26/0 pe suita dedicata, regresie
`14/2 · 5/0 · 20/0 · 6/0 · 8/0`), rulari 18:40-18:42 **dupa** ultima editare (18:34:03); filtrul din
cod e `SUM (Nvl(cant,0)+Nvl(cante,0))*Nvl(pretvtva,0) FOR Nvl(sters,0)=0 AND Nvl(id_tip_rulaj,0)=0`
(`omodificari.vc2:13035-13036`); cens de octeti `2 aa / 2 e3 / 2 fe`, zero `EF BF BD`; text si binar
sincrone. **Trei lucruri bine facute, de pastrat ca tipar**: (1) toate cele trei sume
(`tact`/`trul`/`tvd`) salveaza si restaureaza `Recno()` cu garda `Between(...)` si `GO ... IN alias`,
plus work-area restaurata la final — exact defectul din partea 1, care nu s-a repetat; (2) lista de
conturi se testeaza cu `(','+Alltrim(scc)+',') $ lcCont`, deci **delimitata prin virgule**, ceea ce
inchide capcana prefixului `411`/`4111` mai bine decat un `==` repetat; (3) exista asertie ca pe
`tip=1` contul ramane **strict** `4111` — largirea la `411`/`461` nu scapa pe facturile obisnuite.

**Ce urmeaza** (stabilit de Marius, 09.08.2026): **intrarea directa in valuta in
`frm_articol_factura`** — decizia 35. **Premisa deciziei a fost corectata** intre timp: nu cere
atins `ofacturare.vc2` (vezi decizia 35 mai jos si handoff intermediar (sters)).

Ultima actualizare anterioara: **09.08.2026**, dupa **cele doua defecte de pe pagina de articole
(culoare + valuta), REZOLVATE**.

## PREDARE — sesiunea din 09.08.2026 s-a incheiat la prag de context

Cele patru blocuri cerute de Marius ("toate") plus doua fire nascute din ele sunt **terminate, scrise
in binar, necomise**. **Nimic nu e intr-o stare periculoasa**: toate perechile text/binar sunt
sincrone (verificat pe mtime), zero procese `vfp9.exe` ramase, **zero scrieri in Oracle** in toata
sesiunea, **zero commituri** pe niciun arbore.

**Inchise azi**, fiecare cu agent proaspat si fiecare verificat pe disc de orchestrator (nu din
raportul agentului): datoria 6 (baza de regresie) · cei 5 apelanti `frm_modific2024` + linia din
`roagest.prg` · sub-blocul B partea 1 (stergere logica) · sub-blocul C partea 1 (bara de totaluri +
discount de antet) · sub-blocul B partea 2 (adaugare de linii + selector) · fixul de culoare si valuta.

**Ce urmeaza dupa aceasta predare** — verdictul `ACT`/`RUL` s-a inchis intre timp (vezi sectiunea de
mai sus); ramane doar **intrarea directa in valuta in `frm_articol_factura`** (decizia 35).

**Cifrele de regresie de plecare** (masurate pe starea de pe disc la inchiderea sesiunii):
`test_page3_articole.prg` **14 PASS / 2 FAIL** (cele 2 = artefactul headless de la datoria 7, **nu se
repara**), `test_incarca_vanzare_din_nota.prg` **5/0**, `test_adauga_linie_articol.prg` **20/0**,
`test_adauga_linie_valuta.prg` **6/0**, `test_ui_sterge_linie.prg` **8/0**.

**Avertisment pentru sesiunea urmatoare**: verificarea pe disc a prins azi **patru erori de
raportare** care altfel intrau tacit in stare — doua cifre umflate (`7/7` cand logul avea 6, `10/10`
cand avea 9), o cauza atribuita gresit (esecurile de captura — era `-SyncDir`, nu masina ocupata), si
o premisa gresita propagata chiar de orchestrator (`tip_valuta = 0`). **Cifra se ia numarand liniile
din log, nu din raport**, si dovada ca rularea a ajuns la capat e linia de `REZULTAT`.

## #6, doua defecte noi pe pagina de articole (culoare linie stearsa + valuta linie noua) — REZOLVATE 09.08.2026

Raportate dupa livrarea sub-blocului B partea 2 (mai jos). Ambele in `COMUN\clase\omodificari.vc2`
(+ `ofacturare_editare.prg` pentru al doilea). Write-back facut (fidelity check OK), text si binar
sincrone, **necomise**. Backup dinaintea fixului: `omodificari.vc2.pre_fix_culoare.bak`,
`ofacturare_editare.prg.pre_fix_culoare.bak`. Diff: diff aplicat (sters) +
diff aplicat (sters).
**Reverificat de orchestrator pe starea finala de pe disc**: `ofacturare_editare.prg` fusese modificat
la 17:08:48, adica **la 40 de secunde dupa ultima rulare de test** (17:08:08), deci starea livrata nu
era acoperita de nicio suita. Rerulat `test_page3_articole.prg` pe starea de pe disc: **14 PASS /
2 FAIL**, exit 0, zero dialoguri — identic cu baseline-ul, cele 2 FAIL fiind artefactul headless de la
datoria 7. Editarea era antetul fisierului. Golul e inchis.

- **Defectul 1 — marcajul vizual al liniei sterse nu se vedea, cauza reala gasita**:
  `grdArticoleFactura` e `ADD OBJECT ... AS _grdrow` (`_grd_base.vc2:445`), iar `_grdrow.Init`
  (`_grd_base.vc2:474-487`) face necondiționat `This.SetAll("DynamicForeColor", "iif(RECNO()=
  This.nRecno,...)", "Column")` cand `nrgbrow=1` (implicit) — asta **suprascrie la instantiere**
  `DynamicForeColor`-ul pe `sters` scris in clasa, pe toate cele 14 coloane, cu o expresie de
  evidentiere-linie-curenta care ignora `tvd.sters` cu totul (de-asta pixelii ieseau negri puri,
  nu gri). `grdRulaje`/`grdRulajeObinv` (paginile 1/2) ocolesc problema cu `Init` GOL, care taie
  intreg lantul `DoDefault()` (deci si editabilitatea din `_grid.Init`) — solutie prea larga pentru
  `grdArticoleFactura`, care are nevoie sa ramana editabil. **Fix cu o singura proprietate**:
  `nrgbrow = 0` pe `ADD OBJECT`-ul gridului (`omodificari.vc2:12317`) — tipar deja folosit in alte
  20+ griduri din suita (`configurare.vc2`, `onomenclatoare.vc2`), opreste doar blocul de
  evidentiere din `_grdrow.Init`/`AfterRowColChange`, fara sa atinga `DoDefault()` -> `_grid.Init()`
  (editabilitatea `cantitate`/`pret`/`pret_cu_tva` ramane intacta, verificat).
  **Dovedit cu esantionare de pixeli, nu vizual**: `screenshots_after_fix_culoare\
  step_0_contrast_gri_vs_negru.png` (document cu 4 linii, linia 2 marcata stearsa, linia curenta a
  gridului mutata pe linia 3 ca sa nu acopere culoarea de testat) — pixelul cel mai inchis pe linia
  stearsa e `RGB(150,150,150)` (exact culoarea din `DynamicForeColor`), pe liniile normale e
  `RGB(0,0,0)`. A doua captura, `step_0_linia_grizata.png` (document cu 2 linii), confirma acelasi
  lucru. Capturile "before" (pixeli negri puri pe linia stearsa, din sesiunea anterioara) mutate in
  `screenshots_before_fix_culoare\`.
- **Defectul 2 — liniile adaugate intrau fortat in RON, chiar pe documente in valuta**:
  `AdaugaLinieTvdDinArticol` nu avea niciun camp `tip_valuta` de reparat (`tvd` nu are asa ceva —
  view-ul `VVANZARI_ARTICOLE` nu-l expune); cauza reala era in alta parte: `pret`/`discount_unitar`
  ale liniei noi veneau direct din dialogul `frm_articol_factura`, care lucreaza in RON
  (`poDate.in_valuta` hardcodat 0), si se scriau NECONVERTITE in `tvd` — dar bara de totaluri
  (`ActualizeazaBaraTotaluri`, decizia 33) insumeaza `tvd.valoare` **brut** si inmulteste o singura
  data cu `tvanz.curs`/`multiplicator`, presupunand ca toate liniile sunt deja in valuta
  documentului (verificat pe date: `id_vanzare=1037`, document EURO curs 5.2688, linia are
  `pret=200` brut = 200 EUR, nu 200 RON). O linie noua in RON nefiltrata prin acest cursor umfla
  totalul convertit. **Fix, fara sa ating dialogul** (`frm_articol_factura`/`ofacturare.vc2` nu
  sunt in proprietatea acestei livrari, iar `poDate.in_valuta=1` ar cere validare suplimentara
  `zi_curs`/`id_valuta` netestabila headless): `AdaugaLinieTvdDinArticol` converteste acum
  pretul/discountul RON calculate de dialog in valuta documentului
  (`* tvanz.multiplicator / tvanz.curs`, no-op cand documentul e RON — `curs=multiplicator=1`), si
  preia `id_valuta`/`nume_val` de pe `tvanz` in loc de `.Null.`/gol. `tvanz` extins cu
  `in_valuta`/`id_valuta`/`nume_val` (join nou pe `nom_valute` in `IncarcaVanzareNota`,
  `ofacturare_editare.prg:150-176`) — coloane confirmate pe schema (`VANZARI.IN_VALUTA`/`ID_VALUTA`
  exista, `nom_valute`: 0=LEI, 1=USD, 2=EURO, 3=RON). **Limitare ramasa, documentata**: dialogul
  tot lucreaza in RON (utilizatorul introduce pretul in RON chiar si pe un document in valuta) —
  doar STOCAREA e acum corecta valutar; a face dialogul sa accepte pret direct in valuta ar cere
  `poDate.id_valuta`/`zi_curs` si atingerea `ofacturare.vc2`, in afara scope-ului primit.
- **Testat**: regresie neschimbata — `test_page3_articole.prg` **14 PASS / 2 FAIL** (identic,
  cele 2 = artefactul headless de la datoria 7), `test_incarca_vanzare_din_nota.prg` **5/0**,
  `test_adauga_linie_articol.prg` **20/0** (cazul RON, curs=1 — conversia e no-op, neregresat).
  Suita noua `test_adauga_linie_valuta.prg` (document real + `tvanz` suprascris manual cu
  curs=5.2688/EURO, ca sa simuleze un document in valuta — **motivarea de atunci, „nu exista in schema
  un caz descoperibil simultan cu articole si in valuta reala", s-a dovedit GRESITA**: exista 25 de
  documente `IN_VALUTA=1` cu linii active, vezi sectiunea S5; simularea ramane valida ca test, dar nu
  era singura optiune): **6 PASS / 0 FAIL**, verifica pretul convertit
  (200 EUR), `id_valuta`/`nume_val` preluate, si bara de totaluri recompunand exact 1053.76 RON.
  Suita UI noua `test_ui_culoare_contrast.prg` (captura + esantionare pixeli, de mai sus): log
  complet pana la `REZULTAT`, exit 0, zero dialoguri. Toate rulate sub `watchdog_vfp.ps1`/
  `vfp_ui_harness.ps1 -SyncDir` explicit.
- Cens de octeti: stricat o data (Edit-ul pe `omodificari.vc2` a reencodat cele doua `Caption`
  cu diacritice `Renunțare/Adăugare/Ștergere`, capcana deja cunoscuta), reparat byte-cu-byte cu
  Perl inainte de write-back; cens final identic cu baseline, `2 aa/2 e3/2 fe`, zero `EF BF BD`,
  verificat inainte si dupa.

Ultima actualizare anterioara: **09.08.2026**, dupa **sub-blocul B, PARTEA 2 — adaugarea de linii, GATA**.
Pe `pgfArticole.PAGE3`: buton nou `cmdAdaugaArticol` (langa `cmdStergeArticol`), care alege un
articol prin `caut_articol()` (selector existent pe nomenclator, fara stoc, fara politica de
pret — decizia 34), deschide dialogul real `frm_articol_factura` (`gnScadereStoc=0` — decizia
15, fara verificare de stoc), si la OK adauga in `tvd` o linie noua cu `id_vanzare_det=0` prin
metoda noua `Thisform.AdaugaLinieTvdDinArticol` (separata de `Click` ca sa fie testabila fara
dialogul modal). `poArticol` se construieste cu functia noua `CreeazaPoArticolNouTvd`
(`ofacturare_editare.prg`), pe modelul PROVEN din suita #7 (`test_pret_cu_tva_dialog.prg`, 49+11
proprietati). **Limitare cunoscuta**: doar linii in RON (`tip_valuta=0` fix); editarea unei linii
existente prin acelasi dialog (dublu-clic) **nu e in scope**, ramane nefacuta. Testat: regresie
neschimbata (`test_page3_articole.prg` 14/2, `test_incarca_vanzare_din_nota.prg` 5/5), suita noua
`test_adauga_linie_articol.prg` **20/20 PASS** (headless, direct pe functii — `Show(1)` modal
netestabil headless). **Cele doua goluri lasate de partea 1, inchise**: (1) comutarea inapoi a
stergerii (al doilea click, `sters` 1->0) — asertia mutata inainte de `HarnessStep`, acum **8/8
PASS dovedit pe ambele sensuri**; (2) captura vizuala a grizarii `DynamicForeColor` — **obtinuta**
(cauza reala a esecurilor anterioare: `gcSyncDir` din test nu se potrivea cu `-SyncDir` implicit
al `vfp_ui_harness.ps1`, nu masina ocupata), si **reveleaza un defect real, nou descoperit**:
culoarea gri nu se aplica vizual (verificat prin esantionare de pixeli, nu doar vizual — linia cu
`sters=1` are pixeli negri puri, imposibil daca `RGB(150,150,150)` s-ar aplica), desi codul
`DynamicForeColor` e corect scris pe toate cele 14 coloane. **Defectul apartine livrarii
anterioare** (stergerea logica, sub-blocul B partea 1) — nereparat, predat mai departe. Cens de
octeti stricat si reparat de 2 ori in sesiune (acelasi tipar cunoscut), identic cu baseline la
final: `2 aa/2 e3/2 fe`, zero `EF BF BD`. **Scris in binar (write-back OK dupa 2 fidelity-check-uri
picate pe ordine, rezolvate prin adoptarea textului regenerat), necomis.** Diff:
diff aplicat (sters) (+ diff aplicat (sters)).
Raport: `docs\cercetare\rec_s4_runda3b2.md`.

Inaintea acesteia, in aceeasi zi: **sub-blocul C, PARTIAL — bara de totaluri + discount de
antet (partea 1)**. Pe `pgfArticole.PAGE3`, sub `grdArticoleFactura`: bara noua cu totalul liniilor
active convertit RON la cursul documentului (decizia 33, `tvanz.curs`/`multiplicator` adaugate),
discountul de antet editabil (`tvanz.discount`, decizia 17), total net (linii - discount) si totalul
salvat vechi ca referinta; ascunsa pe transfer/custodie (decizia 22), grid-ul ramane vizibil.
**Nu s-a reutilizat clasa `_grdfooter1`** (mecanism strict de sumare pe coloane de grid, nu poate
converti valutar/edita/afisa text liber) — bara noua respecta doar pozitia si stilul ei (imediat sub
grid, 35px, spatiu deja neutilizat, 0 linii pierdute din grid). Doua defecte reale gasite si reparate
in aceeasi sesiune (nu preexistau): `tvanz` nu avea placeholder in `Load()` (controlul editabil legat
pe `tvanz.discount` pica la instantiere, eroare 1736), si `SUM...FOR` din metoda noua muta pointerul
in `tvd` fara sa-l restaureze (rand citit gresit dupa editare) — ambele descoperite prin regresia
headless, nu prin inspectie. Testat: `test_page3_articole.prg` **14 PASS / 2 FAIL** (cele 2, artefact
headless cunoscut de la datoria 7), `test_incarca_vanzare_din_nota.prg` **5/5**, exit 0, zero
dialoguri. Test UI nou `test_ui_bara_totaluri.prg`: **9 PASS / 0 FAIL in log** (nu 10/10 cum s-a
raportat initial — renumarat de orchestrator), rularea se opreste la `READY 0` fara linia de
`REZULTAT`, pe
`cod=1139934/id_vanzare=882` — bara vizibila, tipuri de camp corecte, total calculat exact, discount
propagat, total net recalculat, ascundere/reafisare pe schimbarea de tip verificate direct pe
proprietatea `nTipVanzare`. **Captura de ecran n-a putut fi obtinuta** (`vfp_ui_harness.ps1` in mod
`-A` a esuat sa detecteze pornirea in 8 incercari, desi testul a rulat complet pana la `READY 0` —
acelasi tipar de infrastructura documentat mai jos, nu problema de cod). Cens de octeti: `2 aa/2 e3/
2 fe`, zero `EF BF BD`, identic inainte/dupa (stricat si reparat de mai multe ori in timpul editarii,
capcana deja cunoscuta). **Scris in binar (write-back OK dupa 3 rulari, fidelity-check picat pe
ordine de fiecare data, rezolvat prin adoptarea textului regenerat), necomis.** Diff:
diff aplicat (sters) (+ diff aplicat (sters), izolat).
Raport: `docs\cercetare\rec_s4_runda3c.md`. **Verdictul de corelatie cu `ACT`/`RUL` NU e facut** —
formulele sunt deja stabilite si verificate pe date in `rec_suma_act.md`, predat ca partea 2 a
sub-blocului C (contul pe tip, filtrul `cod+an+luna`, indicatorul cu 3 stari, threading `an`/`luna`
in clasa).

Inaintea acesteia, in aceeasi zi: **sub-blocul B, PARTIAL — doar stergerea de linii**
(butonul `cmdStergeArticol` pe PAGE3, comuta `tvd.sters`/`lmodificat`, marcaj vizual
`DynamicForeColor` gri pe randul marcat). **Adaugarea de linii (dialog `frm_articol_factura`) NU
e facuta** — sub-blocul s-a dovedit prea mare pentru un context si a fost impartit, cu aprobarea
briefingului. Cercetarea de contract pentru adaugare (proprietati `poArticol`/`poDate` citite de
dialog, cum se ocoleste `gnScadereStoc`, ce lipseste inca — picker de articol) e completa si
predata in handoff intermediar (sters). Testat: regresie neschimbata (`14/2`, `5/5`),
plus test UI nou dedicat (`test_ui_sterge_linie.prg`). **Atentie la cifra**: logul are **6 PASS /
0 FAIL**, nu 7/7 cum s-a raportat initial — rularea s-a **taiat la `READY`**, adica exact la
handshake-ul de captura, si n-a ajuns la linia de `REZULTAT`. Dovedit: butonul exista si e vizibil,
click-ul pune `sters=1` + `lmodificat=.T.` pe linia curenta, linia vecina ramane neatinsa.
**NEdovedit: comutarea inapoi** (al doilea click, care readuce `sters=0`) — asertia era programata
dupa handshake si n-a mai rulat. **Captura de ecran n-a putut fi obtinuta** (`vfp_ui_harness.ps1` in mod `-A` a esuat sistematic de 16 ori sa detecteze pornirea,
desi procesul chiar a rulat testul complet pana la capat de fiecare data — problema de
infrastructura/masina ocupata, nu de cod; detalii in raport). **Scris in binar (write-back
FACUT dupa un fidelity-check picat pe ordine, rezolvat prin adoptarea textului regenerat),
necomis.** Diff: diff aplicat (sters). Raport: `docs\cercetare\rec_s4_runda3b.md`.
Inaintea acesteia, in aceeasi zi: **extinderea la cei 5 apelanti `frm_modific2024` + linia din
`roagest.prg`** — helper nou `PregatesteArticoleFacturaEditare` in `ofacturare_editare.prg`, apelat
gardat inainte de `Createobject` la `afisjurcom.do_modifica` (registrul jurnal, viu in ROACONT),
`anaf_efactura.importmodifica` si cele doua `.sc2` de import; linia `SET PROCEDURE TO
ofacturare_editare.prg` adaugata in `roagest.prg`. Detalii: `docs\cercetare\rec_s4_apelanti.md`,
diff diff aplicat (sters). Mai devreme: **rezolvarea datoriei 6** — baza
de regresie #6/S4 e din nou solida, iar suitele nu mai hardcodeaza documente: si-l descopera
singure, deci nu mai mor la urmatoarea realocare de `cod`. Mai devreme inca: doua defecte de
editare pe pagina de articole (coloanele cantitate/pret needitabile, valoare defazata la bifa
"pret cu TVA"), dovedite pe ecran; doua defecte de afisare (grid gol, pageframe colapsat), trei
defecte pe editarea facturii si regresia de encoding din `ofacturare_comun.vc2`. **S4 runda 3A
are write-back-ul FACUT.** Tot ce e mai sus e scris in binar si **necomis**.

**In lucru acum** (decizia lui Marius, 09.08.2026 — "toate"), strict secvential, cate un agent proaspat
per bloc, pentru ca se ating aceleasi fisiere: 1. datoria 6 **GATA**; 2. extinderea la cei 5 apelanti +
linia din `roagest.prg` **GATA**; 3. sub-blocul B — **stergerea si adaugarea GATA** (integral,
`docs\cercetare\rec_s4_runda3b2.md`); 4. sub-blocul C — **partea 1 (totaluri + discount) GATA,
verdictul de corelatie ACT/RUL preda mai departe** (`docs\cercetare\rec_s4_runda3c.md`).

## Stare la zi

| Punct | Stare |
|---|---|
| **#8** — denormalizare `VANZARI` | **COMIS** (SVN r17990-r17993, r17995). Ramane build-ul ROAAUTO la Marius si cateva datorii mici, mai jos |
| **#7** — pret cu TVA pe linie | **COMIS si LIVRAT** (SVN r17998/r17999/r18001, git `8df728c`/`46df824`+). Build + **deploy 2.11.14 facut de Marius pe 08.08.2026** |
| **#6** — editare factura emisa | **IN LUCRU**, pornit 08.08.2026. 10 stories, `plan_06_editare_factura.md`. **S1-S3 si S4 rundele 1-2 sunt COMISE in SVN** (r18003-r18006, aprobate de Marius 08.08.2026): view-ul `VVANZARI_ARTICOLE`, helperele comune, pagina de articole doar-afisare, butonul de editare, inregistrarile din `roafacturare.prg` si `roacont.prg`. S4 runda 3A (grid editabil, sub-blocul A) e **scrisa in binar**. Separat, trei defecte de editare (`crsJtvaTemp` neinitializat, doua butoane de modificare, 12 diacritice distruse) si **doua defecte de afisare** (grid gol, pageframe colapsat) **REZOLVATE**, scrise in binar, necomise. **Extinderea la cei 5 apelanti + linia din `roagest.prg` GATA** (09.08.2026, `docs\cercetare\rec_s4_apelanti.md`) |
| **#10 / #11 / #12** | **amanate**, motivele in `plan_index.md` |

`versiune_db.txt` = **`2026_08_08_01`** (bumpat 08.08.2026 pentru view-ul `VVANZARI_ARTICOLE`; #7 n-a avut DDL).

### Ce a livrat #7 (pentru context, nu de refacut)

Lucrare VFP-only, doar in `COMUN\clase\ofacturare.vcx`. Bifa "Pret cu TVA inclus" editabila in
dialogul per-articol; buton de modificare + dublu-clic pe linie in `frm_facturare_articole`, ambele
prin `do_modifica`; plafonul de cantitate recalculat din stocul disponibil; articolele gestionabile
redeschid tabelul cu gestiuni (`do_alege_stoc` cu `tnIdTempExclus`). Infrastructura de calcul
exista deja si ramifica pe `VANZARI_DETALII.PRET_CU_TVA` — lipsea doar posibilitatea de a schimba
flagul.

**Suita de regresie e in `comun.git`** (`c5b0ce3`), `COMUN\utile\Teste\facturare_pret_cu_tva\`:
4 niveluri, 38 de asertii, toate PASS. Nu e in SVN (`utile\Teste` e ignorat acolo).

**Ce preda #7 catre #6**: sectiunea "Ce preda #7 catre S6" din `plan_06_editare_factura.md`.
Punctul care conteaza: plafonul de cantitate din #7 se sprijina pe **cursorul de stoc deschis in
formularul de compunere**; la o factura deja salvata acel cursor poate sa nu existe, deci #6 va avea
nevoie de alta sursa pentru plafon.

## #6, runda 1 (S1-S3) — implementat 08.08.2026, corectii 08.08.2026

Diff: diff aplicat (sters) + diff aplicat (sters) (netrimise inca
la commit, asteapta review). Patch-urile per runda raman pe disc pentru istoric.

- **`COMUN\clase\ofacturare_comun.vc2`**, clasa `frm_facturi`: metoda `do_editare_factura`
  (clonata dupa `do_sterge`: garzi luna inchisa / document sters / proforma / luna curenta /
  referinte / eFactura, apoi `IncarcaCursoareModificareNota` + `Createobject([frm_modific2024])`
  + write-back prin `OSCRIE_IN_FISIERE` + `pack_contafin.finalizeaza_modificare_nota`, dupa
  tiparul din `afisjurcom.do_modifica`). Buton `But_editare1`, in `cbuton3` alaturi de
  `but_modifica1`/`But_modifica2` (decizia lui Marius din 08.08.2026 — fara token nou).
- **`COMUN\programe\ofacturare_editare.prg`** (fisier nou, inregistrat in `Programe\roafacturare.prg`
  cu `Set Procedure To ofacturare_editare.prg Additive`): `EsteInEFactura(tnIdFact)` (garda extrasa
  din `do_modifica`) si `IncarcaCursoareModificareNota(tnCod, tnAn, tnLuna, tlAratasterse)` (incarcarea
  cursoarelor notei/rulajelor, copiata din `afisjurcom.do_modifica`). Ambele reutilizabile din runda 2
  (inlocuirea codului inline din `afisjurcom`).
- **Gasit si reparat in runda 1** (lipsea din `Programe\roafacturare.prg`, altfel
  `Createobject('frm_modific2024')` pica cu "Class definition not found" chiar si in productie):
  `SET CLASSLIB TO omodificari.vcx additive`. ROAFACTURARE nu incarcase niciodata aceasta clasa —
  se foloseste azi doar din ROACONT/ROAGEST (registrul jurnal).
- **Corectii de review aplicate 08.08.2026** (diff aplicat (sters)):
  - `IncarcaCursoareModificareNota` propaga acum esecul: pe eroare Oracle la interogarea `vrul_tot` sau
    `vrul_obinv_tot` face `RETURN .F.` (curatand cursoarele deschise pana atunci), nu mai continua pana la
    `RETURN .T.` final ca si cum ar fi reusit. **Corectie de premisa fata de constatarea initiala**:
    `goExecutor.oExecute` intoarce strict succes/insucces (`CT_SUCCES`/`CT_INSUCCES`, peste `SQLExec`), NU
    numarul de randuri — deci `trul`/`trul_obinv` **se creeaza (goale) chiar si la 0 randuri** in
    `vrul_tot`/`vrul_obinv_tot`; verificat live pe `cod=1140885` (0 randuri `rul`). Scenariul "Alias TRUL
    is not found" pe o factura de servicii nu se reproduce — bug-ul real e ingust, doar pe eroare Oracle
    efectiva la interogarea de rulaje (path netestabil fara sa stric conexiunea deliberat). Apelantul
    (`do_editare_factura`) ramane neschimbat pe partea de `trul`/`trul_obinv` (acces neconditionat, ca si
    in `afisjurcom.do_modifica` la `buton=1`) — corect prin constructie, pentru ca acum ajunge acolo doar
    daca incarcarea a reusit integral.
  - **Garda pe `id_set`: adaugata in runda 2, rafinata in runda 3, SCOASA DE TOT in runda 4**
    (diff aplicat (sters), decizia 24). Istoric, ca sa nu se reia: premisa ei era ca
    `PACK_FACTURARE.scrie_discount` scrie randurile `DISCOUNT`/`TVA DISCOUNT` cu `id_set + 5`, deci o
    nota poate avea 2 `id_set`. **Fals la destinatie**: `cumuleaza_note_act_temp` normalizeaza inainte
    de `ACT`, offsetul e tranzitoriu. Pe date: 558 de note legate de `VANZARI` cu un singur `id_set`,
    1 cu doua — si aceea e randul-gunoi `cod=0, an=0, luna=0`. Nici `ID_FACT = -1` din `scrie_discount`
    nu ajunge in `ACT` (zero randuri cu `id_fact <= 0` din 2020 incoace, `id_factd` niciodata NULL).
    Rapoartele istorice: `docs\cercetare\rec_garda_idset.md` (runda 3, premisa infirmata ulterior).
  - **Pozitionarea in `actactan`, corectata in runda 4** — problema reala, alta decat cea presupusa:
    primul rand al notei dupa `id_act` poate fi `INCASARE`/`INCASARE NUMERAR`, cu `id_fact` = al
    facturii **minus 1**. **39 de facturi** in schema de dev pe care un `Go Top` orb prelua `id_fact`-ul
    chitantei — bug preexistent din runda 1/2. Acum: `Locate For Nvl(id_fact,0) = lnIdFact` cu
    `lnIdFact` luat din `crsfacturi` (= `VANZARI.ID_FACT`), si abia pe esec `Go Top` + preluare de
    acolo. `lnIdSet`/`lnIdFactD` se citesc de pe randul astfel pozitionat. Efect colateral util:
    `lnIdFact` nu mai poate ajunge NULL in `Str()`-ul din apelul `finalizeaza_modificare_nota`.
    Dovezi: `docs\cercetare\rec_pozitionare_actactan.md`. Testat headless: 4 cazuri sintetice
    (nota normala / prim rand `INCASARE` / fara randul cautat / `lnIdFact = 0`) + regresie pe
    `cod=1140888`/`cod=1140885` — 6/6 PASS.
  - Repozitionarea finala `Go lnRecno` (dupa `Thisform.do_cauta()`, care rechestioneaza `crsfacturi`) a
    fost inlocuita cu `Locate For id_vanzare = lnIdVanzare` + fallback `Go Top`, conform
    `conventie_go_recno.md` (`id_vanzare` nu se schimba niciodata la editare, spre deosebire de `cod`).
- **Testat headless, pe date reale** (`MARIUSM_AUTO/ROA_CENTRAL`):
  - runda 1: flux real `vizualizare_facturi` -> `frm_facturi.Show(1)` condus prin Timer (`testare-ui-vfp.md`);
    butonul apare si e gatat corect de `cbuton3`; garzile **luna inchisa**, **luna curenta**, **document
    deja sters**, **eFactura** resping corect (mesaje verificate 1:1 prin mock `amessagebox`); pe
    `cod=1140888`, `frm_modific2024` se deschide fara eroare.
  - corectii: `COMUN\utile\Teste\editare_factura\test_incarca_cursoare.prg` (fara UI, pe conexiune reala)
    apeleaza direct `IncarcaCursoareModificareNota` pe `cod=1140888` (regresie: 24 randuri nota, `trul`
    10 randuri) si pe `cod=1140885` (0 randuri `rul`, `trul`/`trul_obinv` create dar goale) — fara eroare
    in niciun caz; plus un cursor sintetic cu 2 `id_set` distincte, confirmand ca garda noua ar detecta
    corect situatia (`Reccount=2`). **Netestat**: calea de eroare Oracle propriu-zisa din
    `IncarcaCursoareModificareNota` (ar cere ruperea deliberata a conexiunii) — verificata doar static,
    pe simetrie cu primul punct de control din aceeasi functie (deja existent, acelasi tipar).
  - write-back in `.vcx`/`.vct`: `txt2vcx.ps1 -AllowComun` — fidelity check OK, cod compileaza curat.
- **Calea de salvare (`buton=1`) — TESTATA REAL si TRECUTA, 08.08.2026.** Marius a aprobat explicit un
  test care chiar scrie in `MARIUSM_AUTO`. `COMUN\utile\Teste\editare_factura\test_writeback_buton1.prg`,
  doua treceri cu **COMMIT real** pe `id_vanzare = 1048`: `cod` 1140886 -> **1140893** (salvare fara
  modificari) -> **1140894** (cu explicatia unui rand `ACT` schimbata). Toate cele 5 verificari PASS,
  confirmate **independent prin `sqlplus` dupa rulare**, nu doar din log: randurile vechi `ACT`/`RUL`
  marcate `STERS=1`, randuri noi active pe `cod`-ul nou cu aceleasi sume / `id_set` (25010) / `id_fact`
  (8009658), `VANZARI` realiniat pe `cod`-ul nou cu totaluri neschimbate, `VANZARI_DETALII` neatins
  (corect — scrierea acolo e S5), iar explicatia modificata a ajuns in `ACT`. Raport:
  `docs\cercetare\rec_test_writeback.md`. **Cod-ul de test ramas in baza: 1140894** (documentul a fost
  realocat de doua ori, ireversibil).
  **Ce NU acopera**: validarea din `inainte_de_do_termin` (`omodificari.vc2:13357-13549`) — sarita,
  `buton=1` fortat direct — si comportamentul real al lui `frm_modific2024` la "Terminat", formularul
  nefiind instantiat deloc. Deci **lantul de scriere merge**; nu s-a dovedit ca utilizatorul ajunge la
  el prin fluxul UI complet. Doua lucruri distincte, a nu se confunda.
- **Netestat, la fel ca in runda 1**: garda **referinte** izolat (fara candidat "pozitiv" in datele de
  test); **inchiderea gratioasa** a
  `frm_modific2024` prin `do_renunt()` — blocata in mediul minimal de test (`ControlCount=0`), la fel ca
  in runda 1, deci nici repozitionarea finala (`Locate For id_vanzare`) n-a fost exercitata prin fluxul UI
  complet — doar prin analiza de cod si
  reconstructia verificata byte-cu-byte a `.vc2`.

## #6, S4 runda 1 (PAGE3, doar afisare) — in lucru, 08.08.2026

Sursa completa: `docs\cercetare\handoff_s4_runda1.md`. Modificarile sunt **pe disc, text si binar
sincronizate**, dar **fara diff livrat si fara raport** — runda nu e inchisa.

- **`COMUN\programe\ofacturare_editare.prg`**: doua functii noi la coada fisierului —
  `IncarcaVanzareNota(tnCod, tnNract, tcSerieAct, tdDataAct)` (randul din `VANZARI` corespunzator
  notei, in cursorul `tvanz`) si `IncarcaArticoleFactura(tnIdVanzare)` (liniile active din
  `VANZARI_DETALII` + denumiri articol/gestiune/valuta, in cursorul `tvd`).
- **`COMUN\clase\omodificari.vc2`** (`frm_modific2024`): `pgfArticole.PageCount = 3` cu
  `PAGE3.Caption = "Articole factura"`; grid nou `grdArticoleFactura` (13 coloane, `RecordSource="tvd"`,
  `ReadOnly` la nivel de grid **si** pe fiecare `Text1`); proprietati noi `lAreArticoleVanzari`,
  `nIdVanzare`, `nTipVanzare`; placeholder `CREATE CURSOR tvd` in `Load()`; bloc nou in `Show()` care
  cheama cele doua functii si comuta `PageCount` intre 2 si 3.
- **Schela de diagnostic SCOASA** 08.08.2026 (cele 5 linii `STRTOFILE(... diag_class.txt ...)` din
  `Init`/`Load`): restaurare din backup, text **si** binar, verificat prin diff ca acelea erau singura
  diferenta. Backup-uri pastrate in `COMUN\clase\`: `omodificari.vc2.pre_s4runda1.bak` (originalul
  dinainte de S4), `omodificari.vc2.pre_diag.bak` = `omodificari.vc2.mine_s4_full.bak` (hash identic,
  versiunea curata), `omodificari.vcx/.vct.mine_s4.bak` (binarul curat).
- **Testat, PASS, direct pe functii** (fara formular), pe date reale — suita
  `COMUN\utile\Teste\editare_factura\test_page3_articole.prg`: `cod=1140888` -> `id_vanzare=1050`,
  `tip=1`, 4 linii (coincide cu baza de regresie); `cod=1140885` -> `id_vanzare=1047`, `tip=-12`
  (confirma decizia 19 — detectia merge pe orice tip, nu doar facturi); `cod=1125486` -> 0 randuri
  (cazul negativ); coliziunea pe `cod=1139934` rezolvata corect de filtrul compus.
- **TESTAT LIVE, PASS** (08.08.2026, dupa trei blocaje separate, toate rezolvate — vezi capcanele):
  suita ruleaza sub watchdog cu **exit 0 si zero dialoguri**; `loForm.ClassLibrary` confirma ca se
  incarca fisierul editat. `cod=1140888` -> `PageCount = 3`, `lAreArticoleVanzari = .T.`,
  `nIdVanzare = 1050`; `cod=1125486` -> `PageCount = 2`, `lAreArticoleVanzari = .F.` Restul asertiilor
  din suita, neschimbate, tot PASS. Cele trei blocaje au fost: `DO ... WITH` prin referinta, harness-ul
  care incarca clasa din ROACONT, si proprietatile custom fara intrare `*p:`.
- **Exclus cu dovezi** (nu relua): nu e cursorul `tvd` lipsa (probat cu placeholder si cu pre-creare);
  nu e un gol preexistent de mediu (binarul original ruleaza curat in acelasi harness —
  `test_baseline_isolation.prg`, `PageCount=2`, fara dialog); `tradu()` din `_pageframe.Init()` e
  inofensiv; zero `CREATE SQL VIEW` / `USE ... VIA` in toata ierarhia de clase.
- **B.2 (marcaje stare linii) nu e in scope runda 1** — grid-ul e strict readonly; marcajele sunt runda 2.
- **Runda 1 e INCHISA pe cod si testata**, asteapta doar review-ul lui Marius. Diff:
  diff aplicat (sters) (2 fisiere, fata de backup-urile de dinainte de S4). Raport:
  `docs\cercetare\rec_s4_runda1.md`. Instrumentarea de depanare a fost scoasa din suita si suita
  rerulata dupa curatare — 7 PASS, zero erori. `test_baseline_isolation.prg` sters (temporar prin
  design, si cu concluzie nula: testa copia ROACONT). **Fara commit — se asteapta aprobarea.**
- **BLOCANT 1 — `Go Top In tact` orb: CONFIRMAT PE DATE** (`docs\cercetare\rec_gotop_tact_s4.md`).
  `Show()` (`omodificari.vc2:14171`) citea `nract`/`serie_act`/`dataact` de pe primul rand dupa
  `id_act`, care poate fi `INCASARE`. Pe **62 de note** din schema de dev unde primul rand e o
  incasare si nota chiar are rand in `VANZARI`, filtrul compus intoarce **0 randuri pe 52 (84%)** —
  PAGE3 lipsea **silentios**. Pe cele 10 ramase nimerea corect (aceleasi valori pe ambele randuri);
  **niciodata alt document**, deci bugul e "pagina lipsa", nu "date gresite". Suita veche nu-l acoperea
  (repeta acelasi `Go Top`). Cazuri reproductibile: `cod=1137874/2009/8` -> `id_vanzare=506`,
  `cod=1139934/2021/12` -> `id_vanzare=882`.
- **BLOCANT 2 — `Show()` rupe ROACONT si ROAGEST** (gasit 08.08.2026, verificat pe puncte de intrare).
  `frm_modific2024` e in `COMUN`, deci ajunge in toate produsele. `ROACONT\Programe\roacont.prg:233` si
  `ROAGEST\Programe\roagest.prg:175` incarca `omodificari.vcx` dar **nu** inregistreaza
  `ofacturare_editare.prg` — o face doar `Programe\roafacturare.prg:214`. Apelurile negardate
  `IncarcaVanzareNota`/`IncarcaArticoleFactura` din `Show()` ar fi rupt **"registru jurnal >
  modificare"** in doua produse care azi merg. Nu ascunde o pagina, rupe o functie existenta.
  Runda 2 pune garda pe `Set("Procedure")` (degradare la `PageCount = 2`, fara eroare).
  **DECIS SI PARTIAL APLICAT** (Marius, 08.08.2026 — aprobat pentru ambele produse):
  `roacont.prg:212` **are deja** `SET PROCEDURE TO ofacturare_editare.prg ADDITIVE` (a intrat in
  r18006). `roagest.prg` **inca nu o are** — de adaugat, langa grupul de facturare (`:259`
  `ofacturare_comun.PRG`, `:305-307` `ofacturare.prg`/`oproceduri_facturare.prg`).
  **Capcana platita**: fisierul a intrat in SVN la r18004, dar copiile de `COMUN` din ROACONT si
  ROAGEST erau la r17987/r17977, deci **nu-l aveau pe disc** — ROACONT pornea pe un `SET PROCEDURE`
  catre un fisier inexistent. Rezolvat prin `svn update` pe ambele (08.08.2026, acum la **r18010**).
  Linia din `roagest.prg` are sens doar dupa update; altfel rupe si ROAGEST identic.
- **RUNDA 2 — IMPLEMENTATA SI TESTATA, 08.08.2026** (ambele blocante de mai sus + ancorarea view-ului).
  `IncarcaArticoleFactura` trece pe `select * from vvanzari_articole`; `Go Top In tact` orb inlocuit cu
  `IncarcaVanzareDinNota(tcAliasAct)` (incearca toate tripletele distincte `(nract,serie_act,dataact)`
  din `tact` pana gaseste un rand in `VANZARI`); garda `"OFACTURARE_EDITARE" $ Upper(Set("Procedure"))`
  pusa in `Show()` **si** `Load()` (placeholder-ul `tvd` are un fallback inline separat pentru cand
  garda nu trece, ca la ROACONT `CreeazaCursorTvdGol` nu exista); `AMESSAGEBOX` adaugat pe erorile
  Oracle din `IncarcaVanzareNota`/`IncarcaArticoleFactura`; cursoarele goale `tvd`/`tvanz` unificate in
  `CreeazaCursorTvdGol()`/`CreeazaCursorTvanzGol()`. Testat headless sub watchdog, exit 0/0 dialoguri,
  **10/10 PASS la data validarii** (cifra nu mai e valabila azi — baza de regresie s-a degradat,
  vezi datoria 6) (`test_page3_articole.prg`, extinsa cu cazurile `cod=1137874`->`id_vanzare=506`,
  `cod=1139934`->`id_vanzare=882` si un test de garda care scoate `ofacturare_editare.prg` din
  `SET PROCEDURE` si verifica `PageCount=2`). Verificat separat (test dedicat) ca `SCAN...ENDSCAN` din
  `IncarcaVanzareDinNota` continua corect chiar daca IncarcaVanzareNota schimba workarea in interiorul
  buclei. Write-back `.vc2`->binar OK (fidelity check trecut). Diff: diff aplicat (sters).
  Raport: `docs\cercetare\rec_s4_runda2.md`. **Fara commit — asteapta review.**
- **ANCORAREA COLOANELOR — REZOLVATA prin view Oracle dedicat** (decizia 26, 08.08.2026).
  `VVANZARI_ARTICOLE` e **creat si validat** pe `MARIUSM_AUTO` (`VALID`, 21 de coloane, verificat independent prin
  `sqlplus` dupa aplicare): `id_vanzare` + cele 20 consumate azi, valori **RAW**, fara conversie
  valutara, fara filtru `sters` (apelantul filtreaza, ca la `vact_tot`/`vrul_tot`). Script:
  `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_08_01_COMUN_VVANZARI_ARTICOLE.sql` (CRLF pur, idempotent,
  **necomis in SVN**). Proiectarea: `COMUN\docs\cercetare\rec_view_articole_vanzare.md`.
  - **`id_vanzare` era omis** din `SELECT`-ul vechi desi e cheia de filtrare — omisiune reala, corectata.
  - **`FACT_VFACTURI_DETALII` exista si a fost respins motivat**: recalculeaza `pret`/`discount_unitar`
    la cursul curent, pentru tiparire. Editarea are nevoie de valorile stocate, ca S5 sa scrie inapoi
    exact ce a citit — refolosirea lui ar fi mutat tacut preturile.
  - **VFP consuma view-ul cu `select *`**, nu cu lista de coloane. Recomandarea agentului (doar `FROM`
    schimbat, lista pastrata) rata cerinta: cu lista in cod, tot se intretine si codul la schimbarea
    structurii.
  - `UpdateVersiune` insereaza, nu face merge: scriptul apare de **doua ori** in `VERSIUNE` dupa proba
    de idempotenta. E datoria 4 deja cunoscuta, fara impact functional. Dupa redenumire, `VERSIUNE`
    contine si 2 randuri cu numele de lucru vechi — acelasi zgomot, aceeasi datorie.
  - **REDENUMIT `VVD_TOT` -> `VVANZARI_ARTICOLE`** (decizia 28, 08.08.2026). Reaplicat si reverificat
    pe `MARIUSM_AUTO`: `VALID`, 21 de coloane, 4 linii pe `id_vanzare = 1050`, idempotent la a doua
    rulare. `VVD_TOT` nu mai exista ca obiect. Scriptul contine doar `CREATE OR REPLACE VIEW`, fara
    `DROP` (Marius, 08.08.2026).
- **Raspunsul initial la cerinta de ancorare** (istoric, inainte de decizia 26 —
  `rec_review_ancorare_s4.md`):
  o coloana **adaugata** in `VANZARI_DETALII` nu rupe nimic azi; una **stearsa sau redenumita** pica
  **silentios** — `SELECT`-ul explicit esueaza pe Oracle, iar `IncarcaVanzareNota`/`IncarcaArticoleFactura`
  **inghit eroarea** si intorc cursor gol fara mesaj (spre deosebire de `IncarcaCursoareModificareNota`,
  care afiseaza `AMESSAGEBOX`). Recomandarea: **pastreaza gridul declarativ** (tiparul deja folosit de
  `grdRulaje`/`grdRulajeObinv` pe acelasi formular) si adauga doar `AMESSAGEBOX` pe cele doua functii
  noi — cateva linii, transforma golul tacut in semnal vizibil. **Respinse**: gridul dinamic din
  `AFIELDS()` (ar fi unicat pe formular — mai multa intretinere, nu mai putina) si `SELECT *` pe join
  brut (muta eroarea din SQL in binding-ul gridului, deci mai rau). Varianta curata pentru `SELECT *`
  ar fi un **view Oracle dedicat**, ca la `trul`/`tact` — migrare de schema, de pastrat pentru cand
  structura chiar incepe sa se miste des.
- Cod duplicat, minor: `CREATE CURSOR tvanz` s-a unificat in runda 2 in `CreeazaCursorTvanzGol`
  (`ofacturare_editare.prg:148`, apare o singura data). Ramane doar `CREATE CURSOR tvd` identic in
  doua fisiere (`ofacturare_editare.prg:260`, `omodificari.vc2:14082`) — duplicarea e obligatorie:
  in ROACONT/ROAGEST functia comuna nu e incarcata.

## #6, S4 runda 2 — COMISA in SVN 08.08.2026 (r18003-r18006)

**Comisul, pe revizii** — oglinda git e in urma, se sincronizeaza separat cu `git_sync.ps1`:

| Revizie | Ce contine |
|---|---|
| r18003 | `DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_08_01_COMUN_VVANZARI_ARTICOLE.sql` (nou) |
| r18004 | `COMUN`: `ofacturare_editare.prg` (nou), `omodificari.vcx/.vct`, `ofacturare_comun.vcx/.vct`, `reguli_lucru.md`, `scripturi-migrare-db.md` |
| r18005 | `ROAFACTURARE`: `roafacturare.prg`, `versiune_db.txt`, `CLAUDE.md` |
| r18006 | `ROACONT`: `roacont.prg` |

`docs\` ramane local (neversionat). **Fara changelog inca**: lucrarea n-a ajuns la utilizatori.

## #6, S4 runda 3 — PORNITA 08.08.2026, impartita pe sub-blocuri

Editare **in memorie**, fara nicio scriere in Oracle (asta ramane S5, runda 4). Se lucreaza pe
sub-blocuri mici, cu cate un agent proaspat, ca review-ul sa ramana mic.

**Sub-blocul A e SCRIS IN BINAR** (08.08.2026). Contrar a ce scria aici, write-back-ul s-a facut:
`omodificari.vct` contine `cSubtotalArt`, `lmodificat`, `cPretCuTvaArt`, iar textul are
`ColumnCount = 14`. Fidelity-check-ul picat descris in handoff intermediar (sters) a fost depasit
(remediul era ordinea `Header1` dupa `_checkbox1` la `cPretCuTvaArt`). Ramane necomis, ca tot restul.

Doua rezultate stabilite in runda 3A, de nu mai reluat:
- `VANZARI_DETALII.PRET_CU_TVA` e **flag logic 0/1**, nu pret numeric, desi coloana e numerica in
  cursor — verificat pe date, toate cele 1113 randuri active. De aceea coloana din grid e checkbox,
  dupa modelul `COMUN\clase\ofacturare.vc2:5817`.
- Numele coloanei de marcaj: **ales `lmodificat`**, dupa test — `_modificat` si `lmodificat` merg
  amandoua ca nume de camp de cursor VFP (verificat headless), s-a preferat `lmodificat` pentru stil.

- **A**: coloanele `cantitate`, `pret`, `pret_cu_tva` editabile inline in `grdArticoleFactura`;
  marcaj `lmodificat` pe linie in `tvd`, setat din `Valid`/`InteractiveChange` dupa tiparul lui
  `grdRulaje.cCant.Text1.Valid` (`omodificari.vc2:~14906`); subtotal live pe linie.
- **B**: dialogul per linie (reutilizarea `frm_articol_factura`), adaugarea si stergerea de linii
  (`id_vanzare_det = 0` pentru randuri noi, flag `sters` pentru stergere — B.2 din plan).
- **C**: discountul de antet editabil in `tvanz` (decizia 17) si bara de totaluri de control
  (decizia 20; fara bara pe transfer/custodie — decizia 22).

**Structura cursorului `tvd` se schimba mereu in DOUA locuri**, tinute identice:
`ofacturare_editare.prg:266` (`CreeazaCursorArticoleGol`) si `omodificari.vc2:14139` (ramura `ELSE`).
Ultimul camp se numeste **`valoare`** (fost `subtotal`), vezi sectiunea de defecte de editare.

## #6, doua defecte de AFISARE pe pagina de articole — REZOLVATE 08.08.2026, dovedite pe ecran

Raportate de Marius dupa testarea pe ecran. Ambele in `frm_modific2024`. Write-back facut, text si
binar sincrone, **necomise**. Diff: diff aplicat (sters). Raport:
`docs\cercetare\rec_fix_grid_tvd_blank.md`.

- **Grid-ul de articole aparea COMPLET GOL** (nici macar coloane), desi `tvd` avea randuri. Cauza:
  `Show()` inchidea si recrea cursorul legat la grid (`IncarcaArticoleFactura` facea `Use In tvd` +
  `Select ... Into Cursor tvd`), iar grid-ul **isi pierde coloanele** (`ColumnCount` ajunge 0) —
  capcana din `COMUN\docs\depanare_testare_vfp.md` sectiunea 6, doar ca declansata din `Show()`, nu
  din `Init()`. **`RecordSource` ramane `"tvd"`** — deci proprietatea nu e indicator de diagnostic.
- **Pageframe-ul disparea cu totul** cand documentul avea articole dar zero rulaje (tipic factura de
  servicii): `Show():14254` colapsa `pgfArticole` prin `afiseaza_rulaje()` (`:12715`) pe conditia
  `trul` + `trul_obinv` goale, fara sa se uite la articole. Conditia tine acum cont si de `tvd`.

**Solutia (Marius, 08.08.2026)**: cursorul se pregateste **inainte de `Createobject`**, ca `tact` si
`trul` — nu dupa ce formularul exista. `Load()` ramane singurul proprietar al structurii: creeaza
mereu `tvd` canonic si, daca apelantul a pregatit `crsArticoleFactura`, il populeaza cu
`APPEND FROM` (potrivire pe nume, deci o divergenta de structura goleste campuri, nu rupe legarea).
`do_editare_factura` pregateste cursorul langa `crsJtvaTemp` si il curata la iesire. Apelul din
`Show()` ramane ca **fallback pazit** (`IF Reccount('tvd') = 0`), pentru cei 4 apelanti care nu
pre-incarca — altfel registrul jurnal, **viu in ROACONT**, ar afisa grid gol.

Doua constatari colaterale, ambele reale:
- campurile din `CreeazaCursorArticoleGol` trebuie marcate **`NULL` explicit**, altfel `APPEND FROM`
  pica cu eroarea 1581 pe primul NULL venit din view;
- **Corectie 09.08.2026**: afirmatia ca `IncarcaArticoleFactura` reumple `tvd` **pe loc**
  (`ZAP` + `APPEND FROM DBF`) **nu corespunde codului de pe disc** — functia face tot
  `Use In (alias)` + `SELECT ... INTO CURSOR (alias) READWRITE` (`ofacturare_editare.prg:303-309`).
  Calea `do_editare_factura` nu e afectata (cursorul vine pre-incarcat prin `crsArticoleFactura` +
  `APPEND FROM` in `Load()`), dar **fallback-ul din `Show()` reinchide cursorul legat la grid** —
  aceeasi capcana ca defectul "grid gol", ramasa deschisa pentru cei 4 apelanti care nu pre-incarca.

**Testat pe ecran, PASS** (harness UI nou: formular vizibil, `PrintWindow`, `ActivePage = 3` din cod,
fara input real): `cod=1140885` (articole, **zero rulaje**) -> pageframe vizibil, grid populat,
`ColumnCount = 14`; `cod=1139934` (cu rulaje) -> grid populat, regresie curata. Regresia
`test_page3_articole.prg` identica cu inainte (FAIL-urile de atunci, pe `cod=1140888`, s-au dovedit
ancorare gresita — datoria 6, rezolvata 09.08.2026).
Capturi: `COMUN\utile\Teste\editare_factura\screenshots_before\` si `screenshots_after\`.
**Atentie**: `vfp_ui_harness.ps1` **goleste `-ShotsDir` la fiecare lansare** — capturile de pastrat se
muta din el, altfel se pierd la urmatoarea rulare.

**FACUT 09.08.2026**: extinderea la **toti cei 5 apelanti** care fac `Createobject([frm_modific2024])`.
`ofacturare_comun.vc2:3792` (`do_editare_factura`) era singurul facut anterior; acum si
`comun.vc2:2435` (registru jurnal, `afisjurcom.do_modifica`), `anaf_efactura.vc2:13084`
(`importmodifica`), `frm_initializare_facturi_balanta.sc2:1803`, `frm_import_note_facturi_clienti.sc2:895`
(ambele `form1.modificanote`) — prin helper-ul unic `PregatesteArticoleFacturaEditare(tcAliasAct)` in
`ofacturare_editare.prg:319-340` (descoperire din `tact` via `IncarcaVanzareDinNota` + precarcare
`crsArticoleFactura` via `IncarcaArticoleFactura`), cu garda `"OFACTURARE_EDITARE" $
Upper(Set("Procedure"))` la fiecare apel. Plus linia din `roagest.prg:260`. Detalii, cifrele
suitelor si care din cei 4 sunt no-op azi (achizitie/note noi fara `cod` legat de `VANZARI`):
`docs\cercetare\rec_s4_apelanti.md`. **Scris in binar, necomis.**

**Prima intrebare deschisa s-a inchis** (decizia 30, 09.08.2026): coloana scade acum
`discount_unitar` si se numeste `valoare`. **Ramane a doua**: valorile **amesteca valutele**
(view-ul intoarce cifre RAW, fara conversie), deci coloana nu e insumabila — conteaza la bara de
totaluri (deciziile 20 si 25).

## #6, doua defecte de EDITARE pe pagina de articole — REZOLVATE 09.08.2026, dovedite pe ecran

Raportate de Marius dupa testarea pe ecran a rundei 3A, in `COMUN\clase\omodificari.vc2`
(`frm_modific2024`) si `COMUN\programe\ofacturare_editare.prg`. Write-back facut (fidelity check
trecut), text si binar sincrone, **necomise**. Diff: diff aplicat (sters).
Backup-uri dinaintea fixului: `COMUN\clase\omodificari.vc2.pre_fix3a.bak`,
`COMUN\programe\ofacturare_editare.prg.pre_valoare.bak`.

- **`cantitate` si `pret` nu se puteau modifica**, desi `Column5/Column6.ReadOnly = .F.` in clasa.
  Cauza: `_grid.Init` (`COMUN\clase\_baza.vc2:240-259`) forteaza `ReadOnly = .T.` pe **fiecare**
  coloana al carei `CurrentControl` e `Text1`, cat timp `lcamptextneeditabil` (implicit **`.T.`**)
  nu e coborat pe instanta. Valorile din designer sunt suprascrise la Init. De asta bifa `pret_cu_tva`
  **mergea** — coloana ei are `CurrentControl = _checkbox1`, deci scapa buclei.
  Fix: `lcamptextneeditabil = .F.` pe `grdArticoleFactura`. `grdRulaje`/`grdRulajeObinv` rezolva
  acelasi lucru altfel — cu `Init` gol (`*Nu sterge`, `:15659`/`:15926`), care taie si
  `_grdrow.Init`, deci si evidentierea liniei curente; varianta pe proprietate o pastreaza.
- **Valoarea pe linie era defazata cu un pas la bifa "pret cu TVA".** `InteractiveChange` se
  declanseaza cand se schimba `Value` **in control**, iar `ControlSource` nu e inca actualizat — deci
  `calculeaza_valori_articol` citea flagul **vechi** din `tvd`. Fix dupa tiparul casei
  (`anaf_efactura.vc2:8089-8113`, care tot din `This.Value` citeste): flagul se scrie intai in
  cursor din `This.Value`, apoi se recalculeaza si se face `Refresh()` pe grid.
- **Coloana `subtotal` s-a redenumit `valoare` si scade acum `discount_unitar`** (Marius,
  09.08.2026). Formula: `cantitate * (pret - discount_unitar)`, inmultit cu `proc_tvav` cand flagul
  e 0 — aceeasi ca in `ofacturare.prg:2222` (`cantitate*(pretctva-discountctva)`). Redenumirea e
  completa, nu doar antetul: campul `tvd.valoare`, coloana `cValoareArt`, `Caption = "Valoare"`.
  Atins in ambele locuri unde se defineste structura `tvd` (`ofacturare_editare.prg:269` si
  `omodificari.vc2:14139`) plus `SELECT`-ul din `IncarcaArticoleFactura`.

**Testat pe ecran, 11/11 PASS** — `COMUN\utile\Teste\editare_factura\test_ui_fix_editabil_subtotal.prg`
sub `vfp_ui_harness.ps1` (formular vizibil off-screen, `PrintWindow`, fara input real), pe
`cod=1139934` / `id_vanzare=882`: `ColumnCount=14`, cantitate si pret editabile, denumire /
discount_unitar / valoare raman readonly, antetul e "Valoare", discountul e scazut deja la
incarcare, iar bifa duce flagul in cursor si valoarea la cifra corecta **din prima** (linia 1:
`cant=1`, `pret=150`, `discount_unitar=15`, `proc_tvav=1.19`, flag `1 -> 0`, valoare
`135 -> 160.65`), cu `lmodificat = .T.` Captura:
`COMUN\utile\Teste\editare_factura\screenshots_fix3a\step_0_pagina3_dupa_bifa.png`.

Regresia headless `test_page3_articole.prg` (actualizata pe noul nume de camp) ruleaza cu exit 0 si
zero dialoguri; fata de rularea de dinainte de fix, **nicio regresie noua**. Esecurile de atunci erau
toate pe `cod=1140888` — ancorare gresita, rezolvata la datoria 6 pe 09.08.2026; azi suita da
**13 PASS / 2 FAIL**, cele 2 fiind strict artefactul headless de la datoria 7.

**Bara de totaluri nu lipseste din greseala — nu e implementata inca**: e sub-blocul **C** al rundei
3 (decizia 20, footer ca pe paginile de rulaje). `PAGE1`/`PAGE2` au `_grdfooter1`, `PAGE3` nu are
niciun obiect in afara gridului. **Amanata explicit** (Marius, 09.08.2026) — se porneste separat, cu
agent proaspat. Coloana **Valoare** exista si se vede pe ecran (ultima din cele 14).

Dovada colaterala pentru corectia de mai sus despre `IncarcaArticoleFactura`: in log-ul suitei,
`workarea tvd dupa Load = 5`, `dupa Show = 20` — deci fallback-ul din `Show()` chiar reinchide si
recreeaza cursorul.

## #6, S4 runda 3 sub-blocul B — stergerea de linii GATA, adaugarea predata mai departe, 09.08.2026

Detalii complete: `docs\cercetare\rec_s4_runda3b.md` (implementare + testare) si
handoff intermediar (sters) (cercetarea de contract pentru partea neinceputa).

- **Stergere logica** — buton nou `cmdStergeArticol` pe `pgfArticole.PAGE3`
  (`omodificari.vc2:12260-12274`), `Click` comuta `tvd.sters` intre 0/1 si seteaza
  `lmodificat=.T.` (`omodificari.vc2:15962-15970`). **Fara stergere fizica din cursor** —
  randul ramane, marcat, ca S5 sa scrie `STERS=1` pe linie. Marcaj vizual:
  `DynamicForeColor` pe toate cele 14 coloane (`IIF(tvd.sters=1,RGB(150,150,150),RGB(0,0,0))`),
  tipar deja folosit in clasa. Campul `tvd.sters` **exista deja** din runda 1/B.1 (vine din
  `VVANZARI_ARTICOLE`), nu a fost nevoie sa se atinga structura cursorului.
- **Adaugarea de linii (dialog `frm_articol_factura`) NU e facuta.** Cercetare completa de
  contract predata (nu se reia): `poDate` are nevoie doar de 3 proprietati citite in tot
  dialogul (`tip`, `in_valuta`, `dataact`) — nu clasa completa `oDateFactura`;
  `gnScadereStoc` trebuie setat manual `=0` inainte de `Createobject` (nu exista global la
  editare post-emitere, altfel `Init`-ul dialogului da eroare "Variable not found");
  `calculeaza_totaluri()` + `do_initializeaza_articol()` (functii/metode deja existente)
  deriva majoritatea proprietatilor `poArticol` din `pret`/`preturi_cu_tva`/`proc_tvav` —
  nu se reinventeaza formulele. **Ramane necunoscut**: de unde se alege articolul la
  adaugare (dialogul nu are picker; `crsarticole`-ul de la compunere e legat de stoc, exclus
  de decizia 15) — de investigat la implementare, posibil in `onom_articole.vc2` sau in
  tiparul din modulul de achizitie.
- **Capcana de encoding lovita si reparata in aceeasi sesiune**: primul `Edit` pe fisier a
  re-encodat tot fisierul si a stricat din nou cele doua linii `Caption` cu diacritice
  (`Renunțare`/`Adăugare`/`Ștergere`) reparate anterior — cens `2 aa/2 e3/2 fe` -> `6 ef/6 bf/6 bd`.
  Reparat byte-cu-byte cu Perl inainte de write-back; cens final identic cu cel de plecare,
  zero `EF BF BD`, verificat de doua ori.
- **Fidelity-check picat prima data** (ordine `ADD OBJECT`/metoda, capcana cunoscuta) —
  rezolvat prin adoptarea textului regenerat din `<staging>\verify\` ca sursa. A doua rulare
  `txt2vcx.ps1 -AllowComun`: OK.
- **Testat**: regresie headless neschimbata (`test_page3_articole.prg` 14/2,
  `test_incarca_vanzare_din_nota.prg` 5/5, exit 0, zero dialoguri). Test UI nou
  (`test_ui_sterge_linie.prg`, pe `cod=1139934`/`id_vanzare=882`): **6 PASS / 0 FAIL** in log —
  **nu** 7/7 cum s-a raportat initial. Logul are 8 linii, se opreste la `READY` (handshake-ul de
  captura) si n-are linia de `REZULTAT`, deci rularea a fost **taiata**: asertia de **comutare
  inapoi** (`sters` 1 -> 0 la al doilea click) era programata dupa handshake si **n-a rulat**.
  Verificat de orchestrator prin numararea asertiilor din log. **Captura de ecran nu s-a putut
  obtine** — `vfp_ui_harness.ps1` in mod `-A` (formular vizibil) a esuat sistematic de 16 ori
  (2 rulari x 8 incercari) sa detecteze pornirea VFP in 30s, desi procesul a rulat testul
  COMPLET pana la capat de ambele ori (dovedit prin logul propriu al testului, ajuns pana la
  `HarnessStep`/`READY`); modul headless (`-A -T`) a raspuns instant in acelasi interval —
  problema pare de mediu/masina ocupata (enumerare read-only de ferestre a aratat desktopul
  activ al lui Marius: RustDesk, VS Code, PL/SQL Developer, Explorer), nu de cod. Recomandare:
  o trecere de confirmare vizuala cand masina e libera, inainte de commit — nu blocheaza
  livrarea.
- Diff: diff aplicat (sters) (162 linii, scopat strict pe aceasta lucrare —
  reconstruit dintr-un backup `.pre_runda3b.bak` obtinut prin reversul exact al editarilor,
  pentru ca nu s-a luat backup INAINTE de prima editare).

## #6, defecte rezolvate in `ofacturare_comun.vc2` (frm_facturi / frm_modific2024) — 08.08.2026

Trei defecte raportate, toate in `COMUN\clase\ofacturare_comun.vc2`. Write-back facut, confirmat
**in binar** (`svn status` din interiorul `COMUN\`: `M clase\ofacturare_comun.vcx` + `.vct`).
Necomis.

- **`crsJtvaTemp` neinitializat.** `frm_facturi.do_editare_factura` nu crea cursorul inainte de
  `Createobject(frm_modific2024)`, iar `frm_modific2024` evalueaza la construirea gridului
  `Column63.ControlSource = "Iif(Seek(...,'crsJtvaTemp','id_jtva'),...)"` (`COMUN\clase\omodificari.vc2:9202`)
  si un `RowSource` pe acelasi cursor (`:9604`). Fix: `update_jtva_coloane("", "crsJtvaTemp", 0)` la
  `ofacturare_comun.vc2:3789`, inainte de `Createobject`, plus cleanup la `:3851-3853`. Tiparul
  `N=0` e cel din `COMUN\programe\ooperatii_comune.prg:113`, adica exact calea ROACONT care functiona.
  Test nou de reproducere: `COMUN\utile\Teste\editare_factura\test_defect1_crsjtvatemp.prg` — fara
  fix reproduce eroarea si dialogul nativ, cu fix **PASS** (`PageCount=3`, `nIdVanzare=882` pe
  `cod=1139934`, 0 dialoguri, exit 0).
- **Doua butoane de modificare.** `But_editare1` sters (`ADD OBJECT` + `OBJECTDATA` + referinta din
  `cbuton3`), `but_modifica1` pastrat neschimbat. Dispecer nou `PROCEDURE inainte_de_do_modifica` cu
  `xmenu()` + `DO CASE` -> `do_modifica()` / `do_editare_factura()`, dupa sablonul
  `COMUN\clase\comun.vc2:2625` si `:2749`. Garzile raman in metode, nu in dispecer. **Verificat doar
  structural** (fidelity-check): `xmenu` cere input real, iar `frm_facturi` nu se instantiaza
  headless (cade pe `Variable TEXT_ADITIONAL is not found` — cere `crsfacturi` populat printr-o
  cautare reala). Clickul ramane de verificat manual dupa rebuild.
- **12 diacritice distruse** — regresie de encoding; cauza si corectarea, in sectiunea urmatoare.

## Encoding: regresie gasita si corectata in `ofacturare_comun.vc2`, conventia documentata corectata — 08.08.2026

Commit-ul `13b4f65` (SVN r18004/r18007) a inlocuit **12 diacritice** din `ofacturare_comun.vc2` cu
**U+FFFD** (`EF BF BD`), vizibile pe ecran ca `ďż˝`: `Marchează`, `Modifică explicaţie articol`,
`Explicaţie`, `Data şi ora expedierii`, `Maşina`, `Şterse`, `Neşterse`, `În RON`, `În valuta`,
`Total în valuta` (ultimul de doua ori). Restaurate byte-exact din `8df728c`; censul de octeti >0x7F
e acum identic cu referinta (`1 aa / 3 ba / 2 ce / 2 e3 / 2 ee / 2 fe`), zero `ef`/`bf`/`bd`,
confirmat si in binarul `.VCT`.

Cauza: fisierele `.vc2`/`.sc2` au diacriticele in octeti **cp1250**, desi antetul FoxBin2Prg declara
`CPID="1252"` si controalele au `FontCharSet=238`. Regula scrisa in documentatie cerea cp1252 si,
urmata literal, pierde tacit diacriticele — fara eroare si fara sa cada fidelity-check-ul. Doua
capcane de detectie de consemnat, ambele contraintuitive:
- censul de octeti >0x7F **creste** la stricare, nu scade (un octet cp1250 devine trei octeti de
  U+FFFD);
- semnatura e `EF BF BD`; un scan care testeaza doar mojibake `C3`/`C4`/`C5`/`C8` o rateaza complet.

Corectate trei documente in `COMUN\docs\` (**cross-project, necomise**): `reguli_lucru.md`
(punctele 5 si 7), `flux-editare-vfp-text.md` (pasul 2), `conventie_encoding_cp1252.md` (cadrul
explicativ, tabelul de octeti, detectia, repararea) — fisierul nu e redenumit, e lincat din 4 locuri.
Verificarea documentata acolo era **neoperationala**: un codepage single-byte mapeaza fiecare octet
la un caracter, deci nu produce niciodata U+FFFD (`Select-String ([char]0xFFFD)` nu gasea nimic nici
pe fisierul stricat); inlocuita cu scanare pe octeti a secventei `EF BF BD`.

Sweep complet de encoding peste toate fisierele urmarite de git din ambele arbori (75 in
ROAFACTURARE, 631 in COMUN): in afara de `ofacturare_comun.vc2`, **nicio alta regresie**. Raport:
`docs\raport_sweep_encoding.md`. Patru semnale false pozitive, toate prezente din primul commit:
`ferestre_seturi_indicatori.vc2` (UTF-8 legitim, tag XML ANAF), `oproceduri_comune.prg` (literal
`"Ă"` intentionat, functie de normalizare), `utile\Menu\menutool.vc2` (comentarii chineza GBK, cod
tert), `utile\excel\ExcelXML.prg` (52x U+FFFD in comentarii portugheze, biblioteca terta, dinaintea
ferestrei git — lasat neatins intentionat). Zero BOM.

**CONCLUZIA SWEEP-ULUI NU SE SUSTINE — infirmata pe date 08.08.2026.** Versiunea **comisa** a lui
`COMUN\clase\omodificari.vc2` (git `HEAD`) are **BOM UTF-8** pe prima linie **si 6 diacritice
distruse** (`EF BF BD`), pe doua linii identice: `"CTRL+F = Terminare; ESC = Renunţare; CTRL+N =
Adăugare; CTRL+D = Ştergere"` (`:4104` si `:8641`). Deci nici "nicio alta regresie", nici "Zero BOM"
nu sunt adevarate pentru acest fisier. Copia de lucru le are **corecte** (cens: 6 octeti >0x7F,
`aa`/`e3`/`fe` cate 2, zero `EF BF BD`) — reparate local, **necomis**. Explicatia probabila a ratarii:
sweep-ul a scanat arborele de lucru, deja reparat, nu `HEAD`. **De reluat sweep-ul pe `HEAD`**, nu pe
disc, inainte sa se mai foloseasca cifra lui ca garantie.

Scaderea censului 26 -> 12 pe `COMUN\clase\ointroduceri.vc2` la commit-ul `75d8ded` **nu e o
stricare**: e stergerea clasei legacy `import_nir`, verificat pe obiect — niciunul din cele 10
string-uri nu mai are container in HEAD, nimic de restaurat acolo. Separat: echivalentele vii din
`import_nota` (`Adauga repere`, `Recalculeaza`, `Valuta`, `TVA valuta`) sunt ASCII **din primul
commit**, deci inconsecventa veche, nu regresie — o eventuala punere de diacritice acolo e o
corectie de continut, neaprobata.

## Starea versionarii — comis pana la r18004/r18007, cu modificari NECOMISE peste (vezi subsectiunea)

| Arbore | SVN | git (`gitea.romfast.ro`, remote `origin`) |
|---|---|---|
| `DATABASE\SCRIPTURI_CLAR` | r18003 | — (nu are oglinda git) |
| `COMUN` | r18004, r18007 | `romfast/comun.git` `13b4f65` |
| `ROAFACTURARE` | r18005 | `romfast/roafacturare.git` `0f98127` |
| `ROACONT` | r18006 | `romfast/roacont.git` `3af0089` |

`git_sync.ps1` a fost rulat inainte de commit-urile git (462 fisiere la zi, zero esecuri).
**Nota**: pentru repo-urile ROA, `origin` **este** remote-ul romfast — interdictia de a impinge pe
`origin` priveste doar repo-ul `foxbin2prg`, unde `origin` e upstream-ul public de pe GitHub.

`docs\` ramane **neversionat**, ca pana acum (patch-uri, handoff-uri, planuri de runda — scaffolding
local). Singurul fisier de stare durabil e chiar acesta, `progres.md`. Curatenia dinainte de commit
s-a facut cu `COMUN\utile\curatenie.ps1` (47 de intrari: patch-uri, handoff-uri, `*.pre_runda*.bak`,
`.FXP`, loguri de test). `.gitignore` din `COMUN` ignora acum si `watchdog_out/` si capturile
`*_dialog*.png` ramase din rulari.

### Dupa acest commit: defectele si encoding-ul de mai sus, NECOMISE

`COMUN` are azi, in plus fata de tabelul de sus, modificari inca necomise: `git status` arata `M` pe
`clase/ofacturare_comun.vc2`, `clase/omodificari.vc2`, `programe/ofacturare_editare.prg`,
`utile/Teste/editare_factura/test_page3_articole.prg`, plus cele 3 fisiere `.md` din `docs\`
(encoding). `svn status` arata in plus binarele `clase\ofacturare_comun.vcx`/`.vct` si
`clase\omodificari.vcx`/`.VCT` ca `M`. Arborele ROAFACTURARE principal e curat. Diff-urile de review:
diff aplicat (sters), diff aplicat (sters),
`docs\raport_sweep_encoding.md`, diff aplicat (sters),
diff aplicat (sters).

### Copiile de `COMUN` din ROACONT si ROAGEST: aduse la r18010 (08.08.2026)

Erau la r17987 si r17977, deci **fara `ofacturare_editare.prg`** (intrat la r18004), desi
`roacont.prg:212` il referea deja — ROACONT pornit din copia de lucru cadea pe `SET PROCEDURE` catre
un fisier inexistent. `svn update` rulat pe ambele, cu aprobarea lui Marius. ROACONT: curat.
**ROAGEST: 2 conflicte de arbore RAMASE NEREZOLVATE**, ambele „local file unversioned, incoming file
add" — `utile\citeste_email.ps1` si `docs\email-thunderbird.md`. Fisierele sunt pe disc, nimic
pierdut; cer `svn resolve`, decizia e a lui Marius. Au ramas modificate local doar
`docs\PACK_DIAG_SPATIU.pck` si `utile\context_watch.ps1`.
**Rebuild ROACONT ramane la Marius** — abia dupa el PAGE3 apare efectiv in registrul jurnal acolo.

## #6, S4 runda 2 — ce contine, pe scurt

Starea completa, inventarul si ce ramane: **handoff intermediar (sters)**. Pe scurt: view-ul
`VVANZARI_ARTICOLE` consumat cu `select *`, pozitionarea pe triplete (decizia 27), garda pentru ROACONT/ROAGEST,
`AMESSAGEBOX` pe erorile Oracle, structura unica pentru cursorul `tvd`. Validata pe starea curenta,
dupa redenumirea view-ului si taierea comentariilor: fidelity check trecut, suita **10/10** si
**5/5** la data validarii (cifrele nu mai sunt valabile azi — vezi datoria 6), exit 0, zero
dialoguri. Diff: diff aplicat (sters).

`vvanzari_detalii` / `vvanzari_detalii_tot` **nu se extind** — motivele pe date, in handoff: 11 coloane
lipsa, cost de 3.7x fata de `VVANZARI_ARTICOLE`, si `select * from vvanzari_detalii_tot` in `oproceduri_listari.prg`
din ~10 produse.

## Datorii deschise, in ordinea importantei

1. **Parolele Oracle sunt expuse in istoricul SVN.** `COMUN\docs\local` a iesit de sub versionare la
   r17995, dar stergerea afecteaza doar HEAD — orice revizie anterioara le contine in clar
   (`svn cat -r 17967`). Singura remediere reala e **schimbarea parolelor**: `MARIUSM_AUTO`,
   `contafin_oracle` (aceeasi parola pe toate serverele de client), `SYS` (parola generica pe toate
   instantele). Curatarea istoricului ar cere `svnadmin dump`/`load` filtrat — decizie de
   administrator. Acelasi tipar de verificat in `D:\GoogleDrive\vending.tlp` si in orice
   `settings.ini` de `tasks.exe` referit din `COMUN\utile\publicare_scripturi.ps1`.
2. **Build ROAAUTO, la Marius**: rebuild din IDE + test UI pe un deviz real — fara el corectia S7 din
   #8 n-are efect. Partea ROAFACTURARE e inchisa (build + deploy 2.11.14, 08.08.2026).
   **Agentul nu atinge `.PJX`/`.PJT`/`.exe`.**
3. **Changelog ROAAUTO** — textul propus e in `COMUN\docs\cercetare\rec_s10_s12.md`, neaplicat in
   `changelog_roaauto.txt`.
4. **Curatarea tabelei `VERSIUNE`** de numele vechi de scripturi (`_02`..`_06`), cu inregistrari
   multiple din aplicarile succesive. `COMUN\docs\cercetare\s10_curata_versiune.sql`, de extins cu numele
   vechi. Fara impact functional, doar istoric zgomotos.
5. **Puncte nedecise de la #8, niciunul blocant**:
   - `tip=1` cu `id_comanda` — 16 facturi pe productie care n-ar trebui sa aiba;
   - `ALTELE` are aceeasi concatenare nepazita ca `CONTRACT` inainte de garda, deci `tip=46` ar
     afisa un `/` singur. Zero documente azi in ambele scheme;
   - cele 620 de randuri cu `ID_VALUTA` NULL — normalizarea la `0`/`1`;
   - **propagarea corectiei `xmlefactura.prg`** in cele ~16 cai ramase din alte produse ROA.
     Inventarul: `COMUN\docs\cercetare\rec_consumatori_vanzari.md`. Grup A (byte-identice, acelasi patch):
     ROAACNPRO, ROAAUTO, ROACONT, ROACONTRACTE, ROADEF, ROAGEST, ROAIMOB, ROAREGISTRATURA, ROARES,
     ROASTART. Grup B (fisier divergent, acelasi tipar la alta linie): OUTPUT/ROACONT `:350`,
     ROACONIMPORT / ROAEFACTURA / ROAPRINT / ROASITFIN `:356`, ROAPRODUCTIE `:326`. Grup C (fara
     bloc, fara risc): ROADECL, ROAMANAGER, ROAPRETURI, ROASAL.
6. **REZOLVATA 09.08.2026 — nu se pierduse nimic, ancorarea era gresita.** `ID_VANZARE = 1050`
   exista si azi, activ, cu totaluri neschimbate: i s-a **realocat `COD`-ul**, 1140888 -> **1140895**,
   pe 08.08.2026 la 14:05 (semnatura `finalizeaza_modificare_nota` + `actualizeaza_vanzari` — 24 randuri
   `ACT` vechi `STERS=1`, 24 noi active, acelasi `nract`/`serie_act`/`dataact`/`id_fact`, aceeasi suma).
   **Nu** testul de write-back aprobat: acela a lucrat pe `id_vanzare=1048` la 09:16. Suitele cadeau
   pentru ca `IncarcaCursoareModificareNota` filtreaza `STERS = 0`, deci `tact` venea gol.
   **Remediu structural**: suitele nu mai hardcodeaza documente, si-l **descopera singure dupa
   proprietatea ceruta de asertie** — `COMUN\utile\Teste\editare_factura\descopera_caz_test.prg`,
   6 cazuri (`FACTURA_ARTICOLE`, `NEFACTURA_ARTICOLE`, `FARA_RULAJE`, `PRIM_RAND_ORB`,
   `COLIZIUNE_COD`, `NOTA_FARA_VANZARI`). Descoperirea merge pe **alt drum** decat codul testat (join
   direct pe `VACT_TOT`/`VRUL_TOT`/`VANZARI`), deci asertia nu devine tautologica; ordonare
   determinista; **niciun caz gasit = FAIL explicit**, nu test sarit. Cifre: `test_page3_articole.prg`
   **13 PASS / 2 FAIL**, `test_incarca_vanzare_din_nota.prg` **5/5**, exit 0, zero dialoguri.
   Cele 2 FAIL sunt artefactul headless de la datoria 7 (eroare 1925 `Unknown member COLUMN5`),
   acoperite pe ecran de `test_ui_fix_editabil_subtotal.prg` (11/11). O asertie s-a **intarit**
   (cazul B verifica acum numarul real de linii, nu `-1`), niciuna nu s-a slabit. Cifra veche
   `7 PASS / 3 FAIL` din acest fisier era stale — numara doar cele 10 asertii de la runda 2.
   Raport: `docs\cercetare\rec_datoria6_baza_regresie.md`. Diff: diff aplicat (sters).
   **Necomis.** Neprobat pe alta schema decat `MARIUSM_AUTO`.
7. **REZOLVATA 08.08.2026 — se verifica pe ecran, cu formular vizibil.** Harness nou:
   `COMUN\utile\Teste\editare_factura\vfp_ui_harness.ps1` (formular vizibil off-screen, `PrintWindow`,
   `ActivePage` setat din cod, fara input real). Sub el, `ColumnCount` se citeste corect (`14`), iar
   captura arata randarea reala. **Consecinta pentru diagnostic**: sub `-A -T`, `ColumnCount = 0` si
   `RecordSource = "tvd"` sunt amandoua **artefacte**, nu dovezi — un grid nematerializat nu s-a legat
   niciodata, deci proprietatile lui nu spun nimic despre legatura. O ipoteza despre bind **nu se
   falsifica headless**. Textul vechi al datoriei, pastrat mai jos ca istoric.
   Sub `vfp9.exe -A -T`
   (`watchdog_vfp.ps1`), un grid instantiat raporteaza `ColumnCount = 0`, `Columns is not an object`
   si `Unknown member ColumnN`, chiar cand clasa are coloanele definite complet — coloanele par sa se
   construiasca la randarea reala, pe care harnessul nu o declanseaza; `ActivePage` forțat nu ajuta.
   Stabilit pe `frm_modific2024.pgfArticole.PAGE3.grdArticoleFactura`: valoarea `0` apare **identic pe
   binarul comis (r18004) si pe cel dupa write-back-ul rundei 3A**, deci nu e regresie si nu e defect
   de aplicatie. `Objcode = 0` pe grid e o pista falsa — era gol si in starea comisa, iar
   `_grdfooter1` are tot `0` si functioneaza. Din acest motiv cad doua din cele patru asertii de runda
   3A (`ColumnCount=14`, `ReadOnly`/checkbox); celelalte doua, pe cursor si pe calcul, trec.
   De rescris ca verificare **statica** pe memo-ul `Properties` din `.vcx` (conține `ColumnCount`,
   `ColumnN.Name`, `ColumnN.ControlSource`, `ColumnN.ReadOnly`, `ColumnN.Sparse`), care se poate parsa
   direct, fara VFP si fara IDE: `.vcx` e DBF cu `OBJNAME`/`PARENT`/`PROPERTIES`/`OBJCODE` ca cimpuri
   **memo** (4 octeti = numar de bloc in `.vct`; blocul are 8 octeti de antet, lungimea pe octetii 4-7
   big-endian). Structura rundei 3A a fost deja validata asa: `ColumnCount = 14`,
   `Column7.Name = "cPretCuTvaArt"` cu `Sparse = .F.`, `Column14.ControlSource = "tvd.subtotal"`,
   `Column14.Name = "cSubtotalArt"`. Randarea si interactiunea rămân de verificat pe ecran.

## Decizii luate de Marius

1. **Ordine**: strict pe risc, cu #12/#11/#10 amanate.
2. **DDL**: sursa de referinta e schema de dezvoltare **`MARIUSM_AUTO`** pe `ROA_CENTRAL`, niciodata
   o schema de client — si numai dupa ce se verifica prin tabela `VERSIUNE` ca are toate scripturile
   aplicate. Notata in `COMUN\docs\scripturi-migrare-db.md`.
3. **`frm_facturare_articole2` NU se atinge** — e cod mort (apelat doar sub `gnFacturareNou = 1`,
   variabila fara nicio atribuire in proiect) si face obiectul punctului 13 din `todos.txt`
   (formular unificat). Orice modificare VFP din #7 si #8 se face **doar** in
   `frm_facturare_articole`.
4. **#8, scop extins**: intra si denormalizarea comenzii si a contractului; **ambele view-uri raman
   in paralel** (`fact_vfacturi` nu se retrage).
5. **#6**: NU regenerare prin re-emitere. Editare directa in `frm_modific2024`, extins cu
   `vanzari`/`vanzari_detalii` pe o pagina noua, similara paginilor de rulaje. Editarea trebuie sa
   fie posibila **si din ROACONT > registru jurnal > modificare**. Sincronizarea preturilor
   rulaje <-> articole se face **cu verificare si propunere explicita, niciodata silentios**.
6. **Acces baza**: tunel spre `VENDING` permis, **strict citiri**. Dezvoltarea si testele pe
   `MARIUSM_AUTO`. Tunelul e azi inchis.
7. **#8 / S8, `CLIENT` pe retur-transfer** (`tip=41`, `tip=-6`, 23 facturi): se aliniaza
   `fact_vfacturi` pe `fact_vfacturi2`, adica pe `VANZARI.ID_GESTIUNE`. Se accepta ca numele
   clientului afisat se schimba pe cele 23 de documente.
8. **#8 / S8, `EXPLICATIE`** (75 facturi): se aliniaza pe varianta din `fact_vfacturi2`, cea
   confirmata de constantele VFP curente.
9. **#8 / S9, cele 41 de facturi** cu totaluri denormalizate si zero linii active in
   `VANZARI_DETALII`: ramane instantaneul de la emitere. Backfill-ul **nu le atinge**; divergenta e
   prin design.
10. **#8, cursul valutar pe facturi in lei**: rezolvat in #8, in acelasi script de migrare cu S4, ca
    pachetul sa se recompileze o singura data.
11. **#8 / S6, `ALTELE`**: lista devine `tip in (3, 21, 27, 28, 42, 46, 47)` — `47` adaugat, `46`
    pastrat explicit, desi nota de plata restaurant n-are comanda.
12. **#7, editarea pe factura in curs de compunere**: prin **buton deasupra gridului + dublu-clic**,
    ambele redeschizand dialogul. Respinsa bifa editabila direct in grid (ar fi cerut o a doua cale
    de calcul). Motivatia butonului: *"altfel utilizatorul nu stie ca se poate modifica"*.
13. **#7, editarea pe factura deja salvata trece in #6** — schimbarea flagului reimparte baza si
    TVA-ul, deci muta totalurile denormalizate din `VANZARI` si notele contabile.
14. **#7, articole gestionabile**: la modificare **se redeschide dialogul cu gestiuni**. Respinse
    varianta mica (dialog simplu, cantitatea doar in jos) si cea cu plafonul total pastrat.
15. **#6, scopul editarii pe linii — COMPLET** (08.08.2026): stergere, adaugare si modificare de
    linii (articol, cantitate, pret, `pret_cu_tva`). **Fara plafon de cantitate si fara verificare
    de stoc** — raspunderea e a utilizatorului care corecteaza. In schimb, formularul ii ofera
    **helpere**: calcule de totaluri, propuneri de sincronizare acolo unde se poate, si
    **verificari de corelatie cu notele contabile (`ACT`) si rulajele (`RUL`)**. Asta inchide
    intrebarea lasata de #7 despre sursa plafonului la factura salvata: nu mai e nevoie de plafon.
16. **#6, drepturi**: editarea sumelor intra **sub tokenul "3" existent** (modificare). Fara token
    nou, fara rand nou in tabelele de drepturi.
17. **#6, discountul de document** (`VANZARI.DISCOUNT`): **editabil**, intra in S4 si in recalculul
    din S5.
18. **#6, liniile din seturi**: se trateaza **ca orice alta linie**, fara ramura speciala si fara
    blocarea facturilor care le contin. De urmarit la S5: agregarea din `scrie_in_vanzari` are o
    ramura proprie pe `VANZARI_SETURI_TEMP`, deci recalculul trebuie sa acopere si liniile de set,
    altfel totalurile diverg tacut pe facturile cu seturi.
19. **#6, domeniul paginii noi (PAGE3)**: apare pe **orice rand din `VANZARI`**, nu doar pe facturi —
    deci si pe avize. Respinsa varianta "strict facturi".
20. **#6, UX-ul totalurilor de control**: **bara de totaluri sub grid**, in acelasi loc si stil cu
    footerul de sume de pe paginile de rulaje. Informatia de control se vede permanent, nu dupa
    click. Respinse varianta cu indicator pe titlul paginii si cea cu fundal colorat.
21. **#6, directia sincronizarii**: **o singura alegere globala pe document**, nu per linie.
22. **#6, transfer si custodie**: pagina de articole **apare**, dar **fara bara de totaluri** —
    pe transfer intre subunitati (23, 25, 30, 41), transfer pe lucrare (27) si custodie (42, 47) nu
    exista suma comparabila, deci nu se afiseaza nici bara, nici vreun verdict. Respinsa varianta cu
    bara goala si mesaj "nu se aplica".
23. **#6, tipul 51 (ROAACNPRO)**: contul e **`4111`**, spus de Marius pe 08.08.2026. Deci `411`
    gasit de cercetare si divergenta de pe `cod=1138989` **au alta cauza** — prima suspiciune e chiar
    filtrarea pe `cod` fara `an`+`luna`, capcana demonstrata pe `cod=1140632`.
24. **#6, garda pe `id_set`**: **se scoate de tot**. Premisa ei (randuri de discount cu `id_set + 5`
    in `ACT`) s-a dovedit falsa — offsetul e tranzitoriu. Nota unei facturi are un singur `id_set`.
    Atentie la implementare: randurile de discount raman cu `ID_FACT = -1` si `ID_FACTD` NULL, deci
    pozitionarea din care se citesc `id_fact`/`id_factd` **nu** are voie sa cada pe ele.
25. **#6, documente mixte** (linii stocate + servicii): suma din `RUL` se **corecteaza cu valoarea
    liniilor nestocate** luata din `VANZARI_DETALII`, ca cifra afisata sa fie comparabila; se
    marcheaza in bara ca e ajustata. Liniile nestocate nu au deloc rand `RUL`.
26. **#6 / S4, ancorarea coloanelor: view Oracle dedicat** (Marius, 08.08.2026 — *"poti sa faci un
    View in baza de date"*). Deblocheaza varianta B din `rec_review_ancorare_s4.md`, respinsa atunci
    doar pentru ca insemna migrare de schema. VFP consuma view-ul cu **`select *`**, ca la
    `vact_tot`/`vrul_tot` — codul nu mai enumera coloane. Respinse: gridul dinamic din `AFIELDS()`
    (unicat pe formular) si `SELECT *` pe join brut (mutase eroarea din SQL in binding-ul gridului).
27. **#6 / S4, pozitionarea in `tact` pentru PAGE3**: **fara euristica pe text**. Nu se alege niciun
    rand — se incearca **toate tripletele distincte `(cod, nract, serie_act, dataact)`** din `tact`
    pana la prima potrivire in `VANZARI`; randul de incasare se elimina singur pentru ca nu se
    potriveste. Masurat pe toate cele **419 note** legate de `VANZARI`: 400 potriviri exacte,
    **0 gresite, 0 ambigue**, maxim **2** triplete per nota (medie 1.17). Respinsa varianta
    `!("INCASARE" $ Upper(explicatia))` desi iesea si ea 62/62 pe multimea de risc: se sprijina pe
    text liber in romana, iar `ACT` **n-are marcaj de origine a randului** si utilizatorul poate
    adauga randuri manual cu ce explicatie vrea. Respinsa si ancorarea pe `FDOC` — e camp la nivel de
    nota, lipseste pe 40 din 62 (`ABONAMENT`/`BON FISCAL`).
28. **Numele view-urilor noi pastreaza prefixul familiei** (Marius, 08.08.2026): view-ul de articole
    s-a redenumit `VVD_TOT` -> **`VVANZARI_ARTICOLE`**, ca sa stea langa `VVANZARI_TOT` /
    `VVANZARI_DETALII` / `VVANZARI_DETALII_TOT` la o listare **alfabetica** — asa se uita Marius la
    ele si asa vede din prefix ca tine de vanzari. Conventia surorilor de pe formular
    (`vact_tot`/`vrul_tot`) cedeaza in fata prefixului de familie.
29. **Comentarii strict necesare, si in scripturi, si in cod** (Marius, 08.08.2026): fara referinte
    la planuri, stories, propuneri, decizii sau erori, fara trimiteri la rapoartele din `docs/`, fara
    justificarea alegerilor. Notat in `COMUN\docs\reguli_lucru.md` punctul 2 (extins explicit la
    `.sql`) si in `COMUN\docs\scripturi-migrare-db.md`, sectiunea "Continutul unui script".
    **Conflictul cu `CLAUDE.md` e inchis** (Marius, 08.08.2026): marcajul `*!* DD.MM.YYYY` + autor
    sta **in antetul fisierului**, niciodata inline; in cod raman doar comentarii scurte,
    functionale, si numai unde chiar explica o ramura sau un filtru, ca sa se inteleaga codul.
    `CLAUDE.md` a fost aliniat (sectiunea noua "Comments", care trimite la `reguli_lucru.md`).

30. **#6 / S4, coloana de valoare pe linie** (Marius, 09.08.2026): scade `discount_unitar` si se
    numeste **`valoare`**, nu `subtotal` — atat antetul, cat si campul din `tvd` si coloana din grid.
    Formula ramane ramificata pe `pret_cu_tva`, ca in `ofacturare.prg:2222`.
31. **#6 / S4, bara de totaluri (sub-blocul C) se amana** (Marius, 09.08.2026): nu intra in
    continuarea fixurilor de editare, se porneste ca runda separata, cu agent proaspat.
32. **Regenerarea din `todos.txt` punctul 13 NU schimba #6** (Marius, 09.08.2026). Pe 09.08.2026 a
    aparut in `COMUN\docs\todos.txt`, la punctul 13, cererea de "editare factura/aviz in toate
    variantele **prin regenerare**" — formularul repopulat ca inainte de salvare, cu documentul
    initial marcat `sters = 1` si salvarea unuia nou. Formularea seamana cu varianta respinsa de
    **decizia 5**, dar tine de **punctul 13** (formularul unificat `frm_facturare_articole2`), adica
    alt proiect si alta perioada. **Decizia 5 ramane in picioare**: #6 face editare directa in
    `frm_modific2024`. De reluat cand se ajunge la punctul 13; a nu se confunda cu ipoteza exclusa.
33. **#6 / S4 sub-blocul C, valutele in bara de totaluri** (Marius, 09.08.2026): liniile se
    **convertesc in RON la cursul documentului** (`VANZARI.CURS` + multiplicator) si se aduna intr-o
    **singura cifra**, ca verdictul de corelatie cu `ACT`/`RUL` sa ramana o comparatie simpla. Asta
    inchide a doua intrebare deschisa lasata de runda 3A (view-ul `VVANZARI_ARTICOLE` intoarce cifre
    **RAW**, neconvertite — conversia se face deci in VFP, la afisare, nu in view). Respinse: total
    doar pe valuta documentului cu semnalarea liniilor straine, si cate un total per valuta.
34. **#6 / S4 sub-blocul B, alegerea articolului la adaugare** (Marius, 09.08.2026): **selector nou,
    simplu, direct pe nomenclatorul de articole** (cautare dupa cod/denumire), **fara** nicio legatura
    cu stocul sau cu politicile de preturi — coerent cu decizia 15 (fara plafon, fara verificare de
    stoc). Respinse: reutilizarea selectorului din formularul de compunere (prea legat de cursorul de
    stoc) si linia goala completata manual (n-ar lega linia de nomenclator).
    **Implementat altfel decat "nou", si acceptat**: agentul a gasit `caut_articol()`
    (`COMUN\programe\ocautare.prg:1636`), functie globala deja existenta si inregistrata app-wide, care
    cauta pe `vnom_articole` dupa cod/denumire, fara stoc si fara politici de pret — adica exact
    descrierea deciziei, fara cod nou. Nu s-a scris niciun selector nou.
35. **#6 / S4, intrarea directa in valuta in `frm_articol_factura`: SE FACE** (Marius, 09.08.2026).
    Azi dialogul lucreaza **in RON** chiar si pe un document in valuta — utilizatorul introduce pretul
    in RON, iar `AdaugaLinieTvdDinArticol` il converteste la stocare (`* multiplicator / curs`). Corect
    matematic si suficient pentru bara de totaluri, dar contraintuitiv pentru utilizator. Se trece pe
    intrare directa in valuta, ceea ce cere **atins `COMUN\clase\ofacturare.vc2`** (`frm_articol_factura`)
    — fisier care n-a apartinut niciunui agent pana acum, de unde si amanarea. De stiut la implementare:
    `poDate.in_valuta = 1` cere in plus `zi_curs` si `id_valuta`, validate intern de dialog, iar calea
    **nu e testabila headless** (dialogul e modal, `Show(1)`) — verificarea trece prin
    `vfp_ui_harness.ps1`, cu `-SyncDir` explicit.
    **CORECTIE DE PREMISA, 09.08.2026** (handoff intermediar (sters), verificat si de
    orchestrator pe cod): **`frm_articol_factura` nu citeste deloc `poDate.in_valuta` / `zi_curs` /
    `id_valuta`** — singurele aparitii din intervalul clasei sunt **comentate** (`ofacturare.vc2:2088`,
    `:2136`, ramura scoasa la v2.0.56). Ramura de valuta a dialogului e condusa integral de
    **`poArticol.tip_valuta` / `Curs` / `multiplicator` / `nume_val`** (cod viu: `:1857`, `:1887`,
    `:1917`, `:1932`, `:1961`, `:2378`, `:2586`), adica proprietati **de articol**, populate de apelant
    prin `Scatter Name poArticol` **inainte** de `Createobject` — asa fac deja cei 3 apelanti vechi
    (`ofacturare.vc2:12873`, `:13805`, `:17180`). Consecinta care schimba scopul:
    **decizia 35 se poate implementa FARA sa se atinga `ofacturare.vc2`** — se populeaza
    `poArticol.tip_valuta=1` + `Curs`/`multiplicator`/`nume_val`/`id_valuta` din `tvanz` (coloane deja
    incarcate de `IncarcaVanzareNota`, fara interogare Oracle noua) in `cmdAdaugaArticol.Click` /
    `CreeazaPoArticolNouTvd`, ambele proprii acestei livrari. Risc de regresie pe apelantii vechi:
    **zero**, cat timp codul dialogului nu se atinge. Dialogul intoarce atunci **ambele** valori —
    `pretftva_val` (valuta, introdusa de user) si `pretftva` (RON, derivat cu acelasi curs,
    `ofacturare.vc2:1989`/`:2017`/`:1892`/`:1937`) — deci `AdaugaLinieTvdDinArticol` trebuie sa citeasca
    **direct `_val`**, nu sa mai converteasca RON->valuta (altfel face cerc RON->valuta->RON->valuta,
    aproape neutru dar cu rotunjiri in plus). Cu `tip_valuta=0` cum e azi, conversia existenta e
    **corecta**, nu dubla.
36. **#6 / S4, suma `RUL` se face DOAR pe `ID_TIP_RULAJ = 0`** (Marius, 09.08.2026). Alea sunt
    intrarile/iesirile **reale**. Randurile `ID_TIP_RULAJ = 3` sunt intrari/iesiri **virtuale**:
    apar cand marfa la pret de vanzare se vinde la alt pret decat cel din stoc, iar perechea de
    diferenta de pret **tine locul procesului verbal de schimbare de pret** care ar fi trebuit
    intocmit inainte ca sa alinieze pretul de vanzare. Nu sunt miscare de marfa, deci nu intra in
    suma comparabila. **Inlocuieste formula veche**
    (`SUM(CANT*PRETVTVA) + SUM(CANTE*PRETVTVA WHERE ID_TIP_RULAJ <> 3)`), al carei prim termen
    insuma si randurile virtuale. **Respinsa** varianta discutata inainte de acest raspuns:
    excluderea randurilor "duplicat" prin potrivire de valoare (acelasi articol/cantitate/pret ca
    partenerul din perechea `3`) — dadea aceeasi cifra pe `cod=1140895`, dar ca euristica fragila,
    nu ca regula. Corectia cu liniile nestocate (decizia 25) ramane neschimbata si in continuare
    marcata "ajustat".
37. **#6 / S4, contul de referinta pe rate/contract nu e unic** (Marius, 09.08.2026): pe tip 2, 6, 52
    cu `id_rata <> 0` poate fi **`4111`, `411` sau `461`**, nu doar `4111` cum s-a implementat
    empiric. Toate trei se accepta. Atentie la comparatie: cu `SET EXACT OFF` un `=` simplu
    potriveste `'411'` ca prefix al lui `'4111'` — se compara cu `==` pe `Alltrim()`, pe o multime de
    conturi, nu pe o valoare unica.

## Fapte stabilite (nu le relua)

### #6 — arhitectura

- `frm_modific2024` e **clasa `.vcx`** in `COMUN\clase\omodificari.vc2` (clasa la `:6375`, metode
  `:12200-15319`), deja disponibila din ROAFACTURARE. **Nu trebuie portata.**
- Pageframe-ul existent `pgfArticole` are `PAGE1` = rulaje 303 (`grdRulaje`) si `PAGE2` = rulaje
  obiecte de inventar 8039 (`grdRulajeObinv`), `:8598-8601`. Pagina de articole factura se adauga
  dupa acest model.
- **`frm_modific2024` nu atinge azi deloc `VANZARI`/`VANZARI_DETALII`.**
- **Zero `UPDATE`/`DELETE` direct pe `ACT`/`RUL` in tot codul VFP.** Singura cale: cursoare ->
  `ACT_TEMP`/`RUL_TEMP` -> `PACK_CONTAFIN`. Editarea marcheaza randul vechi `STERS=1` si scrie
  document nou cu `cod` nou.
- **`ID_FACT` nu se schimba la modificarea notelor** — se genereaza la introducere din `nract` +
  `dataact`; se schimba doar `cod`-ul setului. Deci `VANZARI.ID_FACT` ramane neatins.
- `pack_contafin.finalizeaza_modificare_nota` (`COMUN\docs\PACK_CONTAFIN.pck:8601-8651`) cheama deja
  `pack_facturare.actualizeaza_vanzari(cod_vechi, cod_nou)`. **Dar** `actualizeaza_vanzari` face
  **doar** realinierea `cod` + `STERS=0`: nu recalculeaza sume, nu atinge totalurile denormalizate.
  **Aici e lucrarea server-side**, si de acolo o primesc ambele puncte de intrare.
- Sablon de urmat pentru actiunea din ROAFACTURARE: `frm_facturi.do_sterge`
  (`COMUN\clase\ofacturare_comun.vc2:4503-4719`), **nu** `do_modifica`. `do_sterge` are 3 garzi pe
  care `do_modifica` nu le are (luna inchisa `:4518-4520`, luna curenta `:4543-4546`, referinte
  `:4565-4569`) — devin obligatorii cand se ating sumele. Garda eFactura, de refolosit:
  `ofacturare_comun.vc2:4428-4432`.
- Drepturi pe `frm_facturi`: **nu** `nid_cw`, ci `lactiv3`/`lactiv4` + tokeni in `gcAcces`.
  `lactivN` gateaza executia, `cbutonN` vizibilitatea butoanelor; ambele populate generic de
  `_frm_base.actualizeaza_drepturi` din `gcAcces`.
- Garda eFactura e in `frm_facturi.do_modifica` (`ofacturare_comun.vc2:4426-4430`), **nu** in
  `do_sterge` cum spunea planul, si e un simplu `If`, nu un `Return` cu mesaj. `afisjurcom`
  (registrul jurnal) **nu o are deloc** — de extras in `COMUN\programe\`.
- `frm_modifica_articol_factura` (explicatie + taxcode) e deschis de `do_modifica_explicatie`
  (`But_modifica2`), nu de `do_modifica`, care deschide `frm_modifica_factura` (antet). Niciuna nu
  atinge sume.
- `frm_modific2024` **nu primeste cursoare ca parametru** — se leaga pe aliasurile `tact` / `trul` /
  `trul_obinv`, deschise READWRITE de apelant inainte de `Createobject`; `Init` primeste
  `tnIdSet, tlNotaNoua, toBackupXML, toSet, tlVizualizare`. Validarea grea sta in
  `inainte_de_do_termin` (`omodificari.vc2:13357-13549`) — acolo intra si validarile noi de sume.
- **Calea de scriere in `VANZARI_DETALII`**: la emitere trece prin GTT `VANZARI_DETALII_TEMP`
  (`ON COMMIT DELETE ROWS`), umpluta de `pack_facturare.adauga_articol_factura` (apel Oracle per
  linie din VFP) si golita in tabela reala de `scrie_in_vanzari`. `adauga_articol_factura`
  **nu e reutilizabila la editare** — re-deriva pret/TVA/valuta din documentul-sursa, care la o
  factura emisa nu mai exista. #6 scrie **direct** in `VANZARI_DETALII` (UPDATE / `STERS=1` /
  INSERT), dupa modelul `modifica_explicatie_articol`; PK-ul vine din trigger pe
  `SEQ_VANZARI_DETALII`. Stergerea unei singure linii **nu exista azi**.
- Pe Oracle, calculul per linie e **deja extras** in `calculeaza_total_fara_tva_fact` /
  `calculeaza_total_tva_fact` si ramifica pe `PRET_CU_TVA`; de extras ramane doar **agregarea** pe
  document. `SERIE_INCASAT`/`NR_INCASAT`/`SUMA_INCASAT`/`TIP_INCASAT` **nu se recalculeaza** (n-au
  sursa persistenta; o copiere naiva a `UPDATE`-ului le-ar pune NULL si ar rupe legatura cu
  incasarea). `VALVAL`/`TVAVAL`/`TOTVAL` **intra** in recalcul.
- **S6 inchis pe cod**: toate legaturile trec prin `ID_FACT` sau `ID_VANZARE`, niciuna prin `cod`;
  `actualizeaza_vanzari` rescrie doar `COD` pe acelasi rand, `ID_VANZARE` nu se schimba niciodata.
- **`id_set + 5` de la discount NU ajunge niciodata in `ACT`** — ipoteza lui Marius, confirmata pe cod
  si pe date. `PACK_FACTURARE.cumuleaza_note_act_temp` (`:14198`) rescrie `ID_SET` cu
  `pack_facturare.nid_set` (valoarea de baza, deja restaurata de `scrie_discount`), iar
  `PACK_CONTAFIN.SCRIE_IN_ACT` (`:956-958`) copiaza `ACT_TEMP` -> `ACT` fara alta transformare.
  Pe date: 170 de randuri de discount (64 `MARIUSM_AUTO` 2008-2026, 6 `ROMFAST` 2002-2007,
  100 `VENDING` 2017-2018) — **toate** cu acelasi `id_set` ca restul notei. Offsetul e marcaj
  tranzitoriu. **Ramura "2 id_set la distanta 5" din garda scrisa in runda 3 e cod mort.**
- **`RUL` — formula comparabila, gasita**: liniile de **diferenta de pret** apar din
  `PACK_FACTURARE.descarca_gestiune` (`:9361-9540` marfa, `:9641-9818` produse), declansate de
  `V_PRETV_ORIG <> V_PRETV` pe gestiuni cu `V_TIP_GESTIUNE IN (6,7)` (marfa/produse la pret de
  vanzare). Suma comparabila, forma veche (**SUPERSEDATA de decizia 36**):
  `SUM(CANT*PRETVTVA) + SUM(CANTE*PRETVTVA WHERE ID_TIP_RULAJ <> 3)`. Inchide divergenta de pe
  `cod=1140888` (4476.28 -> 1924.59) si pe productie (`cod=1397098`) — dar pe **ruta gresita**, si
  numai pentru ca pe documentele fara perechi `3` cele doua forme coincid. **Forma corecta e cea din
  decizia 36**: suma **doar pe `ID_TIP_RULAJ = 0`**.
- **Liniile NESTOCATE nu au deloc rand `RUL`** (servicii, `IN_STOC=0`) — confirmat pe productie
  (`cod=1397106`, lipseste exact linia de servicii transport). Deci pe documente mixte suma `RUL`
  trebuie corectata cu liniile nestocate din `VANZARI_DETALII`.
- **Randurile `ID_TIP_RULAJ = 3` sunt miscari VIRTUALE, nu reale** (Marius, 09.08.2026 — vezi
  decizia 36). Apar cand marfa la pret de vanzare se vinde la alt pret decat cel din stoc: in mod
  normal ar fi trebuit intocmit intai un **proces verbal de schimbare de pret**, iar perechea de
  diferenta de pret **tine locul acelui proces verbal**. Deci nu intra in suma comparabila.
  Consecinta pe date: ce numea cercetarea "randuri duplicat" (`ID_TIP_RULAJ = 0` cu aceeasi
  cantitate/pret ca un rand din perechea `3`) sunt de fapt **miscarile reale**, iar perechea `3` e
  suprapunerea virtuala. Pe `cod=1140895`, suma doar pe `ID_TIP_RULAJ = 0` da
  `121.00 + 2*121.01 + 1259.07 + 302.50 = 1924.59` = exact `ACT`/`TOTAL_CU_TVA`. **Euristica de
  excludere pe potrivire de valoare nu mai e necesara** — regula e semantica, nu de potrivire.
  Formula veche parea sa mearga pe cele 360 de documente doar pentru ca pe documentele **fara**
  perechi `3` cele doua forme coincid (`rec_suma_act.md` E.5: in esantionul `VENDING` nu s-a gasit
  niciun `tip=1` cu `ID_TIP_RULAJ = 3`).
- **`cod=1138989` (tip 51) SE INCHIDE: nota e dublata.** Cele 12 randuri `ACT` sunt doua blocuri de
  cate 6, al doilea **exact 2x** primul rand cu rand; blocul A insumeaza exact `TOTAL_CU_TVA`
  (13895.45, cu 0.01 de rotunjire), totalul 41686.35 = 3x. Deci regula pentru suma din `ACT` tine si
  aici — documentul are o nota **postata de doua ori**, anomalie de date, nu exceptie de la regula.
  Ramane neexplicata doar linia unica din `VANZARI_DETALII` (2468.21), care nu reconciliaza cu
  niciuna din cifre. Detalii: `docs\cercetare\rec_cele_41_facturi.md`.
- **Cele 41 de facturi de la decizia 9 sunt toate documente STERSE** (`VANZARI.STERS = 1`).
  Definitia care da exact 41: fara filtru pe `sters`, `total_cu_tva <> 0`, zero linii **active** in
  `VANZARI_DETALII` (cu `sters = 0` pe antet rezultatul e 0). `cod=1138989` **nu e printre ele** —
  are `sters = 0` si o linie activa. Presupunerea din `rec_suma_act.md` ca ar fi "aceeasi familie"
  a picat.
- **`an`/`luna` nu se deriva din `VANZARI.DATA_ACT`**: pe 703 documente, 542 au nota in luna din
  `DATA_ACT`, **78 intr-o alta luna**, 83 n-au deloc randuri `ACT`. In datele de test cazurile sunt
  concentrate pe `tip = 51` (`DATA_ACT` sablon `01-JAN-19`), deci nu e dovedit tipar de productie —
  dar `an`/`luna` se iau din contextul notei deja incarcate, niciodata recalculate din antet. Pentru
  cele 78, `do_editare_factura` raspunde azi "Nu exista nota contabila" si refuza editarea.
- **Randul periculos la pozitionarea in `actactan` nu e cel de discount, ci INCASAREA.** In `ACT` nu
  exista niciun rand cu `id_fact <= 0` din 2020 incoace (si `id_factd` nu e niciodata NULL), deci
  `ID_FACT = -1` scris de `scrie_discount` nu ajunge acolo. In schimb, primul rand al notei dupa
  `id_act` poate fi `INCASARE`/`INCASARE NUMERAR`, cu `id_fact` = al facturii **minus 1**: **39 de
  facturi** in schema de dev pe care un `Go Top` orb ar prelua `id_fact`-ul chitantei. Sursa corecta
  pentru `id_fact` e `crsfacturi` (= `VANZARI.ID_FACT`). Dovezi:
  `docs\cercetare\rec_pozitionare_actactan.md`.
- **`VANZARI.COD` NU e unic — dovedit pe date.** Indexul `IDX_VANZARI_04` e pe `(STERS, COD)` si e
  **NONUNIQUE**; `cod=1139934` are **4 randuri active** cu `TIP`/`NUMAR_ACT` diferite, `cod=1139555`
  are 2. Deci forma simpla din A.3 (`SELECT ... FROM vanzari WHERE cod = tact.cod`) **poate intoarce
  documentul gresit**. Dezambiguizarea aplicata in `IncarcaVanzareNota`: filtru compus
  **`cod` + `nract` + `serie_act` + `data_act`** (toate disponibile pe `tact`, din `vact_tot`) —
  `(COD, NUMAR_ACT, SERIE_ACT, DATA_ACT)` verificat fara nicio dublura pe toata tabela.
  **`ID_FACT` nu e utilizabil ca discriminator**: e NULL pe o fractie mare de randuri chiar si pe
  facturi normale (`tip=1`: 58 din 183 NULL; `tip=51`: 58 din 74) — ar rata avizele, deci ar incalca
  decizia 19.
- **`id_set` unic pe nota, confirmat pe date**: 558 de note legate de `VANZARI` cu un singur `id_set`,
  1 cu doua — si aceea e randul-gunoi `cod=0, an=0, luna=0`. Decizia 24 se sustine.
- **`VANZARI.DATA_ACT` nu se potriveste cu `ACT` pe 19 note din 419** (4.5%): data difera fizic de
  orice `dataact` din nota — majoritatea din 2019, cu `01.01.2019` ca placeholder, restul decalate /
  NULL / stornate. **Nicio alegere de rand din `tact` nu le rezolva**; `Go Top`-ul de azi le rateaza
  identic, deci nu e regresie introdusa de decizia 27. Pe ele PAGE3 nu apare.
- **`ofacturare_editare.prg` e inregistrat DOAR in ROAFACTURARE** (`roafacturare.prg:214`).
  `roacont.prg:233` si `roagest.prg:175` incarca `omodificari.vcx` fara ea. Orice apel nou si negardat
  din `frm_modific2024` catre functiile din acel fisier **rupe registrul jurnal** in ROACONT/ROAGEST.
  De verificat la fiecare extindere a clasei — `COMUN` ajunge in toate produsele, punctele de intrare nu.
- **`finalizeaza_modificare_nota` foloseste `tnIdFactD` doar in cod comentat** (ramurile 90011/90013)
  — azi e complet nefolosit. `tnIdFact` conteaza **doar** pe ramura `tnIdSet IN (31003, 31004,
  31005, 31011)` (`UPDATE NOM_LUCRARI`), care e **vie** si pentru documente din `VANZARI`: 35 de note
  cu `id_set = 31011`, 5 cu `31003`, 1 cu `31005`.
- Regula pentru suma din `ACT` e verificata pe **360 de documente, 12 tipuri, 3 scheme**
  (`MARIUSM_AUTO`, `ROMFAST`, `VENDING` productie): ~97.5% potrivire exacta, restul explicate
  (transfer, custodie) sau izolate. `ROMFAST` se conecteaza **direct, fara tunel** (alias in
  `tnsnames.ora`, nu era in `oracle.md`).
- **"Suma din `ACT`" nu are filtru fix de cont** (spus de Marius, 08.08.2026): facturile merg pe
  `4111`, **avizele pe `418`**; nota mai contine randuri de discount si poate contine note adaugate
  manual de utilizator. Regula corecta, pe tip de document: `docs\cercetare\rec_suma_act.md`.
- **Nota se genereaza in `PACK_FACTURARE`, nu in `PACK_CONTAFIN`** (care doar copiaza
  `ACT_TEMP` -> `ACT`): `scrie_factura2` / `scrie_factura_avize` -> `contabilizeaza_articol` /
  `contabilizeaza_rata` -> `scrie_nota`. Discountul de document: `scrie_discount`, pe cont opus.
- **Comparatia stricta `ACT` vs `VANZARI_DETALII` e imposibila prin constructie**: `ACT` **nu are
  nicio coloana care sa marcheze originea randului** (`omodificari.vc2:12653`, `do_adauga`), deci
  dupa salvare un rand adaugat manual e indistinctibil de unul generat automat. Indicatorul din S4b
  ramane **informativ pe subset definit**, fara verdict automat de eroare. Agraveaza faptul ca #6
  activeaza tocmai `do_adauga` si pe facturi.
- **`cod` singur NU e filtru sigur pe `ACT` — se cere `cod` + `an` + `luna`.** Dovada:
  `cod=1140632` are randuri dintr-o factura de achizitie straina (OCR furnizor) in luna 1 **si** nota
  de vanzare reala in luna 2, cu acelasi `cod`. `IncarcaCursoareModificareNota` filtreaza deja corect.
- **Contul de client difera pe mai mult de doua valori**: facturi `4111`; factura din aviz `4111`
  (discountul direct pe `4111` cu semn negativ, nu pe `667`); **avize catre clienti debitori
  (tip 28, 29) — cont `461`**; restul avizelor `418`. Discountul pe facturi normale e `667`/`4111`
  pe credit, deci suma corecta e **soldul net (debit - credit)**, nu `SUM(SCD=...)`.
- **Tipuri fara suma comparabila**: transfer intre subunitati (23, 25, 30, 41) si transfer pe
  lucrare (27) merg pe cont de **stoc**, nu de client; custodia (42, 47) nu genereaza **niciun** rand
  `ACT` per articol. Pe ele nu exista ce compara — de tratat explicit, nu de raportat ca eroare.

### #8 — cauza si inventarul, confirmate

- `PACK_FACTURARE.scrie_corespondente_vanzari` incheia cu `UPDATE VANZARI SET AVIZE = (...)` **fara
  WHERE la nivel de instructiune** — subinterogarea era filtrata corect, rezultatul se scria pe tot
  tabelul. Singurul `UPDATE`/`DELETE` fara WHERE pe `VANZARI` din tot pachetul (verificate toate cele
  17). Reparat in #8.
- Cele doua view-uri sunt **aliniate structural** (`FACT_VFACTURI` 100 coloane, `FACT_VFACTURI2` 101,
  in plus doar `TIP_PERSOANA`); divergenta era de **valori**, pe 16 coloane din 99.
- Harnessul de regresie: `docs\verificare_vfacturi.sql` — ruleaza pe orice schema si afiseaza doar
  coloanele diferite. **Nu e artefact consumat**: cele doua view-uri raman in paralel prin decizia 4,
  iar #7 a schimbat preturile pe linie, adica exact totalurile pe care le compara.
- Linia de baza acceptata dupa #8, pe 846 perechi: `CURS 19`, `MULTIPLICATOR 3`, `ID_VALUTA 19`,
  `TOTAL_FARA_TVA 54`, `TOTAL_TVA 46`, `TOTAL_CU_TVA 59`, `VALOAREA 39`, `SERIE_CHIT 15`,
  `NR_INCASARE 64`, `INCASAT 76`, `TIP_INCASARE 29`, `NUME_VAL 19`, `VALUTA 19`;
  `ALTELE`, `CONTRACT`, `EXPLICATIE`, `CLIENT`, `DISC_FARA_TVA` = **0**.
  Orice cifra care se misca fata de tabelul asta e regresie.
- Semnificatia completa a tipurilor de document (perechile `(ID_SET, TIP)`, etichetele din
  `EXPLICATIE`, seturile folosite in cod, capcanele `46`/`47` si coliziunea `25051`):
  `COMUN\docs\tipuri_documente_facturare.md`.

### #10 / #11 / #12 — valabile, amanate

Planurile si faptele raman valabile; sunt amanate pentru ca mai au nevoie de analiza (varianta
neatestata la #12, precoditia de inrolare text la #11, go/no-go nedecis la #10). Motivele:
`plan_index.md`. Materialul de reluare: `docs\cercetare\`.

## Ipoteze EXCLUSE (cu dovada)

- **#8, avizul nu se scrie deloc** — fals. `scrie_corespondente_vanzari(1)` e apelata neconditionat
  pentru `tip=4`. Problema era ca scria peste tot.
- **#8, `scrie_in_vanzari` nu are WHERE** — fals, are.
- **#8, cele doua view-uri au divergat structural** — fals, divergenta era de valori.
- **#8, handler-ul `when NO_DATA_FOUND then null` ascunde UPDATE-ul** — exclusa **arhitectural**:
  toate `SELECT INTO`-urile din `scrie_in_vanzari` sunt agregari pure fara `GROUP BY`, care in Oracle
  intorc mereu exact un rand. `NO_DATA_FOUND` nu poate porni de acolo; handler-ul e cod mort.
- **#8, chitantele lipsa ar veni din facturi emise din aviz (`tip=4`)** — fals; 21 din 26 sunt
  `tip=-12`.
- **#8, chitanta stearsa dupa emitere** — exclusa: niciun rand `ACT` sters pe perechile verificate.
- **#7, e nevoie de coloana noua in `VANZARI_DETALII`** — fals, flagul exista deja per linie.
- **#6, `id_fact` s-ar schimba la editare** — fals, e by design stabil.
- **#6, se poate face regenerare prin re-emitere** — respinsa de Marius.
- **#12, varianta B (politica implicita unica)** — exclusa pe date.
- **#12, `ACONT` ar fi contul de venit** — fals, e nefolosita si contine gunoi.

## AVERTISMENT: `MARIUSM_AUTO` are date de TEST

Datele sunt facute manual pentru test, nu de productie. Deci **concluziile bazate pe distributie,
volume sau frecvente sunt slabe** — datele calendaristice pot fi artificiale, iar combinatiile pot sa
nu apara niciodata in realitate. Ramane solid tot ce e demonstrat pe **cod** si tot ce vine din
istoria produsului spusa de Marius. Autoritatea pentru orice intrebare de distributie e **`VENDING`**
(productie), in citire, prin tunel.

## Precoditii de mediu

- **Dezvoltare si test**: `MARIUSM_AUTO/...@ROA_CENTRAL`, client
  `D:\ROA\instantclient_19_18\sqlplus.exe`. Credentiale: `COMUN\docs\local\oracle.md` (scos din SVN
  la r17995, exista doar pe disc). SQL-ul se da prin fisier `.sql` ASCII cu `@fisier`, **nu** prin
  pipe din PowerShell (BOM-ul UTF-16 sparge parserul).
- **`VENDING`** (productie): al doilea set de date, **strict citiri**. Tunelul se porneste headless cu
  `stnlc.exe` (nu `BvSsh.exe`, care e GUI). Tabelele sunt in schema `VENDING`, deci
  `alter session set current_schema = VENDING;` la inceputul fiecarui script.
  Are **avize** si **facturi din comanda** — tipuri care lipsesc din `MARIUSM_AUTO`.
- **`ROMFAST@ROA_ROMFAST`**: are **facturi pe baza de contract**, tot **strict citiri**.
  Impreuna cu `VENDING`, acopera tipurile de document pe care schema de dezvoltare nu le contine.
  Credentiale pentru ambele: `COMUN\docs\local\oracle.md`.
- **#11 / #10**: `ROAPRETURI` si `ROACONTRACTE` **nu au cache text** (`.vc2`/`.sc2`). Procedura:
  `COMUN\docs\inrolare-proiect-git-text.md`.
- Scripturile Oracle: nivel **10.2** (ROMCONSTRUCT), CRLF, idempotente, cu `UpdateVersiune` **si**
  `commit;` la final — `COMUN\docs\scripturi-migrare-db.md`.

## Comenzi utile

```powershell
# text VFP la zi (la inceputul sesiunii si inainte de orice git commit)
powershell -ExecutionPolicy Bypass -File D:\ROA\UTIL\foxbin2prg\git_sync.ps1 -ProjectRoot D:\ROA\ROAFACTURARE

# cautare pe simboluri (da fisier:linie si clasa.metoda proprietara)
$s = 'D:\ROA\UTIL\foxbin2prg\vfp_symbols.ps1'
$c = @('-CacheRoot','D:\ROA\ROAFACTURARE','-ProjectRoot','D:\ROA\ROAFACTURARE','-IndexFile','D:\ROA\_vfp_textcache\roafacturare\_symbols.tsv')
powershell -ExecutionPolicy Bypass -File $s @c -Grep '<expresie>' -CodeOnly

# harnessul de regresie pentru #8
& 'D:\ROA\instantclient_19_18\sqlplus.exe' -L -S 'MARIUSM_AUTO/<parola>@ROA_CENTRAL' '@D:\ROA\ROAFACTURARE\docs\verificare_vfacturi.sql'

# test VFP headless sub watchdog: captura PNG + textul dialogului nativ care blocheaza, apoi kill
powershell -ExecutionPolicy Bypass -File D:\ROA\ROAFACTURARE\COMUN\utile\Teste\watchdog_vfp.ps1 -Script '<test.prg>' -AutoDismiss

# suita de regresie #7 (VFP headless)
powershell -ExecutionPolicy Bypass -File D:\ROA\ROAFACTURARE\COMUN\utile\Teste\facturare_pret_cu_tva\test_pret_cu_tva_nivel3_gestiuni.ps1
```

Sursa `PACK_FACTURARE` se exporta din `MARIUSM_AUTO` (`all_source`), conform
`COMUN\docs\oracle_export.md`. Copia pe disc, cu alta numerotare de linii:
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql`.

## Ce a ramas in `docs\`

| Fisier | Continut |
|---|---|
| `plan_index.md` | ordinea de executie, dependentele intre planuri, precoditii |
| `plan_06_editare_factura.md` | 10 stories + sectiunea "Ce preda #7 catre S6" |
| `plan_07_pret_cu_tva_pe_linie.md` | consumat de #7, pastrat ca referinta a variantei respinse |
| `plan_10` / `plan_11` / `plan_12` | amanate |
| `verificare_vfacturi.sql` | harnessul de regresie pentru cele doua view-uri |
| `plan_06_s4_proiectare.md` | proiectarea S4/S4b; C.1 rescrisa 08.08.2026, A.3 aliniata la decizia 19 |
| diff aplicat (sters) | **diff-ul S4 runda 1, de revizuit** (`omodificari.vc2` + `ofacturare_editare.prg`) |
| `cercetare\rec_s4_runda1.md` | raportul rundei 1: ce s-a implementat, ce s-a testat, ce NU e acoperit |
| `cercetare\rec_review_ancorare_s4.md` | review-ul de ancorare a coloanelor (sursa deciziei 26) |
| `cercetare\rec_gotop_tact_s4.md` | blocantul `Go Top In tact`, confirmat pe date (sursa deciziei 27) |
| `COMUN\docs\cercetare\rec_view_articole_vanzare.md` | proiectarea `VVANZARI_ARTICOLE` + ce s-a respins |
| `COMUN\docs\cercetare\ff_view_articole_vanzare.sql` | copia de lucru a scriptului (originalul e in `SCRIPTURI_CLAR`) |
| `cercetare\handoff_s4_runda1.md` | predarea agentului `s4-runda1`; detaliile blocajului „View Parameter" |
| `COMUN\docs\cercetare\rec_watchdog_vfp.md`, handoff intermediar (sters) | watchdog-ul VFP si regula `*p:` pentru proprietati noi |
| `cercetare\rec_editare_factura.md`, `rec_modific2024.md` | #6 |
| `cercetare\rec_suma_act.md` | regula sumei din `ACT` pe tip de document (sursa lui C.1) |
| `cercetare\rec_pozitionare_actactan.md` | de unde se citesc `id_set`/`id_fact`/`id_factd` (runda 4) |
| `cercetare\rec_datoria6_baza_regresie.md` | realocarea de `cod` 1140888->1140895 si re-ancorarea suitelor pe descoperire |
| diff aplicat (sters) | diff-ul celor doua suite + `descopera_caz_test.prg` |
| `cercetare\rec_cele_41_facturi.md` | cine sunt cele 41 de la decizia 9; `cod=1138989` = nota dublata |
| `COMUN\docs\cercetare\rec_tva_vanzari.md`, `rec_pret_lazy.md` | #7 (fond) si #12 |
| `COMUN\docs\cercetare\rec_integrari.md` | #10, #11, #12 |
| `COMUN\docs\cercetare\rec_consumatori_vanzari.md` | inventarul celor ~16 cai `xmlefactura` (datoria 5) |
| `COMUN\docs\cercetare\rec_s10_s12.md` | textul propus pentru `changelog_roaauto.txt` (datoria 3) |
| `cercetare\rec_todos_done.md` | starea punctelor din `todos.txt` |
| `cercetare\rec_s4_runda3b.md` | sub-blocul B: stergerea de linii (implementare + testare) |
| handoff intermediar (sters) | contractul `frm_articol_factura`/`poArticol`/`poDate`/`gnScadereStoc` pentru adaugarea de linii (neinceputa) |
| diff aplicat (sters) | diff-ul stergerii de linii |
| `COMUN\docs\cercetare\s10_curata_versiune.sql` | curatarea tabelei `VERSIUNE` (datoria 4) |

`docs\` **nu e urmarit nici de git, nici de SVN**, si `COMUN\utile\curatenie.ps1` l-ar sterge la
curatenia dinainte de commit. Ce trebuie pastrat, se muta sau se comite.

## Mod de lucru

Conform `CLAUDE.md`: sesiunea principala orchestreaza, **subagenti proaspeti per sarcina**
(~200-250k tokeni, apoi predare pe disc + agent nou — `COMUN\docs\orchestrare-subagenti.md`).
**Fara commit fara review**: diff-ul se livreaza intai ca fisier in `docs\`.

Doua lectii platite scump, amandoua din aceeasi cauza — un subagent tinut peste prag
(`s5-nivel2` 533k, `s2d-modifica-gestiuni` 434k): **cand un agent a terminat un bloc, se scrie
starea pe disc si blocul urmator il ia un agent nou.** Nu conteaza ca "mai are putin"; predarea e
aproape gratuita, pentru ca raportul e deja scris.

**UN SINGUR SCRIITOR PE FISIER, oricat de disjuncte par sarcinile.** Platit pe 08.08.2026: doi
agenti au primit sarcini diferite care atingeau amandoua `Show()` din `omodificari.vc2`; al doilea a
scris pe baza unei citiri mai vechi si a sters tacit modificarea primului (**lost update**). Nu a
sarit in ochi: fidelity-check-ul trece, testele treceau pe alt caz, iar agentul a raportat drept
"revertite" si lucruri care de fapt erau intacte. **Verificarea starii se face pe disc de catre
orchestrator, nu din raportul agentului.** Al doilea simptom, tot de acolo: textul `.vc2` poate
ramane inaintea binarului daca agentul e oprit intre editare si write-back — se compara **mtime-urile
si markerii din `.vct`**, nu se presupune.

**Criteriul de falsificare dat unui agent trebuie sa fie el insusi verificat.** Tot 08.08.2026: am
cerut "ipoteza cade daca `RecordSource` nu ajunge gol". Predictia era gresita (VFP nu goleste
proprietatea), si headless grid-ul nici nu se materializeaza — deci masuratoarea nu putea decide
nimic. Agentul a raportat corect cifra si a tras concluzia gresita **pe criteriul meu**. Cand un
agent raporteaza "ipoteza infirmata", verifica intai daca proba chiar putea sa o infirme.

Si: **pentru executie delegarea merge; pentru concluzii verifica intotdeauna numitorul, datele de
intrare ale testului si sensul corectiei propuse.** S-a confirmat de mai multe ori — rezultate care
pareau sa infirme o corectie s-au dovedit, la verificare, altceva decat pareau.

## Capcane de mediu, de aplicat imediat

- **Grep de la radacina proiectului NU vede nimic din `COMUN\`** — `COMUN/` e in `.gitignore`-ul
  acestui repo si ripgrep il respecta, deci intoarce tacut "No matches found" pentru simboluri care
  exista. Se da `path` explicit pe `COMUN\...`. Probat: `gridextra` -> 0 fisiere de la radacina,
  25 cu `path=COMUN\clase`.
- **`git stash` e INTERZIS in `COMUN`** (si in orice director dublu-versionat SVN+git): `git stash
  push -u` da jos de pe disc modificari necomise in SVN si fisiere netrackuite, iar `svn status` le
  arata ca `!`, nu ca `M` — pierderea nu sare in ochi. Dupa orice operatie git acolo, ruleaza
  `svn status` si cauta `!`.
- **`svn update` se blocheaza** daca il rulezi ca `svn update <dir> 2>&1 | Select-Object ...` din
  PowerShell 5.1 (proces cu 0% CPU — pare retea sau credentiale, nu e). Forma corecta:
  `svn update <dir> --non-interactive > fisier`, fara `2>&1` si fara pipe.
- **`COMUN` primeste commituri si din alte produse**, si Marius lucreaza uneori din alta copie de
  lucru. "Aici nu lucreaza nimeni altcineva" e valabil pentru copia de lucru, nu pentru repo.
  Verifica `svn log -l 3` inainte sa comiti sau sa tragi concluzii despre ce e in HEAD.
- **Zgomot de la compilarea VFP**: dupa un build din IDE, `svn status` arata `M` pe binare atinse
  doar de recompilare. Se comite tintit pe modificarile reale, apoi se reverteste restul — dupa ce
  se verifica pe versiunile text ca au zero diferente de continut.
- `txt2vcx.ps1 ... -AllowComun` se ruleaza **direct, fara aprobare prealabila**; verificarea ramane
  pe binar. Regula "fara commit fara review" e neschimbata.
- Testarea UI headless (inclusiv dialogurile modale `Show(1)` deschise din codul aplicatiei):
  **`COMUN\docs\testare-ui-vfp.md`** — mecanismul si toate capcanele platite sunt acolo, citeste-o
  inainte sa scrii o suita noua.
- **`vfp_ui_harness.ps1`: nepotrivirea de director de sincronizare blocheaza captura, si TAIE testul.**
  Cauza reala a celor 24 de esecuri de captura din 09.08.2026 (16 intr-o sesiune, 8 in alta):
  testul isi seta `gcSyncDir` pe `uisync4\`, iar harness-ul astepta implicit in `uisync\`. **Se da
  `-SyncDir` explicit** si merge din prima. **Nu era masina ocupata** — asa s-a crezut doua sesiuni la
  rand, si concluzia gresita a fost scrisa si aici; corectata 09.08.2026.
  Consecinta care ramane valabila indiferent de cauza: testul se opreste la fiecare pas `READY` si
  asteapta handshake-ul; daca acesta nu vine, procesul e omorat acolo si **tot ce urma dupa acel pas
  nu se executa, fara nicio eroare in log**. Asa au iesit doua cifre umflate: `7/7` raportat cand
  logul avea **6**, si `10/10` cand avea **9**. **Regula**: cifra se ia numarand liniile `PASS`/`FAIL`
  din log, iar dovada ca rularea a ajuns la capat e **linia de `REZULTAT`** — fara ea, rularea e
  taiata, indiferent ce spune raportul. Asertiile importante se pun **inainte** de primul `READY`.
  (Atentie la numaratoare: linia de `REZULTAT` contine ea insasi cuvintele `PASS` si `FAIL`, deci un
  `Select-String` naiv raporteaza cu unu mai mult din fiecare.)
- **Uneltele de test n-au voie sa foloseasca input real** (`keybd_event`, `SendInput`, `mouse_event`,
  `SetForegroundWindow`) — input-ul real **nu are tinta**, ajunge in fereastra care are focusul atunci,
  oricare ar fi ea, iar masina e partajata. Pe 08.08.2026 watchdog-ul a trimis ESC dupa
  `SetForegroundWindow`; a rezultat eroarea VFP 1 „Execution was canceled by the user", raportata ca
  posibil bug de aplicatie — **s-a dovedit ca era procesul nostru de test**, deci n-a stricat munca
  nimanui, dar a costat un ciclu de alarma falsa. Permis: doar mesaje tintite pe handle
  (`PostMessage`/`SendMessage`), care nu ating focusul.
  Daca asa nu se inchide dialogul, dismiss-ul esueaza cinstit — captura ramane oricum partea de
  incredere. La omorarea proceselor `vfp9.exe`: **doar cele pornite de tine** (verifica `StartTime` si
  `MainWindowTitle`).
- **`DO ... WITH` paseaza PRIN REFERINTA, iar variabila devine invizibila sub numele ei propriu in
  procedura apelata.** Dovedit pe date 08.08.2026: `gnAn` valid in programul principal la fiecare
  checkpoint, `'U'` la intrarea in cele 3 proceduri apelate cu `DO ... WITH gnAn, gnLuna`, valid in
  cele 2 apelate fara — corelatie 5/5 cu **sintaxa apelului**, nu cu ce face procedura. Consecinta
  urata: orice `?variabila` din SQL passthrough de pe lantul respectiv nu se mai poate lega si VFP
  deschide **dialogul nativ „View Parameter"**, care blocheaza testul headless la infinit. Remediu:
  paranteze — `DO proc WITH (gnAn), (gnLuna)` forteaza pasarea prin valoare.
  **In productie tiparul exista, dar e INOFENSIV — verificat 08.08.2026**, deci nu e nimic de reparat:
  `oproceduri_stocuri.prg:35, 130, 207` cheama `INAINTE_DE_STOC` (`oinainte_de.prg:356-411`), unde
  singurul SQL (`:389-390`) construieste totul prin **concatenare** (`Alltrim(Str(tnAn))`), zero `?`.
  Cautarea pe ambele conditii simultan (`DO ... WITH <global>` + `?<aceeasi>` pe lant) in tot
  `COMUN\programe`/`COMUN\clase` da doar un al doilea caz, la fel de inofensiv (`rulaje.vc2:8243` ->
  `fisa_magazie_fifo`). Corroborare: la `oinainte_de.prg:311` sta **comentata** o versiune veche a lui
  `INAINTE_DE_STOC` care folosea `?gnAn,?gnLuna` — capcana a mai fost lovita si s-a trecut pe
  concatenare. **De urmarit, fragil dar corect azi**: `test_casa` (`oinainte_de.prg:258`) chiar
  foloseste `?gnAn`/`?gnLuna`; apelantul (`ocasabanca.prg:66`) nu le paseaza ca argumente, deci nu sunt
  mascate — dar ar deveni bug daca cineva le adauga la apel. Detalii: `docs\cercetare\rec_inainte_de_stoc.md`.
- **O suita care testeaza o clasa din `COMUN` incarca implicit copia ALTUI PRODUS.**
  `COMUN\utile\Teste\test_init_env_auto.prg` face `Set Default To D:\ROA\ROACONT\`, pune `SET PATH` pe
  `ROACONT\COMUN\CLASE` si la `:139` `Set Classlib To omodificari Additive` — deci `Createobject`
  ia `D:\ROA\ROACONT\COMUN\clase\omodificari.vcx`, **nu** fisierul editat. Toate verificarile „live"
  de dinainte de 08.08.2026 pe `frm_modific2024` au validat alt fisier. Remediu, in test, dupa
  initializarea mediului: `RELEASE CLASSLIB omodificari` + `SET CLASSLIB TO <cale completa> ADDITIVE`
  (`SET CLASSLIB ... ADDITIVE` singur da eroarea 24 „Alias name is already in use" si pastreaza tacut
  copia veche). Verificare: `loForm.ClassLibrary` trebuie sa arate calea asteptata.
- **Sterge `.fxp`-ul vechi inainte de FIECARE rulare de test.** Altfel VFP ruleaza tacut codul VECHI
  compilat; simptomul e un log care nu corespunde sursei curente, cu rulari „identice" care dau
  rezultate diferite.
- **Dialogurile native VFP blocheaza testul headless la infinit**, fara log, fara eroare, fara
  `TRY/CATCH`, si nu-i prinde mock-ul de `amessagebox` (nu sunt `AMESSAGEBOX`). Doua vazute pana acum:
  „View Parameter — Enter the value for `<var>`" si „Open" (fisier lipsa). **Nu se depaneaza orbeste**:
  se ruleaza sub watchdog (mai jos), care face captura si citeste textul dialogului cu `WM_GETTEXT`.
- **Grid nou cu `RecordSource` pe un cursor inexistent la constructia formularului** -> VFP incearca
  `USE <recordsource>` ca fisier fizic si deschide dialogul nativ „Open". Solutia din clasa: placeholder
  gol creat in `Load()`, inainte ca framework-ul sa construiasca grid-urile (tiparul existent pentru
  `saft_taxtable` / `saft_mecanisme_plati`).
- **O proprietate custom noua are nevoie de intrare `*p:` in `*<DefinedPropArrayMethod>`**, nu doar de
  valoarea din `*<PropValue>`. Fara `*p:`, valoarea se scrie in text, **trece fidelity-check-ul**, ajunge
  in binar ca text — dar VFP nu o materializeaza pe obiect: `PEMSTATUS(o,'nume',5)` da `.F.` si orice
  acces cade cu eroarea 1734 „Property ... is not found". Regula era documentata doar pentru **metode**
  (`*m:`, `flux-editare-vfp-text.md:76-78`); se aplica identic proprietatilor. Dovedita in ambele
  sensuri pe o clasa de proba izolata (cu `*p:` -> `.T.`, fara -> `.F.`), deci fluxul text->binar
  **poate** crea proprietati noi, contrar ipotezei initiale.
- **FoxBin2Prg sorteaza alfabetic cu `_` DUPA literele obisnuite**, nu in ordine ASCII. O ordine „ASCII
  corecta" scrisa de mana pica fidelity-check-ul; ordinea canonica se citeste din `<staging>\verify\`.
- **FoxBin2Prg NU pastreaza ordinea textuala la roundtrip** pentru `ADD OBJECT` multiple si proprietati
  custom — le regenereaza in ordine proprie (nici macar alfabetica peste tot). Deci orice ordine
  „naturala" scrisa de mana poate pica fidelity-check-ul. Procedura: dupa primul FAIL, **adopta ca sursa
  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: partea VFP a punctului 6 si intrarea de changelog pentru runda 6 (nu exista inca).

**Corectie 20.08.2026, seara** — doua puncte din lista de mai sus erau deja facute:

- **Proba pe ecran a punctelor 1-5**: facuta de Marius.
- **Scriptul `ff_2026_08_20_02_COMUN_PACK_FACTURARE.sql` era deja aplicat** pe schema
  `MARIUSM_AUTO` de pe `ROA_CENTRAL`, contrar notei de mai sus ("NERULAT"). Dovezi, nu mtime:
  `VERSIUNE` are randul `20.08.2026 / seq 2 / COMUN_PACK_FACTURARE`; `ALL_OBJECTS` da PACKAGE si
  PACKAGE BODY **VALID**, `last_ddl_time` 20.08.2026 13:56:38; iar sursa vie din `ALL_SOURCE`
  (spec + body, normalizata: fara `CREATE OR REPLACE`, fara `/`, fara antetul de comentariu si
  fara `exec`/`commit`) e **identica cu fisierul de pe disc — 0 linii diferenta pe 16 407**.
  Deci in Oracle sta varianta **finala** (fara recalcul), nu varianta respinsa, desi fisierul are
  mtime 15:45, ulterior compilarii de la 13:56.
  Concluzie de metoda: mtime-ul fisierului si nota "scriptul nu a fost rulat" din raportul de
  livrare nu sunt surse de stare pentru ce e in Oracle. Starea se citeste din `VERSIUNE` +
  `ALL_SOURCE`, prin diff, inainte de a re-aplica ceva.
- Ramane valabila interdictia: **nu se re-aplica `ff_2026_08_20_01`** — ar sterge punctul 6.

## Runda 6 punctul 6 + runda 7 (sincronizare) - 20.08.2026, seara

Starea completa, cu inventar pe `fisier:linie`, ce s-a stabilit si ce e in lucru:
**`docs\handoff_r6_r7_sincronizare.md`**. Pe scurt:

- **Punctul 6 (explicatie TVA in `frm_facturi`): TERMINAT**, write-back verificat prin
  reconversie (0 linii diferenta, md5 identic), probat pe ecran de Marius de doua ori.
  Filtrul final al listei: `id_jtva_coloana > 0 AND afisat > 0 AND jv = 1 AND cota_tva = <cota
  liniei>`. Pe date (`vjtva_coloane`, `MARIUSM_AUTO`): `afisat = 0` sunt liniile de TVA,
  `afisat = 1` bazele, `afisat = 2` neimpozabilele; `jv = 1` tine afara explicatiile de
  achizitie, care altfel treceau de garda `FACT-029` fiindca au aceeasi cota.
- **Runda 7, in lucru**: sincronizarea articole-rulaje porneste doar din buton (se scoate
  declansarea de la salvare, `omodificari.vc2:14484-14494`), si `AplicaModificareTrul`
  (`ofacturare_editare.prg:924`) scrie si `pretv`/`tvav`, nu doar `pretvtva`.
  **Perimetru fixat de Marius: doar preturi, nu si `valoarev`/`valtvav`/`valoarevcTVA`** -
  sincronizarea e intre cantitate si preturi. Ramane de raspuns, ca fapt, cine recalculeaza
  acele valori dupa sincronizare.
- **Nimic nu e comis** - decizia lui Marius e un singur commit, dupa ce sunt gata toate trei.
- `roafacturare.PJT`/`.PJX`/`.exe` apar modificate: zgomot din sesiunea lui de VFP, se lasa asa.

### Runda 7 - terminata, 20.08.2026, 22:40

Raport complet: **`docs\raport_r7_sincronizare.md`**. Diff-ul commit-ului unic (runda 6 + runda 7):
**`docs\diff_r6_r7_pentru_commit.md`**.

- **M1 gata**: blocul de declansare de la salvare a disparut din `frm_modific2024.inainte_de_do_termin`;
  `AfiseazaDialogSincronizareArticole` are un singur apelant, butonul (`omodificari.vc2:16665`).
  `SemnaturaDivergenteSincronizare` + `cSemnaturaSincronizare` au ramas fara consumator - semnalate,
  nesterse. Write-back facut, dovedit prin reconversie: 0 linii diferenta, md5 identic.
- **M2 gata, in perimetrul corectat**: `AplicaModificareTrul` scrie `pretv`, `pretvtva`, `tvav`.
  Cele trei campuri de valoare pe care le adaugase subagentul au fost scoase.
- **Teste**: `test_s4b_sincronizare` **44/0**, `test_s4b_dialog` **35/0**. Prima rulare a dat 40/2,
  din fixture, nu din cod: harness-ul nu definea `gnPPretV`, iar cursorul `trul` din test nu avea
  coloanele `pretv`/`tvav` (tabela reala `RUL` le are). Adaugat si un caz cu TVA 19% real (C1 1600),
  fiindca toate cazurile existente aveau `proc_tvav = 1` si `tvav` ieseau 0 orice s-ar fi scris.
- **Raspunsul la intrebarea de fapt: nu le recalculeaza nimeni.** Lantul e verbatim de la cursor
  pana in Oracle - `trul` -> `RUL_TEMP` (`ofacturare_comun.vc2:3814`, doar `id_util`/`sters` se
  suprascriu) -> `sql_temp_insert` -> `INSERT INTO RUL (<lista coloane>) SELECT ... FROM RUL_TEMP`
  (`PACK_CONTAFIN.pck:2013`). Nici `ActualizeazaBaraTotaluri` (insumeaza doar `tvd.valoare`), nici
  `finalizeaza_modificare_nota` nu ating valorile. Interogat pe `MARIUSM_AUTO`: `VALOAREV` si
  `VALTVAV` **sunt** coloane in `RUL` si ajung invechite in baza; `VALOAREVCTVA` **nu e** coloana -
  exista doar in cursorul Fox, calculat la incarcare, deci ramane invechit doar pe ecran.
  Back-fill-ul de la reincarcare nu repara: are garda `WHERE EMPTY(NVL(...,0))`, deci prinde doar
  zerourile. Raportat ca defect, **nereparat** - decide Marius.
- **Nimic nu e comis.** Se asteapta aprobarea pe `docs\diff_r6_r7_pentru_commit.md`.

## Curatenie dupa inchiderea planului #6 - 20.08.2026

Planul #6 e inchis (SVN r18026, changelog 2.11.15). S-au sters **64 de fisiere** de lucru care nu
mai au consumator: planul si proiectarea (`plan_06_*`), brief-urile, diff-urile, rapoartele,
propunerile de runda 4/5/6, `rec_s4b_etapa2`, `review_s5_grid_articole`, `verificare_s5_writeback`,
`livrare_s5`, `diagnostic_pagina_articole_ux`, `raport_sweep_encoding`, plus 40 de `rec_*` din
`docs\cercetare\`. A plecat si `verificare_vfacturi.sql`, testul de regresie al planului #8, terminat
demult. Totul e recuperabil din git (`5b52cb3` si mai vechi).

**Ce s-a pastrat, si de ce:**

- planurile deschise sau amanate: **#13** (proiectat integral, urmeaza la rand), #12, #11, #10, #7,
  `plan_index.md`;
- materialul lui #13: `handoff_13_formular_unificat.md`, `mockup_13_formular_unificat.html`,
  `S1_inventar_campuri_formular_unificat.md`;
- `conventii_mediu_oracle.md`;
- din `docs\cercetare\`: toate cele 56 de fisiere non-`rec_*` si **7** `rec_*` care sunt inca
  citate de cercetarile vii (`rec_cale_vanzari_detalii`, `rec_d42_efactura`,
  `rec_datoria6_baza_regresie`, `rec_dec42_proiectare`, `rec_editare_factura`, `rec_s4_runda1`,
  `rec_s5_oracle_vanzari`). Criteriul n-a fost numele, ci referintele: **#13 se sprijina pe
  `docs\cercetare\` cu 86 de trimiteri**, deci folderul nu se putea sterge in bloc.

Trimiterile catre fisierele sterse care raman in acest jurnal (39) si cele 5 mentiuni in proza din
`plan_07`, `plan_13`, `handoff_s4_runda1`, `rec_s4_runda1` si `rec_cale_vanzari_detalii` sunt
istorice - se rezolva din git, ca la curatenia planului #8.

### Completare: si planurile #7 si #8 - 20.08.2026

- **#7** (pret cu TVA pe linie, terminat 08.08.2026, changelog 2.11.14): sters
  `plan_07_pret_cu_tva_pe_linie.md`, singurul lui artefact ramas.
- **#8** (denormalizare VANZARI, terminat si comis 07.08.2026, r17990-r17993): **nu mai era nimic
  de sters**. Planul plecase la curatenia anterioara, testul lui de regresie
  (`verificare_vfacturi.sql`) si `rec_s8_*` au plecat mai sus, in acelasi val.

Atentie la o capcana de nume: `cercetare\s8_incarcare_document.md`, `s8b_rutarea_scrierii.md` si
`audit_vanzari_creare_modificare_stergere.md` **nu** tin de planul #8 - sunt story-uri ale lui
**#13** si sunt citate de `plan_13` si de handoff-ul lui. Raman. Restul mentiunilor de
"denormalizare" din `cercetare\` sunt trimiteri de context catre #8, in cercetari inca vii.

Total sters in aceasta curatenie: **65 de fisiere**. In `docs\` raman 10 fisiere plus
`docs\cercetare\` cu 63.

### Conventia mediului Oracle trece in COMUN - 20.08.2026

`docs\conventii_mediu_oracle.md` ajunsese in `docs\` din inertia rundei 6, desi continutul e
transversal (instanta `ROA_CENTRAL`, schema comuna `CONTAFIN_ORACLE`, interdictia pe `ACN`, sirul de
conectare, `SCRIPTURI_CLAR\`). Mutat in `COMUN\docs\conventie_mediu_oracle.md`, aliniat la seria
`conventie_*`, si indexat la punctul 7 din `reguli_lucru.md`. Sectiunea 6 (starea constatata pe
`PACK_FACTURARE`) e marcata reper istoric ROAFACTURARE; conventia propriu-zisa sunt punctele 1-5.
In `docs\` raman 9 fisiere.