Transa 2: changelog 2.11.68, versiune_db, plan cu semnatura oExecute si decizia pe N

Plan completat: tlReconnect e al 8-lea parametru din oExecute si e implicit .T., deci transa 3
trebuie sa-l paseze .F. explicit. N din dialogul transei 3 numara facturi distincte (decizie
marius.mutu, 28.07.2026).

SVN r17914; script DB in DATABASE r17912.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhJwsrFFe1ZNAAtS8Twuti

docs/handoff_transa2.md

@@ -0,0 +1,51 @@
+# Handoff TRANSA 2 (L4) — borderou eFactura, taxare inversa
+
+Data: 28.07.2026. Status: implementat si validat pe schema dev, NEAPLICAT pe view-urile reale.
+
+## Ce am scris
+
+1. `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\07\ff_2026_07_28_01_COMUN_EFACTURA.sql` (nou, CRLF):
+   `create or replace view` pentru `anaf_vefactura_primit` (coloana `jtva_ti` = suma celor 13
+   termeni `TI*`/`XX*TIT` de pe `jc2007`, printr-un singur `CROSS APPLY` care intoarce si
+   `jtotctva` si `jtva_ti` odata — un singur scan, nu doi subselecti) si `anaf_vefactura_trimis`
+   (`jtva_ti` = `0` constant, `jtotctva` neschimbat). La final: `alter view ... compile` pe cele
+   doua DETALIU + verificare `user_objects.status='INVALID'` care arunca eroare daca ramane ceva
+   invalid. `versiune_db.txt`: `2026_07_26_02` -> `2026_07_28_01`.
+2. `COMUN\programe\import_efactura.prg`: sonda `user_tab_columns` pe `lcTabel` (`goExecutor.oExecuta`,
+   tipar deja folosit in fisier la `cGestiuni`/`cUMISO`/`cUM`) inainte de a construi `lcSelect`;
+   `lcExprDiferenta` ia una din doua forme (cu/fara `jtva_ti`), injectata prin `<<m.lcExprDiferenta>>`
+   in `TEXTMERGE`. `lcSchema` neatins (numar de coloane identic). Antet actualizat cu intrare noua
+   `*!* 28.07.2026 / marius.mutu`.
+
+## Ce am validat pe baza (`MARIUSM_AUTO@ROA_CENTRAL`, doar SELECT + view-uri temporare)
+
+Am creat `zz_test_jtva_primit`/`zz_test_jtva_trimis` cu EXACT corpul din script, verificat, apoi
+`DROP VIEW` pe amandoua (confirmat: `no rows selected` la interogarea finala pe `user_objects`).
+
+- Ambele compileaza (`STATUS = VALID`).
+- `zz_test_jtva_primit`: 487 randuri (coincide cu ce raporta handoff-ul conditiilor); 459 pe trimis.
+- Cele 8 randuri cu `id_fact` completat: `jtotctva` neschimbat fata de azi, `jtva_ti = 0` pe toate
+  (niciuna nu e taxare inversa — coincide cu constatarea din `handoff_transa2_conditii.md`).
+- Pe trimis: `jtva_ti` e `0` pe toate randurile, niciodata NULL.
+- Testul aritmetic direct pe cazul sintetic din handoff (`jc2007.id_fact=8007136`,
+  `an=2022 luna=4 dataact=30-APR-22 nract=222 id_part=614`): `totctva=119`, `jtva_ti_expr=19` —
+  exact valorile asteptate (confirma ca `diferenta` ar deveni `100-(119-19)=0`).
+- Sonda `user_tab_columns` gaseste `JTVA_TI` pe ambele view-uri de test — confirma ca tehnica
+  folosita in `import_efactura.prg` functioneaza identic pe view ca pe tabela.
+
+NU am rulat `create or replace view` pe view-urile reale si nu am atins `jc2007`/`jv2007`.
+
+## Ce ramane de facut de om
+
+- Aplicarea scriptului pe schema clientului, INAINTE de deploy-ul exe-ului (ordinea ceruta de plan).
+- Verificarea finala pe o factura REALA de taxare inversa importata din eFactura — schema dev nu are
+  niciuna (confirmat deja in `handoff_transa2_conditii.md`); mecanismul e demonstrat doar numeric.
+- Review + aprobare `docs\diff_runda1_transa2.patch` inainte de orice commit (SVN sau git).
+- Curatenie dupa aprobare: `import_efactura.prg.pre_runda1.bak` si patch-ul se sterg (nu se comit).
+
+## Fisiere
+
+- Backup: `D:\ROA\ROACONT\COMUN\programe\import_efactura.prg.pre_runda1.bak`
+- Patch: `D:\ROA\ROACONT\docs\diff_runda1_transa2.patch`
+- Script nou: `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\07\ff_2026_07_28_01_COMUN_EFACTURA.sql`
+- `D:\ROA\ROACONT\versiune_db.txt`: `2026_07_28_01`

