romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b5a7108f34fce3ca78a00ece36dca2f65bda9641
roafacturare/docs/rec_s4b_etapa2.md
Marius Mutu b5a7108f34 docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi 
Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge
in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a
planului aflat in lucru. Impartirea:

- 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs,
  TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12,
  watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt
  ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele.
- 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse.
- 91 raman, neatinse.

Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au
fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri
aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase.

progres.md preia rolul de predare: ce ramane din #6 (cele sase documente
parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test
citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in
locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
2026-08-11 22:31:42 +03:00

143 lines
7.9 KiB
Markdown
Raw Blame History

# S4b etapa 2 — butonul, dialogul si verificarea la salvare
Continuarea lui handoff intermediar (sters), sectiunea „S4b etapa 2". Diff-ul complet:
**diff aplicat (sters)** (342 randuri adaugate, 0 sterse, un singur fisier atins:
`COMUN\clase\omodificari.vc2`).
**STARE: WRITE-BACK FACUT, NECOMIS.** `omodificari.vcx`/`.vct` sunt regenerate (11.08.2026 09:34),
textul e cel canonic FoxBin2Prg. Nimic nu e intr-o stare periculoasa.
| Verificare | Rezultat |
|---|---|
| compilare la regenerare (`txt2vcx.ps1`) | `P1,E0,S1,X0` — 0 erori |
| fidelity check binar -> text -> octeti, in staging | trecut (`OK`) |
| `git_sync.ps1` dupa write-back | **0 conversii**, 464 la zi, 0 esecuri — text si binar sincrone |
| textul dupa write-back | 342 adaugari, **0 stergeri** fata de HEAD |
| octeti `>0x7F` (diacritice cp1250) | 6 inainte, 6 dupa, aceleasi valori (170, 227, 254) |
| clasele noi chiar in binar (`.vct`, nu in text) | `frm_sincronizare_articole` x15, `propunere_afisata` x27, `cmdSincronizeazaArticole` x3, `lblAvertisment` x2 |
**Prima incercare de write-back a esuat la fidelity check** — ordonarea canonica FoxBin2Prg difera
de cea scrisa de mana (intrarile `OBJECTDATA` ale header-elor de grid se genereaza singure,
`ADD OBJECT`-urile se sorteaza alfabetic, `optDirectie.Click` merge dupa `Unload`). Am adoptat
textul canonic din staging si am reluat — nicio pierdere de continut, diferentele erau **doar** de
ordine si spatii.
## Ce contine
| Piesa | Unde |
|---|---|
| butonul `cmdSincronizeazaArticole` (Left=350, Top=0, W=250, H=22, TabIndex=6) | `ADD OBJECT` in PAGE3 |
| toggle-ul de `Enabled` pe `lArticoleReadOnly` | `frm_modific2024.Show` |
| `cmdSincronizeazaArticole.Click` | `frm_modific2024` |
| `AfiseazaDialogSincronizareArticole` | `frm_modific2024` |
| verificarea la salvare | `frm_modific2024.inainte_de_do_termin`, imediat inainte de `RETURN m.llRet` |
| clasa `frm_sincronizare_articole` (derivata din `frm_termin_renunt`) | la finalul fisierului |
TabIndex 6 e liber in PAGE3 (folosite: 3, 4, 5, 20 — verificat).
## Ce am schimbat fata de patch-ul partial al agentului mort
Patch-ul din diff aplicat (sters) era mai complet decat il descria predarea (avea si
verificarea la salvare, in metoda corecta). Cinci corectii:
**1. Lipsea `cmdSincronizeazaArticole.Click`** — butonul exista, dar nu facea nimic. Adaugat, cu
aceleasi garzi ca la celelalte doua butoane din PAGE3.
**2. Gridul ramanea nelegat dupa schimbarea directiei.** `ConstruiestePropunereSincronizare` face
`Use In propunere_sincronizare` + `CREATE CURSOR` la fiecare apel (`ofacturare_editare.prg:584-589`),
deci un grid legat la design-time de acel cursor isi pierde legatura la primul click pe radio.
Solutie: gridul se leaga de **`propunere_afisata`**, un cursor cu structura identica creat o
singura data in `Load` (inainte de instantierea controalelor, ca sa existe cand gridul se leaga) si
doar golit + reumplut la fiecare recalcul. Nicio reasignare de `RecordSource` la runtime.
**3. Declansarea la salvare era pe `Reccount(...) > 0`** — ar fi deschis dialogul la *fiecare*
salvare a oricarei facturi cu articole nestocate sau in valuta, pentru ca acelea produc linii `N-A`
in propunere (contract, punctele 1 si 3). Acum se numara doar
`Modificare` / `Adaugare` / `Semnalare`: divergente reale. `N-A` inseamna „nu se poate compara", nu
„difera", si nu mai opreste pe nimeni la salvare.
**4. `Pemstatus(This.oFormArticole, ...)` fara garda de tip** — `oFormArticole` are valoarea
implicita `.F.`, iar `Pemstatus` pe un logic da eroare. Adaugat `Vartype(...) == 'O'`.
**5. Adaugata eticheta de avertisment** ceruta de `propunere_s4b_sincronizare.md` punctul 6
(„Propunere calculata automat - verificati valorile inainte de aplicare"), plus curatarea cursorului
in `Unload`.
## Verificat, nu presupus
| Ce | Cum |
|---|---|
| `_frmbase.WindowType = 1` (dialogul e modal) | `_frm_base.vc2`, blocul `PropValue` |
| `do_termin` cheama `inainte_de_do_termin()` si inchide doar pe `.T.` | `_frm_base.vc2:364-374` |
| `frm_termin_renunt` are `But_termin1` + `But_renunt1` | `_frm_child.vc2:23-51` |
| tiparul apelantului (`CreateObject` + `Show`, citirea lui `gnButon`) | `ofacturare_comun.vc2:4651-4656` |
| clasele `_optiongrup`, `_grdrow`, `_label` exista | `_baza.vc2:435`, `_grd_base.vc2:445` |
| `InputMask = (get_mask(12,gnPCANT))` e tipar real | `omodificari.vc2:12374` s.a. |
| `_frm_child.vcx` nu are nevoie de `SET CLASSLIB` | precedentul `frm_modifica_articol_factura` |
| toate formularele sunt pe `DataSession` implicit (1) | niciun `DataSession` in `_frm_base`/`_baza`/`omodificari` |
| `SET SAFETY OFF` global (pentru `ZAP`) | `COMUN\programe\proceduri.prg:5` |
| octetii cp1250 din fisier sunt neatinsi | cens `>0x7F` = 6 inainte si dupa; diff-ul are **0 stergeri** |
**Netestat**: nimic nu a fost rulat. Dialogul e UI, deci nu e testabil `-A -T` (aceeasi limitare ca
`frm_articol_factura`, `propunere_s4b_sincronizare.md` punctul 7). Logica pura din spate ramane
acoperita de `test_s4b_sincronizare.prg` (35/0), neschimbata de aceasta livrare.
## Doua lucruri de confirmat cu Marius
**A. Aplicarea la salvare ocoleste validarile deja rulate.** Daca utilizatorul apasa „Aplica" in
dialogul deschis *la salvare*, `tvd` se modifica **dupa** ce validarile din
`inainte_de_do_termin` (pret de achizitie, linii sterse) au trecut deja. Alternativa ar fi
reluarea validarilor dupa aplicare — nu am facut-o, ca sa nu extind scopul.
**B. `N-A` nu mai declanseaza dialogul la salvare** (corectia 3). E o alegere de produs facuta de
mine: altfel dialogul ar aparea la fiecare salvare pe documentele in valuta.
## Defect preexistent gasit pe drum — REPARAT (aprobat separat, 11.08.2026)
`omodificari.vc2:16495`, in `frm_modific2024.pgfArticole.PAGE3.cmdAdaugaArticol.Click`:
```
IF !Used('tvd') OR !This.lAreArticoleVanzari OR Thisform.lArticoleReadOnly
```
`This` e **butonul**, nu formularul — `lAreArticoleVanzari` e proprietate a lui `frm_modific2024`
(`omodificari.vc2:12987`, `:14788`, `:14795`, `:14802` o folosesc corect, toate din metode ale
formularului). VFP scurtcircuiteaza `OR`: cand `tvd` exista — adica in exact cazul in care butonul
e activ — primul termen e `.F.` si se evalueaza al doilea, pe buton, unde proprietatea nu exista.
Nu exista metoda `Error` in `_frmbase`/`_baza`/`omodificari` care sa inghita eroarea.
Concluzia: **„Adauga articol" dadea eroare la orice click real**. Suitele existente nu prind asta
pentru ca apeleaza metodele formularului, nu simuleaza click-ul.
**Nu era una, ci doua.** Cautarea sistematica dupa acelasi tipar (proprietati ale formularului
accesate cu `This.` din metode de obiect) a mai gasit una, in aceeasi metoda, la `:16565`:
```
AddProperty(poDate, 'tip', This.nTipVanzare)
```
Ambele reparate cu `Thisform.`. In tot `frm_modific2024` nu mai exista alta: cautarea a acoperit
`lArticoleReadOnly`, `lAreArticoleVanzari`, `nIdVanzare`, `nTipVanzare`, `pgfArticole`,
`ActualizeazaBaraTotaluri`, `AdaugaLinieTvdDinArticol`, `calculeaza_valori_articol`, filtrata pe
metode de obiect (`.Click`/`.Valid`/`.InteractiveChange`/...). Celelalte 4 folosiri ale lui
`This.lAreArticoleVanzari` sunt in metode ale **formularului** (`ActualizeazaBaraTotaluri`, `Show`)
si sunt corecte.
Nu intra in changelog: 2.11.15 nu e inca in productie, deci e un defect al codului nelivrat.
## Changelog
Paragraf nou in blocul **2.11.15** (`:nou:`), nu versiune noua — 2.11.16 a fost dat inapoi
„pana la punerea in productie" (commit `09f9d47`). Descrie butonul, alegerea directiei, liniile
marcate si lasate neatinse, si comparatia de la salvare cu optiunea de a salva fara sincronizare.
Fisierul `changelog_roafacturare.txt` avea deja **un octet stricat in HEAD** (`EF BF BD`, un `©`
transformat candva in U+FFFD, in intrarea despre „ROA Romfast SRL"). E preexistent, **nu l-am
atins**; cenzul ramane 3 octeti `>0x7F` inainte si dupa editarea mea.
## Ce urmeaza
1. **Rebuild `roafacturare.exe`** din IDE si testul pe ecran. Metodele `.vcx` sunt deja compilate
de `txt2vcx.ps1`; EXE-ul nu.
2. Punctele A si B de confirmat.
Reference in New Issue View Git Blame Copy Permalink