sync SVN r18004/r18007: #6 editare factura emisa - pagina de articole

ofacturare_editare.prg (nou): helpere comune - garda eFactura, cursoarele
notei si ale rulajelor, randul de vanzare corespunzator notei si liniile de
articole citite din view-ul VVANZARI_ARTICOLE.

omodificari.vc2 (frm_modific2024): pagina noua de articole ale facturii,
deocamdata doar afisare. Apare numai cand ofacturare_editare.prg e
inregistrat si documentul are rand in VANZARI; in ROACONT si ROAGEST, unde
fisierul nu e incarcat, pagina lipseste si registrul jurnal ramane neatins.
Randul de vanzare al notei se cauta pe toate tripletele distincte (nract,
serie_act, dataact) din nota, pentru ca primul rand poate fi o incasare.

ofacturare_comun.vc2 (frm_facturi): do_editare_factura si butonul aferent,
dupa modelul lui do_sterge, cu garzile de luna inchisa, luna curenta,
document sters, referinte si eFactura.

docs: comentariile se scriu strict necesar, si in cod si in scripturile de
migrare - fara referinte la planuri, stories, decizii sau erori, istoricul
doar in antetul fisierului. Plus regula zero (predarea contextului),
capcanele de la testarea headless si completari pe fluxul text -> binar.

utile/Teste: suita de regresie pentru editarea facturii si harness-ul
watchdog (nu sunt in SVN, unde utile/Teste e ignorat). .gitignore ignora si
capturile PNG si watchdog_out/, ramase din rulari.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3

docs/flux-editare-vfp-text.md

@@ -76,6 +76,17 @@ fals `roundtrip text1 != text2`. Ruleaza atunci cu lista rebazata:
 - Metoda noua de clasa cere `*m: nume` in `*<DefinedPropArrayMethod>`; fara ea, prima salvare
   din IDE o arunca tacut, iar refresh-ul urmator absoarbe pierderea in cache (si in .bak-uri).
   Override-urile de metode de baza (Init, Show, hook-uri) nu au nevoie de `*m:`.
+- **Proprietate noua de clasa cere identic `*p: nume` in `*<DefinedPropArrayMethod>`** — nu doar
+  valoarea in `*<PropValue>`. Fara `*p:`, valoarea se scrie in text, **trece fidelity-check-ul**
+  (fidelity compara doar text-sursa cu text-regenerat) si ajunge in binar ca text, dar VFP nu o
+  materializeaza pe obiect: `PEMSTATUS(o,'nume',5)` da `.F.` si orice acces cade cu eroarea 1734
+  "Property ... is not found". Dovedit in ambele sensuri pe o clasa de proba izolata (cu `*p:` ->
+  `.T.`, fara -> `.F.`).
+- **FoxBin2Prg sorteaza alfabetic cu `_` DUPA literele obisnuite**, nu in ordine ASCII brut (unde
+  `'_' (0x5F) < 'v' (0x76)` pe litere mici). O intrare `*p:`/`*m:` scrisa de mana in ordine "ASCII
+  corecta" pica fidelity-check-ul; ordinea canonica se citeste din textul regenerat in
+  `<staging>\verify\*.vc2` (vezi punctul de mai jos despre pozitia metodelor noi — se aplica identic
+  proprietatilor).
 - FoxBin2Prg NU pastreaza pozitia in text a unei metode noi: o regenereaza la pozitia
   alfabetica din `*<DefinedPropArrayMethod>`. O metoda scrisa in alta parte a fisierului
   face fidelity-check-ul sa pice. Sursa de adevar pentru relocare e textul regenerat din

docs/orchestrare-subagenti.md

@@ -4,6 +4,45 @@ Regula (valabila in toate proiectele ROA/VFP): un singur subagent care duce o mi
 (iteratii de teste, investigatii, mai multe sarcini inlantuite) acumuleaza context urias —
 calitate degradata, cost mare. Nu se lucreaza asa.
 
