Files
roafacturare/docs/brief_s5_test_scriere_reala.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

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.