sync SVN r18026

docs/progres.md

@@ -2309,5 +2309,66 @@ initial, apoi **respinsa** — nu se reintroduce.
 - `ff_2026_08_20_01` (garda `FACT-025`, runda 5) e **deja aplicat** pe `MARIUSM_AUTO`; scriptul 02 il
   contine. **Nu se re-aplica 01** — ar sterge punctul 6.
 
-Ramase: proba pe ecran a punctelor 1-5, aplicarea scriptului pe `MARIUSM_AUTO`, partea VFP a
-punctului 6, si intrarea de changelog pentru runda 6 (nu exista inca).
+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`.