+## REGULA ZERO: predarea contextului e OBLIGATORIE, nu optionala
+
+Se aplica **identic sesiunii principale si oricarui subagent**. Nu e o recomandare de eficienta,
+e o conditie de corectitudine: un context supraincarcat pierde tacut decizii deja luate si reia
+investigatii deja platite.
+
+**Declansatoare — la oricare dintre ele, predarea porneste imediat:**
+
+1. contextul propriu a trecut de **~50% din fereastra** (orchestrator) sau de **~200-250k tokens**
+   (subagent);
+2. harness-ul anunta compactare automata (`PreCompact`) — **prea tarziu ca sa mai amani, dar nu
+   prea tarziu ca sa scrii fisierul**; scrie handoff-ul inainte sa raspunzi orice altceva;
+3. utilizatorul semnaleaza ca s-a atins limita;
+4. s-a terminat un bloc de lucru — indiferent cat context a mai ramas.
+
+**Procedura, in ordine, fara exceptii:**
+
+1. **Opreste lucrul.** Nu incepe o sarcina noua, nu porni o rulare noua. Daca esti in mijlocul unei
+   editari, du-o pana la o stare **consistenta pe disc** (text si binare sincronizate) si atat.
+2. **Scrie handoff-ul pe disc** (`docs\handoff_<subiect>.md`). Nu in mesaj, nu in raport — **pe
+   disc**. Un mesaj catre orchestrator se pierde; fisierul nu.
+3. **Confirma in doua randuri** ce ai lasat in urma si daca ceva e intr-o stare periculoasa
+   (fisier editat fara write-back, tranzactie deschisa, proces ramas viu, date de test consumate).
+4. **Opreste-te.** Blocul urmator il ia un agent proaspat. "Mai am putin" nu e motiv de amanare —
+   exact acolo se pierd lucrurile.
+
+**Obligatia e a fiecaruia, nu doar a orchestratorului.** Un subagent care simte ca se apropie de
+prag **anunta singur** si cere predarea; nu asteapta sa fie oprit. Un orchestrator care se apropie
+de prag isi scrie propriul handoff si preda orchestrarea unei sesiuni noi — regula nu are portita
+pentru "eu doar coordonez".
+
+**Ce intra obligatoriu in handoff**: inventarul livrabilelor cu `fisier:linie`; ce e terminat si ce
+nu; **daca write-back-ul e facut** pentru fiecare fisier atins; comanda exacta de rulare a testelor
+si unde scriu logurile; ce s-a stabilit deja (ca sa nu se reia); ce e interzis; starea datelor de
+test consumate; capcanele de mediu platite. Fara analize noi — doar stare.
+
+Doua lectii platite scump, amandoua din aceeasi cauza — un agent tinut peste prag (`s5-nivel2`
+533k, `s2d-modifica-gestiuni` 434k). Predarea e aproape gratuita: raportul e oricum deja scris.
+
 ## Cum se lucreaza
 
 - Sesiunea principala (sau un agent primar) e ORCHESTRATOR: imparte planul pe sarcini
@@ -58,7 +97,9 @@ diagnostic, fixuri aplicate direct in loc de delegate.
   care intoarce da/nu, nu continutul din care ai deduce singur.
 - **Nu aplica fixuri direct** decat sub ~5 linii si doar daca ai deja contextul in sesiune.
 - **Prag si pe orchestrator**: la ~50% din fereastra, scrie handoff-ul si reia orchestrarea
-  dintr-o sesiune noua. Handoff-ul e deja pe disc - exact pentru asta exista.
+  dintr-o sesiune noua. Handoff-ul e deja pe disc - exact pentru asta exista. Vezi **Regula zero**
+  de la inceputul fisierului: obligatia e aceeasi ca pentru subagenti, fara portita pentru
+  "eu doar coordonez".
 
 ## Model de lucru: backlog de story-uri mici, context mic per story
 

