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
102 lines
5.4 KiB
Markdown
102 lines
5.4 KiB
Markdown
# Briefing — S5, testul cu scriere reala in Oracle
|
|
|
|
Misiune pentru un agent proaspat. Se citeste **impreuna cu** handoff intermediar (sters) (starea blocului) si
|
|
`COMUN\docs\reguli_lucru.md` (regulile de livrare si testare). Nu relua cercetarea — e facuta.
|
|
|
|
## De ce exista acest test
|
|
|
|
Cele sase suite headless dovedesc **doar absenta regresiei**. Lucrul care conteaza in S5 nu e atins de
|
|
niciuna dintre ele, pentru ca se intampla in Oracle, in interiorul unei tranzactii:
|
|
|
|
`pack_facturare.actualizeaza_vanzari` (`PACK_FACTURARE.pck:16020-16023`) face
|
|
`UPDATE VANZARI_DETALII SET STERS = 0` pe **tot documentul**, fara garda. E apelata din
|
|
`finalizeaza_modificare_nota`. Consecinta dubla, care e chiar motivul deciziei 38:
|
|
|
|
1. o linie marcata stearsa de VFP **inainte** de `finalizeaza_modificare_nota` s-ar pierde tacut;
|
|
2. orice linie stearsa la o editare **anterioara** e inviata la fiecare salvare ulterioara — deci
|
|
stergerea de linie n-ar deveni niciodata definitiva.
|
|
|
|
Idiomul adoptat („marcheaza tot sters, invie ce ramane", scris **dupa** `finalizeaza_modificare_nota`)
|
|
trebuie sa corecteze ambele. **Asta e ce are de dovedit testul, nu altceva.**
|
|
|
|
## Ordinea care se testeaza (decizia 38)
|
|
|
|
O singura tranzactie manuala:
|
|
|
|
```
|
|
do_deschide_tranzactie()
|
|
OSCRIE_IN_FISIERE(2, ...) -- sterge nota veche
|
|
OSCRIE_IN_FISIERE(0, ...) -- scrie nota noua
|
|
finalizeaza_modificare_nota(...) -- realiniaza COD, RESETEAZA STERS = 0
|
|
ScrieArticoleFacturaEditate(id_vanzare) -- NOU
|
|
pack_facturare.recalculeaza_totaluri_vanzari(id_vanzare, discount) -- NOU
|
|
do_inchide_tranzactie(Iif(lnSucces < 0, 2, 1))
|
|
```
|
|
|
|
Agatarea reala e in `ofacturare_comun.vc2:3828` si `comun.vc2:2491`, acelasi bloc de 3 randuri.
|
|
|
|
## Ce trebuie sa dovedeasca, punct cu punct
|
|
|
|
**Trecerea 1 — o editare cu o linie stearsa si o linie adaugata:**
|
|
|
|
- linia marcata stearsa in `tvd` ajunge cu `STERS = 1` in `VANZARI_DETALII` **dupa** ce s-a intors
|
|
`finalizeaza_modificare_nota` (deci resetul ei nu o invie);
|
|
- linia noua (`id_vanzare_det = 0`) ajunge cu `INSERT`, cu `ID_VANZARE_DET` alocat de trigger
|
|
(`TRG_VANZARI_DET_BEFOINS`), si cu `PRET_ACHIZITIE` exact valoarea tastata;
|
|
- liniile pastrate raman active (`STERS = 0`) cu cantitatile/preturile editate;
|
|
- `PRET_ACHIZITIE` pe liniile **existente** ramane **neatins** (se omite din `SET`-ul de `UPDATE`) —
|
|
se verifica valoarea dinainte vs. dupa, pe o linie careia i s-a schimbat cantitatea;
|
|
- totalurile din `VANZARI` corespund liniilor active dupa recalcul.
|
|
|
|
**Trecerea 2 — a doua editare a ACELEIASI facturi, fara nicio modificare:**
|
|
|
|
- linia stearsa la trecerea 1 **ramane stearsa**. Asta e consecinta 2 din decizia 38 si e singurul
|
|
mod de a dovedi ca idiomul repara resetul. **Fara aceasta trecere, testul nu si-a atins scopul.**
|
|
|
|
## Cum se verifica
|
|
|
|
**Nu din logul testului.** Dupa fiecare trecere, verificare **independenta prin `sqlplus`** pe
|
|
`MARIUSM_AUTO@ROA_CENTRAL`, cu `SELECT`-uri pe `VANZARI` si `VANZARI_DETALII`. Tiparul exista deja si
|
|
a fost folosit cu succes: `COMUN\utile\Teste\editare_factura\test_writeback_buton1.prg` plus
|
|
`docs\cercetare\rec_test_writeback.md` — **citeste-le intai**, sunt modelul de urmat (au facut COMMIT
|
|
real pe `id_vanzare = 1048`, cu 5 verificari confirmate independent).
|
|
|
|
Cifrele se **numara din loguri**, nu se citesc din impresie. Dovada ca rularea a ajuns la capat e
|
|
linia finala a suitei (`REZULTAT` sau `done`, dupa tipar).
|
|
|
|
## Aprobare si costuri
|
|
|
|
**Scrierea reala e aprobata de Marius** (09.08.2026), aprobarea e consemnata in handoff intermediar (sters).
|
|
**Consuma date de test ireversibil**: `cod`-ul documentului se realoca la fiecare salvare (la testul
|
|
precedent, `1140886 -> 1140893 -> 1140894`). Alege un document de test, **nu** unul folosit ca baza de
|
|
regresie de alte suite daca poti evita, si **consemneaza in raport `cod`-urile consumate**.
|
|
|
|
## Reguli care nu se incalca
|
|
|
|
- **`COMUN\clase\ofacturare.vc2` nu se atinge.**
|
|
- `actualizeaza_vanzari` si `PACK_CONTAFIN` **nu se modifica**.
|
|
- **Fara commit** — nici git, nici SVN.
|
|
- **Un singur scriitor pe fisier.** `omodificari.vc2` e inchis (livrare finala), nu-l atinge.
|
|
Fisierele tale sunt in `COMUN\utile\Teste\editare_factura\`.
|
|
- **Nu rula `git_sync.ps1`** decat daca text si binar sunt sincrone.
|
|
- **Nu porni VFP daca mai exista un `vfp9.exe` viu** care nu e al tau — verifica intai.
|
|
- Daca gasesti un defect real in codul de productie, **nu-l repara singur**: raporteaza-l cu
|
|
`fisier:linie` + citatul minim si asteapta.
|
|
|
|
## Livrabile — se scriu PE DISC, la aceste cai exacte
|
|
|
|
1. `COMUN\utile\Teste\editare_factura\test_s5_scriere_reala.prg` — suita.
|
|
2. `D:\ROA\ROAFACTURARE\docs\cercetare\rec_s5_scriere_reala.md` — raportul: ce s-a dovedit, ce nu,
|
|
`SELECT`-urile de verificare cu rezultatele lor, `cod`-urile consumate, cifrele din loguri.
|
|
3. diff aplicat (sters) — diff-ul.
|
|
|
|
Raspunsul catre orchestrator e **scurt**: „GATA" + cifrele + ce nu s-a dovedit. **Nu trimite raportul
|
|
in text** — el sta pe disc.
|
|
|
|
## Predarea contextului (REGULA ZERO)
|
|
|
|
Daca ajungi la **~200-250k** context: **opreste-te**, adu tot la o stare consistenta pe disc, scrie
|
|
handoff intermediar (sters) cu **starea** (ce e facut, ce nu, ce e
|
|
periculos: tranzactie deschisa, proces viu, date consumate), si anunta. Nu continua „ca mai e putin" —
|
|
si **nu lasa niciodata o tranzactie deschisa** in Oracle.
|