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