139 lines
7.3 KiB
Markdown
139 lines
7.3 KiB
Markdown
# 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.
|