# Handoff — #13 formular unificat de facturare + editare prin regenerare

Sesiune: 11.08.2026, **runda 16** (istoricul de mai jos e cumulativ; blocul rundei 14 e pastrat ca
atare). Runda 13 predase dupa cinci proiectari si deciziile 44-50.
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
> `git status` arata doar `docs/` netracked, dar **SVN e sursa de adevar aici** si arata mult mai mult:
> ```
> 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:**
1. **Golul `IN_STOC` din S8** — deschis de verificarea S10 (consecinta 1). Nu e o poveste noua, e o
   cerinta in plus pentru S8, de prins in nota lui de executie.
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 si a ramas cu patru runde in urma.** Nu s-a republicat, conform deciziei 33.
   Asezarea zonei de jos e insa **decisa** — varianta D, decizia 57 (cu intrebarea de detaliu
   redeschisa de decizia 61, vezi mai sus).
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.** Inchide ultimul punct ramas deschis
    din decizia 57, reluat de decizia 61: randul de jos are trei sectiuni pe acelasi rand —
    incasare, alte date, motivul discountului — ~440 px fiecare la 1366 px, strans; D ramane
    intr-un etaj. Enuntul complet: **in plan**, la „Decizia 64".
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.

## 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.
- 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 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.

**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** — flag-ul de la S10 nu ajunge daca S8 nu incarca valoarea cu care s-a
   scris documentul. De prins **acum**, in nota de executie a lui S8, nu la S12.
5. **Mockup v9** — v8 a ramas cu patru runde in urma. Nici variantele rundei 14, nici **varianta D a
   rundei 15 nu sunt integrate in el** — traiesc doar in artifactul de la punctul 3, iar v8 n-a fost
   atins. Cand se face v9, D e asezarea de pornit.
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).