sync SVN r18077

docs/cercetare/s3_portare_antet.md

@@ -0,0 +1,478 @@
+# 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").