docs: planurile, proiectarile si rapoartele de lucru intra in versionare
Folderul docs\ era pana acum in afara oricarui control de versiuni - nici git, nici SVN - desi contine planurile pe puncte, proiectarile si rapoartele de cercetare pe care se sprijina modificarile din cod. O stergere acolo era definitiva. Fisierele intermediare (handoff-uri intre sesiuni, diff-uri deja aplicate) au fost sterse inainte, nu versionate: ce era durabil in ele a intrat in antetele fisierelor de test la care se refereau. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
This commit is contained in:
101
docs/brief_s5_test_scriere_reala.md
Normal file
101
docs/brief_s5_test_scriere_reala.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Briefing — S5, testul cu scriere reala in Oracle
|
||||
|
||||
Misiune pentru un agent proaspat. Se citeste **impreuna cu** `docs\handoff_s5.md` (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_s5.md`.
|
||||
**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. `D:\ROA\ROAFACTURARE\docs\diff_s5_test_scriere_reala.patch` — 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
|
||||
`D:\ROA\ROAFACTURARE\docs\handoff_s5_scriere_reala.md` 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.
|
||||
Reference in New Issue
Block a user