romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync SVN r18026

Browse Source
This commit is contained in:
Marius Mutu
2026-08-20 22:44:52 +03:00
parent ca3c5d7eea
commit 5b52cb3999
9 changed files with 1481 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

218
docs/brief_r6_punct6_vfp.md Normal file
View File

@@ -0,0 +1,218 @@
# Brief de implementare — runda 6, punctul 6, partea VFP
Explicatia TVA in dialogul de modificare a articolului din `frm_facturi`. Proiectarea completa:
`docs\propunere_runda6_punct6_plsql.md`, sectiunea "Ce ramane de facut in VFP". Acest brief e
executabil: contine liniile exacte, valorile exacte si ce s-a verificat deja.
## Interdictii (citeste-le inainte de orice)
- **NU rula `git_sync.ps1`, `roa_sync.bat`, `svn update`, `svn commit`, `git commit`, `git push`.**
- **NU atinge alt fisier** in afara de `COMUN\clase\ofacturare_comun.vc2` (+ binarul lui prin
write-back) si `docs\raport_r6_punct6_vfp.md` (raportul tau).
- **NU modifica PL/SQL** — pachetul e deja aplicat pe `MARIUSM_AUTO` si verificat.
- **NU schimba `Text1.ReadOnly` nicaieri**, nu atinge grid-ul de articole, nu atinge `omodificari.vc2`.
- Esti **singurul scriitor** pe `ofacturare_comun.vc2`. Daca gasesti modificari necomise pe el la
start, opreste-te si raporteaza.
## Starea de plecare
- `svn`/`git` curate, r18025. Textele `.??2` sunt la zi (git_sync: 0 convertite, 463 la zi).
- Oracle: `MARIUSM_AUTO.PACK_FACTURARE` are deja semnatura noua, verificata pe sursa vie:
```
PROCEDURE modifica_explicatie_articol(V_ID_VANZARE_DET IN NUMBER,
V_EXPLICATIE IN VARCHAR2,
V_ID_UTIL IN NUMBER,
V_TAXCODE IN NUMBER DEFAULT NULL,
V_ID_JTVA_COLOANA IN NUMBER DEFAULT NULL);
```
Al 5-lea parametru lipsa/NULL => ramura veche (se scriu doar `EXPLICATIE` si `TAXCODE`).
## Fapte verificate pe cod — nu le re-investiga
1. `crsDetalii` (`oproceduri_facturare.prg:382-400`) are: `id_vanzare`, `id_vanzare_det`,
`proc_tvav`, `id_jtva_coloana`, `jtva_coloana`, `taxcode`, `taxname`, `sters`, `explicatie`.
**Nu are `data_act` si nu are `id_part`.**
2. `crsfacturi` (`oproceduri_facturare.prg:339-360`) are `data_act`, `id_part`, `id_vanzare`.
Randul curent din `crsfacturi` **este** antetul liniei editate: `crsDetalii` se filtreaza pe
`id_vanzare=` al randului curent din `crsfacturi` (`ofacturare_comun.vc2:3621-3623`).
3. `proc_tvav` e **multiplicator** (1.19), `cota_tva` din `vjtva_coloane` e **procent** (19).
Cota liniei = `Round((Nvl(poRec.proc_tvav,0) - 1) * 100, 2)`.
4. Filtrul de explicatii e cel din `caut_explicatie_tva` (`ocautare.prg:3193, 3220`):
`id_jtva_coloana > 0` + `cota_tva = <cota>`, pe view-ul `vjtva_coloane`.
**Nu** folosi `update_jtva_coloane` — acela adauga restrictii pe `afisat` si pe `cote_tva` de
an/luna curenta, care nu sunt in proiectarea aprobata.
5. `GetTaxCodeIdPart` (`oproceduri_comune.prg:6059-6125`) e apelabila din `frm_facturi`, isi
gestioneaza singura cursorul `jtva_coloane`, si **returneaza `.NULL.` daca `gl406` e `.F.`**
(`:6086-6088`) — de aceea apelul se face doar sub garda `gl406`, altfel ar sterge `taxcode`-ul.
6. `tlNeexigibil` = `.F.` (parametru **omis**). Confirmat, nu presupus: calea de emitere a
facturii foloseste `GetTaxCode(gnAn, gnLuna, ldDataAct, lnIdJtva, .F.)` cu ultimii trei
parametri impliciti (`ofacturare.vc2:2529` si `:3101`), iar pe jurnal de vanzari (`jv`)
`GetTaxCodeIdPart` degenereaza exact in acel apel (ramura `llJC` e `.F.`, `:6098-6110`).
Deci butonul produce acelasi `taxcode` pe care l-ar produce emiterea.
7. `n50`/`n100` = `.F.` (parametri omisi), ca in `ointroduceri.vc2:11488`.
## Modificarile — fisier `COMUN\clase\ofacturare_comun.vc2`
Ruleaza intai `vfp_symbols.ps1 -Where` ca sa confirmi domeniul fiecarei metode inainte sa editezi;
numerele de linie de mai jos sunt de la starea r18025 si se pot deplasa dupa prima editare.
### M1 — `frm_facturi.do_modifica_explicatie` (~`:4642-4659`)
Dupa `Scatter Name poRec Memo` si inainte de `If poRec.sters = 0`, ataseaza antetul pe `poRec`
(vezi faptul 1 si 2 — campurile nu exista pe `crsDetalii`):
```foxpro
AddProperty(poRec, 'data_act', crsfacturi.data_act)
AddProperty(poRec, 'id_part', Nvl(crsfacturi.id_part, 0))
```
Restul metodei ramane neschimbat (`update_saft_taxtable()` ramane unde e).
### M2 — layout `frm_modifica_articol_factura` (~`:5131`)
Randul existent cu `cbo_saft` coboara, iar deasupra lui intra randul nou de explicatie TVA.
Valori exacte:
| obiect | proprietate | din | in |
|---|---|---|---|
| `frm_modifica_articol_factura` | `Height` | 370 | **431** |
| `_shape3` | `Top` | 323 | **384** |
| `cbo_saft` | `Top` | 329 | **390** |
| `lbSaft` | `Top` | 332 | **393** |
Obiecte noi (toate in `*<PropValue>` / `ADD OBJECT`, plus linii `*< OBJECTDATA ... >` in blocul de
ZOrder de la inceputul clasei):
- `_shape4` AS `_shape` OF `_baza.vcx` — `BackStyle=0, Left=13, Top=323, Height=58, Width=348`
- `lbExplTva` AS `_label` OF `_baza.vcx` — `Caption="Explicatie TVA", Left=24, Top=332`
(diacriticele: vezi sectiunea de encoding mai jos; textul afisat corect e `Explicație TVA`)
- `cbo_expl_tva` AS `_cbbase` OF `_cb_base.vcx` — modelat dupa `cbo_saft`:
`BoundColumn=3, BoundTo=.T., ColumnCount=2, ColumnWidths="400,60", Height=24, Left=110,`
`Top=329, Width=238, RowSourceType=3`.
**`ControlSource` ramane gol** (nu legam direct de `poRec.id_jtva_coloana` — valoarea aleasa se
preia in `InteractiveChange`, ca sa putem distinge "userul a atins combo-ul" de "n-a atins").
`RowSource` se construieste in `Init` (vezi M3), nu se scrie in `ADD OBJECT`.
- `lbExplTvaInfo` AS `_label` OF `_baza.vcx` — `Caption="", Left=24, Top=355, Width=324,`
`Height=20, WordWrap=.T., ForeColor=RGB(128,0,0), Visible=.F.`
Proprietate noua de formular: `nidjtvaales`.
**Obligatoriu si intrarea `*p: nidjtvaales` in `*<DefinedPropArrayMethod>`, nu doar valoarea in
`*<PropValue>`** — fara `*p:` valoarea trece fidelity-check-ul, ajunge in binar, dar VFP nu
materializeaza proprietatea si orice acces cade cu eroarea 1734. Valoare initiala: `nidjtvaales = 0`.
### M3 — `frm_modifica_articol_factura.Init`
La finalul metodei `Init` existente (dupa blocul care citeste `citeste_lungcampexplart`), adauga
popularea combo-ului. Comportamentul cerut de proiectare, in trei ramuri:
```foxpro
Local lnCota, lcSqlTva, lcCursorTva
Thisform.nidjtvaales = 0
If Isnull(poRec.proc_tvav) Or Nvl(poRec.proc_tvav, 0) = 0
Thisform.cbo_expl_tva.Enabled = .F.
Thisform.lbExplTvaInfo.Caption = [Cota de TVA a acestei linii nu este cunoscuta; explicatia TVA nu poate fi modificata prin acest buton.]
Thisform.lbExplTvaInfo.Visible = .T.
Return
Endif
lnCota = Round((poRec.proc_tvav - 1) * 100, 2)
lcCursorTva = [crsExplTvaArt]
lcSqlTva = [select id_jtva_coloana, denumire, cota_tva from vjtva_coloane where id_jtva_coloana > 0 ] + ;
[and cota_tva = ] + Alltrim(Str(lnCota, 10, 2)) + [ order by denumire]
If goExecutor.oExecuta(lcSqlTva, lcCursorTva) And Reccount(lcCursorTva) > 0
Thisform.cbo_expl_tva.RowSource = [select denumire, cota_tva, id_jtva_coloana from ] + lcCursorTva + [ into cursor crsExplTvaCbo]
Thisform.cbo_expl_tva.Requery()
Thisform.cbo_expl_tva.Value = Nvl(poRec.id_jtva_coloana, 0)
Else
Thisform.cbo_expl_tva.Enabled = .F.
Thisform.lbExplTvaInfo.Caption = [Nu exista nicio explicatie TVA activa cu aceeasi cota ca linia facturata (cota: ] + ;
Alltrim(Str(lnCota, 10, 2)) + [ %).]
Thisform.lbExplTvaInfo.Visible = .T.
Endif
```
Note de implementare, nu le sari:
- `Alltrim(Str(lnCota,10,2))` produce `19.00`; comparatia cu `cota_tva` (NUMBER(10,0)) e corecta
in Oracle. Nu formata cu virgula.
- daca `Init` are `Return` propriu / `NODEFAULT`, verifica sa nu scurtcircuitezi codul existent.
- inchide cursorul `crsExplTvaArt` in `Destroy` daca ramane deschis (`If Used(...) : Use In ...`).
- textul mesajelor **fara diacritice** (asa sunt scrise si celelalte mesaje din aceasta clasa,
ex. `:4635`) — evita complet problema de encoding pe siruri noi.
### M4 — `cbo_expl_tva.InteractiveChange` (metoda noua)
```foxpro
PROCEDURE cbo_expl_tva.InteractiveChange
Local lnIdJtva
lnIdJtva = Nvl(This.Value, 0)
If lnIdJtva <= 0
Return
Endif
Thisform.nidjtvaales = lnIdJtva
poRec.id_jtva_coloana = lnIdJtva
If Type('gl406') = 'L' And m.gl406
poRec.taxcode = GetTaxCodeIdPart(m.gnAn, m.gnLuna, poRec.data_act, m.lnIdJtva, poRec.id_part)
Thisform.cbo_saft.Refresh()
Endif
ENDPROC
```
### M5 — `inainte_de_do_termin` (~`:5227-5235`)
Al 5-lea parametru pozitional, **literal, nu bind** — ca sa poata fi `null` curat cand userul n-a
atins combo-ul (atunci procedura ramane pe ramura veche):
```foxpro
Local lcParamJtva
lcParamJtva = Iif(Vartype(Thisform.nidjtvaales) = 'N' And Thisform.nidjtvaales > 0, ;
Alltrim(Str(Thisform.nidjtvaales)), [null])
lcSql = [begin pack_facturare.modifica_explicatie_articol(] + Alltrim(Str(poRec.id_vanzare_det)) + [,] + ;
['] + Nvl(Alltrim(OracleSpecialCharacters(poRec.explicatie)),'') + [',?gnIdUtil,?poRec.taxcode,] + lcParamJtva + [); end;]
llReturn = goExecutor.oExecuta(lcSql)
```
Restul metodei (confirmarea `amessagebox`, `Return llReturn`) ramane neschimbat. Erorile
`FACT-026..029` ies deja vizibil prin `goExecutor.oExecuta` — nu adauga cod de afisare.
### M6 — refresh dupa salvare
**Nimic de facut.** `Thisform.actualizeaza_grid2()` din `do_modifica_explicatie` (`:4654`) e
suficient: headerul nu se schimba, totalurile nu se recalculeaza.
## Encoding — capcana platita deja
Fisierele `.vc2` din acest arbore au diacriticele in **cp1250, nu cp1252**. Tool-ul `Edit` le
transforma in U+FFFD si strica textul din alte proprietati.
- **numara octetii > 0x7F inainte si dupa fiecare editare** — trebuie sa iasa acelasi numar;
- daca s-au stricat, repara cu encoding `28591`;
- pentru sirurile **noi** pe care le scrii tu: **fara diacritice**, deci problema nu apare de la
tine — dar poate aparea de la o rescriere a fisierului.
## Write-back si verificare
1. `txt2vcx.ps1 ... -AllowComun` — se ruleaza **direct, fara aprobare** (regula lui Marius).
2. Fidelity-check: FoxBin2Prg **nu pastreaza ordinea textuala** pentru `ADD OBJECT` multiple si
proprietati custom, si sorteaza cu `_` **dupa** litere. Daca primul write-back da FAIL pe
ordine: **adopta ca sursa textul regenerat din `<staging>\verify\*.vc2`**, nu incerca sa
ghicesti ordinea corecta.
3. **`mtime` nu dovedeste sincronizarea text/binar** — `txt2vcx.ps1` rescrie mtime-ul textului.
Dovada ceruta: reconverteste binarul intr-un cache temporar si fa `diff` cu textul din arbore;
raporteaza numarul de linii diferenta (trebuie 0).
## Ce raportezi
Scrie **pe disc**, la `D:\ROA\ROAFACTURARE\docs\raport_r6_punct6_vfp.md`, si raspunde in chat doar
cu `GATA` + calea. In raport:
- inventarul modificarilor cu `fisier:linie` (dupa write-back, deci pe numerotarea finala);
- confirmarea explicita ca write-back-ul e facut si **numarul de linii diferenta** la reconversie;
- numarul de octeti > 0x7F inainte si dupa;
- ce n-ai putut face si de ce;
- **nu comite nimic**; nu rula sincronizari.
Daca te apropii de ~200-250k tokens de context, opreste-te la o stare consistenta pe disc, scrie
raportul cu ce ai facut si ce ramane, si anunta — nu continua.

