# Proiectare — Decizia 42: articole factura vizibile, needitabile dupa trimiterea in eFactura

Scris 10.08.2026. Agent read-only, doar cercetare/proiectare — nicio modificare de cod facuta
de acest agent.

## ATENTIE — implementarea era deja IN LUCRU, de catre alt agent; bugul de mai jos e DEJA CORECTAT

Inainte de a ajunge la proiectare: la momentul cercetarii, `COMUN\clase\omodificari.vc2` avea deja
**modificari necomise in working tree** (`git status` in `COMUN`: `M clase/omodificari.vc2`) care
implementeaza aproape exact Decizia 42 corectata (vizibil, doar needitabil). Agentul `d42-efactura`,
activ in aceeasi sesiune, lucra chiar atunci pe exact acest subiect.

**Acest raport nu descrie deci o proiectare de la zero, ci: (1) verificarea contractelor si (2) un
review al diff-ului in lucru, cu un bug real gasit si dovedit pe schema Oracle — vezi §1 si §8.**

**UPDATE, dupa trimiterea raportului**: `d42-efactura` a gasit acelasi bug independent, in timpul
propriei lucrari (nu din briefingul primit de la team-lead), l-a corectat si scris in binar
**inainte** sa primeasca mesajul meu. **Verificat direct pe disc de acest agent** (nu doar preluat
din raportarea lui `d42-efactura`): `git diff` pe `COMUN\clase\omodificari.vc2` arata
`This.lArticoleReadOnly = EsteInEFactura(Nvl(tvanz.id_fact,0))`, iar `git diff` pe
`COMUN\programe\ofacturare_editare.prg` arata `v.id_fact` adaugat in SELECT-ul din
`IncarcaVanzareNota` si `id_fact I NULL` adaugat in schema `CREATE CURSOR tvanz` din
`CreeazaCursorTvanzGol` — exact varianta B recomandata la §8. **Bugul e inchis, nu mai necesita
actiune.**

Legat de linia necomisa gasita atunci in `ROAGEST\Programe\roagest.prg`
(`SET PROCEDURE TO ofacturare_editare.prg ADDITIVE`, "Not Committed Yet" la 10.08.2026 11:28):
`d42-efactura` confirma ca nu e a lui — a atins doar `omodificari.vc2` si `ofacturare_editare.prg`
(plus fisiere de test noi). Ramane deci dintr-un alt bloc de lucru (posibil S9), de verificat separat
de team-lead — nu descrie starea lui `d42-efactura`.

---

## 1. Cum se afla ca documentul e in eFactura

**Functie**: `FUNCTION EsteInEFactura`, globala (nu metoda de clasa), definita in
`COMUN\programe\ofacturare_editare.prg:16-25`:

```
*!* parametru: id_fact
*!* verifica daca factura cu id_fact dat a fost deja trimisa in eFactura (anaf_efactura)
FUNCTION EsteInEFactura
	LPARAMETERS tnIdFact
	LOCAL lcSql, lnEFactura, llSucces
	lnEFactura = 0
	lcSql = [select count(*) as lneFactura from anaf_efactura where id_fact = ] + Alltrim(Str(Nvl(m.tnIdFact,0)))
	llSucces = goExecutor.oSelecteaza2Value(m.lcSql, @lnEFactura)
	RETURN (Nvl(m.lnEFactura,0) > 0)
ENDFUNC
```

**Contract, deschis din `RETURN`**: primeste `tnIdFact` — **`ID_FACT`, nu `ID_VANZARE`** — si intoarce
`.T./.F.` (numar de randuri in `ANAF_EFACTURA` cu acel `id_fact` > 0). Foloseste `goExecutor`
(disponibil global, aceeasi conventie ca restul aplicatiei).

**Disponibilitate cross-project — VERIFICAT, nu presupus**: `ofacturare_editare.prg` e inregistrat
prin `SET PROCEDURE ... ADDITIVE` in toate cele trei aplicatii:

| App | Fisier | Linie | Stare git |
|---|---|---|---|
| ROAFACTURARE | `Programe\roafacturare.prg` | 214 | comis demult |
| ROACONT | `Programe\roacont.prg` | 212 | comis, `3af0089` (08.08.2026) — mesaj: *"Fara el, pagina de articole ale facturii nu apare in registrul jurnal > modificare"* |
| ROAGEST | `Programe\roagest.prg` | 260 | **necomis**, adaugat azi 10.08.2026 (vezi avertismentul de mai sus) |

Deci `EsteInEFactura` **este** apelabila din contextul `omodificari.vc2`, inclusiv din ROACONT si
(dupa commit-ul in curs) ROAGEST. Comentariul din `omodificari.vc2:14786-14787` ("apare doar cand
ofacturare_editare.prg e incarcat (doar ROAFACTURARE - ROACONT/ROAGEST nu-l inregistreaza)") e
**invechit** — scris inainte de commit-ul `3af0089`, care a inversat exact aceasta premisa pentru
ROACONT. Nu se corecteaza comentariul in acest raport (read-only), dar oricine implementeaza ar
trebui sa-l actualizeze cand atinge zona.

**BUG GASIT in diff-ul in lucru — `id_fact` confundat cu `id_vanzare`.** Apelul din
`omodificari.vc2:14798` (diff necomis) e:

```
This.lArticoleReadOnly = EsteInEFactura(This.nIdVanzare)
```

dar `This.nIdVanzare` e populat cu `tvanz.id_vanzare` (linia 14796), adica `VANZARI.ID_VANZARE` —
**alt camp** decat `VANZARI.ID_FACT`, pe care `EsteInEFactura` il asteapta. Dovada, in trei straturi:

1. **Cod**: precedentul functional existent, `ofacturare_comun.vc2:3739` (`lnIdFact = id_fact`) si
   `:3764` (`EsteInEFactura(lnIdFact)`), citeste `id_fact` dintr-un camp separat de `id_vanzare`
   (`:3734`, `lnIdVanzare = id_vanzare`, aceeasi cursor `crsfacturi`, doua LOCAL-uri distincte).
   Acelasi tipar in `anaf_efactura.prg:3123-3124`: `pnIdFact = id_fact` si `lnIdVanzare = id_vanzare`
   citite **pe acelasi rand** din `crsFacturiEmise` — daca ar fi acelasi numar, codul n-ar avea
   nevoie de doua variabile.
2. **Schema Oracle** (verificat read-only, `user_tab_columns`, `MARIUSM_AUTO`): `VANZARI` are **ambele**
   coloane, `ID_FACT` si `ID_VANZARE`, distincte; `ANAF_EFACTURA` are doar `ID_FACT`.
3. **Date reale** (verificat read-only, join `anaf_efactura.id_fact = vanzari.id_fact`): pentru
   documentele deja trimise in eFactura, cele doua valori difera constant —

   | id_fact | id_vanzare | cod | numar_act | data_act |
   |---|---|---|---|---|
   | 8008013 | 1013 | 1140509 | 510 | 31-AUG-25 |
   | 8007922 | 1007 | 1140439 | 503 | 03-JAN-25 |
   | 8007836 | 993 | 1140380 | 490 | 15-AUG-24 |
   | 8007810 | 991 | 1140369 | 488 | 11-JUL-24 |

Cu bug-ul curent, `EsteInEFactura(1013)` cauta `id_fact = 1013` in `ANAF_EFACTURA` — care nu exista
cu acel numar — deci **intoarce mereu `.F.`**, chiar si pentru documente reale trimise in eFactura.
Garda ar fi complet inoperanta pe date reale. Corectia: §8.

Niciun document dintre cele patru de mai sus nu e din luna curenta (limitare de date deja cunoscuta
din bloc — garda de editare cere luna curenta), deci un test headless pe un caz real din productie
de date nu se poate face acum; testul trebuie sa foloseasca un cursor `tact`/`tvanz` mock cu
`id_fact` setat manual (acelasi tipar folosit deja pentru `id_vanzare_set` in S5).

## 2. Unde se aseaza conditia in omodificari.vc2

Locul folosit deja de diff-ul in lucru e corect si e cel recomandat: `frm_modific2024.Show()`
(`omodificari.vc2:14748-14837` in varianta comisa `1c42ae0`; extins la 14748-14856 in diff-ul
necomis), imediat dupa blocul care rezolva `This.nIdVanzare`/`This.nTipVanzare` prin
`IncarcaVanzareDinNota('tact')` si inainte de `This.pgfArticole.PageCount = 3`. E punctul unde
formularul stie deja daca documentul curent are rand in `VANZARI` (`This.lAreArticoleVanzari`) —
conditia eFactura se agata direct pe acest rezultat, fara sa duplice logica de potrivire
cod/nract/serie_act/dataact -> id_vanzare.

Proprietatea noua, `lArticoleReadOnly` (declarata la nivelul clasei, langa `lAreArticoleVanzari`,
`omodificari.vc2:6827` si `6867` in diff), e citita apoi din `.When`-urile coloanelor editabile ale
gridului `grdArticoleFactura` (mecanismul de editabilitate per rand din S5, §3-4) — deci conditia
de formular **compune** cu mecanismul existent, nu-l inlocuieste.

## 3. Controale care se dezactiveaza — confirmate pe cod

| Control | Path | Linii (comis) | Ce face diff-ul |
|---|---|---|---|
| Buton adaugare | `pgfArticole.PAGE3.cmdAdaugaArticol` | Click: `16488-16529` | `.Enabled = !This.lArticoleReadOnly` la afisare (`Show`); plus guard `OR Thisform.lArticoleReadOnly` in `Click` (aparare in adancime, cazul `Enabled` sarit programatic) |
| Buton stergere | `pgfArticole.PAGE3.cmdStergeArticol` | Click: `16531-16540` | idem |
| Cantitate | `grdArticoleFactura.cCantitateArt.Text1.When` | `16549-16554` | adauga `Thisform.lArticoleReadOnly OR` in fata conditiei existente `Nvl(tvd.id_vanzare_set,0)<>0` |
| Pret achizitie | `grdArticoleFactura.cPretAchizitieArt.Text1.When` | `16556-16561` | idem |
| Pret | `grdArticoleFactura.cPretArt.Text1.When` | `16570-16575` | idem |
| Pret cu TVA (checkbox) | `grdArticoleFactura.cPretCuTvaArt._checkbox1.When` | `16587-16589` | `RETURN !Thisform.lArticoleReadOnly AND ...` |
| Discount | `pgfArticole.PAGE3.txtDiscountArt` | — | **neatins in diff** — vezi nota de mai jos |

**Gol observat**: `txtDiscountArt` (discountul pe factura, cu `ControlSource = tvanz.discount`) nu
are `.When` si nu apare in diff. Daca discountul e considerat parte din "articolele facturii" in
sensul Deciziei 42 (afecteaza totalul liniilor), ramane editabil dupa trimiterea in eFactura — de
clarificat cu Marius sau de inclus explicit. Nu era in lista `cmdAdaugaArticol`/`cmdStergeArticol`
ceruta explicit in brief, deci il semnalez ca gol, nu-l tratez ca bug.

## 4. Tipar read-only pe grid, folosit deja in proiect

Nu se inventeaza un tipar nou. Proiectul (din S5) foloseste deja exact acest idiom pentru randurile
needitabile (liniile din seturi, `id_vanzare_set <> 0`): fiecare coloana editabila a gridului are
un handler `.When` care intoarce `.F.` cand conditia de blocare e adevarata — VFP nu lasa controlul
sa intre in editare daca `.When` intoarce `.F.`. Diff-ul in lucru extinde exact aceste `.When`-uri
existente, adaugand `Thisform.lArticoleReadOnly OR` in fata conditiei deja acolo — e continuarea
directa a mecanismului S5, nu un tipar paralel. Confirma cererea din brief: "foloseste tiparul deja
folosit in proiect, nu inventa unul nou" — respectat.

## 5. Feedback vizual pentru utilizator

Diff-ul adauga o eticheta noua, `pgfArticole.PAGE3.lblArticoleReadOnly`
(`omodificari.vc2:12857-12871` in diff), cu `Caption = "Articole needitabile - factura trimisa in
eFactura"`, `Visible` legat de `This.lArticoleReadOnly` in `Show()`. E minimul cerut de brief —
niciun tipar de marcaj standard read-only nu exista deja in proiect (nu s-a gasit unul in cautarea
pentru §4), deci eticheta simpla e alegerea rezonabila. Singura observatie: eticheta e pozitionata
`Top = 4, Left = 360` — de verificat pe ecran (fara VFP IDE nu se poate confirma vizual) ca nu se
suprapune cu alt control din PAGE3 la latimile de forma folosite azi.

## 6. Suprafata de regresie — de ce notele obisnuite din registrul jurnal nu sunt atinse

Blocul care calculeaza `lArticoleReadOnly` ruleaza **doar** in interiorul conditiei deja existente:

```
IF "OFACTURARE_EDITARE" $ Upper(Set("Procedure")) AND Reccount('tact') > 0
    IncarcaVanzareDinNota('tact')
    IF Reccount('tvanz') = 1
        This.lAreArticoleVanzari = .T.
        ...
        This.lArticoleReadOnly = EsteInEFactura(...)
    ENDIF
ENDIF
```

`IncarcaVanzareDinNota` cauta in `VANZARI` un rand cu tripletul (cod, nract, serie_act, dataact) al
notei curente. Pentru o nota contabila obisnuita (nu factura de vanzare), acest rand nu exista,
`Reccount('tvanz')` ramane `0`, deci **intreg blocul `IF Reccount('tvanz') = 1` e sarit** —
`This.lAreArticoleVanzari` ramane `.F.` si `This.lArticoleReadOnly` ramane la valoarea implicita
`.F.` (setata explicit chiar inainte de bloc, `:14791`). Consecinta directa: `This.pgfArticole.PageCount
= 2` (fara PAGE3), deci `cmdAdaugaArticol`/`cmdStergeArticol`/gridul de articole **nici nu exista**
pentru documentul respectiv — nu doar ca nu sunt dezactivate, ci nu sunt instantiate in fluxul de
afisare. Riscul de regresie pe notele obisnuite din ROAGEST/ROACONT e deci **zero prin constructie**,
mostenit din gating-ul `lAreArticoleVanzari` deja livrat si testat in S4/S5 — Decizia 42 doar adauga
o conditie suplimentara **in interiorul** ramurii deja izolate pentru facturi de vanzare, nu schimba
gating-ul insusi. Acesta e exact argumentul cerut in brief la punctul 6, si e verificabil citind
codul, nu presupus.

`comun.vc2` (clasa `afisjurcom`, `do_modifica`, `2222-2572`) nu e atins de acest diff — ramane
neschimbat, confirmand ca intreaga logica sta in `omodificari.vc2`, un singur punct de intretinere.

## 7. Teste minime propuse (headless, in stilul suitei existente)

Suita `COMUN\utile\Teste\editare_factura\` foloseste harness-ul `ui_harness.prg` + `asserteaza`, cu
formular vizibil (`WindowType = 0`, `Show()`, `DOEVENTS FORCE`), fara input real (nici un
`keybd_event`/`SendInput` — doar citire directa de proprietati si apel direct de metode). Propunere,
dupa modelul `test_ui_sterge_linie.prg`:

**`test_d42_efactura_readonly.prg`** — cazul pozitiv, cu date mock (nu exista document real din
luna curenta trimis in eFactura, cf. §1):
1. Incarca `tact`/`tvd` pentru un document real din luna curenta cu `lAreArticoleVanzari = .T.`
   (ex. acelasi `id_vanzare = 1049` mentionat in `handoff_punct6_dupa_s5.md`, daca inca in luna
   curenta la momentul rularii).
2. Dupa `IncarcaVanzareDinNota`, forteaza `tvanz.id_fact` (sau `tact.id_fact`, dupa care varianta se
   alege in §8) la o valoare stiuta ca exista in `ANAF_EFACTURA` (mock: `INSERT` intr-un cursor
   local, nu in Oracle) — sau, mai simplu, mock-uieste direct `EsteInEFactura` prin
   `SET PROCEDURE`/redefinire temporara, dupa tiparul deja folosit in proiect pentru izolarea de
   Oracle in teste UI.
3. `assert`: `loForm.lArticoleReadOnly = .T.`
4. `assert`: `loForm.pgfArticole.PAGE3.cmdAdaugaArticol.Enabled = .F.`
5. `assert`: `loForm.pgfArticole.PAGE3.cmdStergeArticol.Enabled = .F.`
6. `assert`: `loForm.pgfArticole.PAGE3.lblArticoleReadOnly.Visible = .T.`
7. `assert`: grid-ul e in continuare **vizibil** si populat — `loForm.pgfArticole.PageCount = 3`,
   `Reccount('tvd') > 0` — confirma partea corectata a deciziei (nu se suprima pagina).
8. `assert`: pozitionare pe `grdArticoleFactura`, `SetFocus` pe coloana `cCantitateArt` nu intra in
   editare — verificat prin apelul direct al handlerului `.When` (`loForm.pgfArticole.PAGE3.
   grdArticoleFactura.cCantitateArt.Text1.When()` trebuie sa intoarca `.F.`), nu prin tastare.

**`test_d42_efactura_editabil.prg`** — cazul negativ (control): acelasi document, dar
`EsteInEFactura` mock-uit sa intoarca `.F.` -> toate assert-urile de mai sus inversate (`Enabled =
.T.`, `.When()` nu intoarce `.F.` din cauza flagului — poate intoarce `.F.` din alt motiv, ex.
`id_vanzare_set`, testat separat).

**`test_d42_nota_obisnuita_neatinsa.prg`** — cazul de regresie cerut la §6: incarca o nota
contabila fara corespondent in `VANZARI` (orice test existent din `COMUN\utile\Teste\` care nu tine
de facturare), verifica `loForm.pgfArticole.PageCount = 2` si ca `lArticoleReadOnly` ramane `.F.`
fara sa fi fost nevoie sa se apeleze `EsteInEFactura` deloc (se poate confirma indirect, verificand
ca nu s-a facut nicio interogare Oracle suplimentara, sau direct daca se mock-uieste functia cu un
contor de apeluri).

Toate cele trei suite: fara scriere in Oracle, `QUIT` la final, log langa `.prg` cu acelasi nume +
`_log.txt`, conform conventiei din `handoff_punct6_dupa_s5.md`.

## 8. Schita de diff — corectia necesara peste diff-ul in lucru

Doua variante, cu recomandare pentru B.

**Varianta A — minima**, refoloseste `id_fact` deja prezent pe cursorul `tact` (confirmat: `tact`
vine din view-ul `vact_tot`, care are coloana `id_fact`, folosita deja in `ofacturare_comun.vc2:3776`
ca `Locate For Nvl(id_fact, 0) = lnIdFact` pe acelasi cursor `actactan`/`tact`):

```diff
--- a/COMUN/clase/omodificari.vc2
+++ b/COMUN/clase/omodificari.vc2
@@ frm_modific2024.Show
 			This.nIdVanzare = tvanz.id_vanzare
 			This.nTipVanzare = tvanz.tip
-			This.lArticoleReadOnly = EsteInEFactura(This.nIdVanzare)
+			This.lArticoleReadOnly = EsteInEFactura(Nvl(tact.id_fact, 0))
```

Risc al variantei A: presupune ca recordul curent din `tact` (la momentul `Show()`, imediat dupa
incarcare, deci pe Top) are `id_fact` valid pentru documentul gasit — valabil in cazul normal, dar
nu la fel de robust ca precedentul din `ofacturare_comun.vc2:3775-3783`, care cauta explicit randul
cu `id_fact` potrivit inainte sa cada pe fallback (`Go Top`).

**Varianta B — recomandata**, aduce `id_fact` chiar pe `tvanz` (randul din `VANZARI` deja gasit prin
tripletul cod/nract/serie_act/dataact), simetric cu `id_vanzare`:

```diff
--- a/COMUN/programe/ofacturare_editare.prg
+++ b/COMUN/programe/ofacturare_editare.prg
@@ CreeazaCursorTvanzGol
-	CREATE CURSOR tvanz (id_vanzare I, tip I, discount N(12,2), total_fara_tva N(14,2), total_tva N(14,2), total_cu_tva N(14,2), curs N(10,4), multiplicator N(10,4), ;
+	CREATE CURSOR tvanz (id_vanzare I, id_fact I NULL, tip I, discount N(12,2), total_fara_tva N(14,2), total_tva N(14,2), total_cu_tva N(14,2), curs N(10,4), multiplicator N(10,4), ;
 		in_valuta I NULL, id_valuta I NULL, nume_val C(20) NULL)
@@ IncarcaVanzareNota
-	lcSql = [select v.id_vanzare, v.tip, v.discount, v.total_fara_tva, v.total_tva, v.total_cu_tva, v.curs, v.multiplicator, ] + ;
+	lcSql = [select v.id_vanzare, v.id_fact, v.tip, v.discount, v.total_fara_tva, v.total_tva, v.total_cu_tva, v.curs, v.multiplicator, ] + ;
 		[v.in_valuta, v.id_valuta, nv.nume_val from vanzari v left join nom_valute nv on nv.id_valuta = v.id_valuta where v.cod = ] + Transform(m.tnCod) + ;

--- a/COMUN/clase/omodificari.vc2
+++ b/COMUN/clase/omodificari.vc2
@@ frm_modific2024.Show
 			This.nIdVanzare = tvanz.id_vanzare
 			This.nTipVanzare = tvanz.tip
-			This.lArticoleReadOnly = EsteInEFactura(This.nIdVanzare)
+			This.lArticoleReadOnly = EsteInEFactura(Nvl(tvanz.id_fact, 0))
```

Varianta B e mai robusta pentru ca foloseste `VANZARI.ID_FACT` direct — exact coloana pe care
`ANAF_EFACTURA` o are ca cheie (verificat pe schema Oracle, §1) — fara sa depinda de pozitia
curenta a cursorului `tact`. Costul: doua fisiere in loc de unul (`ofacturare_editare.prg` +
`omodificari.vc2`), plus verificarea ca `select v.id_fact` nu produce eroare Oracle daca vreun rand
vechi din `VANZARI` are `id_fact` `NULL` (coloana e deja `NULL`-abila judecand dupa restul cursorului,
`in_valuta I NULL` etc., deci nu ar trebui sa fie o problema).

**Neschimbat, corect asa cum e**: restul diff-ului (`.When`-urile pe grid, `cmdAdaugaArticol`/
`cmdStergeArticol.Enabled`, eticheta `lblArticoleReadOnly`) — vezi §2-5.

---

## Rezumat pentru implementare

1. Diff-ul lui `d42-efactura` (necomis la momentul acestui raport, in `COMUN\clase\omodificari.vc2`
   + `COMUN\programe\ofacturare_editare.prg`) e **structural corect** — locul (§2), controalele
   (§3), tiparul de grid (§4) si feedback-ul (§5) respecta cerintele Deciziei 42 corectate.
2. **Bug gasit, dovedit pe schema si date, si INCHIS**: `EsteInEFactura(This.nIdVanzare)` trebuia sa
   foloseasca `id_fact`, nu `id_vanzare` — `d42-efactura` l-a gasit independent si l-a corectat cu
   exact varianta B din §8 (`EsteInEFactura(Nvl(tvanz.id_fact,0))`), **verificat pe disc de acest
   agent** dupa corectie. Nu mai necesita nicio actiune.
3. Gol de clarificat, nu bug: `txtDiscountArt` ramane editabil dupa eFactura — de decis cu Marius
   daca discountul intra sub "articole" (§3). Confirmat si de `d42-efactura` ca gol cunoscut, in
   afara scope-ului primit de la team-lead.
4. Comentariul din `omodificari.vc2:14786-14787` ("ROACONT/ROAGEST nu-l inregistreaza") e invechit
   de la commit-ul `3af0089` — de actualizat cand se atinge zona (§1).
5. Teste propuse in §7, aliniate stilistic cu suita existenta — de confirmat cu `d42-efactura` daca
   au fost deja scrise (mesajul lui mentioneaza "doua fisiere noi de test").
6. `ROAGEST\Programe\roagest.prg` (linia necomisa `SET PROCEDURE TO ofacturare_editare.prg`) **nu**
   apartine lui `d42-efactura` — ramane dintr-un alt bloc de lucru, de identificat separat de
   team-lead.