roafacturare/docs/cercetare/s3_portare_antet.md

# Cercetare — proiectare S3: portarea logicii de antet in formularul unificat

Investigatie READ-ONLY pentru povestea **S3** din `docs\plan_13_unificare_formular_facturare.md:1428-1439`.
Fara editari de cod, fara `git_sync.ps1`/`txt2vcx.ps1`, fara commit. Constrangerile din briefing —
`COMUN\clase\ofacturare_comun.vc2` si `COMUN\programe\ofacturare_editare.prg` doar citite (perimetrul
#6), `pack_facturare` si `pack_facturare_comun`-ul intern neatinse, analiticele read-only — respectate.

## Verdict (5-10 randuri)

S3 e **mai mare decat inventarul din plan sugereaza pe numar de metode** (29 `do_cauta_*` reale, nu
30 — vezi punctul 1), dar **mult mai mare decat sugereaza pe complexitate reala**, pentru doua motive
descoperite aici, nu presupuse: (a) `Init`, `inainte_de_do_termin` si — partial — `do_cauta_fdoc` sunt
**omonime cu semantica total diferita pe toate cele patru formulare-sursa** (antet vs. articole vs.
alte-date), deci portarea "o singura data" cere de fapt patru fuziuni de metoda, nu una singura cu
ramificare; (b) bug-ul **#16 e real, reprodus pe cod pana la linia exacta**, si **nu e un bug de focus**
— e o consecinta a faptului ca bucla de reincercare din `factureaza`/`factureaza2`
(`ofacturare.prg:174-571`) trateaza **orice esec SQL** (nu doar cursul lipsa) ca pe un "DA, continui cu
alt document", redeschizand din senin formularul de antet de la zero. Unificarea **nu-l reproduce
automat** — poate chiar sa-l elimine ca efect secundar, daca antetul nu se mai reconstruieste de la
Init dupa un esec Oracle in pasul urmator. Obstacolul principal pentru implementare nu e portarea
codului de validare (majoritatea e `Do Case`/`amessagebox` mecanic), ci **reconcilierea a patru cicluri
de viata `Init`/`inainte_de_do_termin` independente intr-unul singur**, cu ordinea de dependente de la
punctul 5.

---

## 1. Inventarul metodelor de portat — numere corectate

Sursa: `vfp_symbols.ps1 -Class frm_date_factura` / `-Class frm_date_aviz`, confirmat pe fisierul real
`COMUN\clase\ofacturare.vc2` (nu `.bak`).

**`frm_date_factura`** (`ofacturare.vc2:8482-9869`) — **16** metode `do_cauta_*`, nu 17:

| Metoda | Linii | Ce face | Echivalent in `frm_facturare_articole2` |
|---|---|---|---|
| `do_cauta_altele` | `8940-8961` (21) | cautare pe campul cu eticheta dinamica ("Altele"/contract/comanda/etc.) | nu |
| `do_cauta_avize` | `8963-8999` (36) | cautare aviz-sursa (tip=4) | nu |
| `do_cauta_client` | `9001-9060` (59) | cautare client, populeaza sold/cod fiscal | nu |
| `do_cauta_comanda` | `9062-9090` (28) | cautare comanda-sursa | nu |
| `do_cauta_contract` | `9092-9153` (61) | cautare contract-sursa | nu |
| `do_cauta_factura` | `9155-9171` (16) | cautare factura-sursa (credit note, tip 7) | nu |
| `do_cauta_facturi` | `9173-9212` (39) | cautare multi-factura (retur, tip 8/9) | nu |
| `do_cauta_fdoc` | `9214-9225` (11) | cautare generica fel-document, `caut_fdoc()` — **identica byte-cu-byte cu varianta din `frm_date_aviz`**, vezi punctul 4 | nu |
| `do_cauta_gestiune_init` | `9227-9242` (15) | cautare gestiune sursa | nu |
| `do_cauta_locatii` | `9244-9253` (9) | cautare locatie (tip 45) | nu |
| `do_cauta_lucrare` | `9255-9279` (24) | cautare lucrare | nu |
| `do_cauta_responsabil` | `9281-9301` (20) | cautare responsabil | nu |
| `do_cauta_sectie` | `9303-9342` (39) | cautare sectie | nu |
| `do_cauta_valuta` | `9344-9359` (15) | cautare valuta, muta focus pe `clb_zi_curs` daca exista, altfel pe serie (`:9351-9356`, deja conditionat `Type(...)<>'U'`) | nu |
| `do_cauta_venchelt` | `9361-9391` (30) | cautare venit/cheltuiala | nu |
| `do_cauta_venit` | `9393-9394` (1) | stub/alias, o linie — de verificat ce mai apeleaza | nu |
| `do_schimba_tipdoc` | `9396-9438` (42) | vezi punctul 6 — schimba `poDate.nIdTipDoc` si reinitializeaza serie+numar | **nu** — apelat orfan din prototip, vezi punctul 3 |
| `do_verifica` | `9440-9453` (13) | verificare ANAF pe cod fiscal client | nu (dar exista pe `frm_facturi`, aceeasi semantica) |
| `inainte_de_do_termin` | `9455-9561` (106) | validare completa antet inainte de trecerea la articole | **omonim cu semantica diferita** pe toate 4 formulare, vezi mai jos |
| `Init` | `9563-9796` (234) | vezi punctul 5 | **omonim cu semantica diferita**, vezi mai jos |
| `Clb_dataact...LostFocus` | `9798-9813` (15) | sincronizeaza `zi_curs=dataact` daca `clb_zi_curs` exista | nu |
| `Clb_dataireg...LostFocus` | `9815-9831` (16) | idem, pe `dataireg` | nu |
| `Clb_nract...LostFocus` | `9833-9835` (2) | — | nu |
| `Clb_serie_act...LostFocus` | `9837-9844` (7) | — | nu |
| `Ct_clb_fdoc._combobox1.Init` | `9846-9855` (9) | populeaza combo-ul FACTURA/PROFORMA/BON FISCAL | nu |
| `Ct_clb_fdoc._combobox1.LostFocus` | `9857-9859` (2) | `thisform.do_schimba_tipdoc()` — vezi punctul 6 | nu (frm_facturare_articole2 are un apel similar, dar **orfan**, vezi punctul 3) |
| `Ed_tx_simplu1._EDBASE1.KeyPress` | `9861-9867` (6) | — | nu |

**`frm_date_aviz`** (`ofacturare.vc2:6566-7618`) — **13** metode `do_cauta_*`, numarul din plan e corect:

| Metoda | Linii | Observatie |
|---|---|---|
| `do_cauta_altele` | `6882-6894` (12) | mai scurta decat pe factura (21) — set de tipuri mai mic |
| `do_cauta_avize` | `6896-6930` (34) | apropiata ca marime de factura (36) |
| `do_cauta_client` | `6932-7009` (77) | **mai lunga** decat pe factura (59) — trateaza eticheta variabila "Retur de la"/"Gestiune sursa" pe transfer |
| `do_cauta_comanda` | `7011-7034` (23) | |
| `do_cauta_contract` | `7036-7091` (55) | |
| `do_cauta_fdoc` | `7093-7104` (11) | **identica cu factura**, vezi punctul 4 |
| `do_cauta_gestiune_dest` | `7106-7131` (25) | **doar pe aviz** — gestiune destinatie la transfer subunitati |
| `do_cauta_gestiune_init` | `7133-7144` (11) | mai scurta decat pe factura (15) |
| `do_cauta_lucrare` | `7146-7165` (19) | |
| `do_cauta_politica` | `7167-7182` (15) | **doar pe aviz** — `Ct_clb_politici_preturi` |
| `do_cauta_responsabil` | `7184-7204` (20) | aceeasi lungime ca factura |
| `do_cauta_sectie` | `7206-7240` (34) | |
| `do_cauta_venchelt` | `7242-7275` (33) | |
| `inainte_de_do_termin` | `7277-7352` (75) | **omonim**, vezi mai jos — mai scurta decat factura (106): fara validare data-scadenta, fara validare valuta, fara validare client (!) |
| `Init` | `7354-7600` (247) | **omonim**, nu citit integral aici (doar `9563-9650`+`9733-9796` echivalentul pe factura) |
| `Clb_dataact...LostFocus` | `7602-7605` | |
| `Clb_dataireg...LostFocus` | `7607-7612` | |
| `Clb_nract...LostFocus` | `7614-7616` | |

**`frm_date_aviz` nu are `do_schimba_tipdoc`** — confirmat, container-ul `Ct_clb_fdoc` de pe aviz e
o cautare simpla, fara combo si fara evenimentul `LostFocus` care declanseaza schimbarea de tip.

**Total real: 16 + 13 = 29 metode `do_cauta_*`**, plus `do_schimba_tipdoc` (doar factura), `do_verifica`
(doar factura), `inainte_de_do_termin` si `Init` (omonime pe ambele) — planul le numara global corect
ca "17+13 ... plus restul", dar cifra "17" pe factura e gresita cu o unitate: **16**.

---

## 2. Metodele omonime — capcana centrala a portarii

**Nivelul care conteaza cel mai mult, necunoscut inca in plan**: `Init` si `inainte_de_do_termin` sunt
**acelasi nume de metoda pe toate cele patru formulare-sursa implicate in unificare**
(`frm_date_factura`, `frm_date_aviz`, `frm_facturare_articole`/`frm_facturare_articole2`,
`frm_alte_date`), fiecare cu corp complet diferit (antet vs. compunere articole vs. date suplimentare).
O singura clasa unificata nu poate avea patru metode `Init`. **Portarea "o singura data" a S3 inseamna
concret: patru corpuri de `Init` si patru corpuri de `inainte_de_do_termin` trebuie topite intr-un
singur `Init` si un singur `inainte_de_do_termin` (sau redenumite si inlantuite explicit)** — asta e
efortul real, nu doar mutarea codului de validare camp-cu-camp.

**`inainte_de_do_termin`, factura vs. aviz — diferenta reala, cu citat** (comparate direct, ambele corpuri
citite integral, `ofacturare.vc2:9455-9561` si `:7277-7352`):

- **Factura valideaza `id_client` obligatoriu; aviz nu valideaza deloc acest camp**:
  ```
  ofacturare.vc2:9510-9513 (doar pe factura)
  Case Empty(poDate.id_client) Or Isnull(poDate.id_client)
      amessagebox("Nu ati ales clientul!",48,"Atentie")
      This.ct_clb_nume_client.SetFocus()
  ```
  Motiv plauzibil (neconfirmat mai departe): avizele de transfer intre subunitati (tip 23/25/30/41) nu
  au neaparat un "client" — au o gestiune destinatie, validata separat.
- **Factura valideaza scadenta si valuta; aviz nu are deloc aceste `Case`-uri** — `Empty(poDate.datascad)`,
  `poDate.datascad<poDate.dataact`, `poDate.in_valuta=1 And Empty(zi_curs)`, `poDate.in_valuta=1 And
  Empty(id_valuta)` (`:9471-9493`) — aviz nu are control de valuta pe formular (S1, randul "Valuta").
- **Aviz valideaza politica de preturi; factura nu**:
  ```
  ofacturare.vc2:7334-7337 (doar pe aviz)
  Case Empty(Nvl(poDate.id_pol,0)) And InList(poDate.tip,23,41)
      amessagebox("Nu ati ales politica de preturi!",48,"Atentie")
  ```
- **Setul de tipuri si mesaje pentru "sursa neselectata" (`listaid`) e complet diferit**: factura
  `!Inlist(poDate.tip,1,5,7,8,9,10,48,49)` cu mesaje contract/comanda/aviz/locatie (`:9528-9541`); aviz
  `Inlist(poDate.tip,21,23,25,26,28,41,42,47)` cu mesaje comanda/gestiune-destinatie/gestiune-retur/contract
  (`:7318-7333`) — seturile de `tip` nu se suprapun deloc (factura = tipuri <21 sau in {45,48,49,51,52};
  aviz = tipuri >=21 in afara de 27/30). **Discriminatorul natural pentru ramificare exista deja**:
  `poDate.nIdTipDoc` (5=FACTURA, 6=AVIZ — calculat de apelant la `ofacturare.prg:192-196`) sau simpla
  apartenenta a lui `poDate.tip` la unul din cele doua seturi disjuncte, **nu** un flag nou.
- **Contul folosit la verificarea de facturi duplicate difera**: `facturi_duplicate('4111', 0, ...)`
  (factura, `:9545`, cont clienti) vs. `facturi_duplicate('418', 0, ...)` (aviz, `:7341`, alt cont) —
  un literal hardcodat care trebuie sa devina el insusi parte din ramificare, nu doar mesajul.

**Alte omonime cunoscute, cu semantica diferita, relevante pentru zona din jurul lui S3** (nu introduse
aici — reconfirmate, vezi si `docs\handoff_13_formular_unificat.md:192-194`):
- `do_calculeaza_discount` — **la nivel de document** pe `frm_facturare_articole` (`:13405-13424`) si
  `frm_facturare_articole2` (`:17670-17686`, verificat aici: identic ca semantica, scrie
  `Thisform.ndiscfactron`/`ndiscfactval`); **la nivel de linie** pe `frm_articol_factura` (`:1874-1976`,
  scrie `poArticol.discount_unitar*`). Nu intra direct in S3 (nu e printre metodele antetului), dar
  orice cod nou care apeleaza `do_calculeaza_discount` prin nume pe formularul unificat trebuie sa
  stie care semantica o vrea.
- `do_verifica` — pe `frm_date_factura` (`:9440-9453`, verificare ANAF) si pe `frm_facturi`
  (verificare ANAF, aceeasi semantica) — omonim inofensiv, aceeasi actiune.
- `do_cauta_gestiune_init` / `do_cauta_responsabil` / `do_cauta_sectie` / `do_cauta_venchelt` /
  `do_cauta_altele` / `do_cauta_comanda` / `do_cauta_contract` / `do_cauta_avize` / `do_cauta_lucrare` —
  **acelasi nume pe factura si aviz, lungimi diferite** (vezi tabelele de la punctul 1) — nu omonime
  periculoase (aceeasi intentie: cautare pe camp), dar **nu identice** — portarea trebuie sa ia corpul
  fiecareia separat, nu sa presupuna ca sunt duplicate de sters.
- **Singura pereche confirmata identica byte-cu-byte**: `do_cauta_fdoc` (vezi punctul 4) — aceasta
  chiar poate fi portata o singura data, fara ramificare.

---

## 3. Ce e deja in prototip vs. ce lipseste

`frm_facturare_articole2` (`ofacturare.vc2:15741-19355`) are controalele de antet montate direct pe
formular (confirmat in `inventar_controale_formulare.md`), dar **zero logica**:

| Metoda/mecanism | Exista in `frm_facturare_articole2`? | Detaliu |
|---|---|---|
| Toate cele 29 `do_cauta_*` | **NU** | niciunul in lista de metode proprii a clasei (confirmat cu `vfp_symbols.ps1 -Class`) |
| `do_schimba_tipdoc` | **NU, dar e APELAT** — cod orfan | `clb_fdoc.cboFdoc.Valid` (`:19255-19257`) contine `thisform.do_schimba_tipdoc()`, dar clasa **nu are** aceasta metoda in lista proprie. Daca userul ar schimba azi combo-ul `clb_fdoc` pe acest formular mort, ar cadea cu eroare de metoda inexistenta. Confirma independent constatarea din plan ("controalele sunt acolo, logica nu") — de fapt e mai rau: e cod care ar crapa daca s-ar activa calea, nu doar cod lipsa |
| `inainte_de_do_termin` | **DA, dar cu alta semantica** | `:18809-18986` (178 linii) — valideaza ARTICOLE (stoc, discount, TVA), nu antetul; e omonimul de care vorbeste punctul 2, nu un candidat de reutilizare pentru validarea de antet |
| `Init` | **DA, dar cu alta semantica** | `:18988-19080` (92 linii, citit integral aici) — confirmat: doar grid/curs-label/total-mode/coloane in/afara valuta; **niciun** `poDate.xxx -> control.Value`. Nu populeaza antetul deloc |
| Serie/numar (`Clb_serie_act1`/`Clb_nract`) | Controale prezente, dar fara wiring de populare in `Init` | `Clb_serie_act1.TEXT_SIMPLU1.LostFocus` (`:19263-19270`) exista ca metoda proprie — nu verificat aici daca reproduce `genereazanumar` |

**Concluzie punctul 3**: prototipul e o **coaja vizuala**, nu un schelet de 50% functional. Ce trebuie
scris pentru S3 e efectiv tot codul de comportament — controalele economisesc timpul de aranjare in
`.scx`/`.vcx`, nu timpul de portare a logicii.

---

## 4. Ramificarea factura / aviz in interior

**Discriminatorul de ramificare recomandat: `poDate.nIdTipDoc`** (5=FACTURA, 6=AVIZ), deja calculat de
apelant inainte de `Createobject` (`ofacturare.prg:187-196`) si deja disponibil pe `poDate` in
momentul in care formularul unificat ar porni `Init`. Alternativ, acelasi rezultat se obtine testand
direct apartenenta lui `poDate.tip` la unul din cele doua seturi disjuncte folosite azi in
`inainte_de_do_termin` (vezi punctul 2) — cele doua seturi nu se suprapun niciodata, deci nu exista
ambiguitate. **Nu e nevoie de o proprietate noua** gen `lEsteAviz` — `nIdTipDoc` face deja treaba, si
e deja pe obiectul `poDate` care trece prin tot lantul de apeluri.

Ce trebuie sa ramifice concret, cu dovada:
1. **`inainte_de_do_termin`** — Cases specifice fiecarei parti (vezi citatele de la punctul 2), plus
   constanta de cont (`'4111'` vs `'418'`) la `facturi_duplicate`.
2. **`Init`** — seturile `Do Case poDate.tip` care decid ce se elimina (`RemoveObject`) difera pe
   fiecare parte (S1 documenteaza deja fiecare camp cu conditia lui de vizibilitate; portarea trebuie
   sa pastreze fiecare conditie identic, nu sa le generalizeze pe ghicite).
3. **`do_schimba_tipdoc`** — **exista doar pe factura**; pe aviz nu exista mecanismul de schimbare a
   tipului de document dupa deschiderea formularului (containerul `ct_clb_fdoc` de pe aviz e cautare
   simpla, fara `_combobox1`). Ramificarea aici nu e "cod diferit pe aceeasi metoda" ci "metoda
   prezenta doar pe o ramura" — formularul unificat trebuie sa decida daca aviz capata acest
   comportament nou (schimbare tip dupa deschidere) sau ramane fara el, ca azi.
4. **`do_cauta_fdoc`** — **nu ramifica**, e identic (punctul 1) — poate fi portat o singura data, fara
   `If nIdTipDoc=...`.
5. **`do_cauta_client`** — aviz e cu 18 linii mai lung (77 vs 59) pentru eticheta variabila
   "Retur de la"/"Gestiune sursa" pe transfer (S1, randul "Client") — de citit integral la
   implementare pentru ramificarea exacta, nu verificat linie-cu-linie aici.

---

## 5. `Init`-urile — ce face fiecare, in ce ordine, ce depinde de ce

**Secventa de azi, pe drumul normal (factura din lista de preturi, fara eroare Oracle):**

1. **Apelantul** (`ofacturare.prg:factureaza`, inainte de orice `Createobject`): construieste
   `poDate = Createobject("oDateFactura", ...)` si `poGeneratorNumere = Createobject("oGeneratorNumere")`
   (`:184-185`), seteaza `poDate.nIdTipDoc` (`:187-196`), cheama
   `poDate.completeaza_setari_document(...)` daca e copiere (`:200-206`), apoi
   `poGeneratorNumere.ResetNumere()` si `poDate.rezultat_serii = poGeneratorNumere.creeaza_cursor_serii(...)`
   (`:208-211`) — **toate acestea ruleaza inainte ca vreun formular sa existe**. Orice `Init` de mai jos
   presupune `poDate`/`poGeneratorNumere` deja populate.
2. **`frm_date_factura.Init`** (`:9563-9796`, 234 linii, citit integral aici) — `DoDefault()`, apoi
   masoara inaltimile containerelor de antet intr-un array (`laPozitii`), decide pe `Do Case
   gnScadereStoc/poDate.tip` ce containere elimina (`RemoveObject`) si reface layout-ul pe verticala,
   initializeaza serie+numar (`.clb_serie_act.do_initializeaza(poDate.rezultat_serii)`, `:9737`), si
   **la final** seteaza focus: pe `ct_clb_valuta` daca documentul e in valuta si campul valutei apare
   deasupra tipului si nu are inca valuta aleasa, **altfel pe `ct_clb_fdoc`** (`:9788-9793`, citat
   integral la punctul 6). Depinde de: `poDate` (tip, in_valuta, ...), `poGeneratorNumere`
   (`creeaza_cursor_serii` deja rulat de apelant), variabile globale de firma (`gnScadereStoc`).
3. **`frm_facturare_articole2.Init`** (`:18988-19080`, 92 linii, citit integral aici) — confirmat:
   **nu atinge niciun camp de antet**. Configureaza doar gridul (`nNrInregVizibile`), eticheta
   cursurilor valutare, modul total (`gnModTotFact`), si elimina coloanele RON sau valuta din grid
   dupa `poDate.in_valuta`. Depinde de: `poDate.zi_curs`/`in_valuta`/`tip`, `crscursuri` (populat de
   apelant intre pasii 2 si 3, nu de acest `Init`).
4. **`frm_alte_date.Init`** (`ferestre_cere_date.vc2:3105-3207`, 103 linii, citit integral aici) —
   `DoDefault()`, citeste `poDate.dataora_exp`; **daca nu e proforma**: cauta ultimul delegat/masina
   folosite pentru client (apel Oracle `cauta_date_ultima_factura[_tip]`, `:3119-3136`), populeaza
   combo-ul de casa dintr-un cursor Oracle nou (`v_nom_casa`, `:3156-3173`), seteaza `opt_incasat`
   implicit daca `poDate.incasat<>0`; **daca e proforma**: elimina complet grupul delegat/masina/
   incasare (`RemoveObject` in cascada, `:3192-3201`) si redimensioneaza formularul la zona de text
   aditional. **Risc gasit, neurmarit mai departe**: pe eroare la interogarea combo-ului de casa,
   `Init` cheama `poGeneratorNumere.dezaloca_numar(5)` si `Return` (`:3159-3161`) — acelasi tipar de
   "dezalocare numar pe eroare SQL neasteptata" ca la bug-ul #16 (punctul 6), dar intr-un `Init`, nu
   intr-o bucla — **nu s-a verificat daca are aceeasi consecinta de recreare completa a formularului**;
   semnalat, nu investigat suplimentar aici din motive de buget de context.

**Ordinea de dependente, explicit**: `poDate`+`poGeneratorNumere` (apelant) -> `frm_date_factura`/
`frm_date_aviz.Init` (foloseste serie/numar deja create) -> **Oracle: cursorul de articole**
(`ofacturare.prg:266-308`, aici poate pica bug #16) -> `frm_facturare_articole2.Init` (foloseste
`crscursuri` populat intre pasi, nu de propriul `Init`) -> `frm_alte_date.Init` (face **inca** un apel
Oracle nou, cu propriul risc de dezalocare). **Pentru formularul unificat, aceasta secventa de patru
`Init`-uri trebuie sa devina un singur `Init` care ruleaza fazat** (o singura data la deschidere) —
sau ramane o discutie deschisa daca vreo faza (Oracle-lookup-ul din `frm_alte_date.Init`) ramane
intarziata pana la deschiderea sectiunii pliate, ca sa nu incarce round-trip-uri Oracle inutile cand
utilizatorul nu ajunge niciodata la acea sectiune.

---

## 6. Bug-ul #16 — mecanismul exact, verificat pe cod

**Text original** (`COMUN\docs\todos.txt:45`): *"la revenire din formularul de curs valutar, focusul
revine inainte de numar document, cred ca pe TIP DOCUMENT, si la iesire din serie se regenereaza numar
act, ceea ce este periculos daca utilizatorul l-a schimbat".*

**Verdict: NU e un bug de focus. E o bucla de reincercare care trateaza orice esec Oracle ca pe un "DA,
mai fac un document" si reconstruieste formularul de antet de la zero — focusul si regenerarea
numarului sunt doar simptomele vizibile ale acestei reconstructii.**

Lantul complet, verificat linie cu linie:

1. Utilizatorul completeaza antetul, apasa Termina — `inainte_de_do_termin` trece, formularul de antet
   se inchide (`pnButon=1`).
2. Apelantul (`factureaza`, `ofacturare.prg:266-308`) construieste cursorul de articole din Oracle
   (`cursor_preturi`/etc., functie de `poDate.tip`). **Daca cererea esueaza** (`lnSucces<0`,
   `:313`) — inclusiv, dar nu numai, cu eroarea Oracle `-20005` "Nu este setat cursul..." (curs
   valutar lipsa pentru o valuta din listele de preturi ale utilizatorului, verificata neconditionat
   in `pack_facturare.verifica_cursuri_valute`, documentat deja in `zi_curs_validare.md`):
   ```
   ofacturare.prg:313-322
   If lnSucces < 0
       AMESSAGEBOX(goExecutor.oPrelucrareEroare(), 16, "Eroare")
       If goExecutor.nEroare = 20005
           vizualizeaza_curs(poDate.zi_curs)      && deschide "formularul de curs valutar" (frm_curs, modal)
       ENDIF
       poGeneratorNumere.dezaloca_numar(poDate.nIdTipDoc)   && numarul alocat se elibereaza
   Else
       ... [singurul loc unde se cere "Doriti sa continuati?" si se seteaza lnRaspuns]
   Endif
   ```
   `vizualizeaza_curs` (`oproceduri_curs.prg:8-42`) e confirmat: deschide `Createobject("frm_curs",
   tdDataCurs).Show(1)` — chiar formularul din reclamatie.
3. **Punctul central, verificat prin numararea `If`/`Else`/`Endif` din fisier**: prompt-ul "Doriti sa
   continuati cu operatii de acest fel?" care seteaza variabila de bucla `lnRaspuns` **exista doar in
   ramura `Else` a lui `If lnSucces<0`** (`ofacturare.prg:555-564`, in interiorul aceluiasi bloc
   `If/Else/Endif` care se inchide abia la `:568`). **Pe ramura de eroare (`lnSucces<0`), `lnRaspuns`
   nu e niciodata atins.** Isi pastreaza valoarea din intrarea in aceasta iteratie a buclei — pe primul
   document, `6` (initializat la `:174`, inainte de `Do While lnRaspuns = 6` de la `:175`).
4. Bucla externa (`Do While lnRaspuns = 6 ... Enddo`, `:175-571`) **reintra automat**, fara nicio
   intrebare catre utilizator, pentru ca `lnRaspuns` e inca `6`. In aceasta noua iteratie:
   `poGeneratorNumere.ResetNumere()` si `poDate.rezultat_serii = poGeneratorNumere.creeaza_cursor_serii(...)`
   ruleaza din nou (`:208-211`), apoi se creeaza **o instanta noua** de `frm_date_factura`/`frm_date_aviz`
   (`Createobject`, `:230`) si se arata modal (`:235`) — `poDate` insusi **nu** e recreat (ramane
   acelasi obiect, cu `nract`/`serie_act` deja setate de utilizator), dar **formularul da**, deci
   `Init` ruleaza de la capat.
5. `frm_date_factura.Init` (`:9563-9796`) reface layout-ul si, **la final, seteaza focus necondiționat
   pe `ct_clb_fdoc`** (tip document) in cazul normal:
   ```
   ofacturare.vc2:9788-9793
   DO CASE
       CASE poDate.in_valuta = 1 and this.ct_clb_valuta.Top < this.ct_clb_fdoc.Top AND EMPTY(NVL(poDate.nume_valuta,''))
           this.ct_clb_valuta.SetFocus()
       OTHERWISE
           this.ct_clb_fdoc.SetFocus()
   ENDCASE
   ```
   **Aceasta e "focusul care revine pe TIP DOCUMENT"** din reclamatie — nu un bug izolat de focus, ci
   comportamentul normal de `Init` al unui formular nou, aparut unde utilizatorul nu se astepta la un
   formular nou.
6. Cand focusul paraseste `ct_clb_fdoc` (Tab, click in alta parte — orice), se declanseaza
   `Ct_clb_fdoc._combobox1.LostFocus -> thisform.do_schimba_tipdoc()` (`:9857-9859`). Prima linie a
   acestei metode, **inainte de orice verificare "tipul chiar s-a schimbat?"**:
   ```
   ofacturare.vc2:9417 (in do_schimba_tipdoc, INAINTE de guard-ul de la :9419-9421)
   This.clb_serie_act._cbbase1.LostFocus()
   ```
   — apeleaza **neconditionat** handler-ul de LostFocus al combo-ului de serie, indiferent daca tipul
   documentului s-a schimbat sau nu.
7. Acel handler (`serii_numere.vc2:138-140`, clasa `clb_serie_act`) cheama `genereazanumar` (`:114-136`):
   ```
   serii_numere.vc2:122-127
   If poGeneratorNumere.verifica_serie(This.nid_tipdoc) Or &lcValoare. = 0
       lcValoare = lcValoare+[=]+ALLTRIM(Str(poGeneratorNumere.aloca_numar(This.nid_tipdoc,Null),20,0))
       &lcValoare
       This.Parent.Refresh()
   Endif
   ```
   — **aloca un numar nou** si il scrie peste `poDate.nract` prin macro, **necondiționat de ce numar
   avea utilizatorul inainte**. **Asta e "iesirea din serie regenereaza numarul actului"** din
   reclamatie — confirmat exact, pana la linia care face scrierea.

**Verdict pe intrebarea planului ("se rezolva #16 in S3, sau se reproduce bug-ul?"): se poate rezolva
in S3, cu un cost mic, dar nu e o consecinta automata a unificarii — trebuie tratat explicit.**
Cauza reala nu e in `frm_date_factura`/`do_schimba_tipdoc`/`clb_serie_act` (cod care se comporta
"corect" fata de contractul lui local), ci in bucla de reincercare din apelant
(`ofacturare.prg:174-571`), care **nu distinge "utilizatorul a confirmat ca vrea alt document" de
"cererea Oracle a esuat"**. Doua directii posibile, ambele in afara perimetrului strict al portarii de
antet, dar declansate direct de ea:
- **(a) minimal**: in formularul unificat, dupa un esec Oracle la pasul de construire a cursorului de
  articole (echivalentul liniei `:313`), **nu se distruge formularul de antet** — antetul e deja o
  singura sectiune persistenta a aceluiasi formular, nu un obiect separat recreat de apelant; simpla
  arhitectura unificata (un `Init` per sesiune de emitere, nu per formular) elimina pasul 4 de mai sus,
  deci elimina intreg lantul 5-7. **Acesta e motivul pentru care unificarea are sansa reala sa rezolve
  #16 ca efect secundar** — dar numai daca implementarea nu recreeaza formularul intreg la reincercare
  dupa eroare Oracle (ceea ce ar reproduce bug-ul identic, doar mutat).
- **(b) daca (a) nu e suficient** (de ex. daca dupa fix la curs tot trebuie relansata interogarea de
  articole): `lnRaspuns` (sau echivalentul lui in noua arhitectura) trebuie resetat explicit pe orice
  cale care iese din ramura de eroare, ca sa nu mai fie confundat cu "utilizatorul a spus DA".

**Coordonarea cu #6 (decizia 30 si constrangerea din briefing) — verificat direct pe diff-uri, nu doar
pe proza handoff-ului**: `docs\diff_s4_valuta_dialog*.patch` (trei fisiere) ating exclusiv
`COMUN\clase\omodificari.vc2`, `COMUN\programe\ofacturare_editare.prg` si un fisier de test —
**niciunul nu atinge `ofacturare.vc2` (unde traiesc `frm_date_factura`, `do_schimba_tipdoc`,
`clb_serie_act`) sau `ofacturare.prg` (unde traieste bucla `factureaza`)**. Confirmat si de continutul
lui handoff intermediar (sters): intreaga lui cercetare e despre `frm_articol_factura`
(dialogul de adaugare articol pe linie, alt fisier/clasa) si `frm_modific2024.cmdAdaugaArticol.Click`
— un mecanism de valuta **pe linie de articol**, fara nicio legatura cu antetul sau cu bucla de
emitere. **#6 nu a atins deloc lantul lui #16. Bug-ul e in intregime valabil si neschimbat.**

---

## 7. Ordinea de lucru propusa pentru S3

Pasi care lasa suita functionala dupa fiecare (calea veche ramane in productie pe tot parcursul —
niciun pas nu sterge `frm_date_factura`/`frm_date_aviz`/`frm_alte_date` originale):

1. **Fuzioneaza `Init`-urile de antet** (`frm_date_factura` + `frm_date_aviz`) intr-o metoda unica pe
   formularul unificat, ramificata pe `poDate.nIdTipDoc` (punctul 4). Verificare: formularul unificat
   se deschide pe fiecare din cele ~15 tipuri principale de `poDate.tip` folosite azi in cele doua
   `Init`-uri, si arata exact aceleasi campuri vizibile/eliminate ca varianta veche — comparatie
   camp-cu-camp fata de tabelul din `docs\S1_inventar_campuri_formular_unificat.md`.
2. **Porteaza cele 29 `do_cauta_*`** (fara ramificare unde sunt identice — `do_cauta_fdoc` — cu
   ramificare pe `nIdTipDoc` unde difera). Verificare: fiecare cautare deschide acelasi dialog, scrie
   aceleasi proprietati pe `poDate`, muta focusul identic cu azi.
3. **Fuzioneaza `inainte_de_do_termin`**, cu ramificarea documentata la punctul 2. Verificare: aceleasi
   mesaje de eroare, in acelasi ordine, pentru aceleasi campuri goale, pe fiecare tip.
4. **Porteaza `do_schimba_tipdoc`** — decide explicit daca ramane doar-factura sau se extinde si pe
   aviz (punctul 4, pct. 3). **Aici se rezolva sau nu #16** (punctul 6) — de facut ca parte a acestui
   pas, nu separat, pentru ca schimbarea de arhitectura care il rezolva (un singur `Init` persistent)
   e chiar cea care se construieste la pasul 1.
5. **Porteaza `but_modifica`/blocarea antetului** (decizia 9, deja proiectata in plan sectiunea I) —
   depinde de pasii 1-4 fiind stabili, pentru ca reutilizeaza aceleasi controale.
6. **Integreaza bucla de emitere** (`factureaza`/`factureaza2`) cu noul formular unificat, tratand
   explicit esecul Oracle de la cursorul de articole (punctul 6, directia a/b).

**Criteriul de "gata", rescris verificabil.** Azi planul spune "un document se emite integral din
formularul unificat, pe tip 1, cu acelasi rezultat in `vanzari`/`act`/`rul` ca pe calea veche" — fara
sa spuna cum se compara. Propunere concreta:
- Se emite **acelasi document** (acelasi client, articole, cantitati, preturi) o data pe calea veche
  (`frm_date_factura` -> `frm_facturare_articole` -> `frm_alte_date`) si o data pe formularul unificat,
  pe date de test identice, in aceeasi zi contabila.
- Se compara, randuri-cu-randuri, rezultatul in `VANZARI` (toate coloanele, nu doar sumele), `ACT`,
  `RUL`, `DOCUMENTE`, `JV2007` (nota contabila) — cel mai simplu cu doua interogari identice filtrate
  pe cei doi `ID_FACT`/`ID_VANZARE` rezultati, exportate si diff-uite text-cu-text (unealta: acelasi
  export SQL folosit deja pentru `PACK_FACTURARE` in `docs\ff_*.sql`, adaptat pe `SELECT * FROM VANZARI
  WHERE ID_FACT=...`).
- Diferentele **asteptate** (marcate ca OK, nu ca esec): `ID_VANZARE`/`ID_FACT`/timestamp-uri de
  creare — orice altceva trebuie sa fie identic.
- Se repeta pentru **cel putin un tip de factura in valuta** (S3 atinge direct campurile de valuta) si
  **un tip de aviz** (ramificarea de la punctul 4), nu doar tip 1.

---

## 8. Ce nu se poate testa headless din S3

Capcana cunoscuta (`COMUN\docs\depanare_testare_vfp.md`, memorie de proiect): sub harness `-A -T`,
coloanele de grid nu se materializeaza (`ColumnCount=0`, `RecordSource` raman artefacte necitite) —
relevant direct pentru `frm_facturare_articole2` (grid-ul de compunere), dar S3 propriu-zis nu atinge
gridul.

Specific pentru S3 (antet):
- **Toate cele 29 `do_cauta_*`** deschid un dialog modal de cautare (`caut_ora.vcx`/similare) —
  interactiunea reala de selectare dintr-o lista si `Show(1)` modal nu se poate simula headless; se
  pot testa doar efectele **dupa** ce `poCauta`/rezultatul e construit manual (tiparul deja folosit in
  `test_pret_cu_tva_dialog.prg`/`test_adauga_linie_valuta.prg` mentionat in
  handoff intermediar (sters), punctul 7) — apel direct al metodei cu un obiect
  simulat, fara `Show()`.
- **`Init`-ul complet** (redimensionare, `RemoveObject` in cascada, repozitionare containere) e
  verificabil pe proprietati (`.Visible`, `.Height`, existenta obiectului dupa `Type(...)`) fara UI
  vizibil, pentru ca `Createobject` ruleaza `Init` fara `Show()` — tiparul e deja validat in codebase.
- **Focusul si secventa reala de `LostFocus`** (exact ce a produs bug #16) **nu se poate reproduce
  headless** — necesita fie `vfp_ui_harness.ps1` cu UI vizibil si input simulat pe masina, fie testare
  manuala de Marius; simularea unui `SetFocus()`/`LostFocus()` apelat direct din cod ocoleste tocmai
  secventa evenimentelor native care a cauzat bugul.
- **Eroarea Oracle -20005 si redeschiderea `vizualizeaza_curs`** — reproductibila headless doar daca
  se poate forta controlat lipsa unui curs pentru o data de test (manipulare de date, nu de UI) — nu
  s-a verificat aici daca exista deja o retetare de date de test pentru asta.

---

## Ce nu s-a putut stabili si de ce

- **Corpul complet al `frm_date_aviz.Init`** (`:7354-7600`, 247 linii) — citit doar partial in sesiuni
  anterioare (pana la `~7533`, conform `inventar_controale_formulare.md:166-167`); nu re-citit integral
  aici din motive de buget de context. Structura generala (Do Case pe tip, RemoveObject, focus final)
  e foarte probabil simetrica cu `frm_date_factura.Init`, dar nu verificata linie-cu-linie.
- **`do_cauta_venit`** (`frm_date_factura`, `:9393-9394`, o singura linie) — nu s-a citit continutul;
  posibil alias/stub mort, de verificat la implementare.
- **Riscul semnalat la punctul 5** (`frm_alte_date.Init:3159`, `dezaloca_numar` pe eroare la
  interogarea combo-ului de casa) — **doar semnalat, neurmarit**: nu s-a verificat daca apelantul care
  cheama `frm_alte_date` are aceeasi bucla "retry silentios" ca `factureaza`, sau daca eroarea aici
  chiar opreste fluxul curat (`Return` explicit la `:3161`, spre deosebire de bug #16 unde nu exista
  `Return` echivalent). Merita o cercetare separata, de marimea celei de la punctul 6, inainte de
  implementare.
- **`Clb_serie_act1.TEXT_SIMPLU1.LostFocus`** din `frm_facturare_articole2` (`:19263-19270`) — nu
  citit; nu s-a verificat daca reproduce corect `genereazanumar` sau e alt cod orfan ca cel de la
  punctul 3.
- **Ramificarea exacta linie-cu-linie pentru restul celor 27 de perechi `do_cauta_*`** (dincolo de
  `do_cauta_client` si `do_cauta_fdoc`, comparate direct aici) — s-au comparat doar lungimile (indiciu
  de diferenta), nu continutul; de citit la implementare, nu presupus din lungime.
- **`frm_modifica_factura`** — clasa reala traieste in `ofacturare_comun.vc2` (perimetrul #6, doar
  citire permisa), dar `vfp_symbols.ps1` a indexat-o din `.pre_s4butoane.bak.vc2` (linii duplicate,
  nesigure) — nu s-au recitit liniile reale, pentru ca `frm_modifica_factura` **nu intra in portarea
  S3** (e inlocuita de `but_modifica`, deja proiectat separat in plan, sectiunea I).

## Bug-uri semnalate, nereparate

1. **Cod orfan in `frm_facturare_articole2`**: `clb_fdoc.cboFdoc.Valid` (`ofacturare.vc2:19256`) cheama
   `thisform.do_schimba_tipdoc()`, metoda **inexistenta** pe aceasta clasa — ar arunca eroare VFP daca
   userul ar interactiona cu acest combo pe formularul mort. Fara consecinte azi (formularul nu e
   accesibil in productie, cf. plan sectiunea A), dar de curatat sau completat cand prototipul devine
   baza formularului unificat.
2. **Bug #16, confirmat si localizat complet** (punctul 6) — in `ofacturare.prg:555-564` (si simetric
   in `factureaza2`, liniile ~1061 dupa numerotarea echivalenta, nu verificate linie-cu-linie aici):
   `lnRaspuns` nu se reseteaza pe ramura de eroare Oracle a buclei de emitere, cauzand recrearea
   completa si nesolicitata a formularului de antet. In afara perimetrului `ofacturare_comun.vc2`/
   `ofacturare_editare.prg` (deci nu ciocneste cu #6), dar in `ofacturare.vc2`/`ofacturare.prg`, cod
   comun suitei (afecteaza si ROACONT/ROAGEST/etc. daca folosesc acelasi `factureaza`/`factureaza2`
   din `COMUN` — neverificat aici daca alte produse il apeleaza, dar fisierul e in `COMUN\programe`,
   deci probabil da).
3. **Risc structural similar, neconfirmat**: `frm_alte_date.Init:3159` — acelasi tipar
   "`dezaloca_numar` pe eroare SQL neasteptata", posibil fara aceeasi consecinta de reincercare
   silentioasa, dar nu verificat (vezi "Ce nu s-a putut stabili").