docs/reguli_lucru.md

@@ -12,13 +12,20 @@
    handoff-uri/planuri de runda, `*.pre_runda*.bak`, `.bak`-urile din cache-ul text si artefactele
    de test (`screenshots*`, `uisync*`, `.fxp`, `.err`, loguri). Sterge doar fisiere neurmarite de
    git — cele tracked sunt sarite.
-2. Comentarii in cod: minime, strict functionale, descriu comportamentul CURENT (ca si cum ar fi
-   scris asa de la inceput) — o linie de regula, 2-3 doar pentru metode cu contract nebanal
-   (parametri, cursor asteptat/lasat deschis, pozitionare la iesire). Istoricul modificarilor
-   sta DOAR in ANTETUL fisierului (niciodata inline) — la fel in `.prg` si in PL/SQL Oracle.
-   INTERZIS in comentariu: nume de agent ("claude"), referinte la propuneri/decizii/etape
-   (`docs/propuneri_*.md`, "M2", "T3", "dec.6", "runda27", "E7", "D-H2"), istoricul modificarii
-   ("inlocuieste...", "nu mai depinde de...", "mutat din..."), date si autori pe cod nou.
+2. Comentarii in cod SI in scripturile de migrare `.sql`: minime, strict functionale, descriu
+   comportamentul CURENT (ca si cum ar fi scris asa de la inceput). **Doar daca e cazul** — un
+   comentariu se scrie acolo unde explica o **ramura** sau un **filtru** care nu se citeste singur,
+   ca sa se inteleaga codul; unde codul e limpede, nu se comenteaza. O linie de regula, 2-3 doar
+   pentru metode cu contract nebanal (parametri, cursor asteptat/lasat deschis, pozitionare la
+   iesire), 4-5 in antetul unui script de migrare (ce e obiectul si ce contract are). Istoricul
+   modificarilor sta DOAR in ANTETUL fisierului (niciodata inline) — la fel in `.prg`, in `.sql`
+   si in PL/SQL Oracle.
+   INTERZIS in comentariu: nume de agent ("claude"), referinte la planuri, stories, propuneri,
+   decizii, etape sau erori (`docs/plan_*.md`, `docs/propuneri_*.md`, "#6", "S4", "M2", "T3",
+   "dec.6", "runda27", "E7", "D-H2"), trimiteri la rapoartele din `docs/` ("vezi raportul,
+   sectiunea ..."), justificarea alegerii facute (de ce numele acesta, de ce s-a respins varianta
+   cealalta), istoricul modificarii ("inlocuieste...", "nu mai depinde de...", "mutat din..."),
+   date si autori pe cod nou.
    Comentarii vechi in stil jurnal nu se rescriu din oficiu — doar cand blocul e oricum atins
    sau la cerere explicita.
    Antet: o singura intrare CUMULATIVA per functionalitate (`*!* DD.MM.YYYY` / `*!* autor` /
@@ -46,6 +53,20 @@
    se umple contextul. Misiuni lungi: subagenti proaspeti per sarcina (max ~200-250k
    tokens/subagent), nu unul singur cu context acumulat; handoff compact pe disc:
    `orchestrare-subagenti.md`.
+   **Verificarea a ce se intoarce** — pentru executie delegarea merge, pentru concluzii nu:
+   - **citeste contractul functiei apelate, nu-l presupune.** Un raport care descrie corect
+     structura codului poate gresi sensul: ex. `goExecutor.oExecute` intoarce succes/insucces
+     (`CT_SUCCES`/`CT_INSUCCES`), NU numarul de randuri — o garda `If lnSucces > 0` citita ca
+     "are randuri" a produs un bug inexistent, raportat ca blocant. Deschide functia.
+   - **fix ingust, nu supra-constructie.** Cand premisa se corecteaza, corectia se restrange:
+     mecanismele noi introduse "ca sa fie sigur" diverg de la codul-sablon si blocheaza
+     refolosirea lui in alta parte.
+   - **"zero cazuri in date" nu dovedeste nimic** pe scheme cu date de test; raspunsul vine din
+     cod. Si invers: o potrivire de cifre pe 1-2 documente nu e o regula.
+   - **cere raportul sa separe "testat" de "analizat static"**, si ce n-a putut fi acoperit. Un
+     agent care nu e intrebat explicit va prezenta amandoua la fel.
+   - **spune-i ca poate infirma briefingul.** Altfel implementeaza corectia ceruta chiar cand a
+     descoperit ca nu e nevoie de ea.
 7. Conventii obligatorii, de citit cand atingi zona respectiva:
    - editezi fisiere cu octeti cp1252 - `.vc2`/`.sc2`, dar si `.prg` (ex. `programe\ocautare.prg`,
      unde `s`-urile cu virgula din `masina`/`si contul`/`transa` sunt octetul `0xBA`) ->

docs/scripturi-migrare-db.md

@@ -70,6 +70,10 @@ Marius ce nu e aplicat. Exportul sursei de referinta: `oracle_export.md`.
 - **Idempotent**: rulat de doua ori nu mai schimba nimic (`merge`, `where <coloana> is null`).
 - **Un pachet sta singur in scriptul lui**, fara alt DDL sau DML alaturi: modificarile de tabele si
   curateniile de date merg in scripturi separate, cu numar propriu.
+- **Comentarii strict necesare**, ca in cod: antet de 4-5 randuri (data + autor, ce e obiectul, ce
+  contract are), fara referinte la planuri, stories, propuneri, decizii sau erori, fara trimiteri la
+  rapoartele din `docs/`, fara justificarea alegerilor si fara istoricul modificarii. Regula completa
+  si lista de interdictii: `reguli_lucru.md`, punctul 2.
 
 ## Compatibilitate cu serverele clientilor
 

docs/testare-ui-vfp.md

@@ -175,3 +175,40 @@ p. **Nu numi variabilele ca functii built-in VFP.** VFP e insensibil la litere m
    **tacut false** si par sa spuna ca obiectul nu a fost gasit — masuratoarea e stricata, nu
    rezultatul. Simptom de recunoscut: mesajul de eroare contine numele **cu majuscule** al unei
    functii VFP, nu numele variabilei asa cum ai scris-o. Prefixeaza distinctiv (`loBifa`, `loCtrl`).
+q. **`DO ... WITH` paseaza PRIN REFERINTA, iar variabila devine invizibila sub numele ei propriu in
+   procedura apelata.** Consecinta urata: orice `?variabila` din SQL passthrough de pe lantul
+   apelurilor respective nu se mai poate lega, si VFP deschide dialogul nativ **"View Parameter —
+   Enter the value for `<var>`"**, care blocheaza testul headless la infinit (fara log, fara
+   eroare). Dovedit pe date: o variabila globala era valida in programul principal la fiecare
+   checkpoint, dar `TYPE()` intorcea `'U'` (nedefinita) exact la intrarea in procedurile apelate cu
+   `DO proc WITH gnAn, gnLuna` — si valida in cele apelate fara `DO ... WITH` — corelatie exacta cu
+   **sintaxa apelului**, nu cu ce face procedura. Remediu: paranteze pe fiecare argument forteaza
+   pasarea prin valoare — `DO proc WITH (gnAn), (gnLuna)`.
+r. **O suita care testeaza o clasa din `COMUN` poate incarca implicit copia ALTUI PRODUS**, daca
+   harnessul de mediu comun (ex. `test_init_env_auto.prg`) face `SET DEFAULT TO`/`SET PATH` pe
+   working copy-ul altui produs (ex. `D:\ROA\ROACONT\...`) inainte de `SET CLASSLIB TO <clasa>
+   ADDITIVE`: `Createobject` gaseste prima clasa cu acel nume pe `PATH`, care poate fi
+   `D:\ROA\ROACONT\COMUN\clase\<clasa>.vcx` in loc de fisierul editat sub test — silentios, fara
+   eroare. Simptom: testul trece curat, dar valideaza cod vechi/alt working copy; orice concluzie
+   trasa asa e nula. Remediu, dupa initializarea mediului comun: `RELEASE CLASSLIB <nume>` +
+   `SET CLASSLIB TO <cale completa a fisierului sub test> ADDITIVE` (`SET CLASSLIB ... ADDITIVE`
+   **singur**, fara `RELEASE` intai, da eroarea 24 "Alias name is already in use" si pastreaza
+   tacut copia veche). Verificare obligatorie dupa instantiere: `loForm.ClassLibrary` trebuie sa
+   arate calea completa asteptata.
+s. **Dialoguri native care nu apar in log si nu sunt prinse de `ON ERROR`/mock-uri** (ex. "View
+   Parameter", "Open" pe fisier lipsa): nu se depaneaza orbeste, se ruleaza sub
+   `COMUN\utile\Teste\watchdog_vfp.ps1 -Script <test.prg> -AutoDismiss`. Lanseaza `vfp9.exe -A -T`,
+   polleaza ferestrele top-level ale procesului (identificate prin `Process.MainWindowHandle`, nu
+   dupa numele clasei — VFP foloseste clase `vfp9...` si pentru shell-ul principal si pentru
+   dialogurile proprii), captureaza PNG + textul fiecarui control copil (`WM_GETTEXT`) la orice
+   fereastra noua, si omoara procesul la iesire (`finally`, niciodata ramas viu). **Interzis strict:
+   input real** (`keybd_event`/`SetForegroundWindow`/`SendInput`/`mouse_event`) — masina e
+   partajata, un input injectat la nivel de sistem ajunge in orice fereastra are focus in acel
+   moment, nu neaparat in dialogul tintit (patit: un ESCAPE injectat a intrerupt sesiunea IDE a
+   utilizatorului, aflat in lucru in paralel). `-AutoDismiss` foloseste STRICT mesaje Windows
+   tintite pe handle (`BM_CLICK` pe buton Cancel/Anulare, altfel `WM_COMMAND IDCANCEL` ->
+   ESCAPE ca mesaj `WM_KEYDOWN`/`WM_KEYUP` -> `WM_CLOSE`); pe dialogurile proprii VFP owner-drawn
+   (butoane desenate, nu HWND-uri reale) dismiss-ul poate esua cinstit — captura PNG + dump text
+   raman oricum de incredere, indiferent de rezultatul dismiss-ului. Sterge intotdeauna `.fxp`-ul
+   vechi inainte de FIECARE rulare (watchdog-ul o face singur la lansare) — altfel VFP ruleaza
+   tacut codul compilat vechi si rulari "identice" dau rezultate diferite, fara nicio urma in log.

docs/todos.txt

@@ -46,3 +46,6 @@ INTERESUL MEU ESTE SA SIMPLIFIC INTERFATA, SA FIE MAI EFICIENTA, SA NU FIE 2 FOR
 
 17. ROAFACTURARE - daca o nota contabile de vanzare nu are configurat tip de venit/cheltuiala, si nici articolele din lista de preturi, si nici nu se completeaza tip venit/cheltuiala la facturare, la finalizarea facturii apare o eroare oracle ORA ca id_venchelt nu are voie sa fie null. eroarea nu este user friendly si nu se poate recupera usor, pentru ca trebuie sa se dea renunt la toata factura si sa se reia tot porcesul, cu completarea tip venit cheltuiala. si nici nu stiu de ce este obligatoriu tip venit/cheltuiala.
 
+18. ROAFACTURARE - EMITERE FACTURA DIN PROFORMA
+
+19. ROAFACTURARE - EDITARE PROFORMA