139
docs/brief_r7_sincronizare.md Normal file
View File

@@ -0,0 +1,139 @@
# Brief de implementare — runda 7: sincronizarea articole-rulaje
Doua cereri ale lui Marius, 20.08.2026 (dupa proba pe ecran a rundei 6):
1. sincronizarea sa porneasca **doar din buton**, nu sa se mai arate la terminarea editarii;
2. la directia **ARTICOLE_SURSA** (articole -> rulaj) se copiaza `pretvtva`, dar **nu** si `pretv`
si `tvav`, care raman vechi.
## Interdictii (citeste-le inainte de orice)
- **NU rula `git_sync.ps1`, `roa_sync.bat`, `svn update`, `svn commit`, `svn revert`, `git commit`,
`git push`, `git stash`, `git checkout`.**
- **NU atinge `COMUN\clase\ofacturare_comun.vc2`** — are o livrare separata, verificata, necomisa.
Orice scriere acolo distruge munca altcuiva.
- **NU atinge PL/SQL**, nu te conecta la Oracle pentru scriere.
- Fisierele tale, singurele: `COMUN\clase\omodificari.vc2` (+ binarul prin write-back),
`COMUN\programe\ofacturare_editare.prg`, si raportul `docs\raport_r7_sincronizare.md`.
- Esti singurul scriitor pe ele. Daca gasesti alte modificari necomise acolo, opreste-te si raporteaza.
## M1 — sincronizarea porneste doar din buton
`COMUN\clase\omodificari.vc2`, metoda `inainte_de_do_termin` a clasei `frm_modific2024`,
blocul de la **`:14484-14494`** (numerele se deplaseaza dupa prima editare — confirma cu
`vfp_symbols.ps1 -Where`):
```foxpro
*!* al doilea punct de declansare al sincronizarii: enumerarea diferentelor la salvare, cu
*!* continuarea salvarii daca utilizatorul renunta - de aceea llRet nu se schimba aici;
*!* pe document fara linii active nu porneste: propunerea ar marca toata sursa ca "Adaugare"
IF m.llRet AND This.lAreArticoleVanzari AND !This.lArticoleReadOnly AND Used('tvd') AND m.lnLiniiActive > 0
LOCAL lcSemnaturaAcum
lcSemnaturaAcum = This.SemnaturaDivergenteSincronizare()
*!* doar divergentele aparute in sesiunea curenta deschid dialogul; N-A nu intra in semnatura
IF !Empty(m.lcSemnaturaAcum) AND !(m.lcSemnaturaAcum == This.cSemnaturaSincronizare)
This.AfiseazaDialogSincronizareArticole()
ENDIF
ENDIF
```
**Se sterge integral, cu tot cu cele patru linii de comentariu.** `RETURN m.llRet` de dupa ramane.
Nu atinge butonul `pgfArticole.PAGE3.cmdSincronizeazaArticole.Click` (`:16671`) — el ramane singura
cale de pornire.
**Nu sterge** metoda `SemnaturaDivergenteSincronizare`, proprietatea `cSemnaturaSincronizare` si
atribuirea ei de la `:14956`. Dupa aceasta stergere raman fara consumator — **semnaleaza asta in
raport**, ca decizia de curatare sa fie a lui Marius, dar nu o lua tu.
## M2 — `pretv` si `tvav` se recalculeaza la scrierea in rulaj
`COMUN\programe\ofacturare_editare.prg`, `FUNCTION AplicaModificareTrul` (**`:924`**). Azi:
```foxpro
lcCampCant = IIF(Nvl(cant,0) <> 0, 'cant', 'cante')
REPLACE (m.lcCampCant) WITH m.tnCantitateNoua, pretvtva WITH m.tnPretNouCuTva IN trul
```
Formula corecta **exista deja** si e sursa de adevar — nu inventa alta: `omodificari.vc2`,
`calculeaza_valori_rul`, ramura `pretvtva` (**`:13566-13587`**):
```foxpro
lnProcTvav = IIF(EMPTY(proc_tvav), 1, proc_tvav) - 1 && 1.19 -> 0.19
lnTVAv = ROUND(lnPretVtva * lnProcTVAv / (1 + lnProcTvav), gnPPretv)
lnPretv = lnPretvtva - lnTvav
lnValoarecTVA = ROUND(lnCantitate * lnPretvTva, gnPC)
lnValoareTVA = ROUND(lnValoarecTVA * lnProcTVAv / (1 + lnProcTvav), gnPC)
lnValoareFTva = lnValoareCtva - lnValoareTVA
REPLACE pretv, pretvtva, tvav, valoarev, valtvav, valoarevcTVA
```
Atentie la precizii, sunt **doua diferite**: `pretv`/`tvav`/`pretvtva` se rotunjesc la **`gnPPretV`**
(precizia pretului de **vanzare**), iar `valoarev`/`valtvav`/`valoarevcTVA` la **`gnPC`**.
**Nu** apela `toForm.calculeaza_valori_rul()` in locul calculului: metoda alege cursorul din
`This.pgfArticole.ActivePage` (`:13532-13533`) — `trul` doar cand pagina activa e 1. Sincronizarea
porneste de pe pagina 3, deci ar nimeri `trul_obinv`. Calculeaza in `AplicaModificareTrul`, unde
esti deja pozitionat pe randul corect din `trul`.
Ordinea conteaza: cantitatea se scrie **inainte** de a citi `cant`/`cante` pentru valori, altfel
valorile ies pe cantitatea veche.
**Include si `valoarev`, `valtvav`, `valoarevcTVA`.** Marius a numit doar `pretv` si `tvav`, dar
sincronizarea schimba si cantitatea, iar cele trei valori depind de `cantitate x pretvtva`; lasate
nescrise raman la fel de vechi ca `pretv`. E semnalat lui ca depasire fata de cerere.
Actualizeaza si comentariul-antet al lui `AplicaSincronizareArticole` (`:787-794`), care azi spune
*"ARTICOLE_SURSA scrie doar cant/pretvtva pe randul RUL deja existent"* — a devenit fals.
## Teste — obligatoriu, nu optional
Exista suite care acopera exact zona atinsa:
- `COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg` (42 cazuri; **sectiunea C** e chiar
`AplicaSincronizareArticole` pe directia `ARTICOLE_SURSA`, care scrie in `trul`)
- `COMUN\utile\Teste\editare_factura\test_s4b_dialog.prg` (35 cazuri)
Ruleaza-le pe amandoua **dupa** modificari. Reguli platite deja, respecta-le:
- **sterge `.fxp`-ul** inainte de fiecare rulare, altfel se executa bytecode vechi;
- **o singura suita per apel** de comanda — doua rulari inlantuite in acelasi apel atarna;
- cifra se ia **numarand liniile `PASS`/`FAIL` din log**, iar dovada ca rularea a ajuns la capat e
**linia de `REZULTAT`**; fara ea rularea a fost taiata, indiferent ce zice orice raport.
(Linia de `REZULTAT` contine ea insasi cuvintele `PASS` si `FAIL` — un `Select-String` naiv
raporteaza cu unu mai mult din fiecare.)
Daca sectiunea C pica **pentru ca astepta vechiul comportament** (doar `cant`/`pretvtva`), asta e
asertiune invechita, nu regresie: actualizeaz-o si spune explicit in raport ce ai schimbat si de ce.
Daca pica altceva, **nu modifica testul** — raporteaza.
Detalii de mediu si capcane: `COMUN\docs\depanare_testare_vfp.md`, `COMUN\docs\testare-ui-vfp.md`.
## Encoding si write-back (doar pentru `.vc2`)
- `.vc2` e **CRLF pe toate liniile** si are diacriticele in **cp1250**. Numara octetii >0x7F inainte
si dupa; trebuie acelasi numar, si zero `EF BF BD`. `.prg` se editeaza normal.
- Dupa editarea `.vc2`: `txt2vcx.ps1` **imediat** (se ruleaza direct, fara aprobare):
```
powershell -ExecutionPolicy Bypass -File D:\ROA\UTIL\foxbin2prg\txt2vcx.ps1 `
-TextFile 'D:\ROA\ROAFACTURARE\COMUN\clase\omodificari.vc2' `
-ProjectRoot 'D:\ROA\ROAFACTURARE' -CacheRoot 'D:\ROA\ROAFACTURARE' -AllowComun
```
- daca fidelity-check-ul pica pe ordine, adopta textul din `<staging>\verify\`;
- **dovada de sincronizare**: reconverteste binarul intr-un cache temporar cu `vcx2txt.ps1 -Source
... -CacheRoot <temp> -Force` si fa `diff` cu textul din arbore -> **0 linii diferenta**.
`mtime` nu dovedeste nimic.
- **Inainte de write-back verifica sa nu ruleze `vfp9.exe`** (`Get-Process vfp9`) — tine binarul
blocat. Daca ruleaza, **nu-l omori**: opreste-te si anunta-ma.
## Ce raportezi
Scrie **pe disc**, la `D:\ROA\ROAFACTURARE\docs\raport_r7_sincronizare.md`, si raspunde in chat doar
cu `GATA <cale>`. In raport: inventarul cu `fisier:linie` pe numerotarea finala; confirmarea
write-back-ului cu numarul de linii diferenta la reconversie; octetii >0x7F inainte/dupa; cifrele de
test luate din log (`PASS`/`FAIL` + prezenta liniei `REZULTAT`), pe fiecare suita; ce asertiuni ai
schimbat si de ce; ce n-ai putut face.
Daca te apropii de ~200-250k tokens de context, opreste-te la o stare consistenta pe disc
(write-back facut), scrie raportul cu ce ramane, si anunta.

327
docs/diff_r6_punct6.md Normal file
View File

@@ -0,0 +1,327 @@
# Diff pentru aprobare — runda 6, punctul 6 (partea VFP) + changelog
Stare verificata inainte de livrare:
- write-back facut; text din arbore vs. text reconvertit din binar: **0 linii diferenta**, md5 identic
- octetul diacritic din `lbExplTva.Caption`, citit **din binar**: `0xFE` (cp1250, ca restul clasei)
- 13 octeti >0x7F, zero `EF BF BD`, CRLF pe toate liniile
- `PACK_FACTURARE` cu semnatura noua era deja aplicat pe `MARIUSM_AUTO` / `ROA_CENTRAL`
- proba pe ecran facuta de Marius; a rezultat o corectie de filtru (mai jos)
## Filtrul listei de explicatii TVA — verificat pe date
Prima versiune filtra doar `id_jtva_coloana > 0` + cota liniei, si arata si liniile de TVA.
Interogare read-only pe `vjtva_coloane` (`MARIUSM_AUTO`), 197 de randuri cu `id > 0`:
| `afisat` | ce sunt randurile | exemplu |
|---|---|---|
| 0 | **liniile de TVA** | `TVA LIVR. INTERN 19%` |
| 1 | **bazele** cu cota | `LIVR. INTERN 19%` |
| 2 | neimpozabile/scutite (cota 0) | `LIVR. SCUTITE FARA DREPT DE DEDUCERE` |
Filtrul devine `afisat > 0 and jv = 1`, acelasi pe care il foloseste emiterea facturii
(`ofacturare.prg:170`, `update_jtva_coloane([JV], ...)` cu `tnTip` gol).
`jv = 1` nu a fost cerut explicit, dar fara el o factura de **vanzare** primea si explicatii de
**achizitie** (`ACH. INT. 19% BUNURI VANZARE` are cota 19, deci garda `FACT-029` din PL/SQL le-ar
fi acceptat). Numarul de optiuni ramase per cota, pe datele din `MARIUSM_AUTO`:
```
cota: 0 5 9 11 19 20 21 24
tot: 24 16 36 22 40 18 22 19
afisat>0: 24 9 19 9 21 10 12 11
+ jv=1: 15 3 3 3 3 3 3 3
```
Nicio cota nu ramane cu lista goala, deci ramura "lista goala" ramane teoretica, ca la proiectare.
Restrictia pe `cote_tva` de an/luna curenta pe care o adauga `update_jtva_coloane` **nu** a fost
preluata intentionat: ar goli lista la editarea unei facturi vechi cu cota iesita din uz (24%).
## 1. `COMUN\clase\ofacturare_comun.vc2` (repo COMUN, se comite ca `.vcx` + `.vct`)
```diff
diff --git a/clase/ofacturare_comun.vc2 b/clase/ofacturare_comun.vc2
index 6f7f325..367fd89 100644
--- a/clase/ofacturare_comun.vc2
+++ b/clase/ofacturare_comun.vc2
@@ -4647,6 +4647,8 @@ DEFINE CLASS frm_facturi AS _frmbase OF "_frm_base.vcx"
Select crsDetalii
Scatter Name poRec Memo
poRec.explicatie = NVL(poRec.explicatie, ' ')
+ AddProperty(poRec, 'data_act', crsfacturi.data_act)
+ AddProperty(poRec, 'id_part', Nvl(crsfacturi.id_part, 0))
If poRec.sters = 0
ofrmmodificare = Createobject("frm_modifica_articol_factura")
ofrmmodificare.Show()
@@ -5135,9 +5137,14 @@ DEFINE CLASS frm_modifica_articol_factura AS frm_termin_renunt OF "_frm_child.vc
*< OBJECTDATA: ObjPath="Ed_tx_simplu1" UniqueID="" Timestamp="" />
*< OBJECTDATA: ObjPath="cbo_saft" UniqueID="" Timestamp="" />
*< OBJECTDATA: ObjPath="lbSaft" UniqueID="" Timestamp="" />
+ *< OBJECTDATA: ObjPath="_shape4" UniqueID="" Timestamp="" />
+ *< OBJECTDATA: ObjPath="lbExplTva" UniqueID="" Timestamp="" />
+ *< OBJECTDATA: ObjPath="cbo_expl_tva" UniqueID="" Timestamp="" />
+ *< OBJECTDATA: ObjPath="lbExplTvaInfo" UniqueID="" Timestamp="" />
*<DefinedPropArrayMethod>
*p: nid
+ *p: nidjtvaales
*p: ntip_selectie && 0 - cautare in toti delegatii; 1 - cautare in delegatii clientului
*p: orec
*</DefinedPropArrayMethod>
@@ -5145,9 +5152,10 @@ DEFINE CLASS frm_modifica_articol_factura AS frm_termin_renunt OF "_frm_child.vc
*<PropValue>
BorderStyle = 1
DoCreate = .T.
- Height = 370
+ Height = 431
Name = "frm_modifica_articol_factura"
nid = .F.
+ nidjtvaales = 0
ntip_selectie = 0
orec = .F.
Width = 376
@@ -5161,17 +5169,17 @@ DEFINE CLASS frm_modifica_articol_factura AS frm_termin_renunt OF "_frm_child.vc
_shape2.ZOrderSet = 2
Lb_titlu_alb_b121.Caption = "Modific<69> explica<63>ie articol"
Lb_titlu_alb_b121.Name = "Lb_titlu_alb_b121"
- Lb_titlu_alb_b121.TabIndex = 5
+ Lb_titlu_alb_b121.TabIndex = 6
Lb_titlu_alb_b121.ZOrderSet = 3
BUT_TERMIN1.Left = 344
BUT_TERMIN1.Name = "BUT_TERMIN1"
- BUT_TERMIN1.TabIndex = 3
+ BUT_TERMIN1.TabIndex = 4
BUT_TERMIN1.Top = 1
BUT_TERMIN1.ZOrderSet = 4
Gridsort1.Name = "Gridsort1"
But_renunt1.Left = 315
But_renunt1.Name = "But_renunt1"
- But_renunt1.TabIndex = 4
+ But_renunt1.TabIndex = 5
But_renunt1.Top = 1
But_renunt1.ZOrderSet = 6
*</PropValue>
@@ -5181,11 +5189,36 @@ DEFINE CLASS frm_modifica_articol_factura AS frm_termin_renunt OF "_frm_child.vc
Height = 37, ;
Left = 13, ;
Name = "_shape3", ;
- Top = 323, ;
+ Top = 384, ;
Width = 348, ;
ZOrderSet = 0
*< END OBJECT: ClassLib="_baza.vcx" BaseClass="shape" />
+ ADD OBJECT '_shape4' AS _shape WITH ;
+ BackStyle = 0, ;
+ Height = 58, ;
+ Left = 13, ;
+ Name = "_shape4", ;
+ Top = 323, ;
+ Width = 348, ;
+ ZOrderSet = 10
+ *< END OBJECT: ClassLib="_baza.vcx" BaseClass="shape" />
+
+ ADD OBJECT 'cbo_expl_tva' AS _cbbase WITH ;
+ BoundColumn = 3, ;
+ BoundTo = .T., ;
+ ColumnCount = 2, ;
+ ColumnWidths = "400,60", ;
+ Height = 24, ;
+ Left = 110, ;
+ Name = "cbo_expl_tva", ;
+ RowSourceType = 3, ;
+ TabIndex = 2, ;
+ Top = 329, ;
+ Width = 238, ;
+ ZOrderSet = 12
+ *< END OBJECT: ClassLib="_cb_base.vcx" BaseClass="combobox" />
+
ADD OBJECT 'cbo_saft' AS _cbbase WITH ;
BoundColumn = 4, ;
BoundTo = .T., ;
@@ -5197,8 +5230,8 @@ DEFINE CLASS frm_modifica_articol_factura AS frm_termin_renunt OF "_frm_child.vc
Name = "cbo_saft", ;
RowSource = "Select taxname, tip, procent_taxa, taxcode From saft_taxtable where tva = 1 order by taxcode Into Cursor crsTaxTableX", ;
RowSourceType = 3, ;
- TabIndex = 2, ;
- Top = 329, ;
+ TabIndex = 3, ;
+ Top = 390, ;
Width = 266, ;
ZOrderSet = 8
*< END OBJECT: ClassLib="_cb_base.vcx" BaseClass="combobox" />
@@ -5221,20 +5254,54 @@ DEFINE CLASS frm_modifica_articol_factura AS frm_termin_renunt OF "_frm_child.vc
_lbbase1.Name = "_lbbase1"
*< END OBJECT: ClassLib="lb_tx.vcx" BaseClass="container" />
+ ADD OBJECT 'lbExplTva' AS _label WITH ;
+ Caption = "Explica<63>ie TVA", ;
+ Left = 24, ;
+ Name = "lbExplTva", ;
+ TabIndex = 8, ;
+ Top = 332, ;
+ ZOrderSet = 11
+ *< END OBJECT: ClassLib="_baza.vcx" BaseClass="label" />
+
+ ADD OBJECT 'lbExplTvaInfo' AS _label WITH ;
+ Caption = "", ;
+ ForeColor = RGB(128,0,0), ;
+ Height = 20, ;
+ Left = 24, ;
+ Name = "lbExplTvaInfo", ;
+ Top = 355, ;
+ Visible = .F., ;
+ Width = 324, ;
+ WordWrap = .T., ;
+ ZOrderSet = 13
+ *< END OBJECT: ClassLib="_baza.vcx" BaseClass="label" />
+
ADD OBJECT 'lbSaft' AS _label WITH ;
Caption = "Cod taxa", ;
Left = 24, ;
Name = "lbSaft", ;
- TabIndex = 6, ;
- Top = 332, ;
+ TabIndex = 7, ;
+ Top = 393, ;
ZOrderSet = 9
*< END OBJECT: ClassLib="_baza.vcx" BaseClass="label" />
+ PROCEDURE Destroy
+ If Used('crsExplTvaCbo')
+ Use In crsExplTvaCbo
+ Endif
+ If Used('crsExplTvaArt')
+ Use In crsExplTvaArt
+ Endif
+ DoDefault()
+ ENDPROC
+
PROCEDURE inainte_de_do_termin
- Local llReturn
+ Local llReturn, lcParamJtva
If amessagebox("Doriti sa salvati modificarile?",4+32,"Confirmare salvare explicatie") = 6
+ lcParamJtva = Iif(Vartype(Thisform.nidjtvaales) = 'N' And Thisform.nidjtvaales > 0, ;
+ Alltrim(Str(Thisform.nidjtvaales)), [null])
lcSql = [begin pack_facturare.modifica_explicatie_articol(] + Alltrim(Str(poRec.id_vanzare_det)) + [,] + ;
- ['] + Nvl(Alltrim(OracleSpecialCharacters(poRec.explicatie)),'') + [',?gnIdUtil,?poRec.taxcode); end;]
+ ['] + Nvl(Alltrim(OracleSpecialCharacters(poRec.explicatie)),'') + [',?gnIdUtil,?poRec.taxcode,] + lcParamJtva + [); end;]
llReturn = goExecutor.oExecuta(lcSql)
Else
llReturn = .F.
@@ -5258,6 +5325,46 @@ DEFINE CLASS frm_modifica_articol_factura AS frm_termin_renunt OF "_frm_child.vc
Endwith
Endif
+ Local lnCota, lcSqlTva, lcCursorTva
+ Thisform.nidjtvaales = 0
+
+ If Isnull(poRec.proc_tvav) Or Nvl(poRec.proc_tvav, 0) = 0
+ Thisform.cbo_expl_tva.Enabled = .F.
+ Thisform.lbExplTvaInfo.Caption = [Cota de TVA a acestei linii nu este cunoscuta; explicatia TVA nu poate fi modificata prin acest buton.]
+ Thisform.lbExplTvaInfo.Visible = .T.
+ Return
+ Endif
+
+ lnCota = Round((poRec.proc_tvav - 1) * 100, 2)
+ lcCursorTva = [crsExplTvaArt]
+ *!* afisat > 0 = doar bazele, fara liniile de TVA; jv = 1 = doar jurnalul de vanzari
+ lcSqlTva = [select id_jtva_coloana, denumire, cota_tva from vjtva_coloane where id_jtva_coloana > 0 ] + ;
+ [and afisat > 0 and jv = 1 and cota_tva = ] + Alltrim(Str(lnCota, 10, 2)) + [ order by denumire]
+ If goExecutor.oExecuta(lcSqlTva, lcCursorTva) And Reccount(lcCursorTva) > 0
+ Thisform.cbo_expl_tva.RowSource = [select denumire, cota_tva, id_jtva_coloana from ] + lcCursorTva + [ into cursor crsExplTvaCbo]
+ Thisform.cbo_expl_tva.Requery()
+ Thisform.cbo_expl_tva.Value = Nvl(poRec.id_jtva_coloana, 0)
+ Else
+ Thisform.cbo_expl_tva.Enabled = .F.
+ Thisform.lbExplTvaInfo.Caption = [Nu exista nicio explicatie TVA activa cu aceeasi cota ca linia facturata (cota: ] + ;
+ Alltrim(Str(lnCota, 10, 2)) + [ %).]
+ Thisform.lbExplTvaInfo.Visible = .T.
+ Endif
+
+ ENDPROC
+
+ PROCEDURE cbo_expl_tva.InteractiveChange
+ Local lnIdJtva
+ lnIdJtva = Nvl(This.Value, 0)
+ If lnIdJtva <= 0
+ Return
+ Endif
+ Thisform.nidjtvaales = lnIdJtva
+ poRec.id_jtva_coloana = lnIdJtva
+ If Type('gl406') = 'L' And m.gl406
+ poRec.taxcode = GetTaxCodeIdPart(m.gnAn, m.gnLuna, poRec.data_act, m.lnIdJtva, poRec.id_part)
+ Thisform.cbo_saft.Refresh()
+ Endif
ENDPROC
ENDDEFINE
```
## 2. `changelog_roafacturare.txt` (repo ROAFACTURARE)
```diff
diff --git a/changelog_roafacturare.txt b/changelog_roafacturare.txt
index ed81ecb..6c0733f 100644
--- a/changelog_roafacturare.txt
+++ b/changelog_roafacturare.txt
@@ -1,5 +1,5 @@
<!--
-19/08/2026
+20/08/2026
ROAFACTURARE - 2.11.15
:nou:
@@ -7,11 +7,19 @@ ROAFACTURARE - 2.11.15
Pe linia de articol se poate alege explicatia TVA. Lista propune doar explicatiile cu cota TVA a liniei, iar codul de taxa SAF-T se completeaza automat dupa explicatia aleasa.
+ Lista de facturi, butonul de modificare a explicatiei articolului: se poate alege acum si explicatia TVA. Lista propune doar explicatiile cu aceeasi cota de TVA ca linia facturii, iar codul de taxa SAF-T se completeaza automat dupa explicatia aleasa. Valorile facturii raman neschimbate - nu se recalculeaza cota si nici totalurile documentului.
+
:modificare:
Totalul notelor din bara de jos se actualizeaza imediat dupa modificarea sumei de pe randul de nota, nu doar la editarea articolelor.
Fereastra de sincronizare articole - rulaje: coloanele arata acum ce valoare se inlocuieste si de unde se preia cea noua, in loc de "vechi" si "nou" explicate separat.
+ Editare factura, pagina Articole: seria, lotul si explicatia se tasteaza direct in grid, iar articolul, gestiunea, valuta, explicatia TVA si codul de taxa SAF-T se aleg prin dublu clic pe celula. Culorile arata la ce foloseste fiecare coloana: alb - se tasteaza direct, verde - se alege dintr-o lista, gri - nu se poate edita.
+
+ Editare factura, pagina Articole: pretul si pretul cu TVA se afiseaza cu numarul de zecimale stabilit pentru preturile de vanzare, nu cu cel pentru preturile de achizitie.
+
+ Optiunea de meniu prin care se deschide editarea se numeste acum "Editare factura (note, rulaje, articole)".
+
:eroare:
S-a corectat o eroare la descarcarea articolelor importate din eFactura, care aveau pret de achizitie cu 4 zecimale.
```
## 3. `docs\progres.md` (repo ROAFACTURARE)
```diff
diff --git a/docs/progres.md b/docs/progres.md
index 52c419d..f1805d9 100644
--- a/docs/progres.md
+++ b/docs/progres.md
@@ -2309,5 +2309,20 @@ initial, apoi **respinsa** — nu se reintroduce.
- `ff_2026_08_20_01` (garda `FACT-025`, runda 5) e **deja aplicat** pe `MARIUSM_AUTO`; scriptul 02 il
contine. **Nu se re-aplica 01** — ar sterge punctul 6.
-Ramase: proba pe ecran a punctelor 1-5, aplicarea scriptului pe `MARIUSM_AUTO`, partea VFP a
-punctului 6, si intrarea de changelog pentru runda 6 (nu exista inca).
+Ramase: partea VFP a punctului 6 si intrarea de changelog pentru runda 6 (nu exista inca).
+
+**Corectie 20.08.2026, seara** — doua puncte din lista de mai sus erau deja facute:
+
+- **Proba pe ecran a punctelor 1-5**: facuta de Marius.
+- **Scriptul `ff_2026_08_20_02_COMUN_PACK_FACTURARE.sql` era deja aplicat** pe schema
+ `MARIUSM_AUTO` de pe `ROA_CENTRAL`, contrar notei de mai sus ("NERULAT"). Dovezi, nu mtime:
+ `VERSIUNE` are randul `20.08.2026 / seq 2 / COMUN_PACK_FACTURARE`; `ALL_OBJECTS` da PACKAGE si
+ PACKAGE BODY **VALID**, `last_ddl_time` 20.08.2026 13:56:38; iar sursa vie din `ALL_SOURCE`
+ (spec + body, normalizata: fara `CREATE OR REPLACE`, fara `/`, fara antetul de comentariu si
+ fara `exec`/`commit`) e **identica cu fisierul de pe disc — 0 linii diferenta pe 16 407**.
+ Deci in Oracle sta varianta **finala** (fara recalcul), nu varianta respinsa, desi fisierul are
+ mtime 15:45, ulterior compilarii de la 13:56.
+ Concluzie de metoda: mtime-ul fisierului si nota "scriptul nu a fost rulat" din raportul de
+ livrare nu sunt surse de stare pentru ce e in Oracle. Starea se citeste din `VERSIUNE` +
+ `ALL_SOURCE`, prin diff, inainte de a re-aplica ceva.
+- Ramane valabila interdictia: **nu se re-aplica `ff_2026_08_20_01`** — ar sterge punctul 6.
```

250
docs/diff_r6_r7_pentru_commit.md Normal file
View File

@@ -0,0 +1,250 @@
# Diff pentru aprobare — commit unic: runda 6 (punctul 6) + runda 7 (sincronizare)
Marius a cerut **un singur commit, dupa ce sunt gata toate trei lucrarile**. Toate trei sunt gata.
Acest fisier e inventarul complet al commit-ului. Rationamentul detaliat al punctului 6 (filtrul
listei de explicatii TVA, cu cifrele pe date) ramane in `docs\diff_r6_punct6.md` — nu se repeta aici.
Raportul rundei 7, inclusiv raspunsul la intrebarea de fapt, e in `docs\raport_r7_sincronizare.md`.
## Stare verificata inainte de livrare
| fisier | write-back | dovada |
|---|---|---|
| `COMUN\clase\ofacturare_comun.vc2` | facut, binar 19:59 | reconversie + diff **0 linii**, md5 identic |
| `COMUN\clase\omodificari.vc2` | facut, binar 22:20 | reconversie + diff **0 linii**, md5 `d23691466b7017380fe36099943b3208` |
| `COMUN\programe\ofacturare_editare.prg` | n/a (`.prg`) | ASCII curat, CRLF |
| `COMUN\utile\Teste\...\test_s4b_sincronizare.prg` | n/a (`.prg`) | ASCII curat, LF (ca originalul) |
Teste: `test_s4b_sincronizare` **44 PASS / 0 FAIL**, `test_s4b_dialog` **35 PASS / 0 FAIL**,
zero erori in loguri. O suita per apel, `.fxp` sters inainte de fiecare rulare.
Punctul 6 a fost probat pe ecran de Marius, de doua ori.
## Rezumat pe fisiere
Repo `COMUN`:
```
clase/ofacturare_comun.vc2 | 129 +++++++++++++++++++--
clase/omodificari.vc2 | 11 --
programe/ofacturare_editare.prg | 21 +++-
.../editare_factura/test_s4b_sincronizare.prg | 20 +++-
4 files changed, 152 insertions(+), 29 deletions(-)
```
Repo `ROAFACTURARE`:
```
M changelog_roafacturare.txt (2 randuri noi in :modificare:, blocul 2.11.15)
M docs/progres.md
?? docs/raport_r7_sincronizare.md, docs/brief_r7_sincronizare.md, docs/handoff_r6_r7_sincronizare.md,
docs/brief_r6_punct6_vfp.md, docs/raport_r6_punct6_vfp.md, docs/diff_r6_punct6.md (doar git)
```
## 1. `COMUN\clase\omodificari.vc2` — M1: sincronizarea porneste doar din buton
Se comite ca `.vcx` + `.vct`, niciodata `.vc2`.
```diff
@@ -14481,17 +14481,6 @@ DEFINE CLASS frm_modific2024 AS _frmbase OF "_frm_base.vcx"
ENDIF
SELECT (m.lnAreaTvd)
ENDIF
- *!* al doilea punct de declansare al sincronizarii: enumerarea diferentelor la salvare, cu
- *!* continuarea salvarii daca utilizatorul renunta - de aceea llRet nu se schimba aici;
- *!* pe document fara linii active nu porneste: propunerea ar marca toata sursa ca "Adaugare"
- IF m.llRet AND This.lAreArticoleVanzari AND !This.lArticoleReadOnly AND Used('tvd') AND m.lnLiniiActive > 0
- LOCAL lcSemnaturaAcum
- lcSemnaturaAcum = This.SemnaturaDivergenteSincronizare()
- *!* doar divergentele aparute in sesiunea curenta deschid dialogul; N-A nu intra in semnatura
- IF !Empty(m.lcSemnaturaAcum) AND !(m.lcSemnaturaAcum == This.cSemnaturaSincronizare)
- This.AfiseazaDialogSincronizareArticole()
- ENDIF
- ENDIF
RETURN m.llRet
```
## 2. `COMUN\programe\ofacturare_editare.prg` — M2: `pretv` si `tvav` in rulaj
```diff
@@ -789,8 +789,9 @@ ENDFUNC && ConstruiestePropunereSincronizare
*!* Modificare/Adaugare pe tvd nu se aplica, doar cele pe trul, care nu au nevoie de metode de formular)
*!* reconstruieste propunerea (ConstruiestePropunereSincronizare) si aplica tot ce nu e N-A/Semnalare,
*!* DOAR in cursoarele din memorie (tvd/trul) - niciun INSERT/UPDATE Oracle; RUL_SURSA scrie in tvd
-*!* (cantitate/pret, pastrand pret_cu_tva existent pe rand), ARTICOLE_SURSA scrie doar cant/pretvtva pe
-*!* randul RUL deja existent (niciodata rand RUL nou - lipsesc contul/gestiunea sigure din articol)
+*!* (cantitate/pret, pastrand pret_cu_tva existent pe rand), ARTICOLE_SURSA scrie cant/pretvtva si
+*!* recalculeaza pretv/tvav pe randul RUL deja existent (niciodata rand RUL nou - lipsesc contul/
+*!* gestiunea sigure din articol)
*!* retur numeric: cate linii au fost efectiv aplicate (ca apelantul sa poata reface bara de totaluri)
FUNCTION AplicaSincronizareArticole
LPARAMETERS tcDirectie, toForm
@@ -919,12 +920,15 @@ ENDFUNC && AplicaAdaugareTvd
*!* parametri: id_articol, cantitate/pret noi (pret_nou cu TVA)
*!* scrie in trul (singurul rand activ gasit pe articol - garantat unic, altfel propunerea a marcat N-A)
-*!* doar cant/cante (dupa care din ele era deja folosit pe rand) si pretvtva; nu atinge id_tip_rulaj,
-*!* conturi (scd/scc) sau alte campuri derivate (valoare/tva/etc.) - raman de recalculat de apelant daca e nevoie
+*!* cant/cante (dupa care din ele era deja folosit pe rand), apoi recalculeaza pretv/tvav/pretvtva cu
+*!* formula din calculeaza_valori_rul (ramura pretvtva); nu atinge valorile (valoarev/valtvav/
+*!* valoarevcTVA), id_tip_rulaj, conturi (scd/scc) sau valoare/tva (pretul de achizitie) - raman de
+*!* recalculat de apelant daca e nevoie
FUNCTION AplicaModificareTrul
LPARAMETERS tnIdArticol, tnCantitateNoua, tnPretNouCuTva
LOCAL lnAreaOrigine, llAplicat, lcCampCant
+ LOCAL lnPretvtva, lnProcTvav, lnTvav, lnPretv
lnAreaOrigine = Select()
llAplicat = .F.
@@ -933,7 +937,14 @@ FUNCTION AplicaModificareTrul
LOCATE FOR id_articol = m.tnIdArticol AND Nvl(sters,0) <> 1
IF Found()
lcCampCant = IIF(Nvl(cant,0) <> 0, 'cant', 'cante')
- REPLACE (m.lcCampCant) WITH m.tnCantitateNoua, pretvtva WITH m.tnPretNouCuTva IN trul
+ REPLACE (m.lcCampCant) WITH m.tnCantitateNoua IN trul
+
+ lnPretvtva = ROUND(m.tnPretNouCuTva, m.gnPPretv)
+ lnProcTvav = IIF(Empty(proc_tvav), 1, proc_tvav) - 1 && 1.19 -> 0.19
+ lnTvav = ROUND(m.lnPretvtva * m.lnProcTvav / (1 + m.lnProcTvav), m.gnPPretv)
+ lnPretv = m.lnPretvtva - m.lnTvav
+
+ REPLACE pretv WITH m.lnPretv, pretvtva WITH m.lnPretvtva, tvav WITH m.lnTvav IN trul
llAplicat = .T.
ENDIF
ENDIF
```
## 3. `COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg` — fixture + acoperire
Cursorul `trul` din test nu avea `pretv`/`tvav`, iar harness-ul nu definea `gnPPretV`; fara ele
codul nou dadea eroare in test, nu in productie. Cazul C1 1600 adauga TVA 19% real, ca defalcarea
sa fie efectiv verificata (toate cazurile existente aveau `proc_tvav = 1`, deci `tvav` iesea 0).
```diff
@@ -38,6 +38,11 @@ IF Type('gnPC') <> 'N'
gnPC = 2
ENDIF
+IF Type('gnPPretV') <> 'N'
+ PUBLIC gnPPretV
+ gnPPretV = 4
+ENDIF
+
SET PROCEDURE TO D:\ROA\ROAFACTURARE\COMUN\programe\ofacturare_editare.prg ADDITIVE
@@ -348,22 +353,32 @@ AdaugaTvd(1400, 5, 12, 1, 1, 'ARTICOL 1400', 'COD1400', 60)
AdaugaTrul(1400, 0, 3, 9, 0, 1, '371', 1)
*!* 1500: adaugare in ARTICOLE_SURSA (doar in tvd) - nu se aplica niciodata, trul nu primeste rand nou
AdaugaTvd(1500, 1, 1, 1, 1, 'ARTICOL 1500', 'COD1500', 1)
+*!* 1600: modificare cu TVA 19% - defalcarea pretvtva -> pretv/tvav (238/2 = 119 -> 100 + 19)
+AdaugaTvd(1600, 2, 119, 1, 1, 'ARTICOL 1600', 'COD1600', 238)
+AdaugaTrul(1600, 1, 0, 100, 0, 1, '371', 1.19)
LOCAL lnReccountTrulInainte, lnAplicateC1
lnReccountTrulInainte = Reccount('trul')
lnAplicateC1 = AplicaSincronizareArticole('ARTICOLE_SURSA')
-DO asserteaza WITH 'C1 ARTICOLE_SURSA: 2 linii aplicate (modificarile 1300 si 1400; adaugarea 1500 sarita)', lnAplicateC1 == 2, TRANSFORM(lnAplicateC1)
+DO asserteaza WITH 'C1 ARTICOLE_SURSA: 3 linii aplicate (modificarile 1300, 1400 si 1600; adaugarea 1500 sarita)', lnAplicateC1 == 3, TRANSFORM(lnAplicateC1)
DO asserteaza WITH 'C1: trul nu a crescut (adaugarea 1500 nu creeaza rand RUL nou)', Reccount('trul') == m.lnReccountTrulInainte, TRANSFORM(Reccount('trul'))
SELECT trul
LOCATE FOR id_articol = 1300
DO asserteaza WITH 'C1 1300: cant (campul folosit initial) actualizat la 5, pretvtva la 12, id_tip_rulaj neatins', ;
Found() AND cant == 5 AND cante == 0 AND pretvtva == 12 AND id_tip_rulaj == 0, TRANSFORM(cant) + '/' + TRANSFORM(cante)
+DO asserteaza WITH 'C1 1300: pretv/tvav recalculate (proc_tvav = 1, deci TVA 0 si pretv = pretvtva)', ;
+ pretv == 12 AND tvav == 0, TRANSFORM(pretv) + '/' + TRANSFORM(tvav)
LOCATE FOR id_articol = 1400
DO asserteaza WITH 'C1 1400: cante (campul folosit initial) actualizat la 5, cant ramane 0', ;
Found() AND cante == 5 AND cant == 0 AND pretvtva == 12, TRANSFORM(cant) + '/' + TRANSFORM(cante)
+LOCATE FOR id_articol = 1600
+DO asserteaza WITH 'C1 1600: pretvtva 119 defalcat in pretv 100 + tvav 19, cant actualizat la 2', ;
+ Found() AND cant == 2 AND pretvtva == 119 AND pretv == 100 AND tvav == 19, ;
+ TRANSFORM(pretv) + '/' + TRANSFORM(tvav) + '/' + TRANSFORM(cant)
+
STRTOFILE('REZULTAT: ' + TRANSFORM(gnPass) + ' PASS / ' + TRANSFORM(gnFail) + ' FAIL' + CHR(13) + CHR(10), lcLog, 1)
@@ -395,7 +410,8 @@ PROCEDURE CreeazaTrulTest
Use In trul
ENDIF
CREATE CURSOR trul (id_articol N(20), denumire C(100), codmat C(30), um C(10), cant N(12,3), cante N(12,3), ;
- pretvtva N(14,4), id_tip_rulaj I, sters I, id_gestiune I, cont C(20), proc_tvav N(6,4))
+ pretv N(14,4), pretvtva N(14,4), tvav N(14,4), id_tip_rulaj I, sters I, id_gestiune I, cont C(20), ;
+ proc_tvav N(6,4))
ENDPROC
```
## 4. `changelog_roafacturare.txt`
```diff
@@ -1,5 +1,5 @@
<!--
-19/08/2026
+20/08/2026
ROAFACTURARE - 2.11.15
:nou:
@@ -7,11 +7,23 @@ ROAFACTURARE - 2.11.15
Pe linia de articol se poate alege explicatia TVA. Lista propune doar explicatiile cu cota TVA a liniei, iar codul de taxa SAF-T se completeaza automat dupa explicatia aleasa.
+ Lista de facturi, butonul de modificare a explicatiei articolului: se poate alege acum si explicatia TVA. Lista propune doar explicatiile cu aceeasi cota de TVA ca linia facturii, iar codul de taxa SAF-T se completeaza automat dupa explicatia aleasa. Valorile facturii raman neschimbate - nu se recalculeaza cota si nici totalurile documentului.
+
:modificare:
Totalul notelor din bara de jos se actualizeaza imediat dupa modificarea sumei de pe randul de nota, nu doar la editarea articolelor.
Fereastra de sincronizare articole - rulaje: coloanele arata acum ce valoare se inlocuieste si de unde se preia cea noua, in loc de "vechi" si "nou" explicate separat.
+ Sincronizarea articole - rulaje porneste doar din butonul de pe pagina Articole. Nu mai apare automat la salvarea notei.
+
+ Sincronizarea articole - rulaje completeaza pe randul de rulaj si pretul fara TVA, si TVA-ul unitar - pana acum se actualizau doar cantitatea si pretul cu TVA.
+
+ Editare factura, pagina Articole: seria, lotul si explicatia se tasteaza direct in grid, iar articolul, gestiunea, valuta, explicatia TVA si codul de taxa SAF-T se aleg prin dublu clic pe celula. Culorile arata la ce foloseste fiecare coloana: alb - se tasteaza direct, verde - se alege dintr-o lista, gri - nu se poate edita.
+
+ Editare factura, pagina Articole: pretul si pretul cu TVA se afiseaza cu numarul de zecimale stabilit pentru preturile de vanzare, nu cu cel pentru preturile de achizitie.
+
+ Optiunea de meniu prin care se deschide editarea se numeste acum "Editare factura (note, rulaje, articole)".
+
:eroare:
S-a corectat o eroare la descarcarea articolelor importate din eFactura, care aveau pret de achizitie cu 4 zecimale.
```
## 5. `COMUN\clase\ofacturare_comun.vc2` — punctul 6
Neschimbat fata de livrarea precedenta, deja aprobata la proba pe ecran. Diff-ul integral si
rationamentul filtrului: `docs\diff_r6_punct6.md`, sectiunile "Filtrul listei de explicatii TVA"
si "1. `COMUN\clase\ofacturare_comun.vc2`".
## Ce se comite, in ordine
SVN (sursa de adevar), **tintit** — pe binare, niciodata pe `.vc2`/`.sc2`:
- `COMUN\clase\ofacturare_comun.vcx` + `.vct`
- `COMUN\clase\omodificari.vcx` + `.vct`
- `COMUN\programe\ofacturare_editare.prg`
- `COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg`
- `changelog_roafacturare.txt`
- `docs\progres.md`
**Nu se comit**: `roafacturare.PJT` / `.PJX` / `.exe` — apar modificate in `svn status`, dar vin din
sesiunea de VFP a lui Marius, nu din aceasta lucrare.
Imediat dupa `svn commit` -> `roa_sync.bat`, apoi se raporteaza revizia SVN si ce a intrat pe `main`.
Fisierele noi din `docs\` sunt doar in git.
## Ce NU s-a facut, intentionat
- **`valoarev`/`valtvav`/`valoarevcTVA` nu se scriu la sincronizare** — perimetru respins explicit
de Marius. Consecinta e documentata ca defect in `docs\raport_r7_sincronizare.md`: `VALOAREV` si
`VALTVAV` ajung invechite in Oracle, `VALOAREVCTVA` nu e coloana in `RUL` si ramane invechit doar
pe ecran pana la reincarcarea notei. **Decizia de reparare e a lui Marius.**
- `SemnaturaDivergenteSincronizare` si `cSemnaturaSincronizare` au ramas fara consumator dupa M1.
Semnalate, **nesterse**, conform deciziei.

220
docs/handoff_r6_r7_sincronizare.md Normal file
View File

@@ -0,0 +1,220 @@
# Handoff — runda 6 (punctul 6) + runda 7 (sincronizare articole-rulaje)
Scris 20.08.2026, seara. Sesiunea principala a trecut de pragul de context. **Numai stare, fara
analize noi.**
## Stare periculoasa — citeste asta prima
- **Nimic nu e comis.** Nici SVN, nici git, nici in `COMUN`. Marius a decis explicit: **un singur
commit, dupa ce sunt gata toate trei lucrarile** (punctul 6 + cele doua cereri de runda 7).
Punctul 6 e gata si probat, dar asteapta.
- `COMUN\clase\omodificari.vc2` si `COMUN\programe\ofacturare_editare.prg` erau, la scrierea acestui
fisier, **in lucru la subagentul `r7-sincronizare`**. Verifica pe disc `mtime` + `git status` in
`COMUN` inainte sa presupui ceva; nu porni un al doilea scriitor pe ele.
- `roafacturare.PJT` / `.PJX` / `.exe` apar modificate in `svn status`. **Nu sunt ale noastre** — vin
din sesiunea de VFP a lui Marius. Decizia lui: **se lasa asa**, nu se comit, nu se reverteaza.
## 1. Punctul 6 — TERMINAT, verificat, necomis
Explicatia TVA in dialogul de modificare a articolului deschis din `frm_facturi`.
**Cod, pe numerotarea finala** (`COMUN\clase\ofacturare_comun.vc2`):
| ce | unde |
|---|---|
| `data_act` + `id_part` puse pe `poRec` din antetul `crsfacturi` | `frm_facturi.do_modifica_explicatie`, `:4650-4651` |
| layout: `Height` 370->431, randul `cbo_saft` coborat, obiecte noi `_shape4` / `lbExplTva` / `cbo_expl_tva` / `lbExplTvaInfo` | `frm_modifica_articol_factura`, `:5140-5300` |
| proprietatea `nidjtvaales` (+ intrarea `*p:`, obligatorie) | `:5147`, `:5158` |
| popularea combo-ului, filtrata | `Init`, `:5328-5360` |
| filtrul SQL | `:5340-5342` |
| derivarea `taxcode` | `cbo_expl_tva.InteractiveChange` |
| al 5-lea parametru pozitional, literal `null` cand combo-ul n-a fost atins | `inainte_de_do_termin` |
| `Destroy` inchide `crsExplTvaCbo` + `crsExplTvaArt` | in aceeasi clasa |
**Write-back FACUT si dovedit** (nu prin `mtime`): reconversie binar -> text intr-un cache temporar,
`diff` **0 linii**, md5 identic. Binar la 19:59. Encoding: **13** octeti >0x7F, zero `EF BF BD`,
CRLF pe toate liniile; octetul diacritic din `lbExplTva.Caption` e **`0xFE`** (cp1250), verificat
citind din binar.
**Probat pe ecran de Marius, de doua ori** (a doua oara dupa corectia de filtru). E OK.
### Ce s-a stabilit — nu se redeschide
- **Filtrul listei**: `id_jtva_coloana > 0 AND afisat > 0 AND jv = 1 AND cota_tva = <cota liniei>`.
Verificat pe date in `vjtva_coloane` (`MARIUSM_AUTO`, 197 randuri cu `id > 0`): `afisat = 0` sunt
**liniile de TVA**, `afisat = 1` **bazele** cu cota, `afisat = 2` neimpozabilele. `jv = 1` tine
afara explicatiile de achizitie, care altfel treceau de garda `FACT-029` (au aceeasi cota).
Acelasi filtru pe care il foloseste emiterea (`ofacturare.prg:170`).
- **NU** se preia si restrictia pe `cote_tva` de an/luna curenta din `update_jtva_coloane`: ar goli
lista la editarea unei facturi vechi cu cota iesita din uz (24%).
- **`neexigibil` = `.F.`** (parametru omis), la fel `n50`/`n100`. Nu e presupunere: emiterea
foloseste `GetTaxCode(gnAn, gnLuna, ldDataAct, lnIdJtva, .F.)` cu ultimii trei impliciti
(`ofacturare.vc2:2529` si `:3101`), iar pe jurnal de vanzari `GetTaxCodeIdPart` degenereaza exact
in acel apel.
- `crsDetalii` **nu are** `data_act`/`id_part`; vin din randul curent din `crsfacturi`, care e chiar
antetul liniei editate (`ofacturare_comun.vc2:3621-3623`).
- Combo-ul **nu** are `ControlSource` — valoarea se preia in `InteractiveChange`, ca sa se poata
distinge "userul a atins combo-ul" de "nu l-a atins" (al doilea caz trimite `null` si lasa
procedura PL/SQL pe ramura veche).
- Ordinea de tab: `Ed_tx_simplu1`=1, `cbo_expl_tva`=2, `cbo_saft`=3, `BUT_TERMIN1`=4,
`But_renunt1`=5, `Lb_titlu_alb_b121`=6, `lbSaft`=7, `lbExplTva`=8.
### Oracle — nimic de facut
`ff_2026_08_20_02_COMUN_PACK_FACTURARE.sql` **era deja aplicat** pe schema `MARIUSM_AUTO` de pe
`ROA_CENTRAL`, contrar notei "NERULAT" din rapoartele vechi. Dovezi: rand `20.08.2026 / seq 2 /
COMUN_PACK_FACTURARE` in `VERSIUNE`; PACKAGE + PACKAGE BODY **VALID**, `last_ddl_time` 13:56:38;
sursa vie din `ALL_SOURCE` identica cu fisierul de pe disc, **0 linii diferenta pe 16 407**.
**Nu se re-aplica `ff_2026_08_20_01`** — ar sterge punctul 6.
## 2bis. ACTUALIZARE 20.08.2026 20:40 - starea reala pe disc, dupa oprirea subagentului
Sesiunea subagentului `r7-sincronizare` a fost inchisa din greseala, **inainte sa scrie raport**.
`docs\raport_r7_sincronizare.md` **nu exista**. Starea de mai jos e citita direct de pe disc,
nu dintr-un raport.
### STARE PERICULOASA: text editat FARA write-back
| fisier | text | binar | concluzie |
|---|---|---|---|
| `COMUN\clase\omodificari.vc2` | **20:35** | `.vcx`/`.vct` la **14:08** | **modificarea NU exista in binar, deci nu exista in aplicatie** |
| `COMUN\programe\ofacturare_editare.prg` | 20:33 | - | `.prg`, nu are nevoie de write-back |
| `COMUN\clase\ofacturare_comun.vc2` | 19:59 | 19:59, diff 0 linii | punctul 6, sincronizat si verificat |
`vfp9.exe` **nu ruleaza** - lock-ul e liber, write-back-ul se poate face oricand.
### M1 - facut pe text, corect
Blocul "al doilea punct de declansare" a disparut din `frm_modific2024.inainte_de_do_termin`
(0 potriviri pe comentariu). `AfiseazaDialogSincronizareArticole()` mai are **un singur**
apelant, `omodificari.vc2:16665`, adica butonul. Corect. **Ramane de facut write-back-ul.**
### M2 - facut pe text, dar DEPASESTE perimetrul aprobat
`AplicaModificareTrul` (`ofacturare_editare.prg`) calculeaza si scrie acum:
`pretv`, `pretvtva`, `tvav` (cerute) **plus `valoarev`, `valtvav`, `valoarevcTVA`** - pe care
**Marius le-a respins explicit**: sincronizarea e intre cantitate si preturi, nu valori.
Subagentul a apucat sa aplice varianta initiala a brief-ului; corectia de perimetru nu a mai
ajuns la el.
**De facut in sesiunea urmatoare, in aceasta ordine:**
1. Scoate din `AplicaModificareTrul` cele trei campuri de valoare din `REPLACE` si cele trei
linii care le calculeaza (`lnValoarecTVA`, `lnValoareTVA`, `lnValoareFtva`), plus
`lnCantitate` daca ramane nefolosit. Raman `pretv`, `pretvtva`, `tvav`.
Verifica si `LOCAL`-urile declarate, si comentariul-antet al lui `AplicaSincronizareArticole`.
2. Write-back pe `omodificari.vc2` (`txt2vcx.ps1 -TextFile ... -AllowComun`), apoi **dovada prin
reconversie** cu `vcx2txt.ps1` intr-un cache temporar si `diff` - trebuie 0 linii.
3. Ruleaza cele doua suite (vezi mai jos), o suita per apel, cu `.fxp` sters inainte.
4. Raspunde la intrebarea de fapt ramasa deschisa (cine recalculeaza
`valoarev`/`valtvav`/`valoarevcTVA` dupa sincronizare) - **doar raspuns, fara reparatie**.
5. Adauga cele doua puncte in changelog, regenereaza `docs\diff_r6_punct6.md` si cere aprobarea
de commit.
Nimic nu a fost testat: **cele doua suite nu au fost rulate**.
## 2. Runda 7 — IN LUCRU la subagentul `r7-sincronizare`
Brief executabil, cu liniile si formula: `docs\brief_r7_sincronizare.md`.
Raportul lui va fi la `docs\raport_r7_sincronizare.md`.
**M1** — sincronizarea articole-rulaje porneste **doar din buton**. Se sterge blocul "al doilea
punct de declansare" din `frm_modific2024.inainte_de_do_termin`, `omodificari.vc2:14484-14494`.
Butonul `pgfArticole.PAGE3.cmdSincronizeazaArticole.Click` (`:16671`) ramane singura cale.
Dupa stergere raman **fara consumator** metoda `SemnaturaDivergenteSincronizare` (`:14840`),
proprietatea `cSemnaturaSincronizare` si atribuirea de la `:14956` — se semnaleaza, **nu** se sterg.
**M2** — `AplicaModificareTrul` (`ofacturare_editare.prg:924`) scrie azi doar `cant`/`cante` si
`pretvtva`; trebuie sa scrie **si `pretv`, si `tvav`**.
- **Perimetru corectat de Marius**: **DOAR `pretv` si `tvav`.** Versiunea initiala a brief-ului
cerea si `valoarev`/`valtvav`/`valoarevcTVA` — **respinsa**: sincronizarea e intre cantitate si
preturi, nu valori. Nu o reintroduce.
- **Intrebare de fapt inca deschisa**, ceruta subagentului, fara modificare de cod: cine recalculeaza
`valoarev`/`valtvav`/`valoarevcTVA` pe randul `trul` dupa sincronizare, inainte de scrierea in
Oracle? Trei concluzii posibile — le recalculeaza cineva / le recalculeaza salvarea / nu le
recalculeaza nimeni si ajung vechi in Oracle. In ultimul caz **se raporteaza ca defect, nu se
repara**; decide Marius.
- Formula canonica, **de reutilizat, nu de reinventat**: `omodificari.vc2`, `calculeaza_valori_rul`,
ramura `pretvtva`, `:13566-13587`. Doua precizii diferite: `gnPPretV` pentru preturi, `gnPC` pentru
valori.
- `calculeaza_valori_rul` **nu se poate apela direct** din sincronizare: isi alege cursorul din
`This.pgfArticole.ActivePage` (`:13532-13533`) si nimereste `trul` doar cand pagina activa e 1;
sincronizarea porneste de pe pagina 3, deci ar scrie in `trul_obinv`.
### Teste obligatorii pentru runda 7
`COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg` (42 cazuri, **sectiunea C** e chiar
directia `ARTICOLE_SURSA`) si `test_s4b_dialog.prg` (35 cazuri). Reguli: sterge `.fxp`-ul inainte de
fiecare rulare; **o singura suita per apel** de comanda; cifra se ia numarand `PASS`/`FAIL` din log,
iar dovada ca rularea a ajuns la capat e **linia de `REZULTAT`** (care contine ea insasi cuvintele
`PASS` si `FAIL` — un `Select-String` naiv raporteaza cu unu mai mult din fiecare).
## 3. Changelog
`changelog_roafacturare.txt` — intrarea rundei 6 e **scrisa**, in blocul existent **2.11.15**, data
mutata la 20/08/2026. Versiunea **nu se bifurca** cat timp #6 nu e in productie (decizia lui Marius,
commit `09f9d47`).
**Ramas de adaugat**, dupa ce runda 7 e gata: sincronizarea porneste doar din buton, si copierea
`pretv`/`tvav` in rulaj.
## 4. Ce se comite, cand vine aprobarea
SVN (sursa de adevar), **tintit** — pe binare, niciodata pe `.vc2`/`.sc2`:
- `COMUN\clase\ofacturare_comun.vcx` + `.vct`
- `COMUN\clase\omodificari.vcx` + `.vct` (dupa runda 7)
- `COMUN\programe\ofacturare_editare.prg` (dupa runda 7)
- `changelog_roafacturare.txt`
- `docs\progres.md`
**Nu**: `roafacturare.PJT` / `.PJX` / `.exe`. Imediat dupa `svn commit` -> `roa_sync.bat`, si se
raporteaza revizia SVN si ce a intrat pe `main`. Fisierele noi din `docs\` sunt doar in git.
Diff-ul pentru aprobare, deja generat pentru punctul 6: `docs\diff_r6_punct6.md` (contine si
rationamentul filtrului, cu cifrele pe date). **Trebuie regenerat** dupa ce intra runda 7.
## 5. Capcane de mediu platite in aceasta sesiune
- **`python <<EOF` si `python -c "..."` nu executa nimic** prin tool-ul Bash de pe masina asta —
exit 0, zero efect, fara eroare. Scrie scriptul intr-un fisier si ruleaza-l pe cale absoluta.
Pentru `.vc2` foloseste **mod binar** (`'rb'`/`'wb'`): e CRLF peste tot si cp1250 pe diacritice.
- **`txt2vcx.ps1` are parametrul `-TextFile`, nu `-Source`** (`vcx2txt.ps1` are `-Source`). Ambele au
nevoie de `-ProjectRoot` si `-CacheRoot` date explicit pentru acest proiect.
- **Write-back-ul esueaza cat timp ruleaza `vfp9.exe`** — tine `.vcx/.vct` exclusiv. Se verifica cu
`Get-Process vfp9` **inainte**. Procesul e al lui Marius: **nu se omoara**, se cere inchiderea.
- **Un subagent poate raporta `idle` si apoi sa scrie in fisier.** S-a intamplat; era sa produca doi
scriitori pe aceeasi metoda. Verifica `mtime`/md5 pe disc inainte sa preiei un fisier, si spune-le
explicit sa nu raporteze idle cu lucru in curs.
- `svn status` cere `--depth` sau atentie la externals: `COMUN` apare ca `X` (external), iar starea
lui se vede separat.
---
## ACTUALIZARE FINALA 20.08.2026 22:40 — toate cele trei lucrari sunt gata
Pasii 1-5 din lista de mai sus sunt **executati**. Handoff-ul de mai sus ramane ca istoric; starea
curenta e cea de aici.
1. **Perimetrul M2 corectat** — `valoarev`/`valtvav`/`valoarevcTVA` scoase din `AplicaModificareTrul`,
impreuna cu `lnValoarecTVA`/`lnValoareTVA`/`lnValoareFtva`/`lnCantitate` si cu `LOCAL`-urile si
comentariile-antet ale ambelor functii. Raman `pretv`, `pretvtva`, `tvav`.
2. **Write-back pe `omodificari.vc2` FACUT si dovedit** — nu mai exista fisier editat fara binar.
Prima incercare a picat la fidelity check: subagentul lasase linia 14485 goala in loc de `\t\t`.
Restaurata. Dovada pe binarul din proiect: md5 `d23691466b7017380fe36099943b3208`, **diff 0 linii**.
3. **Ambele suite rulate**: `test_s4b_sincronizare` **44/0**, `test_s4b_dialog` **35/0**.
A fost nevoie de o corectie de fixture (`gnPPretV`, coloanele `pretv`/`tvav` in cursorul `trul`)
plus un caz nou cu TVA 19% — detalii in `docs\raport_r7_sincronizare.md`.
4. **Intrebarea de fapt: raspunsa** — nu le recalculeaza nimeni; `VALOAREV`/`VALTVAV` ajung invechite
in Oracle, `VALOAREVCTVA` nu e coloana in `RUL`. Raportat ca defect, **nereparat**.
5. **Changelog completat** (2 randuri in `:modificare:`, blocul 2.11.15) si **diff regenerat** ca
`docs\diff_r6_r7_pentru_commit.md` (inventarul intregului commit; `docs\diff_r6_punct6.md` ramane
ca rationament detaliat al punctului 6).
### Nimic nu e intr-o stare periculoasa
- Niciun fisier editat fara write-back. Nicio tranzactie deschisa. `vfp9.exe` nu ruleaza.
- **Nimic nu e comis** — nici SVN, nici git, nici in `COMUN`. Se asteapta aprobarea pe
`docs\diff_r6_r7_pentru_commit.md`, apoi `svn commit` tintit + `roa_sync.bat`.
- `roafacturare.PJT`/`.PJX`/`.exe` raman modificate din sesiunea de VFP a lui Marius: **nu se comit**.

65
docs/progres.md
View File

@@ -2309,5 +2309,66 @@ initial, apoi **respinsa** — nu se reintroduce.
- `ff_2026_08_20_01` (garda `FACT-025`, runda 5) e **deja aplicat** pe `MARIUSM_AUTO`; scriptul 02 il
contine. **Nu se re-aplica 01** — ar sterge punctul 6.
Ramase: proba pe ecran a punctelor 1-5, aplicarea scriptului pe `MARIUSM_AUTO`, partea VFP a
punctului 6, si intrarea de changelog pentru runda 6 (nu exista inca).
Ramase: partea VFP a punctului 6 si intrarea de changelog pentru runda 6 (nu exista inca).
**Corectie 20.08.2026, seara** — doua puncte din lista de mai sus erau deja facute:
- **Proba pe ecran a punctelor 1-5**: facuta de Marius.
- **Scriptul `ff_2026_08_20_02_COMUN_PACK_FACTURARE.sql` era deja aplicat** pe schema
`MARIUSM_AUTO` de pe `ROA_CENTRAL`, contrar notei de mai sus ("NERULAT"). Dovezi, nu mtime:
`VERSIUNE` are randul `20.08.2026 / seq 2 / COMUN_PACK_FACTURARE`; `ALL_OBJECTS` da PACKAGE si
PACKAGE BODY **VALID**, `last_ddl_time` 20.08.2026 13:56:38; iar sursa vie din `ALL_SOURCE`
(spec + body, normalizata: fara `CREATE OR REPLACE`, fara `/`, fara antetul de comentariu si
fara `exec`/`commit`) e **identica cu fisierul de pe disc — 0 linii diferenta pe 16 407**.
Deci in Oracle sta varianta **finala** (fara recalcul), nu varianta respinsa, desi fisierul are
mtime 15:45, ulterior compilarii de la 13:56.
Concluzie de metoda: mtime-ul fisierului si nota "scriptul nu a fost rulat" din raportul de
livrare nu sunt surse de stare pentru ce e in Oracle. Starea se citeste din `VERSIUNE` +
`ALL_SOURCE`, prin diff, inainte de a re-aplica ceva.
- Ramane valabila interdictia: **nu se re-aplica `ff_2026_08_20_01`** — ar sterge punctul 6.
## Runda 6 punctul 6 + runda 7 (sincronizare) - 20.08.2026, seara
Starea completa, cu inventar pe `fisier:linie`, ce s-a stabilit si ce e in lucru:
**`docs\handoff_r6_r7_sincronizare.md`**. Pe scurt:
- **Punctul 6 (explicatie TVA in `frm_facturi`): TERMINAT**, write-back verificat prin
reconversie (0 linii diferenta, md5 identic), probat pe ecran de Marius de doua ori.
Filtrul final al listei: `id_jtva_coloana > 0 AND afisat > 0 AND jv = 1 AND cota_tva = <cota
liniei>`. Pe date (`vjtva_coloane`, `MARIUSM_AUTO`): `afisat = 0` sunt liniile de TVA,
`afisat = 1` bazele, `afisat = 2` neimpozabilele; `jv = 1` tine afara explicatiile de
achizitie, care altfel treceau de garda `FACT-029` fiindca au aceeasi cota.
- **Runda 7, in lucru**: sincronizarea articole-rulaje porneste doar din buton (se scoate
declansarea de la salvare, `omodificari.vc2:14484-14494`), si `AplicaModificareTrul`
(`ofacturare_editare.prg:924`) scrie si `pretv`/`tvav`, nu doar `pretvtva`.
**Perimetru fixat de Marius: doar preturi, nu si `valoarev`/`valtvav`/`valoarevcTVA`** -
sincronizarea e intre cantitate si preturi. Ramane de raspuns, ca fapt, cine recalculeaza
acele valori dupa sincronizare.
- **Nimic nu e comis** - decizia lui Marius e un singur commit, dupa ce sunt gata toate trei.
- `roafacturare.PJT`/`.PJX`/`.exe` apar modificate: zgomot din sesiunea lui de VFP, se lasa asa.
### Runda 7 - terminata, 20.08.2026, 22:40
Raport complet: **`docs\raport_r7_sincronizare.md`**. Diff-ul commit-ului unic (runda 6 + runda 7):
**`docs\diff_r6_r7_pentru_commit.md`**.
- **M1 gata**: blocul de declansare de la salvare a disparut din `frm_modific2024.inainte_de_do_termin`;
`AfiseazaDialogSincronizareArticole` are un singur apelant, butonul (`omodificari.vc2:16665`).
`SemnaturaDivergenteSincronizare` + `cSemnaturaSincronizare` au ramas fara consumator - semnalate,
nesterse. Write-back facut, dovedit prin reconversie: 0 linii diferenta, md5 identic.
- **M2 gata, in perimetrul corectat**: `AplicaModificareTrul` scrie `pretv`, `pretvtva`, `tvav`.
Cele trei campuri de valoare pe care le adaugase subagentul au fost scoase.
- **Teste**: `test_s4b_sincronizare` **44/0**, `test_s4b_dialog` **35/0**. Prima rulare a dat 40/2,
din fixture, nu din cod: harness-ul nu definea `gnPPretV`, iar cursorul `trul` din test nu avea
coloanele `pretv`/`tvav` (tabela reala `RUL` le are). Adaugat si un caz cu TVA 19% real (C1 1600),
fiindca toate cazurile existente aveau `proc_tvav = 1` si `tvav` ieseau 0 orice s-ar fi scris.
- **Raspunsul la intrebarea de fapt: nu le recalculeaza nimeni.** Lantul e verbatim de la cursor
pana in Oracle - `trul` -> `RUL_TEMP` (`ofacturare_comun.vc2:3814`, doar `id_util`/`sters` se
suprascriu) -> `sql_temp_insert` -> `INSERT INTO RUL (<lista coloane>) SELECT ... FROM RUL_TEMP`
(`PACK_CONTAFIN.pck:2013`). Nici `ActualizeazaBaraTotaluri` (insumeaza doar `tvd.valoare`), nici
`finalizeaza_modificare_nota` nu ating valorile. Interogat pe `MARIUSM_AUTO`: `VALOAREV` si
`VALTVAV` **sunt** coloane in `RUL` si ajung invechite in baza; `VALOAREVCTVA` **nu e** coloana -
exista doar in cursorul Fox, calculat la incarcare, deci ramane invechit doar pe ecran.
Back-fill-ul de la reincarcare nu repara: are garda `WHERE EMPTY(NVL(...,0))`, deci prinde doar
zerourile. Raportat ca defect, **nereparat** - decide Marius.
- **Nimic nu e comis.** Se asteapta aprobarea pe `docs\diff_r6_r7_pentru_commit.md`.

113
docs/raport_r6_punct6_vfp.md Normal file
View File

@@ -0,0 +1,113 @@
# Raport runda 6, punctul 6, partea VFP
## GATA — text editat, write-back facut si verificat
Implementare completa a partii VFP din punctul 6 (explicatia TVA in dialogul de modificare a
articolului din `frm_facturi`), conform `docs\brief_r6_punct6_vfp.md`, punctele M1-M5, plus
doua corectii cerute de team-lead la review (TabIndex complet, `Destroy` inchide ambele
cursoare). Scris pe binar cu succes; verificarile de mai jos confirma sincronizarea text/binar.
## Inventar modificari (numerotare finala, dupa write-back)
Fisier: `D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare_comun.vc2` (+ `ofacturare_comun.vcx`/`.vct`).
- **M1** — `frm_facturi.do_modifica_explicatie` (`:4642`): la `:4650-4651`, doua
`AddProperty(poRec, 'data_act', crsfacturi.data_act)` / `AddProperty(poRec, 'id_part',
Nvl(crsfacturi.id_part, 0))`, intre `poRec.explicatie = NVL(...)` si `If poRec.sters = 0`.
- **M2** — clasa `frm_modifica_articol_factura` (`:5132-5369`):
- Layout: `Height` 370->431 (`:5155`); `_shape3.Top` 323->384 (`:5192`); `cbo_saft.Top`
329->390 (`:5234`); `lbSaft.Top` 332->393 (`:5284`).
- `OBJECTDATA` ZOrder (`:5140-5143`): 4 linii noi — `_shape4`, `lbExplTva`, `cbo_expl_tva`,
`lbExplTvaInfo`.
- Proprietate noua `nidjtvaales`: `*p: nidjtvaales` in `*<DefinedPropArrayMethod>` (`:5147`,
intre `*p: nid` si `*p: ntip_selectie`), valoare initiala `nidjtvaales = 0` in `*<PropValue>`
(`:5158`).
- Obiecte noi (ADD OBJECT): `_shape4` (`:5197`), `cbo_expl_tva` (`:5207`, `ControlSource` gol,
`RowSource` populat in `Init`), `lbExplTva` (`:5257`, caption `Explicaţie TVA`, diacritic
cp1250 `0xFE`), `lbExplTvaInfo` (`:5266`).
- **M3** — `frm_modifica_articol_factura.Init` (`:5313-5353`): la final (dupa blocul
`citeste_lungcampexplart`), populare `cbo_expl_tva` din `vjtva_coloane` filtrat pe cota TVA a
liniei, cu cele 3 ramuri din brief (cota necunoscuta la `:5331-5336`; gasit la `:5342-5345`;
negasit la `:5346-5350`).
- **M4** — `cbo_expl_tva.InteractiveChange` (`:5355-5367`, metoda noua — override de eveniment
de baza, nu necesita `*m:`): seteaza `Thisform.nidjtvaales`, `poRec.id_jtva_coloana`, si sub
garda `gl406` recalculeaza `poRec.taxcode` prin `GetTaxCodeIdPart`.
- **M5** — `inainte_de_do_termin` (`:5298-5311`): parametrul 5 (`lcParamJtva`, `:5301-5302`)
construit literal (nu bind), `null` cand `Thisform.nidjtvaales` n-a fost atins.
- **In plus fata de M1-M5, cerut/corectat la review**:
- `PROCEDURE Destroy` (`:5288-5296`) — inchide `crsExplTvaCbo` (RowSource-ul combo-ului) si
`crsExplTvaArt` (cursorul intermediar din `Init`) daca raman deschise, apoi `DoDefault()`
(`:5295`) — lantul de curatenie mostenit din `frm_termin_renunt` (`_frm_child.vcx`) nu e
taiat; acelasi tipar (cleanup local + `DODEFAULT()`) e deja folosit in fisier la
`frm_modifica_factura.Destroy` (`:5720-5722`).
- `TabIndex`, ordine completa: `Ed_tx_simplu1`=1, `cbo_expl_tva`=2 (nou), `cbo_saft`=2->3,
`BUT_TERMIN1`=3->4, `But_renunt1`=4->5, `Lb_titlu_alb_b121`=5->6, `lbSaft`=6->7, `lbExplTva`=8
(nou); `lbExplTvaInfo` ramane fara `TabIndex` (`Visible = .F.`).
Ordinea fizica finala a metodelor in clasa: `Destroy`, `inainte_de_do_termin`, `Init`,
`cbo_expl_tva.InteractiveChange` — confirmata din textul regenerat de FoxBin2Prg la fidelity-check
(nu presupusa).
## Write-back — confirmat
`txt2vcx.ps1 -TextFile COMUN\clase\ofacturare_comun.vc2 -ProjectRoot D:\ROA\ROAFACTURARE
-CacheRoot D:\ROA\ROAFACTURARE -AllowComun`:
- Prima rulare (pe textul M1-M5, inainte de corectiile de TabIndex/`Destroy`): **ESEC pe ordine**
— exact avertismentul din brief ("FoxBin2Prg nu pastreaza ordinea textuala pentru ADD OBJECT
multiple"). Am adoptat ca sursa blocul clasei `frm_modifica_articol_factura` din
`<staging>\verify\ofacturare_comun.vc2` (ordinea canonica ADD OBJECT: `_shape3, _shape4,
cbo_expl_tva, cbo_saft, Ed_tx_simplu1, lbExplTva, lbExplTvaInfo, lbSaft`), fara sa ating nicio
alta clasa din fisier.
- Rularea finala (dupa corectiile de TabIndex + `Destroy`, cu semnal `WRITE-BACK ACUM` de la
team-lead, lock-ul lui Marius eliberat): **OK** — `1/1 fisier(e) scrise cu succes`, fara alt
esec de fidelitate.
**Dovada de sincronizare text/binar** (nu `mtime` — reconversie separata + diff):
`vcx2txt.ps1 -Source ofacturare_comun.vcx -Force` intr-un cache temporar separat, apoi
`diff` cu textul din arbore -> **0 linii diferenta**.
## Verificari encoding (inainte / dupa, pe tot parcursul)
- **Octeti > 0x7F**: 12 inainte de orice editare -> **13** dupa toate editarile si dupa
write-back (neschimbat de la corectiile de TabIndex/`Destroy` — nu ating diacritice). Singurul
octet nou e `0xFE` (diacriticul `ț` din caption-ul `lbExplTva`, `Explicaţie TVA`); zero
aparitii de `EF BF BD` (fara corupere UTF-8).
- **Octetul diacritic verificat explicit** (cerut de team-lead): `lbExplTva.Caption` (`:5258`) are
octetul `0xFE` exact in aceeasi pozitie semantica ca `Lb_titlu_alb_b121.Caption` (`:5170`,
`"Modific\xE3 explica\xFEie articol"`) din aceeasi clasa — acelasi octet `0xFE` = `ț` cp1250 in
ambele, confirmat byte-cu-byte (`od -c`) pe fisierul final, dupa write-back.
- **LF izolate** (`0x0A` fara `0x0D` inainte): 0, atat inainte cat si dupa toate editarile si dupa
write-back. Fisierul final are 7540 de linii, toate CRLF.
## Scop
`git status` in `D:\ROA\ROAFACTURARE\COMUN` (repo propriu al lui COMUN, unde `.vc2` e versionat
si `.vcx`/`.vct` sunt gitignored prin design — `git check-ignore` confirma `*.VCX`/`*.VCT` in
`.gitignore`): **doar** `clase/ofacturare_comun.vc2` modificat (117 insertii, 11 stergeri),
niciun alt fisier. Niciun PL/SQL, niciun `omodificari.vc2`, niciun grid de articole, niciun
`Text1.ReadOnly` atins — conform interdictiilor.
## Ce n-a fost facut si de ce
Nimic din scopul brief-ului a ramas nefacut. Singura abatere fata de fluxul standard a fost
timpul de asteptare intre editarea textului si write-back, cauzat de un lock legitim
(sesiunea VFP activa a lui Marius pe acelasi binar) — nu de o problema de implementare; write-back-ul
s-a facut abia dupa ce team-lead a confirmat eliberarea lock-ului si a dat semnalul explicit.
## Nu s-a comis nimic si nu s-a rulat nicio sincronizare
Nu s-a rulat `git_sync.ps1`, `roa_sync.bat`, `svn update/commit`, `git commit/push`. Nu s-a pornit
VFP, nu s-a deschis IDE-ul. Commit-ul ramane la latitudinea sesiunii principale, dupa aprobare.
## Fisiere atinse in aceasta sesiune
- `D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare_comun.vc2` — editat, write-back facut, verificat
(0 linii diferenta la reconversie).
- `D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare_comun.vcx` / `.vct` — regenerate prin write-back,
verificate byte-identic cu textul din arbore (via reconversie separata).
- `D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare_comun.vc2.pre_r6p6.bak`,
`ofacturare_comun.vc2.pre_r6p6_fix2.bak` — backup-uri locale (baseline-uri intermediare),
netracked de git, de sters la curatenie (`COMUN\utile\curatenie.ps1`).
- `D:\ROA\ROAFACTURARE\docs\raport_r6_punct6_vfp.md` — acest raport.
- Niciun proces deschis, nicio tranzactie Oracle deschisa, niciun date de test consumate.

138
docs/raport_r7_sincronizare.md Normal file
View File

@@ -0,0 +1,138 @@
# Raport runda 7 — sincronizarea articole-rulaje
Scris 20.08.2026, 22:40. Acopera M1, M2 (dupa corectia de perimetru), rularea celor doua suite si
raspunsul la intrebarea de fapt ramasa deschisa.
## M1 — sincronizarea porneste doar din buton — GATA
Blocul "al doilea punct de declansare" a fost sters din `frm_modific2024.inainte_de_do_termin`.
Metoda se termina acum la `RETURN m.llRet`, imediat dupa validarile pe `tvd`; nu mai exista niciun
apel de sincronizare pe drumul salvarii.
`AfiseazaDialogSincronizareArticole` are un **singur** apelant ramas:
`omodificari.vc2:16665`, adica butonul `pgfArticole.PAGE3.cmdSincronizeazaArticole.Click`.
Definitia metodei e la `:13184`.
**Ramase fara consumator, semnalate, NEsterse** (conform deciziei):
| membru | unde |
|---|---|
| `SemnaturaDivergenteSincronizare` (metoda) | `omodificari.vc2:14829`, declarata `*m:` la `:6820` |
| `cSemnaturaSincronizare` (proprietate) | declarata `*p:` la `:6831`, valoare initiala `:6870` |
| atribuirea care le leaga | `:14945`, in `IncarcaArticoleFactura`-ul din ramura cu articole |
Proprietatea e **scrisa o data si citita niciodata**; metoda e apelata doar ca sa alimenteze acea
scriere. Ambele sunt acum cod mort, dar functional inofensiv.
### Write-back — FACUT si dovedit
`txt2vcx.ps1 ... -AllowComun` a esuat prima data la fidelity check: subagentul rundei precedente
lasase **linia 14485 goala**, desi in original era `\t\t` (o linie de spatiere pe care stergerea
n-ar fi trebuit s-o atinga). Restaurata la `\t\t`; diff-ul fata de HEAD e acum exact blocul de 11
linii sters, nimic altceva.
Dovada pe binarul din proiect, nu pe `mtime`: reconversie `vcx2txt.ps1` intr-un cache temporar,
**md5 identic** (`d23691466b7017380fe36099943b3208`), **diff 0 linii**. Binare la 22:20:09,
text la 22:20:10. Encoding: 6 octeti >0x7F (`0xAA`, `0xE3`, `0xFE` — cp1250), zero `EF BF BD`,
CRLF pe toate cele 17 145 de linii.
## M2 — `pretv` si `tvav` in rulaj — GATA, perimetru corectat
`AplicaModificareTrul` (`COMUN\programe\ofacturare_editare.prg:926`) scrie acum:
```
REPLACE (m.lcCampCant) WITH m.tnCantitateNoua IN trul
REPLACE pretv WITH m.lnPretv, pretvtva WITH m.lnPretvtva, tvav WITH m.lnTvav IN trul
```
Cele trei campuri de valoare (`valoarev`, `valtvav`, `valoarevcTVA`) pe care subagentul apucase
sa le adauge din varianta initiala a brief-ului **au fost scoase**, impreuna cu liniile care le
calculau (`lnValoarecTVA`, `lnValoareTVA`, `lnValoareFtva`) si cu `lnCantitate`, ramas nefolosit.
`LOCAL`-urile si comentariile-antet ale ambelor functii (`AplicaModificareTrul` si
`AplicaSincronizareArticole`) au fost aduse la zi.
Formula e cea canonica din `calculeaza_valori_rul`, ramura `pretvtva` (`omodificari.vc2:13573-13575`),
cu `gnPPretV` pentru preturi — reutilizata, nu reinventata.
`.prg`, deci fara write-back. Fisierul e ASCII curat, CRLF.
## Teste — ambele suite verzi
O suita per apel, `.fxp` sters inainte de fiecare rulare.
| suita | rezultat |
|---|---|
| `test_s4b_sincronizare.prg` | **44 PASS / 0 FAIL**, zero erori in log |
| `test_s4b_dialog.prg` | **35 PASS / 0 FAIL**, zero erori in log |
### Prima rulare a picat — fixture, nu cod
`test_s4b_sincronizare` a dat initial **40 PASS / 2 FAIL**, cu erori in log:
```
EROARE 12 [APLICAMODIFICARETRUL:942] Variable 'GNPPRETV' is not found.
EROARE 12 [APLICAMODIFICARETRUL:947] Variable 'PRETV' is not found.
```
Ambele vin din harness, nu din codul de productie:
1. testul definea `gnPC`, dar **nu si `gnPPretV`** — suitele surori din `achizitie_import` il pun
la `4` (`test_adauga_factura_ui.prg:167`);
2. cursorul `trul` construit de `CreeazaTrulTest` avea `pretvtva`, dar **nu si `pretv`/`tvav`` —
campuri pe care tabela reala `RUL` le are (verificat in Oracle, vezi mai jos) si pe care
`calculeaza_valori_rul` le scrie de ani de zile.
Modificari in `COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg`:
- `PUBLIC gnPPretV = 4` daca nu exista deja, dupa blocul identic al lui `gnPC`;
- `pretv N(14,4)` si `tvav N(14,4)` adaugate in `CREATE CURSOR trul`;
- asserturile C1 1300/1400 verifica si `pretv`/`tvav` (pe `proc_tvav = 1`, adica TVA 0);
- **caz nou C1 1600**, cu TVA 19% real, ca defalcarea sa fie efectiv acoperita:
`238 / 2 buc = 119` cu TVA -> `pretv 100 + tvav 19`. Fara el, toate cazurile din sectiunea C
aveau `proc_tvav = 1` si `tvav` ar fi iesit 0 orice s-ar fi scris in formula.
De aici cresterea 42 -> 44 de cazuri.
## Intrebarea de fapt: cine recalculeaza `valoarev`/`valtvav`/`valoarevcTVA` dupa sincronizare?
**Nimeni.** A treia concluzie din cele trei posibile. Se raporteaza ca defect, **nu s-a reparat**.
Lantul complet, verificat cap-coada:
| pas | unde | ce face cu cele trei campuri |
|---|---|---|
| incarcare nota | `ofacturare_editare.prg:96-104` | `valoarev`/`valtvav` vin din `vrul_tot`, completate **doar daca sunt goale** (`WHERE EMPTY(NVL(...,0))`); `valoarevcTVA` e calculat **o singura data**, `valoarev + valtvav AS valoarevctva`, la construirea `RUL_TEMP` -> `trul` |
| sincronizare | `ofacturare_editare.prg:947` | scrie `cant`/`cante`, `pretv`, `pretvtva`, `tvav`. **Nu le atinge** |
| dupa "Aplica" | `omodificari.vc2:17097` | `ActualizeazaBaraTotaluri()` + refresh grid. Bara **doar insumeaza `tvd.valoare`** (`:13009`) — nu atinge `trul` |
| salvare, pas 1 | `omodificari.vc2:14379` | `inainte_de_do_termin` pune doar `id_set` pe `trul` si valideaza `tvd` |
| salvare, pas 2 | `ofacturare_comun.vc2:3812-3814` | `Select * From trul Into Cursor RUL_TEMP`, apoi `Replace All id_util..., sters With 0`. **Copie verbatim** |
| salvare, pas 3 | `oscrie_in_fisiere.prg:131` | `sql_temp_insert('rul_temp','RUL_TEMP')` — bulk insert, fara calcul |
| salvare, pas 4 | `PACK_CONTAFIN.pck:2013` | `INSERT INTO <schema>.RUL (<lista>) SELECT <lista> FROM RUL_TEMP`, lista fiind coloanele reale ale lui `RUL` (`LISTA_CAMPURI`, `:3287`). **Fara recalcul** |
| post-procesare | `PACK_CONTAFIN.pck:8601` | `finalizeaza_modificare_nota` renumeroteaza `cod`, atinge `atasamente_vanzari`/`nom_lucrari`. **Nimic pe valori** |
### Ce ajunge efectiv gresit in Oracle
Interogat pe `MARIUSM_AUTO` / `ROA_CENTRAL`, coloanele reale ale tabelei `RUL`:
```
CANT, CANTE, PRETV, PRETVTVA, TVAV, VALOAREV, VALTVAV (7 din 8 cerute)
```
`VALOAREVCTVA` **nu e coloana in `RUL`**. Exista doar in cursorul Fox, calculat la incarcare
pentru grid si pentru bara de totaluri (`csumcolumns`) — nu se salveaza nicaieri.
Deci, concret:
- **`VALOAREV` si `VALTVAV` ajung invechite in Oracle.** Dupa sincronizare, cantitatea si pretul
de pe rand sunt cele noi, iar cele doua valori raman cele dinainte. La o reincarcare ulterioara
a notei nu se repara singure: back-fill-ul de la incarcare are garda `WHERE EMPTY(NVL(...,0))`,
deci prinde doar valorile zero, nu si pe cele nenule dar gresite.
- **`VALOAREVCTVA` nu ajunge in Oracle deloc**, dar ramane invechit **in ecran** pana la
reincarcarea notei: gridul de rulaje si bara de totaluri arata suma veche.
Iesirea manuala exista: daca utilizatorul atinge randul de rulaj in gridul de pe pagina 1,
`calculeaza_valori_rul` recalculeaza toate cele sase campuri deodata (`omodificari.vc2:13587`).
Sincronizarea insa porneste de pe pagina 3 si nu poate apela acea metoda direct — isi alege
cursorul din `pgfArticole.ActivePage` (`:13532-13533`) si ar scrie in `trul_obinv`.
**Decizia daca se repara si cum e a lui Marius.** Nu s-a atins nimic.