Marius Mutu
d9f5ca4226
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
184 lines
9.9 KiB
Markdown
184 lines
9.9 KiB
Markdown
# S5 — testul cu scriere reala in Oracle. Rezultat
|
|
|
|
Aprobat de Marius (09.08.2026, consemnat in `docs\handoff_s5.md`). Suita:
|
|
`COMUN\utile\Teste\editare_factura\test_s5_scriere_reala.prg`. Log:
|
|
`COMUN\utile\Teste\editare_factura\test_s5_scriere_reala_log.txt` (rulare 09.08.2026 23:41:32-23:41:35).
|
|
Diff: `docs\diff_s5_test_scriere_reala.patch`.
|
|
|
|
## Rezultat
|
|
|
|
**25 PASS / 0 FAIL**, numarate din log (12 la trecerea 1, 13 la trecerea 2). Ultima linie a logului
|
|
este `done`, deci rularea a ajuns la capat. Ambele treceri s-au inchis cu **COMMIT real**, iar starea
|
|
finala a fost verificata **independent prin `sqlplus`**, nu din logul testului.
|
|
|
|
**Baseline inainte de pornire**: `test_incarca_vanzare_din_nota` rerulata la 23:27:52 — **5 PASS /
|
|
0 FAIL**, identic cu asteptarea. Golul de baseline din briefing e inchis.
|
|
|
|
## Ce dovedeste, si nu putea fi dovedit headless
|
|
|
|
Proba centrala nu vine dintr-o asertie pe starea finala, ci din **citirea starii necomise in
|
|
interiorul tranzactiei**, pe aceeasi conexiune, intre pasi. In ambele treceri:
|
|
|
|
| Moment | `VANZARI_DETALII.STERS` pe linia stearsa (`det=1582`) |
|
|
|---|---|
|
|
| inainte de tranzactie | `1` (trecerea 2) / `0` (trecerea 1, inca nestearsa) |
|
|
| **dupa `finalizeaza_modificare_nota`, inainte de scrierea liniilor** | **`0`** — resetul a rulat si a **inviat** linia |
|
|
| dupa `ScrieArticoleFacturaEditate` | **`1`** — idiomul a corectat resetul |
|
|
| dupa COMMIT | `1` |
|
|
|
|
Log: liniile 19-28 (trecerea 1) si 57-67 (trecerea 2). Asta stabileste direct cele doua afirmatii ale
|
|
deciziei 38: `pack_facturare.actualizeaza_vanzari` face `UPDATE VANZARI_DETALII SET STERS = 0` pe tot
|
|
documentul **inainte** ca liniile sa fie scrise, si idiomul „marcheaza tot sters, invie ce ramane",
|
|
apelat **dupa** `finalizeaza_modificare_nota` in aceeasi tranzactie, il repara.
|
|
|
|
Trecerea 2 e cea care conteaza pentru consecinta 2: documentul a fost **reeditat fara nicio
|
|
modificare**, resetul a inviat din nou `det=1582`, si linia a ramas totusi stearsa dupa commit.
|
|
Fara aceasta trecere, testul nu ar fi atins scopul.
|
|
|
|
## Ordinea testata
|
|
|
|
Copiata literal din `ofacturare_comun.vc2:3799-3837`, inclusiv blocul nou de la `:3828-3830`:
|
|
|
|
```
|
|
MyDeschideTranzactie() -- _frm_base.vc2:252-265, reprodus inline
|
|
OSCRIE_IN_FISIERE(2, .T., .T.) => 1
|
|
OSCRIE_IN_FISIERE(0, .T., .T.) => 1
|
|
pack_contafin.finalizeaza_modificare_nota => 1
|
|
ScrieArticoleFacturaEditate(tvanz.id_vanzare) => 1
|
|
MyInchideTranzactie(1) -- COMMIT
|
|
```
|
|
|
|
`OSCRIE_IN_FISIERE`, `finalizeaza_modificare_nota` si `ScrieArticoleFacturaEditate` au rulat **reale**,
|
|
pe conexiune Oracle reala. Garda blocului nou (`"OFACTURARE_EDITARE" $ Upper(Set("Procedure"))`,
|
|
`Used('tvanz')`, `Reccount('tvanz') = 1`) a fost satisfacuta in ambele treceri — logul ar fi scris
|
|
`ATENTIE: blocul ScrieArticoleFacturaEditate NU s-a executat` altfel.
|
|
|
|
## Documentul de test si ce s-a facut cu el
|
|
|
|
`id_vanzare = 1049`, factura tip 1 din 07.08.2026, `id_fact = 8009659`, `discount = 0`, fara linii de
|
|
set (`id_vanzare_set` NULL pe toate), 3 linii active. **Nu** `id_vanzare = 1050`, care e documentul pe
|
|
care `descopera_caz_test.prg` il alege pentru cazul `FACTURA_ARTICOLE` (`order by id_vanzare desc`).
|
|
Garzile `ReferinteDocumenteNota` si `EsteInEFactura` intorc 0 pe el, verificat inainte de rulare.
|
|
|
|
**Trecerea 1** — o linie stearsa, o cantitate schimbata, o linie noua:
|
|
|
|
| Linie | Actiune in `tvd` | Stare in Oracle dupa commit |
|
|
|---|---|---|
|
|
| `det=1581` | cantitate `1 -> 2`, `lmodificat = .T.` | `sters=0`, `cant=2`, `pret_achizitie=10` (neatins) |
|
|
| `det=1582` | marcata stearsa (`tvd.sters = 1`) | `sters=1` |
|
|
| `det=1583` | neatinsa | `sters=0`, `cant=1` |
|
|
| linie noua | `id_vanzare_det = 0`, `cantitate=3`, `pret=50`, `pret_achizitie=77.77` | `det=1588` alocat de `TRG_VANZARI_DET_BEFOINS`, `sters=0`, `pret_achizitie=77.77` |
|
|
|
|
**Trecerea 2** — reeditare fara nicio modificare: nicio linie noua, `det=1582` inca `sters=1`,
|
|
`det=1588` inca activa cu `pret_achizitie = 77.77`, totaluri neschimbate.
|
|
|
|
`PRET_ACHIZITIE` e verificat pe valori **nenule si distincte** (10 pe linia existenta careia i s-a
|
|
schimbat cantitatea, 77.77 pe linia noua) — nu pe zerouri, care n-ar fi dovedit nimic. La trecerea 2
|
|
linia `1588` e deja **linie existenta**, deci trece prin `UPDATE`-ul care omite `pret_achizitie` din
|
|
`SET`: faptul ca a ramas 77.77 e proba directa a omisiunii.
|
|
|
|
## Verificarea independenta prin sqlplus (dupa ambele treceri)
|
|
|
|
`MARIUSM_AUTO/…@ROA_CENTRAL`, dupa terminarea procesului VFP:
|
|
|
|
```sql
|
|
select cod, sters, id_fact, discount, total_fara_tva, total_tva, total_cu_tva
|
|
from vanzari where id_vanzare = 1049;
|
|
```
|
|
```
|
|
cod=1140897 sters=0 id_fact=8009659 discount=0 ftva=747.96 tva=157.06 ctva=905.02
|
|
```
|
|
|
|
```sql
|
|
select id_vanzare_det, id_articol, cantitate, pret, pret_cu_tva, proc_tvav, id_gestiune,
|
|
sters, pret_achizitie, id_utils, validat, custodie, descarcat, diferenta
|
|
from vanzari_detalii where id_vanzare = 1049 order by id_vanzare_det;
|
|
```
|
|
```
|
|
det=1581 art=315554536 cant=2 pret=302.51 pret_cu_tva=1 proc_tvav=1.21 id_gest=1 sters=0 pret_ach=10 id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
|
|
det=1582 art=4294507492 cant=1 pret=121.3 pret_cu_tva=1 proc_tvav=1.21 id_gest=0 sters=1 pret_ach=0 id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
|
|
det=1583 art=315554536 cant=1 pret=150 pret_cu_tva=1 proc_tvav=1.21 id_gest=2 sters=0 pret_ach=10 id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
|
|
det=1588 art=315554536 cant=3 pret=50 pret_cu_tva=1 proc_tvav=1.21 id_gest=-1000 sters=0 pret_ach=77.77 id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
|
|
```
|
|
|
|
```sql
|
|
select sum(cantitate*pret) from vanzari_detalii where id_vanzare = 1049 and sters = 0;
|
|
```
|
|
```
|
|
905.02 -- identic cu VANZARI.total_cu_tva dupa recalculeaza_totaluri_vanzari
|
|
```
|
|
|
|
```sql
|
|
select cod, count(*), sum(sters) from vact_tot
|
|
where an=2026 and luna=8 and cod in (1140887,1140896,1140897) group by cod;
|
|
```
|
|
```
|
|
cod=1140887 randuri=10 sterse=10 -- nota de la prima editare, integral stearsa
|
|
cod=1140896 randuri=10 sterse=10 -- nota intermediara, integral stearsa
|
|
cod=1140897 randuri=10 sterse=0 -- nota curenta, activa
|
|
```
|
|
|
|
```sql
|
|
select s.sid from v$transaction t join v$session s on s.saddr = t.ses_addr
|
|
where s.username = 'MARIUSM_AUTO';
|
|
```
|
|
```
|
|
(0 randuri) -- nicio tranzactie deschisa
|
|
```
|
|
|
|
Totalurile: `747.96 + 157.06 = 905.02` (identitate verificata), iar `905.02` e chiar suma
|
|
`cantitate * pret` pe liniile active — relatie care se verifica si pe starea de dinaintea editarii
|
|
(`302.51 + 121.30 + 150.00 = 573.81`), pentru ca toate liniile documentului au `pret_cu_tva = 1`.
|
|
|
|
## Date de test consumate ireversibil
|
|
|
|
- **`cod`-uri realocate: `1140887` -> `1140896` -> `1140897`.** `1140897` e valoarea curenta; cine
|
|
reia testul pe `id_vanzare = 1049` trebuie sa citeasca `cod`-ul din `VANZARI`, nu sa-l presupuna.
|
|
- **`det=1582` ramane `sters=1` definitiv** — documentul are acum 3 linii active in loc de 3 initiale,
|
|
dar alta compozitie (`1581`, `1583`, `1588`).
|
|
- **`det=1588`** e o linie noua, creata de test, cu `id_gestiune = -1000` si `pret_achizitie = 77.77`.
|
|
- Totalurile documentului: `573.81` -> `905.02`.
|
|
- `1049` **nu** e documentul ales de `descopera_caz_test.prg` pentru `FACTURA_ARTICOLE` (acela e
|
|
`1050`), si nu apare in listele de excludere ale suitelor existente (`1140888`/`1140885` pentru
|
|
`test_incarca_cursoare`, `1139934` pentru `test_ui_sterge_linie`).
|
|
|
|
Rerularea suitei pe acelasi document e idempotenta ca structura: trecerea 1 ar sterge iar a doua
|
|
linie activa si ar adauga inca una.
|
|
|
|
## Ce NU acopera testul
|
|
|
|
- **`inainte_de_do_termin`** — `buton = 1` e fortat direct, deci cele cinci validari noi din
|
|
`omodificari.vc2` (cantitate <= 0, `id_articol` nul, `pret` nul, zero linii active, avertismentul de
|
|
`pret_achizitie = 0`) **nu** au fost executate pe aceasta cale.
|
|
- **`frm_modific2024`** nu a fost instantiat: gridul de pe PAGE3, coloana noua de pret de achizitie,
|
|
editabilitatea per rand si marcajul liniilor de set raman neverificate aici (cad in verificarea pe
|
|
ecran).
|
|
- **Liniile din seturi** — documentul ales nu are `id_vanzare_set` nenul pe nicio linie, deci
|
|
comportamentul agregarii pe seturi (totalurile luate din capul de set, nu din componente) **nu e
|
|
atins**. Cifrele de totaluri de mai sus nu spun nimic despre acel caz.
|
|
- **Al doilea punct de intrare** (`comun.vc2:2491`) nu a fost rulat; agatarea acolo e identica
|
|
textual, dar testul a trecut doar prin ramura din `ofacturare_comun.vc2`.
|
|
- **Documentele in valuta** si cele cu `discount` nenul — `1049` are `discount = 0` si
|
|
`in_valuta = 0`, deci parametrul de discount al lui `recalculeaza_totaluri_vanzari` a fost testat
|
|
doar cu valoarea `0`, niciodata cu `NULL` si niciodata cu o valoare nenula.
|
|
- **Esecul partial** — nicio cale de eroare nu a fost provocata, deci ROLLBACK-ul lantului
|
|
(`lnSucces < 0`) ramane netestat pe date reale.
|
|
|
|
## Observatii pe cod, fara defecte de raportat
|
|
|
|
- `INSERT`-ul din `ScrieArticoleFacturaEditate` **omite** cinci coloane `NOT NULL` din
|
|
`VANZARI_DETALII` (`VALIDAT`, `STERS`, `DIFERENTA`, `CUSTODIE`, `DESCARCAT`). Verificat pe dictionar
|
|
inainte de rulare: toate cinci au `DEFAULT 0`, deci `INSERT`-ul e valid, iar linia noua intra activa
|
|
(`STERS = 0`) — confirmat pe `det=1588`. Nu e defect, dar dependenta de `DEFAULT` nu se vede din cod.
|
|
- `id_gestiune = -1000` (valoarea folosita de `CreeazaPoArticolNouTvd`) **nu** are corespondent in
|
|
`NOM_GESTIUNI` si nu exista constrangere de cheie straina pe coloana — `INSERT`-ul trece. Inaintea
|
|
acestui test nu exista nicio linie in `VANZARI_DETALII` cu aceasta valoare; acum exista una.
|
|
- Nu am gasit niciun defect in codul de productie in urma acestui test.
|
|
|
|
## Igiena la iesire
|
|
|
|
Zero tranzactii deschise (interogare pe `v$transaction`, 0 randuri), zero procese `vfp9.exe` ramase
|
|
(`tasklist`), zero commituri git sau SVN. Singurul fisier adaugat de aceasta lucrare in arborele de
|
|
lucru este suita de test; `COMUN\clase\ofacturare.vc2`, `omodificari.vc2`, `actualizeaza_vanzari` si
|
|
`PACK_CONTAFIN` nu au fost atinse.
|