From b173fecbf80e568173fc895f080a30f88ec5c752 Mon Sep 17 00:00:00 2001
From: Marius Mutu <mmarius28@gmail.com>
Date: Wed, 16 Sep 2026 21:11:34 +0300
Subject: [PATCH] sync SVN r18143

---
 AGENTS.md                                    |    1 +
 docs/handoff_13_formular_unificat.md         |  798 ---
 docs/handoff_curatenie_progres.md            |   73 -
 docs/handoff_skills_agenti.md                |   94 -
 docs/plan_13_executie.md                     |  146 -
 docs/plan_13_unificare_formular_facturare.md | 4610 ------------------
 6 files changed, 1 insertion(+), 5721 deletions(-)
 delete mode 100644 docs/handoff_13_formular_unificat.md
 delete mode 100644 docs/handoff_curatenie_progres.md
 delete mode 100644 docs/handoff_skills_agenti.md
 delete mode 100644 docs/plan_13_executie.md
 delete mode 100644 docs/plan_13_unificare_formular_facturare.md

diff --git a/AGENTS.md b/AGENTS.md
index 845ddc7..b4c5757 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -16,4 +16,5 @@ skill-ului.
 - garzi pe valori NULL din Oracle in VFP -> skill `roa-vfp-null-guards`
 - `GO` pe un `Recno()` capturat sau primit ca parametru -> skill `roa-vfp-go-recno`
 - procedura PL/SQL cu `SELECT ... INTO` apelata din VFP (randuri pierdute tacut) -> skill `roa-oracle-sqlexec-no-data`
+- inrolezi un calculator nou sau un proiect nou in fluxul git-text / expui skill-urile pe masina / aplici backstop-ul de rutare -> skill `roa-onboarding`
 <!-- roa-skills:end -->
diff --git a/docs/handoff_13_formular_unificat.md b/docs/handoff_13_formular_unificat.md
deleted file mode 100644
index 81fd2dd..0000000
--- a/docs/handoff_13_formular_unificat.md
+++ /dev/null
@@ -1,798 +0,0 @@
-# Handoff — #13 formular unificat de facturare + editare prin regenerare
-
-Sesiune: 11.08.2026, **runda 17** (istoricul de mai jos e cumulativ; blocul rundei 14 e pastrat ca
-atare). Runda 13 predase dupa cinci proiectari si deciziile 44-50.
-
-> ## RUNDA 17 — „Urmatorul bloc de lucru" S-A GOLIT. Proiectarea lui #13 e INCHEIATA.
->
-> Runda 17 a executat **exact cele doua sarcini** care mai ramasesera (punctele 4 si 5 din lista de
-> jos) si **nu a deschis niciuna noua**.
->
-> > ### DECIZIA 66 (runda 17) RASTOARNA DECIZIA 64 — citeste asta inainte de orice paragraf despre asezare
-> > **Motivul discountului sta LANGA DISCOUNT, in banda de totaluri, nu ca a treia sectiune jos.**
-> > Formularea lui Marius: *„motiv discount vreau sa fie langa discount, nu a treia coloana"*.
-> > **Randul de jos revine la DOUA sectiuni** (incasare, alte date), fiecare pe jumatate de latime —
-> > adica exact decizia 57, punctul 2, neatinsa. **Argumentul „~440 px fiecare, strans" cade odata cu
-> > decizia 64.** Mai jos, in istoricul cumulativ al rundei 16, decizia 64 apare inca in vigoare in
-> > cateva paragrafe: **sunt istorie, nu stare curenta.** Locurile decisive sunt corectate; daca
-> > gasesti unul necorectat, **decizia 66 castiga**. Enuntul complet, cu regula de activare adaugata de
-> > proiectare (campul e activ **doar cand discountul nu e zero**): **in plan**, la „Decizia 66".
->
-> **O singura decizie noua, 66**, deci numerotarea se opreste la **66**.
-
-> ### AUDIT DE INCHIDERE (18.08.2026) — planul e curatat de marcajele „deschis" ramase in urma
-> Verificare ceruta de Marius inainte de a inchide sesiunea: **e planul finalizat?** Raspuns: **da ca
-> proiectare**, dar avea **noua intrebari fantoma** — blocuri „De decis de Marius" si „ramane deschis"
-> care supravietuisera deciziilor care le inchisesera. Un agent proaspat le-ar fi citit ca sarcini si
-> ar fi redeschis lucruri transate. **Toate au fost stinse**, fiecare cu decizia care o inchide, in
-> **8 linii** din plan (verificat prin diff fata de o copie de siguranta: zero modificari colaterale):
-> - trei blocuri **„De decis de Marius"** (S5c, S8b, S11) → inchise de deciziile **51**, **52**, **53**
->   si **56**; textul ramane ca **inventar al recomandarilor acceptate**, nu ca intrebari;
-> - doua afirmatii „ramane deschisa asezarea campului de motiv" → inchise de **decizia 66**;
-> - „din intrebarea 7 ramane deschisa partea de tipuri 48/49" → inchisa de **decizia 60**.
->
-> **Ce a ramas deschis, si e corect asa — trei puncte, toate de implementare, niciunul blocant:**
-> 1. **Relistarea unei facturi vechi deja trimise** (decizia 62, rest semnalat): dupa decizia 59 ar
->    produce N randuri de discount in loc de unul, deci hartie diferita de originalul din eFactura.
->    Relistarea nu e modificare, deci `EsteInEFactura` n-o acopera. **Nedecis, semnalat lui Marius.**
-> 2. **`PROC_TVAV` ca parametru** (consecinta 3 a deciziei 54): doar daca se cere reproducere exacta
->    peste o modificare legala de cota. **De decis separat.**
-> 3. **De unde se reconstituie `IN_STOC`** (cerinta rundei 17): preconditie de proiectare a lui S8,
->    trei variante scrise, niciuna aleasa.
-> **Cod: neatins** — nici un `.vc2` / `.sc2` / `.prg` deschis macar. **Zero Oracle** in aceasta runda,
-> nici macar `SELECT`. **Niciun commit dat de aceasta sesiune.**
->
-> **Punctul 4 — golul `IN_STOC` din S8 — INCHIS**, prins acolo unde cerea handoff-ul precedent (in nota
-> de executie a lui S8, nu la S12). Trei editari in plan, toate verificate pe disc dupa ce sesiunea de
-> la #6 a rescris `docs\` in paralel:
-> - `plan_13:3520-3546` — caseta „CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17";
-> - `plan_13:3567-3569` — criteriul intra in „gata cand" al lui S8;
-> - `plan_13` la S10, consecinta 1 — marcata **PRELUAT**, ca sa nu se redescopere.
->
-> **Punctul dur, si e mai greu decat suna cerinta:** valoarea istorica a lui `IN_STOC` **nu e stocata
-> nicaieri** — nu e coloana pe `VANZARI_DETALII` (verificat pe DB inca de la S10), traieste doar in
-> temp. Deci „S8 incarca `IN_STOC` din document" **nu e implementabil ca atare azi**. De unde se
-> reconstituie e o **preconditie de proiectare a lui S8** — trei variante scrise in plan (din urma
-> lasata in rulaje/gestiune; nomenclatorul curent ca aproximatie **declarata**; coloana noua, deci
-> migrare DB inainte de EXE). **Nu s-a ales niciuna** si nu se presupune niciuna.
->
-> **Punctul 5 — mockup v9 — LIVRAT.** `docs\mockup_13_formular_unificat.html`, 71 336 octeti (era
-> 67 075 la v8). Asezarea e acum **varianta D** cu **randul de jos in doua** si motivul discountului in
-> banda de totaluri (deciziile 57 + 66):
-> antet strans pe doua randuri fara titluri de grup; panoul „Discount pe document" **disparut**; banda
-> de totaluri **in interiorul panoului Articole, dupa `.gridbar`**, deci lipita de grid, cu procentul
-> de discount editabil pe loc, **motivul discountului imediat dupa suma pe care o explica** (decizia
-> 66) si totalul mare singur la dreapta; sub ea, **doua** sectiuni colapsabile egale
-> (incasare · alte date), cu **rezumatul continutului pe randul inchis**.
-> Legenda are acum 5 callout-uri (2 si 4 repurpozate, 5 nou). In text au intrat deciziile
-> **52, 53, 54, 59, 60, 61, 62, 63+65**. Raport: `docs\cercetare\mockup_v9_modificari.md`.
-> **Verificat de sesiunea principala, nu preluat din raport:** 0 taguri nechise, 0 inchideri
-> neasteptate, `<style>` unic si inchis.
->
-> **Mockup-ul E REPUBLICAT** (Marius a cerut-o in aceeasi runda), **pe URL-ul existent, nu pe unul nou**:
-> **https://claude.ai/code/artifact/e9d73e86-7518-4f50-a998-43c49e083142**. Cu asta decizia 33 e
-> consumata — URL-ul nu mai e in urma, e la v9. **URL-ul e notat acum si in plan**, la S1; pana in runda
-> 17 nu exista nicaieri in `docs\` si a trebuit scos cu `Artifact action: "list"`.
-> Inainte de publicare s-a facut **WebFetch pe URL** (obligatoriu, altfel publicarea e refuzata) si s-a
-> confirmat ca versiunea online era **v8**, deci v9 e superset si nu s-a suprascris nimic.
->
-> **Ce ramane dupa runda 17:** *nimic de proiectat*. Raman **testele (S6, S12)** si **inchiderea
-> (S13)**, si amandoua cer cod, care nu poate incepe inainte de #6 (decizia 30). Prima sarcina la
-> pornire: **spargerea planului pe stories** + nota de executie a primeia (decizia 55).
-Stare: **ETAPA I E PROIECTATA INTEGRAL. ETAPA II E PROIECTATA INTEGRAL — S8 a fost ultima poveste, si
-e gata. Raman testele (S6, S12), diff/review (S13), si O SINGURA VERIFICARE PE COD, in curs. Cod:
-neatins.** Runda 14 a livrat **doua rapoarte** (S8 in detaliu, garda pe aviz), a luat **deciziile
-51-54**, si a **rasturnat doua premise**: una despre garda existenta (era inteleasa pe dos), alta
-despre S10 (Marius a respins intrebarea, nu a ales dintre variante).
-
-**Din partea rundei 14, nimic nu e intr-o stare periculoasa.** Niciun `.vc2` / `.sc2` editat, **niciun
-write-back**, niciun `git_sync.ps1` / `txt2vcx.ps1` rulat, nicio tranzactie deschisa, niciun commit.
-Pe Oracle **numai `SELECT`-uri** (`all_source`, `all_tab_columns`, distributia `VANZARI_CORESP.TIP`),
-pe `MARIUSM_AUTO`. Singurele fisiere scrise sunt in `docs\` — planul, acest handoff, doua rapoarte noi.
-
-**Verificarea S10 s-a terminat** (`docs\cercetare\s10_rederivare_pe_calea_reemiterii.md`, 245 randuri,
-toate cele 6 intrebari) si e integrata in plan.
-
-**Runda 15 (11.08.2026) a inchis asezarea zonei de jos: varianta D, decizia 57, aprobata de Marius.**
-Cu ea, **punctul 17 din lista de deschise cade**. Deciziile 57 si 58 sunt in plan, la „Deciziile lui
-Marius, runda 15"; S1 e actualizat. **Cod: tot neatins.** Singurele scrieri ale rundei: acest handoff,
-plan-ul, si artifactul de asezare. **`docs\mockup_13_variante_asezare_jos.html` a fost scos din
-`docs\`** la cererea lui Marius („doar online, ca sa nu mai intretii 2 variante") — daca il cauti si
-nu-l gasesti, nu s-a pierdut, e la URL-ul din punctul 3.
-
-**Runda 16 (11.08.2026) a inchis punctul 1 din „Urmatorul bloc de lucru", integral.** Cele doua
-rapoarte de discount au fost **citite**, cele trei afirmatii portante ale lor **verificate la sursa**
-(toate rezista), rapoartele **imbinate** intr-unul singur, rezultatul **integrat in plan** (sectiune
-noua **K-bis**, plus S1, decizia 56 si decizia 57), si raspunsul **dat lui Marius**. **Marius a
-raspuns in aceeasi runda: decizia 59 — repartizare proportionala pe cote.** Cu asta **punctul 18
-iese si din cercetare, si din decizie** pe partea principala; cele doua fire mici (campul de motiv,
-retroactivitatea la relistare) **s-au inchis si ele, tot in runda 16 — decizia 61 (camp: da) si
-decizia 62 (restrictia e strict `EsteInEFactura`, fara legatura cu data)**. Runda 16 a mai luat si
-decizia 60 (tipurile 48/49 editabile) si decizia 63 (cerinta noua de audit). **Cod: tot neatins.**
-
-**Tot runda 16 a mai inchis TREI cercetari, toate cu rezultatul integrat in plan si verificat la
-sursa de sesiunea principala** (nu preluat din rapoarte):
-1. **Custodia (48/49)** — `custodie_48_49_stergere_reemitere.md`. Blocantul de la decizia 60 **cade**:
-   nu e nimic de reversat, fiindca emiterea lor nu atinge stocul. **Premisa era gresita** —
-   `scrie_fact_aviz_custodie` serveste `ntip = 4`, nu custodia. Ramane **cerinta** ca S4/S4g/S5 sa
-   pastreze restrictia `IN_STOC = 0`.
-2. **Auditul** — `audit_vanzari_creare_modificare_stergere.md`, proiectat ca **S14**. Patru din sase
-   informatii exista deja; lipseste perechea de modificare; regenerarea ar suprascrie tacit crearea.
-3. **Stocul la stergere** — `stoc_la_stergere_si_reemitere.md`. **Nu e blocant**, dar din alt motiv
-   decat parea: `sterge_factura` nu reverseaza rulajele, o face `PACK_CONTAFIN.STERGE_DIN_RUL` prin
-   `oscrie_in_fisiere`. Deci **tripleta din S9 nu se simplifica** — vezi S9 si sectiunea „Teste".
-
-**Cu asta „ce ramane de proiectat" e din nou gol**, in afara de S14 care tocmai a fost scris. Raman
-testele (S6, S12), diff/review (S13). **Cele trei intrebari mici lasate lui Marius — asezarea
-campului de motiv (decizia 61) si cele doua de la S14 (audit numai pe antet sau si pe linii; se
-afiseaza in interfata sau e doar pentru interogare) — au primit toate raspuns, tot in runda 16:
-decizia 64 (randul se imparte in trei) si decizia 65 (audit in gridul din `frm_facturi`, deci pe
-antet). Nu mai ramane nicio intrebare deschisa pentru Marius.**
-
-> ### REZOLVAT IN RUNDA 16 — rapoartele de discount sunt citite, verificate, imbinate si integrate
-> Caseta ramane ca inventar al rezultatului, **nu mai e o sarcina**. Nu relua nimic din ea.
->
-> | fisier | stare |
-> |---|---|
-> | `docs\cercetare\discount_document_cota_tva.md` | **raportul unic**, 44 KB — rezultatul imbinarii; aici se citeste |
-> | `docs\cercetare\discount_document_cota_tva_b.md` | **ramane pe disc ca sursa** a partii adaugate (3.1-3.3, 2.3, 4.1); nu se sterge, nu se mai citeste separat |
->
-> **Imbinarea E FACUTA.** Structura noua: sectiunile **3.1** (masuratoarea `IIF`/NULL), **3.2**
-> (grupul orfan pe factura scutita), **3.3** (validarea offline cu control negativ), plus completari
-> in 2.3, 4.1 si 5. Cele trei casete de avertizare vechi („sectiunea 3 nu e inchisa", blockquote-ul
-> din capul sectiunii 4, mentiunea din „Raspunsul scurt") au fost **inlocuite cu rezultatul**, nu
-> lasate alaturi de el.
->
-> **Cele trei afirmatii portante au fost verificate la sursa de sesiunea principala. Toate rezista:**
-> - **masuratoarea `IIF`/NULL** — sonda `probe_null.prg` citita si confruntata cu
->   `xmlefactura.prg:226-248`: reproduce fidel acelasi `LEFT JOIN` si aceeasi cheie de grupare;
->   iesirea reala arata **1 grup** (contopire), `IIF()` da ramura falsa, nu `.NULL.`;
-> - **controlul negativ din validare exista si chiar iese cu erori** — `control_stricat.txt` are exact
->   `[BR-CO-13]` + `[BR-CO-15]`, in timp ce restul au `ok`. Deci validatorul discrimineaza;
-> - **identitatea SHA256** — confirmata cu `Get-FileHash`:
->   `3303AFE34BC9E3E84DA9B3527C435DD9B8CB0BC7881D7D2F660A250237E23C64`, XML-ul de pe disc = cel din
->   `TRIMISE`. Iar continutul din `ERORI` e un mesaj de 446 octeti pentru o incarcare **anterioara**,
->   cu alt index, pe `BR-CO-15` + `BR-CL-04`.
->
-> **In plus, o observatie noua a sesiunii principale, care nu exista in niciun raport** (acum in
-> raport, §4.1): fisierul `...2885...` e o factura **integral scutita** cu alocare de document, si are
-> **un singur `TaxSubtotal`, net** (`4410.00 − 539.82 = 3870.18`), fara grup orfan. Cum `expltva` face
-> parte din cheia de grupare, contopirea **dovedeste** ca pseudo-linia purta un `id_jtva_coloana` real
-> — deci era discount **pe linie**. E un **al treilea indiciu independent** ca cele 4 XML-uri de
-> productie sunt discounturi pe linie, si arata **pozitiv forma corecta** pe o factura scutita — exact
-> forma pe care o recomanda reparatia. Rezerva: fisierul e din 02.2024, inferenta presupune traseul de
-> cod neschimbat.
->
-> **Ce raporta al doilea agent, acum verificat si integrat:**
-> - **Ipoteza bazei negative e GRESITA pe factura obisnuita** — masurat headless, nu dedus: `IIF()` din
->   VFP intoarce **ramura falsa, nu `.NULL.`**, cand conditia e nula. Deci pseudo-linia de discount se
->   contopeste corect in grupul cotei maxime, si **sectiunile 3-4 ale raportului principal raman
->   valabile**.
-> - **Se confirma insa pe facturile scutite / taxare inversa / intracomunitare**, unde liniile reale au
->   `scutit = 1` si `expltva` completat iar pseudo-linia are `0` si gol: apare un **`TaxSubtotal` in
->   plus, cu baza negativa si categoria `Z`**, si `agettipcota(1)` devine ambiguu.
-> - **Nu blocheaza factura:** validat cu **DUKIntegrator offline**, 6 scenarii, **inclusiv un control
->   negativ care chiar iese cu erori** (BR-CO-13/BR-CO-15) — fara el cele cinci „ok" n-ar fi dovedit
->   nimic. Trece inclusiv un caz cu `TaxableAmount = -400.00`. Regulile pe categorii (BR-S/E/Z-08) se
->   satisfac trivial, deci **aritmetica inchide si niciun schematron nu prinde greseala de modelare**.
->   Avertisment propriu: jar-ul local e din 2022, validatorul online curent poate fi mai strict.
-> - **`currencyID="RON"` hardcodat e neconformitate reala si activa**, dovedita pe fisier: XML-ul EUR
->   de la VENDING_MASTER e identic pe SHA256 cu cel din `TRIMISE` (deci exact ce a plecat la ANAF) si
->   **a fost acceptat**. Respingerea din `ERORI` e a unei incarcari anterioare, pentru alte reguli.
->   Deci: neconform, dar **fara dovada ca ar cauza respingere**.
-> - **Nu s-a putut proba pe date reale, si o spune explicit:** in baza accesibila sunt **3** facturi cu
->   discount de document (toate cu o singura cota, anterioare eFacturii) si **34** cu cote mixte fara
->   discount — **intersectia e goala**. Cele 4 XML-uri de productie cu alocare de document par a fi
->   discounturi **pe linie** (unul are alocarea pe cota minima, altul are doua alocari — niciuna
->   obtenabila din `Max()` pe o singura pseudo-linie). **Absenta din date nu e dovada.**
-> - **Completare pentru #13, importanta la implementare:** daca se merge pe repartizare proportionala,
->   bucatile de discount trebuie sa primeasca **`id_jtva_coloana` al grupului pe care il reduc**, nu
->   doar cota — cheia de grupare are cinci campuri si `expltva` se completeaza tot prin
->   `id_jtva_coloana`. O implementare care seteaza doar `proc_tva` **lasa grupul orfan exact unde e azi**.
->
-> **Igiena confirmata de agent pe disc, nu din memorie:** `svn status` gol pe `xmlefactura.prg`,
-> `ofacturare_comun.prg`, `oproceduri_facturare.prg` — doar citite; **zero write-back, deci niciun
-> fisier text editat fara conversie in binar**; niciun proces `vfp9.exe` / `sqlplus.exe` / `java.exe`
-> viu; nicio tranzactie deschisa (numai `SELECT` cu `exit`); **datele de test neconsumate** (scenariile
-> au fost XML-uri sintetice in scratchpad); **niciun apel catre ANAF** — validare offline.
->
-> **SINGURUL PUNCT RAMAS NEDOVEDIT PRIN RULARE, si dupa runda 16:** reproducerea **end-to-end prin
-> program** a scenariului *factura scutita / taxare inversa + discount de document*. Tot ce sustine
-> concluzia de acolo e analiza statica plus XML-uri sintetice plus masuratoarea `IIF`/NULL. Nu e
-> blocant pentru nimic acum — **se dovedeste la implementare**, cand exista cod de testat. Artefactele
-> sunt inca pe disc si sunt refolosibile: sondele si XML-urile de scenariu in scratchpad-ul sesiunii
-> `d2dbc0e9-...`, cu apelul exact al validatorului in raport, §3.3 si §4.3.
->
-> **Nu relansa cei doi agenti** — si-au terminat treaba, iar rapoartele lor sunt deja imbinate. Daca
-> apare o intrebare noua pe discount, porneste un agent proaspat **pe raportul unic**, nu pe `_b.md`.
->
-> **Cauza coliziunii, ca sa nu se repete:** `discount-tva-efactura` raportase `idleReason: interrupted`
-> avand pe disc doar scheletul (624 octeti), a fost presupus mort si relansat — **era viu**. Vezi
-> „Capcane de mediu".
-
-> ### ATENTIE — copia de lucru are modificari necomise care NU sunt ale rundei 14
-> **Actualizat in runda 17, masurat, nu copiat.** Ce e necomis **din partea lui #13**: exact trei
-> fisiere, toate in `docs\` — `handoff_13_formular_unificat.md`, `mockup_13_formular_unificat.html`
-> (v9) si `cercetare\mockup_v9_modificari.md` (netracked). Nimic altceva. Editarile rundei 17 in
-> `plan_13` si `plan_index` **apar deja comise**, prinse in commit-ul de curatenie al sesiunii de la
-> #6 — vezi „Capcane de mediu", prima intrare.
->
-> Restul de mai jos e al lui **#6** si/sau zgomot de compilare VFP, si e **inca acolo** (verificat cu
-> `svn status` in runda 17: `changelog_roafacturare.txt`, `roafacturare.PJX` / `.PJT`, `versiune_db.txt`,
-> plus in `COMUN\`: `anaf_efactura`, `comun`, `ofacturare_comun`, `omodificari`, doua ferestre de import
-> si `ofacturare_editare.prg`). Lista originala, pastrata ca atare:
-> ```
-> M  changelog_roafacturare.txt · M roafacturare.PJX / .PJT · M versiune_db.txt
-> M  COMUN\clase\ofacturare_comun.vcx / .vct · M COMUN\clase\omodificari.vcx / .VCT
-> M  COMUN\clase\anaf_efactura · M COMUN\clase\comun · M COMUN\docs\...
-> ?  COMUN\clase\ofacturare_comun.pre_s4butoane.bak.vcx / .vct · ? bash.exe.stackdump
-> ```
-> Astea sunt **ale sesiunii de la #6** (editarea facturii emise) si/sau zgomot de compilare VFP.
-> **Nu le comite, nu le reverta, nu le da `svn revert` in bloc si nu rula `git stash` in `COMUN\`**
-> (`COMUN` e dublu-versionat SVN+git — un `stash` acolo pierde modificari necomise din SVN).
-> `bash.exe.stackdump` din radacina, din `docs\` si din `docs\cercetare\` se pot sterge.
-> **`{06D747B8-0824-488C-8832-DEB9AE661974}.png` din radacina NU e gunoi** — e captura Saga pusa de
-> Marius ca referinta vizuala pentru asezarea formularului (runda 14), citata in plan la S1. Nu o sterge.
-
-## Ce a livrat runda 14
-
-| Livrabil | Ce a stabilit |
-|---|---|
-| `garda_aviz_facturat.md` | **premisa era pe dos** — garda blocheaza deja avizul facturat; golul e pe **proforma** |
-| `s8_incarcare_document.md` | **S8 proiectat integral** — si ambele piese din schita planului sunt gresite |
-| deciziile **51-54** in plan | `TIP = 4`, `do_modifica`, atasamentele, si **rasturnarea lui S10** |
-| S7 rescris in plan | garda nu se reimplementeaza — se **muta momentul** (pre-flight read-only) |
-| S10 rescris in plan | nu garda, ci **eliminarea** re-derivarii; cele 3 intrebari vechi cad |
-| S9 / S11 corectate | pasul de atasamente devine **stergere**, nu `UPDATE` |
-
-## Cele patru rezultate care conteaza (nu se reiau, nu se reargumenteaza)
-
-### 1. Garda pe aviz EXISTA deja — premisa care circula in plan era gresita
-Se credea ca `sterge_factura` blocheaza documentul doar cand are **retururi** peste el. **Nu:** a doua
-garda testeaza `TIP IN (1, 2)`, iar **`TIP = 1` e corespondenta aviz → factura normala, nu retur**
-(`EXPORT:5464-5476`; semantica citita ramura cu ramura din `CASE`-ul lui `finalizeaza_factura`,
-`EXPORT:14818-14839`). Formularea gresita venea din citirea **comentariului**
-`-- verific daca exista facturi sau avize de retur`, in care „de retur" se distribuia si peste
-„facturi". Codul zice altceva. **Deci decizia 50 nu cere nicio garda noua pe aviz.**
-
-**Sunt trei garzi, nu doua, si a treia schimba enuntul deciziei 50:**
-
-| garda | `EXPORT` | ce blocheaza |
-|---|---|---|
-| 1 | 5452-5462 | **factura** cu facturi de retur peste ea (`TIP = 3`) |
-| 2 | 5466-5476 | **aviz** cu factura (`TIP = 1`) sau aviz de retur (`TIP = 2`) peste el |
-| 3 | 5480-5494 | **factura din aviz** ale carei avize-sursa au primit intre timp aviz de retur |
-
-**„Factura din aviz ESTE editabila" nu e neconditionat** — e editabila doar cat timp niciunul dintre
-avizele ei n-a primit aviz de retur.
-
-**Ce lipseste nu e regula, e MOMENTUL:** garda traieste in `sterge_factura`, deci se manifesta ca
-`ORA-20000` **in mijlocul** stergerii din regenerare, dupa completarea formularului si dupa deschiderea
-tranzactiei. S7 are nevoie de **pre-flight read-only** pe exact aceeasi conditie, **fara** reimplementarea
-regulii. Se interogheaza `VANZARI_CORESP`, **nu `VANZARI.FACTURAT`** — `FACTURAT` e derivat, scris si
-resetat, dar **necitit de nicio garda**.
-
-**GOLUL REAL E PE PROFORMA, si a devenit relevant chiar acum, prin decizia 51.**
-`sterge_proforma` (`EXPORT:5610-5635`) **nu are nicio garda** — corpul ei e doua `UPDATE ... SET
-STERS = 1`. E procedura **complet separata**, nu cheama `sterge_factura`, deci garda existenta **nu se
-extinde automat** la `TIP = 4`. O proforma din care s-a emis factura se poate sterge azi fara niciun
-avertisment (calea VFP iese devreme: `ofacturare_comun.vc2:4707-4719`). **Asta e continutul concret al
-punctului 4 din S5c** — nu mai e intrebare de principiu, e garda de scris intr-o procedura fara niciuna.
-
-**Comanda si contractul nu trec prin `VANZARI_CORESP`.** Comanda: `VANZARI.ID_COMANDA` +
-`inchide_comanda`, garda e **in VFP si pe comanda** (`COMUN\clase\ocomenzi.vc2:1806-1807` la modificare,
-`:2065-2066` la stergere). Contract: `VANZARI.ID_CTR` + `CTR_RATE_FACTURI`, nicio garda „are urmasi".
-
-### 2. S8: ambele piese din schita planului sunt gresite, si nu marunt
-1. **`completeaza_setari_document(toFactura, .T.)` copiaza 16 proprietati din ~120**
-   (`COMUN\programe\ofacturare_comun.prg:361-411`) si **niciuna de identitate**. Lipsesc serie, numar,
-   data, scadenta, `text_aditional`, `id_facturare`, `id_ruta`, `tip_saft`, `efactura`,
-   `listare_detaliata`, `dataora_exp`, discountul de document, `discount_evidentiat`, `eproforma`,
-   valuta, cursul.
-2. **`cursor_retur_document(V_COPIERE = 1)` nu umple documentul, ci selectorul-sursa.** Rezultatul intra
-   in `crsarticole` (gridul din stanga); `crsfactura` se creeaza **gol si ramane gol** — comentariul din
-   cod e explicit (`COMUN\programe\ofacturare.prg:338`, `:455-457`). Transferul se face doar prin
-   `do_adauga_tot` → `do_adauga_articol`, care pentru articole gestionabile trece **prin dialogul de
-   alegere din stoc**.
-3. **Nu intoarce `ID_VANZARE_DET` si nici `TAXCODE`** (`PACK_FACTURARE:3949-4054`). Fara
-   `ID_VANZARE_DET`, cheia de linie presupusa de S8b **nu exista**, iar `modifica_explicatie_articol`
-   **devine neapelabila** — primul ei parametru *este* `V_ID_VANZARE_DET` (`PACK_FACTURARE:14511-14519`).
-
-**Recomandarea centrala:** S8 se construieste pe precedentul care face deja exact asta —
-`relisteaza_ofacturare_stoc` (`COMUN\programe\ofacturare_stoc.prg:456-742`), care reconstituie `poDate` +
-cursorul de linii dintr-un document salvat, prin `FACT_VFACTURI` + `FACT_VFACTURI_DETALII` (ambele au
-`ID_VANZARE_DET` si `TAXCODE`).
-
-**Cerinta din S8b e mai blanda decat se credea:** lookup-ul „ultimul delegat / ultima masina" **are deja
-garda** — `Empty(id_delegat) And Empty(id_masina)` (`ferestre_cere_date.vc2:3111`). Riscul e real
-**numai** pe documentele fara delegat si fara masina. Raportul da inventarul complet al celorlalte
-initializari „pentru document nou" de sarit (§2.2), si **sapte corectii** la materialele existente
-(§8.3) — printre care: nu exista coloana `ZI_CURS` pe `VANZARI`; etichetele lui `Ct_clb_altele` sunt
-**sase**, nu cinci (lipsea „Nr. aviz / avize", tip 4 — exact cazul relevant pentru S9).
-
-### 3. S10 nu se decide, se rastoarna — Marius a respins intrebarea
-Cele trei intrebari deschise (blocare vs. avertizare; ramura de aviz; masurarea frecventei) **sunt
-inchise prin respingerea premisei lor**. Formularea lui: *„nu inteleg de ce se schimba valorile fata de
-ce se incarca din factura sursa care se modifica? asta este comportamentul pe care il doresc — modific
-sursa"*. **La reemitere se scriu valorile din formular.** Nu se cere utilizatorului sa confirme o
-schimbare pe care n-a cerut-o.
-
-**VERIFICAT integral** — `s10_rederivare_pe_calea_reemiterii.md`, confirmat pe fisier **si** pe DB.
-Rezultatul e in plan, la S10, cu tabelul complet. Ce conteaza:
-
-- **Ramurile care re-deriva sunt TREI, nu una — raportul rundei 9 gresea.** Contract, **aviz** si
-  comenzi, toate in acelasi `CASE` din `adauga_articol_factura` (`PF:5052-5220`), **inainte** de
-  insertul in temp. Copierea temp → `VANZARI_DETALII` e 1:1, deci nu protejeaza nimic — dauna e amonte.
-- **Ramura AVIZ e cea mai agresiva din tot `CASE`-ul:** `PRET` inlocuit **neconditionat**, fara `DECODE`,
-  fara filtru pe pretul din formular, **fara bloc `EXCEPTION`**, si **fara `A.STERS = 0`** desi coloana
-  exista. Ramura comenzi, in schimb, **cade cu `ORA-01403`** — vizibila, nu tacita.
-- **Comportamentul cerut de decizia 54 exista deja in cod**, pe ramura de exceptie a contractului
-  (`PF:5167-5185`), care pune toate cele cinci pe valorile din formular. Nu e nimic de inventat.
-- **Curat VFP nu se poate, si acum e dovada pozitiva, nu absenta:** semnatura n-are comutator
-  (`PF:4989-5015`), globalele n-au (`PF:126-212`), poarta se decide pe `ntip` (ajunge in `VANZARI.TIP`)
-  si pe `CONTRACTE.OPT_FACTURARE`. `V_ID_POL = NULL` **are exact acelasi defect ca `V_ID_CTR = NULL`**,
-  deja respinsa — notat in plan **tocmai ca sa nu fie redescoperit ca „solutie"**.
-- **Modificarea de pachet e mica:** un `WHEN` nou, primul in `CASE`, cu **acelasi corp ca `ELSE`-ul de
-  azi**, comandat de o variabila noua de pachet („regenerare in curs", implicit `0`). **Acopera toate
-  trei ramurile dintr-o data.** Punctul de resetare exista deja (`initializeaza_date_factura`,
-  `PF:1808-1917`). Inert prin constructie. **DB inainte de EXE.**
-
-**Trei consecinte de acceptat explicit, nu de descoperit la S12** (detaliate in plan): `IN_STOC` ar veni
-din formular — si **S8 nu-l incarca azi** (`ofacturare_editare.prg:302-303` il ia din nomenclator), deci
-flag-ul singur nu ajunge; se **pierde o validare** pe ramura comenzi; `PROC_TVAV` **ramane derivat** pe
-toate ramurile (nu e parametru), deci o modificare legala de cota schimba TVA-ul la reemitere chiar si
-pe `ELSE`.
-
-**Capcana NULL, dedusa nu rulata:** `CTR_ARTICOLE.PRET_UNITAR` NULL (nu `0`) → `DECODE` da **NULL**,
-pretul din formular se pierde complet. In dev nu apare (27 randuri, 0 NULL) — ceea ce nu spune nimic.
-
-**Obstacol pentru S9, gasit in treacat:** **`VVANZARI_ARTICOLE` nu expune `ID_POL` si nici `ID_CTR`** —
-exact cei doi ceruti de `adauga_articol_factura`. Reemiterea **nu poate folosi view-ul ca atare**. E un
-argument in plus pentru varianta (B) de la intrebarea 1 din S8.
-
-### 4. Doi agenti ucisi de limita de sesiune — si amandoi livrasera
-`s8-incarcare` (52 KB, toate cele 8 puncte, cu propria concluzie de final) si `s10-rederivare` (**zero
-octeti — nu apucase sa scrie nimic**). `garda-aviz` a trecut in `idle` fara mesaj final, desi livrase
-integral 13 KB. **A cincea, a sasea si a saptea oara** cand se intampla. **Livrabilul se verifica pe
-disc**, nu se reia munca reflex. Instructiunea „scrie devreme si incremental" e ce a salvat 52 KB.
-
-## Ce asteapta raspunsul lui Marius
-
-> ### CITESTE ASTA INAINTE DE LISTA DE MAI JOS
-> **Marius a raspuns „DA LA TOATE" (decizia 56) — lista lunga care urmeaza NU mai e deschisa.**
-> A acceptat in bloc toate recomandarile, cu doua exceptii pe care le-a scos el explicit. Lista e
-> pastrata mai jos **doar ca inventar al recomandarilor acceptate**, ca sa se stie ce s-a decis si de
-> ce; fiecare punct e scris si la locul lui, in povestea careia ii apartine. **Nu se reintreaba
-> niciunul.** Textul deciziei 56, cu toate punctele: in plan, la deciziile rundei 14.
->
-> **Runda 16 a raspuns la tot ce mai astepta pe Marius — inclusiv ultima alegere ramasa (48/49),
-> cele doua puncte mici de la decizia 59, asezarea campului de motiv (decizia 64) si cele doua
-> intrebari de la S14 (decizia 65). NU MAI RAMANE NICIO INTREBARE DESCHISA PENTRU MARIUS:**
-> 1. **Tipurile 48/49** (facturi de marfa in custodie) — **INCHIS, decizia 60 (runda 16): DA, sunt
->    editabile prin #13.** Formularea lui: *„vreau sa fie posibila editarea si a facturilor in
->    custodie"*. **Verificarea care conditiona executia s-a facut, si blocantul CADE** — regenerarea
->    e sigura pe 48/49, dar din alt motiv decat se banuia: **nu e nimic de reversat**, fiindca
->    emiterea lor nu atinge deloc stocul (articole `IN_STOC = 0` prin constructie). Premisa despre
->    `scrie_fact_aviz_custodie` **era gresita** — vezi „Capcane de mediu". Ramane o **cerinta** pentru
->    S4/S4g/S5: restrictia `IN_STOC = 0` pe 48/49 se pastreaza, altfel invariantul se rupe.
->    Raport: `docs\cercetare\custodie_48_49_stergere_reemitere.md`; enunt complet in plan, decizia 60.
->    *Precizare pastrata din runda 14:* partea despre `frm_facturare_articole2` era o eroare de
->    raport — nu e o varianta paralela de exclus, e **prototipul pe care se construieste formularul
->    unificat** (S1).
-> 2. **Cota si explicatia de TVA a discountului de document** — **INCHIS INTEGRAL.** Repartizarea:
->    decizia 59, runda 16 (proportional pe cote). Campul text optional de motiv: **decizia 61, runda
->    16 — DA, se adauga.** Retroactivitatea la relistare/retrimitere: **decizia 62, runda 16 —
->    restrictia de modificare e strict `EsteInEFactura`, fara legatura cu nicio data.** Ramane deschis
->    doar cum se aseaza campul de motiv pe rand (vezi punctul 3) si un rest separat semnalat la
->    decizia 62 (relistarea unei facturi vechi deja trimise). Vezi deciziile 61-62 in plan.
-> 3. **Alegerea variantei de asezare** A / B / C — **INCHISA in runda 15**, varianta D, decizia 57.
->    **Redeschisa partial de decizia 61, INCHISA la loc de decizia 64 (runda 16): randul de jos se
->    imparte in trei** (incasare, alte date, motivul discountului), ~440 px fiecare la 1366 px, strans.
->    D ramane intr-un etaj.
-> 4. **Cerinta noua de audit** (decizia 63, runda 16) — **PROIECTATA, S14**. Cercetarea s-a terminat
->    (`docs\cercetare\audit_vanzari_creare_modificare_stergere.md`); cele doua puncte ramase (antet
->    vs. si linii; afisare in UI vs. doar interogare) **INCHISE de decizia 65 (runda 16)**: afisarea e
->    in **gridul din `frm_facturi`**, deci pe **antet** — S14 nu mai cere controale noi in formularul
->    unificat, cere coloane in acel grid, si incepe cu inventarul lui (posibil sa existe deja).
-
-**Blocanta: NICIUNA.**
-
-**Din S8 (opt puncte, toate cu recomandare — `s8_incarcare_document.md` §8.2):**
-1. **Canalul de citire a liniilor:** (A) extinderea lui `cursor_retur_document`, (B) procedura noua
-   `cursor_editare_document`, (C) `FACT_VFACTURI_DETALII`. *Recomandare:* **(B)** — (A) schimba
-   comportamentul copierii (`taxcode` ar incepe sa se propage), (C) pierde `ID_POL`, `PRETD` si
-   tratamentul valutar.
-2. **`GESTIONABIL` la editare: din nomenclatorul de azi sau din document?** *Recomandare:* **din
-   document** — un document editat trebuie sa arate cum a fost emis.
-3. **`text_aditional`: se normalizeaza la incarcare (`Chr(170)` → `CR+LF`)?** *Recomandare:* **da**,
-   altfel orice document cu text pe mai multe randuri apare modificat la deschidere. Nota: cele doua
-   rute de scriere salveaza **forme diferite** ale campului — defect preexistent, de semnalat separat.
-4. **`zi_curs` la editare: ascuns sau afisat gol?** *Recomandare:* **ascuns** (precedent: tipurile 8/9).
-   Mica abatere de la decizia 5, semnalata ca atare.
-5. **`poDate.lEditare`: proprietate pe `oDateFactura` sau parametru?** *Recomandare:* **proprietate** —
-   sunt cel putin patru locuri care au nevoie de semnal, si `lCopiere` e deja acolo cu acelasi rol.
-6. **`id_ruta` — proprietate noua pe `oDateFactura`?** *Recomandare:* **da**; fara ea S8c nu poate
-   implementa unul din cei 14 parametri.
-7. **Tipurile 48/49 si `frm_facturare_articole2` intra in etapa II?** *Recomandare:* **nu acum**, dar se
-   declara explicit ca neacoperite.
-8. **Defectul de prefixare `text_aditional` la `Init` pentru contracte** — se repara in #13 sau separat?
-   *Recomandare:* **se ocoleste** prin `lEditare` si **se semnaleaza separat**.
-
-**Din S5c (patru puncte ramase — punctul 1, `TIP = 4`, e INCHIS prin decizia 51):**
-9. **Apel pe starea de sesiune a pachetului vs. procedura noua cu parametri expliciti.** *Recomandare:*
-   varianta simpla (zero cod Oracle nou), **cu conditia** verificata la implementare ca niciun apel
-   Oracle intercalat nu reseteaza starea.
-10. **Aceeasi proforma poate fi copiata de N ori.** *Recomandare:* daca deranjeaza — avertisment, **nu**
-    blocare.
-11. **Garda simetrica la stergerea proformei** — **nu mai e intrebare de principiu**: `sterge_proforma`
-    n-are nicio garda, deci e **cod nou**. Vezi rezultatul 1.
-12. **Afisarea „provine din proforma X"** — gratis din legatura scrisa, la nivel de document.
-
-**Din S4g (patru puncte):**
-13. **Numarul codului de eroare nou** (`FACT-0xx`), distinct de `FACT-024`.
-14. **`CU_TVA = 1` hardcodat** — are efect **masurat** prin `nproc_tva_max`. **De confirmat.**
-15. **Decizia 36** — numele cheii de optiune de firma pentru `SCD` (`FACT_SCD_ARTFPRET` propus).
-16. **Trasabilitatea `CONT_VENIT` pe `VANZARI_DETALII`** — optionala pentru functionare.
-
-**Deschise la sfarsitul rundei 14:**
-17. ~~**Asezarea zonei de jos**~~ — **INCHIS. Marius a ales varianta D (decizia 57), runda 15.**
-    Enuntul complet, cele patru consecinte de executie si singurul punct lasat deschis sunt **in plan**,
-    la „Deciziile lui Marius, runda 15", si rezumate la S1. Pe scurt: banda de totaluri din C;
-    **incasarea si alte date sunt sectiuni colapsabile in formular, una langa alta pe acelasi rand**,
-    nu dialoguri; **nu exista bara de comenzi jos** — `but_renunt` / `but_termin` raman in banda de
-    titlu. **Nu se reintreaba, nu se reargumenteaza, A / B / C au cazut.**
-    Doua lucruri de dus mai departe la implementare, ambele deja scrise in plan: **validarea incasarii
-    se muta in `Termina`** (de prins in S9), si **„renunt doar la incasare" dispare** — acceptat
-    explicit de Marius dupa ce i s-a spus.
-18. **Cota si explicatia de TVA a discountului de DOCUMENT** — **cercetarea E TERMINATA (runda 16)**,
-    raportul unic e `docs\cercetare\discount_document_cota_tva.md`, rezultatul e in plan la
-    **K-bis**. **INCHIS INTEGRAL, tot in runda 16:** repartizarea — **decizia 59**, proportional pe
-    cote, fara sa se ceara cota de la utilizator; campul text optional de motiv — **decizia 61**, da,
-    se adauga (`AllowanceChargeReason`, `ReasonCode` ramane `95`, stocare noua pe `VANZARI`, control
-    nou in formular); retroactivitatea la relistare/retrimitere — **decizia 62**, restrictia de
-    modificare e strict `EsteInEFactura`, fara legatura cu nicio data (ramane insa deschis, separat,
-    cazul relistarii unei facturi vechi deja trimise — vezi decizia 62 in plan). **Singurul rest
-    deschis: asezarea campului de motiv pe rand** (decizia 61 redeschide punctul de la decizia 57).
-    Ce s-a stabilit prin cercetare, integral valabil:
-    - **Cota discountului de document = cota MAXIMA de pe factura**, si e o regula implicita pe care
-      n-o alege nimeni. `Calculate Max(proc_tvav)` (`oproceduri_facturare.prg:1387`); discountul intra
-      ca **pseudo-linie** printr-un rand-sentinela `Replicate('Z',20)`
-      (`ofacturare_comun.prg:1891-1896`). In XML, `AllowanceChargeReason="Discount"` si
-      `ReasonCode=95` sunt **hardcodate** (`xmlefactura.prg:774-776`), la fel `currencyID="RON"`
-      (`:778`).
-    - **Regula e implementata de DOUA ori**: si in VFP (mai sus), si in PL/SQL —
-      `recalculeaza_totaluri_vanzari`, `MAX(ROUND(discount*(a1.proc_tvav-1),...)) as DISC_TVA_RON`
-      (`ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:16081-16092`), scris in `VANZARI.DISCOUNT_TVA`
-      (`:16214-16227`). **Pentru #13 inseamna doua locuri de schimbat, nu unul.**
-    - **Ipoteza „TaxSubtotal cu baza negativa" — TRANSATA, cu verdict impartit.** Se temea ca
-      pseudo-linia, avand `id_jtva_coloana = 0`, iese din LEFT JOIN cu `coloana_jv` NULL si isi
-      formeaza grup propriu. **Infirmata pe factura obisnuita** — masurat, nu dedus: `IIF()` din VFP
-      intoarce **ramura falsa, nu `.NULL.`**, deci pseudo-linia se contopeste corect si sectiunile
-      3-4 ale raportului raman valabile. **Confirmata pe facturile scutite / taxare inversa /
-      intracomunitare**, unde liniile reale au `scutit = 1` si `expltva` completat iar pseudo-linia
-      are `0` si gol: iese un `TaxSubtotal` orfan cu baza negativa si categoria `Z`, iar
-      `agettipcota(1)` devine ambiguu intre `E` si `Z`.
-    - **Corectie la o presupunere care circula in handoff-ul precedent: ANAF NU respinge forma asta.**
-      Validat offline, 6 scenarii, cu control negativ care chiar iese cu erori. Aritmetica inchide
-      (`BR-S/E/Z-08` se satisfac trivial), deci **niciun schematron nu prinde greseala de modelare**.
-      Ramane eroare **tacuta**, ca si defectul de atribuire fiscala. Rezerva: validatorul local e din
-      2022, cel online al ANAF **nu a fost apelat**.
-    - **`currencyID="RON"` hardcodat e neconformitate reala si activa**, dar dovedit pe fisier ca
-      **a fost acceptat** de ANAF (identitate SHA256 cu XML-ul din `TRIMISE`). Neconform, fara dovada
-      ca ar cauza respingere.
-    - **Nu s-a putut proba pe date reale:** 3 facturi cu discount de document (toate cu o singura
-      cota) si 34 cu cote mixte fara discount — **intersectia e goala**. Absenta din date nu e dovada.
-    - **Completare importanta la implementare:** bucatile de discount trebuie sa primeasca
-      **`id_jtva_coloana` al grupului pe care il reduc**, nu doar cota — o implementare care seteaza
-      doar `proc_tva` **lasa grupul orfan exact unde e azi**. **eFactura nu cere nicio modificare** —
-      `xmlefactura.prg:758-792` grupeaza deja pe cota.
-19. Cele **trei consecinte** ale deciziei 54 (`IN_STOC`, validarea pierduta pe comenzi, `PROC_TVAV`
-    derivat) — ultima poate cere decizie separata.
-
-**Si defectul `lnTip` din `do_copiaza`** (runda 13) — de decis daca se repara in #6 (fisierul e al lui)
-sau separat, dupa.
-
-## Ce ramane de proiectat
-
-**Nu mai e „nimic" — runda 16 a adaugat doua povesti noi, ambele cu cercetare in curs, nu inchise:**
-**Actualizare runda 17: punctele 1 si 4 de mai jos sunt FACUTE. Lista e goala pe partea de proiectare
-— raman doar 3 (testele si inchiderea), care cer cod.**
-
-1. ~~**Golul `IN_STOC` din S8**~~ — **FACUT in runda 17**, in nota de executie a lui S8. A lasat in
-   urma o **alegere de proiectare** (de unde se reconstituie valoarea istorica), nu o sarcina.
-2. **Canalul care scrie `serie_act` / `numar_act` / `data_act` / `data_scad` / `id_ruta` / `tip_saft` /
-   `efactura`** pe documentul reemis — **nu apar in `scrie_factura2`**. Se inchide in S9, la implementare.
-3. `S6` / `S12` (teste pe flux real) si `S13` (diff, review, changelog) raman la final.
-4. ~~**Mockup-ul e la v8**~~ — **FACUT in runda 17: e la v9.1**, cu varianta D, randul de jos in doua
-   si motivul discountului in banda de totaluri (deciziile 57 + 66), plus deciziile
-   52/53/54/59/60/61/62/63+65 in text. **Republicat** pe URL-ul existent (vezi punctul 5 din
-   „Urmatorul bloc de lucru") — decizia 33 e consumata, URL-ul e la zi.
-5. **Verificarea custodiei (decizia 60, runda 16) — TERMINATA.** Verdict:
-   `scrie_fact_aviz_custodie` nu are legatura cu 48/49 (serveste `ntip = 4`); emiterea 48/49 nu
-   atinge stocul (`cursor_articole_k`, `IN_STOC = 0`); `sterge_factura` n-are ce reversa. **Blocantul
-   CADE — regenerarea e sigura pe 48/49.** Ramane o rezerva neverificata exhaustiv (invariantul
-   `IN_STOC = 0` pe 48/49) si o cerinta noua pentru S4/S4g/S5 sa nu-l rupa. Detaliu si citari: plan,
-   decizia 60; raport `docs\cercetare\custodie_48_49_stergere_reemitere.md`.
-6. **Cerinta noua de audit (decizia 63, runda 16) — PROIECTATA, S14.** Cercetarea s-a terminat
-   (`docs\cercetare\audit_vanzari_creare_modificare_stergere.md`): patru din sase informatii exista
-   deja pe `VANZARI` (`ID_UTIL`/`DATAORA` creare, `ID_UTILS`/`DATAORAS` stergere, scrise consecvent);
-   lipseste complet perechea de modificare; regenerarea din S9 ar suprascrie tacit perechea de creare
-   daca nu se transporta explicit, la fel ca `ID_FACT`. S14 are verdictul complet, recomandarea
-   (pereche noua `ID_UTILM`/`DATAORAM`, transport la S9, migrare DB inainte de EXE). **Decizia 65
-   (runda 16) a inchis cele doua puncte ramase** (antet vs. si linii; afisare in UI sau doar
-   interogare): afisarea e in **gridul din `frm_facturi`**, deci pe **antet** — S14 incepe cu
-   inventarul acelui grid (posibil sa existe deja coloane de audit), inainte de a adauga ce lipseste.
-
-**Nu mai intreba** — inchise in rundele 6-15: tot ce listeaza handoff-ul rundei 13, plus deciziile 51-54,
-cele patru intrebari ale rundei 14 puse lui Marius direct, **si asezarea zonei de jos (decizia 57)**.
-
-### Deciziile 51-54 (Marius, runda 14) — luate, nu de reluat
-51. **`TIP = 4` in `VANZARI_CORESP` = „factura scrisa dintr-o proforma".** Confirmat explicit dupa ce i
-    s-a explicat ce inseamna `1/2/3`: `TIP` e **natura legaturii parinte-copil**, nu tipul documentului
-    (`1` = aviz → factura, `2` = aviz → aviz de retur, `3` = factura → factura de retur). `4` e in
-    aceeasi familie cu `1`. **Alocarea e ireversibila** odata cu primele date de productie — acceptat.
-52. **`do_modifica` ramane activ pentru multi-selectie.** Formularul unificat preia cazul cu un singur
-    document. Consecinta: **S2 nu poate desfiinta nici aceasta ruta**, nu doar alegerea de la decizia 49.
-53. **Atasamentul PDF se sterge la reemitere** — nici remigrare, nici marcaj „versiune inlocuita".
-    Pasul din S9 devine **stergere** (`STERS = 1`), nu `UPDATE`. **Consecinta i-a fost spusa explicit si
-    a acceptat-o:** urma PDF-ului efectiv trimis clientului dispare din sistem.
-54. **La reemitere se scriu valorile din formular, nu se reciteste sursa.** Rastoarna S10 — vezi
-    rezultatul 3. Avertizarea + confirmarea sunt **respinse**.
-55. **Metoda de executie e obligatorie, si e scrisa in plan** (sectiunea **„Metoda de executie"**,
-    imediat inainte de Etapa I). Trei cerinte: (a) la implementare planul **se sparge pe stories**,
-    fiecare story fiind o livrare de sine statatoare, cu nota de executie proprie scrisa **inainte** de
-    prima linie de cod; (b) **se testeaza la fiecare pas**, nu doar la S6 / S12 — headless pentru
-    logica, UI vizibil unde sunt griduri, cu rezultatul asteptat declarat **inainte** de rulare, si
-    testele se pastreaza pentru suita finala; (c) **fiecare story trece prin code review dupa
-    implementare si dupa teste, inainte de commit**, facut de **un agent care nu a scris codul**.
-    Ordinea fixa: implementare → teste → diff in `docs\` → review → aprobarea lui Marius → commit.
-    **S13 nu mai e momentul review-ului**, ci al inchiderii (review de ansamblu, suita completa,
-    changelog, documentatie).
-
-### Deciziile 57-58 (Marius, runda 15) — luate, nu de reluat
-57. **Asezarea zonei de jos = varianta D.** Banda de totaluri din C; **incasare si alte date ca
-    sectiuni colapsabile in formular, una langa alta pe acelasi rand**, nu dialoguri; **fara bara de
-    comenzi jos** — `but_renunt` / `but_termin` raman in banda de titlu. A / B / C cad. Enuntul
-    complet, cele patru consecinte si punctul lasat deschis: **in plan**, la deciziile rundei 15.
-58. **Mockup-ul asezarii ramane doar online**, fara copie in `docs\`. Vezi „Urmatorul bloc de lucru",
-    punctul 3, pentru procedura de modificare.
-
-### Decizia 59 (Marius, runda 16) — luata, nu de reluat
-59. **Discountul de DOCUMENT se repartizeaza proportional pe cote**, nu pe cota maxima. Doua locuri
-    de schimbat impreuna (`ofacturare_comun.prg` si `recalculeaza_totaluri_vanzari`), plus
-    `id_jtva_coloana` pe fiecare bucata si diferenta de rotunjire pe ultima cota. Raman deschise
-    campul de motiv si retroactivitatea. Enuntul complet: **in plan**, la „Decizia 59".
-
-### Deciziile 60-65 (Marius, runda 16) — luate, nu de reluat
-60. **Tipurile 48/49 (custodie) SUNT editabile prin #13.** Inchide punctul (a) ramas deschis din
-    decizia 56. **Verificarea s-a facut: blocantul cade**, regenerarea e sigura pe 48/49 fiindca
-    emiterea lor nu atinge stocul (`cursor_articole_k` filtreaza `IN_STOC = 0`), deci n-are ce reversa.
-    Ramane **cerinta** ca S4/S4g/S5 sa pastreze acea restrictie. Enuntul complet, cu ramificatia pentru
-    `ct_clb_altele` in S8: **in plan**, la „Decizia 60".
-61. **Discountul de document primeste un camp text optional de motiv** (`AllowanceChargeReason`,
-    `ReasonCode` ramane `95`) — cere stocare noua pe `VANZARI` si un control nou in formular.
-    **Redeschide intrebarea de asezare de la decizia 57**: randul se imparte in trei sau campul
-    coboara pe rand propriu — **inchisa la loc de decizia 64**. Enuntul complet: **in plan**, la
-    „Decizia 61".
-62. **Restrictia de modificare e strict „nu a fost trimisa in eFactura"** (garda `EsteInEFactura`,
-    deja in S7) — **retroactivitatea nu mai e o intrebare**, nu se leaga de nicio data. Ramane
-    semnalat, nedecis, un rest separat: relistarea (nu editarea) unei facturi vechi deja trimise ar
-    produce N randuri de discount dupa decizia 59, deci hartie diferita de originalul trimis. Enuntul
-    complet: **in plan**, la „Decizia 62".
-63. **Cerinta noua de audit**: data + utilizator pentru creare, modificare si stergere pe documente.
-    **Cercetare TERMINATA, proiectata ca S14.** Patru din sase informatii exista deja pe `VANZARI`
-    (creare, stergere); lipseste perechea de modificare; regenerarea (S9) ar rescrie tacut perechea
-    de creare fara un transport explicit, la fel cum era riscul pentru `ID_FACT` inainte de decizia
-    care l-a pastrat. Locul de afisare, ramas deschis aici, se inchide la decizia 65. Enuntul
-    complet: **in plan**, la „Decizia 63" si la S14.
-64. ~~**Asezarea campului de motiv: randul se imparte in trei.**~~ **RASTURNATA DE DECIZIA 66
-    (runda 17). Nu mai e in vigoare** — se pastreaza doar ca istorie, ca sa se stie ca varianta „a
-    treia sectiune jos" a fost incercata si respinsa dupa ce Marius a vazut-o in mockup. Ce e in
-    vigoare: **motivul sta in banda de totaluri, langa discount; randul de jos are doua sectiuni.**
-65. **Auditul (decizia 63) se afiseaza in gridul din `frm_facturi`, nu in formularul facturii.**
-    Confirma continutul de la decizia 63 (trei perechi data + utilizator: adaugat, modificat,
-    sters). Inchide ambele puncte ramase de la S14: e pe **antet** (gridul listeaza documente) si
-    **se afiseaza**, in acel grid — nu cere controale noi in formularul unificat. **Prim pas al
-    implementarii S14: inventarul gridului din `frm_facturi`**, posibil sa existe deja coloane de
-    audit. Enuntul complet: **in plan**, la „Decizia 65" si la S14.
-
-### Decizia 66 (Marius, runda 17) — luata, nu de reluat. RASTOARNA DECIZIA 64.
-
-66. **Motivul discountului sta LANGA DISCOUNT, in banda de totaluri** — *„motiv discount vreau sa fie
-    langa discount, nu a treia coloana"*. **Rastoarna decizia 64**: randul de jos ramane cu **doua**
-    sectiuni (incasare, alte date), fiecare pe jumatate de latime, adica exact decizia 57 punctul 2.
-    Proiectarea a adaugat o regula care nu i-a fost ceruta explicit si care se poate schimba dintr-o
-    linie: **campul e activ doar cand discountul de document nu e zero**. Consecinta de asezare,
-    acceptata: banda de totaluri devine plina si la latimi mici se rupe pe doua randuri. Enuntul
-    complet: **in plan**, la „Decizia 66".
-
-## Interzis
-
-- **Nu se atinge `COMUN\clase\ofacturare_comun.vc2` si nici `COMUN\programe\ofacturare_editare.prg`** —
-  perimetrul lui #6 cat timp #6 e in lucru. **Include si defectul `lnTip`.**
-  **`COMUN\programe\ofacturare.prg` NU e in acest perimetru.**
-- **Nu se ruleaza `git_sync.ps1`** cat timp sesiunea de la #6 lucreaza.
-- **Nu se propune „avertizare + confirmare" la S10** — respinsa de decizia 54.
-- **Nu se foloseste `oscrie_in_fisiere` ca ruta de contare in #13** (decizia 35). Exceptie: piciorul de
-  **stergere** din S9.
-- **Nu se proiecteaza retragerea fluxului lui #6** (decizia 38).
-- **Reteta in 4 pasi din J-quater e ABANDONATA** (decizia 34).
-- **Nu se proiecteaza pe numere masurate in Dev** (decizia 31).
-- **Nu se reargumenteaza deciziile 22, 29, 39, 43, 49, 50, 57** — perimetrul lor e inchis.
-- **Nu se mai propune dialog modal pentru incasare / alte date** si **nu se readuce bara de comenzi
-  jos** — respinse de decizia 57. Nici A / B / C nu se mai propun.
-- **Nu se mai propune motivul discountului ca sectiune separata jos** — incercat in v9 si **respins de
-  decizia 66**. Sta in banda de totaluri, langa discount.
-- Fara commit din proprie initiativa: diff-ul se livreaza intai ca fisier in `docs\`.
-- **Nu se incepe implementarea pe cod** — #13 porneste dupa terminarea lui #6 (decizia 30).
-
-## Capcane de mediu
-
-- **NOU (runda 17), si e cea care conteaza pentru oricine lucreaza acum: SESIUNEA DE LA #6 COMITE IN
-  ACEEASI COPIE DE LUCRU, IN PARALEL, INCLUSIV IN `docs\`.** In timpul rundei 17 a dat commit-ul
-  `b5a7108` („cercetarile comune trec in COMUN, reziduul #6 dispare") — o curatenie care a **rescris 39
-  de fisiere din `docs\`**, a mutat 14 cercetari in `COMUN\docs\cercetare\` si a **sters 20 de rapoarte**.
-  Doua consecinte de stiut:
-  1. **A sters si doua fisiere ale lui #13**, incadrate gresit drept reziduu de #6:
-     `mockup_v7_modificari.md` si `mockup_v8_modificari.md`. **Nu sunt pierdute** —
-     `git show d9f5ca4:docs/cercetare/mockup_v8_modificari.md` le scoate. Nu s-au restaurat: erau
-     nereferite si stergerea a fost o curatenie aprobata a altei sesiuni; **daca le vrei inapoi, e o
-     comanda, dar se cere lui Marius intai**.
-  2. **Editarile rundei 17 in plan au fost prinse in acel commit**, nu de mine — `git status` arata
-     `plan_13` si `plan_index` **curate**, desi le-am scris eu. Nu e o dovada ca n-am scris nimic.
-     **Verifica pe continut (`grep`), nu pe `git status`.** Toate trei editarile au supravietuit,
-     confirmat.
-  **Regula practica:** cat timp #6 lucreaza, orice fisier din `docs\` poate fi rescris sau sters sub
-  tine intre doua apeluri. Editarile se **reverifica pe continut dupa** ce le-ai facut, iar fisierele
-  proprii nu se presupun stabile.
-- **Ruda punctului de mai sus, platita tot in runda 17: un `grep` care nu gaseste nu dovedeste ca
-  lipseste.** Am „constatat" ca decizia 62 lipseste din mockup si eram gata s-o adaug — era acolo,
-  rupta pe doua randuri (`decizia\n62`), iar eu cautasem si forma feminina („trimisa"), nu pe cea din
-  text („trimis"). **Inainte sa declari ceva lipsa dintr-un fisier, cauta termenul cel mai scurt si
-  neflexionat**, si abia apoi forma completa.
-- **NOU (runda 16): `PACK_CONTAFIN` are DOUA copii pe schema** — `owner = ACN` si
-  `owner = MARIUSM_AUTO`. O interogare pe `all_source` **fara filtru pe `owner`** intoarce cele doua
-  corpuri intercalate, adica **text corupt** care pare cod real. Filtreaza mereu pe owner, sau
-  citeste din exportul de pe disc (`D:\ROA\DATABASE\SCRIPTURI_CLAR\...`).
-- **NOU (runda 16): `git_sync.ps1` a fost rulat din greseala de un subagent**, desi e interzis cat
-  timp sesiunea de la #6 lucreaza. **Paguba: zero** — verificat pe mtime, singurul fisier atins e
-  `COMUN\clase\ofacturare_comun.pre_s4butoane.bak.vc2`, text generat pentru un **binar de backup
-  netracked**; niciun `.vc2` / `.sc2` de lucru n-a fost rescris, niciun write-back, niciun commit.
-  **Lectia pentru briefing:** interdictiile trebuie puse **la inceputul** promptului, nu la mijloc —
-  agentul a inceput sa lucreze inainte sa le citeasca pe toate.
-- **NOU, si e cea mai scumpa a rundei: o garda intreaga a fost inteleasa pe dos pentru ca s-a citit
-  COMENTARIUL, nu codul.** `-- verific daca exista facturi sau avize de retur` a fost citit ca „facturi
-  de retur sau avize de retur"; codul testa `TIP IN (1,2)`, adica si facturarea normala. Premisa a
-  circulat prin plan mai multe runde. **Comentariul nu e sursa de adevar; `IF`-ul e.**
-- **Ruda buna a punctului de mai sus: numele unei proceduri nu e sursa de adevar.**
-  `scrie_fact_aviz_custodie` suna ca si cum ar servi facturile de custodie (48/49) — de fapt are un
-  singur apel in tot pachetul, pe ramura `ntip <> 4` (`PACK:7472`, `:7521`), deci serveste `ntip = 4`
-  (factura din avize). Premisa gresita a circulat pana in decizia 60. Se verifica **apelantul si
-  garda**, nu numele.
-- **NOU: numerotarea difera intre exportul `PACK_FACTURARE` si corpul din `all_source`.**
-  `sterge_factura` incepe la `EXPORT:5432` si la `DB PACK_FACTURARE:4192`. **Nu exista offset
-  constant** — nici intre export si rapoarte, nici intre export si DB. Textul insa e identic.
-- **Cifrele si multimile de valori se citesc din `Do Case`-ul real, nu din raportul precedent.** A doua
-  oara consecutiv cand asta salveaza ceva.
-- **Un agent poate trece in `idle` fara mesaj final, desi a livrat integral** — si poate fi **ucis de
-  limita de sesiune** dupa ce a livrat. S-a intamplat de **opt** ori pana acum, ultima oara chiar la
-  `s10-rederivare-2`, care a raportat `idle` la o ora dupa ce terminase raportul. **Livrabilul se
-  verifica pe disc** (dimensiune, sectiuni, ultimele randuri, marcaje `(in lucru)` ramase), nu se reia
-  munca reflex.
-- **NOU, si a costat o coliziune: `idleReason: interrupted` NU dovedeste ca agentul a murit.**
-  `discount-tva-efactura` a raportat `interrupted` (de doua ori) avand pe disc doar scheletul de 624
-  octeti. A fost presupus mort si relansat — **era viu**, si a ajuns la 13,5 KB. Al doilea agent era la
-  un pas de un `Write` peste raportul viu; a scapat doar pentru ca harness-ul a prins ca fisierul se
-  schimbase de la citire. **Inainte de relansare se compara mtime-ul livrabilului cu ora curenta**, nu
-  doar dimensiunea — un fisier atins acum cateva minute inseamna scriitor viu. **Daca s-a produs deja
-  coliziunea:** al doilea agent scrie in fisier separat (`<nume>_b.md`) si se imbina manual — nu `Edit`
-  tintit pe sectiunile ramase (primul le scrie oricum), si nu predare, care arunca firul deja inceput.
-- **Cere din promptul initial: raport scris pe disc devreme si incremental.** In runda 14 asta a salvat
-  52 KB de la un agent ucis; celalalt, care n-apucase sa scrie, a pierdut tot.
-- **Limita de sesiune poate ucide agentii instant, la pornire.** **Sonda ieftina**: relanseaza intai
-  agentul cel mai mic.
-- **`vfp_symbols.ps1` se cheama din unealta PowerShell, nu din Bash** — caile cu `\` sunt mancate de
-  Bash. Indexeaza si `.bak`-urile; liniile se confirma pe fisierul real.
-- **Pentru sqlplus foloseste unealta PowerShell**, nu Bash:
-  `& 'D:\ROA\instantclient_19_18\sqlplus.exe' -L -S 'MARIUSM_AUTO/ROMFASTSOFT@ROA_CENTRAL' '@C:\cale\x.sql'`
-  SQL-ul **in fisier ASCII**, cu `set linesize 32767` / `set pagesize 0` / `set feedback off` si `exit`.
-- **`cd` intr-un apel de shell persista intre apeluri.** Verifica fisierele pe **cale absoluta**.
-- **Grep de la radacina nu vede `COMUN\`** (gitignore); se da `path` explicit.
-- **`grep -o -E '.{N}X.{N}'` rateaza tacut potrivirile de la capete de rand.** Intai termenul simplu.
-- **`ID_UTILS` / `DATAORAS` pe `VANZARI_DETALII` nu inseamna „sters de/la".** Editarea de linie a lui
-  #6 le scrie si pe randuri **nesterse** — `ofacturare_editare.prg:501-505` (pe rand viu, `sters = 0`)
-  si `:522-525` (pe rand proaspat inserat). Un raport de audit trebuie sa puna si `STERS` in conditie,
-  altfel liniile doar atinse la editare apar gresit drept sterse.
-- **Cautarea unui literal SQL trebuie sa tina cont de spatii** (`-10000` nu gaseste `rownum - 10000`).
-- **Un singur scriitor pe fisier.** Integrarea in plan a facut-o sesiunea principala, secvential.
-- **Verifica afirmatiile portante ale rapoartelor, nu le lua pe incredere.** Runda 14 a infirmat doua
-  premise portante din plan (garda pe aviz; ambele piese ale schitei S8) si a corectat sapte afirmatii
-  din materialele existente.
-- **Export pachet:** `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql`
-  (17217 linii). Marcajul `versiune_db.txt` = `2026_08_09_02`, deci exportul e aplicat pe DB.
-
-## Teste
-
-**Caz adaugat de runda 16, si e cel mai important dintre toate:** **reemiterea unei facturi cu
-articole gestionabile lasa stocul NESCHIMBAT.** E proba directa ca piciorul de stergere din S9 a
-trecut chiar prin `oscrie_in_fisiere` — daca cineva „simplifica" tripleta la un apel direct de
-`sterge_factura`, rulajele raman in picioare si gestiunea se descarca **de doua ori**, fara niciun
-mesaj. Testul se face pe stocul agregat inainte / dupa, nu pe inspectia codului.
-
-**Caz adaugat de runda 17, pereche cu cel de mai sus:** un document emis cu un articol caruia i s-a
-schimbat intre timp `IN_STOC` in nomenclator, deschis in formular, **poarta valoarea de la emitere**,
-nu pe cea de azi; iar reemiterea lui lasa **stocul agregat neschimbat**. Masurat inainte / dupa, nu
-prin inspectia codului. E criteriul care demonstreaza ca golul `IN_STOC` din S8 chiar s-a inchis.
-
-**Nu s-a rulat nimic.** Nu exista inca cod de testat (decizia 30). Testele minime raman in
-`canal_cont_venit_fara_politica.md` §6, plus cazurile rundei 11 (aviz cu articol fara politica → `SCD`
-ramane `461` / `418`; `ntip = 46` → `scrie_nota` nu se cheama), probele de paritate ale rundei 12
-(acelasi rezultat de inchidere cu si fara linii libere; factura emisa dupa du-te-vino prin proforma
-descarca stocul) si cele ale rundei 13 (factura din proforma descarca gestiunea si are rand `TIP = 4`,
-iar proforma **nu** e marcata `FACTURAT`; linie cu `id_pol` si `cont_venit` simultan → eroare).
-**Runda 14 adauga:** reemiterea unui document de contract **dupa** ce pretul din contract s-a schimbat
-reproduce **pretul din formular**, nu pe cel din contract (decizia 54); si stergerea unei proforme din
-care s-a emis factura **e refuzata** (garda noua, punctul 11).
-**Runda 16 adauga (decizia 60, verificare terminata):** pe un document de tip 48/49 (custodie) **nu
-se poate adauga un articol gestionabil** (`IN_STOC <> 0`), nici prin cautarea pe server in linie
-(S4), nici prin „Alege din nomenclator…" (S4g) — criteriu de test, nu presupunere; raport
-`docs\cercetare\custodie_48_49_stergere_reemitere.md`.
-`s8_incarcare_document.md` §7 da criteriul „gata cand" al lui S8 in forma testabila, pe fiecare tip de
-sursa.
-
-## Urmatorul bloc de lucru
-
-1. ~~Citeste cele doua rapoarte de discount si imbina-le~~ — **FACUT INTEGRAL in runda 16**, toti cei
-   cinci pasi (a)-(e): citite, cele trei afirmatii portante verificate la sursa, imbinate in raportul
-   unic, integrate in plan (**K-bis** + S1 + deciziile 56 si 57), si raspunsul dat lui Marius. **Nu se
-   reia nimic din el.** Ce a ramas in urma lui e o **decizie a lui Marius**, nu o sarcina de executie:
-   se implementeaza sau nu repartizarea proportionala pe cote, si vrea sau nu un camp de motiv.
-   *Cand vine vorba de asta, atentie la formulare:* concluzia s-a intors de doua ori pe drum — cota
-   maxima e regula reala, dar defectul e **tacut**, nu blocheaza factura, si nu s-a putut proba pe
-   date reale.
-2. **NU mai cere raspunsuri pe lista de 19 puncte** — sunt inchise prin decizia 56 („da la toate").
-   Tipurile 48/49 s-au raspuns si ele — **decizia 60, runda 16: da, editabile**. Nimic de reintrebat
-   din lista veche.
-3. ~~Confirmarea variantei D~~ — **DATA (decizia 57).** Cercetarea a confirmat ca discountul **NU
-   cere cota de la utilizator**, deci **a treia sectiune „grea" (cota + explicatie proprii) nu mai e
-   in discutie**. **Varianta minimala s-a materializat — decizia 61, runda 16: Marius vrea campul
-   text optional de motiv.** Intrebarea de asezare e deci **activa, nu mai e ipotetica**: campul fie
-   imparte randul in trei (~440 px fiecare la 1366 px, strans), fie coboara pe rand propriu si D
-   redevine doua etaje. **De decis de Marius**, nu la implementare. Pagina:
-   https://claude.ai/code/artifact/dfc70d38-856f-48fd-b6af-3da78e9da4f7
-   > **ATENTIE — mockup-ul asezarii NU MAI ARE COPIE PE DISC.** Cerinta lui Marius, runda 15: „doar
-   > online, ca sa nu mai intretii 2 variante". `docs\mockup_13_variante_asezare_jos.html` **a fost
-   > mutat afara din `docs\`**; **artifactul e singura sursa de adevar**. Ca sa-l modifici:
-   > **intai `WebFetch` pe URL** ca sa recuperezi HTML-ul, scrie-l intr-un fisier de lucru **in
-   > scratchpad, nu in `docs\`**, editeaza, apoi `Artifact` cu **`url` = link-ul de mai sus** (fara
-   > `url` se creeaza link nou). `WebFetch` cere si el o citire prealabila daca artifactul a fost
-   > publicat din alta conversatie — asa a fost si in runda 15, si a mers.
-   > **`docs\mockup_13_formular_unificat.html` (v8) nu e atins de regula asta** — Marius a cerut-o
-   > numai pentru mockup-ul asezarii.
-4. ~~**Golul de la `IN_STOC` in S8**~~ — **FACUT in runda 17.** E in plan, in nota de executie a lui S8
-   (caseta „CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17"), cu criteriul de test in „gata cand" si cu
-   consecinta 1 de la S10 marcata **PRELUAT**. **Nu se reia.** Ce a ramas in urma lui **nu e o sarcina
-   de executie, e o alegere de facut la proiectarea lui S8**: valoarea istorica a lui `IN_STOC` nu e
-   stocata nicaieri, deci trebuie ales **de unde se reconstituie** (una din cele trei variante scrise
-   in plan). Nu se presupune niciuna.
-5. ~~**Mockup v9**~~ — **FACUT in runda 17.** `docs\mockup_13_formular_unificat.html` e la **v9.1**, cu
-   varianta D, randul de jos in **doua** sectiuni si motivul discountului in banda de totaluri
-   (decizia 66, care rastoarna decizia 64); raport de modificari:
-   `docs\cercetare\mockup_v9_modificari.md`. **Republicat**, la cererea lui Marius, pe URL-ul existent:
-   **https://claude.ai/code/artifact/e9d73e86-7518-4f50-a998-43c49e083142** (notat de acum si in plan,
-   la S1). Ca sa-l modifici: `WebFetch` pe URL intai — fara asta publicarea e refuzata — apoi `Artifact`
-   cu `url` = link-ul de mai sus.
-6. Dupa aceea **nu mai e proiectare de facut**: #13 asteapta terminarea lui #6 (decizia 30). Prima
-   sarcina la pornirea implementarii e **spargerea planului pe stories** si scrierea notei de executie
-   pentru prima dintre ele (decizia 55).
-
-**FACUT in runda 14, nu se reia:** integrarea in plan a rezultatelor 1-3 (decizia 50 rescrisa cu cele
-trei garzi; S7 rescris cu pre-flight; S8 cu blocul de avertizare peste schita gresita; S10 rescris
-integral; S9 si S11 corectate pentru atasamente; deciziile 51-55 adaugate), **plus sectiunea „Metoda de
-executie"** (spargerea pe stories, testele la fiecare pas, code review per story inainte de commit) si
-rescrierea lui S13 ca inchidere, nu ca moment al review-ului. **Plus, tot in runda 14:** corectia S8
-(`frm_facturare_articole2` e **prototipul**, nu o varianta de exclus — S1); inchiderea punctului
-`REST_NOTE_PLATA` / `IPS_VOYAGES_VANZARI` prin raspunsul lui Marius, cu cerinta ca **S7 sa le refuze
-explicit**; si cele trei variante de asezare a zonei de jos.
-
-**Nu se incepe implementarea pe cod** (decizia 30).
diff --git a/docs/handoff_curatenie_progres.md b/docs/handoff_curatenie_progres.md
deleted file mode 100644
index 4a8da8c..0000000
--- a/docs/handoff_curatenie_progres.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# Handoff — stergerea lui progres.md (ultimul pas al curateniei)
-
-Scris 20.08.2026, dupa r18027. Sesiunea principala a trecut de pragul de context (254k).
-**Numai stare, fara analize noi.**
-
-## Nimic nu e intr-o stare periculoasa
-
-- **Totul e comis si pushed.** SVN `r18026` (lucrarea) si `r18027` (curatenia). Git: proiect
-  `3ddcbc0`, COMUN `58d4c4a`, ambele la zi cu origin. `git status` curat in ambele repo-uri.
-- Niciun fisier editat fara write-back. `vfp9.exe` nu ruleaza. Nicio tranzactie deschisa.
-- `roafacturare.PJT`/`.PJX`/`.exe` raman modificate din sesiunea de VFP a lui Marius: **nu se comit**.
-
-## Ce a cerut Marius, si unde s-a oprit
-
-> "cred ca poti sa stergi si progres.md daca nu mai indica catre modificari active"
-
-**Premisa e corecta**, verificat: `progres.md` nu mai descrie lucrari active. #6, #7 si #8 sunt
-inchise; starea lui #13 sta in `handoff_13_formular_unificat.md`, care **nu** il refera
-(0 trimiteri; la fel `plan_13` si `plan_10`).
-
-**Ce lipseste ca sa se poata sterge** — sase trimiteri vii de rescris:
-
-| fisier | trimiteri | ce spune |
-|---|---|---|
-| `docs\plan_index.md` | **3** | "Planul a fost sters la curatenie; istoricul e in `progres.md`" — randurile #8, #6, #7 |
-| `docs\plan_11_integrare_politici_preturi.md` | 1 | |
-| `docs\plan_12_nomenclator_ca_lista_preturi.md` | 1 | |
-| **`COMUN\docs\reguli_lucru.md`** | 1 | **cross-proiect** — fisier partajat de toata suita ROA |
-
-Ultima e motivul pentru care lucrarea nu e banala: `COMUN` e dublu-versionat (SVN + git propriu,
-`gitea.romfast.ro:romfast/comun.git`) si orice modificare acolo atinge toate produsele ROA.
-
-## Ce are de facut sesiunea urmatoare
-
-1. Decide cu Marius **unde se muta rolul de arhiva**: fie se renunta la promisiune (istoricul
-   ramane doar in git, `3ddcbc0` si mai vechi), fie trimiterile arata catre revizia SVN/commit-ul
-   git in loc de fisier.
-2. Rescrie cele 6 trimiteri de mai sus in acord cu decizia.
-3. Sterge `docs\progres.md` (e sub SVN — `svn delete`, nu doar `rm`).
-4. Commit in **doua repo-uri**: SVN pe `docs\` + `COMUN\docs\reguli_lucru.md`, apoi `roa_sync.bat`.
-   Verifica separat repo-ul git al lui `COMUN`.
-5. Sterge si acest handoff, odata ce pasul e incheiat.
-
-## Starea curenta a documentatiei
-
-`docs\` are **10 fisiere** + `docs\cercetare\` cu **63**:
-
-- planurile deschise/amanate: `plan_13` (**urmatorul la rand**, locul 1 in index), `plan_12`,
-  `plan_11`, `plan_10`, `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` (netrackat in SVN, doar git);
-- `progres.md` — subiectul acestui handoff.
-
-**Capcana de nume, deja platita**: `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**. Criteriul de stergere in `cercetare\` a fost referinta, nu numele: **#13 se sprijina pe
-folder cu 86 de trimiteri**, deci nu se poate sterge in bloc.
-
-## Reziduu acceptat, nu defect
-
-`progres.md` pastreaza 39 de trimiteri catre fisiere sterse, plus 5 mentiuni in proza in
-`plan_13`, `cercetare\handoff_s4_runda1.md`, `cercetare\rec_s4_runda1.md` si
-`cercetare\rec_cale_vanzari_detalii.md`. Sunt istorice, se rezolva din git — aceeasi situatie ca la
-curatenia planului #8. Daca `progres.md` dispare, dispar si cele 39.
-
-## Defect deschis, raportat si nereparat (decizia lui Marius)
-
-Sincronizarea articole-rulaje nu recalculeaza `valoarev`/`valtvav` pe randul `trul`; ele ajung
-invechite in Oracle (`RUL`). `VALOAREVCTVA` nu e coloana in `RUL` — ramane invechit doar pe ecran,
-pana la reincarcarea notei. Back-fill-ul de la reincarcare are garda `WHERE EMPTY(NVL(...,0))`,
-deci prinde doar zerourile. Lantul complet, cu `fisier:linie`, era in `docs\raport_r7_sincronizare.md`,
-sters la curatenie — se recupereaza din git (`5b52cb3`), iar rezumatul a ramas in `progres.md`.
diff --git a/docs/handoff_skills_agenti.md b/docs/handoff_skills_agenti.md
deleted file mode 100644
index 3e78dc1..0000000
--- a/docs/handoff_skills_agenti.md
+++ /dev/null
@@ -1,94 +0,0 @@
-# Handoff: skill-uri de agent ROA + backstop de rutare
-
-Data: 2026-09-16. Sesiune oprita la limita de context. Acesta e fisier de stare, nu documentatie.
-
-## Ce s-a livrat (in COMUN, versionat git + SVN)
-
-- 9 skill-uri, cate un `SKILL.md` per folder (`COMUN\skills\<nume>\`), frontmatter doar
-  `name`+`description`, corp auto-suficient (skill = proprietarul procedurii):
-  `roa-vfp-text-edit`, `roa-vfp-headless-test`, `roa-git-svn-commit`, `roa-oracle-migration`,
-  `roa-oracle-diagnostic`, `roa-oracle-production-access`, `roa-vfp-null-guards`,
-  `roa-vfp-go-recno`, `roa-oracle-sqlexec-no-data`.
-- `COMUN\utile\leaga_skills.ps1` - creeaza symlink-uri in `%USERPROFILE%\.claude\skills\` catre
-  `COMUN\skills\<nume>` (fara copiere; citit de Claude Code SI de opencode). Idempotent, `-DryRun`.
-- `COMUN\utile\backstop_skills.txt` (sursa canonica a rutarii) +
-  `COMUN\utile\scrie_backstop_skills.ps1` (`-Root`, `-Proiecte`, `-DryRun`; scrie `AGENTS.md` +
-  bloc marcat in `CLAUDE.md`; garda anti-duplicare: sare fisierele care contin deja `roa-` fara markers).
-- `COMUN\docs\reguli_lucru.md` pct. 7 + `COMUN\docs\README.md` - ruteaza fiecare zona la skill-ul
-  care o detine (nu la doc).
-- `COMUN\docs\cercetare\rec_skills.md` - decizia, inventarul, cum se adauga un skill nou.
-- `AGENTS.md` (radoacina ROAFACTURARE, backstop pentru opencode) + `CLAUDE.md` (2 rute + ancora).
-- Backstop aplicat pe 10 proiecte: ROAACNPRO, ROAAUTO, ROACONT, ROACONTRACTE, ROADEF,
-  ROAFACTURARE, ROAGEST, ROAIMOB, ROAPRETURI, ROAREGISTRATURA (verificat idempotent).
-
-## Ce NU e terminat (de continuat)
-
-1. **2 fisiere de onboarding modificate, NEcomise in SVN** (singura stare nefinalizata de cod):
-   - `COMUN\docs\onboarding\inrolare-calculator-nou.md` - secțiune noua "Pasul 8 - skill-uri de
-     agent ROA" (+22 linii; pastreaza diacriticele).
-   - `COMUN\docs\onboarding\inrolare-proiect-git-text.md` - secțiune noua "### 8. Skill-uri de
-     agent (backstop de rutare)" (+7 linii; ASCII).
-   - Ambele: LF, fara BOM. NU au fost testate mai departe (sunt doar text).
-2. **8 proiecte au commit SVN dar mirror-ul git nu a rulat `roa_sync`** (ROAACNPRO, ROAAUTO,
-   ROACONT, ROACONTRACTE, ROADEF, ROAGEST, ROAIMOB, ROAPRETURI, ROAREGISTRATURA). Fisierele sunt
-   active pe disc; git-ul lor se aliniaza la urmatorul `roa_sync.bat` local.
-3. **Optional nefacut**: skill `roa-onboarding` (Nivel D din plan). Nu s-a creat intentionat:
-   `vfp-ui-test` NU se creeaza (e acoperit de `roa-vfp-headless-test`).
-
-## Stare depozite
-
-- SVN: COMUN r18116; ROAFACTURARE r18118; proiecte r18114/18115/18117/18119/18120/18121/18122/
-  18123/18124.
-- git: COMUN `4756dc0`, ROAFACTURARE `50274b8`, ambele `ahead=0` (push facut, `main`).
-- `svn status COMUN` = 2 x M (cele doua onboarding-uri de mai sus).
-- `svn status ROAFACTURARE` (in afara COMUN) = reziduri PRE-EXISTENTE, neale noastre:
-  `.claude` (?), `Clase\ofundal_facturare.vc2.pre_runda1.bak` (?),
-  `Utile\Teste\test_catalog_articole_s1.FXP` (?), `docs\diff_runda3_vanzare_ui.patch` (?).
-- Branch `claude/skills-agenti`: sters in ambele repo-uri.
-
-## Comenzi de rulare (exacte)
-
-- Backstop, pe proiecte: `powershell -ExecutionPolicy Bypass -File D:\ROA\<PROJ>\COMUN\utile\scrie_backstop_skills.ps1 -Root D:\ROA -Proiecte ROAACNPRO,ROAAUTO,ROACONT,ROACONTRACTE,ROADEF,ROAFACTURARE,ROAGEST,ROAIMOB,ROAPRETURI,ROAREGISTRATURA`
-  (intai `-DryRun`). Fara `-Proiecte` = toate proiectele detectate (53 - NU rula asa fara acord).
-- Legare pe masina: `powershell -ExecutionPolicy Bypass -File <PROJ>\COMUN\utile\leaga_skills.ps1 [-DryRun]`.
-- Sync: `D:\ROA\ROAFACTURARE\roa_sync.bat` (svn update -> git_sync -> commit "sync SVN rN" ->
-  reconciliere; push DOAR daca tot ahead-ul e commit-uri de sync).
-- Verificare ASCII: `([IO.File]::ReadAllBytes($p) | Where-Object {$_ -gt 127}).Count` -> 0.
-
-## Decizii luate (nu re-investiga)
-
-- Skill = proprietarul procedurii; docurile din `COMUN\docs` = referinta CONDITIONATA (cel mult 1
-  pointer per skill). Motiv: sa nu se incarce contextul de doua ori.
-- Un singur loc de rutare per host: `AGENTS.md` (opencode) + `reguli_lucru.md` pct. 7 (Claude,
-  citit mereu) + ancora in `CLAUDE.md`.
-- Skill-urile traiesc in `COMUN\skills`, expuse prin symlink in `~/.claude/skills` (fara copie).
-  opencode citeste nativ `.claude/skills` (confirmat in sursa: `SkillV2.load` -> `glob(...,{symlink:true})`).
-- Sursa canonica a rutarii = `COMUN\utile\backstop_skills.txt` (regenerata in proiecte de script).
-- NU se foloseste plugin marketplace: opencode nu citeste cache-ul de pluginuri.
-- Declansare: automata din `description` in ambele host-uri; backstop-ul always-on prinde
-  cazurile in care descrierea nu se potriveste. `paths` NU se foloseste (doar restrange, nu forteaza).
-
-## Interzis
-
-- Nu copia manual fisiere de skill in `~/.claude/skills` (se pierde legatura cu sursa; doar `leaga_skills.ps1`).
-- Nu `git commit`/`push`/`merge` pe `main` in COMUN in afara fluxului; commit-urile de lucru pe branch
-  `claude/<subiect>`, apoi `svn commit` + `roa_sync`.
-- Nu rula `roa_sync` pe un branch cu fisiere noi inainte de `svn commit` (pe branch face
-  `checkout main` si scoate fisierele de pe disc).
-- Nu rescrie `COMUN\docs\` din proprie initiativa (regula 11/12) - propune.
-- Nu rula `scrie_backstop_skills.ps1` fara `-Proiecte` (atinge 53 de proiecte).
-
-## Capcane platite
-
-- PowerShell 5.1 `New-Item -ItemType SymbolicLink` cere privilegii; `mklink /D` merge cu Developer
-  Mode activ (scriptul are fallback).
-- `COMUN\docs` sunt LF, nu CRLF; fisierele noi create (AGENTS.md, skill-uri) sunt CRLF.
-- `reguli_lucru.md` si `CLAUDE.md` au em-dash (non-ASCII) PRE-EXISTENTE - nu se "repara" din oficiu.
-- `inrolare-proiect-git-text.md` are 5 en-dash pre-existente (15 octeti non-ASCII); adaugarea
-  noastra e ASCII pur.
-
-## Urmatorul pas recomandat
-
-1. `svn commit` pentru cele doua onboarding-uri + `roa_sync.bat` + `push`.
-2. `roa_sync.bat` in cele 8 proiecte ramase (apoi push, la alegere).
-3. (Optional) skill `roa-onboarding`.
diff --git a/docs/plan_13_executie.md b/docs/plan_13_executie.md
deleted file mode 100644
index 1905b85..0000000
--- a/docs/plan_13_executie.md
+++ /dev/null
@@ -1,146 +0,0 @@
-*!* 03.09.2026
-*!* agent documentatie (orchestrat de team-lead, sesiune plan13-s2)
-*!* Coloana "Stare" era stale din 27.08.2026 (marca NEINCEPUT povesti de mult inchise si probate).
-*!* Adusa la zi pe baza `docs\handoff_plan13_executie_continua.md` (fisierul de stare viu — ramane
-*!* sursa de adevar, se citeste ACOLO intai). Rezolvata si capcana de numerotare de mai jos, prin
-*!* sectiunea separata "Firul geometrie (designer editabil)".
-
-# Plan #13 - executie pe stories
-
-Tabel de urmarire pentru executia planului `docs\plan_13_unificare_formular_facturare.md`,
-conform metodei de executie (liniile 1954-2015 din plan, decizia 55). Nu e reproiectare - fiecare
-story are proiectarea proprie in plan si/sau in `docs\cercetare\`. Actualizat dupa fiecare story
-inchisa. **Sursa de adevar pentru stare e `docs\handoff_plan13_executie_continua.md`** - acest
-tabel e o rasfrangere a lui, tinuta pentru titluri scurte, fisiere atinse si dependente.
-
-**Capcana de numerotare — REZOLVATA (03.09.2026).** Numele `S6`/`S7`/`S8`/`S8b`/`S8c` din acest
-tabel se refera strict la povestile din acest plan ("Test pe flux real", "Actiunea si garzile",
-"Incarcarea documentului in formular" etc.). Un lant separat, comis tot pe `plan13-s2`, a folosit
-ACELEASI nume pentru firul "designer editabil" (cererea separata a lui Marius,
-`docs\sinteza_designer_editabil.md`). Cele doua nu au nicio legatura. Firul de geometrie are acum
-randuri proprii, cu prefixul `S8-geometrie-*`, in sectiunea **„Firul geometrie (designer
-editabil)"** de sub tabelul principal — nu se mai confunda cu povestile de aici.
-
-## Vocabular de stare
-
-- **INCHISA SI PROBATA** — cod comis + proba automata verde.
-- **INCHISA FARA COD** — inchisa prin decizia lui Marius, fara implementare (cu decizia citata).
-- **LIVRATA, PROBA MANUALA DATORIE** — codul e comis si probat automat, dar criteriul oficial
-  „gata" e o proba manuala UI pe care Marius n-o poate face acum (mandatul din §1 al handoff-ului).
-- **PARTIALA** — ce s-a livrat si ce a ramas, explicit.
-- **NEINCEPUT** — chiar neinceput.
-
-## Tabel stories
-
-| Story | Nume scurt | Fisiere atinse (din plan) | Depinde de | Stare | Nota de executie |
-|---|---|---|---|---|---|
-| S1 | Inventar campuri + alegerea bazei | (inventar, fara cod) | - | **INCHISA FARA COD** — aprobata de Marius, 09.08.2026 | `docs\S1_inventar_campuri_formular_unificat.md` |
-| S2 | O singura procedura `factureaza` | `COMUN\programe\ofacturare.prg`, `Clase\ofundal_facturare.vc2` (decizia 67 + completare + corectie review) | S1 | **LIVRATA, PROBA MANUALA DATORIE** — comisa pe `plan13-s2`, 21.08.2026; netestata manual la momentul comiterii (decizia lui Marius). De atunci exercitata cu succes indirect, prin documente reale emise care trec prin `factureaza`, la S6 (`docs\raport_s6_flux_real.md`) si S9 (`docs\raport_s9_7_oracle.md`, `docs\raport_s9_7_vfp_proba.md`) — proba manuala UI dedicata ramane datorie deschisa | `docs\nota_executie_s2.md`, `docs\raport_s2_implementare.md`, `docs\cercetare\s2_factureaza_unificare.md`, `docs\review_s2.md`, `docs\handoff_13_s2.md` |
-| S3 | Portare logica antet in formularul unificat (spart in S3-1..S3-4, decizia 68) | `ofacturare.vc2`, `ofacturare_antet.prg` (nou, S3-2), `ofacturare.prg` (S3-4) | S2 | **LIVRATA, PROBA MANUALA DATORIE** — S3-1..S3-4d COMISE pe `plan13-s2` (COMUN `89dd30a`, `27bdf58`, `c269fdf`, `4f6af10`, `359f478`, `02df236`, `e538590`, `409ce90`, `e96fd3e`); Q8 (numarul ars) COMISA, doar pe calea unificata. Implementarea e completa; proba manuala pe tip 1 a fost refuzata de Marius (22.08.2026), iar `factureaza` nu e apelabila headless | `docs\nota_executie_s3.md`, rapoartele si review-urile S3-1/S3-2/S3-3, `docs\raport_b1_rerulare_s3_3.md`, `docs\raport_q8_numar_ars.md`, `docs\review_q8_numar_ars.md`, `docs\raport_adaptare_paritate_q8.md`, `docs\handoff_13_s3.md` |
-| S3b | Sectiune pliata: alte date + analitice | `caut_ora.vc2`, `ferestre_cere_date.vc2`, `ofacturare.vc2`, `omodificari.vc2` | S3 | **PARTIALA** — implementata aproape integral, comisa pe `plan13-s2`. Criteriul „gata" din 5 puncte (`docs\cercetare\s3b_alte_date_analitice.md` §10): **(1) paritate emitere pe 4 tipuri de incasare — TRECUT**, `test_s3b_emitere_paritate_2.prg` PASS 20/0 (`docs\raport_s3b_criteriu1_pasat.md`); **(2) non-alocare la toggle de pliere — TRECUT**, `test_s3b_incasare_nealocare.prg` PASS 14/0 (`docs\handoff_13_s3b_asezare.md`); **(3) blocarea grupului de incasare pe document emis — CADUC pentru S3b, amanat la S8c** (decizia 25); **(4) analitice read-only — CADUC, rasturnat de decizia 72** (raman editabile); **(5) paritate delegat/transport/adresa/text — FACUT**, cu o inconsecventa vizuala minora ramasa (`Ct_clb_delegat`/`Ct_clb_masina` editabile pe proforma, unde calea veche le scotea) [^1] | `docs\handoff_13_s3b_varianta_b.md`, `docs\raport_s3b_varianta_b.md`, `docs\handoff_13_s3b_reasezare_grila.md`, `docs\handoff_13_s3b_asezare.md`, `docs\cercetare\s3b_alte_date_analitice.md` §10, `docs\cercetare\s3b_bloc5_ce_ramane.md` |
-| S3c | Sursa ca parametru, nu ca global | `ferestre_contracte.vc2`, `ocomenzi.vc2`, `ofacturare.prg`, `ofacturare_comun.prg`, `ofundal_facturare.vc2`, `oproceduri_facturare.prg` | S2. Atinge cod comun intregii suite - nu se face impreuna cu alta modificare | **INCHISA SI PROBATA (S3c-1/2/3/4-tinta1)** + **INCHISA FARA COD (S3c-4-tinta2 si S3c-5)**, 31.08.2026 — S3c-1/S3c-2/S3c-3: `toSursa` la coada in `Init`/`factureaza`/`facturare_contracte`/`facturare_comenzi`, test 55/0, comis 27.08.2026. S3c-4 tinta 1 (`ocomenzi.vc2:do_factura`): LIVRATA, test 18/0. S3c-4 tinta 2 (ROACONTRACTE) si S3c-5 (sincronizare cross-produs, 6 produse): mutate intr-o **poveste separata prin decizia lui Marius**, nu se mai ating la planul #13 (detaliu in §9 al handoff-ului) | `docs\nota_executie_s3c.md`, `docs\raport_s3c_1_implementare.md`, `docs\handoff_13_s4_s3c.md`, `docs\propunere_s3c_4_apelanti_reali.md`, `docs\propunere_s3c_5_sincronizare.md` |
-| S4 | Cautarea articolelor pe server, in linie | `ofacturare.prg`, `ofacturare.vc2` | S3 | **PARTIALA** — S4-1 (Oracle articole server) INCHISA SI PROBATA, 23.08.2026 (identic byte-cu-byte pe filtru NULL fata de baseline); S4-2 (functii Oracle remainder/plafon) INCHISA SI PROBATA, 24.08.2026 (114 randuri numai adaugate in `PACK_FACTURARE`, zero stergeri); S4-3 (cautare in linie, `ofacturare_cautare.prg` nou) INCHISA SI PROBATA, 27.08.2026, teste 41/0, 50/0, 39/0; S4-4 (decuplare Rol A, decizia 6 varianta C) LIVRATA, PROBA MANUALA DATORIE, test paritate 18/0; **S4-5 (Rol B) PARTIALA** — garda `If Used(lcCursor)` in `do_sterge` LIVRATA (repara bug LIVE preexistent, test 10/10), dar plafonul Rol B pe tipul `23` a fost implementat, testat si **REVENIT** in aceeasi sesiune (garda structural moarta); ramane deschis prin deciziile 7 si 8 din handoff §2 (nedecise) [^2] | `docs\raport_s4_1_aplicare.md`, `docs\scripturi_oracle_13.md`, `docs\cercetare\s4_cautare_articole_server.md`, `docs\raport_s4_3_implementare.md`, `docs\raport_s4_4_vfp_implementare.md`, `docs\raport_s4_4_oracle_varianta_c.md`, `docs\propunere_s4_5_rol_b.md`, `docs\raport_s4_5_implementare.md` |
-| S4b | Bara de butoane si meniul de adaugare | `ofacturare.vc2` | S4 | **INCHISA FARA COD** — decizia 9 varianta 3 (31.08.2026): mecanismul v2 (`but_incarca_articole` -> `do_incarca_articole`) e pastrat neatins; alegerea selectiva devine poveste separata (datoria 19) | `docs\propunere_s4b_bara_butoane.md` |
-| S4c | Discount pe linie, mutat din dialog in grid | `ofacturare.vc2`, `ofacturare_comun.prg`, `oproceduri_facturare.prg`, `xmlefactura.prg` | S4 | **LIVRATA, PROBA MANUALA DATORIE** — handlere `LostFocus` pe cele doua campuri de discount + `recalc_discount_linie` nou, camp `procdisc` nou; repara si un defect preexistent (`cProcentDiscount` editabila dar legata la camp inexistent); test 26/0/0, write-back verificat independent | `docs\propunere_s4c_discount_grid.md` |
-| S4d | Data cursului valutar, numai cand are sens | `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.prg` | S4 | **LIVRATA, PROBA MANUALA DATORIE** — metoda noua `do_actualizeaza_vizibilitate_curs`, apelata din 3 puncte (sink comun `do_calculeaza_totaluri`, `Init`, `do_incarca_articole`); test 32/0/0, inclusiv traseul complet al erorii Oracle `-20005`, write-back verificat independent | - |
-| S4e | Lista de preturi si pe factura din comanda | `ofacturare.prg`, `ofacturare.vc2` | S4-1, S4-3 | **INCHISA SI PROBATA** — S4e-1 acoperit de S4-3 (prin `do_adauga_articol_cautat`, acceptat de Marius ca solutie finala, nu se redeschide); S4e-2 GATA (decizia 44); S4e-0 GATA 31.08.2026 (deblocarea `do_adauga_articol`); S4e-3 GATA 31.08.2026 (validare cantitate/stoc, tipurile `3,4,21,25,28,42,47`, test 62/0/0); S4e-4 GATA (proba de neregresie a registrului, fara cod nou, test 15/0/0); S4e-5 GATA (probe repetate pe tip 4/21 + captura dialog, test 37/0/0) | `docs\nota_executie_s4e.md`, `docs\recon_s4e_stare_reala.md`, `docs\raport_s4e_2_implementare.md`, `docs\raport_s4e_0_implementare.md`, `docs\raport_s4e_3_implementare.md`, `docs\raport_s4e_4_implementare.md` |
-| S4f | Returul in formularul unificat | `ofacturare.vc2` | S2, S4e | **INCHISA** (08.09.2026) — stare veche din acest tabel depasita, vezi `docs\handoff_plan13_executie_continua.md` §4.0; `do_adauga_articol_cautat` deleaga returul (tip 8/9/41) la `do_adauga_articol` | `docs\raport_s4f_retur.md` |
-| S4g | Adaugare articole la modificarea documentului | `ofacturare.vc2`, `ofacturare_comun.prg` | S4e + deciziile de mai sus. Nu blocheaza etapa I | **INCHISA** (08.09.2026) — stare veche din acest tabel depasita, vezi `docs\handoff_plan13_executie_continua.md` §4.0; decizia 34/optiunea B aplicata (Oracle `FACT-032` + VFP `deriva_cont_venit_fara_pol`) | `docs\raport_s4g_oracle.md`, `docs\raport_s4g_vfp.md` |
-| S5 | Acoperirea tuturor tipurilor de document | `ofacturare.prg` | S4 | **INCHISA SI PROBATA**, 01.09.2026 — cod COMUN `1f89c18` (v2), teste conform §6 al handoff-ului | `docs\propunere_s5_acoperire_tipuri.md`, `docs\matrice_goluri_s5_form2.md`, `docs\verificare_s5_tabel_sursa.md` |
-| S5b | Proforma si copierea pe formularul unificat | `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.vc2`, `oproceduri_facturare.prg` | S5 | **INCHISA SI PROBATA**, 01.09.2026 — COMUN `76e7398` (emiterea proformei pe formularul unificat, v2) + `d6cae36` (v1, calea de copiere); teste `080321f` (UI, 20/0/2) + testul de rutare (22/0/0). Ramane o singura datorie neblocanta: clauza de gestiune probata prin paritate, nu prin `id_gestiune > 0` (M3) | `docs\propunere_s5b_proforma_copiere.md`, `docs\raport_s5b_implementare.md`, `docs\raport_verificare_s5b_disc.md` |
-| S5c | Factura din proforma (decizia 43) | `cmd_butoane.vc2`, `ocomenzi.vc2`, `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.prg`, `ofacturare_comun.vc2`, `ofacturare_editare.prg`, `oinit_optiuni.prg`, `xmlefactura.prg` | S5b | **INCHISA SI PROBATA**, 01.09.2026 — proba capat-la-capat prin UI RULATA, 20/0/2; vezi si golul de produs semnalat separat (nu al lui S5c) in handoff §4.0a | `docs\raport_s5c_test_ui.md` |
-| S6 | Test pe flux real - formularul unificat | (test, nu cod nou) | S5 | **PARTIALA** — INCHIS 02.09.2026 cu proba partiala: **4 din 7** surse au acum comparatie v1/v2 pe document real emis (0/7 la pornire), **7 defecte de productie gasite, 6 reparate si comise** (3 cu proba doar partiala) | `docs\raport_s6_flux_real.md`, `docs\propunere_s6_test_flux_real.md`, `docs\raport_s6_1_lista_preturi.md`, `docs\raport_s6_3_aviz_retur.md`, `docs\raport_s6_4_transfer.md`, `docs\raport_s6_5_valuta.md`, `docs\raport_s6_6_listare_intrare.md` |
-| S7 | Actiunea si garzile | `ofacturare_comun.vc2`, `ofacturare_editare.prg` | S6, si inchiderea perimetrului cu #6 | **INCHISA SI PROBATA**, 02.09.2026 — cod revizuit integral si comis, COMUN `70eddfa`; cele 5 cerinte de review inchise (cens octeti 13=13, metoda cu toate cele 3 inregistrari). Metoda ramane schela, fara apelant, pana cand S8 cableaza a treia optiune de meniu | `docs\propunere_s7_actiune_garzi.md`, `docs\raport_s7_actiune_garzi.md`, `docs\verif_s7_doua_fapte.md` |
-| S8 | Incarcarea documentului in formular | `ferestre_cere_date.vc2`, `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.prg`, `ofacturare_editare.prg`, `ofacturare_stoc.prg` | S7 | **INCHISA SI PROBATA**, 02.09.2026 — pasii 1-8 GATA, proba finala `test_s8_editare_incarcare.prg` 307/0, CINCI rulari consecutive identice verificate pe md5/diff. Decizia 1 (`IN_STOC`) INCHISA de Marius (handoff §2). Defect nou, neblocant, in afara perimetrului: **G10 incalcat pentru avize** | `docs\propunere_s8_incarcare.md`, `docs\raport_s8_pas7b_proba.md`, `docs\raport_s8_defect5_incasat.md`, `docs\nota_s8q_aplicare_etapa6.md` |
-| S8b | Rutarea scrierii dupa schimbarea tipului | `ferestre_cere_date.vc2`, `ofacturare.vc2` | S8 | **INCHISA SI PROBATA**, 03.09.2026 — rutarea scrierii la editare, COMUN `0a41327`, ROAF `e5530fe`; proba 54/0, trei rulari consecutive identice, toate cele patru rute exercitate pe traseul real | `docs\raport_s8b_implementare.md` |
-| S8c | Buton comutator antet + salvare separata | `lb_tx.vc2`, `rulaje.vc2` | S8 | **NEINCEPUT** — mentionata in handoff doar ca alternativa paralela posibila cu S9 (mai mica, poate rula in paralel), fara cod scris pana acum | - |
-| S9 | Stergere + reemitere intr-o tranzactie, `ID_FACT` pastrat | `oscrie_in_fisiere.prg` | S8b | **PARTIALA — IN LUCRU (03.09.2026)** — S9-1..S9-7 INCHISE SI PROBATE (S9-6 `PACK_CONTAFIN.nIdFactFortat` aplicat/probat pe `MARIUSM_AUTO`; S9-7 cablaj VFP aplicat si probat, sweep P1-P6/CN1-CN4 verde, COMUN `658acc6`/`cc79734`, ROAF `5886b3f`/`119474e`). **S9-8** (testul de flux: reemitere identica + cu modificari, pe aviz/comanda/contract/ELSE) **IN LUCRU** in aceasta sesiune. Datorii neinchise: proba vizuala UI dupa scoaterea garzii, neregresia pe ROACONTRACTE pentru scriptul #9 | `docs\propunere_s9_stergere_reemitere.md`, `docs\propunere_s9_6_pack_contafin.md`, `docs\propunere_s9_7_cablare_idfact.md`, `docs\raport_s9_7_oracle.md`, `docs\raport_s9_7_vfp_aplicare.md`, `docs\raport_s9_7_vfp_proba.md` |
-| S10 | Pretul care nu trebuie re-derivat | `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_editare.prg` | S9 | **NEINCEPUT** — decizia 3 (`PROC_TVAV` ca parametru) care il blocheaza e INCHISA (handoff §2), deci pornirea nu mai e conditionata de o decizie in asteptare | - |
-| S11 | Legaturile ramase pe `ID_VANZARE` | (verificare + cod punctual, vezi plan) | S9 | **NEINCEPUT** | - |
-| S12 | Test pe flux real - regenerarea | (test, nu cod nou) | S10, S11 | **INCHISA** - criteriul (toate cele patru familii trec scenariul B) atins prin sweep 4/4 pe `test_s9_8_flux.prg`, 04.09.2026 | `docs\raport_s12_inchidere.md` |
-| S14 | Audit: creare, modificare, stergere document | `ofacturare_editare.prg` | S9 | **INCHISA**, 04.09.2026 — criteriul din plan bifat pe date reale (documentele reemise 1195/1196); vezi datoriile deschise in raport | `docs\raport_s14_oracle.md`, `docs\raport_s14_vfp_transport.md`, `docs\raport_s14_vfp_grid.md`, `docs\raport_s14_inchidere.md` |
-| S13 | Diff, review, changelog, documentatie | toate cele de mai sus (inchidere de etapa) | toate stories anterioare - livrare finala | **NEINCEPUT** | - |
-
-[^1]: In plus, nedus in niciun raport separat pana acum: `lb_total_mod` e cod viu dar inert
-(`docs\raport_s3b_lb_total_mod.md`, recomandat pentru alta poveste); euristica „205/210 dezalinieri
-de coloana" din `verifica_grila.ps1` ramane neinvestigata.
-
-[^2]: Tipul `41` (S4-5) ramane definitiv in afara perimetrului curent — fix-ul necesar e proiectat
-in `docs\propunere_s4_5_rol_b.md` §7, dar nefacut, ca sa nu arate tacit stoc din gestiuni gresite.
-
-## Firul geometrie (designer editabil)
-
-Firul separat, comis tot pe `plan13-s2`, prin care Marius poate aranja controalele formularului cu
-mana in designerul VFP (`docs\sinteza_designer_editabil.md`). A folosit intern aceleasi litere
-`S6`/`S7`/`S8b`/`S8c` in documentele lui proprii (`docs\handoff_s6_designer_editabil.md`,
-`docs\handoff_s7_containere.md`, `docs\handoff_s8b_transa_a_si_ghid.md`,
-`docs\handoff_s8c_transa_c.md`) si, intr-o etapa ulterioara, etichetele `S8h`-`S8p`/Etapa 6 — **fara
-nicio legatura** cu povestile din tabelul de mai sus. Randurile de aici sunt rasfrangerea acelei
-etape ulterioare (sursa: `docs\handoff_plan13_executie_continua.md` §3); tot firul e **INCHIS SI
-COMIS**.
-
-| Bloc | Ce | Stare | Commit |
-|---|---|---|---|
-| S8-geometrie-h..m | Ancorare nativa vs. geometrie din cod; bitul `Bottom(4)` scos de pe controalele asezate din cod | **INCHISA** | COMUN `e2eca46` |
-| S8-geometrie-n | Test de geometrie mutat din scratchpad in arborele de teste | **INCHISA SI PROBATA**, 8/8 pasi | COMUN `4063277`, ROAF `20eb547` |
-| S8-geometrie-p | Dependenta rupta reparata: `Clase\ofacturare_util.vc2` intrat in versionare + `SET CLASSLIB` in `roafacturare.prg` | **INCHISA** — fara ea, `plan13-s2` era rupt la checkout curat | ROAF `fe3eef8` |
-| S8-geometrie-o | Proba de rezolutie 1366x768 + diagnosticul benzii de totaluri | **INCHISA SI PROBATA** — la 1366x768 maximizat, deficit 98px, preexistent, nu regresie | COMUN `261f547`, ROAF `6257df6`, `3b312a0` |
-| Etapa 6 | 5 fisiere de test reparate (`ObjExists` facut recursiv in 3; substitutia `opt_incasat.Value` -> `seteaza_mod_incasare` aplicata doar pe siturile formei NOI) | **INCHISA SI PROBATA** — `test_s3b_emitere_paritate_2` 20/0, `test_s3b_emitere_reala` 1/0, `test_s3_controale` 20/0, zero aparitii ale erorii 1734 | COMUN `34a1f30` |
-
-## Ordinea de executie rezultata din dependente
-
-```
-S1 (GATA)
- -> S2 (GATA implementare, in asteptare review/aprobare)
-     -> S3c (paralel cu S3, atinge alt fisier comun - nu impreuna cu alta modificare)
-     -> S4e (STALE: aici in arbore ca "porneste dupa S2"; depinde de fapt de S4-1 si S4-3 -
-             vezi randul S4e din tabel si `docs\nota_executie_s4e.md` §6)
-         -> S4f (dupa S4e)
-     -> S3
-         -> S3b
-         -> S4 (proiecteaza intai punctul 2, neproiectat)
-             -> S4b
-             -> S4c
-             -> S4d
-             -> S4g (dupa S4e + deciziile anterioare; nu blocheaza etapa I)
-             -> S5
-                 -> S5b
-                     -> S5c
-                 -> S6 (test pe flux real)
-                     -> S7 (dupa inchiderea perimetrului cu #6)
-                         -> S8 (varianta IN_STOC fixata in nota de executie S8, runda 17)
-                             -> S8b
-                                 -> S9
-                                     -> S10
-                                     -> S11
-                                     -> S14
-                                     -> S12 (dupa S10 si S11)
-                             -> S8c
-                         -> S13 (inchidere finala, dupa toate)
-```
-
-Observatii pe ordine:
-- S3c si S4e nu depind de S3/S4 - pot fi luate in paralel cu ramura S3, dar **un singur scriitor pe
-  fisier**: S3c atinge `ofacturare.prg`/`oproceduri_facturare.prg`, S2 le-a atins deja si le-a
-  eliberat (S2 e inchisa la nivel de implementare), deci nu se suprapun.
-- S4g explicit "nu blocheaza etapa I" - poate aluneca dupa S6/S7 fara sa opreasca lantul principal.
-- S8c e paralela cu S9 (ambele depind doar de S8), dar scrie in fisiere diferite (`lb_tx.vc2`,
-  `rulaje.vc2` vs `oscrie_in_fisiere.prg`) - fara conflict de scriitor.
-- **Starea reala la 03.09.2026** (handoff §6): lantul e dus pana la S9 (S9-1..S9-7 inchise,
-  S9-8 in lucru); ordinea ramasa e **S10 -> S11 -> S12 -> S14 -> S13**, cu **S8c** paralela.
-  Actualizare 04.09.2026: **S12 inchisa** (`docs\raport_s12_inchidere.md`) - vezi §4.0 al
-  handoff-ului pentru starea curenta. **S14 inchisa** (`docs\raport_s14_inchidere.md`) - ramane
-  doar **S13** (inchiderea de etapa), cu **S8c** in continuare paralela.
-
-## Cele 3 puncte de implementare ramase deschise — TOATE INCHISE (handoff §2, 31.08.2026)
-
-Sursa initiala: `docs\handoff_13_formular_unificat.md`. Cele trei decizii ale lui Marius care le
-inchid sunt in `docs\handoff_plan13_executie_continua.md` §2.
-
-1. **Relistarea unei facturi vechi deja trimise** (decizia 62) — **INCHISA**: toate facturile se
-   tiparesc dupa regula noua, fara versionare dupa data. Facturile trimise la ANAF nu se mai pot
-   retrimite.
-2. **`PROC_TVAV` ca parametru** (consecinta 3 a deciziei 54) — **INCHISA, DA devine parametru**:
-   caile de copiere si modificare pastreaza cota documentului original; blocheaza S10.
-3. **De unde se reconstituie `IN_STOC`** — **INCHISA, varianta (2)**: valoarea curenta din
-   nomenclator, fara migrare DB si fara reconstituire din rulaje; blocase S8, acum livrat si probat.
diff --git a/docs/plan_13_unificare_formular_facturare.md b/docs/plan_13_unificare_formular_facturare.md
deleted file mode 100644
index d896f9a..0000000
--- a/docs/plan_13_unificare_formular_facturare.md
+++ /dev/null
@@ -1,4610 +0,0 @@
-# Plan #13 — formular unificat de facturare + editare prin regenerare
-
-Sursa: `COMUN\docs\todos.txt` punctul 13.
-Mockup: `docs\mockup_13_formular_unificat.html` (versiunea 5).
-Cercetare pe cod, toata in `docs\cercetare\`: `inventar_controale_formulare.md`,
-`proforma_copiere_puncte_intrare.md`, `import_roris_roaacnpro.md`, `discount_pe_articol.md` si
-`discount_verificare2.md` (a doua il corecteaza pe primul), `modifica_antet_bifa.md`,
-`valuta_si_curs.md`, `buton_comutator_picture.md`, `modifica_date_factura_parametri.md`,
-`retur_si_lista_preturi.md`, `factura_retur_document.md`, `roaauto_facturi.md`,
-`roaauto_articole_lista_preturi.md`, `cont_venit_articol_fara_politica.md`.
-Stare: **propunere, neinceput**. Analiza facuta pe cod la 09.08.2026, in sase runde.
-
-## Cerinta, asa cum a fost formulata
-
-Trei lucruri intr-un singur punct:
-
-1. **Unificarea formularelor** — `date_factura` / `date_aviz` sa intre in formularul de facturare,
-   ca sa nu mai fie doua ferestre pentru acelasi document.
-2. **Fara incarcarea prealabila a tuturor articolelor** din toate politicile de preturi — pot fi mii
-   si dureaza mult aducerea lor de pe server.
-3. **Editarea facturii / avizului prin regenerare**, in toate variantele (politici de preturi,
-   comanda, contract, aviz): formularul se redeschide completat ca inainte de salvarea initiala, se
-   fac modificarile ca la introducere, iar la confirmare documentul initial se marcheaza `sters = 1`
-   si se salveaza unul nou — ca sa se vada ce s-a modificat.
-
-Decizia lui Marius, 09.08.2026: **intai unificarea, apoi editarea prin regenerare.** Explicit
-**nu** pe calea editarii directe a notelor / rulajelor / articolelor.
-
-## Deciziile lui Marius, 09.08.2026 — luate, nu de reluat
-
-1. **#13 coexista cu #6**, nu il inlocuieste.
-2. **`ID_FACT` se pastreaza**, ca la orice modificare. Documentul reemis nu-si schimba identitatea.
-3. **Toate datele se pastreaza, inclusiv numarul documentului.** Scopul e modificarea documentului,
-   nu emiterea altuia.
-4. **Antetul care intra in generarea lui `ID_FACT` (serie, numar, data) are cale proprie de
-   modificare** — nu trece prin regenerare.
-5. **Un singur formular, aceeasi infatisare la introducere si la modificare.** Fara banda de
-   avertisment, fara coloane cu valorile initiale, fara panou de diferente.
-6. **Se integreaza si modificarea de antet, si modificarea de articol care exista azi** — sa nu
-   ramana trei actiuni de modificare pe acelasi document.
-
-## Deciziile lui Marius, runda 3 (09.08.2026) — luate, nu de reluat
-
-7. **`frm_alte_date` intra in formular**, in sectiunea pliata. Se inchide intrebarea ramasa deschisa
-   in runda 2 (recomandarea de atunci — „ramane dialog” — **cade**).
-8. **Sectiunea pliata primeste in plus analiticele**: venit / cheltuiala, sectie, responsabil (si,
-   prin simetrie, lucrare). Antetul vizibil ramane aerisit, cu **controalele grupate** pe intelesuri,
-   nu insirate.
-9. **Un singur buton comutator pe antet.** Antetul se deschide blocat. Un singur `but_modifica`
-   (creionul) il deblocheaza si **isi schimba imaginea in discheta lui `but_salvare`**; a doua
-   apasare salveaza **doar antetul** si il blocheaza la loc. Un singur control, nu bifa plus buton —
-   mai compact. **Toata factura se salveaza in continuare din `Termina`.** Rostul ramane acelasi:
-   antetul se editeaza intentionat, nu din greseala, si se poate corecta fara a trece prin articole.
-
-   **Butonul singur deschide tot antetul. Nu mai exista bife individuale** — nici cele patru de azi
-   (serie / numar / data / scadenta). Un singur control comanda toata protectia antetului.
-
-   *Istoric, ca sa nu se reia:* runda 3 propusese un buton `Modificare / Salveaza` care bloca **tot
-   documentul** — respins, protectia e doar pe antet. Runda 4 propusese **bifa + buton separat** —
-   respins la 09.08.2026 in favoarea butonului comutator. Runda 5 propusese **pastrarea celor patru
-   bife individuale sub buton** — respins la 09.08.2026: bifele dispar cu totul.
-
-   **Verificat pe cod la 09.08.2026** (`docs\cercetare\buton_comutator_picture.md`): **tiparul exista
-   deja in suita si se copiaza, nu se inventeaza.** `frm_rulaje.se_modifica_assign`
-   (`COMUN\clase\rulaje.vc2:4716-4773`) comuta exact asa **o singura instanta** de `but_modifica`
-   intre creion si discheta — nu instantiaza a doua clasa. Trei lucruri de retinut din el:
-   - se rescriu **impreuna** `.cpicturedown`, `.cpictureup` **si** `.Picture`, plus `.ToolTipText`,
-     urmate de `.Refresh()`. Numai `.Picture` nu ajunge: hover-ul standard din
-     `buton.MouseEnter` / `MouseLeave` (`_cmd_base.vc2:88-97`) rescrie `Picture` din `cPictureUp` /
-     `cPictureDown`, deci iconita veche ar reveni la primul mouse-over;
-   - numele de fisier se dau **fara cale** (`"save_sus.bmp"`), rezolvate prin `SET PATH` — care
-     include si `GRAFICE`, si `COMUN\GRAFICE` (`Programe\roafacturare.prg:85-108`). Calea relativa
-     `..\grafice\...` din clasa e buna doar la design-time;
-   - imaginile exista: `COMUN\grafice\save_sus.bmp` / `save_jos.bmp` (discheta),
-     `modific_sus.bmp` / `modific_jos.bmp` (creion, perechea folosita de clasa).
-
-   Clasa de salvare din biblioteca se numeste **`but_salveaza`**, nu `but_salvare`
-   (`cmd_butoane.vc2:340-352`); e sursa numelor de imagini, dar nu se instantiaza. Clasa
-   `but_modifica` e la `cmd_butoane.vc2:184-198`. Butoanele **nu** au `do_activeaza` /
-   `do_dezactiveaza` — pe ele se lucreaza direct pe `.Enabled`.
-
-   **Consecinta asupra celor patru bife individuale** (serie / numar / data / scadenta, vezi I):
-   **se elimina**, si **odata cu ele se abandoneaza si conditia lor** de azi
-   (`chkSerieAct.Enabled = !EMPTY(NVL(poRec.numar_act,0))`, `ofacturare_comun.vc2:5736-5750`).
-   Decis de Marius la 09.08.2026: **butonul deschide tot**, fara conditii pe camp. Un singur control,
-   o singura regula. Cat de departe merge „tot” — vezi **decizia 19**: exact cat scrie
-   `modifica_date_factura`, parametru cu parametru.
-10. **Proforma foloseste acelasi formular.**
-11. **Copierea foloseste acelasi formular**, ca document nou, cu antetul editabil.
-12. **Formularul trebuie sa *poata* fi apelat cu sursa deja completata** — din pagina de comenzi cu
-    comanda, si din programul de contracte cu contractul, fara ca utilizatorul sa mai aleaga ulterior.
-    **Nu se integreaza contractele acum**; nu depinde de #10.
-13. **Un singur buton de adaugare a articolelor, cu `xmenu()`** — nu doua butoane separate „adauga
-    tot” si „alege”. Optiunile din meniu se schimba dupa sursa si acopera **comanda, contractul si
-    avizele**, cu alegere selectiva acolo unde are sens (de exemplu o singura rata de contract).
-    Butoanele de linie stau deasupra tabelului.
-14. **Discountul pe articol, procent si valoare absoluta**, amandoua accesibile.
-15. **Data cursului valutar apare doar cand are sens.** Sunt doua concepte diferite, care azi impart
-    acelasi camp mereu vizibil: (a) **factura in valuta**, unde si articolele au pret in valuta, si
-    (b) **factura in lei cu articole care pot avea pret in valuta**, convertite in lei la cursul din
-    data cursului, cu documentul si contabilitatea in lei. Formularul trebuie sa fie **ergonomic si
-    simplu** — campul nu apare cand nu e nimic de convertit.
-
-### Deciziile lui Marius, runda 6 (09.08.2026)
-
-16. **Lista de preturi e disponibila mereu, indiferent de sursa — si liniile suplimentare se pot si
-    sterge.** Pe o factura din comanda sau din contract trebuie sa se poata **adauga si sterge**
-    articole libere din lista de preturi, nu doar articole din sursa. Cazul real, formulat de Marius:
-    clientul a comandat ceva, iar la facturare mai vrea ceva in plus sau vrea sa schimbe — deci
-    documentul trebuie sa poata devia de la comanda, in ambele sensuri. Sursa umple documentul, nu il
-    inchide. Optiunea „Cauta in lista de preturi…" ramane in meniul butonului de adaugare **pentru
-    toate sursele**, inclusiv pentru documentele deja emise care se modifica.
-    **Verificat pe cod** (`docs\cercetare\retur_si_lista_preturi.md`, B): **contractul o are deja**
-    (`crsarticole` e populat de `cursor_preturi` / `cursor_contract` cu lista intreaga, al doilea grid
-    e un adaos, nu o restrictie), **comanda nu** — `cursor_comanda` umple `crsarticole` **doar** cu
-    articolele comenzii (`ofacturare.prg:266-308`). Deci golul real e pe comanda, si e in **continutul
-    cursorului**, nu in vreun `Visible` de buton. Reteta exista deja in produs: ramura de copiere
-    adauga lista de preturi peste cursorul sursei cu `APPEND FROM` (`ofacturare.prg:454-473`) — se
-    generalizeaza ea, nu se inventeaza alta.
-17. **Returul intra in formularul unificat, cu tot cu alegerea facturilor sursa.** Factura de retur
-    facuta din facturi anterioare e un caz de acoperit explicit — lipsea si din mockup, si din
-    proiectare. *Vezi sectiunea N.*
-    **Sunt doua mecanisme distincte, si prima cercetare l-a vazut doar pe al doilea:**
-    (a) **factura de retur ca document** (tipurile 8, 9, si avizul 24) — alege facturile sursa **la
-    nivel de document**, cu selectie multipla, si isi populeaza liniile din ele; **gestiunea si
-    pretul de achizitie vin neschimbate din linia originala**, verificat in `cursor_retur_document`.
-    **Exista deja si merge** — nu se reproiecteaza. Vezi N.1;
-    (b) **`But_retur`** — retur de articole intr-o factura de vanzare normala (tipurile 1, 5, 7, 10),
-    unde factura sursa se alege **per articol**, iar gestiunea nu se mosteneste, ci se alege. Vezi N.2.
-    Sunt doua fluxuri de cod independente, fara punct comun. Decizia 17 le duce pe amandoua in
-    formularul unificat; ce se proiecteaza nou e (b) ridicat la nivel de document, nu (a).
-18. **Facturile emise din ROAAUTO intra in perimetru la modificare.** ROAAUTO le emite din formularul
-    lui, dar scrie tot in `VANZARI_DETALII`, si pe ele trebuie sa se poata adauga articole din lista
-    de preturi. **Emiterea ramane la ROAAUTO** — se unifica doar modificarea.
-    **Verificat pe cod** (`docs\cercetare\roaauto_facturi.md`): acelasi `PACK_FACTURARE`, acelasi drum
-    `VANZARI_DETALII_TEMP` -> `VANZARI_DETALII`, tip de document **`-12`**, pe care editorul lui #6 il
-    **vede deja**, testat pe date reale.
-    **Precizarea lui Marius, 09.08.2026, verificata pe cod**
-    (`docs\cercetare\roaauto_articole_lista_preturi.md`): in ROAAUTO **exista deja adaugarea de
-    articole reale**, pe langa liniile generice — mecanismul „Alte servicii” din `frm_incasare_finala`.
-    Deci descrierea „doar linii sintetice cu `id_articol` negativ” din primul raport e **incompleta**.
-    Nuanta care conteaza pentru proiectare: sursa lui e **nomenclatorul brut**, nu lista de preturi,
-    articolele oferite sunt **fara stoc** (`in_stoc = 0 and in_crm = 1`), iar **pretul se tasteaza
-    manual** — nu vine din politici. Ce se cere e ca **acelasi lucru sa fie posibil si la modificarea
-    documentului**, nu doar la emitere, **si nu numai pentru facturile auto, ci pentru orice tip**,
-    cu **ambele surse**: lista de preturi (cu pret calculat) sau nomenclatorul (cu pret tastat).
-    **Vezi O.**
-19. **Toti parametrii lui `modifica_date_factura` trebuie sa fie modificabili din butonul de antet.**
-    Butonul comutator nu deschide un subset ales de noi: daca procedura Oracle stie sa scrie un camp
-    de antet, formularul trebuie sa aiba controlul prin care acel camp se poate schimba.
-    **Verificat pe cod** (`docs\cercetare\modifica_date_factura_parametri.md`): sunt 15 parametri,
-    din care **14 sunt campuri** — al 15-lea, `V_ID_VANZARE`, e identitatea randului si nu se
-    editeaza. Din cele 14:
-    - **13 au deja control** in `frm_modifica_factura` si se muta ca atare in antetul unificat;
-    - **`V_EFACTURA` nu are niciun control nicaieri** (`ofacturare_comun.vc2:4576` il forteaza `0`
-      la selectie multipla, altfel vine din `Scatter`) — **primeste unul**, e singurul camp nou-nout
-      cerut de decizia asta;
-    - `V_TIP_SAFT` are control, dar ascuns dupa `gl406` (`:5739-5741`) — ramane conditionat, nu se
-      forteaza vizibil.
-    Vezi I-bis pentru contractul procedurii, care impune si **cum** se cheama, nu doar ce se trimite.
-20. **Din nomenclator se aleg si articole gestionabile, si negestionabile.** Filtrul `in_stoc = 0`
-    al lui ROAAUTO **nu se preia** — acolo e o ocolire a subiectului gestiunii, nu o regula de produs.
-    Consecinta acceptata: pe documentele auto vor coexista linii care descarca stoc cu linii care nu
-    descarca, caz care azi nu exista nicaieri. *Vezi J si O-bis, intrebarea 2.*
-    **Intrebarea care insotea decizia — „cu ce cont de venit intra un articol fara politica de pret”
-    — s-a inchis prin cercetare: nu exista cont de venit pe linie.** Vezi **J-bis**.
-
-### Deciziile lui Marius, runda 7 (09.08.2026)
-
-21. **Cand `NOM_ARTICOLE.CONT` e gol pe un articol negestionabil, se aplica un fallback la un cont
-    implicit.** Nu se accepta `NULL` (comportamentul de azi al liniilor „Alte servicii" din ROAAUTO) si
-    nu se refuza adaugarea articolului. Contul anume se alege la implementare.
-    **Atentie la perimetru:** decizia priveste **contul de gestiune** (`VANZARI_DETALII.CONT`). Cand a
-    fost luata nu se stia inca faptul, stabilit mai tarziu in aceeasi runda, ca pe linie exista **doua**
-    conturi cu surse diferite — cel de venit (`NOTE_CONTABILE.SCC`, prin politica de pret) nu e acoperit
-    de aceasta decizie si e inca deschis. *Vezi J-bis.*
-    Ipoteza de la care a pornit Marius — corespondenta 3xx -> 7xx dintr-un tabel — **nu s-a confirmat
-    ca tabel**, dar intentia ei da: legatura articol -> cont de venit exista, prin politica de pret si
-    `NOTE_CONTABILE`, configurata manual de contabil.
-22. **Linia de retur fara factura originala e permisa.** Pe tipurile 8, 9, 24, „Cauta in lista de
-    preturi…" si „Alege din nomenclator…" se comporta ca pe orice alt document — nu apar doar pentru
-    corectii si nu sunt marcate special. Consecinta acceptata: gestiunea si pretul de achizitie se
-    aleg (nu se mostenesc), iar maximul returnabil de pe server nu se aplica acelei linii. *Vezi N.3.*
-23. **Secventierea deciziei 18: `pack_auto` se cerceteaza acum**, inainte de orice estimare, nu cand ii
-    vine randul la livrare. *Vezi O, „Secventierea".* **Rezultat:** riscul tehnic nu exista —
-    `PACK_AUTO` nu citeste `VANZARI` / `VANZARI_DETALII` deloc. Decizia 18 nu mai trebuie sa fie ultima.
-24. ~~**Articolul ales din nomenclator primeste `id_pol`-ul unei politici de pret implicite.**~~
-    **RETRASA in runda 8, inlocuita de decizia 27.** Ramane in plan doar ca sa nu fie reintrodusa:
-    politica implicita ar fi evitat codul nou in `pack_facturare`, dar cu pretul unei intrebari de
-    configurare cu contabilul si al unui cont de venit uniform pentru orice articol adaugat asa.
-    Marius a ales in loc corespondentele `CORESP_CONT_VENCHELT`. *Vezi decizia 27 si J-quater.*
-25. **Butonul de antet deschide tot; ce nu se poate salva pe loc forteaza regenerare.** La a doua
-    apasare, cei **14 parametri** merg prin `modifica_date_factura`, iar orice camp schimbat din
-    **grupul B** (tip document, valuta, zi curs, client, sursa, gestiune sursa, politica de preturi)
-    sau **C** (incasare) **marcheaza documentul pentru regenerare**, aplicata la `Termina`. Decizia 9
-    ramane intacta ca intentie — butonul chiar deschide tot antetul —, dar ruta de scriere se bifurca
-    dupa camp, nu dupa buton. *Vezi G-bis.*
-    **Consecinta pe etape:** in **etapa I** regenerarea nu exista inca, deci acele campuri nu au unde
-    sa se salveze. **Planul le tine blocate in etapa I**, cu explicatie la hover, si le deschide odata
-    cu etapa II. Motivul alegerii, in lipsa unei instructiuni contrare: un camp care se deschide dar nu
-    se salveaza e o capcana — pierderea tacuta a unei modificari e mai rea decat un camp inca blocat.
-26. **Analiticele raman read-only in #13; editarea lor e a lui #6.** Venit/cheltuiala, sectie,
-    responsabil si lucrare se **afiseaza** in sectiunea pliata, cu valoarea de antet, dar nu se
-    editeaza din formularul unificat — cine vrea sa le schimbe trece prin editarea notei contabile.
-    Motivul: sunt deja editabile acolo, **la nivel de linie de nota**, iar #13 le-ar scrie uniform pe
-    tot documentul — doua ferestre care scriu acelasi camp cu semantici diferite, cu risc ca #13 sa
-    suprascrie tacit o diferentiere facuta din #6. **Zero suprapunere intre fire.** *Vezi G-bis.*
-    Asta **nuanteaza decizia 8**: analiticele intra in sectiunea pliata ca **afisare**, nu ca editare.
-
-    **RASTURNATA DE DECIZIA 72 (22.08.2026): analiticele raman EDITABILE**, si la introducere, si la
-    reemitere. Motivul semantic de mai sus ramane consemnat ca **consecinta acceptata**, nu ca
-    restrictie: la reemitere nota se reconstruieste uniform pe document, deci o diferentiere facuta
-    din #6 la nivel de linie de nota se pierde — efect al regenerarii, nu al editabilitatii.
-
-### Deciziile lui Marius, runda 8 (09.08.2026)
-
-27. **Contul de venit vine din corespondente si din nomenclator, nu dintr-o politica de pret
-    implicita. Decizia 24 se retrage.** Regula, pe doua ramuri:
-    - **articol gestionabil** (cont de gestiune de clasa 3xx): contul de venit se ia din tabelul de
-      corespondente `CORESP_CONT_VENCHELT` — `select id_ccv, cont, cont_chelt, cont_venit, sters,
-      dataoras, cont_aprovizionare, cont_diferente from coresp_cont_venchelt`, cautand pe `CONT`
-      (contul de gestiune al liniei) si luand `CONT_VENIT`;
-    - **articol negestionabil**: se foloseste `NOM_ARTICOLE.CONT` **daca e deja un cont de clasa 7xx
-      sau 6xx**; altfel, implicit **704**.
-
-    Motivul respingerii politicii implicite: ea muta problema in configurare (cine creeaza politica,
-    cu ce `SCC`, una sau mai multe) si obliga la o intrebare cu contabilul inainte de orice livrare.
-    Corespondentele exista deja ca date de productie si leaga contul de gestiune de cel de venit —
-    exact relatia cautata, doar ca sub alt nume decat s-a cautat in runda 7.
-27-bis. ~~**Regula din 27 se implementeaza FARA cod nou in `pack_facturare`.**~~ **RELAXATA de decizia
-    34 si inchisa de decizia 35** — pachetul se modifica punctual, si e singurul cod de contare, si la
-    emitere si la editare. Textul de mai jos ramane doar ca istoric al rationamentului.
-    (Marius, runda 8, dupa
-    prima formulare a lui 27). Motivul: pachetul e mare si e folosit de toate produsele suitei — o
-    ramura noua acolo e un risc peste tot, nu doar in ROAFACTURARE.
-    Deci **regula de derivare a contului de venit se aplica pe partea VFP**, inainte ca articolul sa
-    plece spre Oracle, iar `contabilizeaza_articol` ruleaza **neschimbata**. Calea de verificat:
-    VFP calculeaza contul de venit dupa regula de mai sus si alege un `id_pol` a carui nota are deja
-    acel `SCC`, astfel incat `FACT-024` sa nu se mai poata declansa.
-    **Modificarea pachetului ramane planul B**, folosit doar daca se dovedeste ca nu exista nicio cale
-    dinspre VFP. *Vezi J-quater;* fezabilitatea: `docs\cercetare\coresp_cont_venchelt.md`, punctul 8.
-
-    **PREMISA A FOST VERIFICATA (Marius, runda 8):** „in ROAACNPRO, dar si la factura din comanda /
-    contract, se adauga articole fara politica de preturi — de ce nu se poate si aici?" **Raspuns:
-    observatia e reala, dar niciunul din cele doua exemple nu e un articol fara politica.** ROAACNPRO
-    nu cheama deloc `contabilizeaza_articol` (are propria contabilizare, `pack_acn.salveaza_regdoc`);
-    pe contract, articolele vin din `cursor_contract` / `cursor_preturi`, care le livreaza **cu `id_pol`
-    atasat**. `FACT-024` ramane blocantul. *Detalii, cu dovezi: J-quater, punctul 1.*
-    **REZULTAT: calea VFP exista si e mai buna decat modificarea pachetului** — se sprijina pe un RPC
-    existent (`pack_preturi.adauga_politica_pret_art`) si aduce, pe langa `SCC`, si `CU_TVA` /
-    `IN_VALUTA`, pe care un fallback in pachet ar fi trebuit sa le hardcodeze. *Vezi J-quater, punctul 3.*
-    **Planul B (modificarea `pack_facturare`) se abandoneaza.**
-28. **Pe factura ROAAUTO pot exista si alte articole decat cele de pe deviz.** Nepotrivirea de afisare
-    dintre ecranul de deviz si factura retiparita (O, intrebarea 1) **e acceptata**: cerinta e ca
-    **MANOPERA si MATERIALE sa fie conform devizului**, plus orice alte articole adaugate. Nu se cere
-    cod nou in ROAAUTO ca sa aduca ecranul de deviz la zi. *Vezi O, intrebarea 1.*
-29. **Stergerea unei linii venite din comanda ramane fara protectie.** Linia se sterge ca oricare alta;
-    comanda va aparea, corect, ca **facturata partial**. Nu se adauga confirmare, nu se marcheaza
-    „refuzat", nu se ajusteaza numararea acoperirii. *Vezi S4e.*
-30. **Nu se coordoneaza cu firul #6.** #13 **incepe dupa ce #6 se termina**, deci suprapunerea pe
-    fisiere nu se poate produce si nu e nevoie de impartire de perimetru. Consecinta pe interdictii:
-    cele doua fisiere ale lui #6 raman intangibile **cat timp #6 e in lucru**, dar restrictia expira
-    odata cu el, nu cere negociere. Decizia 26 (analiticele read-only in #13) era pastrata aici pentru
-    ca tinea de semantica, nu de coliziunea de lucru — dar a fost **rasturnata de decizia 72**:
-    analiticele sunt editabile, iar suprapunerea de semantica ramane consemnata acolo ca efect asumat
-    al regenerarii. *Vezi „Relatia cu #6".*
-
-### Deciziile lui Marius, runda 9 (10.08.2026)
-
-**31. Datele din Dev nu sunt baza de proiectare.** Fiecare client isi defineste propriile politici de
-pret, fiecare cu nota ei contabila de vanzare salvata pe un `ID_SET`. Orice masurare pe `MARIUSM_AUTO`
-vale ca **dovada ca un mecanism exista** si ca sursa de concluzii **structurale**, niciodata ca harta a
-ce e configurat la client. Nicio decizie de proiectare nu se sprijina pe numarul de politici sau de note
-gasite pe Dev. *(Generalizeaza regula „zero cazuri in date nu e dovada" in ambele sensuri: nici prezenta
-nu e dovada.)*
-
-**32. Intrebarea de raspuns inainte de orice implementare a contului de venit:** cum alege programul nota
-contabila de vanzare la **factura pe baza de comanda**, care **nu are politica de pret**? Daca acel
-mecanism se poate refolosi pentru articolul adaugat ad-hoc, **reteta in 4 pasi din J-quater se
-abandoneaza** in favoarea lui. Vezi J-quater, „Intrebarea deschisa care poate anula toata reteta".
-
-**34. `contabilizeaza_articol` primeste un parametru de cont contabil. Decizia 27-bis e RELAXATA.**
-Marius, 10.08.2026, textual: *„poți să adaugi parametrul contul contabil la `contabilizeaza_articol`."*
-Consecinta: **reteta in 4 pasi din J-quater se abandoneaza.** Nu mai e nevoie de politica tehnica, nici de
-interogarea inversa pe `SCC`, nici de inserarea articolului in politica. VFP calculeaza contul dupa regula
-deciziei 27 si **il trimite direct**.
-**Ce rămâne de proiectat, si nu e „doar un parametru":** contul nu e singurul lucru care venea de pe nota.
-`cursor_articol` aducea si `SCD`, `CU_TVA`, `IN_VALUTA`, `EXPLICATIE`, `ID_VENCHELT`, `ID_SECTIE`, iar bucla
-care il consuma apeleaza **si** `scrie_nota` **si** `descarca_gestiune`. Pe un articol fara politica,
-`FACT-024` sare inainte. Deci e nevoie de **parametru + ramura fara politica**, care sa furnizeze ce
-furniza nota si sa ruleze `descarca_gestiune` **exact o data**. Obiectia rundei 8 („`CU_TVA` si `IN_VALUTA`
-n-au sursa in afara lui `NOTE_CONTABILE`") **nu mai e blocanta, e proiectare** — de reevaluat daca se pot
-deriva din document.
-**Constrangeri de forma, ca sa nu se strice suita:** parametru nou **cu `DEFAULT NULL`**, la finalul listei,
-si ramura inerta cand lipseste — apelanții existenți nu se schimba. `pack_facturare` e comun **intregii
-suite**, deci cere regresie pe ROACONT / ROAGEST / ROACONTRACTE / ROAAUTO / ROAACNPRO, nu doar ROAFACTURARE.
-**Ramura noua nu moșteneste bug-ul de set multi-rand** din L.0-ter.
-**PROIECTATA** — `docs\cercetare\canal_cont_venit_fara_politica.md`, sectiunea „Proiectarea parametrului
-de cont contabil", liniile 13-227. Verdictul, in trei randuri, pentru ca schimba forma modificarii:
-`contabilizeaza_articol` primeste azi **un singur parametru**, `detalii_articol
-VANZARI_DETALII_TEMP%ROWTYPE` — deci contul **nu intra literal pe ea**, ar fi cosmetic. Intra ca
-**coloana noua `VANZARI_DETALII_TEMP.CONT_VENIT VARCHAR2(4) NULL`**, populata printr-un parametru nou
-`V_CONT_VENIT IN VARCHAR2 DEFAULT NULL` la **coada lui `adauga_articol_factura`** (procedura chemata
-direct din VFP), pe care `contabilizeaza_articol` o primeste automat: cei trei apelanti interni fac
-`SELECT * BULK COLLECT` intr-un `TABLE OF ...%ROWTYPE`, deci `scrie_factura2`,
-`scrie_factura_avize_retur` si `scrie_aviz_retur` **nu se ating deloc**.
-> **Corectie de nume, runda 11 — mecanismul insa rezista.** Al doilea apelant e **`scrie_factura_avize`**
-> (`:6708-6749`), nu `scrie_factura_avize_retur`, care nici nu cheama `contabilizeaza_articol`.
-> **Verificat pe cod ca toti trei apelantii reali** — `scrie_factura2` (`:6039-6063`),
-> `scrie_factura_avize` (`:6708-6749`), `scrie_aviz_retur` (`:7097-7106`) — fac intr-adevar
-> `SELECT * BULK COLLECT INTO` un `TABLE OF VANZARI_DETALII_TEMP%ROWTYPE`, **fara lista explicita de
-> coloane**. Deci coloana noua curge automat prin toti trei si **niciunul nu se atinge**; concluzia
-> proiectarii sta, doar doua din cele trei nume erau gresite. In `scrie_factura_avize`, `tab_detalii(i)`
-> e modificat inainte de apel doar pe `.cantitate` / `.id_rata` — `CONT_VENIT` ramane neatins. Efectul cerut de Marius e exact
-acelasi; doar mecanica de livrare difera de formularea literala. Precedentul e in aceeasi semnatura:
-`V_TAXCODE` si `V_LOT` sunt deja doi parametri adaugati ulterior, la coada, cu `DEFAULT NULL`, iar apelul
-VFP e pozitional si se opreste la `V_LOT`.
-Ramura noua se activeaza pe `detalii_articol.cont_venit IS NOT NULL`, **infasoara si blocul `FACT-024`**
-(garda ramane litera cu litera pe ramura veche: o linie fara politica **si** fara cont trimis cade in
-continuare cu `FACT-024`), n-are cursor deloc — deci `descarca_gestiune` ruleaza **exact o data prin
-constructie** si bug-ul de set multi-rand nu se mosteneste, fara sa se repare ramura veche.
-**Doua hardcodari raman decizii deschise pentru Marius**, nu descoperiri: `SCD = '4111'` si `CU_TVA = 1`
-— vezi „Ce ramane de decis" mai jos.
-
-**VERIFICATA ADVERSARIAL** — `docs\cercetare\parametru_cont_contabilizeaza_articol.md`. Proiectarea
-rezista; patru rezultate schimba insa detalii de executie:
-
-- **Parametrul se cableaza in DOUA locuri VFP, nu unul.** `ofacturare.vc2:14069` si `:18089` **nu** sunt
-  o duplicare a aceleiasi metode, cum se presupusese: sunt **doua clase distincte**,
-  `frm_facturare_articole.do_scrie_articole` (`:13967-14195`) si
-  `frm_facturare_articole2.do_scrie_articole` (`:18003-18221`), fiecare construindu-si separat apelul RPC.
-- **`CU_TVA = 1` nu e inofensiv, cum spunea proiectarea.** Actualizarea lui `nproc_tva_max` /
-  `nid_jtva_coloana` / `nTaxCode` e chiar in interiorul lui `IF V_CU_TVA = 1` (`:12537-12558`), iar
-  comparatia `nproc_tva_max < V_PTVA` **se uita doar la rata, nu la suma**. O linie fallback cu TVA real
-  0% ar intra deci in comparatia de maxim si, daca e prima linie a documentului (`nproc_tva_max` porneste
-  `-1`, `:1885`), **castiga** — iar coloana si taxcode-ul ei ajung sa descrie **linia de discount a
-  intregii facturi** (`:6164-6184`). Combinatia e ingusta (linie scutita + discount global + acea linie e
-  „maximul" de pana atunci), dar efectul e real. Motivul pentru care decizia ii apartine lui Marius e
-  acum concret, nu formal.
-- **`INSERT INTO VANZARI_DETALII ... FROM VANZARI_DETALII_TEMP` are lista de coloane explicita** — 24 de
-  coloane, `PACK_FACTURARE:13705-13757`, in `scrie_in_vanzari`. Deci daca se vrea `CONT_VENIT` pastrat si
-  dupa fapt in `VANZARI_DETALII`, **lista trebuie extinsa explicit**; altfel coloana traieste doar in
-  `VANZARI_DETALII_TEMP` si `ACT_TEMP`.
-- **Articolul compus nu e o gaura in proiectare** — e exclus structural, nu prin presupunere. `COMPUS`,
-  asa cum il citeste `contabilizeaza_articol` (`:7279-7283`), e definit in `VCRM_POLITICI_PRET_ART` ca
-  proprietate a **perechii (articol, politica)**, identificata prin `ID_POL_ART`. O linie fara politica
-  n-are `ID_POL_ART`, deci intrebarea nu se poate pune.
-
-**Golul `ntip = 4` — INCHIS in runda 11.** Cercetat (`docs\cercetare\gol_ntip4_factura_din_avize.md`) si
-**verificat adversarial** (`docs\cercetare\verif_goluri_ntip_aviz.md`). Trei rezultate, dintre care doua
-schimba ce trebuie scris in pachet:
-
-- **`ntip = 4` e exclus structural — dar nu prin garda pe care o presupunea proiectarea.** Blocajul nu e
-  `FACT-024` din `contabilizeaza_articol`, ci **o functie mai devreme**: `adauga_articol_factura`, ramura
-  `WHEN ntip = 4` (`:5080-5103`), cauta randul sursa din `VANZARI_DETALII` prin `A.ID_POL = V_ID_POL`
-  **fara handler de exceptie**. Cu `V_ID_POL = NULL` — exact cazul liniei fara politica — comparatia nu
-  se poate potrivi niciodata, deci apelul cade cu `ORA-01403` **la adaugarea articolului**, in bucla
-  `do_scrie_articole` (`ofacturare.vc2:13967-14106`), care ruleaza intotdeauna inaintea `Do Case`-ului
-  (`:14282`). Linia nu ajunge niciodata la `contabilizeaza_articol`; ramura noua n-are nimic de tratat
-  acolo, si **nu are nevoie de garda defensiva** (ar fi redundanta peste doua straturi independente).
-- **GOL REAL, mai ingust decat parea, dar efectiv atins: `SCD` pe avize.** Ramurile de aviz care chiar
-  ajung la `contabilizeaza_articol` — `ntip IN (28,29)` → `SCD = '461'`, restul avizelor „simple"
-  (`21, 22, 24, 27`) → `SCD = '418'` (`:7413-7422`) — **sunt accesibile cu `cont_venit` populat**, pentru
-  ca `adauga_articol_factura` nu cere `id_pol` pe niciunul din ele. Ramura noua, care ia `SCD` din
-  optiunea deciziei 36 (`4111`), l-ar scrie **necontitionat de `ntip`** → **cont contabil gresit pe
-  aviz**. Deci ramura noua **alege `SCD` dupa `ntip`**: `'461'` pentru `IN (28,29)`, `'418'` pentru
-  celelalte avize atinse, si abia pe restul optiunea `RF_CONT_ART_FARA_POL`.
-  **Verificarea a restrans lista:** `ntip IN (23,25,30,41,42,47)` **nu ajung deloc** la
-  `contabilizeaza_articol` — sunt deviate mai devreme, in `scrie_factura2`, spre `transfera_articol`
-  (`23,25,30,41`) sau direct spre `descarca_gestiune` (`42,47`). Golul nu li se aplica.
-- **Al doilea gol confirmat: garda `ntip = 46`.** `nTipNotaPlata` **este** `46`, iar `scrie_nota` e
-  sarita azi intentionat pentru el (`IF ntip <> nTipNotaPlata`, `:7441`). Un articol fara politica poate
-  ajunge si pe acest tip. **Ramura noua trebuie sa reproduca garda** — altfel scrie o nota care azi e
-  sarita deliberat.
-
-**CORECTIE la proiectare — al doilea apelant intern e numit gresit peste tot.** Nu
-`scrie_factura_avize_retur`, ci **`scrie_factura_avize`** (`:6692-7058`) — care e chiar handler-ul Oracle
-al lui `ntip = 4`, apelat din `ofacturare.vc2:14318`; apelul catre `contabilizeaza_articol` e la `:6858`,
-in interiorul lui `IF articole_aviz(j).custodie = 1`. `scrie_factura_avize_retur` (`:6264-6657`) **nu
-cheama deloc** `contabilizeaza_articol` — insereaza direct in `VANZARI_DETALII_TEMP` din
-`VANZARI_DETALII`. Iar `scrie_aviz_retur` (`:7085-7171`) **n-are niciun apelant VFP gasit** in tot
-`COMUN\` si in tot proiectul — posibil cod mort sau apelata din alt produs. Greseala e propagata in
-`canal_cont_venit_fara_politica.md:67` si `nota_contabila_fara_politica.md:103`; se citeaza de acum
-lista corectata de mai sus.
-
-**Nota de metoda, valabila pentru toate rapoartele:** presupunerea ca liniile din exportul
-`PACK_FACTURARE` au un **offset constant `+17`** fata de rapoartele vechi e **falsa**. Nu exista offset
-universal (masurat: `+9` fata de `nota_contabila_fara_politica.md`, `0` fata de alte rapoarte). Numerele
-de linie se **re-verifica direct pe fisier**, niciodata prin corectie presupusa.
-
-**Nu se implementeaza** — decizia 30 sta, #13 incepe dupa #6.
-
-**33. Mockup-ul nu se republica la v7.** Se duce la **v8** cu rezultatele verificarilor rundei 9 si abia
-atunci se republica — o singura citire a HTML-ului, o singura republicare. Url-ul artifact rămâne la v6
-pana atunci.
-
-### Deciziile lui Marius, runda 10 (10.08.2026)
-
-**35. Un singur cod de scriere contabila: `pack_facturare`, si la emitere si la editare.
-`oscrie_in_fisiere` NU se foloseste in #13.** Marius, 10.08.2026, textual: *„nu doresc folosirea scrie in
-fisiere ci doar `pack_facturare` la emitere si la editare pentru ca nu vreau sa intretin doua coduri."*
-
-**Ce anuleaza:** impartirea propusa la finalul rundei 9 — „emiterea prin parametrul deciziei 34, editarea
-prin canalul generic catre `ACT_TEMP`, care nu cere nimic in pachet" — e **respinsa**. Canalul
-`actactan` / `tact` → `COMUN\programe\oscrie_in_fisiere.prg` → `pack_contafin.SCRIE_IN_ACT` exista si e
-folosit azi in productie de fluxul de editare al lui #6, dar folosirea lui in #13 ar insemna **doua
-implementari ale aceleiasi reguli de contare** — una in pachet, pe emitere, alta in VFP, pe editare —
-tinute in pas manual la fiecare schimbare a regulii deciziei 27. Motivul e de **intretinere**, nu tehnic,
-si nu se reargumenteaza cu „canalul exista deja".
-
-**Ce impune:** editarea prin regenerare (etapa II) scrie pe **exact acelasi drum** ca emiterea —
-`scrie_factura2` → `contabilizeaza_articol`, cu parametrul de cont de la decizia 34. Nu exista ramura de
-scriere separata pentru documentul reemis si nu exista editare directa a randului din `ACT_TEMP` din #13.
-
-**Ce nu atinge decizia 35:**
-- **fluxul lui #6** ramane cum e (`ofacturare_comun.vc2:3796-3821` → `frm_modific2024`) — decizia priveste
-  #13; retragerea lui e alt subiect si alt perimetru — **inchis de decizia 38: coexista, se decide dupa
-  ce #13 livreaza**;
-- **stergerea** documentului vechi din S9 ramane pe drumul existent (`do_sterge` → `oscrie_in_fisiere` +
-  `pack_contafin.finalizeaza_stergere_nota`), pentru ca acolo **nu exista al doilea cod de intretinut**:
-  `pack_facturare` nu are echivalent de stergere a notei, iar drumul de stergere e comun intregii suite.
-  *Presupunere declarata, de infirmat daca Marius vrea si stergerea mutata in pachet — ar fi alt mandat si
-  alta suprafata de risc.*
-
-**Ce castiga:** regula deciziei 27 traieste intr-un singur loc, si o corectie pe ea nu trebuie facuta de
-doua ori. **Ce costa:** etapa II nu mai are cale ieftina — depinde de parametrul deciziei 34 exact cat
-depinde etapa I, deci **S9 nu poate porni inaintea parametrului**, iar regresia pe suita se plateste o
-singura data, dar obligatoriu.
-
-**36. Cele doua campuri ramase fara sursa pe ramura fara politica — decis.** Verificarea a stabilit intai
-ca **nu exista in cod nicio sursa alternativa** pentru ele: nici optiune de firma existenta, nici cont pe
-partener, nici flag de scutire pe articol sau client (`parametru_cont_contabilizeaza_articol.md`,
-sectiunea 4). Deci sunt decizii de produs, si Marius le-a luat asa:
-
-- **`SCD` — fix, dar citit din configurare, nu hardcodat.** O optiune de firma, cu **`4111` ca implicit**.
-  **PROIECTATA** — `docs\cercetare\optiune_firma_cont_debit.md`. **Costul e mult mai mic decat parea:
-  tiparul exact exista deja in productie, in acelasi pachet, pe acelasi camp.**
-  `pack_facturare.scrie_incasare2` (`PACK_FACTURARE:13161-13234`) isi ia `V_SCD` in **trei niveluri**:
-  parametru explicit daca a fost dat → **optiunea de firma** (`RF_CONT_INCASARE_BONFISCAL` s.a.m.d., cate
-  una per tip de incasare) → **constanta hardcodata** daca optiunea lipseste. Se copiaza identic, si se
-  inlocuieste punctual linia `SCD := '4111'` din proiectarea ramurii noi.
-  Mecanismul are 15+ ani: tabelul `OPTIUNI` (458 randuri azi), `PACK_SESIUNE.getoptiunefirma`, si un
-  **ecran de editare complet generic** peste tabel (`frm_optiuni` / `frm_optiuni_nou`,
-  `COMUN\clase\oOptiuni.vc2`) — deci **cheia noua nu cere niciun cod VFP nou**, doar randul in tabel.
-  Nu exista `ID_FIRMA`: fiecare firma are schema Oracle proprie, deci `OPTIUNI` din schema de conexiune
-  **este** deja „optiunile firmei curente".
-  **Dubla plasa de siguranta, si asta acopera integral cerinta lui Marius:** implicitul `4111` traieste si
-  in randul din `OPTIUNI` (scris de migrare, editabil fara recompilare), si hardcodat langa
-  `getoptiunefirma` — deci si o instalare veche fara migrare, si un rand golit din ecran cad tot pe `4111`.
-  `getoptiunefirma` intoarce `''` cand nu gaseste, ceea ce in Oracle e `IS NULL`, deci ambele cazuri se
-  trateaza cu aceeasi conditie.
-  **`ASCD` nu trebuie atins** — se calculeaza deja din `V_SCD`, deci primeste automat valoarea corecta
-  indiferent de sursa.
-  **`PROGRAME` se pune larg, nu doar `ROAFACTURARE`** — intrebarea a ramas deschisa in raport, dar se
-  inchide combinand-o cu masuratoarea de regresie: apelul catre `adauga_articol_factura` traieste in
-  `COMUN\clase\ofacturare.vc2`, fisier prezent si folosit in **toate cele sapte produse**, deci ramura noua
-  e atinsa de toata suita, exact ca `RF_CONT_INCASARE_*` (care listeaza sase produse).
-- **`CU_TVA` — derivat din cota liniei**, nu fixat: `1` daca `proc_tvav > 0`, altfel `0`. Asta **elimina
-  prin constructie** efectul gasit la verificare: o linie scutita nu mai intra in comparatia de maxim din
-  `nproc_tva_max`, deci nu mai poate imprumuta coloana si taxcode-ul ei liniei de discount a intregii
-  facturi. Pretul e o regula in plus in pachet si un comportament **diferit de ce face azi nota** pentru o
-  linie scutita — diferenta e intentionata, nu accidentala, si se noteaza ca atare la testare.
-
-Deci lista parametrilor noi ramane la **unul singur** (`V_CONT_VENIT`): `SCD` vine din configurare, iar
-`CU_TVA` se deriva in pachet din date deja prezente pe rand.
-
-**37. Cheia optiunii si validarea — decise (10.08.2026).**
-- **Cheia: `RF_CONT_ART_FARA_POL`**, aliniata la familia `RF_CONT_INCASARE_*` — adica exact optiunile care
-  alimenteaza azi `SCD` in acelasi pachet. Cele cinci apar astfel **grupate alaturi in ecranul de
-  optiuni**, ceea ce le face inteligibile impreuna. Incape in `OPTIUNI.VARNAME` (`VARCHAR2(30)`).
-  `VARTYPE = 'CHARACTER'`, `VARVALUE = '4111'`, `PROGRAM = 'ROAFACTURARE'`, `PROGRAME` larg (vezi 36).
-- **Fara validare de cont**, nici la salvare, nici la citire — se copiaza tiparul existent. Motivul:
-  niciuna dintre optiunile de tip cont nu e validata azi nicaieri, iar `RF_CONT_INCASARE_*` traieste asa
-  de 15 ani; a introduce validare aici ar fi o imbunatatire noua, nu continuarea unui tipar, si ar cere
-  fie cod nou in pachet, fie prima logica per-cheie din ecranul generic `COMUN\clase\oOptiuni.vc2` —
-  fisier al intregii suite. **Garda gratuita ramane lungimea:** un `VARVALUE` peste 4 caractere da
-  `ORA-12899` la `INSERT INTO ACT_TEMP`, deci esec zgomotos, nu cont tacut gresit.
-  *De consemnat la testare ca risc acceptat constient:* un cont inexistent in planul de conturi, scris din
-  greseala in ecran, ajunge pe nota neschimbat — acelasi risc pe care produsul il are deja, nu unul nou.
-
-### Deciziile lui Marius, runda 11 (10.08.2026)
-
-**38. Fluxul de editare al lui #6 nu se retrage odata cu #13. Coexista, si se decide mai tarziu.**
-Intrebarea pusa la finalul rundei 10 — daca decizia 35 („un singur cod de scriere contabila") obliga la
-rerutarea editarii lui #6 pe acelasi drum — primeste raspuns: **nu acum**. #6 ramane pe editarea directa
-a randului din `ACT_TEMP` (`ofacturare_comun.vc2:3796-3821` → `frm_modific2024` → `oscrie_in_fisiere`),
-#13 merge pe regenerare prin `pack_facturare`. Cele doua traiesc separat, pe povesti separate.
-**Ce inseamna concret:** decizia 35 se citeste strict ca perimetru al lui #13 — nu se proiecteaza si nu
-se planifica nicio retragere a fluxului lui #6 in aceasta poveste, si nu se adauga in #13 nicio piesa
-care sa pregateasca acea retragere. Subiectul **nu e inchis definitiv**: se redeschide dupa ce #13
-livreaza regenerarea si se vede in practica daca intretinerea celor doua drumuri doare cu adevarat.
-Pana atunci nu se reargumenteaza in niciun sens.
-
-**39. S4 ramane integrala: se desface si registrul de cantitate ramasa.** Proiectarea rundei 11 a aratat
-ca `crsarticole` nu e doar sursa gridului, ci **registrul cantitatii ramase de facturat** — scris de
-`do_sterge` la stergerea unei linii (`ofacturare.vc2:14640-14669`) si citit prin
-`Calculate Sum(cantitate) To lnCantitateRamasa` ca sa se decida **inchiderea automata** a comenzii /
-avizului (`:14303-14311`, `:14334-14338`). Varianta ieftina ar fi fost sa se restranga S4 la lista de
-preturi; Marius a ales varianta intreaga: **bookkeeping-ul se decupleaza de cursorul incarcat in masa**,
-ca sa poata disparea incarcarea si pe comanda si pe aviz.
-**Consecinta, declarata explicit:** S4 nu mai e o poveste de performanta pe formular, ci atinge
-**inchiderea automata a documentelor sursa** — cea mai mare suprafata de regresie din etapa I, si
-singura care poate lasa o comanda deschisa (sau o poate inchide prematur) fara ca operatorul sa vada
-ceva. Criteriul de „gata" al lui S4 include de acum, obligatoriu, **paritate pe inchiderea automata**:
-acelasi document sursa, aceleasi linii facturate partial, acelasi `INCHISA` la final, pe fiecare tip cu
-document sursa. Registrul nou trebuie sa fie sursa unica — nu o a doua copie tinuta in pas cu prima,
-altfel povestea introduce exact tipul de dublura pe care decizia 35 il refuza in alta parte.
-
-**40. Bug-ul de dezalocare POS se repara in S3b, in trecere.** Vezi `L.4`. Consecinta acceptata: diff-ul
-lui S3b **nu mai e o mutare pur mecanica**, deci testarea lui trebuie sa acopere si dezalocarea POS pe
-calea veche, nu doar paritatea de emitere.
-
-**41. Sectiunea pliata are DOUA comutatoare, nu unul si nu cinci.** Grupul de **incasare** — singurul cu
-efecte laterale reale (alocare / dezalocare de numere) si singurul blocat pe document emis prin decizia
-25 — primeste comutator propriu. Delegat/transport, adresa, text aditional si analiticele stau impreuna
-sub al doilea. Motivul e izolarea riscului: garda de non-alocare la toggle
-(`opt_incasat.ProgrammaticChange`) se scrie si se testeaza **intr-un singur loc**, nu pe cinci stari.
-
-**42. Validarea de curs valutar se restrange la valuta articolului cautat.** Pe varianta filtrata a
-cursoarelor, `verifica_cursuri_valute` nu mai ruleaza global, ci doar pe valuta randului adus.
-**Schimbare de comportament asumata:** un curs lipsa pe **alta** valuta nu mai e semnalat la deschiderea
-formularului, ci abia cand se ajunge la un articol pe acea valuta. Se consemneaza la testare ca
-diferenta intentionata fata de azi, nu ca regresie.
-
-#### Puncte marunte ramase din proiectarile rundei 11 — se merge pe recomandare daca Marius nu spune altfel
-
-Nu blocheaza nimic; se inchid la implementarea povestii respective. Enumerate ca sa nu se piarda intre runde.
-
-| # | Punct | Poveste | Se merge pe |
-|---|---|---|---|
-| a | Textul exact al tooltip-ului pentru grupul de incasare blocat (cel pentru analitice cade odata cu decizia 72) | S3b | formularea propusa in raport, sectiunea 5.3 |
-| b | Eager vs. lazy pentru lookup-urile Oracle din `Init` (delegat / masina ultimei facturi, casa) | S3b, S3 | **lazy**, ca sa nu se plateasca la fiecare depliere; deschis si in `s3_portare_antet.md` §5 |
-| c | `_checkbox1` vs. `chkDetaliat` — care devine campul unic de „listare detaliata" | S3b, S1 | **INCHIS (runda 12)**, pe cod: sunt **doua controale distincte** in `frm_alte_date`, nu o duplicare — nu exista nimic de ales. `docs\cercetare\s4c_discount_in_grid.md`, sectiunea 11 |
-| d | Forma lui `toSursa`: obiect scatter (duck-typing) sau clasa dedicata | S3c | **duck-typing**, ca azi — o clasa noua n-ar schimba nimic functional |
-| e | Conversia comenzii si a contractului: un commit sau doua | S3c | **un singur commit** — ating aceleasi trei fisiere comune, separarea nu reduce regresia, doar amana testarea pe ROACONTRACTE |
-| f | `goComanda = ''` redundant la `Cw3.do_actiune` dupa conversie | S3c | **se lasa**, marcat explicit „intentionat" in diff, ca sa nu para omisiune la review |
-| g | Contractul are doua meniuri (articole vs. rate): eticheta generica sau diferentiata pe `OPT_FACTURARE` | S4b | **diferentiata** — „Alege ratele de facturat…" e gresita pe contractele cu articole |
-| h | „Alege facturile de returnat…" ramane doar la antet sau capata incarcare aditiva din bara | S4b | **ramane la antet** in etapa I; mutarea e o poveste separata |
-| i | `But_renunt1` / `But_reset1` primesc `Caption` pentru consistenta cu bara etichetata | S4b | **da** — decizia 13 cere etichete, nu iconite mute; exceptia ar fi inconsecventa |
-| j | Ordinea si formularea optiunilor din `xmenu()` per sursa | S4b | tabelul din sectiunea 3 a raportului, ca propunere |
-| k | UX-ul contractului cu doua surse pe acelasi grid conceptual (`crsarticole` filtrat + `crsarticole1`) | S4 | de confirmat vizual la mockup, nu pe hartie |
-
-### Ce s-a dovedit ca exista deja (deciziile 10, 11, 12, 14)
-
-Verificat pe cod la 09.08.2026; rapoartele complete sunt in `docs\cercetare\`
-(`proforma_copiere_puncte_intrare.md`, `discount_pe_articol.md`,
-`inventar_controale_formulare.md`, `import_roris_roaacnpro.md`).
-
-- **Proforma nu e tip de document si nu are formular propriu.** E valoarea `PROFORMA` din combo-ul
-  „Tip document” (`ct_clb_fdoc._combobox1`, `RowSource = "FACTURA,PROFORMA,BON FISCAL"`,
-  `ofacturare.vc2:8745-8754`), care seteaza `nIdTipDoc = 23` si, prin setter,
-  `eProforma = 1` (`ofacturare_comun.prg:593-599`, `nIdTipDocProforma = 23` la `:104`). Deci intra in
-  formularul unificat **fara nimic de portat**. Specific proformei si de pastrat: serie si numar
-  proprii, realocate la comutarea din combo (`ofacturare.vc2:9415,9427-9428`); **fara nota contabila
-  si fara atasamente**, prin garzile `poDate.eProforma = 0`
-  (`ofacturare.prg:1960,1996,2052,2063,2103`); raport propriu (`:1638-1643`, `COMUN\Rapoarte\proforma.fr2`);
-  relistarea pe cale separata (`ofacturare_comun.vc2:7230-7264`).
-- **Copierea foloseste deja acelasi formular, cu antetul editabil.** `do_copiaza` -> `copiere_factura`
-  -> `factureaza(tip, toFactura)` -> `frm_date_factura` precompletat de
-  `completeaza_setari_document(toFactura, .T.)` (`ofacturare_comun.prg:362-412`). Numar nou se aloca
-  **intotdeauna**, neconditionat de copiere (`ofacturare.prg:208,211`). Nimic din traseu nu blocheaza
-  controale de antet.
-- **Butonul de facturare din pagina de comenzi exista deja in ROAFACTURARE**: `ct_comenzi.do_factura`
-  (`ocomenzi.vc2:1580-1596`) face `SCATTER NAME goComanda MEMO` si cheama `facturare_comenzi` ->
-  `factureaza(3)`; butonul `But_factura1` (`ocomenzi.vc2:932-937`) e ascuns cand comanda e deja
-  facturata (`:2199-2203`), si e montat pe Page5 (`ofundal_facturare.vc2:604`, `Ferestre\fundal.sc2:206`).
-- **Precompletarea contractului vine din programul de contracte** (`ROACONTRACTE`):
-  `ferestre_contracte.vc2:1538-1549` si `:1605` -> `facturare_contracte` -> `factureaza(2/6/52)`,
-  cu contractul deja completat — exact ce cere decizia 12, si **functioneaza azi**. In ROAFACTURARE
-  exista, in plus, calea din meniu **fara** precompletare (`ofundal_facturare.vc2:886-897`), unde
-  utilizatorul alege contractul in formular. Cele doua coexista; #13 nu adauga o lista de contracte
-  in ROAFACTURARE si **nu depinde de #10**.
-- **Discountul pe articol are deja si procent, si valoare — dar intr-un dialog separat.** Vezi K.
-- **Deblocarea antetului exista deja**, dar sub forma a patru bife individuale in
-  `frm_modifica_factura`; in formularul unificat ele sunt inlocuite de un singur buton comutator.
-  Vezi I.
-- **Data cursului valutar nu e conditionata azi de valuta.** Vezi M.
-
-### Canalul de precompletare e un global, nu un parametru
-
-`factureaza(tnTip, toFactura)` (`ofacturare.prg:81-82`) nu are parametru pentru sursa: comanda si
-contractul se transmit prin globalele `goComanda` / `goContract`, citite in `oDateFactura.Init`
-(`ofacturare_comun.prg:301-328` comanda, `:261-297` contract). De aceea calea generica de comanda e
-obligata sa scrie explicit `goComanda = ''` inainte de apel (`ofundal_facturare.vc2:899-902`), altfel
-ar ramane precompletata cu ce era in sesiune. **Calea generica de contract nu face resetarea
-simetrica** (`:886-897`) — de verificat daca `goContract` poate ramane populat intr-o sesiune si
-precompleta tacit un document nou. Decizia 12 se implementeaza corect prin **parametru explicit**, nu
-prin inca un global.
-
-## Relatia cu #6 — transata: #13 incepe dupa #6
-
-`plan_06_editare_factura.md` rezolva **aceeasi problema de fond** (o factura emisa nu se poate
-corecta fara ca notele si rulajele sa ramana in urma) pe calea opusa: editare directa in
-`frm_modific2024`, cu `id_fact` pastrat. Planul #6 a respins explicit regenerarea, cu motivul ca
-*"emiterea face verificari de stoc si alte protectii dependente de tipul documentului; la
-regenerare acestea ar esua pe date care intre timp s-au schimbat"*.
-
-Argumentul acela **cade partial** daca stergerea si reemiterea se fac in aceeasi tranzactie, in
-ordinea corecta — vezi sectiunea "Stocul" mai jos. Dar nu cade complet: raman verificarile care nu
-tin de stoc (configurare politica / contract / cota TVA, vezi `adauga_articol_factura`).
-
-Cele doua nu se exclud tehnic, dar **se suprapun pe aceleasi fisiere** si, mai important, produc
-doua semantici diferite pentru "am corectat factura":
-
-| | #6 — editare directa | #13 — regenerare |
-|---|---|---|
-| Punct de intrare | registru jurnal + formular facturi | formularul de facturi |
-| Utilizator vizat | contabil | operatorul de facturare |
-| `ID_FACT` | pastrat prin constructie | **pastrat, prin cerinta** (vezi E) |
-| Serie, numar, data | neschimbate | neschimbate (cale proprie, vezi F) |
-| `COD`, `ID_VANZARE` | `COD` nou, `ID_VANZARE` pastrat | ambele noi |
-| Notele si rulajele | rescrise din formularul de note | **regenerate din articole**, ca la emitere |
-| Documentul sursa (comanda/aviz/contract) | neatins | **eliberat si reconsumat** |
-| Efort | mediu (in curs, S1–S3 livrate) | mare |
-
-**Decizia lui Marius (09.08.2026): coexista, cu roluri separate.** #6 ramane calea contabilului
-pentru corectii pe nota — si e singura cale posibila din registrul jurnal din ROACONT/ROAGEST, unde
-nu exista contextul de facturare (`poDate`, `crsfactura`, politici, serii). #13 devine calea
-operatorului de facturare: modific documentul, notele si rulajele se refac singure.
-
-**Coliziune de lucru: nu exista. DECIS (decizia 30): #13 incepe dupa ce #6 se termina.** Sesiunea de
-la #6 a atins `COMUN\clase\ofacturare_comun.vc2` (`do_editare_factura`, `:3715-3869`), a creat
-`COMUN\programe\ofacturare_editare.prg` si a adus `omodificari.vcx` in proiect (`97d1613`) — dar
-implementarea lui #13 nu porneste cat timp acestea sunt in lucru, deci **nu e nevoie nici de
-impartire de perimetru, nici de coordonare intre fire.** Cele doua buguri semnalate (L.0 si L.0-bis)
-raman semnalate catre #6, nu reparate din #13.
-Decizia 26 — analiticele read-only in #13 — era tinuta aici pe motiv semantic (#6 le editeaza la nivel
-de linie de nota, #13 le-ar scrie uniform pe tot documentul), nu de calendar. **Decizia 72 o rastoarna**:
-analiticele sunt editabile, iar scrierea uniforma pe document e acceptata ca efect al regenerarii.
-
----
-
-## Ce s-a stabilit din cod
-
-### A. Formularul unificat exista deja ca prototip, oprit din 2017
-
-`frm_facturare_articole2` (`COMUN\clase\ofacturare.vc2:15741-19355`) **este** formularul cerut la
-punctul 13, la nivel de controale:
-
-- are deja campurile de antet mutate din `frm_date_factura`: `Clb_serie_act1`, `Clb_nract`,
-  `Clb_dataact`, `Clb_zi_curs`, `Clb_data_scadenta`, `Ct_clb_nume_client`, `Ct_clb_responsabil`,
-  `Ct_clb_sectie`, `Ct_clb_lucrare`, `Ct_clb_venchelt`, `Ct_clb_altele`, `Ct_clb_valuta`,
-  `clb_fdoc`, `Ed_tx_simplu1` (`:15744-15812`);
-- **nu** are `grd_articole`, `grd_contracte`, `cb_politici_preturi`, `cb_contracte`, casetele de
-  cautare `txtCodmat` / `txtArticole` — adica exact partea care azi consuma incarcarea in masa;
-- are grid editabil in linie, cu combouri `combosql` din `cautare.vcx` pe `cCodMat.cboCodmat`,
-  `cDenumire.cCboDenumire`, `cGestiune.cCboGestiune` (`:16751-16881`), plus `But_nou1`;
-- e lansat de `factureaza2` (`COMUN\programe\ofacturare.prg:590-1080`), care se cheama numai daca
-  `gnFacturareNou = 1` **si** utilizatorul raspunde DA la un `AMESSAGEBOX` (`:87-92`).
-
-**Cat de mort e prototipul.** In `factureaza2`, deschiderea formularului de date si incarcarea
-articolelor sunt inchise cu `If .F.`: `:707-711` (formularul de date), `:826-829` (executia
-cursorului de articole), `:838` (verificarea de "nu exista articole"), `:985-1008` (`crspolitici`
-si `crscontracte`). `Init`-ul lui `frm_facturare_articole2` are 92 de linii (`:18988-19080`) fata
-de 368 la `frm_facturare_articole` (`:14976-15344`) si **nu completeaza niciun camp de antet** —
-controalele sunt acolo, logica nu.
-
-**Drift-ul dintre `factureaza` si `factureaza2`** (fork din 08.06.2017, nesincronizat): lipsesc din
-`factureaza2` tipurile 51 si 52, ramura `llCopiere` / `toFactura`, completarea `codmatc` /
-`codnc8` / `codcpv`, `GetInstitutiePublica`, `GetSoldClient`, filtrul `RORTC` pe `jtva_coloane`,
-tratarea `eProforma`, `verifica_numar(16, ...)` pentru chitanta, `cursor_retur_document`,
-`cursor_avize` cu tip 23. **Concluzie: nu se continua cu doua proceduri.** Se merge pe una singura,
-cu un parametru de mod, altfel divergenta se reia imediat (exact tiparul care a produs problema
-reparata la #8).
-
-### B. Nu doua formulare, ci patru
-
-Fluxul de azi are **patru** ferestre. Runda 2 numarase trei; a patra, `frm_articol_factura`
-(`ofacturare.vc2:1108-2659`), se deschide **pentru fiecare articol adaugat**, din
-`do_adauga_articol` (`:12873`, `ofrmadarticol.Show(1)`, doar daca `!tlImplicit`) — si e locul in care
-se introduce azi discountul pe linie (vezi K). Formularul unificat o desfiinteaza, deci campurile ei
-trebuie sa aiba unde sa se mute.
-
-Celelalte trei:
-
-1. `frm_date_factura` (`ofacturare.vc2:8482-9869`) sau `frm_date_aviz` (`:6566-7618`) —
-   17, respectiv 13 metode `do_cauta_*`, plus `do_schimba_tipdoc`, `inainte_de_do_termin` si un
-   `Init` de 234 / 247 de linii;
-2. `frm_facturare_articole` (`:10968-15739`) — compunerea;
-3. `frm_alte_date` (`COMUN\clase\ferestre_cere_date.vc2:2219-3353`) — **aratat dupa** confirmarea
-   articolelor, din `inainte_de_do_termin` (`ofacturare.vc2:14921-14941`): delegat, auto, agent,
-   adresa de facturare, incasare (numerar / chitanta / bon fiscal / POS), text aditional. Aloca si
-   numere proprii (bon fiscal, POS, chitanta).
-
-Punctul 13 vorbeste doar despre primele doua. **Decizia 7 le aduce pe toate trei**: `frm_alte_date`
-intra in formular, ca zona pliata. Recomandarea din runda 2 („ramane dialog in prima etapa”) e
-respinsa.
-
-Ce inseamna concret, din inventarul de controale: se muta patru grupuri — delegat si transport
-(`Ct_clb_delegat`, `Ct_clb_masina`, `Ct_clb_agent`, `Clb_dataora_exp`), incasare (radiogrupul
-`opt_incasat` cu patru optiuni, `Cb_casa`, `Clb_serie_chit`, `Clb_nrchit`, `Clb_incasat`,
-`cmdModificaBon`, `chkPOS`, `chkDetaliat`, `cboTipFactura`), adresa de facturare
-(`clb_adresa_facturare`) si textul aditional (`Ed_tx_simplu1`) —
-`ferestre_cere_date.vc2:2343-2638`. **Masina de stari se muta ca atare, nu se rescrie**:
-`actualizeaza_tipincasare` (`:2698-2856`) comuta vizibilitatea pe cele patru valori si aloca sau
-dezaloca numarul de chitanta (`:2783`), de bon fiscal (`:2807`) sau de POS (`:2844`). Riscul semnalat
-in runda 2 nu dispare, dar e localizat: **alocarea de numere trebuie sa ramana legata de aceleasi
-evenimente**, nu de deschiderea formularului.
-
-Peste ele coboara analiticele din antet (decizia 8): `Ct_clb_venchelt`, `Ct_clb_sectie`,
-`Ct_clb_responsabil`, `Ct_clb_lucrare`.
-
-### C. Incarcarea articolelor — de ce dureaza si ce inlocuieste
-
-`factureaza` executa, inainte de a deschide compunerea, **un singur apel** care aduce toate
-articolele disponibile: `pack_facturare.cursor_preturi` (`ofacturare.prg:281-286`, corp la
-`PACK_FACTURARE:2121+`), respectiv `cursor_contract` / `cursor_comanda` / `cursor_avize` /
-`cursor_gestiune` / `cursor_retur` dupa tip (`ofacturare.prg:265-311`). Rezultatul intra in
-`crsarticole` si tine gridul de sus.
-
-`cursor_preturi` **nu are filtru pe articol** — semnatura e
-`(V_DATA_CURS, V_TIP, V_ID_VALUTA, V_ID_GESTIUNE_INIT, V_LUNA, V_AN, V_ID_UTIL, V_ID_SUCURSALA)`
-(`PACK_FACTURARE:335-343`). De aici vin miile de randuri.
-
-Mecanismul de inlocuire **exista deja**, in prototip: `combosql` cauta pe server, incremental, cu
-`csourcesql = select codmat, denumire, um, grupa, subgrupa, codbare, id_articol from vnom_articole`
-si `csourcewhere = inactiv = 0` (`ofacturare.vc2:16751-16766`).
-
-**Dar `vnom_articole` e nomenclatorul, nu lista de preturi.** Nu are pret, nota contabila, cota TVA,
-valuta, `id_pol`, `gestionabil`, `pret_cu_tva` — toate vin azi din `cursor_preturi`. Deci partea
-Oracle a lucrarii e o **varianta filtrata pe articol** a cursoarelor de facturare, apelata la
-alegerea liniei, nu la deschiderea formularului. Nu e o simplificare: ramurile pe tip din
-`cursor_preturi` (restaurant, custodie, retur, contract, comanda) trebuie pastrate identic, altfel
-pretul difera intre cele doua cai.
-
-**Legatura cu #12.** Daca articolul poate purta el insusi pretul si nota contabila (varianta C din
-`plan_12`), cautarea in linie devine directa si nu mai are nevoie de o rezolvare separata a listei
-de preturi. #13 nu depinde de #12, dar cine face #12 dupa #13 va rescrie exact bucata asta.
-
-### D. Regenerarea — piesele exista, montajul nu
-
-**1. Stergerea elibereaza deja documentul sursa.** `pack_facturare.sterge_factura`
-(`PACK_FACTURARE:5415-5591`) face, pe langa `sters = 1` pe `VANZARI` si `VANZARI_DETALII`:
-
-- `FACTURAT = 0, ID_UTILFACT = NULL, DATA_FACTURAT = NULL` pe avizele facturate (tip 4 si 24);
-- `STERS = 1` pe `VANZARI_CANTITATI` (cantitatile consumate de pe avize);
-- `STERS = 1` pe `COMENZI_ELEMENTE` cu `CANTITATE < 0` (consumul din comanda);
-- `STERS = 1` pe `VANZARI_CORESP` si pe `CTR_RATE_FACTURI` (contracte in rate, tip 2/6/52).
-
-Adica **exact reversul consumului sursei** — conditia ca reemiterea sa poata reconsuma aceeasi
-comanda / acelasi aviz / aceeasi rata. Sunt si garzi: refuza stergerea daca s-au emis facturi sau
-avize de retur peste document (`:5432-5477`).
-
-**2. Calea VFP de stergere completa exista.** `frm_facturi.do_sterge`
-(`COMUN\clase\ofacturare_comun.vc2:4658-4874`): tranzactie manuala, `oscrie_in_fisiere`, apoi
-`pack_contafin.finalizeaza_stergere_nota` (care cheama `sterge_din_vanzari`). Rulajele si notele
-dispar pe aceasta cale, nu prin `sterge_factura`.
-
-**3. Reconstituirea liniilor exista.** `pack_facturare.cursor_retur_document(..., V_COPIERE = 1, ...)`
-(`PACK_FACTURARE:3932-4045`) reface liniile din `VANZARI_DETALII`, cu `explicatie`, `id_gestiune`,
-`pret_achizitie`, `pretd`, `id_jtva_coloana`, `id_jtva_coloana_ex`, `lot`, `serie`, `id_pol`,
-`pret_cu_tva`, plus `curs` / `multiplicator` din `VANZARI_CURSURI`. E deja folosita, exact asa, la
-copierea unei facturi.
-
-**4. "Redeschide formularul precompletat" exista.** `frm_facturi.do_copiaza`
-(`ofacturare_comun.vc2:3640-3713`) -> `copiere_factura` (`oproceduri_facturare.prg:150-153`) ->
-`factureaza(tip, toFactura)`, iar in `factureaza` ramura `llCopiere` (`ofacturare.prg:255-257`,
-`:458-473`) incarca liniile documentului si adauga peste ele lista de preturi, ca sa se poata
-adauga articole noi. `oDateFactura.completeaza_setari_document(toFactura, .T.)`
-(`COMUN\programe\ofacturare_comun.prg:362-412`) precompleteaza antetul.
-
-**Ce nu se poate refolosi ca atare:** `do_copiaza` **degradeaza intentionat tipul** — factura din
-contract / comanda / aviz devine `tip = 1`, avizele devin `22`, transferurile `10`
-(`ofacturare_comun.vc2:3696-3710`), cu comentariul *"nu are sens sa fie copiata, dar o tratez ca pe
-o factura din lista de preturi"*. La regenerare, degradarea e **exact ce nu trebuie sa se intample**:
-documentul nou trebuie sa ramana pe acelasi tip, ca sa reconsume sursa. Deci se cloneaza structura
-lui `do_copiaza`, nu comportamentul.
-
-### E. `ID_FACT` — cerinta si ce presupune ea
-
-**Cerinta (decizia 2):** documentul reemis pastreaza `ID_FACT`.
-
-**Starea de azi, verificata:** `ID_FACT` se genereaza cu secventa, neconditionat.
-`PACK_CONTAFIN.SET_IDFACT(V_GCS)` e `SELECT SEQ_IdFact.NEXTVAL`
-(`COMUN\docs\PACK_CONTAFIN.pck:3037-3040`), citit cu `get_idFact()` (`:725`), iar `DOCUMENTE`
-primeste rand nou cu acel `ID_DOC` (`:796-808`).
-
-**Dar intuitia „id_fact depinde de numar si data" e corecta istoric:** exista in pachet varianta
-`SET_IDFACT(tdDataAct, tcSerie_Act, tnNrAct, tnId_Ctr)` care cauta intai in `DOCUMENTE` dupa
-`NRACT` + `SERIE_ACT` + `DATAACT` + `ID_CTR` si ia secventa doar la `NO_DATA_FOUND`
-(`:3016-3035`) — **comentata**, deci inactiva.
-
-**Ce inseamna pentru #13** (de proiectat in S9, dupa verificarea din handoff):
-
-- fie se reactiveaza cautarea, sub un comutator folosit **numai** de regenerare — modificarea lui
-  `SET_IDFACT` fara comutator ar schimba comportamentul pentru toata suita, ceea ce nu se face;
-- fie se transmite `ID_FACT`-ul cunoscut, ca parametru, pe drumul de scriere;
-- **capcana de ordine**: cautarea filtreaza `STERS = 0`. Daca documentul vechi e marcat sters
-  inainte, cautarea nu-l mai gaseste si se genereaza id nou. Deci `ID_FACT`-ul se citeste **inainte**
-  de stergere, in aceeasi tranzactie.
-
-Cu `ID_FACT` pastrat, ce ramane de inventariat e mult mai putin decat in varianta cu id nou:
-`ATASAMENTE_VANZARI` si `marcheaza_facturat` merg pe `ID_VANZARE` (care **se schimba**),
-`ANAF_EFACTURA` e gol prin garda, iar `DOCUMENTE` / `ACT` / `RUL` / `JV2007` / `IREG_PARTENERI` merg
-pe `ID_FACT` (pastrat). **`ID_VANZARE` nou ramane singura discontinuitate reala** — de verificat
-daca `DOCUMENTE` primeste un al doilea rand pe acelasi `ID_DOC` sau il refoloseste.
-
-### F. Serie, numar, data — cale proprie, nu regenerare
-
-**Cerinta (deciziile 3 si 4):** toate datele se pastreaza, inclusiv numarul; iar antetul care intra
-in identitatea documentului se modifica pe cale proprie.
-
-Calea exista deja si e exact ce trebuie: `pack_facturare.modifica_date_factura`
-(`PACK_FACTURARE:14392-14463`) face `UPDATE` in loc si **propaga serie / numar / data / scadenta
-pe `VANZARI`, `DOCUMENTE`, `ACT`, `IREG_PARTENERI`, `JV2007`, `RUL`, dupa `ID_FACT`**
-(`:14427-14460`). Tot ea scrie delegat, agent, masina, adresa de facturare, text aditional,
-`dataora_exp`, `listare_detaliata`, `tip_saft`, `efactura`. E procedura din spatele actiunii de azi
-`frm_facturi.do_modifica` -> `frm_modifica_factura`.
-
-**Deci in formularul unificat:** campurile de antet se scriu prin `modifica_date_factura`, nu prin
-regenerare. Regenerarea porneste doar pentru ce atinge sumele. Vezi tabelul din G-bis.
-
-`oGeneratorNumere` (`COMUN\programe\oserii_numere.prg:227-233`) nu incurca: la modificare nu se
-aloca numar nou, deci nu e nimic de dezalocat. Intrebarea despre o eventuala constrangere de
-unicitate pe `VANZARI(SERIE_ACT, NUMAR_ACT)` **dispare** — nu mai exista doua documente nesterse cu
-acelasi numar, pentru ca numarul nu se realoca; ramane doar cazul „vechi sters + nou nesters", care
-e exact situatia de azi de la orice stergere si reintroducere.
-
-### G-bis. Cele trei modificari de azi, si ce se scrie la confirmare
-
-Pe `frm_facturi` exista azi trei actiuni care ating acelasi document, fiecare cu fereastra ei:
-
-| Actiune de azi | Formular | Ce atinge | Sursa |
-|---|---|---|---|
-| `do_modifica` | `frm_modifica_factura` | antet: ruta, delegat, agent, serie, numar, date | `ofacturare_comun.vc2:4538-4637` |
-| `do_modifica_explicatie` | `frm_modifica_articol_factura` | `explicatie` + `taxcode` pe o linie | `:4639-4656` |
-| `do_editare_factura` (#6) | `frm_modific2024` | nota contabila si rulajele | `:3715-3869` |
-| — | — | **cantitati, preturi, linii: nicaieri** | — |
-
-Decizia 6 le comaseaza in formularul unificat. Ruta de scriere se alege dupa ce s-a schimbat:
-
-| Ce s-a schimbat | Cum se scrie | Efect |
-|---|---|---|
-| Serie, numar, data, scadenta, delegat, auto, agent, adresa facturare, text aditional | pe loc, `modifica_date_factura` | propaga dupa `ID_FACT` |
-| Explicatia si `taxcode` pe o linie | pe loc, `modifica_explicatie_articol` (`PACK_FACTURARE:14464-14472`) | doua coloane, nicio suma |
-| Cantitati, preturi, linii adaugate/sterse, discount, gestiune, cota TVA | **regenerare** | vechiul `sters = 1`, documentul nou scris pe drumul de emitere, note si rulaje refacute |
-| Nimic | nimic | documentul nu se rescrie degeaba |
-
-Ultima linie nu e cosmetica: fara ea, orice deschidere a formularului ar produce un document nou si
-ar umple `VANZARI` cu randuri sterse.
-
-**Gol descoperit la S1 (runda 7): tabelul de mai sus nu acopera tot antetul.** Inventarul camp-cu-camp
-(`docs\S1_inventar_campuri_formular_unificat.md`) a gasit trei grupuri de campuri de antet care **nu
-sunt printre cei 14 parametri** ai lui `modifica_date_factura` si pentru care nu s-a gasit alta ruta:
-
-- **analiticele** — venit/cheltuiala, sectie, responsabil, lucrare (grupul „Pliat — analitice” din I);
-- **identitate/sursa, altele decat serie/numar/data/scadenta** — tip document, valuta, zi curs, client,
-  sursa/„altele”, gestiune sursa, politica de preturi;
-- **grupul de incasare** — mod incasare, casa, serie si numar de chitanta/bon, suma incasata, POS.
-
-**Verificat (runda 7): `docs\cercetare\rute_scriere_antet.md`.** Cautare exhaustiva in ambele straturi
-— Oracle (pachetul de facturare curent, plus `PACK_CONTAFIN`, `PACK_UPDATE`, `PACK_MIGRARE`; toate
-cele 13 aparitii de `UPDATE VANZARI` inspectate individual) si VFP (indexul complet: 316 fisiere,
-1128 clase, 9281 metode). Rezultatul e neuniform pe cele trei grupuri:
-
-| Grup | Verdict | Ce inseamna |
-|---|---|---|
-| **B** — tip document, valuta, zi curs, client, sursa, gestiune sursa, politica de preturi | **NU**, toate sapte | Controalele traiesc **exclusiv** in wizardul de emitere; nu exista niciun `UPDATE` care sa le atinga dupa emitere. Un „nu" verificabil, nu o absenta de cautare. |
-| **C** — mod incasare, casa, serie/nr chitanta, suma, POS | **NU direct** | Nu exista coloane proprii pe `VANZARI`: incasarea devine ea insasi **o linie de nota contabila** (`scrie_incasare2`). Nicio procedura de tip „modifica incasare". |
-| **A** — sectie, responsabil, lucrare | **DA** | Dar nu prin `modifica_date_factura`, ci prin **mecanismul lui #6**, aterizat chiar pe branch-ul asta (`97d1613`). Vezi mai jos. |
-| **A** — venit/cheltuiala (`ID_VENCHELT`) | **neconfirmat** | Gridul afiseaza coloana `dst_chlt`, dar `do_modifica` nu are caz pentru ea. |
-
-**Descoperirea care conteaza: analiticele sunt deja editabile, dar din #6.** `frm_facturi.do_editare_factura`
-(`ofacturare_comun.vc2:3690-3869`) e acum cablat la `frm_modific2024` (`omodificari.vc2`), incarca
-nota contabila a documentului emis si o rescrie prin `OSCRIE_IN_FISIERE` ->
-`pack_contafin.finalizeaza_modificare_nota`, care **resincronizeaza `VANZARI`**. `do_modifica`
-(`omodificari.vc2:13934-13943`) trateaza explicit `id_lucrare` si `id_responsabil`.
-
-**Doua nuante care schimba proiectarea, nu doar inventarul:**
-1. **Editarea e la nivel de LINIE de nota, nu de antet.** La emitere, cele patru analitice se scriu
-   uniform pe tot documentul, din variabilele de sesiune. Prin editorul lui #6, fiecare linie se poate
-   edita separat — deci un document poate ajunge cu **sectii diferite pe linii diferite**, stare
-   imposibila la emitere. Conteaza pentru orice raportare care presupune „un singur `ID_SECTIE` per
-   factura".
-2. **Bug suspectat pe `sectie`** (`omodificari.vc2:13941`): `replace ... id_valuta with
-   loCauta.id_sectie` — pare sa scrie in `id_valuta` in loc de `id_sectie`. Daca e real, textul afisat
-   se schimba dar coloana nu. **E in perimetrul lui #6** — se semnaleaza, nu se repara aici. Pana la
-   verificare, „DA" pentru `ID_SECTIE` e un da cu rezerva.
-
-**Consecinta pentru decizia 9**, acum pe fapte: `but_modifica` **poate salva pe loc doar cei 14
-parametri**. Pentru grupurile B si C nu exista alta cale decat **regenerarea**, care le rescrie oricum
-pe toate, fiind chiar drumul de emitere. Pentru grupul A exista o a treia cale, dar e a lui #6 si
-lucreaza pe alt nivel (linie de nota).
-
-**Tabelul de rutare, completat (deciziile 25 si 26):**
-
-| Ce s-a schimbat | Cum se scrie |
-|---|---|
-| cei **14 parametri** (serie, numar, data, scadenta, ruta, delegat, masina, agent, `dataora_exp`, adresa facturare, text aditional, `listare_detaliata`, `tip_saft`, `efactura`) | **pe loc**, `modifica_date_factura` |
-| explicatia si `taxcode` pe o linie | **pe loc**, `modifica_explicatie_articol` |
-| cantitati, preturi, linii, discount, gestiune, cota TVA | **regenerare** |
-| **grupul B** — tip document, valuta, zi curs, client, sursa, gestiune sursa, politica de preturi | **regenerare** (decizia 25); blocate in etapa I |
-| **grupul C** — incasare | **regenerare** (decizia 25); blocate in etapa I |
-| **grupul A** — venit/cheltuiala, sectie, responsabil, lucrare | **regenerare** — editabile si la introducere, si la reemitere (decizia 72, rastoarna 26) |
-| nimic | nimic |
-
-### G. Stocul — de ce argumentul lui #6 nu inchide subiectul
-
-Verificarea de stoc **nu** e in `adauga_articol_factura`: acolo erorile sunt de configurare
-("Nu a fost gasita cota de TVA", politica / contract lipsa — `PACK_FACTURARE:5125-5180`).
-Descarcarea efectiva de gestiune se face la emitere, in `contabilizeaza_articol` ->
-`descarca_gestiune` (`:7631+`). Plafonul pe cantitate pe care il vede utilizatorul azi vine din
-**cursorul client** `crsarticole` (`frm_facturare_articole.do_adauga_articol`,
-`ofacturare.vc2:12813-13086`) — cursor care in formularul unificat **nu mai exista**, pentru ca nu
-se mai incarca in masa.
-
-Deci, pe #13:
-
-- in timpul compunerii **nu exista plafon** — coincide cu decizia deja luata de Marius pe #6 la
-  08.08.2026 ("editarea unei facturi emise nu are plafon si nu verifica stocul");
-- la finalizare, daca **stergerea ruleaza inaintea reemiterii, in aceeasi tranzactie**, stocul
-  consumat de documentul initial e deja eliberat cand se descarca gestiunea pentru documentul nou.
-
-**Aici e riscul tehnic principal.** Azi stergerea si emiterea deschid fiecare propria tranzactie
-(`do_deschide_tranzactie` / `do_inchide_tranzactie` in ambele cai). O tranzactie nu poate fi tinuta
-deschisa peste minutele in care utilizatorul editeaza formularul. Ordinea corecta e deci:
-**citire (fara tranzactie) -> editare -> o singura tranzactie la confirmare, care contine intai
-stergerea, apoi scrierea.** Asta cere mutarea apelului de stergere in interiorul tranzactiei
-deschise de `do_scrie_articole`, nu inaintea ei.
-
-Atentie si la `VANZARI_DETALII_TEMP`, care e GTT `ON COMMIT DELETE ROWS`: umplerea si consumul
-trebuie sa ramana in aceeasi tranzactie — ceea ce e compatibil cu schema de mai sus, dar interzice
-un `commit` intermediar dupa stergere.
-
-### H. Pretul rescris de server la reemitere
-
-`adauga_articol_factura` (`PACK_FACTURARE:4972-5268`) ramifica pe `V_OPT_FACTURARE` si, pe unele
-ramuri, **re-deriva pretul, cota TVA si valuta din documentul sursa** (ex. `V_OPT_FACTURARE = 3`,
-preturile de pe contract, `:5129-5168`), in timp ce pe ramura implicita valoarea venita din VFP
-castiga (`V_PRET := V_PRET_TEMP`, `:5183-5186`). Planul #6 semnalase deja acelasi lucru.
-
-**Consecinta pentru #13:** pe facturile din contract (si posibil pe alte ramuri), pretul editat de
-utilizator poate fi suprascris tacut la reemitere. De inventariat ramura cu ramura, si de decis daca
-regenerarea trece un flag "preturile vin din formular, nu se re-deriva". **Nu se porneste
-implementarea inainte de acest inventar** — e singurul punct din care poate iesi o factura reemisa
-cu alte sume decat cele confirmate pe ecran.
-
-### I. Asezarea antetului (deciziile 8 si 9)
-
-**Doua grupuri vizibile, restul pliat.** Grupurile si etichetele reale, din inventar:
-
-| Grup | Controale | Note |
-|---|---|---|
-| Identitatea documentului | `Ct_clb_fdoc` („Tip document”: FACTURA / PROFORMA / BON FISCAL), `Clb_serie_act`, `Clb_nract`, `Clb_dataact`, `Clb_data_scadenta`, `Clb_zi_curs`, `Ct_clb_valuta` | scadenta e **dezactivata**, nu eliminata, cand `gnScadentaAutomata = 1` (`ofacturare.vc2:9713-9715`); ziua de curs se elimina pe retur (`:9717-9722`, tipurile 8 si 9 — nu si 24); valuta se elimina cand `in_valuta = 0` (`:9725-9728`) |
-| Partener si sursa | `Ct_clb_nume_client`, `txtCodFiscal` + `But_verifica1` (ANAF), `txtSoldLei`, `Ct_clb_altele` (sursa), `Ct_clb_gestiune_init`, pe aviz `Ct_clb_politici_preturi` | codul fiscal si soldul sunt read-only si derivate |
-| **Pliat** — analitice | `Ct_clb_venchelt`, `Ct_clb_sectie`, `Ct_clb_responsabil`, `Ct_clb_lucrare` | responsabilul si gestiunea sursa se elimina azi cand `gnScadereStoc = 0` sau tipul e 4/7/8/9/48/49 (`ofacturare.vc2:9646-9707`) |
-| **Pliat** — alte date | cele patru grupuri din `frm_alte_date`, vezi B | |
-
-**Butonul de modificare a antetului (decizia 9).** Mecanismul **exista deja**, si e mai fin decat
-credeam: `frm_modifica_factura` (`ofacturare_comun.vc2:5262-5774`) are **patru bife individuale** —
-`chkSerieAct`, `chkNrAct`, `chkDataAct`, `chkDataScad` — fiecare deblocand exact textbox-ul ei
-(`thisform.txtDataAct.Enabled = this.Value`, `:5758-5772`), si toate patru sunt ele insele inactive
-daca documentul nu are numar (`this.chkSerieAct.Enabled = !EMPTY(NVL(poRec.numar_act,0))`,
-`:5736-5750`). **Restul campurilor de antet nu sunt blocate deloc** — delegat, agent, masina, ruta,
-adresa, dataora expediere, text aditional sunt mereu editabile.
-
-In formularul unificat (**decizia 9, forma finala — un singur buton comutator, fara nicio bifa**):
-
-- in bara panoului de antet sta **un singur `but_modifica`**; apasat, deblocheaza **tot antetul** —
-  si campurile „moi”, si cele patru de identitate — si **isi schimba imaginea in discheta lui
-  `but_salvare`**; documentul deschis pentru consultare ramane inert;
-- **cele patru bife individuale dispar.** Nu se transpun in formularul unificat sub nicio forma:
-  butonul e singurul control de protectie a antetului;
-- **si conditia lor se abandoneaza.** Azi bifele de serie si numar sunt ele insele inactive dupa
-  `!EMPTY(NVL(poRec.numar_act,0))` (`:5736-5750`); regula asta nu se mai transpune pe campuri.
-  Cu antetul deschis, **toate campurile de antet sunt editabile, fara exceptie si fara conditie de
-  stare**. E o pierdere deliberata de protectie, in schimbul unei singure reguli inteligibile:
-  antet blocat sau antet deschis, atat;
-- a doua apasare **salveaza doar antetul**. E posibil pentru ca
-  `do_modifica` cheama azi **exclusiv** `pack_facturare.modifica_date_factura`, cu 15 parametri toti
-  de antet, si niciun apel spre articole, note sau `oscrie_in_fisiere` (`ofacturare_comun.vc2:4587-4630`).
-  Acopera cazul „vreau sa corectez doar delegatul”.
-  **Precizare, ca sa nu se citeasca gresit:** „nu atinge notele si rulajele” e adevarat **la nivel de
-  apel VFP**, nu si in Oracle. Corpul procedurii propaga seria, numarul si datele in `JV2007` si `RUL`
-  (`PACK_FACTURARE.pck:14428-14459`) — coloane de **identitate**, nu sume: nicio valoare nu se
-  recalculeaza. Pentru celelalte zece campuri, scrierea e strict in `VANZARI`. Vezi I-bis.
-- **`Termina` ramane salvarea intregului document**, cu rutarea din G-bis.
-
-**Ce nu exista si trebuie scris:** containerele efectiv folosite in antet nu au un mecanism gata
-facut de blocare. `ct_clb_cautare` are `do_activeaza` / `do_dezactiveaza` (`caut_ora.vc2:780-806`),
-dar acestea doar ascund iconita de cautare, iar in `ofacturare_comun.vc2` nu sunt apelate nicaieri;
-`clb_tx_simplu` (`lb_tx.vc2:551-585`) si `clb_serie_act` (`serii_numere.vc2:7`) **nu au deloc**
-metode de activare. Singura reteta completa din biblioteca e `clb_tx_data.dezactiveaza()` /
-`reactiveaza()` (`lb_tx.vc2:521-538`: `ReadOnly` + `TabStop` + butonul de calendar) — se
-generalizeaza de la ea, nu se inventeaza alta.
-
-Decizia 5 ramane in picioare: **asezarea e identica** la introducere si la modificare; difera doar
-starea antetului.
-
-### I-bis. Contractul lui `modifica_date_factura` (decizia 19)
-
-Raport complet: `docs\cercetare\modifica_date_factura_parametri.md`. Spec `PACK_FACTURARE.pck:921-935`,
-corp `:14392-14462`, singurul apel VFP la `ofacturare_comun.vc2:4599-4614`.
-
-Procedura are **doua regimuri de scriere**, si diferenta dintre ele decide cum se cheama din
-formularul unificat:
-
-| Parametri | Regim | Unde ajung |
-|---|---|---|
-| `V_ID_VANZARE` | doar `WHERE` | identitatea randului; sursa lui `lnIdFact` (`:14424-14426`) |
-| `V_ID_RUTA`, `V_ID_DELEGAT`, `V_ID_AGENT`, `V_ID_MASINA`, `V_DATAORA_EXP`, `V_ID_FACTURARE`, `V_LISTARE_DETALIATA`, `V_TEXT_ADITIONAL`, `V_TIP_SAFT`, `V_EFACTURA` | **scrise neconditionat**, inclusiv cu `NULL` | `VANZARI`, randul curent (`:14414-14423`) |
-| `V_DATA_ACT`, `V_DATA_SCAD`, `V_NUMAR_ACT`, `V_SERIE_ACT` | scrise **doar daca** sunt `NOT NULL` **si** difera de valoarea curenta | `VANZARI` + propagare in `DOCUMENTE`, `ACT`, `IREG_PARTENERI`, `JV2007`, `RUL` (si `RUL.DATAOUT`), toate **dupa `ID_FACT`**, nu dupa `ID_VANZARE` (`:14428-14459`) |
-
-**Consecinta 1 — apelul trimite intotdeauna antetul intreg.** Cele zece campuri din regimul
-neconditionat se scriu cu ce primesc, deci un apel cu `poRec` completat partial **goleste** in baza
-campurile netrimise. Butonul de antet nu poate trimite „doar ce s-a schimbat”: incarca antetul
-curent, aplica modificarile peste el, trimite tot.
-
-**Consecinta 2 — cele patru campuri de identitate ating cinci tabele.** Propagarea dupa `ID_FACT`
-inseamna ca schimbarea seriei sau a numarului dintr-un document atinge toate randurile legate de
-acelasi `ID_FACT`. E acelasi mecanism pe care se sprijina S9 (reemiterea cu `ID_FACT` pastrat) si
-acelasi motiv pentru care ordinea operatiilor conteaza acolo.
-
-**Consecinta 3 — un camp nou.** `V_EFACTURA` se scrie neconditionat dar nu are niciun control in
-niciun formular; azi valoarea vine din `Scatter` sau e fortata `0` (`ofacturare_comun.vc2:4576`).
-In antetul unificat primeste control, langa `V_TIP_SAFT` (ambele tin de raportare, nu de document).
-
-**Unde stau cele 14 in formularul unificat** (raportat la gruparea din I): cele patru de identitate
-in antetul vizibil; ruta, delegatul, agentul, masina, `dataora_exp` si adresa de facturare in
-sectiunea pliata, la „delegat si transport” / „adresa de facturare”; `text_aditional` si
-`listare_detaliata` tot in pliat; `tip_saft` si `efactura` formeaza acolo un **grup nou, de
-raportare**. Niciunul dintre cei 14 nu vine azi din `frm_alte_date` — clasa aceea nu e implicata
-deloc in fluxul `do_modifica`, deci sectiunea B si I-bis nu se suprapun.
-
-### J. Butoanele de linie si adaugarea din sursa (decizia 13)
-
-**Cum sunt azi.** In `frm_facturare_articole` butoanele sunt imprastiate lateral, intre cele doua
-griduri, si sunt iconite de 30x27 fara text: `But_modifica1` / `But_sterge1` la 773/61 si 811/61,
-`But_reset1` la 303/295, `But_urmator1` la 343/348, `But_urmator_tot1` la 343/378, `But_retur` la
-343/407 (`ofacturare.vc2:11192-11257`). **`But_urmator_tot1` — „adauga tot” — nu are nici caption
-nici `ToolTipText`** (`:11257`); metoda lui, `do_adauga_tot` (`:13169-13198`), face SCAN peste
-`crsarticole` si cheama `do_adauga_articol(.T.)` pe fiecare linie.
-
-**In prototip sunt deja unde trebuie**: `But_nou1` si `But_sterge1` la `Top = 175`, gridul la
-`Top = 204` (`:15936`, `:15955`) — adica **deasupra tabelului**, exact cum cere decizia 13.
-`But_nou1.Click -> do_adauga` (`:17118-17122`) e `APPEND BLANK` + focus in grid.
-
-**Ce lipseste: contractele.** `But_urmator_tot1` e vizibil pe `eProforma = 1`, `lCopiere`, tip 3
-(comanda), tip 4 (din avize), 21/28/42/47, 25, 8/9, 24 (`:15113-15245`). **Tipurile de contract
-(2, 6, 26, 52) nu sunt in lista.** Deci „adauga tot” acopera deja avizele, dar nu contractele.
-
-**Alegerea selectiva — tiparul importului RORIS.** In ROAACNPRO, `cmdImport` („Import Roris &
-Contracte”, `oacnpro.vc2:6894-6905`) face exact ce s-a cerut aici, si merita copiat ca structura:
-
-1. **buton activ conditionat** de document editabil **si** tip care are sursa
-   (`llFacturaEditabila and llRorisSauContracte`, `oacnpro.vc2:8117-8145`);
-2. **o metoda unica de intrare** care ramifica pe tip (`do_executa` -> `factura_import`,
-   `proceduri_acnpro.prg:3151-3212`);
-3. **dialog modal de selectie** cu coloana de bifat si criterii de cautare (`frm_tranzit`, coloana
-   `cAles` legata de `crsConvoaie.ales`, `oacnpro.vc2:14500-14515`, `:14801`), urmat de un al doilea
-   nivel de calcul / confirmare;
-4. **populare aditiva** prin `INSERT INTO` in cursorul local de articole, fara nicio procedura Oracle
-   — pachetele intra abia la salvare (`proceduri_acnpro.prg:3331-3467`);
-5. **protectie minimala la dublu-import**: butonul se dezactiveaza dupa un import reusit
-   (`oacnpro.vc2:7827-7834`), plus avertisment neblocant daca sursa a mai fost folosita
-   (`:14915-14930`).
-
-Ce **nu** se copiaza: sursele de date si calculele ACN (`ips_*`, tarife, ecluzari), formularele lor,
-si valorile `poDate.cTip`. Ce trebuie facut mai bine: la zero rezultate, dialogul RORIS nu spune
-nimic — butonul pare ca nu face nimic (`oacnpro.vc2:14898-14943`).
-
-**Bara propusa, deasupra gridului (decizia 13):** linie noua · sterge linia · detalii linie ‖
-**un singur buton „Adauga articole”**, care deschide un `xmenu()` cu optiunile potrivite sursei —
-nu doua butoane separate. Tiparul e deja folosit in produs: `frm_facturi.but_modifica1` ->
-`inainte_de_do_modifica` -> `xmenu("Modificare date factura;Editare factura (articole, cantitati,
-preturi)")` (`ofacturare_comun.vc2:4925-4934`).
-
-| Sursa documentului | Optiunile din meniu |
-|---|---|
-| comanda | Adauga tot din comanda · Alege din comanda… · Cauta in lista de preturi… |
-| contract | Adauga tot din contract · **Alege ratele de facturat…** · Cauta in lista de preturi… |
-| avize | Adauga tot din avize · Alege avizele… · Alege liniile din avize… · Cauta in lista de preturi… |
-| lista de preturi | Cauta in lista de preturi… · Retur de articole… |
-| retur (tip 8, 9, 24) | Alege facturile de returnat… · Alege liniile de returnat… · Cauta in lista de preturi… |
-
-**Constanta meniului (deciziile 16 si 18): ultimele doua optiuni sunt aceleasi peste tot** —
-**„Cauta in lista de preturi…”** (cu pret din politici) si **„Alege din nomenclator…”** (cu pret
-tastat, ca „Alte servicii” din ROAAUTO, O-bis). Apar inclusiv pe documentele cu sursa, pe cele de
-retur si pe cele deja emise care se modifica. Sursa umple documentul, nu il inchide.
-
-**Decizia 20 (Marius, 09.08.2026): din nomenclator se pot alege si articole gestionabile, si
-negestionabile.** Nu se preia filtrul `in_stoc = 0` al lui ROAAUTO — acolo e o ocolire a subiectului
-gestiunii, nu o regula de produs. Consecinta directa: pe documentele auto vor putea aparea linii care
-descarca stoc langa linii care nu descarca, caz care azi nu exista nicaieri (O-bis, intrebarea 2).
-
-#### J-bis. Contul de venit al liniei — intrebarea lui Marius era corect pusa
-
-Doua cercetari, a doua o corecteaza pe prima. **Valabil e al doilea raport:**
-`docs\cercetare\cont_venit_corespondente.md`. Primul (`cont_venit_articol_fara_politica.md`) ramane
-util pentru contul de **gestiune**, dar concluzia lui pe venit e gresita si nu se citeaza.
-
-**Ce a gresit primul raport.** A cautat literalii `707` / `704` / `706` / `708` in `pack_facturare`,
-nu i-a gasit (corect — nu sunt hardcodati nicaieri) si a conchis ca **nu exista cont de venit pe
-linie**. Exista. E doar **indirect**, si sta chiar in `pack_facturare`, nu intr-un pachet de
-contabilitate separat.
-
-**Sunt doua conturi pe aceeasi linie de vanzare, cu surse complet diferite:**
-
-| | Contul de **gestiune** | Contul de **venit** |
-|---|---|---|
-| Unde ajunge | `VANZARI_DETALII.CONT` (`varchar(4)`) | `SCC` in randul de nota contabila |
-| De unde vine | `NOM_ARTICOLE.CONT` / `STOC.CONT` / `NOM_GESTIUNI.CONT` | `NOTE_CONTABILE.SCC` |
-| Prin ce | alegerea lotului (`do_alege_stoc`) | **politica de pret** a articolului |
-| Cine il consuma | `descarca_gestiune` (`ff_...:7485-7507`) | `scrie_nota` (`ff_...:7452-7476`) |
-
-Lantul care aduce venitul, in `pack_facturare.contabilizeaza_articol` (`ff_...:7182-7556`, cursorul
-`cursor_articol` la `:7227-7280`):
-
-**`CRM_POLITICI_PRET_ART` -> `CRM_POLITICI_PRETURI.ID_NOTA` -> `CRM_NOTE_VANZARI.ID_SET` ->
-`NOTE_CONTABILE.SCD` / `SCC`**
-
-Pentru o factura normala (`ntip <= 20`), `SCD` e contul debitor (creanta) si **`SCC` e contul de
-venit efectiv** al liniei (`ff_...:7407-7437`). Nu e derivat din nimic: perechea SCD/SCC e **scrisa
-manual de un contabil**, per sablon de nota, din ecranul „Configurare note contabile"
-(`COMUN\ferestre\frm_config_note_contabile[2007].sc2`, clasa `onote_contabile.vc2:2401-2435`,
-salvare la `:315-322`, `:486-493`).
-
-**Nu exista tabel de corespondenta 3xx -> 7xx.** Cautat in `SCRIPTURI_CLAR` sub toate numele
-plauzibile — negativ. Ipoteza lui Marius era corecta ca **intentie** (exista un mecanism care leaga
-articolul de contul de venit), dar mecanismul e **configurare manuala pe politica de pret**, nu
-derivare automata din contul de stoc.
-
-**Consecinta care conteaza pentru #13 — si care valideaza intrebarea initiala a lui Marius.** Daca
-contul de venit vine **prin politica de pret**, atunci un articol adaugat **direct din nomenclator,
-fara politica** (exact ce cere decizia 16 / 20) nu are `ID_POL`, deci cursorul de mai sus — filtrat
-`WHERE A.ID_POL = detalii_articol.id_pol` — nu intoarce niciun rand, si `SCD` / `SCC` raman `NULL`
-(sunt `LEFT JOIN`-uri). **Intrebarea „cu ce cont de venit intra un articol fara politica de pret" era
-deci exact intrebarea corecta.**
-
-#### J-ter. Raspunsul: nu „cu niciunul”, ci **eroare** — si nu exista precedent
-
-Verificat: `docs\cercetare\nota_contabila_fara_politica.md`. Doua rezultate, amandoua mai dure decat
-se anticipase.
-
-**1. Codul nu scrie tacut un cont gol — refuza documentul.** `contabilizeaza_articol` cauta politica
-articolului **inainte** de cursorul care aduce `SCC` (`ff_...:7286-7311`), si pe `NO_DATA_FOUND`
-ridica `RAISE_APPLICATION_ERROR` cu **`FACT-024`** („Articolul … nu este definit in politica de
-preturi …”). Cu `id_pol` `NULL`, `ID_POL = detalii_articol.id_pol` nu poate potrivi nimic, deci
-**mereu** se intra pe exceptie. Cursorul cu `SCC` nu se mai deschide. Nu exista ramura de default,
-nu exista fallback, si `scrie_nota` (`ff_...:12338-12570`) **nu are nicio validare pe cont** — dar
-nici nu ajunge sa fie chemat.
-Concluzie: o linie fara politica trecuta prin codul de azi **opreste tranzactia cu eroare**, nu produce
-o nota incompleta. Din perspectiva datelor e vestea buna; din perspectiva lui #13, e blocantul dur.
-
-**2. „Alte servicii" din ROAAUTO NU e precedent** — premisa pe care se sprijinea decizia 18 cade.
-Liniile acelea chiar ajung cu `id_pol` gol (confirmat: nici `crsalteserv`, nici `crsvanztemp`, nici
-semnatura lui `adauga_articol_factura_deviz` nu au `id_pol`, iar `INSERT`-ul in
-`VANZARI_DETALII_TEMP` nu include coloana). **Dar ele nu trec niciodata prin
-`contabilizeaza_articol`**: fluxul ROAAUTO cheama `initializeaza_date_factura` ->
-`adauga_articol_factura_deviz` -> `scrie_in_vanzari` -> `pack_auto.actualizeaza_deviz`
-(`oproceduri_devize.prg:1211-1310`), iar `scrie_in_vanzari` (`ff_...:13497-13962`, citit cap-coada)
-**nu genereaza nicio nota contabila de venit** — copiaza `ID_POL` (deci `NULL`) direct in
-`VANZARI_DETALII` si actualizeaza totalurile.
-Deci ROAAUTO nu demonstreaza ca articolele fara politica sunt tolerate; demonstreaza ca **exista o cale
-paralela de facturare care ocoleste contabilizarea de venit prin `pack_facturare`**. Unde capata acele
-documente contul de venit — daca il capata — **nu se vede in codul cercetat**; `actualizeaza_deviz`
-presupune deja existenta unui rand in `ACT`, a carui sursa nu a fost gasita.
-
-**3. Apelantii sunt trei, si acopera fluxul principal** (lasat neverificat de raportul 2):
-`scrie_factura2` (`ff_...:6150`) — factura normala si majoritatea tipurilor —, `scrie_factura_avize_retur`
-(`:6867`) si `scrie_aviz_retur` (`:7149`). Nu exista al patrulea.
-
-**4. `NOM_ARTICOLE.CONT` ca sursa de venit: NU.** Grep pe `NOM_ARTICOLE.CONT` in tot pachetul — zero
-potriviri. `V_SCC` vine exclusiv din `D.SCC` al lantului de politica. Varianta propusa de Marius nu
-exista nici macar ca ramura moarta.
-
-**Ce inseamna asta pentru perimetru.** „Alege din nomenclator…" nu mai e o adaugare de UI peste un
-mecanism existent: **cere modificare in `pack_facturare`**, adica in COMUN, cu impact peste toata
-suita — sau evitarea completa a lui `contabilizeaza_articol`, ca la ROAAUTO, ceea ce inseamna document
-fara nota de venit. **Aceasta e o schimbare de cost, nu un detaliu**, si se decide de Marius (vezi
-intrebarea deschisa de mai jos).
-
-**`NOM_ARTICOLE.CONT` nu e restrans la clasa 3** — confirmat: `verific_cont`
-(`COMUN\programe\oproceduri_comune.prg:2389-2415`) verifica doar ca acel cont exista in planul de
-conturi al anului (`vplcont_sintetic`), fara filtru de clasa; nu exista `CHECK CONSTRAINT` pe coloana
-si nici vreo ramificare pe `Left(cont,1)` aplicata articolelor. Deci un articol negestionabil **poate**
-purta legitim un cont 6xx / 7xx, cum a spus Marius. **Dar codul de azi nu-l foloseste asa**: acel camp
-merge in `VANZARI_DETALII.CONT` si de acolo la `descarca_gestiune`, niciodata la `SCC`. Ca sugestia lui
-Marius sa devina comportament, ar trebui **cod nou in `pack_facturare`** — adica in COMUN, cu impact
-peste toata suita. *Vezi intrebarea deschisa de mai jos.*
-
-**`ID_VENCHELT` / `NOM_VENIT_CHELTUIELI` nu e sursa contului.** Tabelul nu are coloana de cont;
-`ID_VENCHELT` se rezolva separat (`NVL(nid_venchelt, NVL(A.ID_VENCHELT, C.ID_VENCHELT))`,
-`ff_...:7205`) si pleaca la `scrie_nota` ca **parametru propriu**, alaturi de `SCD`/`SCC` — e o a
-treia dimensiune analitica (centru de venituri/cheltuieli, pentru raportare), nu contul insusi.
-Presupunerea din runda 7 ca „venitul vine din `Ct_clb_venchelt`" **se retrage**.
-
-De unde vine `CONT`, pe cele doua cai:
-
-| Cale | Sursa contului | Fallback |
-|---|---|---|
-| **gestionabil, cu stoc** — trece prin `do_alege_stoc` (`ofacturare.vc2:13239-13345`) | `STOC.CONT`, de pe lotul ales (`cursor_gestiuni_articol`) | **niciunul** — lot cu `CONT` gol ramane `NULL` |
-| **gestionabil, fara stoc** (`RF_FACTURARE_FARA_STOC = 1`) | `NOM_GESTIUNI.CONT` -> ultimul `STOC.CONT` -> `'371'` hardcodat (`cursor_gestiuni_articol_stoc0`) | singurul loc din pachet cu cascada si default |
-| **negestionabil** — `frm_articol_factura` direct (`:12871-12880`) | `NOM_ARTICOLE.CONT`, citit la cautarea articolului | **niciunul**; gol -> sentinela `'XXXX'` -> `NULL` la INSERT |
-
-`adauga_articol_factura` **nu recalculeaza** contul: il primeste ca parametru `V_CONT` si il scrie ca
-atare. **Nu exista nicio exceptie pe `CONT`** in tot pachetul — spre deosebire de cota de TVA, unde
-lipsa produce explicit `FACT-012` / `FACT-013` / `FACT-018`. O linie fara cont se scrie tacut.
-
-**Precedentul ROAAUTO nu ofera o regula, ci absenta ei.** „Alte servicii” (O-bis) trimite literal `''`
-catre `adauga_articol_factura_deviz` (`oproceduri_devize.prg:1256`), care ajunge `NULL` in Oracle,
-fara `NVL` si fara fallback. Liniile de articole reale din ROAAUTO **ajung deci cu `CONT = NULL`**.
-
-**Decizia 21 (Marius, 09.08.2026)** acopera **contul de gestiune**: cand `NOM_ARTICOLE.CONT` e gol pe
-un articol negestionabil ales din nomenclator, se aplica un **fallback la un cont implicit** — nu se
-accepta `NULL` ca la ROAAUTO, nu se refuza adaugarea. Precedentul de forma exista in pachet:
-`cursor_gestiuni_articol_stoc0` cade in cascada pana la `'371'` hardcodat. Contul anume ramane de ales
-la implementare. **Decizia 21 nu rezolva insa contul de venit** — sunt doua campuri diferite, cum arata
-tabelul de mai sus; la momentul cand a fost luata, distinctia nu era inca stabilita.
-
-~~**Decizia 24: articolul ales din nomenclator primeste `id_pol`-ul unei politici de pret
-implicite.**~~ **RETRASA in runda 8.** Argumentul ei — zero cod Oracle nou, COMUN neatins — ramane
-valabil ca argument, dar pretul lui era o intrebare de configurare cu contabilul (care politica, cu ce
-`SCC`, una sau mai multe) si un cont de venit uniform pentru orice articol adaugat asa. Marius a ales
-in loc derivarea contului. **Nu se reintroduce.** *Vezi J-quater.*
-
-Ramane valabil de aici, si e important: **alegerea politicii de catre operator** a fost si ea respinsa
-— muta costul pe fiecare adaugare si cere operatorului sa stie ce inseamna o nota contabila.
-
-**Ce se stie sigur pana atunci:** decizia 16 si decizia 20 **nu sunt anulate** de subiectul asta — pe
-articolele **cu** politica de pret (lista de preturi, comanda, contract, retur) contul de venit vine
-ca azi si nimic nu se schimba. Blocajul e strict pe ramura **„Alege din nomenclator…"**, adica pe
-partea din S4g care adauga articole fara politica.
-
-**Unde e efectiv de lucru pentru asta:** doar pe **comanda**. Verificat
-(`docs\cercetare\retur_si_lista_preturi.md`, B): pe contract, `crsarticole` contine deja lista de
-preturi intreaga, deci adaugarea libera **merge azi**; pe comanda, `cursor_comanda` umple `crsarticole`
-strict cu articolele comenzii (`ofacturare.prg:266-308`), deci nu merge. Restrictia **nu** e pe buton
-si nu e la validare — e in continutul cursorului. Se rezolva ca la copiere: `APPEND FROM` peste
-`crsarticole` cu rezultatul lui `cursor_preturi` (`ofacturare.prg:454-473`).
-
-#### J-quater. Deciziile 27 / 27-bis — contul de venit derivat, aplicat din VFP
-
-> **DEPASITA IN PARTE — de citit cu avertismentul asta in fata.** **Decizia 34** relaxeaza 27-bis
-> (`contabilizeaza_articol` primeste parametru de cont) si **decizia 35** cere ca `pack_facturare` sa fie
-> singurul cod de contare, si la emitere si la editare. Prin urmare:
-> - **punctul 1** (de ce ROAACNPRO si contractul nu sunt contraexemple) si **punctul 2** (derivarea
->   contului din `CORESP_CONT_VENCHELT` — regula deciziei 27) **raman valabile integral**;
-> - **punctul 3, „reteta in 4 pasi"** — politica tehnica per `SCC`, interogarea inversa,
->   `pack_preturi.adauga_politica_pret_art`, inserarea articolului in politica — e **ABANDONAT**. Se
->   pastreaza doar ca trasabilitate a rationamentului. **Nu se implementeaza si nu se reargumenteaza.**
-> - **cele trei variante** de la finalul sectiunii (reteta / nota pe antet / nota pe antet ca fallback)
->   sunt **caduce**: alegerea a fost facuta prin decizia 34.
->
-> Proiectarea in vigoare e parametrul deciziei 34 — `docs\cercetare\parametru_cont_contabilizeaza_articol.md`.
-
-Raport: `docs\cercetare\coresp_cont_venchelt.md`. Trei lucruri s-au stabilit, in ordinea in care conteaza.
-
-**1. Intrebarea lui Marius („in ROAACNPRO si pe factura din comanda / contract se adauga articole fara
-politica — de ce nu si aici?") a primit raspuns: observatia e reala, dar niciunul din cele doua exemple
-nu e un contraexemplu.** `FACT-024` ramane blocantul.
-
-- **ROAACNPRO nu foloseste deloc `contabilizeaza_articol`.** Salvarea facturii ACN
-  (`proceduri_acnpro.prg:3331-3467`) merge pe `initializeaza_date_factura` ->
-  **`adauga_articol_factura_deviz`** -> **`scrie_in_vanzari`** -> **`pack_acn.salveaza_regdoc`**.
-  Cautare directa dupa `contabilizeaza_articol` in acel fisier: **zero rezultate**. Nota contabila o
-  scrie o procedura proprie ACN, care nici nu primeste `id_pol` printre parametri. Acelasi tipar ca
-  ROAAUTO „Alte servicii" (J-ter, punctul 2): **o cale de facturare paralela**, nu o dovada ca articolele
-  fara politica sunt tolerate.
-- **Pe contract, articolul „liber" nu e fara politica.** `crsarticole` e populat de
-  `pack_facturare.cursor_contract` / `cursor_preturi`, care **selecteaza explicit `A.ID_POL`**
-  (`ff_...:2162-2167`) si care ruleaza la fiecare apel `completare_politica_stoc` (`ff_...:2151`).
-  Deci fiecare rand din grila vine deja **cu o politica reala atasata**. „Adaugare libera pe contract"
-  inseamna „orice articol din lista de preturi, nu doar cele din contract" — nu „articol fara politica".
-
-  **Diferenta reala e cursorul-sursa al grilei, nu tipul de document:** `caut_articol`
-  (`COMUN\programe\ocautare.prg:1636-1735`, cautarea in nomenclator) **nu are coloana `id_pol` in nicio
-  ramura**; `cursor_preturi` / `cursor_contract` o au, pentru ca pleaca de la politica, nu de la
-  nomenclator. Povestea #13 cere exact ce nu exista azi nicaieri.
-- **Ce verifica de fapt `FACT-024`:** `SELECT COMPUS, ID_POL_ART FROM VCRM_POLITICI_PRET_ART WHERE
-  ID_ARTICOL = ... AND ID_POL = ...` (`ff_...:7278-7302`) — deci **apartenenta articolului la politica
-  de pe linie**. Ipoteza din runda 8 e **partial** confirmata: verificarea e de apartenenta, dar `id_pol`
-  **nu** vine din antet ca valoare unica — e parametru per linie, trimis de VFP. Doua cauze diferite
-  (`id_pol` gol; articol nemembru) produc aceeasi eroare, iar codul nu le distinge.
-
-**2. `CORESP_CONT_VENCHELT` exista, e populat si e folosit in productie — dar niciodata pentru
-`CONT_VENIT`.** Toti consumatorii gasiti (`pack_vin`, `pack_devize`, `gestiune_pack_gest_import`,
-rapoarte de gestiune) citesc `CONT_CHELT` sau `CONT_APROVIZIONARE`. Coloana `CONT_VENIT` **are date
-reale** dar **zero consumatori**, nici Oracle nici VFP. Cheia de join e stabila si testata: pe `CONT`, cu
-`STERS = 0`, prin `LEFT JOIN` — tiparul se copiaza identic. Deci regula lui Marius e implementabila; e
-insa **un consumator nou**, nu o reteta deja rulata.
-
-**Masurat pe baza vie (10.08.2026, `MARIUSM_AUTO`) — `docs\cercetare\verif_baza_vie_cont_venit.md`:**
-tabelul are **41 de randuri active**, din care exact **20 au `CONT_VENIT`** populat; restul 21 sunt
-conturile de ajustari (`391`…`398`, toate cu `CONT_CHELT = 681`), care nu poarta marfa. **Niciun `CONT`
-nu e duplicat**, deci pasul 1 al retetei e determinist — desi schema nu are unique pe `CONT`, doar `PK`
-pe `ID_CCV`. Si, decisiv: **zero articole active cad pe un rand cu `CONT_VENIT` gol**, deci ramura
-„cont derivat gol" se trateaza defensiv dar nu are cazuri reale. DDL-ul complet e in raport.
-
-**3. Calea VFP (decizia 27-bis) exista si e construita din piese functionale.** Patru pasi.
-
-> **Clarificare ceruta de Marius (10.08.2026) — de citit inainte de cei patru pasi.** Politica **nu e
-> necesara ca sa se afle contul.** Regula deciziei 27 il determina complet, in VFP: corespondentele pe
-> clasa 3, contul de pe articol daca e 6xx / 7xx, `704` altfel. Aia e **pasul 1**, si e verificata pe date.
-> Politica e necesara **doar ca canal de transport** catre Oracle: `contabilizeaza_articol` **nu are
-> parametru de cont de venit** — primeste `V_ID_POL` si deduce singura contul prin lantul politica → nota →
-> `NOTE_CONTABILE.SCC`. Deci **pasii 2-4 nu decid nimic**, doar convertesc un cont pe care VFP il stie deja
-> intr-o forma pe care pachetul o accepta. Indirectarea e consecinta deciziei **27-bis**, nu a regulii lui
-> Marius: daca pachetul ar putea fi modificat, un parametru de cont ar face pasii 2-4 sa dispara.
-> **INCHIS (runda 9 + decizia 35).** Cautarea canalului direct s-a terminat —
-> `docs\cercetare\canal_cont_venit_fara_politica.md`. Verdict: canalul **exista** (`actactan` / `tact` →
-> `oscrie_in_fisiere` → `pack_contafin.SCRIE_IN_ACT`), dar e cablat pe **editarea unei note deja scrise**,
-> nu pe emitere; emiterea trece exclusiv prin `scrie_factura2` → `contabilizeaza_articol`. Pistele
-> `V_CONT` (e contul de gestiune), setterele de sesiune, `ID_VENCHELT` si `GetAnaliticByGrupUtilizatori`
-> sunt **toate NU**.
-> **Si nu se foloseste oricum:** decizia 35 il respinge explicit in #13, ca sa nu existe doua coduri de
-> contare. Reteta in 4 pasi cade prin **decizia 34** (parametru de cont in pachet), nu prin canal.
-
-1. **VFP calculeaza `SCC`-ul** dupa regula deciziei 27: `CORESP_CONT_VENCHELT.CONT_VENIT` pe contul de
-   gestiune al liniei (articol gestionabil), `NOM_ARTICOLE.CONT` daca e 6xx / 7xx, altfel `'704'`.
-2. **VFP cauta o politica a carei nota are deja acel `SCC`** — interogarea inversa pe acelasi lant:
-   `CRM_POLITICI_PRETURI -> CRM_NOTE_VANZARI -> NOTE_CONTABILE`, `WHERE NC.SCC = :cont_calculat`.
-   Interogare **noua**, dar pe coloane si relatii deja confirmate.
-   **Corectat pe baza vie:** legatura nu e politica -> nota, ci politica -> **set de note** —
-   `CRM_POLITICI_PRETURI.ID_NOTA` -> `CRM_NOTE_VANZARI.ID_SET` -> `NOTE_CONTABILE.ID_SET`. Pe cele 7 note
-   de vanzari active fiecare set are **un** rand, dar in tabel exista seturi cu pana la **30** de randuri,
-   deci „nota politicii" e bine definita doar cat timp seturile de vanzari rămân cu un rand.
-   **Si mai important: filtrarea pe `SCC` singur nu e suficienta** — vezi „Ce nu e gratuit" mai jos.
-3. **VFP se asigura ca articolul e membru al acelei politici** — RPC **existent**
-   `pack_preturi.adauga_politica_pret_art`, deja folosit exact asa (verifica intai, insereaza daca
-   lipseste) in `ofacturare.vc2:15551-15587`, la modificarea listei de preturi de la NIR. **`pack_preturi`
-   nu e `pack_facturare`** — nu se atinge nimic din pachetul comun de facturare.
-4. **VFP trimite acel `id_pol`** in `adauga_articol_factura` (`V_ID_POL` e parametru de intrare explicit,
-   `ff_...:4989-5015`). `contabilizeaza_articol` ruleaza **neschimbata**.
-
-**Modelul „politica tehnica, configurata o data, populata automat" exista deja in pachet:**
-`completare_politica_stoc` (`ff_...:2093-2120`) face `MERGE` in `CRM_POLITICI_PRET_ART` pentru toate
-articolele `IN_STOC = 1` sub politica `pack_facturare.nid_politica_stoc`, alimentata din optiunea globala
-`gnId_pol_pret_stoc` (`ofacturare.vc2:21733-21753`). Nu e direct reutilizabila — are o singura nota
-pentru toate articolele, iar decizia 27 cere pana la sase conturi diferite — dar arata ca tiparul e
-acceptat in produs.
-
-**Calea VFP e mai completa decat modificarea pachetului**, nu doar mai ieftina: politica reala aduce si
-`CU_TVA`, `IN_VALUTA`, `EXPLICATIE`, `ASCD`, `ASCC` din nota configurata. Un fallback in
-`contabilizeaza_articol` ar da doar `SCC`; `CU_TVA` si `IN_VALUTA` **nu au nicio sursa alternativa** in
-afara lui `NOTE_CONTABILE`, deci ar trebui hardcodate — cu risc de calcul gresit al bazei si al TVA.
-
-**Ce nu e gratuit, si trebuie stiut inainte de S4g:**
-
-- **Pasul 2 depinde de configurarea fiecarui client — deci nu se poate proiecta pe acoperire.**
-  Decizia lui Marius, 10.08.2026: **datele din Dev nu sunt baza de proiectare.** Fiecare client isi
-  defineste propriile politici de pret, fiecare cu nota ei de vanzare salvata pe un `ID_SET`. Pe schema
-  de dezvoltare masurarea a dat `704` cu 19 politici valabile, `707` cu 4, `7015` cu 1, si zero pentru
-  `711` / `702` / `703` / `7018` — **dar aceste numere nu se folosesc ca argument**, pe o baza de client
-  distributia poate fi complet alta. Ce se pastreaza din masurare e strict **structural** (forma lantului,
-  absenta unique-ului pe `CONT`, bug-ul de set multi-rand) plus un fapt negativ: **afirmatia rundei 8 ca
-  „pentru `704` nu exista nicio nota configurata" nu se susține ca regula** — pe Dev exista patru, deci
-  pasul „se creeaza nota pentru 704" nu poate fi pus in plan ca obligatoriu.
-  **Consecinta de proiectare:** reteta nu are voie sa presupuna ca gaseste o politica pentru `SCC`-ul
-  calculat. Ori garanteaza singura existenta a ceea ce foloseste (politica tehnica creata de produs), ori
-  are o cale care **nu trece prin politica deloc** — vezi mai jos.
-- **`PTVA` de pe nota e inofensiv — verificat pe cod, nu presupus.** `cursor_articol`
-  (`PACK_FACTURARE:7218-7271`) **nu selecteaza `D.PTVA`**; cota folosita efectiv vine din
-  `detalii_articol.proc_tvav * 100 - 100` (`:7464`), adica din articol / document. Deci o nota cu
-  `PTVA = 5` pe un articol cu 21% **nu produce nimic** — coloana e moarta pentru aceasta procedura.
-  Ingrijorarea initiala („criteriul trebuie sa fie `(SCC, PTVA)`") **se retrage**.
-  `IN_VALUTA = 1` de pe nota pe un document in lei nu da nici eroare, nici suma greșita — doar populeaza
-  redundant `ACT_TEMP.SUMA_VAL` la curs 1 (`scrie_nota:12391-12404`, `:12492-12507`): inconsistenta
-  cosmetica, nu contabila. `ASCD` / `ASCC` nule au fallback automat prin
-  `GetAnaliticByGrupUtilizatori` (`:7409-7428`), iar `ID_PARTD` / `ID_PARTC` **nu se citesc de pe nota**
-  deloc — vin din contul si din contextul documentului (`:12510-12530`).
-- **In schimb, `ID_SET` cu mai multe randuri dubleaza venitul SI descarcarea de gestiune.** Asta e
-  riscul real, si e mai grav decat cel presupus. `cursor_articol` face `LEFT JOIN NOTE_CONTABILE D ON
-  C.ID_SET = D.ID_SET` **fara `ROWNUM`, fara agregare, fara filtru**, iar bucla care il consuma
-  (`:7393-7542`) executa `scrie_nota` **si** `descarca_gestiune` **o data pentru fiecare rand al
-  setului, cu aceeasi cantitate si acelasi pret intreg de fiecare data** — nu impartite. Nu exista
-  nicio logica de distributie: `ORDINE` nu apare in tot pachetul. Deci pasul 2 nu trebuie doar sa
-  gaseasca un rand cu `SCC`-ul potrivit, ci **sa garanteze ca setul ales are exact un rand**. Cele 7
-  note de vanzari active au, azi, exact un rand fiecare — dar 30 din cele 40 de seturi din baza au mai
-  multe, cu maxim 30. **Conditia care face reteta sigura e o coincidenta a datelor curente, nu o
-  garanție a codului.** Sursa: `docs\cercetare\s10_pret_rederivat.md`, „Completare: nota contabila a
-  politicii", punctul 1.
-- **Pasul 3 poluează o lista de preturi de producție.** Politica **este** lista de preturi: candidatele
-  reale contin `STOC PRODUSE` cu **6310** articole si `LISTA PRETURI LEI` cu **909**, plus liste cu nume de
-  client si de sezon (`CHIOSC`, `SERVICE AUTO`, `S7 CRACIUN`…). Un articol adaugat ad-hoc pe factura ar
-  aparea de acum in acea lista, cu pretul cu care a fost facturat o data. **Deci pasul 2 nu trebuie sa
-  caute orice politica potrivita, ci o politica tehnica dedicata, una per `SCC`** — modelul
-  `gnId_pol_pret_stoc` extins de la una la sapte. Cele **sase** politici cu 0 articole din baza vie arata
-  ca o politica goala e o stare acceptata de produs.
-- **Ambiguitatea celor 19 politici pe `704` e de lista de preturi, nu de rezultat contabil** — majoritatea
-  trimit la aceeasi `id_nota = 1`, deci toate dau `704` / `PTVA = 21` / lei. Cu atat mai mult, criteriul de
-  departajare corect e „care lista de preturi accept sa murdaresc", iar raspunsul e „niciuna dintre cele
-  existente".
-- **Politica tehnica devine vizibila utilizatorului** in `caut_politici_curente_util()` — aceeasi functie
-  ca la cautarea normala. Ori se filtreaza explicit (flag / prefix dedicat), ori se accepta riscul ca
-  cineva sa o aleaga din greseala pe o factura normala. **De decis in S4g.**
-- **`id_pol` devine populat** acolo unde azi ar fi gol. Nu s-a gasit cod care sa presupuna „`id_pol` gol =
-  articol fara politica", dar nici nu s-a cautat exhaustiv.
-- **Doua politici active nu au `ID_NOTA`** (`32 HOTEL TAXE`, `33 HOTEL CAZARE`) — `id_pol` valid, nota
-  absenta. Ce face `contabilizeaza_articol` in acest caz e intrebare deschisa, trimisa pe cod. E o gaura
-  care **exista deja azi**, independenta de #13.
-
-**RASPUNS LA DECIZIA 32 — reteta RAMANE. `docs\cercetare\idpol_comanda_contract.md`.**
-
-Intrebarea era: cum alege programul nota contabila la factura din comanda, care „nu are politica de pret"?
-**Raspuns: are. Structural nu poate sa nu aiba.** `COMENZI_ELEMENTE.ID_POL` e **`NOT NULL`** la nivel de
-schema (constrangerea `SYS_C0015376`, plus `FK_COMENZI_ELEMENTE_002`) — verificat direct: **0 din 7108
-randuri** au `ID_POL` nul sau zero, 9 politici distincte in uz, toate cu nota atasata. Deci nu exista nicio
-ruta alternativa catre nota, si **nu exista contradictie cu concluzia rundei 8**: pe comanda cazul „`id_pol`
-gol" e imposibil, nu doar neintalnit. Ce percepe operatorul ca „n-am ales nicio politica" e faptul ca
-politica se alege **o data pe comanda** — manual sau moștenita dintr-o optiune legata de tipul comenzii —
-si de atunci fiecare articol adaugat o primeste automat, din `com_vpreturi_utilizator`, view care filtreaza
-`id_pol IS NOT NULL` la sursa. Pe **contract** tiparul e acelasi, dar cheia stocata e
-`CTR_ARTICOLE.ID_POL_ART` — FK direct la randul din `CRM_POLITICI_PRET_ART`, **nullable**, cu cazuri reale.
-
-**De ce `FACT-024` nu se declanseaza pe comanda / contract:** nu pentru ca ar exista un fallback, ci pentru
-ca **articolul nu e ales niciodata din nomenclator** — e ales dintr-o lista deja filtrata pe politica, deci
-apartenenta e garantata **prin construcția listei**, nu prin validare. Exact aici e diferenta cu #13, unde
-`caut_articol` ofera nomenclatorul intreg.
-
-**Deci refolosirea nu simplifica nimic:** mecanismul de jos — RPC de inserare + apartenenta garantata — e
-**exact** ce propune reteta in 4 pasi. Ce ar simplifica cu adevarat („ia politica curenta fixa si pune
-articolul in ea") e **decizia 24, retrasa**, si motivul retragerii sta: o politica unica da **un singur**
-cont de venit oricarui articol, indiferent de natura lui — opusul deciziei 27. Comanda si contractul nu
-raspund niciodata la intrebarea „**care** politica pentru **acest** articol", pentru ca la ele politica vine
-gata aleasa, o data, de operator.
-
-**CORECTIE, a doua tura a aceluiasi agent — premisa lui Marius ERA corecta, dar pe contract, nu pe comanda.**
-Exista o ruta reala catre nota contabila **complet in afara lui `id_pol`**: la **contractele cu rate /
-scadentar** (`OPT_FACTURARE IN (1, 2)`), o functie separata — **`contabilizeaza_rata`** — scrie nota direct
-din **`CONTRACTE.ID_NOTA`**, fara sa treaca prin `CRM_POLITICI_PRETURI`. Confirmat pe cod de agent si pe o
-factura reala (`id_vanzare 360`: `SCD = 4111` / `SCC = 704` in `ACT`, pe o linie fara articol si fara
-politica). **Structura confirmata independent de sesiunea principala:** `CONTRACTE.ID_NOTA` exista, e
-nullable, si e **populat pe 19 din 242 de contracte**, rezolvand la note reale — `1 NOTA 1` → `SCC 704`
-(5 contracte), `2 DISCOUNT` → `SCC 4111` (5), `5 VANZARE MARFA` → `SCC 707` (1). Deci nota **pe antetul
-documentului** nu e o ipoteza, e un mecanism in uz.
-
-**Ce inseamna asta pentru #13, si de ce e o decizie de produs, nu una tehnica.** Tiparul „nota pe antet"
-ar fi **mai simplu decat reteta in 4 pasi**: n-ar mai fi nevoie nici de gasirea politicii, nici de
-inserarea articolului in ea, nici de politica tehnica — antetul ar purta nota, iar liniile ad-hoc ar
-moșteni-o. **Dar cere cod nou in `pack_facturare`**, pentru ca `contabilizeaza_rata` trateaza rate, nu
-articole de factura. Adica **incalca exact decizia 27-bis** („`pack_facturare` nu se atinge").
-**Deci alegerea e a lui Marius, intre trei variante:**
-
-1. **reteta in 4 pasi** (decizia 27-bis respectata, `pack_facturare` neatins, dar cere politica tehnica per
-   `SCC` si o interogare inversa noua);
-2. **nota pe antet ca la `contabilizeaza_rata`** (mult mai simplu si mai curat conceptual, dar **relaxeaza
-   decizia 27-bis** — cod nou in pachetul comun intregii suite);
-3. **nota pe antet doar ca fallback** pentru articolele fara politica, lasand restul neschimbat.
-
-**Nu se implementeaza nimic pana la aceasta alegere.** Detalii: `idpol_comanda_contract.md`, sectiunea E-bis.
-
-**Doua observatii din date, gasite la confirmarea verdictului:**
-
-- **Precedentul cerut de decizia 27 exista deja in producție, si e mai bun decat `gnId_pol_pret_stoc`.**
-  Politica `7 DISCOUNT` apare pe **870 de linii de comanda** si trimite la nota `2 DISCOUNT`
-  (`SCD = 667`, `SCC = 4111`). E o politica de pret folosita **exclusiv ca mecanism de rutare contabila**,
-  nu ca lista comerciala de preturi. Deci „politica tehnica, dedicata unui cont, populata automat" nu e o
-  invenție a lui #13 — **produsul o face deja**, pentru discount. Argument direct pentru politica tehnica
-  per `SCC`.
-- **Garantia prin construcția listei nu e etanșă in date: 37 de linii de comanda au un articol care NU e
-  membru al politicii de pe linie.** **VERIFICAT (runda 10)** —
-  `docs\cercetare\linii_comanda_articol_nemembru.md`. **Decizia 32 NU se redeschide in sensul periculos:
-  nu exista cale de cod care sa ocoleasca `FACT-024`.** Patru rezultate:
-  - **Cifra 37 se reconfirma, dar numitorul din plan era gresit** — `6868` era alt numitor; cel corect
-    pentru linii cu `ID_POL NOT NULL` e **7108**.
-  - **Premisa „37 de linii ar cadea la facturare" era partial gresita.** Un rand cu `CANTITATE < 0` **nu
-    dovedeste ca linia a fost facturata**: singurul loc care il insereaza e `inchide_comanda`
-    (`PACK_FACTURARE:5769-5820`), care scrie *diferenta ramasa* la **inchiderea** comenzii, chiar si cand
-    nimic nu s-a facturat pe acea linie. **34 din 35 de linii negative n-au nicio factura in spate, nici
-    macar stearsa** — comenzile au fost inchise, nu facturate.
-  - **Una singura chiar a ajuns intr-o factura emisa** — comanda `497`, articolul `4294507522`
-    („VOUCHER DISCOUNT") pe politica `7` („DISCOUNT"), in factura `ID_VANZARE = 1028`, `20.03.2026`. Si
-    codul **chiar a rulat** `contabilizeaza_articol` pentru ea: apelul e in ramura `ELSE` a lui
-    `CASE pack_facturare.ntip` din `scrie_factura2`, care exclude doar transferurile, avizele de custodie
-    si facturile cu rate — tipul 3 cade in `ELSE`. Deci **fie articolul era membru al politicii la
-    20.03.2026 si a fost scos ulterior, fie verificarea a fost ocolita altfel; dovada pentru a doua
-    varianta nu exista.**
-  - **Cauza e NEDETERMINABILA DIN DATE, structural.** `CRM_POLITICI_PRET_ART` **n-are coloana `STERS`** si
-    n-are tabel de istoric — stergerile sunt **fizice, fara urma**, deci nu se poate reconstitui starea de
-    la 20.03.2026. Coloanele de audit ale facturii (`VANZARI.ID_UTILS` / `DATAORAS` si cele de pe cele
-    doua linii) sunt **toate NULL**, deci nici o editare ulterioara nu s-a inregistrat. Indiciu de tipar,
-    nu dovada: aceeasi pereche articol-politica apare pe **35 de comenzi diferite**, ceea ce sustine o
-    **curatare de catalog** mai degraba decat 35 de greseli independente de introducere.
-
-  **Ce ramane, si cum se formuleaza:** pentru celelalte 36 de linii, „zero facturi in date" **nu
-  demonstreaza ca nu se pot factura** — demonstreaza doar ca nu s-a intamplat. Iar cu starea de azi a lui
-  `CRM_POLITICI_PRET_ART`, toate cele 37 **ar** cadea cu `FACT-024` daca ar trece acum prin
-  `contabilizeaza_articol` (verificat pe view-ul `VCRM_POLITICI_PRET_ART`, care n-are filtru propriu, deci
-  vede exact aceleasi perechi ca tabelul). **Concluzia pentru #13 e neschimbata:** garantia prin
-  constructia listei e reala cat timp catalogul nu se editeaza sub documente deja emise.
-
-**Verificarile pe baza vie sunt facute** (10.08.2026) — `docs\cercetare\verif_baza_vie_cont_venit.md`:
-interogarea inversa pe fiecare `SCC` candidat, DDL-ul lui `CORESP_CONT_VENCHELT`, distributia articolelor
-pe ramurile deciziei 27 (6125 din 6430 pe ramura gestionabila), efectele colaterale ale pasului 3 si trei
-fragilitati de structura. **Rămâne deschisa doar partea de cod**, listata mai sus.
-
-### K. Discountul pe linie (decizia 14)
-
-Verificat de doua ori, pe formularul real si pe DDL. Raspunsul la intrebarea „e doar procentual?” e
-**nu, si nici doar valoric — sunt amandoua, dar in alta fereastra**.
-
-**Intrarea pentru operator exista deja, in dialogul de articol.** `frm_articol_factura`
-(`ofacturare.vc2:1108-2659`), deschis la fiecare adaugare de articol, are trei campuri legate:
-`Clb_procent_discount` (procent), `Clb_discount_unitar` (suma, in lei sau valuta) si
-`Clb_discountctva` (varianta cu TVA). Toate cheama
-`frm_articol_factura.do_calculeaza_discount(valoare, tip)` (`:1874-1976`) cu `tip = 1` procent,
-`tip = 2` lei, `tip = 3` valuta (`:2602-2649`) — tastezi in oricare, se recalculeaza celelalte.
-Rezultatul intra in `poArticol.discount_unitar` si variantele lui, apoi in `crsfactura` prin
-`Replace` (`:12956-12957`).
-
-**Se stocheaza o singura coloana, si e valoare.** `VANZARI_DETALII.DISCOUNT_UNITAR NUMBER(22,6)`
-(`ff_2024_06_13_02_COMUN_FACTURARE.sql:3`; simetric pe `VANZARI_DETALII_TEMP` la `:9` si pe
-`CRM_POLITICI_PRET_ART` la `:16` — **trei tabele diferite, nu aceeasi coloana de trei ori**).
-**Nu exista coloana de procent** pe `VANZARI_DETALII` — procentul e doar mod de introducere.
-Parametru Oracle: `V_DISCOUNT_UNITAR` in `adauga_articol_factura`
-(`ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql:4986`), scazut din pretul fara TVA inainte de TVA
-(`:15794-15847`).
-
-**In grid, azi, comportamentul e inconsecvent.** Pe factura in lei ramane `cDiscountCTva`, care e
-`ReadOnly = .T.` (`ofacturare.vc2:12311-12317`); pe factura in valuta ramane `cVdiscountftva`, care
-**e editabila** — dar nu are niciun `Valid` / `InteractiveChange`, deci o editare directa in celula
-schimba valoarea bruta fara sa refaca totalurile. Excluderea reciproca e la `:15269-15278`.
-
-**Corectie fata de runda 3:** afirmasem ca prototipul are deja procent pe linie, ca argument pentru
-pornirea de la el. **Fals.** `procdisc` apare o singura data in tot fisierul, ca `ControlSource` de
-coloana (`:16721`), fara niciun `Replace` care sa-l populeze si fara corespondent Oracle — e schela
-moarta. (Restul aparitiilor de „procdisc” sunt variabila de optiune `gnMemProcDisc`, altceva.)
-Argumentele pentru prototip raman celelalte doua: controalele de antet si butoanele deasupra gridului.
-
-**Ce ramane de facut:**
-
-- cele doua campuri din dialogul de articol devin **coloane in grid** — procent si valoare unitara —
-  cu **acelasi calcul reciproc** din `do_calculeaza_discount`, mutat pe evenimentele coloanelor;
-- se repara astfel si inconsecventa de mai sus: aceleasi validari in ambele monede;
-- se pastreaza excluderea pe `in_valuta`;
-- modelul de date **nu se atinge**;
-- **de verificat separat, blocant**: daca `discount_unitar` apare pe rapoartele `.frx` si daca e
-  transmis in eFactura (UBL) si SAF-T. Daca nu apare pe hartie, documentul tiparit nu explica totalul.
-
-#### K-bis. Discountul de DOCUMENT — cota, explicatia si atribuirea pe cote
-
-Cercetare terminata, verificata la sursa (doua runde, a doua a corectat concluzii ale primei —
-vezi rezervele de mai jos). Detaliu complet: `docs\cercetare\discount_document_cota_tva.md`.
-
-**Cota discountului de document = cota MAXIMA de pe factura, ca regula implicita.** Nimeni n-o
-alege: nu exista control in formular si nicio coloana pe `VANZARI` pentru ea.
-`Calculate Max(proc_tvav)` — `COMUN\programe\oproceduri_facturare.prg:1387`,
-`COMUN\clase\ofacturare_comun.vc2:4495` si `:7294`, `COMUN\programe\ofacturare_stoc.prg:582`.
-Discountul intra ca **pseudo-linie negativa** printr-un rand-sentinela `Replicate('Z',20)`
-(`COMUN\programe\ofacturare_comun.prg:1886-1897`), care devine linia „Discount NN.NN % Factura"
-(`:1273-1392`).
-
-**Explicatia nu exista ca notiune — e o constanta.** In XML, `AllowanceChargeReason="Discount"`
-si `ReasonCode="95"` sunt hardcodate (`COMUN\programe\xmlefactura.prg:774-776`), la fel
-`currencyID="RON"` (`:778`). Textul construit in VFP („Discount 10.00 % Factura") nu ajunge in
-XML.
-
-**Regula e implementata de doua ori, independent — nu intr-un singur loc.** In VFP (mai sus) si
-in PL/SQL: `PACK_FACTURARE.recalculeaza_totaluri_vanzari`,
-`MAX(ROUND(discount*(a1.proc_tvav-1),...)) as DISC_TVA_RON` —
-`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:16081-16092`,
-scris in `VANZARI.DISCOUNT_TVA` si de acolo in `TOTAL_TVA` / `TOTAL_CU_TVA` (`:16214-16227`).
-**Pentru #13: doua locuri de schimbat, nu unul** — daca se schimba doar unul, `VANZARI.TOTAL_TVA`
-si TVA-ul din XML diverg pe facturile cu cote mixte.
-
-**Defectul dovedit e de atribuire fiscala, nu de validare.** Pe cote mixte, tot TVA-ul
-discountului se scade din cota maxima. Exemplu: 1000 lei la 21% + 1000 lei la 11%, discount de
-document 10% (200 lei) → se declara 10 lei TVA in minus, mereu in acelasi sens (TVA colectat
-subdeclarat). Aceeasi valoare gresita ajunge si in nota contabila si in jurnalul de TVA. Caz-limita
-real, masurat: daca liniile de la cota maxima sunt o mica parte din total, `TaxSubtotal` iese cu
-baza negativa (`TaxableAmount = -410.00`).
-
-**Ipoteza bazei negative — verdict nuantat, asa cum a iesit din verificare, nu simplificat.**
-Temerea: pseudo-linia, avand `id_jtva_coloana = 0`, iese din `LEFT JOIN` cu `coloana_jv` NULL si
-formeaza grup propriu in `C_TVA_FACTURA`. **Infirmata pe factura obisnuita** — masurat headless,
-`IIF()` din VFP intoarce ramura falsa, nu `.NULL.`, cand conditia e nula, deci pseudo-linia se
-contopeste corect. **Confirmata insa pe facturile scutite / taxare inversa / intracomunitare**,
-unde liniile reale au `scutit = 1` si `expltva` completat iar pseudo-linia are `0` si gol: apar
-doua grupuri, deci un `TaxSubtotal` in plus cu baza negativa si categoria `Z`, iar
-`agettipcota(1)` (`xmlefactura.prg:782-786`) devine ambiguu intre `E` si `Z`.
-
-**Nu blocheaza factura — validat, nu presupus.** Validat offline cu DUKIntegrator, 6 scenarii,
-inclusiv un control negativ care chiar iese cu erori (`BR-CO-13` + `BR-CO-15`) — deci cele „ok"
-inseamna ceva. Trece inclusiv un caz cu `TaxableAmount = -400.00`. Regulile pe categorii
-(`BR-S-08` / `BR-E-08` / `BR-Z-08`) se satisfac trivial: aritmetica inchide, modelarea fiscala e
-cea gresita, si asta niciun schematron nu prinde. **Rezerva de scris explicit:** validatorul local
-e din 2022; validatorul ANAF online n-a fost apelat (interdictie).
-
-**`currencyID="RON"` hardcodat e neconformitate reala si activa, dar fara dovada ca ar cauza
-respingere.** Dovedit pe fisier: XML-ul in EUR de la VENDING_MASTER e identic pe SHA256 cu cel din
-`TRIMISE` (deci exact ce a plecat la ANAF) si a fost acceptat. Respingerea din `ERORI` e a unei
-incarcari anterioare, pentru alte reguli.
-
-**Nu s-a putut proba pe date reale, si asta ramane netransat.** In baza accesibila sunt 3 facturi
-cu discount de document (toate cu o singura cota, anterioare eFacturii) si 34 cu cote mixte fara
-discount — intersectia e goala. Cele 4 XML-uri de productie cu alocare de document sunt, dupa trei
-indicii independente, discounturi pe linie, nu de document. Absenta din date nu e dovada (regula
-casei). Ramane nedovedit prin rulare: reproducerea end-to-end prin program a scenariului „factura
-scutita + discount de document".
-
-**Recomandarea cercetarii pentru #13:** repartizare proportionala automata pe cote, **nu se cere
-utilizatorului cota**. Discountul de document nu are o cota proprie de ales — natura lui de TVA e
-determinata de liniile pe care le reduce; a pune operatorul sa aleaga inseamna a-i cere o decizie
-fiscala pe care datele o dau deja. Pentru explicatie: un singur camp text optional pe document,
-folosit ca `AllowanceChargeReason` in locul constantei (`ReasonCode` ramane `95`).
-
-**Doua completari obligatorii daca se implementeaza, altfel reparatia e degeaba:**
-- bucatile de discount trebuie sa primeasca **`id_jtva_coloana` al grupului pe care il reduc**, nu
-  doar cota — cheia de grupare are cinci campuri si `expltva` se completeaza tot prin
-  `id_jtva_coloana`. O implementare care seteaza doar `proc_tva` lasa grupul orfan exact unde e azi;
-- **eFactura nu are nevoie de nicio modificare** — `xmlefactura.prg:758-792` grupeaza deja
-  `GROUP BY proc_tva` si emite cate un `AllowanceCharge` per cota.
-
-Doua consecinte vizibile daca se implementeaza: factura tiparita va arata N randuri „Discount X %
-Factura" in loc de unul, si nota contabila primeste TVA-ul discountului spart pe cote.
-
-**Decizia a fost luata — decizia 59 (runda 16): repartizare proportionala pe cote.** Vezi sectiunea
-„Decizia 59" de la deciziile rundei 16, cu toate consecintele de implementare.
-
-**Cele doua puncte ramase s-au inchis si ele, tot in runda 16.** Campul text optional de motiv —
-**decizia 61**: da, se adauga (`AllowanceChargeReason`, `ReasonCode` ramane `95`), cu stocare noua
-pe `VANZARI` si un control nou in formular. Asezarea lui s-a inchis in runda 17 — **decizia 66**: sta in banda de totaluri, langa discount. Retroactivi-
-tatea la relistare/retrimitere — **decizia 62**: restrictia de modificare e strict `EsteInEFactura`,
-fara legatura cu nicio data; ramane insa deschis, separat, cazul relistarii (nu editarii) unei
-facturi vechi deja trimise, vezi decizia 62.
-
-### M. Valuta si data cursului (decizia 15)
-
-**Cele doua concepte exista in cod, distinct** — decizia 15 nu introduce o distinctie noua, o face
-vizibila:
-
-- **(a) factura in valuta**: `poDate.in_valuta` / `Curs` / `multiplicator` / `id_valuta`, un singur
-  curs pentru tot documentul;
-- **(b) articol cu pret in valuta pe document in lei**: `poArticol.tip_valuta = 1`, proprietate a
-  politicii de pret, independenta de `in_valuta`. Conversia se face **in VFP**, cu cursul zilei:
-  `poArticol.pretftva = Round(poArticol.pretftva_val * poArticol.Curs / poArticol.multiplicator, gnPPretV)`
-  (`ofacturare.vc2:1989`, `:2017`, `:2953`). Cursurile zilei se incarca exact pe ramura „document in
-  lei”: `If poDate.in_valuta = 1 ... Else citeste_cursuri_zi(poDate.zi_curs)` (`ofacturare.prg:407-418`).
-
-**In baza, exact cum ai descris:** `VANZARI_DETALII` **nu are coloana `CURS`**; pastreaza `PRET` (in
-lei, valoarea de facturare) plus `PRETD` si `ID_VALUTAD` ca urma a pretului original in valuta.
-Cursurile ajung in `VANZARI_CURSURI`, scrise neconditionat la emitere pentru **orice** valuta straina
-aparuta pe linii — deci si pe o factura in lei
-(`PACK_FACTURARE.sql:14491-14501`, `scrie_cursuri`).
-
-**`in_valuta` nu e o alegere, e o proprietate a tipului de document.** Se seteaza o singura data, in
-`Init`: `If Inlist(tnIdSet,223,225,226,227,271) OR INLIST(m.tnTip, 5,6,7,9,10,52) -> .in_valuta = 1`
-(`ofacturare_comun.prg:248-250`), si nu se mai schimba. Selectorul de valuta e chiar eliminat din
-formular cand `in_valuta = 0` (`ofacturare.vc2:9725-9728`), deci operatorul nici nu-l poate alege.
-
-**Problema semnalata, confirmata:** `Clb_zi_curs` e eliminat **doar** pe retur (tip 8, 9), la
-`ofacturare.vc2:9717-9722` — si niciodata in functie de valuta, desi blocul imediat urmator,
-`:9725-9728`, face exact asta pentru selectorul de valuta. Deci **azi campul apare si pe facturi in
-lei**, unde de multe ori nu are ce cauta. Validarea e la randul ei asimetrica: `frm_date_factura`
-cere ziua cursului doar cand `in_valuta = 1` (`:9484`), dar `frm_date_aviz_lucrare` o cere
-**neconditionat** (`:8076`).
-
-**Regula propusa:** campul apare cand tipul nu e retur **si** (documentul e in valuta **sau** exista
-pe document macar un articol cu pret in valuta).
-
-**Unificarea face regula posibila.** Azi cazul (b) nu se poate sti la deschiderea antetului — se
-afla abia dupa incarcarea articolelor, cand antetul e deja inchis si eliberat (`Release
-ofrmceredate`, `ofacturare.prg:248`). In formularul unificat antetul si gridul sunt in aceeasi
-fereastra, deci campul poate aparea in clipa in care intra pe grid primul articol cu pret in valuta.
-**Din acelasi motiv dispare si mecanismul lui #16**: bug-ul de focus si de renumerotare apare la
-revenirea din `frm_curs` intr-un antet care tocmai s-a inchis — in formularul unificat nu mai exista
-un antet inchis la care sa te intorci. `frm_curs` e in `COMUN\clase\onom_curs.vc2:537`, deschis din
-`vizualizeaza_curs` (`oproceduri_curs.prg:8-42`) ca recuperare la eroarea Oracle 20005
-(`ofacturare.prg:313-317`).
-
-**Capcana:** `poDate.zi_curs` se trimite **neconditionat** ca prim parametru catre `cursor_preturi` /
-`cursor_articole_k` / `cursor_gestiune` / `cursor_lucrare` (`ofacturare.prg:272-303`), inclusiv pe
-tip 1. Ascunderea campului nu inseamna golirea valorii — valoarea implicita (data documentului)
-trebuie sa ramana. Iar pe avizul de lucrare, ascunderea fara repararea validarii de la `:8076` ar
-bloca finalizarea antetului cerand un camp care nu mai e pe ecran.
-
-### N. Returul din facturi anterioare (decizia 17)
-
-Rapoarte: `docs\cercetare\factura_retur_document.md` (mecanismul principal) si
-`retur_si_lista_preturi.md`, A (al doilea mecanism).
-
-**Sunt doua fluxuri de cod independente**, care ating aceeasi clasa de formular prin metode si
-proceduri Oracle diferite. Nu au niciun punct comun in afara conventiei de semn a cantitatii.
-
-#### N.1 Factura de retur ca document (tipurile 8, 9 — si avizul de retur, 24)
-
-**Asta e mecanismul pe care il descrie Marius, si functioneaza deja cap-coada.**
-
-- **Intrare:** tile-ul de pe ecranul de facturare (`ofundal_facturare.vc2:882-884`) -> `politica.mpr`
-  -> `factureaza(8)` / `factureaza(9)` (`Meniuri\politica.mn2:14-15, 45-46`).
-- **Alegerea facturilor, la nivel de document:** `frm_date_factura.do_cauta_facturi`
-  (`ofacturare.vc2:9173-9212`) cheama `caut_facturi_multiple_client`
-  (`oproceduri_facturare.prg:2091-2121`) — browse cu **selectie multipla**, titlu „Alegeti facturile
-  (mouse-click pe numar sau apasati SPACE)”. Filtrare pe **client** (obligatoriu ales inainte) si
-  **valuta**; sursele exclud tipurile de retur, deci nu se face retur dintr-un retur. Id-urile alese
-  se aduna intr-un CSV in `poDate.listaid`, numerele in `poDate.descriere`, iar antetul primeste
-  automat textul „RETUR FACTURA …”. Fara alegere nu se poate continua (`:9523-9526`).
-- **Popularea liniilor:** `pack_facturare.cursor_retur` -> `cursor_retur_document`
-  (`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:3943-3956`, `:3958-4071`) selecteaza direct din
-  `VANZARI_DETALII` liniile facturilor alese si le pune in acelasi `crsarticole` pe care celelalte
-  tipuri il umplu cu lista de preturi (`ofacturare.prg:306-311`). **Confirmat exact ce spunea Marius:**
-  `ID_GESTIUNE` vine din linia originala (`:4034`, `:4055`), `PRET_ACHIZITIE` la fel, **neschimbat**
-  (`:4035`, `:4056`), iar pretul de vanzare se recalculeaza pe curs doar daca moneda nu e nationala
-  (`:4016-4030`). `GESTIONABIL` e `NVL2(A1.ID_GESTIUNE,1,0)` — gestionabil doar daca originalul avea
-  gestiune.
-- **Ce se poate face manual:** **stergerea liniilor aduse merge** si cantitatea redevine disponibila
-  in cursorul sursa (`do_sterge`, `ofacturare.vc2:14608-14693`, ramura de retur la `:14658-14659`);
-  **returul partial merge** (`do_verifica_articol`, `:14743-14754`, fata de maximul calculat pe
-  server).
-- **Avizul de retur (24)** foloseste acelasi `cursor_retur` si aceleasi ramuri; difera doar antetul —
-  `nIdTipDoc = 6` si `frm_date_aviz` in loc de `frm_date_factura` (`ofacturare.prg:194-195`, `:225`).
-
-**Singurul gol real, si e acelasi ca la comanda:** pe un document de retur **nu se poate adauga o
-linie din afara facturilor sursa**, pentru ca `crsarticole` **este** rezultatul lui `cursor_retur`
-(`do_adauga_articol` ia articolul mereu din el, `ofacturare.vc2:12843-12851`). Nu e o interdictie
-explicita, e continutul cursorului — exact cauza de la comanda (J). Se rezolva la fel, prin
-`APPEND FROM`, si abia asta face reala decizia 16 pe documentele de retur.
-
-#### N.2 Retur de articole intr-o factura de vanzare normala (`But_retur`)
-
-Butonul (`cmd_butoane.vc2:324-338`, `caction = do_retur`) e vizibil **doar** pe tipurile 1, 5, 7, 10
-(`ofacturare.vc2:15122-15127`) — pe un document de retur nu exista deloc. Aici factura sursa se alege
-**per articol**, la fiecare linie: `caut_facturi_multiple_client_articol`
-(`oproceduri_facturare.prg:2124-2159`), filtrat suplimentar pe articolul curent. Perechile
-`ID_ARTICOL:ID_VANZARE` se acumuleaza in `thisform.cListaIdArticoleRetur` (`:12888`) si pleaca ca
-`poDate.listaid` (`:13977-13979`). Gestiunea se alege prin
-`pack_facturare.cursor_gestiuni_articol_retur`, nu vine din factura sursa — **diferenta de fond fata
-de N.1**.
-
-**Legatura linie-de-retur -> linie originala: neverificat** pe schema. In VFP nu exista coloana de
-linie sursa; la nivel de antet exista `poDate.nid_vanzare_retur` (`ofacturare.vc2:14448`, `:14509`).
-Conteaza doar pentru **afisare** — daca formularul poate arata din ce factura vine fiecare linie.
-
-#### N.3 Ce se schimba in formularul unificat
-
-- **N.1 se muta ca atare.** Alegerea facturilor devine o optiune in meniul butonului de adaugare
-  („Alege facturile de returnat…”), cu acelasi dialog, aceleasi filtre si aceeasi populare din
-  `cursor_retur`. **Nu se reproiecteaza nimic din ce merge**, si in special nu se atinge preluarea
-  gestiunii si a pretului de achizitie din facturile originale.
-- **N.2 capata si alegerea la nivel de document**, dupa modelul lui N.1, pastrand calea per-articol
-  pentru cazul cu un singur articol.
-- **Lista de preturi devine disponibila si pe documentele de retur** (decizia 16), prin acelasi
-  `APPEND FROM` ca la comanda. Consecinta de proiectat: pe acelasi document vor coexista linii
-  aduse din facturi sursa (cu gestiune si pret de achizitie mostenite) si linii libere, care nu au
-  factura sursa.
-  **Decizia 22 (Marius, 09.08.2026): linia de retur fara factura originala e permisa, ca pe orice alt
-  document.** Returul nu face exceptie de la regula deciziei 16 — sursa umple documentul, nu il
-  inchide, si nici nu apare doar „pentru corectii”. Consecintele de proiectat, acum ferme:
-  - **gestiunea si pretul de achizitie nu se pot mosteni** pe o linie libera, pentru ca nu exista linie
-    originala. Se aleg, ca la N.2 (`cursor_gestiuni_articol_retur`), nu se preiau ca la N.1;
-  - **maximul returnabil calculat pe server nu se aplica** unei linii fara factura sursa — nu exista
-    cantitate originala fata de care sa se limiteze;
-  - afisarea „din ce factura vine linia” trebuie sa suporte si valoarea goala (vezi mai sus, legatura
-    linie-de-retur -> linie originala, inca neverificata pe schema).
-
-*De pastrat cum e:* excluderea returului dintr-un retur, filtrarea pe client si valuta, maximul
-returnabil calculat pe server, si mostenirea gestiunii si a pretului de achizitie. Nu se ating.
-
-### O. Facturile din ROAAUTO (decizia 18)
-
-Raport: `docs\cercetare\roaauto_facturi.md`.
-
-> **Precizare la descrierea liniilor de mai jos.** „Liniile unei facturi ROAAUTO nu sunt articole” e
-> adevarat doar pentru liniile **generate din deviz**. Langa ele pot sta articole reale, adaugate
-> prin mecanismul **„Alte servicii”** — vezi O-bis, verificat pe cod
-> (`docs\cercetare\roaauto_articole_lista_preturi.md`). Restul sectiunii ramane valabil: tipul `-12`,
-> drumul comun prin `PACK_FACTURARE`, faptul ca editorul lui #6 le vede, si blocarea modificarii
-> dupa facturare — ultima **reconfirmata**.
-
-**Ce se confirma.** ROAAUTO nu are cale proprie spre baza: `factureaza_deviz`
-(`ROAAUTO\Programe\oproceduri_devize.prg:846`) cheama acelasi `PACK_FACTURARE` partajat —
-`initializeaza_date_factura` (`:1211`), `adauga_articol_factura_deviz` (`:1240`), `oscrie_in_fisiere`
-(`:1269`), `scrie_in_vanzari` (`:1302`) — deci liniile trec prin acelasi `VANZARI_DETALII_TEMP` si
-ajung in acelasi `VANZARI_DETALII` ca orice factura ROA. Tipul documentului e **`-12`**
-(`:922`). Editorul lui #6 le vede deja, fara cod de recunoastere a sursei, verificat pe date reale
-(`id_vanzare = 1047`). **Deci partea de „le vede” e gratuita.**
-
-**Ce nu se confirma — si asta schimba dimensiunea deciziei.** „Se pot modifica ulterior” **nu e
-adevarat azi, in niciun produs**:
-
-- in ROAAUTO, formularul de devize isi dezactiveaza butonul de modificare de indata ce comanda are
-  numar de factura (`oviz_devize.vc2:4536`); singura actiune post-facturare gasita e re-listarea
-  (`oproceduri_devize.prg:1516`), care nu scrie nimic. Niciun apel din ROAAUTO catre
-  `modifica_date_factura`;
-- in ROAFACTURARE, gridul de articole din editorul nou (`frm_modific2024`, `COMUN\clase\omodificari.vc2`)
-  e **read-only prin design**, la nivel de grid si pe fiecare `Text1`.
-
-Deci decizia 18 nu extinde o cale existenta, **creeaza o capacitate care nu exista nicaieri**.
-
-**Cum arata liniile.** `factureaza_deviz` agrega sumele devizului si insereaza cate o linie sintetica
-per categorie, cu `id_articol` **negativ**: `-100000` MANOPERA (`:965-967`), `-100003` MATERIALE
-(`:947-949`), `-100001` discount manopera, `-100005` / `-100006` avans si stornare avans,
-`-100007` / `-100008` inspectie tehnica si spalare (`:936-1027`). Optional, cu
-`gnAUTOIdArticolReparatii` setat, toate se cumuleaza intr-o singura linie cu un articol real
-(`:989-1004`). Langa ele pot sta **articole reale**, prin „Alte servicii” — vezi O-bis.
-
-### O-bis. „Alte servicii” — cum se adauga azi articole reale in ROAAUTO
-
-Raport: `docs\cercetare\roaauto_articole_lista_preturi.md`. **Asta e mecanismul de refolosit.**
-
-- **Unde:** formularul `frm_incasare_finala` (`ROAAUTO\Clase\oviz_devize.vc2:5435-7143`), aratat **la
-  emiterea facturii finale** (`do_factureaza_final`, `:2569`) — nu pe devizul propriu-zis.
-- **Sursa articolelor:** `cauta_nom_articole` pe `vnom_articole_toate`
-  (`COMUN\programe\ocautare.prg:1781-1823`), filtrat `in_stoc = 0 and in_crm = 1` si cu id-urile
-  sintetice excluse (`oviz_devize.vc2:6539-6580`). **Nomenclatorul brut, si numai articole fara
-  stoc** — nu lista de preturi, nu politici.
-- **Pretul se tasteaza manual.** `do_adauga` nu completeaza pretul si cantitatea; operatorul le pune
-  in grid, iar `do_modifica_alteserv` recalculeaza valoarea (`:6692-6698`, `:7064-7070`). Nu exista
-  preluare automata de pret pe calea asta.
-- **Liniile raman separate.** Cumularea in „REPARATII AUTO” include doar id-urile sintetice
-  (`oproceduri_devize.prg:999-1012`); randurile din `crsalteserv` se insereaza dupa, cu `id_articol`
-  real, si ajung ca atare in `VANZARI_DETALII_TEMP` (`:1036-1041`, `:1240-1257`).
-- **Gestiune: tot zero.** `id_gestiune` nu e completat de niciun `INSERT` si pleaca `0` spre Oracle
-  (`:1201-1206`, `:1255`) — consistent cu filtrul `in_stoc = 0`. Deci **nici articolele reale din
-  ROAAUTO nu descarca gestiune**. Diferenta fata de liniile sintetice e doar `id_articol`.
-- **Stergere si modificare:** exista, dar **doar cat timp formularul e deschis, inainte de emitere**
-  (`do_sterge`, `:6730-6741`).
-- **Contul pleaca gol.** `crsvanztemp` are coloana `Cont c(4)`, dar `INSERT`-ul care il umple nu o
-  include (`oproceduri_devize.prg:1190-1206`); apelul trimite literal `''` (`:1256`), care ajunge
-  `NULL` in `VANZARI_DETALII_TEMP.CONT`, fara `NVL` si fara fallback. Deci **liniile de articole reale
-  din ROAAUTO se scriu azi fara cont** de gestiune, tacut. Vezi J-bis.
-- **Si fara politica de pret — dar pe alta cale decat credeam.** `id_pol` lipseste peste tot pe firul
-  asta (nu e nici in `crsalteserv`, nici in `crsvanztemp`, nici in semnatura lui
-  `adauga_articol_factura_deviz`). **Motivul pentru care asta nu produce `FACT-024`** e ca fluxul
-  ROAAUTO **nu trece prin `contabilizeaza_articol`**: merge pe `scrie_in_vanzari`, care nu genereaza
-  nicio nota de venit. Vezi **J-ter**.
-
-> **Corectie importanta la temeiul deciziei 18.** Ideea ca „«Alte servicii» face deja jumatate din ce
-> cerem, deci se generalizeaza” **nu se sustine**. Mecanismul acela functioneaza tocmai pentru ca
-> ocoleste contabilizarea de venit; generalizat pe fluxul ROAFACTURARE, unde `contabilizeaza_articol`
-> **este** apelata (`scrie_factura2`, `ff_...:6150`), s-ar lovi de `FACT-024`. Ce ramane valabil din
-> O-bis e descrierea UI (articole reale langa linii sintetice, pret tastat, fara gestiune) — nu si
-> concluzia ca partea grea e deja rezolvata.
-
-**Ce inseamna asta pentru decizia 18.** Doua lucruri, in directii opuse:
-
-- **usureaza** partea de model: un articol real langa linii sintetice **nu e o noutate**, e deja
-  cazul normal al facturilor auto. Intrebarea „cum coexista” are deja un raspuns in produs;
-- **nu rezolva** cerinta: mecanismul traieste in formularul de emitere al ROAAUTO si moare odata cu
-  el. Ce cere Marius e aceeasi capacitate **la modificare**, care nu exista nici acolo, nici aici.
-
-**Intrebarile ramase, in ordinea in care blocheaza:**
-
-1. ~~**Ce se intampla cu totalul devizului**~~ — **RASPUNS (runda 7)**, raport
-   `docs\cercetare\pack_auto_actualizeaza_deviz.md`. Premisa intrebarii era gresita: **nu exista niciun
-   `SUM` peste `VANZARI_DETALII`, pentru ca `PACK_AUTO` nu citeste deloc `VANZARI` /
-   `VANZARI_DETALII`** — zero potriviri pe `VANZARI` in tot pachetul (1804 linii).
-   `actualizeaza_deviz` (`ff_2026_03_31_02_AUTO_PACK_AUTO.sql:692-733`) face trei lucruri, toate pe
-   structura proprie ROAAUTO: scrie cota TVA pe `DEV_ORDL`, stampileaza `ID_FACT` pe `RUL`, si — doar
-   pe anumite `id_set` — pe `NOM_LUCRARI`. E o legatura **deviz -> document**, nu un recalcul
-   **document -> total deviz**. Nu e nici macar specifica facturarii: aceleasi trei apeluri o
-   folosesc si la inchiderea de productie si de regie, care scriu note contabile, nu facturi.
-   **Deci o linie noua pe `tip = -12` nu poate dezechilibra nimic pe partea Oracle**, si nu e nevoie
-   de niciun apel suplimentar catre ROAAUTO. Precedentul „Alte servicii” confirma pe date live:
-   liniile reale coexista de mult cu cele sintetice, fara ca `actualizeaza_deviz` sa faca distinctie.
-   **Ce ramane, si e de alt fel:** o **desincronizare de afisare**. Totalul devizului aratat in
-   ROAAUTO se calculeaza din `RUL` si din cursoarele de facturare (`oviz_devize.vc2:7816-7823`),
-   **niciodata** din `VANZARI_DETALII` — deci nu va arata linia adaugata, nici azi, nici dupa #13.
-   In schimb **relistarea o va arata**: `relisteaza_factura_deviz` citeste `fact_vfacturi_detalii`
-   (`oproceduri_devize.prg:1564`), un view neconditionat peste `VANZARI_DETALII`
-   (`ff_2024_06_04_01_COMUN_FACTURARE.sql:8-94`). Factura retiparita si ecranul de deviz vor spune
-   lucruri diferite — **DECIS (decizia 28): e acceptabil.** Cerinta lui Marius e ca **MANOPERA si
-   MATERIALE sa fie conform devizului**; restul articolelor pot exista pe factura fara sa apara in
-   ecranul de deviz. Nu se cere cod nou in ROAAUTO si nu se mai pune intrebarea.
-2. **Gestiunea, pentru articole cu stoc. DECIS (decizia 20):** se admit si articolele gestionabile.
-   ROAAUTO ocoleste subiectul filtrand `in_stoc = 0`; filtrul acela **nu se preia**. Deci pe
-   documentele auto vor coexista linii care descarca stoc cu linii care nu descarca — caz nou, de
-   proiectat, nu de evitat.
-3. **Cine ramane proprietarul documentului** dupa ce ROAFACTURARE ii adauga o linie — mai poate
-   ROAAUTO sa-l relisteze corect (`relisteaza_factura_deviz` citeste din `fact_vfacturi`)?
-
-**Reconfirmat:** dupa emitere nu exista cale de intoarcere in ROAAUTO. `verifica_stornare`
-(`oviz_devize.vc2:4513-4514`) e o metoda **goala**; `do_storneaza_avans` priveste doar avansul.
-Singurul instrument gasit asupra unei facturi emise e stergerea totala (soft-delete) prin ecranul
-generic din COMUN — nu o editare.
-
-**Secventierea — reevaluata dupa raport (runda 7).** Marius a cerut ca `pack_auto` sa fie cercetat
-inainte de orice estimare (decizia 23), si a avut dreptate: raspunsul **rastoarna recomandarea
-initiala**. Motivul pentru care decizia 18 urma sa se livreze ultima era riscul tehnic de a scrie pe
-un produs pe care #13 nu-l controleaza. **Acel risc nu exista** — `PACK_AUTO` nu citeste `VANZARI` /
-`VANZARI_DETALII` deloc, deci nu are ce sa se dezechilibreze (vezi intrebarea 1 de mai sus).
-
-Ce ramane nu mai e risc tehnic, ci **o singura intrebare de produs**:
-1. ~~e acceptabil ca ecranul de deviz sa nu arate linia adaugata din #13~~ — **RASPUNS, decizia 28:
-   da, e acceptabil.** Conditia e alta: MANOPERA si MATERIALE conform devizului.
-2. cine ramane proprietarul documentului (intrebarea 3 de mai jos) — nu s-a schimbat.
-
-**Decizia 18 nu mai trebuie sa fie ultima din motive tehnice.** Ordinea de lucru din S4g ramane insa
-valabila din alt motiv, mai bun: se face intai pe documentele ROAFACTURARE, unde scrierea e a
-noastra, pentru ca acolo se aseaza mecanismul; `tip = -12` vine dupa, ca **aplicare**, nu ca risc.
-
-**Perimetru:** gridul read-only din `frm_modific2024` si `ofacturare_editare.prg` sunt ale lui **#6**.
-Deschiderea lui la scriere nu se face din #13 fara intelegere explicita — un singur scriitor pe fisier.
-
-### L. Observatii colaterale, gasite in timpul verificarii
-
-Nu fac parte din #13 si nu se repara aici — se semnaleaza ca sa nu se piarda.
-
-0-ter. **(runda 9) O nota de vanzari cu set multi-rand inregistreaza venitul si descarca gestiunea de N
-   ori.** In `pack_facturare.contabilizeaza_articol`, `cursor_articol` face `LEFT JOIN NOTE_CONTABILE D ON
-   C.ID_SET = D.ID_SET` **fara `ROWNUM`, fara agregare, fara filtru**
-   (`ff_2026_08_09_01_...:7218-7271`), iar bucla care il consuma (`:7393-7542`) executa `scrie_nota`
-   **si** `descarca_gestiune` **o data pentru fiecare rand al setului, cu aceeasi cantitate si acelasi
-   pret intreg** — nu impartite. Nu exista nicio logica de distributie: `ORDINE` nu apare in tot pachetul.
-   Azi nu se manifesta pentru ca toate cele 7 note de vanzari active au exact un rand pe set — dar **30
-   din cele 40 de seturi din baza au mai multe, cu maxim 30 de randuri**. Deci e o bomba armata de
-   configurare: cine ataseaza unei politici de pret o nota cu set multi-rand obtine **dublare de venit si
-   dublare de descarcare de gestiune**, silentios. **E in `PACK_FACTURARE`, adica in COMUN** — se
-   semnaleaza, nu se repara din #13. Conteaza direct pentru reteta din J-quater: vezi acolo.
-   Sursa: `docs\cercetare\s10_pret_rederivat.md`, „Completare", p. 1 + `verif_baza_vie_cont_venit.md` p. 6.
-0-quater. **(runda 9) Politica de pret fara `ID_NOTA` nu are nicio plasa de siguranta.** Spre deosebire de
-   articolul lipsa din politica (`FACT-024`), aici nu exista cod de eroare: lantul de `LEFT JOIN` din
-   `cursor_articol` supravietuieste inelului lipsa, cursorul intoarce **un rand cu totul `NULL`**, iar
-   `scrie_nota` insereaza in `ACT_TEMP` un rand cu conturile de debit si credit **nule**. Daca `ACT_TEMP`
-   are `NOT NULL` pe ele, iese un `ORA-01400` generic in loc de un mesaj `FACT-0xx` — **neverificat**,
-   DDL-ul lui `ACT_TEMP` nu e in export. Starea exista in baza vie **azi**: politicile active `32 HOTEL
-   TAXE` si `33 HOTEL CAZARE` n-au `ID_NOTA`. Independent de #13.
-0-bis. **(runda 7) `do_modifica` pare sa scrie `id_valuta` in loc de `id_sectie`.** In
-   `frm_modific2024.do_modifica` (`COMUN\clase\omodificari.vc2:13941`), ramura
-   `CASE m.lcControl = 'sectie'` face `replace sectie with loCauta.sectie, id_valuta with
-   loCauta.id_sectie`. Daca e ce pare, textul afisat al sectiei se schimba dar coloana `id_sectie`
-   nu — si, in plus, se strica `id_valuta`. **Necitit pe date, doar pe cod.** Fisierul e in
-   **perimetrul lui #6** (`omodificari.vcx` a intrat in proiect prin `97d1613`) — se semnaleaza acolo,
-   nu se repara de aici. Conteaza pentru #13 pentru ca sustine partial verdictul „`ID_SECTIE` e
-   editabil": teoretic da, practic poate nu.
-0. **(runda 7) Handler-ul lui `FACT-024` se auto-saboteaza cand `id_pol` e `NULL`.** In
-   `pack_facturare.contabilizeaza_articol` (`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:7286-7311`),
-   ramura `WHEN NO_DATA_FOUND` construieste mesajul cu inca doua `SELECT ... INTO`, dintre care al
-   doilea e `FROM CRM_POLITICI_PRETURI WHERE id_pol = detalii_articol.id_pol`. Cu `id_pol` `NULL`,
-   **si acel `SELECT` da `NO_DATA_FOUND`**, iar in handler nu exista al doilea nivel de tratare — deci
-   utilizatorul primeste un `ORA-01403` generic in loc de mesajul `FACT-024` formatat. Articolul
-   apucase sa fie rezolvat, deci informatia nu se pierde de tot, dar diagnosticul e mult mai prost.
-   **E in `PACK_FACTURARE`, adica in COMUN** — se semnaleaza, nu se repara din #13. Devine relevant
-   direct daca se alege varianta 3 din J-bis.
-1. **`do_copiaza`, ramura de avize: variabila gresita.** La `ofacturare_comun.vc2:3702-3703`, ramura
-   `CASE INLIST(loFactura.tip, T21, T24, T26, T30, ...)` scrie `lnTip = T22` in loc de
-   `loFactura.tip = T22`, deci degradarea de tip **nu se aplica** pe acea ramura. **Fisierul e in
-   perimetrul lui #6** — nu se atinge de aici; efectul nu a fost verificat pe date.
-2. **„Proforma -> factura” merge prin omisiune.** Copierea nu propaga `nIdTipDoc` pentru ca linia e
-   comentata (`ofacturare_comun.prg:370`), deci copia unei proforme porneste implicit pe FACTURA.
-   Functioneaza, dar ca efect secundar, nu ca ramura dedicata. Daca #13 atinge copierea, merita
-   transformat in intentie explicita.
-3. **Asimetria de resetare a globalelor** — vezi „Canalul de precompletare”, mai sus.
-4. **Modificarea in bloc pare sa goleasca campuri pe care nu le-ai atins.** Pe selectie multipla
-   (`lnNrInreg > 1`), `do_modifica` face `Scatter Name poRec Memo Blank` si reseteaza explicit ruta,
-   delegatul, agentul, masina, `dataora_exp`, `id_facturare`, `listare_detaliata`, `tip_saft`,
-   `text_aditional` si `efactura` (`ofacturare_comun.vc2:4565-4580`). Cum acesti zece parametri se
-   scriu **neconditionat** in `VANZARI` (I-bis), un `SCAN` peste facturile alese pare sa scrie valorile
-   goale pe **fiecare** dintre ele — deci schimbarea rutei pe trei facturi ar sterge delegatul si
-   textul aditional de pe toate trei. **De confirmat pe date inainte de a fi numit bug**: e posibil ca
-   fluxul sa presupuna ca operatorul completeaza tot ce vrea propagat. **Fisierul e in perimetrul lui
-   #6** — se semnaleaza, nu se repara de aici. Conteaza si pentru #13: formularul unificat lucreaza
-   pe un singur document si trebuie sa trimita antetul intreg (I-bis, consecinta 1), deci nu
-   mosteneste problema.
-
-**L.4 (runda 11). Numarul de POS nu se dezaloca la Renunt.** In `frm_alte_date`, la anulare se
-dezaloca numarul de chitanta (16) si cel de bon fiscal (3), dar **nu si cel de POS (26)** —
-`docs\cercetare\s3b_alte_date_analitice.md`, sectiunea 9. Bug preexistent, in productie, **nu introdus
-de #13**. Conteaza pentru S3b pentru ca „`actualizeaza_tipincasare` se muta ca atare" **l-ar propaga
-in formularul unificat**. Se repara in trecere sau se lasa ca azi si se preia separat — punct de decis,
-vezi lista de la finalul rundei 11.
-
----
-
-## Stories
-
-Ordinea e strict pe risc: unificarea intai (livrabil de sine statator, util si fara regenerare),
-regenerarea peste ea.
-
-## Metoda de executie (Marius, runda 14) — obligatorie, nu recomandare
-
-**Planul asta e un document de proiectare, nu un plan de executie. La implementare se SPARGE PE
-STORIES, si fiecare story se executa ca livrare de sine statatoare.** Nu se porneste implementarea pe
-tot #13 deodata, nu se acumuleaza modificari nelivrate peste mai multe povesti, si nu se trece la
-povestea urmatoare cu cea precedenta netestata si nerevizuita.
-
-### Ce inseamna „spart pe stories"
-
-- **O story = o unitate de livrare.** Are perimetru propriu de fisiere, criteriu „gata cand" propriu
-  (fiecare story de mai jos il are deja scris) si se incheie cu diff + review + commit propriu.
-- **Inainte de prima linie de cod dintr-o story**, se scrie o **nota de executie** in `docs\` care
-  transpune proiectarea in pasi concreti: fisierele atinse, metodele atinse, ordinea editarilor, si ce
-  se testeaza dupa fiecare. Proiectarea spune *ce* si *de ce*; nota de executie spune *unde* si *in ce
-  ordine*. Rapoartele din `docs\cercetare\` sunt materia prima — nu se reface cercetarea.
-- **Povestile cu dependente declarate** (`*Depinde de:*`, la fiecare story) **nu se pornesc in paralel
-  cu cele de care depind.** Unde nu e dependenta, se pot rula in paralel de agenti diferiti — dar
-  **un singur scriitor pe fisier**, niciodata doi agenti pe aceeasi metoda.
-- **O story care se dovedeste prea mare la executie se sparge mai departe**, cu acordul lui Marius, si
-  se noteaza in plan. Mai bine cinci livrari mici decat una care nu se poate revizui.
-
-### Teste la fiecare pas — nu doar la S6 si S12
-
-`S6` si `S12` raman testele **pe flux real**, la capatul fiecarei etape. **Ele nu inlocuiesc testarea
-per story.** Fiecare story se incheie cu teste proprii, rulate si trecute, **inainte** de review:
-
-- **Harness headless** (`COMUN\docs\depanare_testare_vfp.md`) pentru logica — cazurile minime ale
-  povestii, plus **cel putin o proba de neregresie** pe calea veche, care trebuie sa ramana neatinsa.
-- **Harness UI vizibil** (`COMUN\docs\testare-ui-vfp.md`) unde povestea atinge formulare sau griduri —
-  coloanele de grid **nu se materializeaza headless**, deci acolo verificarea headless nu e concludenta.
-- **Rezultatul asteptat se declara INAINTE de rulare**, inclusiv pentru cazurile care trebuie sa dea
-  eroare. Un test scris dupa ce s-a vazut rezultatul nu dovedeste nimic.
-- **Un esec documentat e livrabil valid** — se raporteaza, nu se ascunde si nu se reia la nesfarsit.
-- Testele fiecarei povesti **se pastreaza**, si intra in suita rulata de S6 / S12. Nu se scriu de
-  unica folosinta.
-
-### Code review dupa implementare, inainte de commit — pentru fiecare story
-
-**Nicio story nu se comite fara review, si review-ul vine dupa implementare si dupa teste, nu in loc
-de ele.** Ordinea, fixa:
-
-1. **Implementare** (delegata unui subagent, conform modului de lucru din `CLAUDE.md`).
-2. **Teste** — rulate, trecute, cu rezultatele raportate.
-3. **Diff ca fisier in `docs\`** (`diff_s<N>_<subiect>.patch`), inclusiv partea din `COMUN`.
-4. **Code review pe diff**, de catre **un agent care nu a scris codul** — altfel isi revizuieste
-   propriile presupuneri. Review-ul verifica cel putin: regresia pe calea veche, conventiile per zona
-   atinsa (`COMUN\docs\reguli_lucru.md`, punctul 7 — encoding `cp1250` la `.vc2`/`.sc2`, `GO` pe
-   `Recno()`, `goExecutor` + `ALTER TABLE`, UX formulare/griduri), comentariile (istoric **numai** in
-   antetul fisierului, max o linie in cod), si ca write-back-ul text→binar e facut pentru fiecare
-   fisier atins.
-5. **Aprobarea lui Marius.**
-6. **Commit** — in **ambele** repo-uri unde e cazul (ROAFACTURARE si COMUN), cu changelog.
-
-**Afirmatiile review-ului se verifica, nu se cred.** Un review poate citi structura corect si presupune
-semantica gresit; cand semnaleaza un defect, se deschide codul citat inainte sa fie acceptat — la fel
-cum se procedeaza cu rapoartele de cercetare.
-
-**Ce NU face review-ul:** nu reargumenteaza deciziile luate (lista lor e in acest plan), nu extinde
-perimetrul povestii, si nu propune refactorizari colaterale. Ce gaseste in afara perimetrului se
-**raporteaza separat**, nu se repara in trecere — exact cum s-a procedat cu defectul `lnTip` din
-`do_copiaza`.
-
-### Etapa I — formularul unificat
-
-#### S1 — Inventarul de campuri si alegerea bazei
-Deciziile de perimetru sunt luate (vezi listele de la inceput). Ramane: **se porneste de la prototipul
-`frm_facturare_articole2` sau de la `frm_facturare_articole` extins?**
-Recomandare: **de la prototip**, si acum cu trei argumente in plus fata de runda 2 — are deja
-controalele de antet, are butoanele **deasupra** gridului (decizia 13), si are coloanele de discount
-editabile plus procentul pe linie (decizia 14). Partea grea de layout e deja acolo; logica lipsa se
-porteaza in el.
-Livrabil: tabel camp-cu-camp `frm_date_factura` / `frm_date_aviz` / `frm_modifica_factura` /
-`frm_alte_date` -> formular unificat, cu ce se pastreaza, **in ce grup din cele patru intra** (I),
-ce se pliaza, ce dispare, si **cu ruta de scriere a fiecarui camp** (pe loc sau prin regenerare —
-vezi G-bis). Baza de pornire: `docs\cercetare\inventar_controale_formulare.md`, care are deja
-etichetele reale si conditiile de vizibilitate.
-**Livrat (runda 7): `docs\S1_inventar_campuri_formular_unificat.md`** — 30 de campuri de antet, cu
-grupul din I, conditiile de vizibilitate si ruta de scriere pentru fiecare, plus randul dedicat lui
-`V_EFACTURA` (singurul camp fara control azi, nicaieri) si cele patru bife marcate ca disparute.
-Tabelul a scos la iveala **golul de rute de scriere** din G-bis — vezi acolo. Are si o sectiune
-„Neclarificate" cu opt puncte, dintre care doua ambiguitati de nume (`chkDetaliat`, `cboTipFactura`
-apar in doua formulare si nu s-a confirmat pe cod ca scriu acelasi camp).
-**Coloana „ruta de scriere" e completa acum** — `rute_scriere_antet.md` a inchis cele trei grupuri
-lasate neclarificate, iar deciziile 25 si 26 le-au dat ruta. Tabelul se citeste **impreuna cu tabelul
-de rutare din G-bis**, care e sursa de adevar pentru ruta fiecarui camp; sectiunea „Neclarificate" din
-S1 ramane valabila doar pentru punctele **4, 5, 7 si 8** (ambiguitatile `chkDetaliat` / `cboTipFactura`,
-liniile exacte de definire a controalelor, si dependenta de drepturi).
-*Gata cand:* tabelul e aprobat. **APROBAT de Marius, 09.08.2026 — S1 e incheiata.** Tabelul devine
-referinta pentru S3 si S3b; modificarile ulterioare se fac in el, nu se rescrie de la zero.
-
-**ASEZAREA ZONEI DE JOS — INCHISA prin decizia 57 (Marius, runda 15): VARIANTA D.**
-Cerinta initiala (runda 14), formulata de el: *„totalurile de jos sa fie mai compacte, si sa includa
-si discount-ul; formularul trebuie sa fie compact si aerisit; incasarea si alte date jos de tot,
-eventual 2 butoane pe acelasi rand — vezi modelul Saga; in centrul atentiei sa fie datele facturii"*.
-Referinta vizuala: `{06D747B8-0824-488C-8832-DEB9AE661974}.png`.
-Rundele 14-15 au dat patru variante (A / B / C, apoi D). **Aleasa: D.** Vezi „Decizia 57" la
-deciziile rundei 15, care are enuntul complet, cele patru consecinte de implementare si punctul lasat
-deschis. Ce e de retinut aici, pentru executia lui S1:
-
-- **Antetul se strange la doua randuri**, fara titluri de grup — campurile se recunosc dupa eticheta.
-- **Panoul separat „Discount pe document" dispare**; discountul devine rand editabil in banda de
-  totaluri, cu procentul pe loc.
-- **Banda de totaluri** e pe toata latimea, lipita de grid: baza, discount articole, discount document
-  cu procentul, TVA — desfacute pe un rand — si totalul mare singur la dreapta.
-- **Incasare si Alte date NU sunt dialoguri** — sunt doua sectiuni colapsabile in formular, **una
-  langa alta pe acelasi rand**, sub totaluri, fiecare cu rezumatul continutului pe randul inchis.
-- **Bara de comenzi de jos nu exista**: `but_renunt` / `but_termin` raman in banda de titlu.
-
-**Cota de TVA a discountului de document s-a decis — decizia 59, runda 16** (vezi sectiunea K-bis):
-repartizare proportionala automata pe cote, discountul **NU cere cota de la utilizator**, deci **nu
-e nevoie de o a treia sectiune pentru cota**. Ce mai cere UI e **un camp text optional de motiv**
-(pentru `AllowanceChargeReason`), mult mai mic decat o sectiune. **Decizia 61 (runda 16) l-a
-materializat: Marius vrea campul. Asezarea lui s-a inchis definitiv abia in runda 17 — decizia 64
-(a treia sectiune jos) a fost **rasturnata de decizia 66: motivul sta in banda de totaluri, langa
-suma pe care o explica**, iar randul de jos ramane cu **doua** sectiuni, ca la decizia 57. Varianta
-grea (cota + explicatie proprii) ramane exclusa, ca mai sus.
-
-**Cele doua pagini online ale lui #13 — nu se confunda:**
-- **mockup-ul formularului** (fisier pe disc, `docs\mockup_13_formular_unificat.html`, **v9** din runda
-  17, cu asezarea D si motivul discountului in banda de totaluri):
-  **https://claude.ai/code/artifact/e9d73e86-7518-4f50-a998-43c49e083142**.
-  Are copie pe disc, si ea e sursa de adevar; artifactul se republica din ea (`WebFetch` pe URL intai,
-  apoi `Artifact` cu `url`). Decizia 33 e consumata — URL-ul e la zi.
-- **pagina cu variantele de asezare** (A/B/C/D), **fara copie pe disc**, deci artifactul **e** sursa de
-  adevar:
-
-Pagina cu variantele: **https://claude.ai/code/artifact/dfc70d38-856f-48fd-b6af-3da78e9da4f7**
-— **nu mai are copie pe disc** (cerinta lui Marius, runda 15: „doar online, ca sa nu mai intretii 2
-variante"). Procedura de modificare: `WebFetch` pe URL → fisier de lucru **in scratchpad, nu in
-`docs\`** → `Artifact` cu `url` = link-ul de mai sus.
-
-#### S2 — O singura procedura `factureaza`
-Se elimina `factureaza2` ca procedura paralela; `factureaza` primeste un mod. Se pastreaza
-integral ramurile care lipsesc azi din `factureaza2` (lista din A).
-
-**ACTUALIZAT dupa decizia 67 (Marius, 20.08.2026) — comutatorul `gnFacturareNou` cu dialog e
-INLOCUIT.** Proiectarea initiala (mai jos) alesese sa mute verificarea `gnFacturareNou` la punctul
-de alegere a lui `lcObject`, in interiorul lui `factureaza` — implementata asa intr-o prima trecere.
-Marius a respins comutatorul global cu dialog: vrea acces simultan la ambele fluxuri, nu un
-`AMESSAGEBOX` care alege intre ele. Mecanismul final: `plFacturareNoua`, variabila **Private**
-declarata de apelant (nu comutator persistent), plus o **intrare noua de meniu** ("Facturare (nou)",
-buton `Cw10` in `Clase\ofundal_facturare.vc2`) care o seteaza inainte de a apela `factureaza(N)`.
-Detalii complete la **Decizia 67**, mai jos in acest document (dupa Decizia 66).
-
-**PROIECTAT (runda 9) — `docs\cercetare\s2_factureaza_unificare.md`.**
-**S2 e mult mai ieftina decat arata planul.** `factureaza2` nu e a doua implementare functionala care
-cere fuziune atenta — e un fork din 08.06.2017 la care **executia interogarii de articole e dezactivata**
-(`lnSucces = 1` hardcodat, `goExecutor.oExecute` niciodata apelat) si mai multe blocuri intregi sunt
-inchise cu `If .F.`. Are **exact un apelant** in tot codul — `ofacturare.prg:90`, din interiorul lui
-`factureaza`, in spatele unui `AMESSAGEBOX` de confirmare — deci **zero utilizatori reali**. Ambele sunt
-proceduri globale in `COMUN\programe\ofacturare.prg` (`:81-577` si `:583-1081`, ~500 de linii fiecare),
-fara omonime. Singura diferenta functionala care justifica existenta lui `factureaza2` e formularul de
-articole (`frm_facturare_articole2` vs `frm_facturare_articole`).
-**Obstacolul nu e tehnic:** formularul spre care duce e tot un prototip neterminat, deci unificarea
-procedurilor **nu** face formularul nou utilizabil — doar elimina duplicarea. Aia rămâne treaba lui S3.
-**Trei corectii la lista din sectiunea A:** `verifica_numar(16, ...)` pentru chitanta **nu lipseste** din
-`factureaza2` (e identic, `:502-504` vs `:1018-1020`) — planul greseste; „`cursor_avize` cu tip 23" e
-imprecis — tipul 23 nu lipseste, e **rutat diferit** (`cursor_preturi` in `factureaza` vs
-`cursor_gestiune` in `factureaza2`), ceea ce e mai grav decat o omisiune; si lipsesc din plan **tipul 52**
-pe ramura de contract si **tipul 24** pe ramura de retur. Semnatura propusa, ramificarea interna, ordinea
-in care se face fara sa strice suita si criteriul de „gata" verificabil sunt in raport, sectiunile 5-7.
-**`ofacturare.prg` e cod comun al intregii suite** (copie in fiecare produs ROA, sincronizata manual) —
-la fel ca S3c, nu se face impreuna cu alta modificare. Butonul de meniu (`Clase\ofundal_facturare.vc2`)
-e specific ROAFACTURARE, nu e cod comun.
-*Gata cand (rescris dupa decizia 67 + completare + corectie review):* `factureaza2` nu mai exista;
-`ofacturare.prg` nu mai contine `gnFacturareNou`; are exact o aparitie a lui `plFacturareNoua`
-(variabila Private a apelantului), la punctul de alegere a lui `lcObject`; meniul „Facturare" (`Page2`)
-are o intrare noua „Facturare (nou)" (`Cw10`) cu **primele patru** optiuni ale paginii (`Cw1..Cw4` -
-lista de preturi, contract, comanda, aviz - singurele care trec prin `factureaza`; `Cw5..Cw9` ruteaza
-prin `initializeaza_vanzare_din_stoc()`, un flux separat, in afara perimetrului), meniul „Avize"
-(`Page3`) are o intrare noua „Avize (nou)" (`Cw5`) cu toate cele patru optiuni ale paginii (toate
-verificate ca trec prin `factureaza`) — ambele seteaza `plFacturareNoua` si deschid
-`frm_facturare_articole2` prin `Cw<N>.do_actiune()`, fara sa afecteze
-butoanele existente.
-*Depinde de:* S1.
-
-#### S3 — Portarea logicii de antet in formularul unificat
-Cele 17 + 13 metode `do_cauta_*`, `do_schimba_tipdoc`, validarile din `inainte_de_do_termin`
-(`ofacturare.vc2:9455-9561` si `:7277-7352`) si `Init`-urile. Se porteaza **o singura data**, cu
-ramificare pe factura / aviz in interior, nu doua copii.
-Punct de atentie cunoscut: **#16 din `todos.txt`** — la revenirea din formularul de curs valutar,
-focusul sare pe tip document si iesirea din serie regenereaza numarul actului.
-
-**PROIECTAT (runda 9) — `docs\cercetare\s3_portare_antet.md`.** Doua rezultate schimba povestea:
-
-- **Portarea „o singura data cu ramificare" nu e posibila ca atare.** `Init`, `inainte_de_do_termin` si
-  partial `do_cauta_fdoc` sunt **omonime cu semantica total diferita pe toate cele patru formulare-sursa**
-  (antet vs. articole vs. alte-date). Deci nu e o metoda cu ramificare interna, sunt **patru fuziuni de
-  metoda**. Obstacolul principal al lui S3 nu e codul de validare — majoritatea e `Do Case` / `amessagebox`
-  mecanic — ci **reconcilierea a patru cicluri de viata `Init` / `inainte_de_do_termin` independente
-  intr-unul singur**, cu ordinea de dependente din sectiunea 5 a raportului. Numarul real de `do_cauta_*`
-  e **29, nu 30**. Lista completa a omonimelor e la sectiunea 2 — **se citeste inainte de orice editare**,
-  altfel portarea le confunda (capcana deja platita o data cu `do_calculeaza_discount`).
-- **#16 nu e un bug de focus, si nu e in perimetrul in care il caută planul.** Reprodus pe cod pana la
-  linia exacta: bucla de reincercare din `factureaza` / `factureaza2` (`ofacturare.prg:174-571`) trateaza
-  **orice esec SQL** — nu doar cursul valutar lipsa — ca pe un „DA, continui cu alt document", si
-  redeschide formularul de antet de la zero. Deci **unificarea nu-l reproduce automat**; poate chiar sa-l
-  elimine ca efect secundar, daca antetul nu se mai reconstruieste din `Init` dupa un esec Oracle in pasul
-  urmator. **Cade premisa „ori se rezolva #16 aici, ori se reproduce bug-ul".** Si leaga #16 de **S2**, nu
-  de S3 — bucla e in procedura, nu in formular.
-
-*Gata cand:* un document se emite integral din formularul unificat, pe tip 1 (lista de preturi), cu
-acelasi rezultat in `vanzari` / `act` / `rul` ca pe calea veche — criteriul rescris verificabil e la
-sectiunea 7 a raportului, iar ce **nu** se poate testa headless la sectiunea 8.
-*Depinde de:* S2.
-
-#### S3b — Sectiunea pliata: alte date + analitice
-Deciziile 7 si 8. Se muta in formular cele patru grupuri din `frm_alte_date` (B) si coboara acolo
-analiticele din antet. `actualizeaza_tipincasare` se muta ca atare; **alocarea si dezalocarea
-numerelor** de chitanta / bon fiscal / POS raman legate de aceleasi evenimente ca azi, nu de
-deschiderea formularului. `frm_alte_date` nu se sterge cat timp calea veche mai e in uz.
-**Doua precizari din runda 7, amandoua restrang povestea:**
-- **analiticele coborau ca AFISARE, nu ca editare** (decizia 26) — **CADUC: decizia 72 le face
-  editabile**, si la introducere, si la reemitere. Nu se scrie `ReadOnly` pe ele si nu mai e nevoie de
-  tooltipul explicativ; editorul de nota al lui **#6** ramane singurul loc care le trateaza pe linie;
-- **pe un document deja emis, grupul de incasare e blocat in etapa I** (decizia 25) — nu are ruta de
-  scriere pe loc, iar regenerarea nu exista inca. La emitere se comporta ca azi.
-
-  **AMANAT LA S8c (23.08.2026), decis de Marius.** Blocarea nu are azi nicio stare pe care sa se
-  declanseze: pe `frm_facturare_articole2` nu exista notiunea de „document deja emis" — zero
-  `numar_act`, `Init` are un singur parametru (`toFactura`, doar pentru copiere), `oDateFactura`
-  n-are `numar_act`, iar `lcopiere` / `lArticoleIncarcate` inseamna altceva. Singura blocare
-  conditionata din toata clasa e pe **tipul** documentului (aviz), nu pe stare. In plus,
-  `but_modifica` — de care depinde criteriul „ambele stari ale antetului" — **e S8c**, nu exista
-  inca. O garda scrisa impotriva unei stari care nu poate aparea nu se poate testa, deci **decizia
-  25 iese din criteriul de „gata" al S3b si trece in S8c**, impreuna cu notiunea de document emis.
-  Cercetarea completa, inclusiv ce inseamna „blocat" pe fiecare tip de control din grup:
-  `docs\cercetare\s3b_decizia25_document_emis.md`. Confirmat acolo si ca **nu exista ruta de
-  reemitere**, nici in VFP, nici in Oracle (`PACK_FACTURARE.scrie_incasari` are doi apelanti, ambii
-  interni fluxului de emitere; zero apeluri din VFP).
-**PROIECTAT (runda 11) — `docs\cercetare\s3b_alte_date_analitice.md`.** S3b nu e o mutare de controale.
-Trei rezultate schimba povestea:
-
-- **Riscul din criteriul de „gata" e real, si are mecanism.** Alocarea numarului de chitanta nu porneste
-  din clicul utilizatorului, ci din **orice atribuire programatica** a lui `.Value`:
-  `opt_incasat.ProgrammaticChange` (`ferestre_cere_date.vc2:3351-3352`) cheama acelasi
-  `actualizeaza_tipincasare()` ca `.Click` (`:3250-3251`). Consecinta neasteptata: **azi, deja**,
-  `Init` (`:3150`) seteaza singur `opt_incasat.Value = 2` cand documentul soseste cu `poDate.incasat<>0`
-  (cazul copierii), deci deschiderea dialogului aloca un numar fara ca cineva sa atinga ceva. Intr-un
-  formular unde zona se plieaza si se deplieaza repetat pe acelasi `poDate` persistent, o repopulare
-  naiva a starii ar aloca si dezaloca **la fiecare toggle**. Solutia proiectata: populare **o singura
-  data**, iar plierea strict pe `Visible`/`Height` — niciodata pe reasignare de `.Value`. Criteriul de
-  non-alocare e formulat ca **assert headless pe `poGeneratorNumere`**, pe doua scenarii de start
-  (document nou **si** document copiat cu incasare presetata — al doilea e cel care azi chiar aloca).
-- **Nu exista mecanism de pliere de refolosit.** Cautare exhaustiva in `ofacturare.vc2`: zero potriviri
-  in prototipul `frm_facturare_articole2`. Cel mai apropiat tipar din suita e
-  `frm_modific2024.afiseaza_rulaje` (`omodificari.vc2:13169-13199`, perimetrul #6 — **citit, neatins**),
-  acelasi idiom sus/jos validat deja pentru `but_modifica`/`but_salveaza` la decizia 9. Deci **cod nou**,
-  dupa un tipar existent, nu o clasa reutilizabila.
-- **Decizia 26 cerea mai mult decat mecanismul existent** — `ct_clb_cautare.do_dezactiveaza()`
-  (`caut_ora.vc2:800-806`) ascunde **doar lupa de cautare**, textbox-ul ramane tastabil, deci read-only
-  real ar fi cerut `ReadOnly` explicit pe langa el. **CADUC odata cu decizia 72**: analiticele raman
-  editabile, deci nu se scrie nimic. Constatarea despre `do_dezactiveaza()` ramane valabila pentru
-  oricare alt camp care ar avea nevoie de blocare reala.
-
-**Bug preexistent, gasit in trecere:** la Renunt se dezaloca chitanta (16) si bonul fiscal (3), dar
-**nu si POS (26)**. Nu e introdus de S3b, dar „`actualizeaza_tipincasare` se muta ca atare" **l-ar
-propaga**. **Decizia 40: se repara aici, in trecere** — deci diff-ul lui S3b nu mai e o mutare pur
-mecanica, si testarea acopera si dezalocarea POS pe calea veche.
-
-**Decizia 41 fixeaza granularitatea plierii: doua comutatoare.** Grupul de **incasare** are comutator
-propriu — e singurul cu efecte laterale (alocare/dezalocare) si singurul blocat pe document emis prin
-decizia 25 — iar delegat/transport, adresa, text aditional si analiticele stau impreuna sub al doilea.
-Garda de non-alocare la toggle se scrie si se testeaza astfel **intr-un singur loc**.
-
-*Gata cand:* criteriul rescris verificabil e la sectiunea 10 a raportului, in cinci puncte — mai strans
-decat formularea de mai jos pe trei dintre ele: paritatea de emitere se cere pe **toate patru** tipurile
-de incasare (nu doar bon fiscal), non-alocarea la toggle se cere pe **ambele** scenarii de start, iar
-iar blocarea grupului de incasare — **amanata la S8c, vezi mai sus** — se cerea pe **ambele stari ale antetului** (inainte si dupa
-`but_modifica`), nu doar la deschidere. **Punctul care cerea read-only-ul analiticelor pe ambele stari
-cade odata cu decizia 72** — analiticele sunt editabile, si la introducere, si la reemitere, deci
-criteriul devine invers: pe un document emis analiticele **se pot alege**. Formularea initiala,
-pastrata ca rezumat: un document cu incasare prin bon fiscal emis din formularul unificat produce
-aceleasi randuri si acelasi numar de bon ca pe calea veche, iar deschiderea si inchiderea formularului
-fara a atinge zona de incasare **nu aloca si nu dezaloca niciun numar**.
-*Depinde de:* S3.
-
-#### S3c — Sursa ca parametru, nu ca global
-Decizia 12. Punctele de intrare exista deja (comanda: `ocomenzi.vc2:1580-1596`; contract: din
-ROACONTRACTE), dar transmit prin globalele `goComanda` / `goContract`. Se adauga parametru explicit
-pe `factureaza` si pe `oDateFactura`, cu globalele pastrate ca sursa de rezerva pana se convertesc
-toti apelantii (inclusiv cei din ROACONTRACTE si ROAGEST — e cod comun). Se verifica intai asimetria
-de resetare semnalata la L.3.
-**PROIECTAT (runda 11) — `docs\cercetare\s3c_sursa_ca_parametru.md`.** Se poate face, e o interventie
-mica — dar **planul supraestimeaza cat de „globala" e problema azi**, si in doua sensuri opuse:
-
-- **`goContract` nu e scris nicaieri in ROAFACTURARE** — nici in codul produsului, nici in `COMUN`-ul
-  lui. Deci ramura de precompletare din contract (`ofacturare_comun.prg:261-297`) e **cod mort in acest
-  produs**, iar **asimetria de resetare de la L.3** (`ofundal_facturare.vc2:886-902`) exista textual dar
-  e **inerta**: n-are ce sa lase nereseta, pentru ca n-are scriitor. Devine risc real abia daca cineva
-  adauga in viitor un scriitor in ROAFACTURARE — moment in care lipsa resetarii s-ar activa **tacut**.
-- **`goComanda` chiar e viu, si are DOI scriitori**, nu unul: clicul pe „Factureaza"
-  (`ocomenzi.vc2:1583`) **si** navigarea in grid (`:2199`, doar ca sa decida vizibilitatea unui buton).
-  Al doilea n-are nicio legatura cu facturarea si **ramane si dupa conversie** — deci globala nu dispare.
-- **Criteriul „pana se convertesc toti apelantii" nu se poate citi ca „pana dispare globala".** In
-  ROACONTRACTE, `goContract` e **bufferul de editare al intregului ecran de contracte** (peste 100 de
-  `ControlSource` legate de el), populat de navigarea in grid, independent de facturare. Nu dispare la
-  aceasta poveste si nici la vreuna rezonabila urmatoare; S3c schimba **doar canalul** prin care valoarea
-  ajunge la `oDateFactura.Init`.
-
-**Suprafata de regresie, masurata:** doi scriitori de convertit (`ocomenzi.vc2:1580-1596`;
-`ferestre_contracte.vc2:1538-1549` + `:1598-1606` in ROACONTRACTE), **trei** fisiere comune atinse o
-singura data fiecare (`ofacturare.prg`, `oproceduri_facturare.prg`, `ofacturare_comun.prg`), si **zero
-schimbari** la celelalte ~31 de puncte de intrare din inventarul S2 — toate cheama `factureaza(N)` cu un
-singur argument. Cele cinci fisiere sunt **identice pe MD5** in cele sapte produse, cu o singura exceptie:
-**ROAIMOB**, o linie lipsa in `ofacturare_comun.prg` — acolo diff-ul se aplica **manual**, nu prin copiere
-mecanica.
-
-**Semnatura propusa:** `factureaza(tnTip, toFactura, toSursa)` si `oDateFactura::Init(tnIdSet, tnTip,
-toSursa)` — parametru nou la coada, cu implicit, fallback pe global cand lipseste.
-**Capcana de limbaj, semnalata explicit:** garda se scrie `Type('toSursa') = 'O'`, **nu**
-`Type('toSursa') <> 'U'`. Un parametru VFP nepasat **nu** e `'U'` (aia e pentru variabile nedeclarate),
-ci `'L'` cu `.F.` — o garda `<> 'U'` ar trece mereu adevarat si ar incerca sa citeasca `.id_part` de pe
-`.F.`, eroare la primul apel neconvertit. Raportul cere verificarea comportamentului `Type()` pe un
-`.prg` de proba **inainte** de a atinge fisierele reale.
-
-*Gata cand:* criteriul rescris e la sectiunea 10 punctul 4 al raportului, pe patru probe — una
-structurala (parametrul prezent cu semnatura identica in toate cele trei fisiere comune, in toate cele
-sapte produse) si trei comportamentale: **calea convertita** cu globala deliberat „murdara" dintr-o
-navigare anterioara produce documentul dat prin parametru, nu pe cel din globala; **calea neconvertita**
-(oricare din cele ~31 de apeluri cu un singur argument) produce acelasi document ca inainte; iar
-**ROACONTRACTE** da aceeasi precompletare ca azi, verificat manual pe build separat.
-*Depinde de:* S2. **Atinge cod comun intregii suite** — nu se face impreuna cu alta modificare.
-
-#### S4 — Cautarea articolelor pe server, in linie
-Partea Oracle: variante filtrate pe articol ale cursoarelor de facturare, cu aceleasi ramuri pe tip
-ca `cursor_preturi` / `cursor_contract` / `cursor_comanda` / `cursor_avize` / `cursor_gestiune`.
-Partea VFP: `combosql` pe cod si pe denumire completeaza linia cu pret, cota TVA, valuta, `id_pol`,
-`gestionabil`, `pret_cu_tva`; `crsarticole` nu se mai incarca in masa.
-Se pastreaza "adauga tot" pentru tipurile care au document sursa (comanda, aviz, contract) — acolo
-setul e marginit si incarcarea lui e legitima.
-**PROIECTAT (runda 11) — `docs\cercetare\s4_cautare_articole_server.md`. Criteriul de mai jos nu e
-atingibil ca atare, si motivul nu e UX.**
-
-- **`crsarticole` nu e doar sursa de populare a gridului — e un registru al cantitatii ramase de
-  facturat.** E citit **si scris** de `do_adauga_tot`, `do_sterge` si `do_scrie_factura` pentru toate
-  tipurile cu document sursa: stergerea unei linii **reface** cantitatea in `crsarticole`
-  (`ofacturare.vc2:14640-14669`), iar la scriere se face `Calculate Sum(cantitate) To lnCantitateRamasa`
-  peste el ca sa se decida daca se inchide automat comanda / avizul (`:14303-14311`, `:14334-14338`).
-  Deci pe **comanda, aviz si contract** incarcarea in masa **nu poate disparea**, indiferent de decizia
-  de UX privind „adauga tot" — bookkeeping-ul e cablat pe cursorul incarcat. **S4 se aplica curat doar
-  pe ramurile de lista de preturi** (`cursor_preturi`, plus jumatate din `cursor_contract` si
-  `cursor_gestiune`).
-  **DEPASIT de proiectarea punctului 2 (runda 12)** — se citeste doar ca istoric al deciziei 39.
-  Concluzia „incarcarea in masa nu poate disparea" cadea pentru ca `crsarticole` era tratat ca un
-  registru omogen; sunt de fapt **doua mecanisme distincte** (Rol A / Rol B), si niciunul nu cere
-  cursorul incarcat. Vezi mai jos.
-- **`combosql` e un prototip la jumatate, si e singura lui utilizare din suita.**
-  `grd_factura.cCodMat.cboCodmat` / `cCboDenumire` (`ofacturare.vc2:16751-16797`, wiring la
-  `:19288-19334`) chiar cauta pe server, dar scrie **doar** `codmat` / `denumire` / `id_articol`, pentru
-  ca sursa lui (`vnom_articole`) n-are pret, TVA, valuta, `id_pol`, `gestionabil`. Cautare in
-  `COMUNROA` si `ROAGEST`: **zero alte utilizari** — nu exista de unde copia un exemplu complet.
-  Confirma insa exact punctul C: de facut e **varianta filtrata pe articol a celor cinci cursoare**, nu
-  o cautare noua.
-- **`cursor_contract` produce deja doua cursoare** — `V_CURSOR` (`crsarticole`, prin delegare la
-  `cursor_preturi`) si `V_CURSOR2` (`crsarticole1`, articole **sau** rate). Filtrarea se aplica curat
-  doar pe jumatatea `crsarticole`; **randurile de rata n-au `id_articol`** si raman needitate.
-- **Vizibilitatea de azi a butonului „adauga tot" coincide aproape exact cu impartirea utila pentru S4**
-  (`ofacturare.vc2:15108-15248`: ascuns pe lista de preturi, vizibil pe comanda / aviz / retur) —
-  confirmare pe cod, nu presupunere.
-- **Legatura cu S10, confirmata:** pretul se cauta **o singura data**, la alegerea liniei, si se
-  transmite mai departe neschimbat — exact ce face azi `adauga_articol_factura`, care il primeste ca
-  parametru in loc sa-l re-derive.
-- **Efect secundar al filtrarii, rezolvat prin decizia 42:** `verifica_cursuri_valute` e azi
-  neconditionata in procedura, deci pe varianta filtrata s-ar declansa la **fiecare** cautare de articol
-  in loc de o data la deschidere — cu `-20005` posibil pe o valuta pe care operatorul n-o foloseste,
-  inainte sa vada vreun rand. Se **restrange la valuta articolului cautat**.
-- **Cele doua puncte „de inchis inainte de implementare" sunt INCHISE (runda 12)** —
-  `docs\cercetare\s4_puncte_deschise.md`. Raspunsul de baza e la amandoua „filtrarea nu schimba nimic",
-  dar **fiecare lasa in urma o cerinta de implementare, nu doar o bifa**:
-  - **`id_jtva_coloana` chiar lipseste** din `cursor_preturi`, din `cursor_gestiune` si din `V_CURSOR2`
-    al lui `cursor_contract`, pe toate ramurile — confirmat pe SQL. **Nu e bug:** `do_initializeaza_articol`
-    pune `0`, iar `frm_articol_factura.Init` (mostenit si de `frm_articol_gest_factura`) **il rederiva
-    mereu** din `proc_tvav` via `jtva_coloane`, pe orice linie adaugata prin `do_adauga_articol`.
-    **Cerinta care rezulta pentru S4:** derivarea tine **numai** daca linia trece prin
-    `do_adauga_articol`. `combosql`-ul prototip de azi (`ofacturare.vc2:19288-19306`) face `REPLACE`
-    direct in `crsfactura` si **ocoleste toata derivarea**; daca S4 extinde acel `REPLACE` fara sa treaca
-    prin `do_adauga_articol`, `id_jtva_coloana` ramane nederivat si Oracle
-    (`adauga_articol_factura`, ramura `ELSE`) arunca **`-20000 FACT-013`** sau scrie cota gresita.
-    **Bug nou posibil, introdus de S4** — intra ca cerinta explicita in proiectare, nu ca observatie.
-  - **`but_urmator_tot1` are `Visible = .F.` la design** (`ofacturare.vc2:11265`); tipurile 23 si 41 au
-    `Case` propriu, dar **niciunul nu-l face vizibil** — confirmat, nu presupus. Nu exista alt mecanism
-    de „adauga tot"; exista insa `but_urmator1` (adaugare rand-cu-rand), **neconditionat de tip**, care
-    merge prin acelasi `do_adauga_articol` — deci dupa S4 **nu se pierde nimic** pe aceste tipuri.
-  - **Corectie de rutare fata de ce presupunea planul:** pe formularul **standard** (`factureaza`,
-    `ofacturare.prg:266-308`) doar **tipul 41** cheama `cursor_gestiune`; **tipul 23 cheama de fapt
-    `cursor_preturi`** (grupat cu lista de preturi). Tipurile **45, 48, 49 nu ating deloc**
-    `cursor_gestiune` (45 → `cursor_preturi`, 48/49 → `cursor_articole_k`, alta procedura). Doar pe
-    **prototip** (`factureaza2`, opt-in `gnFacturareNou`) 23 si 41 merg impreuna pe `cursor_gestiune` —
-    **divergenta reala intre cele doua formulare**, semnalata, neatinsa, in afara perimetrului S4.
-
-**Decizia 39 largeste povestea peste ce propunea raportul.** Raportul recomanda restrangerea la lista de
-preturi, tocmai pentru ca registrul de cantitate ramasa blocheaza restul; Marius a ales sa se desfaca si
-registrul. Deci S4 are de acum **doua bucati, nu una**:
-1. **varianta filtrata a cursoarelor** + completarea liniei din `combosql` (partea proiectata in raport);
-2. **decuplarea bookkeeping-ului de cantitate ramasa** de cursorul incarcat in masa — sursa unica, nu o a
-   doua copie tinuta in pas cu prima. Atinge `do_adauga_tot`, `do_sterge`, `do_scrie_factura` si
-   **inchiderea automata** a comenzii / avizului.
-
-**Punctul 2 — PROIECTAT (runda 12): `docs\cercetare\s4_punct2_registru_cantitate_ramasa.md`.** Iese mult
-mai ieftin decat parea, pentru un motiv care nu se vedea din raportul punctului 1.
-
-- **`crsarticole.cantitate` are DOUA roluri, nu unul** — si numai unul e „registrul" temut.
-  **Rol A — cantitate ramasa de facturat dintr-un document sursa** (comanda `3,21,25,28,42,47`; avize
-  `4`). **Rol B — plafon de cantitate in sesiune** (lista de preturi gestionabila `1,22,29` si jumatatea
-  de contract, transfer `23,41`, retur `8,9,24`): impiedica operatorul sa adauge mai mult decat vede pe
-  ecran. **Rol B nu alimenteaza nicio decizie Oracle** — e plafon de UI, nu registru de business.
-- **Pe Rolul A, cursorul VFP e o copie redundanta a unui calcul pe care Oracle il repeta oricum.**
-  `do_scrie_factura` sumeaza `crsarticole` doar ca sa decida ce trimite in `pnParametruAditional`, iar
-  Oracle **recalculeaza independent, din tabele reale**, in `inchide_comanda()` / `marcheaza_facturat()`,
-  chiar in procedura care scrie factura.
-- **Nu exista coloana `INCHISA`.** Cautare in tot pachetul: **zero potriviri** (verificat separat de
-  sesiunea principala). „Comanda inchisa" e o stare **derivata** din `COMENZI_ELEMENTE` vs
-  `VANZARI_DETALII`; `inchide_comanda()` insereaza un **rand compensator**, nu seteaza un flag. Pe
-  comanda, `pnParametruAditional` e strict **binar** — „s-a cerut fortarea inchiderii?" —, iar cantitatea
-  trimisa de VFP **nu participa** la calculul Oracle.
-- **Pe avize e altfel, si aici sta subtilitatea:** `VANZARI.FACTURAT` **e** un flag persistat, iar
-  `V_VERIFICARE` (= `pnParametruAditional`) alege intre „**increde-te in VFP** si marcheaza toate avizele
-  referite" (`0`) si „**recalculeaza per-aviz** din tabele reale si marcheaza doar cele cu `ramas = 0`"
-  (`1`). Deci pe aviz suma din VFP schimba semantica, nu doar declanseaza o actiune.
-- **Un bug preexistent, de REPRODUS identic, nu de reparat in trecere:** cand un `crsarticole` agrega mai
-  multe avize, suma globala poate da `0` desi un aviz are ramas si altul are exces care-l compenseaza —
-  caz in care toate se marcheaza facturate, inclusiv cel cu ramas real. Varianta noua pastreaza aceeasi
-  conditie de declansare (suma globala pe tranzactie, nu per document).
-- **`23` si `41` nu apar deloc in `CASE`-ul de finalizare** — cad pe `ELSE`, fara nicio inchidere:
-  transferul n-are document sursa de inchis, doar plafon (Rol B). Contractul (`2,6,52`) intra pe
-  `scrie_rate_factura`, care **nu e o inchidere**, e alta operatie.
-- **Recomandarea: (b) pentru Rolul A, (c) pentru Rolul B.**
-  **(b)** cele doua `Calculate Sum` din `do_scrie_factura` se inlocuiesc cu un apel Oracle facut **dupa**
-  `do_scrie_articole()` (cand `VANZARI_DETALII_TEMP` contine exact liniile pe cale sa fie scrise) si
-  **inainte** de `Do Case`-ul care alege procedura de scriere. Cele doua functii Oracle noi sunt o
-  **extragere** a interogarii pe care `inchide_comanda` / `marcheaza_facturat` o ruleaza oricum, nu logica
-  noua. Efect secundar gratuit: dispare si un bug latent de concurenta — cursorul local nu vede azi ce a
-  facturat intre timp alt operator din aceeasi comanda.
-  **(c)** plafonul Rol B se cere pe server **la fiecare adaugare/editare**, minus ce e deja in
-  `crsfactura` — deci nu mai exista a doua copie de tinut in sincron.
-  Varianta cu un cursor propriu, minimal, a fost **respinsa motivat**: ramane tot o a doua copie manuala,
-  doar mai ingusta. Nu e „sursa unica".
-- **Cazul limita cerut in plan** (adauga si sterge inainte de salvare) devine **trivial**, nu doar
-  acoperit: liniile adaugate-si-sterse nu ajung niciodata in `VANZARI_DETALII_TEMP`, deci nu influenteaza
-  calculul, fara nicio actiune de refacere.
-- **CORECTIE asupra punctului 1:** pasul lui 5 (`s4_cautare_articole_server.md:417-424`) opreste
-  incarcarea in masa si pe `23,41`, presupunand ca n-au bookkeeping — **au Rol B**, confirmat pe cod.
-  Punctul 1 **nu se poate aplica pe `23,41`** inainte ca punctul 2 sa acopere Rolul B pe ele.
-
-**Toate trei sunt INCHISE (runda 13). Nu se mai reiau.**
-1. ~~**Asimetria din `do_modifica`**~~ — azi, pe grupul `1,22,29` + contract-lista, plafonul **nu** se
-   ajusteaza la editarea cantitatii unei linii deja adaugate. E preexistenta. **INCHIS — decizia 45
-   (runda 13, pe recomandare):** se lasa sa se **corecteze de la sine** prin recalculul la cerere, cost
-   zero, dar corectia se **declara explicit in changelog** — S4 schimba atunci un comportament punctual,
-   nu doar „decupleaza".
-2. ~~**Corectia pe `23,41`**~~ — **INCHIS — decizia 46 (Marius, runda 13): asteapta punctul 2.**
-   Punctul 1 **nu se redeschide** acum; aplicarea lui pe `23,41` vine odata cu recalculul pe server, care
-   acopera Rolul B. Nu se pierde nimic: ordinea de implementare oricum le pune dupa.
-3. ~~**Contract `26,52`**: nu s-a gasit dovada nici de prezenta, nici de absenta a Rolului B.~~
-   **INCHIS de proiectarea S5** (`docs\cercetare\s5_acoperire_tipuri.md`): `26` si `52` **n-au niciun
-   bookkeeping**, nici Rol A, nici Rol B — excluderea e totala, pe `Do Case` exhaustiv fara ramura
-   implicita. Deci „dovedit absent", nu „nepresupus". Nu mai e o decizie de luat.
-
-**Cerinta de revizuire**: cele doua functii Oracle noi sunt o extragere din proceduri existente, dar
-raman **PL/SQL nou in `PACK_FACTURARE`**, cu `JOIN`-urile reproduse **din citire, nu din executie**. Se
-verifica pe Oracle inainte de a continua — e primul pas al implementarii, nu o formalitate.
-
-**Nota de executie (decizia 60):** pe documentele de tip **48/49** (custodie), cautarea pe server in
-linie ramane restransa la articole `IN_STOC = 0` — nu se ofera articole gestionabile pe aceste tipuri.
-Siguranta regenerarii la editarea custodiei (decizia 60,
-`docs\cercetare\custodie_48_49_stergere_reemitere.md`) atarna de acest invariant.
-
-*Gata cand:* patru probe, nu una. **(a)** Deschiderea formularului nu mai executa niciun cursor de
-articole, **pe niciun tip** — nu doar pe lista de preturi. **(b)** Alegerea unei linii produce aceleasi
-valori ca randul corespunzator din `crsarticole` de azi, pe fiecare tip; maparea camp-cu-camp e la
-sectiunea 6 a raportului, cu coloanele semnalate explicit acolo unde varianta filtrata **nu** poate
-produce aceeasi valoare. **(c)** **Paritate pe inchiderea automata** (decizia 39): acelasi document
-sursa, aceleasi linii facturate partial, **aceeasi stare finala** — pe comanda, acelasi rand compensator
-in `COMENZI_ELEMENTE` (nu exista flag `INCHISA` de comparat); pe aviz, exact aceleasi `VANZARI.FACTURAT`
-marcate, inclusiv in cazul in care avizele agregate se compenseaza intre ele — pe fiecare tip cu document
-sursa —
-inclusiv cazul in care operatorul adauga si apoi sterge linii inainte de a salva, care azi trece prin
-refacerea cantitatii in `crsarticole`. **(d)** O linie adaugata prin cautarea in grid ajunge in
-`crsfactura` cu **`id_jtva_coloana` derivat** — adica trece prin `do_adauga_articol`, nu prin `REPLACE`
-direct ca prototipul de azi; proba e ca documentul se scrie fara `FACT-013` si cu aceeasi cota ca pe
-calea veche. **(e)** Pe un document de tip 48/49, cautarea pe server nu ofera si nu permite adaugarea
-unui articol cu `IN_STOC <> 0` (decizia 60).
-*Depinde de:* S3. **Punctul 2 nu e proiectat** — se proiecteaza separat inainte de implementare.
-
-#### S4b — Bara de butoane si meniul de adaugare
-Decizia 13, proiectata in J. Trei bucati:
-1. **Butoanele de linie deasupra gridului**, cu eticheta, nu iconite mute: linie noua (`but_nou`),
-   sterge linia (`but_sterge`), detalii linie.
-2. **Un singur buton „Adauga articole” cu `xmenu()`**, cu optiunile din tabelul din J. Inlocuieste
-   `But_urmator_tot1` (azi fara caption si fara `ToolTipText`) si butonul separat de alegere.
-   **Acopera si contractele** — tipurile 2, 6, 26, 52 lipsesc azi din conditiile de vizibilitate
-   (`ofacturare.vc2:15113-15245`), desi avizele sunt acolo.
-3. **Alegerea selectiva**, dupa tiparul RORIS: dialog modal cu coloana de bifat si criterii de
-   cautare, populare aditiva in cursorul local, nicio scriere in baza pana la salvare. Pe contract,
-   unitatea de selectie e **rata** — cazul explicit cerut. Spre deosebire de modelul RORIS, la zero
-   rezultate se spune de ce, nu se inchide in tacere.
-**PROIECTAT (runda 11) — `docs\cercetare\s4b_bara_butoane_meniu.md`.** Implementabila fara cod nou major,
-cu **patru corectii** fata de textul de mai sus:
-
-- **Golul de contract e mai mare decat „lipseste `but_urmator_tot1.Visible`".** Pe **tipul 52**
-  formularul nu intra in **niciun** `Case` al `Do Case`-ului (`ofacturare.vc2:15109-15248`) — deci pierde
-  si titlul, si eliminarea coloanei `cSerie`, nu doar butonul „tot".
-- **Nu se porneste de la tiparul RORIS.** `frm_tranzit` e specific ROAACNPRO si ar insemna formular nou;
-  ROAFACTURARE are deja `cauta_alfa(..., tnTipReturn=1)` — mecanism **generic** de selectie multipla cu
-  bifare, criterii de cautare si populare aditiva, folosit **chiar in acest formular** pentru returul
-  multi-factura (`do_cauta_facturi`). Mai ieftin, si deja dovedit in productie.
-- **„Unitatea de selectie e rata" e adevarat doar pe jumatate.** `crsarticole1` are **doua ramuri
-  disjuncte** in SQL — `OPT_FACTURARE = 3` (articole reale) si `OPT_FACTURARE IN (1,2)` (rate de
-  scadentar) — iar un contract e mereu pe una singura, niciodata pe amandoua. Eticheta „Alege ratele de
-  facturat…" e corecta doar pe a doua ramura; **contractul are deci doua meniuri, nu unul**.
-- **Un gol de cod, nu doar de vizibilitate:** `do_adauga_tot` parcurge azi **exclusiv `crsarticole`,
-  niciodata `crsarticole1`**. Fara extindere, „adauga tot" pe contract fie n-ar face nimic, fie ar aduce
-  liniile gresite — deci pe contract butonul trebuie **scris**, nu doar facut vizibil.
-
-**Echivalenta „tot" = „alege total"** tine azi prin constructie, pe o singura rutina comuna de adaugare
-pe rand (`do_adauga_articol`) — se pastreaza asa, iar pe contract devine adevarata abia dupa extinderea
-de mai sus.
-
-*Gata cand:* pe fiecare sursa (comanda, contract, avize, document returnat) meniul ofera si „tot" si
-„alege", iar rezultatul in `crsfactura` e identic pe cele doua cai cand selectia e totala — **inclusiv
-pe contract**, unde azi „tot" nu parcurge cursorul potrivit, si **inclusiv pe tipul 52**, care azi nu
-intra in nicio ramura. Pasii cu criterii verificabile sunt la sectiunea 7 a raportului; ce nu se poate
-testa headless, la sectiunea 8.
-*Depinde de:* S4.
-
-#### S4c — Discountul pe linie, mutat din dialog in grid
-Decizia 14, proiectata in K. Dialogul de articol dispare odata cu unificarea, deci cele doua campuri
-de discount ale lui — **procent** si **valoare unitara** — devin coloane in grid, cu acelasi calcul
-reciproc din `frm_articol_factura.do_calculeaza_discount` mutat pe evenimentele coloanelor. Se repara
-in acelasi timp inconsecventa de azi (read-only in lei, editabil fara recalcul in valuta). Se
-pastreaza excluderea pe `in_valuta`. Modelul de date **nu se atinge** — se stocheaza tot valoarea.
-**VERIFICAT — S4c e deblocata, dar capcana e alta decat se credea.** Raport:
-`docs\cercetare\discount_in_rapoarte_si_efactura.md`.
-
-- **Niciun raport de factura nu tipareste discountul pe linie** — nici valoare, nici procent. Cautare
-  in toate `.fr2` de factura / proforma / invoice din `COMUN\Rapoarte`: **zero potriviri** pe „disc".
-  Singurele doua `.fr2` cu „DISCOUNT" sunt de NIR, nu de facturi emise. Se tipareste `pretftva` si
-  `valftva`, **deja nete de discount** (`prelucreaza_factura`, `ofacturare_comun.prg:1055-1059`,
-  `:1156-1248`, in cursorul `crsfacttemp`).
-- **eFactura foloseste exact acelasi cursor** (`xmlefactura.prg`) — `LineExtensionAmount` si
-  `PriceAmount` sunt aceleasi valori nete, cu optiunea (dezactivata implicit) de a adauga si un
-  `cac:AllowanceCharge` informativ pe linie.
-- **SAF-T (D406) nu exista in ROAFACTURARE** — doar tabele de nomenclator cu prefix `saft_` (coduri
-  TVA / plata), pe partea de achizitii, fara legatura cu `DISCOUNT_UNITAR`.
-- **Deci ingrijorarea initiala („utilizatorul schimba totalul fara sa se vada pe hartie") era gresit
-  tintita:** discountul nu se vede pe hartie **prin design**, iar totalul se vede corect pentru ca
-  pretul tiparit e deja net.
-
-**PROIECTAT (runda 12) — `docs\cercetare\s4c_discount_in_grid.md`.** Implementabila, cu **capcana
-retintita**: formularea de mai jos, din rundele anterioare, era in acelasi timp prea alarmista si prea
-vaga.
-
-- **Baza de date nu e in pericol.** `do_scrie_articole` trimite spre Oracle **direct** din
-  `discountftva` / `discountctva` / `vdiscountftva` / `vdiscountctva` (`ofacturare.vc2:14081-14083`,
-  ales pe `cu_tva` si `tip_valuta`) — verificat pe cod, nu presupus. Deci
-  `VANZARI_DETALII.DISCOUNT_UNITAR` iese **mereu corect**, indiferent de starea campurilor agregate.
-- **Riscul e strict local, si e o inconsistenta, nu o valoare veche.** `valdiminuatftva` /
-  `valdiminuatctva` sunt agregate citite de `prelucreaza_factura` **din acelasi `crsfactura` din
-  memorie**, nereincarcat din Oracle. Netratate, factura tiparita poate iesi cu `pretftva` corect si
-  `valftva` inconsistent — **pret x cantitate diferit de valoare**, ceea ce se vede pe hartie.
-- **Exista deja azi calea care demonstreaza gaura:** editarea `vdiscountftva` in grid, pe factura in
-  valuta, **nu declanseaza recalculul** agregatelor (`discount_verificare2.md`, punctul 3).
-- **Calculul e deja generic si refolosibil**, nu trebuie rescris: `do_calculeaza_discount`
-  (`ofacturare.vc2:1874-1976`) plus `calculeaza_totaluri()` (`oproceduri_facturare.prg:2258-2381`),
-  care ruleaza pe `Scatter Name`, **fara dialog**.
-- **Evenimentul recomandat pe coloanele noi e `Text1.LostFocus`**, nu `InteractiveChange` sau `Valid` —
-  tiparul e deja folosit in acelasi fisier, pe `frm_avizare_lucrare.grd_articole.cCantitate` /
-  `cPret` (`:6549-6562`).
-- **Punctul deschis din S1 e inchis in trecere:** `_checkbox1` si `chkDetaliat` sunt **doua controale
-  distincte** in `frm_alte_date`, nu o duplicare — subiectul nu are legatura cu S4c.
-
-*Gata cand:* tastarea in oricare din cele doua coloane produce aceleasi valori in `crsfactura` ca
-dialogul de azi, pe ambele monede; totalurile se refac imediat; discountul venit din politica de pret
-se comporta ca azi; **si `valdiminuatftva` / `valdiminuatctva` se recalculeaza la fiecare editare**,
-astfel incat pe factura tiparita `pret x cantitate` sa dea exact valoarea — verificat prin retiparire
-si prin XML-ul de eFactura, nu doar pe ecran. Pasii cu criterii verificabile sunt la sectiunea 7 a
-raportului; ce nu se poate testa headless, la sectiunea 9.
-*Depinde de:* S4.
-
-#### S4d — Data cursului valutar, numai cand are sens
-Decizia 15, proiectata in M. Campul apare cand tipul nu e retur **si** (documentul e in valuta **sau**
-a intrat pe grid macar un articol cu pret in valuta) — evaluat reactiv, ceea ce devine posibil abia
-in formularul unificat.
-**VERIFICAT — S4d e deblocata.** Raport: `docs\cercetare\zi_curs_validare.md`. Ascunderea selectorului
-**nu** poate lasa documentul fara curs, cu o conditie deja indeplinita de cod:
-
-- **Implicitul exista si e neconditionat.** `poDate.zi_curs` primeste data documentului chiar in
-  `oDateFactura.Init` / `Reset` (`COMUN\programe\ofacturare_comun.prg:247`, `:496`), **inainte** ca
-  formularul sa decida ce ascunde. **Nicaieri codul nu goleste `zi_curs` cand controlul e ascuns.**
-  Deci „valoarea implicita ramane" nu e ceva de construit — e comportamentul actual, de **nestricat**.
-- **Precedentul cerut exista deja**, in alt formular: `frm_date_factura`, tipurile 8 / 9 (retur), unde
-  `clb_zi_curs` se elimina **neconditionat** si documentul se salveaza corect — in principal pentru ca
-  `cursor_retur` nici nu foloseste `poDate.zi_curs`.
-- **Linia `:8076` nu e in formularul de factura.** Apartine lui `frm_date_aviz_lucrare`
-  (`inainte_de_do_termin`, `ofacturare.vc2:8054-8119`), un formular restrans pentru **aviz pe lucrare /
-  aviz pe NIR** (tipurile 27 si 30), care nici nu are control de valuta. Valideaza `zi_curs` pentru ca
-  tipul 27 are nevoie de curs pentru articolele din comanda, **independent de `poDate.in_valuta`** —
-  deci nu e o inconsecventa de reparat orbeste, are un motiv. Se aliniaza doar daca formularul unificat
-  preia si tipurile 27 / 30.
-
-**Riscul real e in alta parte, si nu tine de vizibilitatea campului:**
-`pack_facturare.verifica_cursuri_valute` (chemata din `cursor_preturi`) ruleaza **neconditionat de
-`in_valuta`** si exclude doar moneda nationala. Deci un `zi_curs` implicit (azi) fara curs setat in
-`CURS` pentru o valuta prezenta in listele de preturi ale utilizatorului **poate pica oricum**
-(`-20005`, „Nu este setat cursul…"), indiferent daca selectorul e vizibil sau nu. **Ascunderea nu
-introduce riscul asta si nici nu-l rezolva** — dar il face mai greu de inteles pentru operator, care nu
-mai vede campul din cauza caruia primeste eroarea. De tratat in mesajul de eroare, nu in vizibilitate.
-
-**PROIECTAT (runda 12) — `docs\cercetare\s4d_zi_curs_reactiv.md`.** Nu se inventeaza nimic; se
-reevalueaza vizibilitatea unui control care exista deja.
-
-- **Cheia reactivitatii e un camp deja prezent in cursorul gridului: `crsfactura.tip_valuta`**,
-  interogabil cu **exact tiparul deja folosit in cod** (`ofacturare.prg:1656`, `:1730`:
-  `Select Distinct ... From crsfactura Where tip_valuta = 1`). Nu e nevoie de o structura noua.
-- **Prototipul are deja `Clb_zi_curs` propriu, editabil, legat la `poDate.zi_curs`**
-  (`ofacturare.vc2:16285-16305`) — se schimba doar **cand** e vizibil.
-- **Mesajul `-20005` contine DEJA data si numele valutei lipsa** (`STRINGAGG` peste toate valutele fara
-  curs) — deci partea de „sa spuna care valuta si ce zi" nu e de construit. **Decizia 42 nu schimba
-  continutul mesajului, ii schimba domeniul**: il restrange la valuta articolului cautat, dar **numai pe
-  varianta filtrata** (S4 punctul 1); pe caile cu document sursa incarcarea in masa ramane
-  neconditionata, deci acolo eroarea poate inca numi o valuta straina de documentul curent.
-- **Ce lipseste cu adevarat, si intra ca pas de implementare, nu ca optiune:** sectiunea M cere ca la
-  aceasta eroare campul sa **revina vizibil** — altfel operatorul primeste o eroare despre un camp pe
-  care nu-l vede.
-- **#16 nu e in perimetrul S4d.** E legat de S2 (bucla de reincercare din `ofacturare.prg`), cu verdict
-  separat in `s3_portare_antet.md`. S4d doar **confirma** ca antetul persistent ii inlatura mecanismul,
-  cu conditia ca S2/S3 sa nu recreeze formularul la eroare.
-- ~~**De confirmat cu Marius (mic, de UX):** ce se intampla cand se sterge **ultimul** articol in
-  valuta?~~ **INCHIS — decizia 47 (Marius, runda 13): simetrie.** Campul **se ascunde la loc** cand
-  dispare ultimul articol in valuta, pe tiparul `lb_cursuri`. „Clipitul" la adaugari/stergeri repetate
-  e acceptat ca pret al unei reguli unice: aparitia si disparitia urmeaza aceeasi conditie, nu doua.
-
-*Gata cand:* o factura in lei fara articole in valuta nu arata campul si se emite corect; aceeasi
-factura, dupa adaugarea unui articol cu pret in valuta, arata campul cu data implicita completata;
-factura in valuta se comporta ca azi; iar la `-20005` **campul redevine vizibil**, cu mesajul de azi
-(care deja numeste valuta si ziua). Pasii cu criterii verificabile sunt la sectiunea 7 a raportului; ce
-nu se poate testa headless, la sectiunea 9.
-*Depinde de:* S4. **#16 se urmareste in S2/S3, nu aici** — vezi M.
-
-#### S4e — Lista de preturi disponibila si pe factura din comanda
-Decizia 16, proiectata in J. Singurul gol real: pe contract merge deja, pe comanda nu, pentru ca
-`cursor_comanda` umple `crsarticole` doar cu articolele comenzii. Se adauga lista de preturi peste
-cursorul sursei, exact ca la copiere (`ofacturare.prg:454-473`), si optiunea „Cauta in lista de
-preturi…” intra in meniu pe toate sursele.
-**Si stergerea intra aici**, nu doar adaugarea: cazul cerut e „clientul mai vrea ceva sau vrea sa
-schimbe”, deci o linie adaugata trebuie sa poata fi si scoasa.
-**DECIS (decizia 29): stergerea unei linii venite din comanda ramane fara protectie.** Se sterge ca
-oricare alta; comanda ramane cu cantitatea nefacturata si va aparea **facturata partial**, ceea ce e
-si starea corecta. Nu se cere confirmare, nu se marcheaza „refuzat", nu se ajusteaza numararea
-acoperirii.
-Ramane un singur efect lateral de tratat, si e pe **adaugare**, nu pe stergere: capul de coloana
-„Cantitate comandata” si mesajul „A fost facturata intreaga cantitate comandata”
-(`ofacturare.vc2:15144-15150`) nu sunt adevarate pentru liniile libere adaugate langa cele din
-comanda.
-**PROIECTAT (runda 12) — `docs\cercetare\s4e_lista_preturi_pe_sursa.md`. Reteta din decizia 16 NU se
-generalizeaza literal** — si asta e rezultatul principal al proiectarii.
-
-- **`APPEND FROM` peste cursorul sursei ar strica doua lucruri pe comanda**, ambele tacut:
-  **(1)** `id_c` e `ROWNUM` per executie Oracle, deci randurile din lista de preturi ar **coliziona** cu
-  cele ale comenzii, iar `do_sterge` ajusteaza cantitatea `For id_c = poArticol.id_c` (`:14652-14655`) —
-  ar atinge randul gresit; **(2)** `do_scrie_factura` face `Sum(cantitate)` peste `crsarticole` pe exact
-  aceste tipuri (`:14332-14338`), iar in `cursor_preturi` **`cantitate` inseamna STOC**, nu „ramas de
-  facturat" — suma care decide inchiderea comenzii ar fi poluata.
-- **De ce merge totusi pe contract azi**, verificat: lista de preturi si articolele contractului sunt
-  **doua cursoare separate** de la bun inceput (`crsarticole` / `crsarticole1`), iar `cursor_contract`
-  emite `id_c` ca **`rownum - 10000`** (`PACK_FACTURARE:2722` — confirmat direct pe export de sesiunea
-  principala), adica autorii au tratat coliziunea de `id_c` ca risc real. In plus, tipurile de contract
-  **nu au deloc** ramura cu `Sum(cantitate)` in `do_scrie_factura` — cad pe `Otherwise`. Nu e un tipar
-  de copiat, e o coincidenta favorabila.
-- **Solutia curata, verificata fezabila pe cod: liniile libere NU intra deloc in `crsarticole`.** Se
-  adauga direct in `crsfactura` prin `APPEND BLANK` + `combosql` — tipar **deja existent** in
-  `frm_facturare_articole2.do_adauga` si pe linia de discount (`ofacturare.vc2:14531`). Atunci `id_c`
-  ramane `0` implicit, si **`do_sterge` devine no-op prin constructie**, fara nicio modificare de cod.
-- **Se aplica identic pe AVIZE (tip 4), nu doar pe comanda** — `cursor_avize` are aceeasi semantica
-  „ramas de facturat" si aceeasi ramura de `Sum`. Titlul povestii spune „din comanda", perimetrul real
-  e „orice sursa cu registru".
-- **Avertisment care traverseaza in S4f:** pe returul ca document (`8,9,24`) riscul de coliziune `id_c`
-  **ramane** (`do_sterge` ajusteaza cu semn opus, urmarind maximul returnabil), desi **fara** poluarea
-  sumei de inchidere. Deci S4f foloseste acelasi mecanism, nu `APPEND FROM`.
-- **Validarea de cantitate pe liniile din comanda e satisfacuta prin constructie** — drumul
-  `do_adauga_articol` → `do_verifica_articol` nu e atins, fiindca liniile libere nu modifica `crsarticole`.
-- **Gol real ramas, neacoperit de S4 si S4b:** nu exista mecanism de validare a cantitatii/stocului
-  pentru un rand ales prin `combosql` — ambele rapoarte se opresc la maparea campurilor. `do_verifica_articol`
-  nu se poate refolosi ca atare (cere un `poArticol` scatter-uit dintr-un cursor sursa incarcat).
-  **DECIS — decizia 44 (Marius, runda 13): `poArticol` devine parametru explicit.** Se pastreaza un
-  **singur loc de validare**: `do_verifica_articol` primeste `poArticol` ca **parametru**, in loc sa
-  citeasca variabila `Private` populata de apelant. Schimbarea de contract a metodei e **aprobata ca
-  atare**; consecinta obligatorie e actualizarea **tuturor apelantilor existenti**, inventariati inainte
-  de prima editare. Aceeasi decizie acopera si `do_alege_stoc` / `frm_articol_gest_factura` din S4f (R7)
-  — o singura solutie pentru amandoua, cum cerea raportul.
-
-*Gata cand:* pe o factura la comanda **si pe una din avize** se poate adauga un articol care nu e in
-sursa, cu pretul din lista de preturi, si se poate sterge o linie adaugata, fara ca liniile din sursa
-sa-si piarda validarea de cantitate **si fara ca suma care decide inchiderea automata sa se schimbe** —
-proba directa: aceeasi comanda, cu si fara linii libere adaugate, produce acelasi rezultat de inchidere.
-*Depinde de:* S2. **Interactioneaza cu S4 punctul 2** (registrul) si **avertizeaza S4f**.
-
-#### S4f — Returul in formularul unificat
-Decizia 17, proiectata in N. **Partea grea nu e ce credeam.** Factura de retur ca document (tipurile
-8, 9, 24) functioneaza deja cap-coada: alegere multipla a facturilor sursa, populare din
-`cursor_retur`, gestiune si pret de achizitie mostenite din liniile originale, stergere si retur
-partial. Munca e:
-
-1. **mutarea lui N.1 ca sursa in meniul de adaugare**, fara sa se atinga popularea — acelasi dialog,
-   aceleasi filtre, acelasi `cursor_retur`;
-2. **ridicarea lui N.2 (`But_retur`) la nivel de document**, dupa modelul lui N.1, cu calea
-   per-articol pastrata;
-3. **lista de preturi pe documentele de retur**, prin acelasi `APPEND FROM` ca la S4e.
-
-Nu se ating: excluderea returului dintr-un retur, filtrarea pe client si valuta, maximul returnabil
-calculat pe server, mostenirea gestiunii si a pretului de achizitie.
-**DECIS (decizia 22):** linia de retur care nu vine din nicio factura originala **e permisa**, ca pe
-orice alt document. Deci punctul 3 nu mai are conditie de intrare. Ce trebuie proiectat in schimb, pe
-liniile libere: gestiunea si pretul de achizitie **se aleg** (ca la N.2), nu se mostenesc, iar maximul
-returnabil calculat pe server **nu se aplica** — nu exista cantitate originala.
-**Afisarea provenientei — VERIFICAT, si raspunsul e „nu la nivel de linie".** Raport:
-`docs\cercetare\legatura_linie_retur.md`. Deci **S4f se livreaza fara coloana de provenienta pe linie**;
-nu se inventeaza. Ce s-a stabilit, ca sa nu se reia:
-
-- **Legatura se pierde chiar in cursorul care aduce datele.** `cursor_retur_document`
-  (`ff_...:3949-4062`) foloseste `V_LISTAID` **doar ca filtru** (`WHERE A1.ID_VANZARE IN (...)`,
-  `:4054-4055`); in lista de coloane a `SELECT`-ului extern (`:3965-4028`) **nu apar nici
-  `ID_VANZARE`, nici `ID_VANZARE_DET`**. `crsarticole` nu are de unde sti din ce factura vine randul.
-- **`INSERT`-ul in `VANZARI_DETALII` nu are nicio coloana de sursa.**
-- **Exista insa o legatura la nivel de DOCUMENT, si nu era cunoscuta in plan: `VANZARI_CORESP`.**
-  `scrie_corespondente_vanzari(3)` (`ff_...:14834-14836`, din `finalizeaza_factura`) scrie
-  `(ID_VANZARE_FACT = documentul de retur, ID_VANZARE_AVIZ = fiecare factura sursa, TIP = 3)`
-  (`:15481-15516`) — **cate un rand per factura sursa aleasa**, nu per linie. Numele coloanei e generic,
-  reutilizat si pentru perechi aviz-factura (`TIP = 1/2`).
-- **Consecinta pentru UI:** cand s-a ales **o singura** factura sursa, se poate afisa corect „documentul
-  asta de retur provine din factura Y" — la nivel de antet, nu de linie. Cand s-au ales **mai multe**
-  (selectie multipla, suportata explicit de dialog), `VANZARI_CORESP` da **multimea** de facturi
-  posibile, deci nici macar antetul nu poate arata o sursa unica. **De asezat in UI ca informatie de
-  document, niciodata ca proprietate de linie.**
-- **N.2 (`But_retur`) nu scrie nicio legatura.** `listaid` (perechi `ID_ARTICOL:ID_VANZARE`) e folosit
-  in `pack_facturare` (`ff_...:8142-8212`) exclusiv ca filtru pe `RUL`, ca sa calculeze cantitatea inca
-  disponibila din acea vanzare. Sursa nu ramane atribut al liniei noi.
-**PROIECTAT (runda 12) — `docs\cercetare\s4f_retur_formular_unificat.md`**, cu **trei corectii** fata de
-textul de mai sus:
-
-- **Punctul 1 se restrange.** Alegerea facturilor sursa **nu se muta** in bara de butoane — ramane la
-  antet / in sectiunea pliata (confirmat impotriva `s4b_bara_butoane_meniu.md` §9.3 si a tabelului de
-  meniu de acolo). Ce se muta in meniul de adaugare e doar **„adauga tot din facturile alese"** si
-  **„alege liniile"**.
-- **Un risc concret, netratat nicaieri pana acum (R1):** `frm_articol_gest_factura`
-  (`ofacturare.vc2:4094-4103`) face, sub `If Thisform.lRetur`, `poArticol.pretftva = pretv` — adica
-  **suprascrie pretul de vanzare cu pretul din stoc pe ORICE linie de retur** (verificat direct de
-  sesiunea principala). Corect pentru liniile **mostenite** dintr-o factura sursa; **gresit pentru
-  liniile libere** permise de decizia 22, care trebuie sa pastreze pretul din lista de preturi.
-  Raportul propune fixul.
-- **Distinctia „linie libera" vs. „linie mostenita" nu cere camp nou: `crsfactura.id_c = 0`.** Oracle nu
-  produce niciodata `id_c = 0` din `ROWNUM`, deci valoarea implicita e ea insasi semnalul. Vine din
-  mecanismul impus de S4e: liniile libere intra direct in `crsfactura` (`APPEND BLANK` + `combosql`),
-  **nu** in `crsarticole` — asa ca ajustarea din `do_sterge` (care pe retur urmareste maximul returnabil)
-  devine **no-op prin constructie**. Acelasi semnal dezactiveaza si suprascrierea de pret de mai sus.
-- **Gol nou (R7), pe care S4e nu-l are** (comanda si avizele n-au dialog de gestiune): azi se intra in
-  `do_alege_stoc` / `frm_articol_gest_factura` **doar** dintr-un `poArticol` scatter-uit din
-  `crsarticole`. O linie libera din `crsfactura` nu are asa ceva, iar decizia 22 cere ca gestiunea **sa
-  se aleaga**. Deci trebuie un **punct de intrare nou** in dialog. **Se unifica cu golul echivalent din
-  S4e** (validarea cantitatii, `do_verifica_articol`): e aceeasi problema structurala — dialogurile sunt
-  cuplate de `crsarticole` —, deci merita **o singura solutie**, nu doua.
-  **INCHIS prin decizia 44** (runda 13): `poArticol` devine **parametru explicit** si aici, nu variabila
-  `Private` populata de apelant — aceeasi solutie ca in S4e, cum cerea raportul.
-- **R4 e inchis** (verificare independenta): `scrie_corespondente_vanzari(3)` e gatata pe `ntip IN (8,9)`,
-  nu pe `listaid`.
-- **`VANZARI_CORESP` nu e afectata de liniile libere** — se scrie din `poDate.listaid`, fixat la antet.
-  **De confirmat (R4):** pentru `But_retur` ridicat la nivel de document, raspunsul pare a fi „fara
-  corespondenta persistata", pentru ca scrierea e gatata pe `ntip IN (8,9)`, nu pe `listaid`.
-
-*Gata cand:* un document de retur deschis in formularul unificat aduce liniile facturilor alese cu
-aceleasi valori ca azi — inclusiv gestiunea si pretul de achizitie —, permite stergere si cantitate
-partiala, iar pe o factura normala se poate face retur alegand facturile o singura data. **In plus: o
-linie libera pe un document de retur isi pastreaza pretul din lista de preturi**, adica nu trece prin
-suprascrierea de la `:4094-4103`. Pasii cu criterii verificabile sunt la sectiunea 9 a raportului; ce nu
-se poate testa headless, la sectiunea 11; riscurile R1-R6, la sectiunea 12.
-*Depinde de:* S2, S4e.
-
-#### S4g — Adaugarea de articole la modificarea oricarui document, inclusiv auto
-Decizia 18, proiectata in O si O-bis. **Nu se porneste de la zero:** „Alte servicii” din ROAAUTO
-face deja jumatate — articole reale langa linii sintetice, cu pret tastat, fara gestiune — doar ca
-traieste in formularul de emitere si moare odata cu el. Se generalizeaza in formularul unificat, ca
-a doua sursa din meniu („Alege din nomenclator…”), disponibila **si la modificare**, pe orice tip de
-document, nu doar pe cele auto.
-**Ordinea in care se lucreaza**, ca sa nu se blocheze tot: intai pe documentele ROAFACTURARE, unde
-scrierea e a noastra; abia apoi pe `tip = -12`.
-**Decizia 20 se aplica aici:** din nomenclator se ofera **si articole gestionabile, si
-negestionabile** — nu se copiaza filtrul `in_stoc = 0` al lui ROAAUTO.
-**Blocantul real e contul de venit, si el priveste doar ramura „Alege din nomenclator…”** (J-bis,
-J-ter). Contul de venit vine din `NOTE_CONTABILE.SCC` **prin politica de pret**; un articol fara
-`ID_POL` nu ajunge la cont gol, ci **la eroare** — `contabilizeaza_articol` ridica `FACT-024` si
-opreste tranzactia. Pe ramura „Cauta in lista de preturi…” nu se schimba nimic: acolo politica exista.
-**Premisa de la care pornea povestea asta a cazut:** „Alte servicii” din ROAAUTO **nu face deja
-jumatate** din treaba — acele linii ocolesc complet `contabilizeaza_articol`, printr-o cale de
-facturare paralela care nu genereaza nota de venit. Nu e un mecanism de generalizat, e o exceptie.
-**DECIS (decizia 27, care inlocuieste 24):** contul de venit se **deriva**, nu se ia prin politica —
-din `CORESP_CONT_VENCHELT` pentru articolele gestionabile (pe contul de gestiune al liniei), din
-`NOM_ARTICOLE.CONT` daca e 6xx / 7xx pentru cele negestionabile, altfel **704**. **Derivarea se face
-in VFP**, dar **transportul s-a schimbat la decizia 34**: contul calculat se trimite **direct, ca
-parametru nou al lui `contabilizeaza_articol`**. Ocolul prin `id_pol` cu nota potrivita — politica
-tehnica, interogarea inversa pe `SCC`, `pack_preturi.adauga_politica_pret_art` — e **abandonat**;
-J-quater punctul 3 se citeste doar ca trasabilitate. **Decizia 35** adauga ca acelasi drum serveste si
-editarea prin regenerare, deci nu se proiecteaza aici o a doua ruta de contare.
-~~**De decis in aceasta poveste, nu inainte:** ce se intampla cand linia are **si** politica, **si**
-cont trimis din VFP — cine castiga.~~ **PROIECTAT (runda 13) —
-`docs\cercetare\s4g_adaugare_articole_modificare.md`.** Intrebarile despre politica tehnica in ecranul
-de cautare a politicilor **au disparut** odata cu reteta.
-
-**Raspunsul: niciuna dintre cele trei variante pure — parametrul castiga, dar combinatia ambigua e
-oprita explicit, nu rezolvata tacit.**
-- **Combinatia nu poate aparea in fluxul normal, si asta e dovedit, nu presupus.** `crsfactura.id_pol`
-  e `N(20) Null` (`COMUN\programe\ofacturare_comun.prg`, `creeaza_facturacrs` — **verificat direct**),
-  deci la `APPEND BLANK` ramane `.NULL.`, si ajunge la Oracle ca literalul `NULL`
-  (`ofacturare.vc2:14072`). Cursorul de cautare din nomenclator **n-are deloc coloana `id_pol`**, deci
-  nu exista punct in care o linie „din nomenclator" sa-l poata popula.
-- **Singurul scenariu real de ambiguitate e regenerarea** (decizia 35): daca derivarea contului ar rula
-  **necondiționat** pe toate liniile documentului, si nu doar pe cele fara `id_pol`, o linie cu politica
-  reala ar primi si cont derivat. **E un risc de implementare VFP, nu Oracle** — dar proiectarea Oracle
-  nu trebuie sa-l faca invizibil.
-- **Deci: `cont_venit IS NOT NULL` intra pe ramura noua; daca in acel moment `id_pol` e si el populat,
-  se ridica eroare** (cod nou, distinct de `FACT-024`, care ramane pentru cazul „nici politica, nici
-  cont"). Variantele „politica castiga" si „fallback la `NO_DATA_FOUND`" au fost respinse motivat:
-  prima defineste castigatorul pe **prezenta** campului, nu pe rezolvarea lui, si ar reintroduce
-  `FACT-024` acolo unde VFP a oferit deja o solutie; a doua e semantic cea mai curata, dar cere
-  **restructurarea interna** a functiei (un flag propagat din `EXCEPTION` pana la punctul de decizie),
-  fata de un singur `IF` la intrarea in ramura deja proiectata. **Ambele ascund o eroare de date in loc
-  s-o semnaleze.**
-- **Regresie zero pe apelantii de azi**, prin constructie: cand `cont_venit` e `NULL` — adica toti
-  apelantii existenti, care nu cunosc parametrul —, executia intra direct pe `ELSE`, garda nu se
-  evalueaza niciodata, comportamentul e identic cu cel de azi.
-- **De ales de Marius:** numarul concret al codului de eroare nou (`FACT-0xx`).
-Separat, contul de **gestiune** e rezolvat ca regula (decizia 21): fallback, nu `NULL`, nu refuz.
-**`pack_auto` nu mai e blocant** — `PACK_AUTO` nu citeste `VANZARI` / `VANZARI_DETALII` deloc (O,
-intrebarea 1). Desincronizarea de afisare e **acceptata** (decizia 28); conditia e MANOPERA si
-MATERIALE conform devizului.
-**Blocantul netehnic a cazut si el:** gridul read-only din `frm_modific2024` e al lui #6, dar #13
-incepe dupa ce #6 se termina (decizia 30).
-**Restul proiectarii S4g, pe scurt** (detaliile in raport):
-- **Suprafata pe Oracle**: `contabilizeaza_articol` primeste contul prin `VANZARI_DETALII_TEMP%ROWTYPE`
-  (`cont_venit`), deci semnatura functiei ramane aceeasi — se extinde **tipul de rand**. Consecinta de
-  livrare: **DB inainte de EXE**.
-- **Derivarea in VFP** urmeaza fix decizia 27: `CORESP_CONT_VENCHELT` pentru gestionabile (pe contul de
-  gestiune al liniei), `NOM_ARTICOLE.CONT` daca e 6xx/7xx pentru negestionabile, altfel **704**. Ruleaza
-  **doar pe liniile fara `id_pol`** — vezi garda de mai sus; aici se leaga cele doua.
-- **Fluxul in formular** refoloseste exact mecanismul lui S4e: linia „din nomenclator" intra prin
-  `APPEND BLANK` + `combosql` **direct in `crsfactura`**, niciodata in `crsarticole`.
-- **Ramane deschis, mostenit din S4e:** validarea de cantitate/stoc pentru linia libera — se rezolva
-  prin decizia 44 (`poArticol` ca parametru explicit), aceeasi solutie pe ambele surse.
-- **De re-rulat inainte de implementare, nu de presupus incheiat:** cautarea apelantilor lui
-  `adauga_articol_factura` in restul suitei (ROAGEST, ROAAUTO, ROAACNPRO, ROAIMOB). Risc asteptat zero
-  — folosesc proceduri separate sau alt pachet —, dar cautarea **nu s-a terminat in nicio runda**.
-- **Trei hardcodari raman de confirmat de Marius, nu de presupus inofensive:** `CU_TVA = 1` (are efect
-  masurat prin `nproc_tva_max`, pe linie scutita + discount global), numele cheii de optiune de firma
-  pentru `SCD` (decizia 36) si domeniul ei `PROGRAME`, si trasabilitatea `CONT_VENIT` pe
-  `VANZARI_DETALII` (optionala pentru functionare, dar fara ea coloana nu se pastreaza dupa fapt).
-
-**Nota de executie (decizia 60):** pe documentele de tip **48/49** (custodie), „Alege din
-nomenclator…" ramane restrans la articole `IN_STOC = 0`, la fel ca ramura „Cauta in lista de
-preturi…" (S4) — decizia 20 (si articole gestionabile, si negestionabile) **nu se aplica** pe
-tipurile 48/49. Altfel se rupe invariantul pe care se sprijina siguranta regenerarii la editarea
-custodiei (decizia 60, `docs\cercetare\custodie_48_49_stergere_reemitere.md`).
-
-*Gata cand:* pe un document deja emis se poate adauga o linie noua, din lista de preturi sau din
-nomenclator, si documentul se salveaza consistent — pe fluxurile ROAFACTURARE, cu partea auto
-livrata separat, dupa (1). Pe un document 48/49, „Alege din nomenclator…" nu ofera si nu permite
-adaugarea unui articol cu `IN_STOC <> 0`.
-*Depinde de:* S4e, si de deciziile de mai sus. **Nu blocheaza etapa I.**
-
-#### S5 — Acoperirea tuturor tipurilor
-`frm_facturare_articole.Init` are 20 de ramuri pe `poDate.tip` (`:15107-15250`) care schimba titlul,
-capul coloanei de cantitate, mesajul de stoc, vizibilitatea discountului, prezenta seriei. Toate
-trebuie sa existe si in formularul unificat. Tipurile speciale raman pe calea lor:
-`tip = 27` (`frm_avizare_lucrare`), `tip = 30` (aviz din NIR, formular nevizibil).
-**PROIECTAT (runda 12) — `docs\cercetare\s5_acoperire_tipuri.md`. Povestea e mult mai mare decat
-„porteaza cele 20 de ramuri", si motivul e ca baza de pornire aleasa nu are aproape nimic de portat.**
-
-- **`Do Case`-ul de azi acopera 21 de valori de `tip`** (in 14 ramuri). **Patru tipuri reale,
-  reachable prin `factureaza()`, nu intra in niciun `Case`: `45` (factura restaurant), `48` / `49`
-  (custodie), `52` (contract, factura fiscala valuta)** — pierd titlu, cap de coloana, mesaj de stoc,
-  vizibilitatea discountului si eliminarea coloanei `cSerie`. **Nu doar `52`**, cum semnalase S4b.
-  Rutarea cursorului le recunoaste (`ofacturare.prg:271-282`); doar `Init` nu le-a „prins" niciodata.
-  **Nota de executie (decizia 60):** randul de configurare pentru `48`/`49` trebuie sa pastreze
-  restrictia la articole `IN_STOC = 0` mostenita de la sursa lor de azi (`cursor_articole_k`,
-  `PACK:3595-3701`, `:3695`) — vezi notele echivalente la S4 si S4g; e conditia de siguranta pentru
-  regenerarea la editarea custodiei (decizia 60,
-  `docs\cercetare\custodie_48_49_stergere_reemitere.md`).
-- **Cinci tipuri (`43,44,46,50,51`) nu ajung deloc la acest formular** — zero potriviri in tot arborele
-  `D:\ROA`. `50` e marcat „in lucru" in sursa. Se declara explicit ramase in afara.
-- **Descoperirea care schimba estimarea: prototipul nu e o versiune partiala a `Do Case`-ului — e
-  aproape gol.** `frm_facturare_articole2.Init` (`:18988-19080`) alege pe tip **doar** cuvantul
-  „factura"/„aviz", pe o lista mai scurta (lipseste `24`). Nu seteaza titlu (nu exista
-  `lb_titlu_alb_b121` in tot prototipul), nu schimba capul coloanei, nu schimba mesajul de stoc, nu
-  ascunde discountul, si **n-are deloc conceptul de coloana `cSerie`**. Daca formularul unificat porneste
-  de la prototip — cum decide S1 —, **toata diferentierea pe tip se reconstruieste de la zero**, nu se
-  completeaza. Asta e cel mai mare cost ascuns al etapei I descoperit pana acum.
-- **Rutarea cursorului diverge pe TREI tipuri, nu unul:** pe prototip, ramura de contract e
-  `Inlist(tnTip, 2, 26, 6)` (`ofacturare.prg:762`) fata de `Inlist(tnTip, 2, 26, 6, 52)` pe standard
-  (`:283`) — **verificat direct de sesiunea principala** —, iar ramura de retur omite `24`. Pe aceste
-  tipuri, prin prototip, `lcSqlCursor` ar ramane **nedefinit**: eroare, nu doar comportament diferit.
-- **Punctul lasat deschis de S4 punctul 2 se inchide aici:** tipurile **`26` si `52` n-au niciun
-  bookkeeping** `crsarticole` — nici Rol A, nici Rol B. Excluderea e totala, pe `Do Case` exhaustiv fara
-  ramura implicita, deci e „dovedit absent", nu „neconfirmat".
-- **`30` nu e un formular separat**, cum spunea planul: e **acelasi `frm_facturare_articole`**, trecut
-  prin acelasi `Init`, dar niciodata aratat (`ofacturare.prg:444-453` — calculeaza totalurile, apasa
-  programatic `but_termin1.Click()`, apoi `Release()`, fara `Show()`). Deci **e afectat de golurile din
-  `Do Case`** ca oricare alt tip; doar ca defectele nu se vad pe ecran. `27` chiar ramane pe calea lui.
-- **Alegerea de proiectare centrala, recomandata: tabel de configurare per tip**, un rand per `tip`, cu
-  exact proprietatile pe care le seteaza azi `Do Case`-ul (titlu, cap cantitate, mesaj stoc, discount
-  vizibil, are serie, tip doc, butoane, grup-sursa pentru meniul S4b). Motivul nu e estetic: **un
-  `Do Case` fara `Otherwise` nu semnaleaza niciodata un tip lipsa** — exact mecanismul care a lasat
-  patru tipuri pierdute ani la rand. Cu tabel, un tip necunoscut devine **eroare la deschidere**, iar
-  completitudinea se verifica **mecanic**, cu un `SELECT` fata de `tipuri_documente_facturare.md`, fara
-  sa porneasca formularul. Variantele „completeaza `Do Case`-ul" si „metoda per grup" au fost respinse
-  motivat: amandoua raman implicite, deci nu adauga detectie.
-- **DECIS — decizia 48 (Marius, runda 13): tabelul e un CURSOR GENERAT IN COD la pornire**, nu `DBF`
-  static (recomandarea raportului) si nu tabela pe Oracle. Ambele au fost puse pe masa cu argumentele
-  lor si respinse: `DBF`-ul adauga un fisier de intretinut, de livrat la fiecare update si de tinut
-  sincron intre produsele ROA; tabela Oracle ar cere script de migrare si o citire in plus la
-  deschiderea formularului. **Ce NU se pierde prin alegerea asta:** detectia ramane intacta — tip
-  necunoscut = **eroare la deschidere**, exact castigul pentru care exista propunerea —, iar proba
-  mecanica de completitudine ramane posibila, doar ca ruleaza **din aplicatie**, nu cu un `SELECT`
-  din afara. **Ce se accepta:** orice tip nou de document cere **recompilare si versiune noua de exe**,
-  ca azi. Forma concreta: un `.prg` cu `CREATE CURSOR` + `INSERT`-uri, un rand per tip, incarcat o
-  singura data si citit de `Init` prin `SEEK` pe `tip`.
-
-*Gata cand:* fiecare tip din `COMUN\docs\tipuri_documente_facturare.md` fie e acoperit, fie e
-declarat explicit ramas pe calea veche — **verificat prin proba mecanica de la sectiunea 8 a raportului**,
-nu prin citire. Include cele patru tipuri lipsa azi (`45,48,49,52`) si alinierea rutarii de cursor intre
-standard si prototip. Pe `48`/`49`, in plus: restrictia `IN_STOC = 0` mostenita ramane activa (decizia
-60) — nu se poate adauga un articol gestionabil.
-*Depinde de:* S4.
-
-#### S5b — Proforma si copierea pe formularul unificat
-Deciziile 10 si 11. Amandoua vin **aproape gratuit**, pentru ca folosesc deja acest drum: proforma e
-o valoare in combo-ul de tip document, copierea e `factureaza(tip, toFactura)` cu antetul
-precompletat. De facut, concret:
-- combo-ul `Ct_clb_fdoc` ramane in antetul unificat, cu realocarea de serie si numar la comutare;
-- garzile `eProforma = 0` de pe notele contabile si atasamente raman intacte, iar raportul propriu de
-  proforma continua sa fie ales;
-- copierea deschide formularul in starea „document nou”, cu antetul editabil (comportamentul de azi);
-- **degradarea de tip din `do_copiaza` ramane pentru copiere si nu se aplica la regenerare** (D) —
-  sunt doua moduri distincte ale aceluiasi formular, nu acelasi comportament.
-*Gata cand:* o proforma emisa din formularul unificat nu produce nota contabila si se listeaza pe
-raportul ei; o copie produce un document nou cu numar nou si acelasi continut.
-**VERIFICAT (runda 9) — `docs\cercetare\s5b_proforma_descarcare_gestiune.md`. Verificarea 4 e inchisa.**
-**NU, gestiunea nu se descarca pe proforma** — pentru niciun articol, indiferent daca e gestionabil in
-nomenclator. Si nu e un efect colateral al ascunderii stocului, e **prin design**: VFP marcheaza toate
-liniile proformei negestionabile inainte de compunerea documentului, ceea ce le trimite cu sentinela
-`id_gestiune = -1000`, iar pe Oracle `contabilizeaza_articol` sare apelul catre `descarca_gestiune`
-exact pe acest sentinel. Intentia e explicita in changelog (12.03.2021 / 2.7.x): *„Articolele din
-proforma sunt marcate 'negestionabile', astfel incat nu mai este necesara existenta articolelor in stoc
-pentru a genera proforma."* — deci cerinta a fost „proforma trebuie sa mearga si fara stoc", nu „nu arata
-plafonul". **Se corecteaza presupunerea din plan** ca zeroizarea `gestionabil` ar fi doar cosmetica.
-Consecinta pentru S5b: sentinela `-1000` e contractul care trebuie pastrat — vezi sectiunile 6 si 7 ale
-raportului pentru constrangerile de proiectare si ce lipseste la copiere.
-
-**PROIECTAT (runda 12) — `docs\cercetare\s5b_proiectare_proforma_copiere.md`. „Aproape gratuit" nu mai
-tine: proiectarea a scos la iveala un risc de date care nu era semnalat nicaieri.**
-
-- **Mecanismul real care tine proforma curata nu e sentinela, ci routing-ul.** In `do_scrie_factura`
-  (`ofacturare.vc2:14282-14300`), `eProforma = 1` alege `scrie_proforma`, care **nu cheama niciodata**
-  `contabilizeaza_articol` — comentariul din cod o spune direct: *„salveaza doar in vanzari, nu si in
-  contabilitate"* (verificat de sesiunea principala). Sentinela `-1000` e al doilea strat, nu primul.
-- **RISCUL CENTRAL — „drumul invers", nesemnalat pana acum si cu consecinta pe date.** Operatorul
-  adauga linii cu documentul pe **Proforma** (deci marcate `gestionabil = 0` / `id_gestiune = -1000`),
-  apoi comuta combo-ul inapoi pe **Factura** inainte de „Termina". Atunci routing-ul alege
-  `scrie_factura2`, care **chiar** cheama `contabilizeaza_articol` — dar acesta sare `descarca_gestiune`
-  exact pe sentinela `-1000` (`PACK:7472-7476`). Rezultatul: **o factura reala iese cu stocul
-  nedescarcat, silentios** — `-1000` e o valoare valida, nu ridica nicio exceptie. **Azi nu exista
-  nicio plasa pentru acest caz**, si nici nu putea exista: combo-ul traieste in dialogul separat
-  `frm_date_factura`, inchis **inainte** sa existe vreo linie. Riscul se naste **din unificare**.
-- **De aici si de ce marcarea negestionabila nu mai poate fi un singur `UPDATE` de masa:** in
-  formularul unificat trebuie extrasa intr-o metoda refolosita din **trei** puncte — la incarcare, la
-  adaugarea unei linii, si la comutarea tipului cu linii deja prezente.
-- **`id_c` la copiere: SIGUR, cu dovada.** `do_copiaza` degradeaza tipul spre grupul-tinta
-  **`{1,5,7,10,22,23}`**, care nu intra niciodata in ramurile Rol A din `do_scrie_factura` / `do_sterge`.
-  Coliziunea tehnica exista in date, dar **n-are efect observabil**. (Intrebarea venea din corectia lui
-  S4e — vezi acolo.)
-  > **CORECTIE (runda 13, verificata direct pe cod).** Grupul-tinta scris pana acum in plan
-  > (`{1,5,10,22}`) era **gresit**, si la fel era si `{1,5,7,10}` din raportul S5c. Setul real e cel de
-  > mai sus, citit din primul `CASE` al lui `frm_facturi.do_copiaza`
-  > (`COMUN\clase\ofacturare_comun.vc2:3693-3694`), care lasa neatinse exact `T1,T5,T7,T10,T22,T23`.
-  > Concluzia „copierea e sigura" **nu se schimba** — `7` si `23` nu au bookkeeping Rol A —, dar cifrele
-  > se corecteaza peste tot unde apar. Aceeasi corectie se aplica lui
-  > `s5b_proiectare_proforma_copiere.md` §2.1 / §7.
-- **DEFECT PREEXISTENT, gasit in trecere la verificarea de mai sus — de raportat, NU de reparat acum.**
-  In `frm_facturi.do_copiaza`, ramura de avize scrie `lnTip = T22`
-  (`COMUN\clase\ofacturare_comun.vc2:3703`) in loc de `loFactura.tip = T22` — **singura ramura din tot
-  `Do Case`-ul care nu atribuie in obiect**; toate celelalte cinci scriu `loFactura.tip`. Consecinta:
-  la copierea unui aviz (`21,24,26,30,-7,-9,-10,-13,28,29,42`) **degradarea nu se produce**, iar
-  `copiere_factura` cheama `factureaza(toFactura.Tip, ...)`
-  (`COMUN\programe\oproceduri_facturare.prg:150-152`) cu tipul **original** — deci copia unui „aviz pe
-  baza de comanda" reintra pe ruta de comanda, nu pe cea de lista de preturi. **Verificat ca `factureaza`
-  nu citeste un `lnTip` privat** (`ofacturare.prg:101` declara `lnTipTemp`, nu `lnTip`), deci
-  atribuirea chiar se pierde; in plus `lnTip` e nedeclarat in metoda, deci poate suprascrie un `lnTip`
-  al apelantului. **Fisierul e in perimetrul interzis (#6) — se raporteaza, nu se atinge.**
-
-**VERIFICAT (runda 12, la cererea lui Marius) — `docs\cercetare\verif_proforma_alegere_stoc.md`.
-Pe proforma NU se alege stoc azi, si asta e deliberat.**
-
-- **Un singur mecanism activ, si e in VFP, la incarcare:** `ofacturare.prg:333-336` face
-  `UPDATE (lcCursor) SET gestionabil = 0` cand `eProforma = 1`, **inainte** sa se deschida gridul.
-  Comentariul din cod spune intentia direct: *„Daca este o proforma, consider toate articolele
-  negestionabile, **pentru a nu mai alege din stoc**"* (12.03.2021). Deci `Do Case`-ul de la
-  `ofacturare.vc2:13803` vede mereu `gestionabil = 0` → **`do_alege_stoc` nu ruleaza niciodata**.
-  Valabil pe **toate** cursoarele de creare directa a unei proforme; **niciunul** n-are parametru
-  `V_PROFORMA` (verificat pe ~9 proceduri `cursor_` din pachet).
-- **Mecanismul Oracle exista, dar e mort in fluxul curent:** `cursor_retur_document` (`PACK:3993-4000`)
-  are `CASE V_PROFORMA = 1 THEN 0`, insa se cheama doar la **copiere**, unde `V_PROFORMA` trimis e
-  `eProforma` al documentului **nou** — mereu `0`. **Nu e o contradictie intre rapoarte**: sunt doua
-  mecanisme reale, doar unul activ.
-- **`pret_achizitie` depinde de sursa:** pe calea principala (lista de preturi) ramane `0` —
-  `cursor_preturi` nici nu-l selecteaza. Pe surse care carata un document existent (avize, copiere)
-  vine real din `VANZARI_DETALII.PRET_ACHIZITIE`.
-- **Daca liniile ar pastra gestiunea reala pana la salvare, nu s-ar strica nimic pe contabilizare sau
-  stoc:** `adauga_articol_factura` se cheama oricum si pentru proforma, dar `scrie_proforma` **nu**
-  cheama `contabilizeaza_articol`, deci `descarca_gestiune` tot n-ar rula; iar **`do_alege_stoc` nu
-  rezerva stoc** (doar `SELECT` + scadere locala in memorie, zero scriere Oracle). Singurul loc unde
-  s-ar vedea o diferenta e la **relistare** (`crsDetaliiListare` / `fact_vfacturi2` citesc
-  `id_gestiune` fara filtru pe `eproforma`) — **neconfirmat** daca vreun raport chiar il tipareste.
-
-**Consecinta care schimba forma deciziei: cele doua sensuri nu sunt simetrice.**
-- **FACTURA → PROFORMA cu linii deja adaugate:** liniile au trecut deja prin `do_alege_stoc`, deci au
-  gestiune reala si pret de achizitie corect. **E sigur, si sentinela se poate aplica abia la salvare**
-  — exact varianta ceruta de Marius. **Fara atentionare.**
-- **PROFORMA → FACTURA cu linii deja adaugate:** liniile au fost adaugate **fara** alegere de stoc
-  (`gestionabil` fortat `0`), deci **nu au gestiune**. Aici e riscul „drumului invers".
-- **A forta alegerea stocului si pe proforma NU e o optiune** — ar regresa cerinta din 12.03.2021
-  (*„nu mai este necesara existenta articolelor in stoc pentru a genera proforma"*): un articol fara
-  stoc n-ar mai putea intra pe proforma, pentru ca `do_alege_stoc` ar cere un lot inexistent.
-
-### Decizia 43 (Marius, runda 12) — proforma NU alege stoc, si factura se face DIN proforma
-
-**Pe proforma nu se alege stoc, si asta e cerinta, nu efect colateral.** Motivul, in cuvintele lui
-Marius: *„sa dau o proforma chiar si in absenta stocului, pentru ca ma intereseaza doar pretul de
-vanzare, nu si cel de achizitie din stoc"*. Deci:
-- **Varianta (b) — realegerea gestiunii linie cu linie la comutare — e RESPINSA.** Nu se mai
-  reargumenteaza.
-- **Comutarea PROFORMA → FACTURA cu linii prezente se blocheaza**, cu mesaj explicit. Comportamentul de
-  azi (`gestionabil = 0` fortat la incarcare, `ofacturare.prg:333-336`) se **pastreaza**, nu se rafineaza.
-- **Sensul FACTURA → PROFORMA ramane liber**, fara atentionare, cu sentinela aplicata **la salvare** —
-  liniile au deja gestiune reala, deci nu se pierde nimic.
-
-**Cerinta noua: „ulterior o sa vreau si o factura din proforma".** Nu prin comutarea tipului pe acelasi
-document, ci ca **document nou**, generat din proforma. **Mecanismul pare sa existe deja pe calea de
-copiere** — `cursor_retur_document` reface gestionabilitatea reala cand `V_COPIERE = 1`
-(`GESTIONABIL = B.IN_STOC`, `PACK:3993-4000`), deci liniile venite dintr-o proforma **redevin
-gestionabile**, trec prin `do_alege_stoc` la adaugare, primesc `id_gestiune` real si descarca gestiune
-normal (`docs\cercetare\s5b_proiectare_proforma_copiere.md` §2.6). **De verificat inainte de a te baza
-pe asta**, pentru ca §2.6 descria copierea in general, nu cazul „sursa e o proforma":
-1. poate fi azi o **proforma** aleasa ca sursa de copiere, sau e exclusa undeva?
-2. `do_copiaza` degradeaza tipul spre `{1,5,10,22}` — ce tip rezulta dintr-o proforma si e cel dorit?
-3. ~~se pastreaza legatura proforma → factura?~~ **RASPUNS (Marius, runda 12): DA — „ar fi bine sa aiba
-   urma sursei, la fel ca factura din aviz".** Deci trasabilitatea **e ceruta**, si tiparul de urmat e
-   cel deja existent pentru aviz → factura: `scrie_corespondente_vanzari(1)`, chemata din
-   `finalizeaza_factura`, care scrie in **`VANZARI_CORESP`** perechea
-   `(ID_VANZARE_FACT = factura, ID_VANZARE_AVIZ = documentul sursa, TIP = 1)`. Numele coloanei e generic,
-   deja reutilizat pentru mai multe feluri de perechi (`TIP = 1/2` aviz-factura, `TIP = 3` retur), deci
-   **structura nu se schimba — se adauga o valoare noua de `TIP`** pentru proforma → factura.
-   **De proiectat, nu de presupus:** ce valoare de `TIP` se aloca; de unde stie fluxul de copiere ca
-   sursa a fost o proforma (azi `do_copiaza` degradeaza tipul, deci informatia s-ar putea pierde
-   **inainte** de scriere — vezi punctul 2); si daca `marcheaza_facturat` / `FACTURAT` trebuie sau nu
-   atinse (pe aviz sunt, pe proforma probabil **nu**, pentru ca proforma nu e un document de livrare —
-   **de confirmat, e exact genul de detaliu care se copiaza gresit din tiparul avizului**).
-~~**Aceasta e prima sarcina de proiectare a rundei 13.**~~ **LIVRATA — vezi S5c mai jos.**
-
-*Depinde de:* S5.
-
-#### S5c — Factura din proforma (decizia 43, cerinta noua)
-**PROIECTAT (runda 13) — `docs\cercetare\s5c_factura_din_proforma.md`. Toate cele trei intrebari si
-ambele capcane au raspuns cu dovada. Vestea buna: mecanismul de baza chiar exista, si nu se atinge.**
-
-- **(a) O proforma poate fi azi aleasa ca sursa de copiere, fara nicio excludere.** `IsCopy` returneaza
-  **necondiționat `.T.`** (`COMUN\clase\ofacturare_comun.vc2:4969`, cu comentariul explicit *„POT SA
-  COPIEZ ORICE, TRATEZ TIPURILE IN DO_COPIAZA"*; filtrul vechi pe tip e comentat dedesubt, la `:4971`) —
-  **verificat direct**. Nici vizibilitatea butonului, nici filtrul de grid „Facturi&Avize / Proforme" nu
-  se uita la `eproforma`. Deci nu e nimic de deblocat.
-- **(b) Tipul rezultat e corect, fara schimbare.** Copierea produce un document real
-  (`nIdTipDoc = 5`, `eproforma = 0`) — factura fiscala, exact ce trebuie. Degradarea lasa neatins
-  grupul-tinta **`{1,5,7,10,22,23}`** (vezi corectia de cifre de mai sus).
-- **(c) `TIP = 4` e liber in `VANZARI_CORESP`** si se aloca pentru „factura din proforma". Confirmat
-  **cod + date** pe schema vie: tabela are un **singur scriitor in toata baza**
-  (`pack_facturare.scrie_corespondente_vanzari`), iar azi se folosesc doar `1/2/3`. **Structura nu se
-  schimba.**
-- **Capcana (i) — confirmata, si e miezul poveștii.** `id_vanzare` al proformei **supravietuieste**
-  copierii (prin `poDate.listaid`), dar faptul ca **sursa era o proforma se pierde**:
-  `completeaza_setari_document` copiaza `.listaid`, dar **nu** si `eproforma`
-  (`COMUN\programe\ofacturare_comun.prg:387` — **verificat direct: `eproforma` nu apare nicaieri in tot
-  fisierul**). De aceea legatura **nu se poate agata de `CASE`-ul din `finalizeaza_factura`**, care e
-  cheiat pe `ntip` — `ntip` nu poarta distinctia. Solutia: un semnal nou, client-side
-  (`poDate.lProformaSursa`), capturat exact acolo unde informatia mai exista, plus un **apel Oracle
-  explicit separat** care reutilizeaza `scrie_corespondente_vanzari(4)` **neschimbata**. Zero cod PL/SQL
-  nou pe calea recomandata.
-- **Capcana (ii) — INFIRMATA presupunerea comoda, cu patru argumente: `marcheaza_facturat` NU se cheama
-  pe proforma.** Proforma n-are `VANZARI_CANTITATI`, n-are ramura de reversare la stergere in
-  `sterge_factura`, nimic nu filtreaza dupa `FACTURAT` pe proforme, si oricum calea aleasa e in afara
-  `CASE`-ului care il cupleaza azi. Era exact detaliul care se copia gresit din tiparul avizului.
-
-**Ce NU se schimba:** `IsCopy`, vizibilitatea butonului de copiere, filtrul de grid, degradarea de tip
-din `do_copiaza`, `cursor_retur_document` (`GESTIONABIL = B.IN_STOC`), si `scrie_corespondente_vanzari`
-insasi.
-
-**INCHISE, nu de reintrebat (marcaj pus in runda 17).** Cele cinci puncte de mai jos au primit raspuns: punctul 1 (`TIP = 4`) prin **decizia 51**, restul in bloc prin **decizia 56** („da la toate"). Lista ramane ca **inventar al recomandarilor acceptate**, ca sa se stie ce s-a decis si de ce — nu ca intrebari:
-1. **`TIP = 4`** — liber azi, dar alocarea e **ireversibila in date** odata intrata in productie. De
-   confirmat explicit, nu tacit.
-2. **Apel pe starea de sesiune a pachetului (`clistaid` / `nid_vanzare`) vs. procedura noua cu
-   parametri expliciti.** *Recomandarea raportului:* varianta simpla (zero cod Oracle nou), **cu
-   conditia** verificata la implementare ca niciun apel Oracle intercalat nu reseteaza starea intre
-   scrierea facturii si scrierea corespondentei.
-3. **Aceeasi proforma poate fi copiata de N ori**, fiecare copie cu randul ei `TIP = 4`. E comportamentul
-   implicit al oricarei copieri de azi. *Recomandare:* daca deranjeaza, avertisment — **nu** blocare.
-4. **Garda simetrica la stergere** (*„nu poti sterge o proforma care are deja factura generata din ea"*),
-   pe tiparul `TIP IN (1,2,3)` din `sterge_factura` — de decis daca se doreste.
-5. **Afisarea „provine din proforma X"** pe factura noua — vine gratis din legatura scrisa, la nivel de
-   **document** (ca la retur), nu de linie. De decis daca intra acum sau mai tarziu.
-
-*Gata cand:* dintr-o proforma emisa se genereaza o factura reala, cu numar nou, care descarca gestiunea
-normal, are rand `TIP = 4` in `VANZARI_CORESP` catre proforma sursa, iar proforma **nu** e marcata
-`FACTURAT`.
-*Depinde de:* S5b.
-
-### Decizia 49 (Marius, runda 13) — cele doua formulare merg IN PARALEL, si ALEGE UTILIZATORUL
-
-**Cerinta, in cuvintele lui Marius:** *„utilizatorul sa poata accesa alternativ, daca doreste"*. Deci
-**nu** o setare care ruteaza tacit pe un flux sau altul, si **nu** un pilot pe cativa oameni: ambele
-formulare raman accesibile, iar **alegerea o face omul, in momentul in care factureaza**. Rostul e sa
-existe mereu **un flux despre care se stie ca functioneaza**, cat timp cel nou se stabilizeaza.
-
-> **Corectie a rundei 13:** prima formulare a acestei decizii descria un pilot per utilizator, prin
-> optiunea de firma. **Gresit** — Marius a corectat: optiunea **nu alege**, ci doar **face alegerea
-> disponibila**. Nu se reargumenteaza in varianta veche.
-
-**Mecanismul exista deja in produs si face exact asta**, nu se inventeaza:
-- `factureaza` (`COMUN\programe\ofacturare.prg:87-93`) verifica `gnFacturareNou` si, cand e pornita,
-  **intreaba la fiecare facturare**: `AMESSAGEBOX('Facturare noua (DA) sau standard (NU)?', 4+32, ...)`.
-  Optiunea deschide alegerea; raspunsul il da utilizatorul, de fiecare data.
-- `gnFacturareNou` e o **optiune de firma**: `optiuni_firma` (`COMUN\programe\oinit_optiuni.prg:225-275`)
-  cheama `SCRIE_OPTIUNI(gcUserName)`, parcurge `v_optiuni` si **declara dinamic** globalele publice dupa
-  tip (`Public gn&lcvarname` pentru `NUMERIC`), cu filtru optional pe program
-  (`Isnull(programe) Or gcNumeProgram $ programe`). **Deci se activeaza si se dezactiveaza din date,
-  fara livrare de exe.**
-- **Fluxul vechi ramane intreg:** `factureaza` + `frm_facturare_articole`. S2 sterge doar
-  **`factureaza2`**, un fork mort din 2017 (executia interogarii dezactivata, `lnSucces = 1` hardcodat,
-  zero utilizatori reali) — **nu** calea veche. **S2 nu are voie sa desfiinteze alegerea.**
-- **Pentru etapa II plasa e alta, si exista deja:** editarea prin regenerare e o **actiune noua**, deci
-  „fluxul vechi" pentru ea e **fluxul lui #6**, pe care decizia 38 il pastreaza oricum.
-
-**Cum se prezinta alegerea — de ales la implementare, ambele satisfac cerinta:**
-- **(A) intrebarea de azi**, modal la fiecare facturare. Exista deja, zero cod. Neajuns: intreaba si
-  cand utilizatorul stie de o luna ce vrea.
-- **(B) doua intrari distincte** in meniu / doua butoane („Facturare" si „Facturare (nou)"). Aceeasi
-  libertate, fara modal la fiecare document. **Recomandat.** Se poate porni cu (A), care e gata, si trece
-  la (B).
-
-**Limita, si trebuie spusa explicit ca sa nu creeze o falsa siguranta: alegerea acopera VFP-ul, nu
-Oracle.** Modificarile din pachete — parametrul nou al lui `contabilizeaza_articol` (decizia 34),
-variabila noua din `SET_IDFACT`, si `INSERT` → `MERGE` in `DOCUMENTE` (S9) — sunt **cod comun al
-intregii suite** si se aplica **tuturor deodata**, indiferent pe ce formular alege omul sa lucreze.
-Proiectarea le face **inerte prin constructie** (parametru `NULL` → executie identica cu azi;
-`WHEN MATCHED` care nu se declanseaza pe drumul normal), dar asta e o garantie de regresie zero,
-**nu** o cale de intoarcere. Consecinta practica: pe formular si procedura intoarcerea e imediata; pe
-baza de date, siguranta vine din **testarea unui ciclu normal de scriere in fiecare produs** (deja
-ceruta in S9).
-
-### Decizia 50 (Marius, runda 13) — se editeaza documente curente, nu documente dintr-un lant
-
-**Formularea lui Marius:** *„in principiu nu se poate edita un document pentru care s-a facut retur;
-de principiu se pot modifica documente curente, nu cele care fac parte dintr-un lant"*.
-
-**Deci garda de azi ramane, si devine regula declarata, nu limitare tolerata.** `sterge_factura` arunca
-`ORA-20000` cand documentul are deja facturi / avize de retur emise peste el; S7 **semnaleaza conditia
-inainte de intrarea in formular**, cu mesaj clar, nu ca eroare Oracle la final. Utilizatorul care chiar
-vrea sa editeze sterge intai documentele-copil — comportament existent, nu ceva de construit.
-
-**PRECIZAT de Marius (runda 13), si inchide punctul: „lantul" se citeste IN AMONTE, nu in ambele
-sensuri.** In cuvintele lui: *„daca este generata factura din aviz, avizul nu se mai poate modifica,
-factura da, pentru ca este documentul curent; ma refeream la documentele din lant anterioare"*.
-
-Deci regula, in forma finala:
-- **Documentul care are urmasi se blocheaza** — avizul din care s-a facut factura, factura peste care
-  s-a emis retur. Are deja o reprezentare in cod: garda din `sterge_factura`.
-- **Documentul de la capatul lantului ramane editabil** — el e „documentul curent". **Factura din aviz
-  (`ntip = 4`) ESTE editabila**, chiar daca are parinte.
-- Prin urmare **perimetrul etapei II nu se restrange**, iar intrebarea deschisa din S10 despre `ntip = 4`
-  (aceeasi re-derivare tacuta ca pe contract, dar cu alta sursa de comparat) **ramane in picioare** — nu
-  dispare, cum s-ar fi intamplat la citirea stricta.
-
-**VERIFICAT in runda 14 — si premisa era gresita.** Raport: `docs\cercetare\garda_aviz_facturat.md`.
-Se credea ca garda de azi blocheaza documentul doar cand are **retururi** peste el. **Nu e asa:** a doua
-garda din `sterge_factura` testeaza `TIP IN (1, 2)`, iar **`TIP = 1` este corespondenta aviz → factura
-normala, nu retur** (`EXPORT:5464-5476`, semantica citita ramura cu ramura din `CASE`-ul lui
-`finalizeaza_factura`, `EXPORT:14818-14839`). Formularea gresita venea din citirea comentariului
-`-- verific daca exista facturi sau avize de retur`, in care „de retur" se distribuia si peste „facturi";
-codul zice altceva. **Deci regula ceruta de decizia 50 e deja implementata pentru avize** — nu e nevoie de
-nicio garda noua ca *regula*.
-
-**Dar sunt trei garzi, nu doua, si a treia schimba enuntul deciziei 50:**
-
-| garda | `EXPORT` | ce blocheaza |
-|---|---|---|
-| 1 | 5452-5462 | **factura** care are facturi de retur peste ea (`TIP = 3`) |
-| 2 | 5466-5476 | **aviz** care are factura (`TIP = 1`) sau aviz de retur (`TIP = 2`) peste el |
-| 3 | 5480-5494 | **factura din aviz** ale carei avize-sursa au primit intre timp aviz de retur |
-
-Prin urmare **„factura din aviz ESTE editabila" nu e neconditionat**: e editabila doar cat timp niciunul
-dintre avizele ei nu a primit aviz de retur. Nu e „capat de lant" prin definitie.
-
-**Ce lipseste nu e regula, e MOMENTUL.** Garda traieste in interiorul lui `sterge_factura`, deci se
-manifesta ca `ORA-20000` **in mijlocul** pasului de stergere din regenerare — dupa ce utilizatorul a
-completat formularul si dupa deschiderea tranzactiei. S7 are nevoie de un **pre-flight read-only** pe
-**exact aceeasi conditie**, fara reimplementarea regulii (vezi S7). Interogarea se face pe
-`VANZARI_CORESP`, **nu** pe `VANZARI.FACTURAT`: `FACTURAT` e un marcaj derivat, scris si resetat, dar
-**necitit de nicio garda** — semnalul autoritar e `VANZARI_CORESP`.
-
-**GOLUL REAL NU E PE AVIZ, E PE PROFORMA — si a devenit relevant chiar in runda 14, odata cu decizia 51.**
-`pack_facturare.sterge_proforma` (`EXPORT:5610-5635`) **nu are nicio garda**: corpul ei e doua
-`UPDATE ... SET STERS = 1`. E o procedura **complet separata**, care nu cheama `sterge_factura`, deci
-garda existenta **nu se extinde automat** la `TIP = 4`. O proforma din care s-a emis factura se poate
-sterge azi fara niciun avertisment. Calea VFP iese devreme din `do_sterge`
-(`ofacturare_comun.vc2:4707-4719`), inainte de restul verificarilor. **Asta e continutul concret al
-punctului deschis 4 din S5c** („garda simetrica la stergere") — nu mai e o intrebare de principiu, e o
-garda de scris intr-o procedura care azi n-are niciuna.
-
-**Comanda si contractul nu trec prin `VANZARI_CORESP`** si n-au garda de tip „are urmasi" pe factura:
-comanda se leaga prin `VANZARI.ID_COMANDA` + `inchide_comanda`, iar garda ei e **in VFP si pe comanda**,
-nu pe factura (`COMUN\clase\ocomenzi.vc2:1806-1807` la modificare, `:2065-2066` la stergere); contractul
-se leaga prin `VANZARI.ID_CTR` + `CTR_RATE_FACTURI`.
-
-### Deciziile lui Marius, runda 13 (10.08.2026) — luate, nu de reluat
-
-Cele cinci puncte neblocante ramase din runda 12. **Patru din cinci au mers pe recomandare; al
-cincilea (48) a respins-o motivat.** Fiecare e scrisa si la locul ei, in povestea careia ii apartine.
-
-44. **`poArticol` devine parametru explicit** al dialogurilor de linie (`do_verifica_articol`,
-    `do_alege_stoc` / `frm_articol_gest_factura`), in loc de variabila `Private` populata de apelant.
-    **O singura solutie pentru golul din S4e si cel din S4f (R7)** — e aceeasi problema structurala.
-    Schimbare de contract, **aprobata ca atare**; cere inventarul si actualizarea tuturor apelantilor
-    existenti inainte de prima editare. (S4e, S4f)
-45. **Asimetria din `do_modifica`** se lasa sa se **corecteze de la sine** prin recalculul la cerere,
-    dar corectia se **declara explicit in changelog**. (S4, punctul 2)
-46. **Corectia pe tipurile `23,41` asteapta punctul 2** (recalculul pe server, care acopera Rolul B).
-    Punctul 1 **nu se redeschide** acum. (S4, punctul 2)
-47. **`zi_curs`: simetrie.** Campul se ascunde la loc la stergerea ultimului articol in valuta;
-    „clipitul" e acceptat ca pret al unei reguli unice. (S4d)
-48. **Tabelul de configurare per tip = cursor generat in cod la pornire**, nu `DBF` static, nu tabela
-    Oracle. Detectia tipului necunoscut (eroare la deschidere) se pastreaza; se accepta recompilarea
-    la orice tip nou. (S5)
-
-### Deciziile lui Marius, runda 14 (11.08.2026) — luate, nu de reluat
-
-51. **`TIP = 4` in `VANZARI_CORESP` = „factura scrisa dintr-o proforma".** Confirmat explicit, dupa ce
-    i s-a explicat ce inseamna `1/2/3` (`TIP` = **natura legaturii parinte-copil**, nu tipul
-    documentului: `1` = aviz → factura, `2` = aviz → aviz de retur, `3` = factura → factura de retur).
-    `4` intra in aceeasi familie cu `1`. Valoarea e libera pe ambele fronturi (niciun apel cu `4` in
-    pachet, zero randuri in date), tabela are un singur scriitor in toata suita, structura nu se
-    schimba. **Alocarea e ireversibila odata cu primele date de productie** — acceptat ca atare. (S5c)
-52. **`do_modifica` ramane activ pentru multi-selectie.** Formularul unificat preia cazul cu un singur
-    document; calea veche ramane pentru modificarea in bloc. **Nicio capacitate nu se pierde la
-    retragere** — dar consecinta e ca S2 nu poate desfiinta nici aceasta ruta, nu doar alegerea de la
-    decizia 49. (S8b, punctul 10)
-53. **Atasamentul PDF se sterge la reemitere**, nu se remigreaza si nu se marcheaza „versiune
-    inlocuita". Documentul reemis porneste curat; PDF-ul se regenereaza la prima listare. **Consecinta
-    semnalata explicit lui Marius si acceptata de el:** urma a ceea ce s-a trimis efectiv clientului
-    dispare din sistem. Pasul `UPDATE ATASAMENTE_VANZARI SET id_vanzare = :nou`, adaugat in S9 la runda
-    13, **se inlocuieste cu stergere**. (S11, punctul 15)
-54. **La reemitere se scriu valorile din formular, nu se reciteste sursa.** Formularea lui Marius:
-    *„nu inteleg de ce se schimba valorile fata de ce se incarca din factura sursa care se modifica?
-    asta este comportamentul pe care il doresc — modific sursa"*. **Asta rastoarna S10:** intrebarea nu
-    mai e „ce garda punem peste re-derivare", ci **„re-derivarea chiar se produce pe calea de
-    reemitere?"** — si daca da, se **elimina**, nu se avertizeaza. Avertizarea + confirmarea propuse de
-    raportul S10 sunt **respinse**: nu se cere utilizatorului sa confirme o schimbare pe care n-a
-    cerut-o. Vezi S10, rescris. (S10, punctele 11 si 12)
-56. **„DA LA TOATE" — Marius a acceptat in bloc toate recomandarile deschise, runda 14.** Formularea
-    lui: *„da la toate, mai putin"* cele doua puncte pe care le-a intrebat separat (48/49 si voiajele).
-    **Nu se mai reintreaba niciunul dintre punctele de mai jos** — sunt luate, si fiecare e scris si la
-    locul lui, in povestea careia ii apartine:
-    - **S8** — canalul de citire a liniilor: **(B), procedura noua `cursor_editare_document`** (nu se
-      extinde `cursor_retur_document`, ca sa nu se schimbe comportamentul copierii; nu
-      `FACT_VFACTURI_DETALII`, care pierde `ID_POL`, `PRETD` si tratamentul valutar — argument intarit
-      de faptul ca **`VVANZARI_ARTICOLE` nu expune `ID_POL` / `ID_CTR`**, vezi S10).
-    - **S8** — `GESTIONABIL` la editare: **din document**, nu din nomenclatorul curent.
-    - **S8** — `text_aditional`: **se normalizeaza la incarcare** (`Chr(170)` → `CR+LF`) si se
-      re-normalizeaza la comparatie. Formele diferite salvate de cele doua rute de scriere se
-      **semnaleaza separat** ca defect preexistent.
-    - **S8** — `zi_curs` pe calea de editare: **ascuns** (precedent: tipurile 8/9). Abatere mica de la
-      decizia 5, asumata.
-    - **S8** — `poDate.lEditare`: **proprietate pe `oDateFactura`**, nu parametru (patru locuri au
-      nevoie de semnal; `lCopiere` e deja acolo cu acelasi rol).
-    - **S8** — `id_ruta`: **proprietate noua pe `oDateFactura`** (fara ea S8c nu poate implementa unul
-      din cei 14 parametri).
-    - **S8** — defectul de prefixare `text_aditional` la `Init` pentru contracte: **se ocoleste in #13**
-      prin `lEditare` si **se semnaleaza separat**, nu se repara pe calea de emitere.
-    - **S5c** — apelul Oracle pentru legatura proforma → factura: **varianta simpla**, pe starea de
-      sesiune a pachetului, zero cod PL/SQL nou — **cu conditia verificata la implementare** ca niciun
-      apel intercalat nu reseteaza starea intre scrierea facturii si scrierea corespondentei.
-    - **S5c** — aceeasi proforma facturata de N ori: **avertisment, nu blocare**.
-    - **S5c** — garda simetrica la stergerea proformei: **se scrie**. Nu e reutilizare —
-      `sterge_proforma` n-are azi nicio garda (vezi decizia 50, sectiunea rescrisa).
-    - **S5c** — afisarea „provine din proforma X": **da**, la nivel de document.
-    - **S4g** — `CU_TVA = 1` hardcodat: **se verifica pe date inainte de implementare**, nu se
-      presupune inofensiv. Efectul prin `nproc_tva_max` e masurat, pe linie scutita + discount global.
-    - **S4g** — trasabilitatea `CONT_VENIT` pe `VANZARI_DETALII`: **da**, se pastreaza coloana.
-    - **Decizia 54, cele trei consecinte: acceptate toate trei.** `IN_STOC` vine din formular (si **S8
-      trebuie sa-l incarce** — vezi S10, consecinta 1); **se pierde validarea** liniei fata de comanda
-      pe ramura comenzi, asumat; **`PROC_TVAV` ramane derivat** — reemiterea dupa o modificare legala
-      de cota va da cota noua, **acceptat deocamdata**; transformarea lui in parametru ramane o
-      decizie separata, daca se cere vreodata reproducere exacta si peste asta.
-    - **Defectul `lnTip` din `do_copiaza`** (runda 13): **se repara la #6**, fisierul fiind al lui.
-    - **Punctele pur interne** (numarul codului de eroare `FACT-0xx`, numele cheii de optiune
-      `FACT_SCD_ARTFPRET`, forma semnalului de regenerare) — **lasate la latitudinea implementarii**,
-      cu recomandarile deja scrise in povestile lor.
-
-    **Raman deschise doar doua**, si amandoua din motive proprii, nu din lipsa de raspuns:
-    **(a) tipurile 48/49** (custodie) — Marius a cerut sa stie implicatiile, i s-au explicat, decizia
-    n-a fost inca data. *Inchis intre timp — decizia 60, runda 16: da, sunt editabile prin #13,
-    cu executia conditionata de verificarea custodiei in curs.*
-    **(b) cota si explicatia de TVA a discountului de document** —
-    **cercetare TERMINATA** (sectiunea K-bis): cota era regula implicita „cota maxima de pe factura",
-    explicatia e azi o constanta hardcodata (`ReasonCode="95"`, text „Discount"). **Partea de
-    repartizare s-a decis — decizia 59, runda 16: proportional pe cote.** Ramane deschis doar campul
-    text optional de motiv — **inchis si el: decizia 61** (da, se adauga), cu asezarea fixata de
-    **decizia 66** (in banda de totaluri, langa discount).
-55. **Metoda de executie e obligatorie, si e scrisa in plan.** La implementare planul **se sparge pe
-    stories**, fiecare story fiind o livrare de sine statatoare; **fiecare pas se testeaza**, nu doar
-    capetele de etapa (S6 / S12); si **fiecare story trece prin code review dupa implementare si dupa
-    teste, inainte de commit**. Sectiunea **„Metoda de executie"**, imediat inainte de Etapa I. S13
-    nu mai e momentul review-ului, ci al inchiderii.
-
-### Deciziile lui Marius, runda 15 (11.08.2026) — luate, nu de reluat
-
-57. **Asezarea zonei de jos: VARIANTA D.** Aprobata explicit („sunt de acord cu varianta D"), dupa doua
-    corectii cerute de el pe drum: (a) *„imi place linia de totaluri de la varianta C, dar incasarea si
-    alte date le vreau tot in acelasi formular, colapsate, mai jos de totaluri"*; (b) *„sectiunile
-    incasare si alte date colapsate trebuie sa fie pe acelasi rand — este destul loc pentru amandoua,
-    detaliile pot sa fie grupate pe orizontala, nu pe verticala"*. A / B / C **cad**.
-
-    **Ce inseamna D, concret, pentru S1 si S3:**
-    1. **Banda de totaluri** (preluata din C): pe toata latimea, lipita de grid, cu baza, discountul pe
-       articole, discountul de document **cu procentul editabil pe loc** si TVA desfacute pe un rand;
-       totalul mare, singur, la dreapta.
-    2. **Incasare si Alte date sunt sectiuni colapsabile in formular, nu dialoguri modale** — **una
-       langa alta pe acelasi rand**, sub totaluri, fiecare pe jumatate de latime. Randul inchis arata
-       **rezumatul continutului** („NUMERAR · 5 570,55 lei"), nu doar un titlu. Independente: se poate
-       tine deschisa doar una. Campurile dinauntru se aseaza **pe orizontala**, doua randuri fiecare.
-    3. **Nu exista bara de comenzi jos.** `but_renunt` / `but_termin` raman unde sunt azi — in banda de
-       titlu, sus in dreapta (`COMUN\clase\cmd_butoane.vc2:288` si `:386`, butoane-imagine cu
-       `Top = 1`, `Anchor = 8/9`, tooltip „Renuntare (ESC)" / „Terminare (CTRL+F)").
-    4. **Antetul strans la doua randuri**, fara titluri de grup, si **panoul „Discount pe document"
-       dispare** ca panou separat.
-
-    **Patru consecinte de dus in executie, nu de redescoperit:**
-    - **Dispare „renunt doar la incasare".** Fara `Accept` propriu pe dialog, ce se completeaza in
-      sectiune se scrie la `Termina`, impreuna cu documentul. **I-a fost spus explicit** inainte de
-      aprobare si a acceptat.
-    - **Validarea incasarii nu mai are moment propriu** — se muta in `Termina`, langa restul
-      verificarilor. **De scris explicit in S9.**
-    - **Starea deschis/inchis a sectiunilor** — de decis daca se retine intre documente sau porneste
-      mereu inchisa. Nu blocheaza nimic; recomandare: porneste inchisa, se retine per utilizator.
-    - **Caption pe cele doua butoane.** Sus in dreapta, langa `✕`-ul ferestrei, un `✓` verde fara text
-      e ambiguu. Punctul era deja notat in v8 pentru `But_renunt1` / `But_reset1`; D il face mai
-      apasat, pentru ca acum ele sunt **singura** cale de iesire.
-
-    **INCHIS.** Cercetarea despre cota si explicatia de TVA a discountului de document (punctul
-    deschis (b) de la decizia 56) **s-a terminat** — vezi sectiunea K-bis — si repartizarea s-a decis
-    (**decizia 59, runda 16**: proportional pe cote, fara sa se ceara cota de la utilizator), deci a
-    treia sectiune „grea" (cota + explicatie proprii) nu mai e in discutie. Ramane varianta minimala:
-    **decizia 61 (runda 16) a materializat-o** — Marius vrea campul text optional de motiv. Asezarea
-    lui a oscilat o data: decizia 64 il facea a treia sectiune jos, **decizia 66 (runda 17) o
-    rastoarna si il muta in banda de totaluri, langa discount**. **Punctul 2 de mai sus ramane deci
-    exact cum a fost aprobat: doua sectiuni jos, fiecare pe jumatate de latime.** D ramane intr-un etaj.
-
-58. **Mockup-ul asezarii ramane doar online.** Formularea lui: *„nu vreau artifactul html, doar online,
-    ca sa nu mai intretii 2 variante"*. `docs\mockup_13_variante_asezare_jos.html` **a fost scos din
-    `docs\`**; sursa de adevar e
-    **https://claude.ai/code/artifact/dfc70d38-856f-48fd-b6af-3da78e9da4f7**.
-    Ca sa-l modifici: `WebFetch` pe URL → scrie HTML-ul intr-un fisier de lucru **in scratchpad, nu in
-    `docs\`** → `Artifact` cu **`url` = link-ul de mai sus** (fara `url` se creeaza link nou).
-    **`docs\mockup_13_formular_unificat.html` (v8) nu intra sub regula asta** — cerinta a fost data
-    numai pentru mockup-ul asezarii.
-
-### Decizia 59 (Marius, runda 16) — luata, nu de reluat
-
-59. **Discountul de DOCUMENT se repartizeaza PROPORTIONAL PE COTE.** Formularea lui: *„discount pe
-    document repartizat proportional pe cote"*. Se adopta recomandarea cercetarii din **K-bis**:
-    regula de azi („toata valoarea discountului primeste cota MAXIMA de pe factura", prin
-    `Calculate Max(proc_tvav)`) **se inlocuieste** cu repartizarea proportionala cu baza fiecarei
-    cote de pe factura. **Nu se cere utilizatorului cota** — repartizarea e automata.
-
-    **Ce atrage dupa sine, tot din K-bis:**
-    1. **Doua locuri de schimbat, nu unul, si in ACEEASI livrare:** `prelucreaza_facturacrs` (VFP,
-       `COMUN\programe\ofacturare_comun.prg:1886-1897`) trebuie sa insereze cate un rand-sentinela
-       **per cota** in loc de unul singur; si `recalculeaza_totaluri_vanzari` (PL/SQL,
-       `ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:16081-16092`) trebuie sa inlocuiasca `MAX(...)`
-       cu suma repartizarii. Daca se schimba doar unul, `VANZARI.TOTAL_TVA` si TVA-ul din eFactura
-       **diverg** pe facturile cu cote mixte. **Nu e optional si nu se poate esalona.**
-    2. **Bucatile de discount trebuie sa primeasca `id_jtva_coloana` al grupului pe care il reduc**,
-       nu doar cota. Cheia de grupare din `xmlefactura.prg:246` are cinci campuri si `expltva` se
-       completeaza tot prin `id_jtva_coloana`. O implementare care seteaza doar `proc_tva` **lasa
-       grupul orfan exact unde e azi** — repara jumatate din defect si o lasa pe cealalta.
-    3. **eFactura nu cere nicio modificare** — `xmlefactura.prg:758-792` grupeaza deja
-       `GROUP BY proc_tva` si emite cate un `AllowanceCharge` per cota.
-    4. **Diferenta de rotunjire cade pe cota cu baza cea mai mare**, ca suma bucatilor sa fie exact
-       `VANZARI.DISCOUNT`. E recomandarea cercetarii, luata ca implicita — Marius a fost instiintat
-       ca se merge asa fara sa mai fie intrebat, deci se schimba doar daca obiecteaza. (Raportul
-       spune pe alocuri „ultima cota preia diferenta"; **regula care se implementeaza e cea de aici**,
-       ca sa nu ramana doua formulari in circulatie.)
-    5. **Doua consecinte vizibile, acceptate implicit prin decizie:** factura tiparita va arata **N
-       randuri** „Discount X % Factura" in loc de unul, pe facturile cu cote mixte; si **nota
-       contabila** primeste TVA-ul discountului spart pe cote.
-    6. **Rezolva si grupul orfan** de pe facturile scutite / taxare inversa / intracomunitare
-       (K-bis), fara garda separata, si desfiinteaza ambiguitatea lui `agettipcota(1)`.
-
-    **Raman DESCHISE, nu de presupus rezolvate:**
-    - **campul text optional de motiv** (`AllowanceChargeReason` in locul constantei „Discount";
-      `ReasonCode` ramane `95`) — Marius **nu s-a pronuntat**; de el atarna si intrebarea de asezare
-      din S1 / decizia 57 (a treia sectiune pe rand sau rand propriu);
-    - **retroactivitatea la relistare / retrimitere**: o factura veche relistata sau retrimisa in
-      eFactura ar genera alt XML decat cel trimis initial. **Nedecis.**
-
-### Deciziile 60-65 (Marius, runda 16) — luate, nu de reluat
-
-60. **Facturile de marfa in CUSTODIE (tipurile 48 si 49) SUNT editabile prin #13.** Formularea lui:
-    *„vreau sa fie posibila editarea si a facturilor in custodie"*. Intra deci in perimetrul
-    **etapei II**, contrar recomandarii „nu acum" din raportul S8 (intrebarea 7, §8.2).
-
-    **Inchide** punctul **(a)** de la **decizia 56** (tipurile 48/49, singurul ramas deschis din
-    blocul „da la toate") si **necunoscuta N5** din `docs\cercetare\s8_incarcare_document.md` §8.1,
-    plus restul intrebarii 7 din §8.2.
-
-    **Ramificatie noua pentru S8:** pe tipurile 48/49, controlul `ct_clb_altele` e scos
-    **neconditionat** la copiere (`ofacturare.vc2:9705-9712`), spre deosebire de tipurile 1/5/10
-    unde copierea il **pastreaza** si il reeticheteaza (`s8_incarcare_document.md` §3.2, ramura 3).
-    Calea de **editare** trebuie sa-l pastreze si pe custodie — ramura 48/49 a copierii nu poate fi
-    refolosita ca atare.
-
-    **VERIFICAT — blocantul CADE, dar premisa initiala era gresita.** Raportul:
-    `docs\cercetare\custodie_48_49_stergere_reemitere.md`. `scrie_fact_aviz_custodie` **nu are
-    legatura cu tipurile 48/49** — are un singur apel in tot pachetul (`PACK:7521`), pe ramura
-    `pack_facturare.ntip <> 4` (`:7472`), deci serveste `ntip = 4` (factura din avize), nu custodia;
-    numele procedurii a indus in eroare, si premisa gresita a circulat pana in aceasta decizie.
-    Emiterea unui document 48/49 **nu atinge deloc stocul**: sursa lor unica de articole e
-    `cursor_articole_k` (`PACK:3595-3701`), restransa explicit la `WHERE C.IN_STOC = 0` (`:3695`),
-    iar `descarca_gestiune` se cheama doar cand `in_stoc = 1` (garda dubla, la apelant `:7472-7475`
-    si in corpul procedurii `:7789-7797`). `sterge_factura` (`:5432-5607`) nu are ramura dedicata
-    pentru 48/49, si nici cele trei garzi de refuz al stergerii (`:5452-5494`) nu le prind — dar
-    **n-are ce reversa**, fiindca nimic legat de stoc n-a fost scris la emitere. **Regenerarea e
-    sigura pe 48/49**, nu pentru ca reversarea ar functiona, ci pentru ca nu exista nimic de
-    reversat.
-
-    **Rezerva, de scris, nu de ascuns:** siguranta atarna de un invariant azi impus doar de sursa de
-    articole — „documentele 48/49 contin numai articole cu `IN_STOC = 0`". Invariantul **nu s-a
-    verificat exhaustiv**, doar constatat pe sursa curenta. #13 schimba modul de adaugare a
-    articolelor (**S4** — cautare pe server, in linie; **S4g** — adaugare de articole la modificarea
-    oricarui document): daca formularul unificat ajunge sa permita adaugarea unui articol
-    **gestionabil** pe un document 48/49, invariantul se rupe si concluzia de siguranta pica.
-    **Cerinta pentru S4/S4g/S5: pe tipurile 48/49 se pastreaza restrictia la articole `IN_STOC = 0`**
-    — vezi notele de executie la acele povesti; devine **criteriu de test**, nu presupunere.
-
-    Pentru **emitere**, tipurile 48/49 erau oricum deja acoperite de etapa I (S5 completeaza cele
-    patru randuri lipsa din `Do Case`: 45, 48, 49, 52) — decizia 60 priveste doar **editarea**.
-
-61. **Discountul de document primeste un CAMP TEXT OPTIONAL de motiv.** Formularea lui: *„la
-    discount, da, un camp text optional"*.
-
-    **Inchide** ultimul punct ramas deschis din **K-bis** si din **decizia 56 (b)** — campul de
-    motiv nu mai e „Marius nu s-a pronuntat".
-
-    **Ce inseamna concret:**
-    - inlocuieste constanta hardcodata `"Discount"` ca `cbc:AllowanceChargeReason`
-      (`COMUN\programe\xmlefactura.prg:774-776`); **`ReasonCode` ramane `95`**;
-    - cere **stocare noua** — azi nu exista nicio coloana pe `VANZARI` pentru motivul discountului
-      de document;
-    - cere **un control nou in formular** — singura bucata din reparatia discountului (K-bis /
-      decizia 59) care chiar cere UI nou, restul fiind repartizare automata fara interactiune.
-
-    **Redeschisese, in varianta minimala, intrebarea de asezare de la decizia 57. INCHISA DEFINITIV
-    PRIN DECIZIA 66 (runda 17): campul sta in banda de totaluri, langa discount.** Decizia 64, care il
-    facea a treia sectiune jos, **e rasturnata** — randul de jos ramane cu doua sectiuni, ca la decizia
-    57. Varianta D ramane intr-un etaj. Paragrafele din **S1** si din **decizia 57** sunt actualizate
-    in acest sens.
-
-62. **Restrictia de modificare e „documentul sa NU fi fost trimis in eFactura" — si de aici
-    retroactivitatea NU mai e o intrebare.** Formularea lui: *„singura restrictie pentru modificare
-    este sa nu fie trimisa in eFactura, deci nu are legatura retroactivitatea"*.
-
-    Garda insasi nu e noua — **S7** o are deja, reutilizata din #6
-    (`COMUN\programe\ofacturare_editare.prg:19-28`, functia `EsteInEFactura`; apelata din
-    `COMUN\clase\ofacturare_comun.vc2:3764`). Ce era intrebare deschisa era
-    doar partea lasata de **decizia 59**: daca o factura veche, retrimisa, ar trebui tratata altfel
-    fata de una noua. Raspunsul lui Marius **inchide** acea intrebare: nu se leaga de nicio data si
-    de niciun flag suplimentar — verificarea `EsteInEFactura` ramane singurul criteriu de
-    modificare.
-
-    **Ramane un rest neacoperit, semnalat lui Marius, nedecis inca:** o factura **veche, deja
-    trimisa**, daca e doar **relistata** (tiparita din nou, nu editata), trece iar prin
-    `prelucreaza_facturacrs` si — dupa decizia 59 — ar produce **N randuri de discount in loc de
-    unul** pe facturile cu cote mixte, deci hartia ar diferi de originalul trimis in eFactura.
-    Relistarea nu e modificare, deci garda `EsteInEFactura` nu o acopera.
-
-63. **CERINTA NOUA DE AUDIT pe documente.** Formularea lui: *„este doar util de stiut data crearii,
-    data modificarii daca este cazul, utilizatorul crearii si al modificarii daca este cazul,
-    respectiv data stergere si utilizator stergere daca este cazul, pentru audit"*. Sase informatii:
-    **data + utilizator** pentru **creare**, **modificare** si **stergere**.
-
-    Scrisa initial ca cerinta, cu cercetarea in curs. **Cercetarea TERMINATA**, raport:
-    `docs\cercetare\audit_vanzari_creare_modificare_stergere.md`.
-
-    **Verdict, in doua randuri:** patru din cele sase informatii cerute **exista deja** pe `VANZARI`
-    si se scriu consecvent (`ID_UTIL`/`DATAORA` la creare, `ID_UTILS`/`DATAORAS` la stergere); **lipseste
-    complet perechea de modificare** (nicio coloana, verificat cu filtru `%MODIF%` pe
-    `all_tab_columns`), iar editarea prin stergere+reemitere (S9) ar **suprascrie tacit** perechea de
-    creare cu utilizatorul si data regenerarii, daca nu se transporta explicit — acelasi risc deja
-    rezolvat pentru `ID_FACT` (sectiunea „E. `ID_FACT`", linia 762).
-
-    **Poveste noua, proiectata: S14** — verdict complet, recomandare si punctele ramase de decis cu
-    Marius acolo.
-
-64. ~~**Asezarea campului de motiv: RANDUL SE IMPARTE IN TREI.**~~ **RASTURNATA DE DECIZIA 66
-    (runda 17) — NU MAI E IN VIGOARE.** Formularea de atunci: *„campul de motiv imparte randul in 3"*;
-    randul de jos ar fi avut trei sectiuni (incasare, alte date, motivul discountului), ~440 px
-    fiecare la 1366 px.
-
-    **Se pastreaza ca istorie, nu ca regula**, si merita pastrata: varianta a fost **construita in
-    mockup (v9) si respinsa dupa ce Marius a vazut-o** — *„motiv discount vreau sa fie langa discount,
-    nu a treia coloana"*. E argumentul cel mai bun din tot planul pentru **de ce se face mockup
-    inainte de cod**: decizia luata pe descriere s-a intors la prima privire pe forma desenata.
-    Ce e in vigoare: **decizia 66**, mai jos.
-
-65. **Auditul (decizia 63) se afiseaza in gridul din `frm_facturi`, nu in formularul facturii.**
-    Formularea lui: *„auditul presupun coloanele dataora si utilizator adaugat/modificat/sters, le
-    vreau pe grid-ul din formularul frm_facturi, nu in formularul facturii propriu-zise - este
-    posibil sa fie deja coloane"*.
-
-    Confirma continutul cerintei de audit (decizia 63): trei perechi **data + utilizator**, pentru
-    **adaugat**, **modificat** si **sters**. Locul de afisare e **gridul din `frm_facturi`**, nu
-    formularul unificat — deci **S14 nu cere controale noi in formularul unificat**, cere **coloane
-    in gridul listei de facturi**. E o cerinta mai usoara decat presupunea S14, si e de spus explicit.
-
-    **Sarcina de verificat la implementarea lui S14, adaugata ca prim pas al povestii:** Marius
-    banuieste ca unele coloane exista deja in acel grid. **Nu s-a verificat.** S14 incepe deci cu
-    **inventarul gridului din `frm_facturi`** — ce coloane de audit sunt deja acolo, ce surse au —
-    si abia apoi adauga ce lipseste. Nu se presupune nici ca exista, nici ca nu.
-
-### Decizia 66 (Marius, runda 17) — luata, nu de reluat. RASTOARNA DECIZIA 64.
-
-66. **Motivul discountului sta LANGA DISCOUNT, in banda de totaluri — nu ca a treia sectiune jos.**
-    Formularea lui: *„motiv discount vreau sa fie langa discount, nu a treia coloana"*.
-
-    **Anuleaza decizia 64** (randul de jos se imparte in trei). Randul de jos revine la **doua
-    sectiuni colapsabile** — incasare si alte date — adica exact la ce aprobase decizia 57, punctul 2,
-    inainte ca decizia 61 sa redeschida discutia. **Decizia 57 ramane intreaga; nu se mai atinge.**
-
-    **Ce inseamna concret, pentru S1 si S3:**
-    - campul de motiv e un **control in banda de totaluri**, imediat dupa suma discountului de
-      document, inainte de TVA; ia latimea ramasa pana la totalul mare, care sta la dreapta;
-    - **cele doua sectiuni de jos redevin pe jumatate de latime** (~660 px la 1366 px), nu ~440 —
-      argumentul „strans, asumat ca atare" din decizia 64 **cade odata cu ea**;
-    - **regula de activare, adaugata de proiectare, nu ceruta explicit:** campul e activ **numai cand
-      discountul de document nu e zero**. Un motiv fara discount n-are ce explica, si ar ajunge in
-      `AllowanceChargeReason` pe un `AllowanceCharge` inexistent. Daca Marius vrea altfel, e o linie
-      de schimbat.
-
-    **Consecinta de asezare, de stiut la implementare:** banda de totaluri devine plina — baza,
-    discount articole, discount document (procent + suma + bifa „evidentiat"), motiv, TVA, total. La
-    latimi mici **se rupe pe doua randuri** (`flex-wrap`), si asta e acceptat: alternativa ar fi
-    scoaterea bifei „evidentiat" din banda, care n-a fost ceruta.
-
-    Restul deciziei 61 (stocare noua pe `VANZARI`, `AllowanceChargeReason`, `ReasonCode` ramane `95`)
-    **e neatins** — se schimba doar locul controlului in formular.
-
-### Decizia 67 (Marius, 20.08.2026) — intrare separata „Facturare (nou)", nu comutator. Inchide (A)/(B) din decizia 49 pe (B).
-
-67. **Nu comutator global cu dialog — buton nou de meniu, ca ambele fluxuri sa fie accesibile in
-    acelasi timp.** Formularea lui: *„nu vreau sa modific o optiune pentru facturarea pe model nou,
-    ci vreau sa pui in meniu o varianta de facturare nou, ca sa pot sa accesez in acelasi timp ambele
-    facturari, si cea existenta si cea noua"*.
-
-    **Inchide definitiv alegerea (A)/(B) din decizia 49 (plan, liniile 3040-3082) pe varianta (B).**
-    Implementarea S2 din runda anterioara (comutator `gnFacturareNou` + `AMESSAGEBOX` DA/NU la
-    inceputul lui `factureaza`, care selecta intre proceduri) **se inlocuieste**, nu se pastreaza ca
-    alternativa.
-
-    **Mecanismul, minim, pe doua fisiere:**
-    - `COMUN\programe\ofacturare.prg`, in `factureaza`, la punctul de alegere a lui `lcObject`:
-      `llFacturareNoua = (Type('plFacturareNoua') = 'L' And m.plFacturareNoua)` — variabila
-      `plFacturareNoua` e `Private`, declarata de apelant; nedeclarata => `.F.` => calea veche,
-      identica azi, in toata suita (celelalte produse nu o declara). Fara dialog, fara comutator
-      global. `gnFacturareNou` dispare complet din fisier.
-    - `Clase\ofundal_facturare.vc2`, `Page2` (fundalul „Facturare"): buton nou `Cw10`, „Facturare
-      (nou)", cu propriul `do_actiune` care declara `Private plFacturareNoua = .T.` si ofera acelasi
-      meniu de surse (lista de preturi, contracte, comenzi, avize) ca butoanele existente, apeland
-      aceiasi wrapperi din `oproceduri_facturare.prg`. Popup-urile (`politica.mpr`/`contracte.mpr`)
-      executa `factureaza(N)` in interiorul `ACTIVATE POPUP`, deci vad variabila privata a
-      apelantului pe tot lantul de apel, fara sa fie redeclarata pe drum.
-
-    **Criteriul „gata" pentru S2 se rescrie in consecinta** (vezi story S2 mai jos): zero aparitii
-    `gnFacturareNou`, exact o aparitie `plFacturareNoua` in `ofacturare.prg`; butonul `Cw10` deschide
-    `frm_facturare_articole2` din formularul unificat vechi al meniului `Facturare`, fara sa
-    afecteze butoanele Cw1-Cw9 existente.
-
-    **COMPLETARE (Marius, 20.08.2026, aceeasi zi) — acoperire completa, nu doar 4 intrari.**
-    Intrarea „model nou" trebuie sa acopere **toate** intrarile de facturare existente, pe **ambele**
-    pagini ale fundalului, nu doar cele patru de pe `Page2` alese initial. Implementare generica,
-    fara duplicare de cod:
-    - `Page2.Cw10.do_actiune` ofera **toate cele noua** optiuni ale paginii „Facturare" (captions
-      identice, extrase textual din `Label_item1.Caption`/`LABEL_ITEM1.Caption` al fiecarui `Cw1..Cw9`,
-      in aceeasi ordine), si apeleaza `This.Parent.Cw<N>.do_actiune()` pentru optiunea aleasa — nu mai
-      cheama wrapperii direct, ca sa nu duplice logica fiecarui buton (unele cheama wrapperi din
-      `oproceduri_facturare.prg`, altele — pe `Page3` — cheama `.mpr` direct; `This.Parent.Cw<N>` merge
-      identic in ambele cazuri).
-    - Buton nou `Page3.Cw5`, „Avize (nou)", acelasi tipar, peste cele patru intrari ale paginii „Avize"
-      (`Cw1`=catre clienti, `Cw2`=catre clienti in custodie, `Cw3`=catre clienti debitori,
-      `Cw4`=transfer intre subunitati).
-    - `plFacturareNoua` (Private, setata `.T.` in `do_actiune`-ul butonului nou) ramane vizibila prin
-      `This.Parent.Cw<N>.do_actiune()` -> wrapper/`.mpr` -> `ACTIVATE POPUP` -> `factureaza(N)`, la fel
-      ca in varianta cu patru intrari - niciun apel din lant nu o redeclara.
-    - **Verificat in `factureaza`**: exista un singur punct unde se atribuie `lcObject`, intr-un
-      `If tnTip = 27 ... Else ... Endif` cu exact doua ramuri. Tipul 27 (aviz pe baza de lucrare) e
-      **singura exceptie** - toate celelalte tipuri (toate avizele, toate vanzarile, contractele,
-      returul, credit note) cad in `Else`, deci vad `plFacturareNoua`. Daca un utilizator ajunge la
-      tipul 27 prin butonul nou „Avize (nou)" (posibil via `aviz_subunitati.mpr`), flagul nu are efect
-      pentru acel sub-flux - comportament asteptat, nu bug, semnalat aici explicit.
-
-    **CORECTIE dupa review (aceeasi zi) — 5 din cele 9 optiuni initiale ale `Page2.Cw10` NU treceau
-    niciodata prin `factureaza`.** Review-ul (`docs\review_s2.md`, sectiunea 3) a gasit ca `Cw5..Cw9`
-    (materii prime, produse, marfa la pret de achizitie/vanzare/achizitie-vanzare) ruteaza prin
-    `vanzare_*` -> `vanzare1-5.mpr` -> `initializeaza_vanzare_din_stoc()`
-    (`COMUN\programe\ofacturare_stoc.prg:35-103`), un flux complet separat de „facturare" (deschide
-    formularul prin `lans()`, nu apeleaza niciodata `factureaza()` - `grep -c "factureaza("` pe fisier
-    = 0). Analiza de mai sus despre `lcObject`/`Else` e corecta, dar incompleta: demonstreaza doar ca
-    *daca* un tip ajunge la `factureaza`, vede `plFacturareNoua` - nu ca toate cele noua optiuni ale
-    lui `Cw10` ajung acolo. **`Page2.Cw10.do_actiune` s-a corectat la primele patru optiuni (`Cw1..Cw4`
-    - lista de preturi, contract, comanda, aviz), singurele care trec prin `factureaza`.** `Page3.Cw5`
-    ramane neschimbat - toate cele patru optiuni ale lui verificate ca trec prin `factureaza`. Vanzarile
-    din stoc (`Cw5..Cw9` de pe `Page2`) raman in afara perimetrului povestii #13 - `factureaza` nu are
-    nicio legatura cu ele.
-
-    **`frm_facturare_articole2` ramane, ca si pana acum, un prototip neterminat** (S1/S3) — decizia
-    67 schimba doar *cum se ajunge la el* (intrare de meniu explicita, nu comutator ascuns), nu
-    starea lui functionala.
-
-
-### Decizia 68 (Marius, 21.08.2026) — S3 se sparge in S3-1..S3-4; logica comuna a antetului trece in `.prg`, designul ramane in `.vcx`
-
-Marius a aprobat, pe nota de executie `docs\nota_executie_s3.md`: **spargerea lui S3** in S3-1 (pas 0
-+ `Init` fuzionat + C3 + `do_cauta_fdoc`), S3-2 (cele 28 `do_cauta_*` + `do_verifica`), S3-3
-(`inainte_de_do_termin` fuzionat + `do_schimba_tipdoc` + evenimentele de antet + testul UI), S3-4
-(integrarea buclei din `factureaza`, `ofacturare.prg` — cod comun suitei; raspunde la Q1), in
-ordinea asta; si recomandarile Q2 (combo `cboFdoc` dezactivat „AVIZ" pe aviz, `do_cauta_fdoc`
-portata, nelegata) si Q3 (doar `RemoveObject`, reasezarea la S3b).
-
-**Q4, precizat de Marius, textual:** *„toate metodele care se preteaza se pot muta in prg, sub forma
-de metode de clase. preteaza inseamna ca sunt lucruri comune, folosite de mai multe clase, sau
-utilitare [...]. imi este mult mai usor sa editez prg decat vcx. daca sunt lucruri care afecteaza
-design, ar trebui sa fie in vcx."* Regula de aplicat in S3-1..S3-4 (si in restul lui #13):
-
-- **in `.prg`, ca metode ale unei clase** (`Define Class ... As Custom`, sablon `anaf_efactura.prg`;
-  un singur cod, nu doua — in spiritul deciziei 35): cautarile `do_cauta_*` care scriu pe `poDate`
-  prin `caut_*()`, validarile din `inainte_de_do_termin` (lanturile `Do Case` / `amessagebox`),
-  regulile de `do_schimba_tipdoc` care nu ating controale, si orice utilitar folosit din mai multe
-  clase (`frm_date_factura`, `frm_date_aviz`, `frm_facturare_articole2`). Metoda din `.vcx` devine
-  un apel de o linie catre obiectul din `.prg` (`This.oAntet.<metoda>(This)` sau echivalent), ca sa
-  ramana `cprocedura` al controalelor valid.
-- **in `.vcx`**: tot ce tine de design si de suprafata — `Init`-ul (asezare, `RemoveObject`, focus,
-  etichete, serie/numar pe controale), `SetFocus`, `Enabled`/`Visible`, `ADD OBJECT`, evenimentele
-  controalelor.
-- Linia de demarcatie nu se trage mecanic: o metoda care amesteca o regula cu un `SetFocus` se
-  desparte — regula in `.prg`, efectul pe control in `.vcx`. Portarea ramane verificabila fata de
-  sursa (diff-ul citeaza de unde a venit fiecare corp).
-- Fisierul `.prg` nou (sau clasa noua in `COMUN\programe\ofacturare_comun.prg`, unde traieste deja
-  `oDateFactura`) se inregistreaza in `SET PROCEDURE ... ADDITIVE` din `Programe\roafacturare.prg`
-  daca e fisier nou — alegerea (fisier nou vs. clasa in `ofacturare_comun.prg`) se face in S3-2, o
-  singura data, si se noteaza in nota de executie.
-
-Consecinta pe S3-1, deja pornit: `Init` ramane in `.vcx` (e design); `do_cauta_fdoc` se porteaza in
-`.vcx` acum si **se muta** in clasa `.prg` la S3-2, odata cu celelalte `do_cauta_*` — ca sa nu se
-faca de doua ori alegerea locului.
-### Decizia 69 (Marius, 21.08.2026) — S3-4: forma functiei, declansarea incarcarii, antetul dupa incarcare, numarul ars
-
-Raspunsuri la Q5-Q7 din `docs\nota_executie_s3_4.md` plus perimetrul semnalat de
-`docs\verif_nract_do_cauta.md`.
-
-- **Q5 — functie globala**, langa clasa, in `COMUN\programe\ofacturare_antet.prg`. Constructia
-  cursorului de articole se apeleaza si din `factureaza` (unde nu exista formular), si din
-  `do_incarca_articole` (unde exista); o metoda de clasa ar cere fie doua cai de apel, fie
-  instantierea artificiala a lui `oAntetFacturare` doar pentru acest apel.
-- **Q6 — buton explicit** `but_incarca_articole` pe formularul unificat. Incarcarea automata la
-  completarea ultimului camp obligatoriu ar re-executa interogari Oracle la fiecare corectie de camp.
-- **Q7 — limitare cunoscuta, se lasa pentru S3b.** S3-4 livreaza exact criteriul „gata" al lui S3:
-  antetul se completeaza o data, articolele se incarca o data, documentul se termina. Ce se intampla
-  cu `crsfactura` daca antetul se schimba dupa incarcare nu se rezolva aici si nu se blocheaza
-  antetul; se documenteaza.
-- **Q8 — numarul ars se repara pe AMBELE cai, in S3-4.** In `do_schimba_tipdoc` alocarea
-  (`clb_serie_act1._cbbase1.LostFocus()`) ruleaza inaintea garzii „s-a schimbat tipul?"
-  (`ofacturare_antet.prg:906-908`; echivalent inline pe calea veche, `ofacturare.vc2:9396+`), deci se
-  consuma un numar real la simpla intrare-iesire din combo, fara nicio schimbare. Garda se muta
-  inainte de alocare in ambele implementari.
-
-  **Abatere asumata de la politica S3** („calea veche nu se atinge — nici nu se repara, nici nu se
-  reproduce"): orchestratorul a recomandat amanarea ca bug separat dupa #13, fiindca reparatia atinge
-  cod din productia tuturor utilizatorilor in mijlocul unificarii. Marius a decis reparatia pe ambele
-  cai. Consecinte de verificat la implementare: `test_s3_neregresie_vechi` compara amprente de dupa
-  `Init` (controale, etichete, `nid_tip`, `Height`) si nu exercita `do_schimba_tipdoc`, deci ar trebui
-  sa ramana identic — **de dovedit, nu de presupus**; iar paritatea pe `nract` din
-  `test_s3_do_cauta`/`test_s3_tipdoc` se pastreaza doar daca ambele cai se schimba impreuna.
-
-### Decizia 70 (Marius, 21.08.2026, seara) — amendament la Q8: pe modelul vechi se lasa cum era
-
-Reparatia Q8 ramane **doar pe calea unificata** (`plFacturareNoua`); `frm_date_factura` revine
-neatins. Politica S3 „calea veche nu se atinge" se restabileste.
-
-Motivul: review-ul independent (`docs\review_q8_numar_ars.md`, Q8-R5) a aratat ca pe calea veche
-reparatia nu inseamna doar „nu se mai arde un numar", ci **muta momentul alocarii** — documentul nou
-primeste numar abia la iesirea din controlul de serie, iar utilizatorul care sare peste el cu mouse-ul
-vede „Numar document" gol si primeste la finalizare „Nu ati completat numarul documentului!"
-(`ofacturare.vc2:9492-9495`). Schimbare de flux zilnic pentru toti utilizatorii suitei, in mijlocul
-unificarii.
-
-Ce ramane ca **datorie deschisa pe calea veche** (constient, nu prin omisiune): numarul ars la simpla
-intrare-iesire din combo si eroarea 1925 pe configuratiile cu `rezultat_serii = 0`.
-
-Consecinta prevazuta de decizia 69 s-a materializat: cele doua suite de paritate au incetat sa mai fie
-valabile ca atare (`test_s3_tipdoc` 11/5 FAIL, `test_s3_do_cauta` cu 23 de comparatii excluse tacit).
-Au fost adaptate sa **afirme divergenta explicit**, nu s-o excluda — `docs\raport_adaptare_paritate_q8.md`.
-
-
-### Decizia 71 (Marius, 22.08.2026) — `incarca_cursor_articole` nu mai primeste `poDate` ca parametru
-
-Functia extrasa la S3-4a isi pierde parametrul `poDate`; foloseste doar `Private`-ul apelantului.
-Semnatura devine `Lparameters tnTip, tlCopiere, poGeneratorNumere`.
-
-Motivul, ridicat de review-ul S3-4a (`docs\raport_s3_4a_implementare.md:142-177`): parametrul creeaza
-**doua legaturi** pentru acelasi nume. Codul VFP din corp foloseste parametrul, dar parametrii SQL
-`?poDate.*` se rezolva in `oExecute` la `poDate`-ul `Private` al apelantului. Azi coincid; un apel
-viitor cu alt obiect (de exemplu `This.oDate` din formularul unificat, exact ce urmeaza la S3-4b) ar
-construi cursorul pe alt antet decat cel trimis la Oracle — **tacut**, fara eroare si fara mesaj.
-Testul actual nu ar prinde-o: foloseste acelasi obiect pe ambele cai, cu executor mock-uit.
-
-Garda runtime propusa in review nu functioneaza in VFP (`Evaluate('poDate')` in interiorul functiei
-intoarce parametrul local, nu privatul apelantului), deci singura varianta care inchide problema prin
-constructie e eliminarea parametrului. Pretul: un parametru mai putin explicit in semnatura.
-
-### Decizia 72 (Marius, 22.08.2026) — reasezarea formularului unificat. RASTOARNA DECIZIA 26.
-
-Mockup aprobat, online: https://claude.ai/code/artifact/de29f441-7f23-4c73-801f-e75d801ed3e9
-(inventarul complet control-cu-control e sectiunea 5 din mockup; nu se duplica aici). Castigul masurat
-pe captura 1920x944: antet 177 -> ~139 px, banda de totaluri 154 -> ~36 px, grid 580 -> ~674 px,
-adica ~4-5 randuri de articole in plus.
-
-**1. Formularul se deschide maximizat** (`WindowState`).
-
-**2. Antetul pe doua randuri grupate, etichete deasupra casetelor** (varianta D din mockup):
-- rand 1, documentul: tip document, serie, numar, data, scadenta, inregistrare, data curs;
-- rand 2, partenerul: client, cod fiscal **cu butonul ANAF in caseta**, sold lei, bifa
-  **TVA la incasare** — bifa tine de client, nu de document.
-
-**3. Ies din antet si coboara in sectiunea pliata `Alte date`:** analiticele (venit/cheltuiala, sectie,
-lucrare, responsabil), **gestiunea sursa** — etichetata „filtru de stoc", fiindca `poDate.id_gestiune_init`
-pleaca pe server ca `V_ID_GESTIUNE_INIT` si restrange ce gestiuni intra in calculul stocului
-(`ofacturare.prg:471`, `:479`), nu e o valoare implicita a liniilor — si **explicatia pentru nota
-contabila** (`Ed_tx_simplu1` = `poDate.explicatia4`), etichetata „nu apare pe factura": ajunge in `ACT`
-prin `initializeaza_date_factura` (`ofacturare_stoc.prg:335`), dar nu apare nici pe `.frx`, nici in
-`xmlefactura.prg`.
-
-**4. Banda de totaluri pe un singur rand**, lipita de grid: Baza · Disc. art. · Disc. factura (procent +
-suma + bifa scurta „evid." cu tooltip) · Motiv · TVA · **TOTAL** la dreapta. Inlocuieste cele doua
-panouri de azi.
-
-**5. Gridul se intinde pe toata latimea** — azi se opreste la ~1360 px din 1920.
-
-**6. Bara de butoane deasupra gridului**, forma minima: Linie noua / Sterge linia / Incarca articole.
-**`But_verifica1` NU intra aici**: e verificarea ANAF (`do_verifica` -> `VerificaCodFiscal(...,
-"ANAF_SERVICIU_WEB")`, `ofacturare_antet.prg:740-754`), ramane langa codul fiscal.
-
-**7. `Alte date` si `Incasare` raman JOS, sub totaluri, una langa alta.** Marius: *„nu este esentiala
-pentru completarea facturii... nu vreau sa ocupe loc principal"*. **Decizia 57 punctul 2 ramane
-intacta**; propunerea de a le muta deasupra gridului a fost retrasa si nu se reia.
-
-**8. Analiticele raman EDITABILE, definitiv — decizia 26 se rastoarna.** Marius: *„de ce sa fie blocate?
-la introducere sa pot sa aleg sectia, lucrarea etc. la fel si la editarea ulterioara a facturii, care
-face stergere + inregistrare noua. editarea din #6 este separata de ce faci acum"*. Venit/cheltuiala,
-sectie, lucrare si responsabil se aleg si la introducere, si la reemitere; **nu se scrie `ReadOnly` pe
-ele nicaieri**. Consecinta de consemnat, nu de reluat: la reemitere nota se reconstruieste uniform pe
-document, deci o diferentiere facuta in #6 **la nivel de linie de nota** se pierde — e inerent
-regenerarii (documentul vechi se marcheaza `sters=1`, se scrie unul nou), nu efectul acestei decizii.
-
-**Punctele deschise la momentul aprobarii — INCHISE de decizia 73** (sursa deasupra gridului langa buton,
-buton cu eticheta dupa sursa, `explicatia`/`explicatia5` amanate, grupul contabil fara optiune de
-ascundere). Ramane deschis un singur punct:
-- **Adresa de livrare** — cercetare completa in `docs\cercetare\adrese_facturare_livrare.md`. Golul real:
-  pe o factura din comanda adresa de livrare **pleaca in eFactura** (`xmlefactura.prg:696-736`, cu
-  validari blocante) venind tacit din `comenzi.id_livrare` prin `poDate.oClient.adresa_livrare`
-  (`ofacturare.prg:685`, `694-695`), dar utilizatorul **nu o vede si nu o poate schimba** pe formularul
-  de facturare. `frm_alte_date` are un singur control de adresa, `clb_adresa_facturare`
-  (`ferestre_cere_date.vc2:2422-2440`) — control de livrare nu exista. Daca se vrea vizibila/editabila:
-  camp nou pe `poDate` + control in `Alte date` + propagare in `poClient`.
-
-**De stiut la implementare:** nici `Incasare`, nici `Alte date` nu exista azi in `frm_facturare_articole2` —
-amandoua sunt inca dialogul modal `frm_alte_date` (`COMUN\clase\ferestre_cere_date.vc2:2219`), deschis cu
-`Createobject("frm_alte_date")` (`ofacturare.vc2:19193`). Continutul lui se imparte astfel: **Incasare** —
-`Clb_incasat`, `opt_incasat`, `Clb_serie_chit`, `Clb_nrchit`, `Cb_casa`, `chkPOS`, `chkDetaliat`,
-`cmdModificaBon`, `But_modifica1`; **Alte date** — `Ct_clb_delegat`, `Ct_clb_masina`, `Ct_clb_agent`,
-`Clb_dataora_exp`, `clb_adresa_facturare`, `cboTipFactura`.
-
-
-### Decizia 73 (Marius, 22.08.2026) — inchide cele patru puncte lasate deschise de decizia 72
-
-**1. Sursa (`Ct_clb_altele`) sta deasupra gridului, langa butonul de import** — nu in antet si nu in
-`Alte date`. Marius: *„cred este nevoie de sursa sa fie vizibila la factura din comanda/contract/aviz/retur
-etc. probabil si cu butonul importa din comanda/contract/aviz etc"*. Sursa si butonul care importa din ea
-stau impreuna; dupa incarcare butonul dispare (`do_incarca_articole` face
-`This.but_incarca_articole.Visible = .F.`, `ofacturare.vc2:18071`), iar sursa ramane vizibila ca referinta.
-
-Bara devine: `[Nr. comanda: 1234]` `[Incarca din comanda]` | `[Linie noua]` `[Sterge linia]`.
-
-**Verificat pe cod, nu e cerinta noua:** `Ct_clb_altele` isi schimba deja eticheta dupa tipul documentului —
-„Nr. comanda", „Nr. contract", „Nr. aviz / avize", „Nr. facturi", „Gestiune destinatie", „Retur la",
-„Locatie" — in `Do Case`-ul din `Init` (`COMUN\clase\ofacturare.vc2:19375-19520`), si e scos cu
-`RemoveObject` exact acolo unde nu exista sursa (factura din lista de preturi, necopiata). Deci
-vizibilitatea ceruta exista deja; decizia priveste **doar pozitia**.
-
-**2. Butonul de import primeste eticheta dupa sursa:** „Incarca din comanda" / „din contract" / „din aviz" /
-„din facturi", in loc de „Incarca articole" (`ofacturare.vc2:15982`). Caption-ul se seteaza din **acelasi**
-`Do Case` care seteaza eticheta lui `Ct_clb_altele` — un singur loc, cateva linii. Cand sursa lipseste si
-controlul e scos, ramane „Incarca articole".
-
-**3. `explicatia` si `explicatia5` NU intra in aceasta reasezare.** S3b livreaza doar `explicatia4`, ca azi.
-Aducerea lor pe formular cere doua campuri noi pe `poDate` (`ofacturare_comun.prg:200`) plus lantul de
-scriere pana in `ACT` — story propriu, in afara #13 asa cum e definit acum.
-
-**4. Grupul contabil nu primeste optiune de ascundere.** Plierea sectiunii `Alte date` acopera deja cazul:
-cine nu foloseste analiticele nu deschide sectiunea. Zero cod in plus, niciun camp de configurare nou.
-
-
-### Decizia 74 (Marius, 22.08.2026) — trei corectii de asezare, dupa ce cercetarea a infirmat premisele mockup-ului
-
-Cercetarea completa, cu citate: `docs\cercetare\s3b_geometrie_grid_totaluri.md`.
-
-**1. Gridul de cursuri valutare coboara in sectiunea pliata `Alte date`.**
-
-Mockup-ul spunea „ascunse pe factura in lei". **Fals.** `grd_cursuri` / `lb_cursuri` apar si pe
-facturile in lei: conditia de afisare nu e moneda documentului, ci existenta cursurilor zilei.
-Pe ramura de lei, `ofacturare.prg:599` apeleaza `citeste_cursuri_zi(poDate.zi_curs)`, care citeste
-tot `vcurs`-ul valabil in ziua respectiva (`oproceduri_curs.prg:113-122`), iar `zi_curs` e setat
-neconditionat la data documentului (`ofacturare_comun.prg:247`, `:496`). Formularul nu verifica
-nicaieri `in_valuta` pentru vizibilitate — doar `Used('crscursuri') And Reccount('crscursuri') > 0`
-(`ofacturare.vc2:18072`, `:19269`).
-
-Blocul ocupa deci permanent ~100 px stanga-jos, exact unde vine banda de totaluri. Marius: intra
-in `Alte date`, langa analitice — nu ocupa loc cand sectiunea e pliata, ramane accesibil pe orice
-document, iar banda de totaluri ia toata latimea. **Nu se schimba conditia de populare** a
-cursorului si nu se ascunde nimic pe criteriu de moneda; se muta doar locul.
-
-**2. „Motiv" (motivul discountului) se creeaza acum, gol.**
-
-Nu exista azi: zero potriviri in `frm_facturare_articole2` si niciun camp pe `poDate`. E controlul
-nou cerut de reparatia discountului (deciziile 59 / 64 / 66), pe care decizia 66 l-a asezat in banda
-de totaluri, langa discount.
-
-Marius alege sa fie creat acum, ca sa nu se rearanjeze banda a doua oara. Ca sa nu fie un camp
-vizibil care minte, controlul se leaga de o proprietate noua pe `poDate` (`ofacturare_comun.prg`),
-deci valoarea traieste cat sesiunea de editare a documentului. **Nu primeste coloana in baza si nu
-se scrie nicaieri** — persistenta vine odata cu reparatia discountului. Limitare declarata, de
-consemnat ca atare.
-
-**3. Latimea ramasa se imparte proportional pe toate coloanele gridului.**
-
-Azi `grd_factura` se intinde prin `Anchor = 15`, dar coloanele raman la latimile de design, de unde
-spatiul gol de la ~1360 px la 1920 px. **Nu exista niciun mecanism de autofit in suita** — cautare
-exhaustiva pe `ColumnWidth` / `AdjustColumns` / `autofit` in `COMUN\clase\*.vc2` si
-`COMUN\programe\*.prg`; `_grdrow` (`_grd_base.vc2:445`) si `_grdbase` (`_grd_base.vc2:7`) n-au asa
-ceva. Deci e cod nou.
-
-**Preferintele salvate per utilizator nu intervin aici**, contrar capcanei generale din
-`COMUN\docs\capcana_grid_preferinte_utilizator.md`: instanta `Gridextra3` din acest formular are
-`allowgridpreferences = .F.` explicit (`ofacturare.vc2:17172`), iar `restoregridpreferences` si
-`savegridpreferences` sunt amandoua gardate de acea proprietate (`gridextras.vc2:1051-1078` si
-`:1130`). Latimile redistribuite la runtime nu vor fi suprascrise.
-
-Codul nou merge intr-o clasa dintr-un `.prg`, nu ca metoda in `.vcx` (`reguli_lucru.md`, punctul 3);
-formularul doar instantiaza si apeleaza.
-
-
-#### S6 — Test pe fluxul real, formularul unificat
-Headless (`COMUN\docs\depanare_testare_vfp.md`) + UI (`COMUN\docs\testare-ui-vfp.md`), cate un caz
-pe fiecare sursa: lista de preturi, comanda, contract, aviz, retur, transfer, valuta. Comparatie
-directa cu documentul emis pe calea veche: `vanzari`, `vanzari_detalii`, `act`, `rul`, totalurile
-denormalizate, listarea.
-*Depinde de:* S5.
-
-### Etapa II — editarea prin regenerare
-
-#### S7 — Actiunea si garzile
-Actiune noua pe `frm_facturi`, sub tokenul de drepturi existent. Garzi refolosite din
-`COMUN\programe\ofacturare_editare.prg` (`EsteInEFactura:12`, plus luna inchisa, luna curenta,
-`ReferinteDocumenteNota`) — **nu se rescriu**, sunt deja extrase de #6. Plus garzile proprii
-regenerarii: refuz daca documentul are **urmasi**.
-
-**PRECIZAT in runda 14, pe cod** (`docs\cercetare\garda_aviz_facturat.md`): regula exista deja integral
-in Oracle, in **trei** garzi consecutive din `sterge_factura` — factura cu retururi (`TIP = 3`,
-`EXPORT:5452-5462`), **aviz cu factura sau aviz de retur** (`TIP IN (1,2)`, `EXPORT:5466-5476`), si
-factura din aviz ale carei avize-sursa au primit intre timp aviz de retur (`EXPORT:5480-5494`).
-**S7 nu reimplementeaza regula** — o citeste **mai devreme**, read-only, inainte de intrarea in
-formular:
-
-```sql
-select count(*) from vanzari_coresp
- where sters = 0 and id_vanzare_aviz = :id_vanzare and tip in (1, 2, 3)
-```
-
-plus subinterogarea din garda 3 pentru cazul „factura din aviz". Se interogheaza `VANZARI_CORESP`,
-**nu `VANZARI.FACTURAT`** — `FACTURAT` e derivat si necitit de nicio garda. Garda din `sterge_factura`
-**ramane pe loc ca plasa de siguranta**: nu se muta, nu se slabeste.
-
-**Gol de acoperit, iesit tot in runda 14:** pentru **proforma** (`TIP = 4`, decizia 51) garda **nu
-exista deloc** — `sterge_proforma` (`EXPORT:5610-5635`) e o procedura separata fara nicio verificare,
-iar calea VFP iese din `do_sterge` inainte de restul (`ofacturare_comun.vc2:4707-4719`). Garda simetrica
-ceruta de S5c e **cod nou**, nu reutilizare.
-*Gata cand:* actiunea refuza corect si cu mesaj clar documentele trimise in eFactura, sterse, din
-luna inchisa, referentiate, sau care au urmasi (retur, factura din aviz, factura din proforma) —
-**inainte** de deschiderea formularului, nu ca `ORA-20000` la final.
-*Depinde de:* S6, si de inchiderea perimetrului cu #6 (fisier partajat).
-
-#### S8 — Incarcarea documentului in formular
-
-> **PROIECTAT INTEGRAL in runda 14 — `docs\cercetare\s8_incarcare_document.md` (52 KB, 8 sectiuni).**
-> **Schita de mai jos e corecta ca directie, dar gresita in piese, si nu marunt:**
-> 1. **`completeaza_setari_document(toFactura, .T.)` copiaza 16 proprietati din ~120**
->    (`COMUN\programe\ofacturare_comun.prg:361-411`) si **niciuna de identitate**. Lipsesc serie,
->    numar, data, scadenta, `text_aditional`, `id_facturare`, `id_ruta`, `tip_saft`, `efactura`,
->    `listare_detaliata`, `dataora_exp`, discountul de document, `discount_evidentiat`, `eproforma`,
->    valuta, cursul.
-> 2. **`cursor_retur_document(V_COPIERE = 1)` nu umple documentul, ci selectorul-sursa.** Rezultatul
->    intra in `crsarticole` (gridul din stanga); `crsfactura` se creeaza **gol si ramane gol** —
->    comentariul din cod e explicit (`COMUN\programe\ofacturare.prg:338`, `:455-457`). Transferul se
->    face doar prin `do_adauga_tot` → `do_adauga_articol`, care pentru articolele gestionabile trece
->    **prin dialogul de alegere din stoc**.
-> 3. **`cursor_retur_document` nu intoarce `ID_VANZARE_DET` si nici `TAXCODE`**
->    (`PACK_FACTURARE:3949-4054`). Fara `ID_VANZARE_DET`, cheia de linie presupusa de S8b **nu exista**,
->    iar ruta ieftina `modifica_explicatie_articol` **devine neapelabila** — primul ei parametru *este*
->    `V_ID_VANZARE_DET` (`PACK_FACTURARE:14511-14519`).
->
-> **Recomandarea centrala:** S8 se construieste pe precedentul care face deja exact asta —
-> `relisteaza_ofacturare_stoc` (`COMUN\programe\ofacturare_stoc.prg:456-742`), care reconstituie
-> `poDate` + cursorul de linii dintr-un document salvat, prin `FACT_VFACTURI` + `FACT_VFACTURI_DETALII`
-> (ambele au `ID_VANZARE_DET` si `TAXCODE`). Canalul final e intrebarea 1 din §8.2 al raportului
-> (*recomandat:* procedura noua `cursor_editare_document`, ca sa nu se schimbe comportamentul copierii).
->
-> **CORECTIE la raportul S8, facuta de sesiunea principala (runda 14):** raportul lasa deschis (N6,
-> intrebarea 7) daca „`frm_facturare_articole2` (varianta paralela)" intra in perimetru, si recomanda
-> „nu acum". **Premisa e gresita: `frm_facturare_articole2` NU e o varianta paralela de exclus — e
-> PROTOTIPUL pe care se construieste formularul unificat**, conform S1 („se porneste de la prototip",
-> `ofacturare.vc2:15741-19355`). Deci S8 il tinteste pe el, nu pe `frm_facturare_articole`. Faptul ca
-> are `do_adauga_tot` / `do_adauga_articol` proprii, cu logica divergenta (fara testul `llGestionabil`,
-> `ofacturare.vc2:17476`, `:17124`), **nu e un motiv de excludere, e exact driftul din 2017 pe care S2
-> il inchide** — cele doua se unifica, nu se aleg. Partea de tipuri 48/49 din intrebarea 7 **s-a
-> inchis prin decizia 60**: sunt editabile. Intrebarea 7 e deci inchisa integral.
-
-> **CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17 — `IN_STOC` se incarca din document, nu din nomenclator.**
-> Vine din consecinta 1 a deciziei 54 (vezi S10, „Trei consecinte"), si se prinde **aici**, nu la S12.
-> Cu flag-ul de regenerare pornit, `IN_STOC` nu mai e re-derivat de `adauga_articol_factura`, ci **vine
-> din formular** — deci valoarea pe care o incarca S8 devine valoarea care decide **descarcarea de
-> gestiune la reemitere**. Azi loader-ul lui #6 o citeste din nomenclatorul curent
-> (`ofacturare_editare.prg:302-303`), deci un articol devenit intre timp gestionabil (sau invers) ar
-> face reemiterea sa atinga **alt stoc decat documentul initial**, tacut.
->
-> Trei consecinte concrete pentru canalul de citire (intrebarea 1 din §8.2, *recomandat* (B),
-> `cursor_editare_document`):
-> - canalul trebuie sa intoarca `IN_STOC` **asa cum a fost la emitere**, nu `GESTIONABIL = B.IN_STOC`
->   din nomenclatorul de azi, cum face `cursor_retur_document` (`PACK:3993-4000`). E un **al treilea
->   argument** pentru procedura noua, langa `ID_VANZARE_DET` / `TAXCODE` si langa `ID_POL` / `ID_CTR`
->   lipsa din `VVANZARI_ARTICOLE`;
-> - **valoarea istorica nu e stocata nicaieri**: `IN_STOC` nu e coloana pe `VANZARI_DETALII` (verificat
->   pe DB, vezi S10), traieste doar in temp. Deci primul pas al lui S8 pe aceasta cerinta e sa
->   stabileasca **de unde se reconstituie** — fie din urma lasata in rulaje / gestiune pentru documentul
->   respectiv, fie se accepta nomenclatorul curent ca aproximatie **declarata explicit**, fie se adauga
->   coloana (migrare DB, deci **DB inainte de EXE**, ca la S10). **Nu se presupune niciuna dintre
->   variante**; e o **preconditie de proiectare a lui S8**, nu un detaliu de implementare;
-> - pe tipurile **48/49** cerinta se intalneste cu decizia 60: acolo invariantul e `IN_STOC = 0` prin
->   constructie, deci valoarea incarcata trebuie sa fie `0` indiferent ce zice nomenclatorul azi.
->
-> *Criteriu de test (intra in „gata cand" al lui S8):* un document emis cu un articol caruia i s-a
-> schimbat intre timp `IN_STOC` in nomenclator, deschis in formular, poarta **valoarea de la emitere**;
-> iar reemiterea lui lasa **stocul agregat neschimbat** (masurat inainte / dupa, nu prin inspectia
-> codului).
-
-> **Cerinta noua din S8b e mai blanda decat se credea:** lookup-ul „ultimul delegat / ultima masina"
-> **are deja o garda** — `Empty(id_delegat) And Empty(id_masina)` (`ferestre_cere_date.vc2:3111`).
-> Riscul ramane real, dar **numai** pe documentele fara delegat si fara masina. Raportul da inventarul
-> complet al celorlalte initializari „pentru document nou" care trebuie sarite (§2.2).
-
-`completeaza_setari_document` pentru antet + `cursor_retur_document(V_COPIERE = 1)` pentru linii,
-**fara** degradarea de tip din `do_copiaza`. Se incarca in plus, fata de copiere: serie / numar /
-data / scadenta reale, discountul de document (`VANZARI.DISCOUNT`), `discount_evidentiat`, textul
-aditional, datele din `frm_alte_date` (delegat, auto, agent, adresa de facturare), explicatia si
-`taxcode` pe fiecare linie, si legatura cu sursa (`id_comanda`, `id_ctr`, lista de avize din
-`vanzari_coresp`) — ca reemiterea sa reconsume aceeasi sursa.
-**Campul de sursa exista deja** — nu e de adaugat, ci de pastrat vizibil: e `Ct_clb_altele`, cu
-eticheta schimbata pe tip de `do_schimba_explicatia` („Nr. contract” / „Nr. comanda” / „Nr. factura” /
-„Nr. facturi” / „Locatie”, `ofacturare.vc2:9633-9643`), eliminat azi din formular cand
-`gnScadereStoc = 0` si tipul e 1/5/10 fara copiere. La modificare e blocat: schimbarea sursei ar
-insemna alt document, nu o corectie.
-Formularul arata **identic** cu cel de introducere: fara banda de avertizare, fara coloane cu
-valorile initiale, fara panou de diferente (decizia 5). Se schimba titlul ferestrei si **butonul
-principal** (decizia 9, vezi S8c).
-*Gata cand:* formularul deschis pe un document existent arata exact documentul, pe fiecare tip de
-sursa, si nu se distinge vizual de formularul de introducere; **si** liniile incarcate poarta `IN_STOC`
-de la emitere, nu din nomenclatorul de azi (cerinta rundei 17, mai sus).
-*Depinde de:* S7.
-
-#### S8b — Rutarea scrierii dupa ce s-a schimbat
-Comasarea celor trei actiuni de modificare (G-bis): la confirmare se compara starea din formular cu
-cea incarcata si se alege ruta — `modifica_date_factura` pentru antet, `modifica_explicatie_articol`
-pentru explicatia liniei, regenerare pentru orice atinge sumele, nimic daca nu s-a schimbat nimic.
-Cele trei actiuni vechi de pe `frm_facturi` (`do_modifica`, `do_modifica_explicatie`) se retrag
-abia dupa ce formularul unificat le acopera, nu inainte.
-**PROIECTAT (runda 13) — `docs\cercetare\s8b_rutarea_scrierii.md`. Reteta G-bis e corecta ca directie,
-dar avea un gol nedocumentat, si el schimba forma solutiei.**
-
-- **Cele patru rute NU sunt teste independente, ci un lant cu prioritate — sumele primele.**
-  Motivul e concret: **`modifica_date_factura` nu e singura ruta care scrie cei 14 parametri de antet.**
-  **Sapte din 14** (`id_delegat`, `id_masina`, `id_facturare`, `listare_detaliata`, `dataora_exp`,
-  `id_agent`, `text_aditional`) sunt scrisi **si** de calea normala de emitere, prin `scrie_factura2`,
-  direct din `poDate` — **verificat direct de sesiunea principala** pe apelul de la
-  `COMUN\clase\ofacturare.vc2:14345-14359`. Nu exista doi proprietari ai acestor campuri: e **acelasi
-  obiect `poDate`** citit de ambele cai.
-- **Deci, cand regenerarea porneste, `modifica_date_factura` NU se mai cheama.** Inainte de regenerare
-  ar scrie pe randul care urmeaza sa fie sters — pierdut. Dupa, ar fi a doua scriere pe aceleasi sapte
-  coloane, pe alt `ID_VANZARE`. Regenerarea **este** deja calea de scriere a antetului cand sumele se
-  schimba, nu o cale care trebuie compusa cu alta.
-- **Ordinea rutarii:** (1) s-au schimbat liniile / discountul de document? → **regenerare, gata**;
-  (2) altfel, antet? → `modifica_date_factura`; (3) altfel, doar explicatie de linie? →
-  `modifica_explicatie_articol`; (4) altfel → **nimic**.
-- **Explicatia de linie e transportata gratuit de regenerare**, prin parametrii nativi ai lui
-  `adauga_articol_factura` (`V_EXPLICATIE`, `V_TAXCODE`) — **cu conditia** ca regenerarea sa citeasca
-  din cursorul curent al formularului, nu dintr-un snapshot separat.
-- **Cel mai probabil fals pozitiv al criteriului „deschid si inchid → nicio scriere":** lookup-ul
-  „ultimul delegat / masina al clientului" din `frm_alte_date.Init`
-  (`COMUN\clase\ferestre_cere_date.vc2:3119-3136`). E cod gandit pentru **document nou**. Pe calea de
-  editare ar suprascrie delegatul **incarcat corect din document** cu ultimul folosit de client — deci
-  ori documentul apare „modificat" fara ca nimeni sa fi atins nimic, ori, daca ruleaza inainte de
-  snapshot, **salveaza tacit delegatul gresit**. **S8 trebuie sa-l sara explicit pe calea de editare.**
-- **Comparatia se face pe valori rotunjite la precizia de scriere** (`gnPc` / `gnPPretV` / `gnPCant`),
-  nu pe valoarea binara — altfel rotunjirea singura produce diferente.
-
-**INCHIS, nu de reintrebat (marcaj pus in runda 17).** Punctul de mai jos are raspuns: **decizia 52** — `do_modifica` ramane activ pentru multi-selectie, iar formularul unificat preia doar cazul cu un singur document. Se pastreaza enuntul, nu intrebarea:
-1. **Editarea multipla** — `do_modifica` de azi lucreaza pe multi-selectie, capacitate fara echivalent
-   in formularul unificat. Se accepta pierderea ei la retragere, sau `do_modifica` ramane activ separat
-   exact pentru cazul asta?
-
-**Doua goluri de inchis inainte de implementare (semnalate, nu presupuse):**
-- **Ce canal scrie `serie_act` / `numar_act` / `data_act` / `data_scad` / `id_ruta` / `tip_saft` /
-  `efactura`** pe documentul reemis — **nu apar in `scrie_factura2`**, deci vin pe alt drum. Raspunsul
-  decide daca mai e nevoie de o scriere separata dupa regenerare. **Se inchide in S9.**
-- ~~**`cursor_retur_document` re-deriva pretul la incarcare?**~~ **INCHIS (runda 13): NU** — pretul vine
-  din `VANZARI_DETALII.PRET` stocat, fara `JOIN` catre contract sau politici (`PACK_FACTURARE:3960-4062`,
-  verificat direct). **Mecanismul de detectie e valid.** Detaliul despre rotunjire si `DIFERENTA` — in S10.
-
-*Gata cand:* fiecare din cele patru situatii din tabelul G-bis produce exact scrierile din tabel si
-nimic in plus; in special, deschiderea si inchiderea fara modificari nu scrie nimic.
-*Depinde de:* S8.
-
-#### S8c — Butonul comutator de antet si salvarea separata a antetului
-Decizia 9, proiectata in I. Antetul unui document existent porneste **blocat**; un singur
-`but_modifica` il deschide si isi schimba imaginea in discheta de salvare; a doua apasare cheama
-`modifica_date_factura` si **nu atinge articolele** — exact ce face azi `do_modifica`, dar din
-formularul unificat, dupa care antetul se blocheaza la loc si butonul revine la creion. **Fara nicio
-bifa**: butonul deschide tot antetul, inclusiv serie / numar / data / scadenta; cele patru bife de
-azi nu se transpun. `Termina` ramane salvarea intregului document.
-Se generalizeaza reteta de blocare din `clb_tx_data.dezactiveaza()` / `reactiveaza()`
-(`lb_tx.vc2:521-538`) la containerele de antet care azi nu au niciuna (I), si se aplica **uniform**
-tuturor campurilor de antet — asta e ce face posibila eliminarea bifelor.
-Comutarea imaginii butonului se copiaza din `frm_rulaje.se_modifica_assign` (`rulaje.vc2:4716-4773`):
-o singura instanta `but_modifica`, cu `.cpicturedown` / `.cpictureup` / `.Picture` rescrise impreuna
-si `.Refresh()` — vezi decizia 9 pentru capcana hover-ului.
-**Ce deschide efectiv butonul (decizia 25, verificat pe cod in G-bis).** „Tot antetul” nu inseamna
-ca totul se salveaza pe aceeasi ruta:
-- **cei 14 parametri** — pe loc, prin `modifica_date_factura`. Asta livreaza S8c;
-- **grupul B** (tip document, valuta, zi curs, client, sursa, gestiune sursa, politica de preturi) si
-  **grupul C** (incasare) — **nu au ruta de scriere pe loc**, deci raman **blocate in etapa I**, cu
-  explicatie la hover; se deschid in etapa II, cand modificarea lor marcheaza documentul pentru
-  regenerare;
-- **grupul A** (analiticele) — **editabile** (decizia 72, care rastoarna decizia 26), si la introducere,
-  si la reemitere; nota se reconstruieste uniform pe document.
-
-Deci in etapa I butonul deschide **exact cei 14**, si asta nu e o abatere de la decizia 9, ci
-consecinta ei corecta pe starea de azi a codului: restul campurilor n-ar avea unde sa se scrie.
-*Gata cand:* se poate corecta delegatul unui document emis, salva antetul si inchide formularul,
-**fara nicio scriere in `VANZARI_DETALII` si fara recalcul de sume in note sau rulaje**; se poate
-corecta si data scadentei prin acelasi buton, fara alt control intermediar; iar un document deschis
-si inchis fara a apasa butonul nu produce nicio scriere.
-*Atentie la formularea criteriului:* „nicio scriere in note si rulaje” ar fi un criteriu imposibil —
-schimbarea seriei / numarului / datei propaga coloanele de identitate in `JV2007` si `RUL` prin
-procedura insasi (I-bis). Ce se verifica e ca **nu se ating sumele**, nu ca nu se atinge tabelul.
-*Depinde de:* S8.
-
-#### S9 — Stergerea si reemiterea intr-o singura tranzactie, cu `ID_FACT` pastrat
-Partea grea. Doua lucruri simultan:
-
-**Constrangere de la decizia 35, inainte de orice:** reemiterea **scrie prin `pack_facturare`**, pe acelasi
-drum ca emiterea (`scrie_factura2` → `contabilizeaza_articol`, cu parametrul de cont de la decizia 34).
-`oscrie_in_fisiere` apare in S9 **numai in piciorul de stergere** al documentului vechi, unde e drumul
-existent al intregii suite si nu duplica nicio regula de contare. **Nu se scrie si nu se corecteaza niciun
-rand din `ACT_TEMP` direct din VFP.** Consecinta de secventiere: **S9 nu poate porni inaintea parametrului
-deciziei 34** — nu mai exista varianta „editarea nu cere nimic in pachet".
-
-**VERIFICAT ca decizia 35 e realizabila** (`docs\cercetare\parametru_cont_contabilizeaza_articol.md`,
-sectiunea 1): pe partea Oracle, **a doua emitere a aceluiasi document merge pe cod identic**.
-`scrie_factura2` cheama `initializeaza_date_factura` (`PACK_FACTURARE:1808-1846`) la fiecare apel, iar
-aceasta face `DELETE FROM VANZARI_DETALII_TEMP` (`:1835`) si `nid_act := 0` (`:1836`) — contorul folosit
-de `scrie_nota` / `scrie_discount` / `scrie_tva` la fiecare `INSERT INTO ACT_TEMP` **porneste curat si la
-reemitere**. Nimic din `contabilizeaza_articol`, ramura noua inclusa, nu citeste vreo stare care sa
-presupuna „documentul e nou": variabilele de sesiune sunt **citite**, nu comparate cu o stare anterioara.
-**Singurul obstacol real al regenerarii e in alt pachet** — `PACK_CONTAFIN`, prin `SET_IDFACT` si
-`PK_DOCUMENTE`, exact ce e deja analizat mai jos in acest S9. Adica: „cod separat" inseamna **alta
-procedura, in alt pachet**, nu o a doua ruta de contare — deci **decizia 35 nu e contrazisa**.
-
-- **Tranzactia.** Apelul de stergere (`oscrie_in_fisiere` + `finalizeaza_stergere_nota` +
-  `sterge_factura`) se muta in interiorul tranzactiei deschise de `do_scrie_articole`, inaintea
-  primului `adauga_articol_factura`. Fara `commit` intermediar (`VANZARI_DETALII_TEMP` e GTT
-  `ON COMMIT DELETE ROWS`). La orice eroare, rollback total.
-- **Tripleta de mai sus e si ce face ciclul NEUTRU fata de stoc — nu se simplifica.** `sterge_factura`
-  **nu** reverseaza rulajele. Revenirea stocului vine din `PACK_CONTAFIN.STERGE_DIN_RUL`
-  (`UPDATE RUL SET STERS = 1, ID_UTILS = ..., DATAORAS = ...`,
-  `ff_2026_07_29_03_COMUN_PACK_CONTAFIN.sql:1867-1882`, apelata la `:8473`), la care se ajunge prin
-  `finalizeaza_scriere_act_rul(tnScrieSterge = 2)` ← `oscrie_in_fisiere(2, ...)`. Adica **stocul e
-  derivat** din miscari nesterse, iar marcarea lor `STERS = 1` inchide subiectul — dar **numai daca
-  piciorul de stergere chiar trece prin `oscrie_in_fisiere`**. O implementare care „simplifica" pasul
-  la un apel direct de `sterge_factura` ar lasa rulajele in picioare si reemiterea ar descarca
-  gestiunea **a doua oara**, tacut. Verificat pe sursa pachetului.
-  `docs\cercetare\stoc_la_stergere_si_reemitere.md`.
-- **`ID_FACT`.** Se citeste inainte de stergere (vezi capcana `STERS = 0` din E) si se impune
-  documentului nou, printr-un comutator folosit **numai** de regenerare. `SET_IDFACT` nu se schimba
-  neconditionat — e cod comun intregii suite.
-- **`ID_UTIL` / `DATAORA` (audit de creare, S14).** Acelasi tipar ca la `ID_FACT`: se citesc din
-  documentul vechi **inainte** de stergere si se impun explicit documentului nou — altfel `INSERT
-  INTO VANZARI` de la reemitere le rescrie cu utilizatorul si momentul curente, si „data/utilizatorul
-  crearii" se pierde tacut. Detaliu si recomandare de coloane: S14.
-
-**VERIFICAT — se poate, dar cere TREI schimbari simultane, nu una.** Raport:
-`docs\cercetare\idfact_refolosire_si_documente.md`. Verdict: **DA, cu conditii.**
-
-1. **Varianta comentata din `SET_IDFACT` NU rezolva S9** — nu se reactiveaza.
-   (`PACK_CONTAFIN.pck:3016-3035`) cauta documentul pe `NRACT + SERIE_ACT + DATAACT + ID_CTR` cu
-   `STERS = 0`; dupa soft-delete `STERS` e deja 1, deci **nu-l gaseste** si cade tot pe secventa.
-   In plus e vulnerabila la coliziuni cu un document viitor neinrudit care are aceleasi patru campuri.
-   `ID_FACT`-ul se **citeste explicit inainte de stergere** (VFP il are in cursor) si se **transmite**.
-2. **`SET_IDFACT` are nevoie de o cale de intrare noua, inerta implicit.** Azi **nu exista niciun
-   canal**: `pack_contafin.nIdFact` e scrisa neconditionat de fiecare apel, si nu exista alt global sau
-   parametru de sesiune. Solutia cu suprafata minima: **variabila noua de pachet** („ID_FACT fortat",
-   implicit `NULL`), citita **doar in corpul activ** al lui `SET_IDFACT`, consumata si resetata la prima
-   folosire. **Nu se atinge semnatura `SET_IDFACT(V_GCS)`** — altfel s-ar schimba apelul pentru toti.
-3. **Blocajul real nu e in `SET_IDFACT`, ci in `DOCUMENTE`** — si asta e descoperirea care schimba
-   estimarea. Scrierea de azi (`PACK_CONTAFIN.pck:796-817`) e un **`INSERT` simplu** pe `ID_DOC`, care e
-   **PRIMARY KEY** (`PK_DOCUMENTE`, `fn_script.sql:5192-5198`). Stergerea (`STERGE_DIN_ACT:1835-1855`) e
-   **soft-delete pur** — randul vechi ramane fizic in tabel cu `STERS = 1`. Deci reemiterea cu acelasi
-   `ID_FACT`, cu codul de azi, **arunca `ORA-00001`**. Dovada, nu presupunere.
-   `MERGE`-ul deja comentat (`:818-847`) **nu ajuta**: are doar `WHEN NOT MATCHED`, deci ar ignora tacit
-   randul existent si documentul reemis ar ramane cu `STERS = 1`. E nevoie de **upsert real**, cu
-   `WHEN MATCHED THEN UPDATE SET STERS = 0, ...` pe restul coloanelor de identitate.
-
-**Succesiunea corecta**, in aceeasi tranzactie: citeste `ID_FACT` **si lista sursa** -> sterge documentul
-vechi (soft-delete, ca azi) -> seteaza variabila fortata -> scrie documentul nou pe drumul obisnuit ->
-**remigreaza atasamentele** -> commit doar daca toate au reusit; orice eroare -> rollback total,
-documentul vechi intact.
-
-**DOI PASI ADAUGATI DE S11 (runda 13) — niciunul nu „vine gratis" din drumul normal:**
-1. **Citirea listei sursa INAINTE de stergere, si refurnizarea ei la reemitere.** `VANZARI_CORESP` si
-   `marcheaza_facturat` **se rescriu singure** prin `CASE`-ul pe `ntip` din `finalizeaza_factura` — dar
-   **numai daca** `ntip` si lista sursa (`clistaid` / `clistaid_avize`) sunt refurnizate. Ele traiesc in
-   randurile `VANZARI_CORESP` ale documentului **vechi**, care dupa stergere nu mai sunt disponibile.
-   **Fara acest pas nu apare nicio eroare — corespondenta si `FACTURAT` pur si simplu nu se scriu.**
-   Scriere lipsa silentioasa, exact tipul de defect care trece de o verificare vizuala.
-2. ~~**`UPDATE ATASAMENTE_VANZARI SET id_vanzare = :nou`**~~ — **INLOCUIT de decizia 53 (runda 14):
-   atasamentele NU se remigreaza, se sterg la reemitere.** Documentul reemis porneste curat; PDF-ul se
-   regenereaza la prima listare. Pasul ramane **cod nou**, dar e o **stergere**, nu un `UPDATE`
-   (`STERS = 1`, ca sa ramana consistent cu view-ul `VATASAMENTE_VANZARI`, care filtreaza `b.sters = 0`
-   — vezi S11). Consecinta acceptata explicit de Marius: **urma PDF-ului efectiv trimis clientului
-   dispare din sistem.**
-
-**Suprafata de risc pentru suita**, masurata: **~25-30 cai de apel** — cate o copie a lui
-`COMUN\programe\oscrie_in_fisiere.prg` in fiecare produs ROA, plus trei variante care cheama
-`SCRIE_IN_ACT` direct. Toate converg in acelasi punct, `SET_IDFACT(V_GCS)`. **Garantia e structurala,
-nu prin inspectie:** cu variabila implicit `NULL` si citita strict local, toate cele ~25-30 de cai raman
-identice cu azi — nu trebuie verificat fiecare apelant.
-**Dar `INSERT` -> `MERGE` in `DOCUMENTE` e cod comun apelat de toata suita.** Practic ramura noua e
-inerta (secventa e monoton crescatoare, `WHEN MATCHED` nu se declanseaza niciodata pe drumul normal),
-**dar se testeaza un ciclu normal de scriere in fiecare produs care scrie facturi sau note**, nu doar in
-ROAFACTURARE.
-
-*Gata cand:* o editare care mareste cantitatea peste stocul curent trece (stocul documentului
-initial e eliberat inainte); documentul reemis are **acelasi `ID_FACT`, serie, numar si data** ca
-inainte; **randul din `DOCUMENTE` e acelasi, revenit la `STERS = 0`**, nu unul nou; o eroare la scriere
-lasa documentul initial intact; si un ciclu normal de scriere ramane neschimbat in celelalte produse.
-*Depinde de:* S8b.
-
-#### S10 — Pretul care nu trebuie re-derivat
-Inventarul ramurilor din `adauga_articol_factura` (H) si, unde e nevoie, un mod in care preturile
-vin din formular.
-
-**VERIFICAT (runda 9) — `docs\cercetare\s10_pret_rederivat.md`. Verificarea 3 e inchisa.**
-**Exista exact o ramura care suprascrie pretul: contractul.** Cu `OPT_FACTURARE = 3` (sau `NULL`, care
-se implicit-eaza tot la 3), daca `CTR_ARTICOLE.PRET_UNITAR` e diferit de 0, acea valoare **inlocuieste**
-pretul trimis de VFP — `DECODE(A.PRET_UNITAR, 0, V_PRET_TEMP, A.PRET_UNITAR)` — necondiționat de faptul
-ca linia a fost sau nu atinsa pe ecran. Procedura **nu are nicio notiune de „reemitere"**: la fiecare
-apel cu acelasi `V_ID_CTR` se reface derivarea din contract. Pe celelalte ramuri (implicita, restaurant)
-pretul trimis de VFP e respectat ca atare. **Nu exista niciun parametru sau flag care sa opreasca
-re-derivarea** — deci S10 nu poate „cere pachetului sa nu re-derive", trebuie sa lucreze in jurul
-ramurii de contract. Riscul se materializeaza doar cand pretul din contract s-a schimbat intre emitere
-si reemitere; pana atunci rezultatul e identic si nimeni nu observa. Detaliile pe discount, TVA si curs
-sunt in sectiunile 6 si 7 ale raportului.
-**PROIECTAT (runda 13) — `docs\cercetare\s10_pret_contract_reemitere.md`. Faptul portant al rundei 9
-se reconfirma la sursa, dar problema e mai larga decat „pretul".**
-
-- **Nu e doar pretul: acelasi `SELECT` de pe ramura de contract alimenteaza CINCI valori.**
-  **Verificat direct de sesiunea principala** (`PACK_FACTURARE:5149-5166`): `DECODE(A.PRET_UNITAR, 0,
-  V_PRET_TEMP, A.PRET_UNITAR)` **impreuna cu** `B.PROC_TVAV`, `B.ID_VALUTA`, `A.PRET_CU_TVA` si
-  `C.IN_STOC` intra in aceeasi interogare. Raportul semnalase trei (pret, TVA, valuta); sunt **cinci** —
-  se adauga flagul „preturi cu TVA" si **gestionabilitatea**, care vine din **nomenclatorul curent**,
-  nu din document. **Orice garda trebuie sa acopere tot setul**, nu doar pretul.
-- **Nu exista alt loc care suprascrie pretul mai departe in lant** — `scrie_in_vanzari` copiaza `PRET`
-  neschimbat din `VANZARI_DETALII_TEMP` in `VANZARI_DETALII`.
-- **Divergenta e reala, nu ipotetica:** pe baza de dezvoltare, **3 din 11** linii deja facturate pe
-  contract au azi alt pret in contract decat cel facturat. Esantionul e mic si **nu se extrapoleaza** la
-  productie — dar demonstreaza ca situatia se intampla.
-- **Discountul ramane passthrough** — acolo nu e nicio problema.
-- **Recomandarea raportului: varianta (c) — se avertizeaza si se cere confirmare, cu diferenta
-  afisata.** Satisface literal criteriul „decis explicit, nu accidental", se implementeaza **integral in
-  VFP**, fara sa se atinga `pack_facturare`. Variantele: (a) accepta tacit — respinsa, e exact ce cere
-  criteriul sa nu se intample; (b) blocheaza — mai sigura, dar frustranta daca divergentele sunt dese;
-  (d) ocoleste ramura trimitand `V_ID_CTR = NULL` — **respinsa motivat**, pierde **permanent** legatura
-  `VANZARI_DETALII.ID_CTR`.
-- **„Reemitere identica" nu e garantata uniform:** pe ramurile `ELSE` / restaurant, da; pe **comenzi**
-  esueaza **tare** (eroare, deci vizibila); pe **contract** si pe **aviz (`ntip = 4`)** esueaza **tacit**.
-  Riscul pe aviz **nu fusese semnalat pana acum** ca decizie explicita.
-
-**GOLUL LUI S8b E INCHIS — `cursor_retur_document` NU re-deriva pretul.** Verificat direct de sesiunea
-principala (`PACK_FACTURARE:3960-4062`): pretul vine din **`VANZARI_DETALII.PRET`** stocat, printr-un
-`FROM VANZARI_DETALII A1` fara niciun `JOIN` catre `CTR_ARTICOLE` sau catre politici; `PROC_TVAV` la fel,
-din document. **Deci mecanismul de detectare a schimbarii din S8b e valid** — un document deschis nu
-apare „modificat" din cauza citirii. **Confirmat independent si pe partea VFP** (raportul S10): in
-`ofacturare.prg:266-283`, ramura `Case m.llCopiere` are **prioritate indiferent de tip** — pentru un
-document de contract (`2,6,26,52`) **nu se ajunge deloc** la `cursor_contract` la incarcare. Citirea si
-scrierea sunt guvernate de **cursoare complet diferite, fara cod comun**: riscul de suprascriere tacita
-apare **strict la re-scriere**, niciodata la deschidere. O garda pusa la scriere nu afecteaza citirea si
-nu e afectata de ea.
-> **Dar citirea nu e o copie curata, si asta conteaza pentru S12.** Pretul returnat e
-> `ROUND(A.PRET, nzecimale_pretv) + A.DIFERENTA` (pe valuta: `ROUND(CURS * ROUND(PRET, ...) /
-> MULTIPLICATOR, ...) + DIFERENTA`). Adica **rotunjit la precizia de sesiune si cu `DIFERENTA` pliata
-> inauntru**. La reemitere se trimite inapoi valoarea pliata, deci **impartirea `PRET` / `DIFERENTA` se
-> reface**, nu se conserva. De verificat in S12 ca o reemitere identica reproduce **suma**, chiar daca
-> nu reproduce neaparat aceeasi impartire — si ca `DIFERENTA` nu se acumuleaza la reemiteri repetate.
-
-### RASTURNAT de decizia 54 (Marius, runda 14) — nu garda, ci eliminarea re-derivarii
-
-Cele trei intrebari de mai sus (blocare vs. avertizare; ramura de aviz; masurarea frecventei) **sunt
-inchise, si nu prin alegerea uneia dintre variante — prin respingerea premisei lor.** Formularea lui
-Marius: *„nu inteleg de ce se schimba valorile fata de ce se incarca din factura sursa care se modifica?
-asta este comportamentul pe care il doresc — modific sursa"*.
-
-**Deci:** la reemitere se scriu **valorile din formular** (incarcate din documentul editat), nu se
-reciteste sursa. Nu se cere utilizatorului sa confirme o schimbare pe care n-a cerut-o. Variantele
-(b) si (c) **cad amandoua**; ramane obiectivul (a-invers): re-derivarea, unde exista pe calea de
-reemitere, se **elimina**.
-
-**Si aici e problema reala, spusa pe fata:** runda 9 a stabilit deja ca **„nu exista niciun parametru
-sau flag care sa opreasca re-derivarea"**, iar singura varianta care ocolea ramura — (d), `V_ID_CTR =
-NULL` — a fost **respinsa motivat**, pentru ca pierde permanent legatura `VANZARI_DETALII.ID_CTR`.
-Prin urmare decizia 54 **cere, cel mai probabil, o modificare in `pack_facturare`** (un semnal „nu
-re-deriva, foloseste ce ti-am trimis" pe `adauga_articol_factura`), nu o solutie curat VFP. Asta atinge
-un pachet din `COMUN`, partajat de toata suita — **iar modificarile de pachet se aplica tuturor
-deodata, fara cale de intoarcere prin alegerea de la decizia 49.** Trebuie proiectata ca inerta pentru
-apelantii de azi (implicit = comportamentul actual), exact ca la S4g.
-
-**VERIFICAT in runda 14 — `docs\cercetare\s10_rederivare_pe_calea_reemiterii.md`.** Confirmat pe fisier
-**si** pe DB (`all_source`, corp VALID, `last_ddl_time = 2026-08-09 20:03:50`).
-
-**Se pierd intr-un SINGUR loc:** `adauga_articol_factura`, in `CASE`-ul de la `PF:5052-5220`, adica
-**inainte** de `INSERT INTO VANZARI_DETALII_TEMP` (`PF:5222`). Tot ce urmeaza — copierea temp →
-`VANZARI_DETALII` (`PF:13705-13757`) — e **1:1**, deci „copiaza `PRET` neschimbat" e adevarat dar **nu
-e o protectie**: dauna e amonte de temp.
-
-**RAMURILE CARE RE-DERIVA SUNT TREI, NU UNA. Raportul rundei 9 gresea.**
-
-| valoare | **contract** (2/6/26/52) | **aviz** (`ntip = 4`) | **comenzi** (3/21/28/42/47) | restaurant (45) | `ELSE` |
-|---|---|---|---|---|---|
-| `PRET` | re-derivat din `CTR_ARTICOLE.PRET_UNITAR` daca `<> 0`; temp daca `= 0`; **NULL daca e NULL** (`PF:5149`) | **re-derivat neconditionat** din avizul sursa (`PF:5082`) | temp de facto — `WHERE A.PRET = V_PRET_TEMP` (`PF:5077`) | temp | temp |
-| `PROC_TVAV` | re-derivat din `CRM_POLITICI_PRET_ART` | re-derivat din aviz | re-derivat din `COMENZI_ELEMENTE.PTVA` | derivat din `JTVA_COLOANE` | derivat din `JTVA_COLOANE` pe `ID_JTVA_COLOANA` **din formular** |
-| `ID_VALUTA` | re-derivat | re-derivat | re-derivat | temp | temp |
-| `PRET_CU_TVA` | re-derivat | re-derivat | re-derivat | temp | temp |
-| `IN_STOC` | re-derivat din `NOM_ARTICOLE` | re-derivat | re-derivat | temp | temp |
-
-- **Ramura AVIZ e cea mai agresiva din tot `CASE`-ul** (`PF:5080-5103`): `PRET` se inlocuieste
-  **neconditionat**, nu exista nici `DECODE`, nici `AND A.PRET = V_PRET_TEMP`, **si nu exista bloc
-  `EXCEPTION`**. Un pret modificat pe ecran e inlocuit tacit. In plus **nu filtreaza `A.STERS = 0`**,
-  desi coloana exista — linii sterse ale avizului sursa pot fi citite. Si depinde de `clistaid`, care
-  la reemitere **trebuie repopulata** (leaga direct de pasul 1 adaugat in S9).
-- **Ramura comenzi esueaza tare, nu tacit** — fara `EXCEPTION`, o linie care nu se mai potriveste da
-  **ORA-01403**, vizibila. Mai putin periculoasa, dar tot re-derivare.
-- **Ramura contract are o portita** — `EXCEPTION WHEN NO_DATA_FOUND` (`PF:5167-5185`) pune **toate cele
-  cinci** pe valorile din formular. **Comportamentul cerut de decizia 54 exista deja in cod**, dar
-  numai pe calea de exceptie. Aviz si comenzi **nu au** asa ceva.
-- **Capcana NULL, dedusa din semantica `DECODE`, nerulata:** daca `CTR_ARTICOLE.PRET_UNITAR` e `NULL`
-  (nu `0`), `DECODE` nu potriveste literalul `0` → rezultatul e **NULL**, deci pretul din formular se
-  pierde complet si linia intra cu `PRET` gol. In dev cazul nu apare (27 randuri, 0 NULL) — **ceea ce
-  nu spune nimic despre productie**.
-- **`PROC_TVAV` nu vine din formular pe NICIO ramura** — nu e parametru al procedurii. Pe calea „buna"
-  se deriva din `JTVA_COLOANE` pe `ID_JTVA_COLOANA`-ul trimis de formular, deci reproduce documentul
-  **doar cat timp cota nu s-a schimbat**. La o modificare legala de cota, reemiterea schimba TVA-ul
-  **chiar si pe `ELSE`**.
-- **`IN_STOC` nu ajunge in `VANZARI_DETALII`** — coloana nu exista (verificat pe DB). Traieste doar in
-  temp, unde decide **descarcarea de gestiune**.
-- **Dupa insertul in temp nimic nu mai suprascrie cele cinci valori.** `adauga_diferente_pret` atinge
-  numai `DIFERENTA`, `scrie_factura_avize` numai `CANTITATE`, `scrie_seturi` numai `ID_VANZARE_SET`.
-
-### Cum se implementeaza decizia 54
-
-**Curat VFP nu se poate — confirmat cu dovada pozitiva, nu prin absenta.** Semnatura n-are comutator
-(`PF:4989-5015`, 27 de parametri, toti date de linie); globalele pachetului n-au (`PF:126-212`); poarta
-`CASE`-ului se decide pe `ntip` (care ajunge in `VANZARI.TIP`, deci nu se poate falsifica) si pe
-`CONTRACTE.OPT_FACTURARE` (date de contract, nu parametru). Singurele parghii VFP care ar devia pe
-`NO_DATA_FOUND` sunt `V_ID_CTR = NULL` — **deja respinsa** — si `V_ID_POL = NULL`, care are **exact
-acelasi defect pe alta coloana** (`PF:5258` → `temp.ID_POL` → `PF:13737` → `VANZARI_DETALII.ID_POL`) si
-in plus ar rupe ramura aviz, care potriveste pe `A.ID_POL`. **Notata aici tocmai ca sa nu fie
-redescoperita ca „solutie" intr-o runda urmatoare.**
-
-**Deci decizia 54 cere obligatoriu modificare in `pack_facturare`** — dar mica, si care nu adauga
-comportament nou:
-
-- **Semnalul:** variabila noua de pachet („regenerare in curs"), implicit `0` = comportamentul de azi,
-  scrisa de VFP **dupa** `initializeaza_date_factura` (`ofacturare.vc2:13981`) si inainte de bucla de
-  `adauga_articol_factura`. *Recomandata* fata de un parametru `DEFAULT 0`, din trei motive: se
-  potriveste cu stilul pachetului (deja o punga de stare de sesiune); se scrie o data pe document, nu
-  o data pe linie, in toate produsele; si **punctul de resetare exista deja** —
-  `initializeaza_date_factura` (`PF:1808-1917`) reinitializeaza ~40 de globale si goleste temp
-  (`PF:1835`), deci flag-ul nu poate scapa in documentul urmator.
-- **Ce face:** un `WHEN` nou, **primul** in `CASE`-ul de la `PF:5052`, cu **acelasi corp ca `ELSE`-ul de
-  azi** (`PF:5189-5203`). Nimic inventat — se forteaza ramura care exista deja. **Acopera dintr-o data
-  toate trei ramurile problematice**, fiind in acelasi `CASE`. `INSERT`-ul de la `PF:5222` ramane
-  neatins.
-- **Inert prin constructie** pentru toti apelantii de azi, exact ca la S4g. **Consecinta de livrare:
-  DB inainte de EXE.**
-
-### Trei consecinte de acceptat explicit, nu de descoperit la S12
-
-1. **`IN_STOC` ar veni din formular.** Nu murdareste documentul (coloana nu exista), dar schimba
-   **comportamentul de stoc** al reemiterii. Ca reemiterea sa fie identica, **S8 trebuie sa incarce
-   valoarea cu care s-a scris documentul initial** — si **azi nu o incarca**: loader-ul lui #6 o citeste
-   din nomenclatorul curent (`ofacturare_editare.prg:302-303`). **Flag-ul singur nu rezolva asta.**
-   **PRELUAT (runda 17) ca cerinta de executie in S8**, cu cele trei consecinte pentru canalul de citire
-   si criteriul de test — vezi caseta „CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17" din S8. Aici nu mai e
-   nimic de decis.
-2. **Se pierde o validare pe ramura comenzi.** Azi, `A.PRET = V_PRET_TEMP` + lipsa lui `EXCEPTION` fac
-   ca o linie care nu se mai potriveste cu comanda sa **opreasca** scrierea. Cu flag-ul pornit,
-   reemiterea unei facturi din comanda nu mai verifica linia fata de comanda. Decizia 54 pare sa vrea
-   exact asta, dar e schimbare de comportament — **se declara, nu se descopera**.
-3. **`PROC_TVAV` ramane derivat, nu preluat.** Reproducerea exacta cere ca S8 sa pastreze
-   `ID_JTVA_COLOANA` **si** ca `JTVA_COLOANE` sa nu se fi schimbat. Daca se cere reproducere exacta si
-   peste o modificare legala de cota, `PROC_TVAV` trebuie sa devina **parametru** — schimbare mai mare
-   decat flag-ul, **de decis separat**.
-
-### Obstacol pentru S9, gasit in treacat
-
-**`VVANZARI_ARTICOLE` nu expune `ID_POL` si nu expune `ID_CTR`** (lista de coloane interogata pe DB) —
-exact cei doi pe care `adauga_articol_factura` ii cere (`V_ID_POL`, `V_ID_CTR`) si pe care
-`VANZARI_DETALII` ii pastreaza. **Reemiterea nu poate folosi acest view ca atare**: ori se completeaza
-view-ul, ori loader-ul citeste direct din `VANZARI_DETALII`. Se leaga de intrebarea 1 din S8 (canalul de
-citire a liniilor) — **un argument in plus pentru varianta (B), procedura noua.**
-
-*Gata cand:* pentru fiecare tip, documentul reemis are **exact valorile din formular** — pret, TVA,
-valuta, flag „preturi cu TVA" — iar o reemitere fara modificari reproduce documentul identic, inclusiv
-dupa ce pretul din contract s-a schimbat intre timp.
-*Depinde de:* S9.
-
-#### S11 — Legaturile care raman pe `ID_VANZARE`
-`ID_FACT`, seria, numarul si data se pastreaza (E, F), deci legaturile prin `ID_FACT` sunt in
-regula. Ramane discontinuitatea pe **`ID_VANZARE`**, care se schimba: `ATASAMENTE_VANZARI`,
-`marcheaza_facturat`, `vanzari_coresp`, si eventualele referinte de incasari / plati.
-De verificat si daca `DOCUMENTE` primeste un al doilea rand pe acelasi `ID_DOC` sau il refoloseste.
-
-**PROIECTAT (runda 13) — `docs\cercetare\s11_legaturi_id_vanzare.md`. Inventarul s-a facut prin
-FK-urile reale din Oracle, nu prin grep — si asta a scos doi consumatori pe care nicio cautare de text
-nu-i gasise.**
-
-- **Premisa centrala, corectata: mecanismul lui #6 NU se mosteneste de S9.** La #6, documentul isi
-  **pastreaza randul** din `VANZARI` — `actualizeaza_vanzari` face `UPDATE ... SET COD = nou,
-  STERS = 0`, deci **`ID_VANZARE` nu se schimba**, doar `COD`, si atasamentele se realiniaza in acelasi
-  gest. La S9, reemiterea merge pe drumul normal de emitere (`INSERT ... RETURNING ID_VANZARE`), deci
-  **rand nou, cheie noua, si `actualizeaza_vanzari` nu se declanseaza deloc.** Tot ce e protejat azi
-  tacit de #6 e **expus** la regenerare. Asta nu era in plan.
-- **Sapte tabele au FK declarat pe `VANZARI.ID_VANZARE`. Doua nu erau in nicio lista:**
-  **`REST_NOTE_PLATA`** (modul restaurant) si **`IPS_VOYAGES_VANZARI`** (modul specific unui client).
-  Clasificate **(A) suspecte** — pachetele lor PL/SQL n-au fost citite integral.
-  **INCHIS de Marius, runda 14 — riscul dispare, si nu prin presupunere.** Intrebat direct, a raspuns:
-  *„daca este vorba despre facturarea voiajelor din ROAACNPRO, acolo nu merge modificarea de genul
-  acesta, ci doar editarea de la #6"*. **Documentele acestor module sunt IN AFARA domeniului
-  regenerabil al #13** — pentru ele ramane calea #6 (modificare pe loc). Pachetele lor **nu mai trebuie
-  citite**. Doua consecinte de dus mai departe: **(a) garda lui S7 trebuie sa le refuze EXPLICIT**, nu
-  doar sa nu le trateze — altfel „in afara domeniului" e o intentie, nu o garantie; **(b)** conditia se
-  declara in S13, la actualizarea `tipuri_documente_facturare.md`.
-- **`ATASAMENTE_VANZARI` — corectie de premisa, in favoarea noastra.** **Nu** sunt documente incarcate
-  de utilizator: sunt **PDF-uri auto-generate la listare** (`poDate.scrieAtasamente()` dupa
-  `export2pdf`; cursorul nu vine din niciun dialog de fisier — cautat explicit, zero potriviri). Deci
-  **nu e pierdere ireparabila**, cum presupusese briefingul. Se rup totusi real: view-ul
-  `VATASAMENTE_VANZARI` filtreaza pe `b.sters = 0`, deci dupa regenerare atasamentele vechi **dispar
-  tacit** din toate interogarile (inclusiv din ROAGEST / ROAIMOB), desi BLOB-ul ramane fizic.
-  ~~**(A) — remigrare printr-un simplu `UPDATE ... SET id_vanzare = :nou`**~~ — **INCHIS altfel,
-  decizia 53 (runda 14): se STERG la reemitere.** Marius a ales a treia varianta, nici remigrare, nici
-  marcaj „versiune inlocuita". Documentul reemis porneste curat. **Consecinta i-a fost spusa explicit
-  si a acceptat-o:** motivatia care sustinea remigrarea — *pastrarea urmei PDF-ului trimis clientului* —
-  **cade odata cu ea**; dupa editare nu mai exista in sistem dovada a ce a primit clientul. Punctul 15
-  se inchide aici.
-- **Incasarile si platile nu sunt afectate — si dovada e structurala, nu statistica:** niciun tabel de
-  incasari/plati n-are FK pe `ID_VANZARE`, si nici referinta text. Se leaga prin **`ID_FACT`**, care se
-  pastreaza. **(C)**, cu dovada dubla.
-- **eFactura, `DOCUMENTE`, listarile, `VANZARI_CANTITATI` — (C)**, toate cheiate pe `ID_FACT` sau
-  rescrise automat.
-
-**INCHISE, nu de reintrebat (marcaj pus in runda 17).** Punctul 1 e transat de cercetarea garzilor din runda 14 (garda exista si e corecta; S7 o muta in pre-flight read-only) — ramane **limitare declarata**. Punctul 2 e rasturnat de **decizia 53**: atasamentul vechi **nu se remigreaza, se sterge**, deci premisa „factura editata ajunge cu PDF-ul vechi" nu se mai produce. Punctul 3 e inchis in runda 14, cu cerinta ca **S7 sa refuze explicit** cele doua tipuri. Se pastreaza ca inventar:
-1. **Editarea unui document care are deja retur emis pe el e azi BLOCATA, nu doar riscanta** —
-   `sterge_factura` arunca `ORA-20000`. Garda e corecta (protejeaza lantul), iar **S7 planifica deja
-   sa semnaleze conditia inainte de intrarea in formular**, nu ca eroare Oracle la final. Ce ramane de
-   decis: se accepta ca **limitare declarata** (utilizatorul sterge intai documentele-copil), sau se
-   vrea alt comportament?
-2. **Atasamentul vechi arata continutul dinainte de editare.** Remigrat pe documentul nou, factura
-   editata ajunge sa aiba atasat PDF-ul **vechi**. De decis daca asta e exact ce se vrea (audit trail),
-   sau daca vechiul ar trebui marcat cumva ca „versiune inlocuita".
-3. **`REST_NOTE_PLATA` / `IPS_VOYAGES_VANZARI`** — de confirmat ca tipurile lor sunt in afara
-   domeniului regenerabil.
-
-*Gata cand:* documentul reemis se regaseste corect in borderoul eFactura, in listari, in atasamente
-si in rapoartele care il cauta dupa numar.
-*Depinde de:* S9.
-
-#### S12 — Test pe fluxul real, regenerarea
-Cate un caz pe fiecare sursa, rulat de doua ori (o data fara modificari — reemitere identica, o data
-cu modificari de cantitate, pret si linii adaugate / sterse). Se verifica: documentul initial
-`sters = 1` cu nota si rulajele lui, documentul nou corect, sursa eliberata **si** reconsumata
-(comanda redevine facturabila si redevine facturata), stocul corect dupa ciclu, totalurile
-denormalizate din `VANZARI`, si ca o reemitere identica produce **exact** aceleasi sume.
-
-**Probe adaugate de runda 13:**
-- **Reemitere repetata de trei ori pe acelasi document** — `DIFERENTA` **nu se acumuleaza**. Motivul:
-  `cursor_retur_document` intoarce pretul deja **rotunjit si cu `DIFERENTA` pliata inauntru** (S10), iar
-  reemiterea trimite inapoi valoarea pliata, deci impartirea `PRET` / `DIFERENTA` se **reface** la
-  fiecare ciclu. Se verifica **suma**, nu impartirea — dar se verifica si ca impartirea nu deriveaza.
-- **„Reemitere identica" nu e garantata uniform** (S10): pe `ELSE` / restaurant da; pe **comenzi**
-  esueaza **tare** (eroare vizibila); pe **contract** si pe **aviz (`ntip = 4`)** esueaza **tacit**.
-  Fiecare din cele patru situatii isi are cazul lui de test, cu rezultatul asteptat **declarat dinainte**
-  — inclusiv cele care trebuie sa dea eroare.
-- **Deschid si inchid fara sa modific nimic → nicio scriere** (S8b), rulat pe un document al unui client
-  **cu activitate recenta** — cazul in care lookup-ul „ultimul delegat / masina" ar polua antetul.
-
-*Depinde de:* S10, S11.
-
-#### S14 — Audit: creare, modificare si stergere pe document
-
-**Cerinta (decizia 63):** pentru fiecare document, sase informatii de audit — data + utilizator
-pentru creare, pentru modificare (daca e cazul) si pentru stergere (daca e cazul).
-
-**Cercetarea s-a terminat** — `docs\cercetare\audit_vanzari_creare_modificare_stergere.md`.
-Verificat pe `all_tab_columns` (`ROA_CENTRAL`, schema live) si pe cod.
-
-**Ce exista deja, pe `VANZARI`:**
-- `ID_UTIL` + `DATAORA` — **creare**, ambele `NOT NULL`, scrise consecvent la fiecare `INSERT`
-  (`PACK_FACTURARE.scrie_in_vanzari`, `EXPORT:13598-13640`, si a doua ruta din
-  `finalizeaza_avize_lucrare`, `EXPORT:14930`). Niciun `UPDATE VANZARI SET ID_UTIL/DATAORA` in tot
-  pachetul (cautare directa, zero rezultate).
-- `ID_UTILS` + `DATAORAS` — **stergere**, nullable, scrise consecvent de `sterge_factura`
-  (`EXPORT:5496-5499`) si `sterge_proforma`.
-- (neceruta, dar arata conventia) `ID_UTILFACT` + `DATA_FACTURAT` — facturare din aviz.
-- Pe `VANZARI_DETALII`: acelasi tipar de creare/stergere, plus `ID_UTIL_VALID` + `DATAORA_VALID`
-  (validare).
-
-**Conventia casei:** o pereche utilizator + data per eveniment. Patru din cele sase informatii
-cerute exista deja si se scriu consecvent.
-
-**Ce lipseste, integral:** nicio coloana de **modificare**, nici pe `VANZARI`, nici pe
-`VANZARI_DETALII`. Interogat explicit `all_tab_columns` cu filtru pe `%MODIF%` — zero rezultate.
-`DATA_ACT` nu e echivalentul: e data contabila, propagata in `ACT`/`DOCUMENTE`/`JV2007`/`RUL`
-(verificat in `modifica_date_factura`, `EXPORT:14439-14500`), nu un marcaj de audit.
-
-**Capcana, si e miezul povestii:** editarea din #13 se face prin stergere + reemitere (S9), iar
-documentul nou se scrie pe **acelasi `INSERT`** ca o creare normala (`scrie_in_vanzari`). Fara un
-pas explicit, `ID_UTIL` / `DATAORA` ale documentului reemis ar deveni tacut utilizatorul si data
-**modificarii**, iar informatia despre creare s-ar pierde — exact ce cere decizia 63 sa nu se
-intample. **Precedentul de rezolvare exista deja in plan, pentru `ID_FACT`** (sectiunea „E.
-`ID_FACT`", linia 762, si S9: se citeste din documentul vechi inainte de stergere si se impune
-celui nou). **Niciun pas echivalent nu e proiectat azi pentru `ID_UTIL` / `DATAORA`** — cautare
-directa in tot planul, zero mentiuni.
-
-**Atenuare, nu solutie:** la regenerare randul vechi ramane cu `STERS = 1` si cu `ID_UTILS` /
-`DATAORAS` completate — iar acea stergere **este** momentul modificarii. Cum `ID_FACT` se pastreaza
-peste regenerare, lantul vechi → nou e parcurgibil, deci o parte din istoric e reconstruibila din
-randurile existente, fara coloane noi. O pereche explicita pe documentul curent ramane insa
-preferabila: se citeste direct, fara parcurgerea lantului.
-
-**Complicatie reala, verificata pe cod livrat de #6:** editarea de linie
-(`COMUN\programe\ofacturare_editare.prg`) scrie `id_utils` / `dataoras` pe `VANZARI_DETALII` si pe
-randuri care **nu sunt sterse** — `ofacturare_editare.prg:492-494` (corect, cu `sters = 1`),
-`:501-505` (odata cu `sters = 0`, pe rand viu) si `:522-525` (pe un rand proaspat inserat). Acolo
-perechea de stergere e folosita ca marcaj „cine a umblat ultima data", nu strict ca „sters de/la".
-**Consecinta:** un raport de audit nu poate citi `ID_UTILS` / `DATAORAS` ca „sters de/la" fara sa
-puna si `STERS` in conditie. `ofacturare_editare.prg` e perimetrul lui #6, in lucru — semnalat aici,
-neatins.
-
-**Recomandare (de confirmat, nu decisa):**
-1. **O singura pereche noua pe `VANZARI`**, urmand conventia casei — nume propus
-   `ID_UTILM` / `DATAORAM` (utilizator si data ultimei modificari). Numele e de confirmat.
-2. **La regenerare (S9): `ID_UTIL` / `DATAORA` se transporta din documentul vechi in cel nou**,
-   exact ca `ID_FACT` — vezi nota adaugata la S9. Perechea noua de modificare primeste utilizatorul
-   curent si `sysdate`. Fara acest pas, creare si modificare se suprapun.
-3. **Perechea de stergere nu are nevoie de nimic** — exista si e scrisa consecvent.
-4. **Cere migrare de DB** (`ALTER TABLE` pe `VANZARI`) — **DB inainte de EXE**, ca la S10. Scriptul
-   intra in `D:\ROA\DATABASE\SCRIPTURI_CLAR\`, `versiune_db.txt` se bumpeaza.
-
-**De decis cu Marius — AMBELE INCHISE prin decizia 65 (runda 16):**
-- **(a)** Auditul e cerut numai pe antet (`VANZARI`) sau si pe linii (`VANZARI_DETALII`)? **Raspuns
-  prin deductie, nu spus explicit de Marius:** locul de afisare ales de el e gridul din `frm_facturi`,
-  care listeaza **documente** — deci auditul e pe **antet**.
-- **(b)** Se afiseaza undeva in interfata (formular / lista), sau ramane doar pentru interogare?
-  **Da, se afiseaza** — in **gridul din `frm_facturi`**, nu in formularul facturii propriu-zise.
-  Prim pas de implementare: inventarul acelui grid, posibil sa existe deja coloane de audit.
-
-*Gata cand:* documentul reemis pastreaza `ID_UTIL` / `DATAORA` ale creatiei originale; perechea noua
-de modificare e completata la fiecare regenerare, cu utilizatorul si momentul curente; perechea de
-stergere ramane neschimbata fata de azi; migrarea DB e aplicata inainte de EXE.
-*Depinde de:* S9.
-
-#### S13 — Diff, review, changelog, documentatie
-
-**Atentie: S13 NU e momentul in care se face review-ul.** Conform metodei de executie, **fiecare story
-isi are propriile teste, propriul diff si propriul code review, inainte de commit-ul ei** — S13 nu
-strange la final ce n-a fost revizuit pe parcurs. Ce ramane aici e **inchiderea**, adica exact ce nu se
-poate face per story:
-
-- **Review de ansamblu**, pe suma povestilor: coerenta intre ele, cai ramase orfane, cod mort din
-  fluxul vechi care trebuia retras si n-a fost, si verificarea ca alegerea de la decizia 49 chiar
-  functioneaza in ambele sensuri.
-- **Changelog** `:nou:`, cu mentiunile declarate explicit pe parcurs: asimetria `do_modifica`
-  corectata prin recalculul la cerere (decizia 45), si faptul ca `do_modifica` ramane activ pentru
-  multi-selectie (decizia 52).
-- **Documentatie**: `COMUN\docs\tipuri_documente_facturare.md` — ce tipuri sunt regenerabile si ce
-  tipuri sunt **declarate explicit ca neacoperite** (48/49 si `frm_facturare_articole2`, daca se merge
-  pe recomandarea din S8), plus confirmarea din S11 pentru `REST_NOTE_PLATA` si `IPS_VOYAGES_VANZARI`.
-- **Rularea suitei complete** — toate testele scrise per story, la un loc, nu doar cele ale ultimei
-  povesti.
-- **Commit-urile finale**, in **ambele** repo-uri (ROAFACTURARE si COMUN), dupa aprobare.
-
----
-
-## Riscuri
-
-- ~~**Cel mai mare: perimetrul comun cu #6.**~~ **Inchis prin decizia 30** — implementarea lui #13
-  incepe dupa terminarea lui #6, deci nu exista doi scriitori simultan pe `ofacturare_comun.vc2` /
-  `ofacturare_editare.prg`. Riscul revine doar daca ordinea se schimba.
-- ~~**Riscul „cod nou in `pack_facturare`" e evitat prin constructie (decizia 27-bis).**~~ **Caduc dupa
-  deciziile 34 si 35, si riscul revine ca risc principal.** Politica tehnica per `SCC` si scrierea in
-  `CRM_POLITICI_PRET_ART` nu se mai fac — deci cade si riscul ca o politica tehnica sa apara in
-  `caut_politici_curente_util()`. In locul lui: **`pack_facturare` se modifica** (parametru de cont +
-  ramura fara politica in `contabilizeaza_articol`), iar pachetul e **comun intregii suite** — ROACONT,
-  ROAGEST, ROACONTRACTE, ROAAUTO, ROAACNPRO. Mitigarea e structurala, nu prin inspectie: parametru
-  **`DEFAULT NULL` la finalul listei** si ramura inerta cand lipseste, astfel incat apelantii existenti
-  sa fie identici cu azi.
-  **MASURAT — `docs\cercetare\suprafata_regresie_contabilizeaza_articol.md`. Riscul e mai mic decat parea.**
-  `contabilizeaza_articol` are **trei apelanti, toti interni pachetului**, toti pozitionali cu acelasi
-  singur argument — **zero apelanti externi, nici PL/SQL, nici VFP, in niciunul din cele sapte produse**.
-  `adauga_articol_factura` e apelata **pozitional peste tot**, niciodata cu notatie pe nume (`=>`), iar
-  cele sapte copii `COMUN\clase\ofacturare.vc2` sunt **acelasi sit de apel duplicat**, nu sapte
-  implementari care ar putea diverge: fisierele difera intre ele (patru variante distincte pe MD5), dar
-  **textul apelului e identic cuvant cu cuvant**, doar offsetul de linie difera. Exista in plus doua
-  implementari proprii reale — ROAGEST (`Programe\ofactureaza.prg:264`) si ramura `_deviz` din ROAAUTO /
-  ROAACNPRO.
-  **Precedentul e activ, nu teoretic:** ROAGEST apeleaza azi `adauga_articol_factura` cu **24 din 25 de
-  parametri**, omitand `V_TAXCODE` si `V_LOT` tocmai pentru ca au `DEFAULT NULL`. Tiparul propus e deja
-  in uz in productie.
-  **Ce ramane:** toate cele **sapte** produse emit efectiv prin acest pachet, deci aria de regresie e
-  toata suita chiar daca niciun apelant nu se modifica.
-- ~~**Anomalie preexistenta: `scrie_factura2` apelata cu 16 din 17 parametri.**~~ **INCHISA — fals
-  pozitiv, nu intra ca risc.** `oExecuta` (`COMUN\programe\oproceduri_comune.prg:121-159`) deleaga la
-  `oExecute` (`:173-504`), care face `SQLExec(lnHandle, lcSql, lcCursor)` (`:330`) — **textul SQL nu e
-  rescris**, deci al 17-lea parametru chiar n-are placeholder. Explicatia e tiparul cunoscut al
-  driverului ODBC Oracle: cand ultimul parametru declarat e un `REF CURSOR OUT`, driverul il ia din
-  catalog, nu din textul apelului, si intoarce randurile ca *result set* — captat exact de al treilea
-  argument al lui `SQLExec`. *Nuanta de pastrat:* mecanismul din interiorul driverului **nu poate fi
-  confirmat din codebase**, e verificabil doar prin comportament; dovada e indirecta, dar consistenta —
-  acelasi tipar in toate cele patru situri, neschimbat de la `v 2.0.13` la `v 2.0.93`, iar ecranul de
-  verificare depinde de acel cursor populat la fiecare emitere, deci un apel esuat s-ar fi vazut demult.
-- **Decizia 35 leaga etapa II de aceeasi modificare de pachet.** Editarea prin regenerare nu mai are cale
-  proprie (canalul `oscrie_in_fisiere` e respins ca al doilea cod de contare), deci **un blocaj pe
-  parametrul deciziei 34 blocheaza si S9-S12**, nu doar etapa I. In schimb dispare riscul de divergenta
-  intre regula de contare de la emitere si cea de la editare.
-- **`ofacturare.vc2` e in COMUN si are 843 KB / 25 de clase**, folosite de toata suita. Formularul
-  vechi trebuie sa ramana functional pana cand cel nou acopera toate tipurile — deci comutator, nu
-  inlocuire.
-- **`ID_FACT` pastrat cere atingerea unui punct comun intregii suite.** `SET_IDFACT` e in
-  `PACK_CONTAFIN` si e chemat de fiecare scriere de note din toate produsele ROA. Comutatorul din S9
-  trebuie sa fie inert pentru toate celelalte cai; altfel regresia nu e in ROAFACTURARE, ci peste tot.
-- **Formularul identic la introducere si la modificare taie o plasa de siguranta.** Decizia 9 o repune
-  **doar pe antet** — butonul protejeaza campurile de antet, nu si liniile. Pe articole nu exista niciun
-  semnal ca modificarea va sterge si va rescrie documentul; confirmarea de la `Termina` ramane
-  singurul moment in care se poate spune ce urmeaza sa se intample. De formulat cu grija.
-- **Ascunderea datei de curs poate lasa un document fara curs corectabil.** `poDate.zi_curs` se
-  trimite neconditionat catre cursoarele de articole; daca lipseste cursul pentru acea zi, Oracle da
-  eroarea 20005 si se deschide formularul de curs — dar utilizatorul nu mai are unde sa corecteze data
-  daca i-am ascuns campul. Regula din M trebuie sa aduca inapoi campul in exact acest caz.
-- **Sectiunea pliata ascunde campuri care schimba documentul.** Analiticele si datele de incasare
-  intra sub un panou inchis implicit. Daca un camp obligatoriu pe un anumit tip ajunge acolo,
-  utilizatorul primeste eroarea fara sa vada campul. Panoul trebuie sa se deschida singur cand
-  contine un camp necompletat si obligatoriu, si sa arate in antet ca are ceva completat.
-- **Mutarea `frm_alte_date` muta si alocarea de numere.** Bonul fiscal, POS-ul si chitanta primesc
-  numar din masina de stari a incasarii. Daca ea ajunge sa ruleze la deschiderea formularului in loc
-  de la alegerea tipului de incasare, se aloca numere pentru documente care nu se mai emit.
-- **`S3c` si `S4c` ating cod comun.** Parametrizarea sursei atinge `factureaza` (toata suita), iar
-  discountul editabil atinge listarile si eventual eFactura. Fiecare merge separat, cu regresie
-  proprie.
-- **Reemiterea nu e idempotenta prin constructie.** Daca la reemitere pretul se re-deriva (H) sau
-  cursul valutar al zilei difera, documentul "nemodificat" iese cu alte sume decat originalul.
-  Testul din S12 (reemitere identica) exista tocmai ca sa prinda asta.
-- **`verifica_total_document`** (`PACK_FACTURARE:16009+`) insereaza automat o linie de corectie cand
-  totalul difera de suma notelor. La regenerari repetate trebuie confirmat ca nu se acumuleaza —
-  aceeasi intrebare ca S7 din #6.
-- **Cautarea in linie schimba un obicei.** Utilizatorii care lucreaza azi cu gridul de articole
-  vizibil si filtrare locala pierd vederea de ansamblu. Merita verificat pe un client inainte de a
-  scoate definitiv gridul vechi.
-
-## Dependente
-
-- **#7 (pret cu TVA pe linie)** — flagul `pret_cu_tva` pe linie apare in gridul unificat; se
-  pastreaza comportamentul stabilit acolo.
-- **#12 (nomenclator ca lista de preturi)** — S4 construieste cautarea in linie peste politici de
-  preturi; daca #12 muta pretul in nomenclator, S4 se rescrie.
-- **#16** — bug-ul de focus / renumerotare la revenirea din cursul valutar. Confirmat ca apare **dupa**
-  ce antetul s-a inchis si s-a eliberat (`ofacturare.prg:248`), la recuperarea erorii Oracle 20005.
-  In formularul unificat nu mai exista un antet inchis la care sa te intorci, deci **mecanismul lui
-  dispare** — de confirmat in S4d, nu de presupus.
-- **#6** — **dependenta de calendar, nu de perimetru** (decizia 30): implementarea lui #13 incepe
-  dupa ce #6 se termina. Proiectarea si cercetarea merg mai departe in paralel.
-
-## Preconditii de mediu
-
-- Orice DDL / modificare `PACK_FACTURARE`: sursa de referinta e `MARIUSM_AUTO` pe `ROA_CENTRAL`,
-  nu productia (`COMUN\docs\scripturi-migrare-db.md`). Scripturi nivel Oracle 10.2, CRLF,
-  idempotente, `versiune_db.txt` actualizat.
-- Sursa completa `PACK_FACTURARE` nu e in working copy; copia pe disc e
-  `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql` (16 948 linii),
-  cu alta numerotare decat exportul din baza.
-- Editarile pe `.vc2` / `.sc2` trec prin `git_sync.ps1` + `txt2vcx.ps1`, cu atentie la
-  `COMUN\docs\conventie_encoding_cp1252.md` (diacriticele din `.vc2` sunt cp1250 — vezi si memoria
-  proiectului).