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

changelog_roacont.txt

@@ -1,3 +1,11 @@
+<!--
+28/07/2026
+ROACONT - 2.11.68
+
+:modificare:
+  Borderou eFactura, facturi primite. Facturile cu taxare inversa nu mai apar colorate ca avand diferenta fata de contabilitate. In eFactura taxarea inversa are TVA zero, dar in contabilitate se inregistreaza 4426 = 4427, iar diferenta afisata tine cont acum de acest TVA. Necesita actualizarea bazei de date.
+-->
+
 <!--
 28/07/2026
 ROACONT - 2.11.67

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.**
 

versiune_db.txt

@@ -1 +1 @@
-2026_07_26_02
+2026_07_28_01