# 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`