romfast/roacont
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8b5a670ff1514be79f71316befa3de1c451980f7
roacont/docs/handoff_transa2.md
Marius Mutu 8b5a670ff1 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
2026-07-28 08:23:40 +03:00

3.2 KiB
Raw Blame History

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