docs/plan-anaf-tva-efactura-4-lucrari.md

@@ -488,7 +488,14 @@ una absenta, pentru ca nimeni nu afla ca nu mai merge. Esecul nu blocheaza salva
   **inchide aplicatia**, in mijlocul salvarii. Exact opusul cerintei.
 - Deci apelul TREBUIE facut cu reconectarea dezactivata explicit. **Nu exista precedent**: din 150+
   apeluri `oExecute`/`oExecuta` din codebase, niciunul nu trece de 2 parametri. Tiparul se scrie
-  aici prima oara — de verificat pozitia exacta a parametrului in semnatura inainte de a-l folosi.
+  aici prima oara.
+- Semnatura confirmata (`oproceduri_comune.prg:169`):
+  `oExecute(tcSql, tcCursor, tlProgress, tcTitluProgress, tnHandle, tlShowError, tlQuitOnError, tlReconnect)`.
+  `tlReconnect` e al **8-lea** parametru si are **implicit `.T.`** (comentariul din cod, `:175`),
+  deci trebuie pasat `.F.` EXPLICIT — altfel se obtine exact dialogul cu `QUIT`.
+  Atentie la parametrii 3-7 care trebuie completati ca sa se ajunga la al 8-lea: pentru fiecare, ia
+  din cod valoarea pe care codul o considera implicita cand parametrul lipseste, ca sa nu schimbi
+  din greseala alt comportament (in special `tnHandle` si `tlQuitOnError`).
 - Se foloseste `oExecute`, NU `oExecuta` (aceasta din urma afiseaza mesaj propriu, neconditionat, pe
   orice esec). Nu se adauga niciun `amessagebox` propriu.
 - Nu exista niciun timeout Oracle configurat (`SQLSETPROP QueryTimeout`/`ConnectTimeout`) nicaieri:
@@ -516,7 +523,10 @@ inexecutabila in doua feluri: captionul difera intre cele doua clase (`:2643` vs
 `Command5.Enabled` se calculeaza dupa **randul curent** (`:5661-5667`, `:13850`) si `cmdSelect.Click`
 nu il recalculeaza — deci butonul poate fi gri exact dupa "Selecteaza tot".
 
-`<N>` — de fixat inainte de implementare daca numara facturi distincte sau linii din `tact`.
+`<N>` — **FIXAT 28.07.2026, marius.mutu: facturi DISTINCTE**, nu linii din `tact`. Actiunea pe care o
+propune butonul e per factura, nu per linie: trei plati partiale pe aceeasi factura sunt o singura
+factura de exigibilizat, si asa trebuie numarate. Textul dialogului se ajusteaza corespunzator
+("Exista <N> facturi cu TVA la incasare pentru care nu s-a adaugat nota de TVA exigibilizat").
 
 **Pasul 5 — flag anti-bucla.**