roafacturare/docs/handoff_13_formular_unificat.md

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