Marius Mutu
8b5a670ff1
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
52 lines
3.2 KiB
Markdown
52 lines
3.2 KiB
Markdown
# 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`
|