221 lines
13 KiB
Markdown
221 lines
13 KiB
Markdown
# 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**.
|