Files
roafacturare/docs/cercetare/rec_s5_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

184 lines
9.9 KiB
Markdown

# S5 — testul cu scriere reala in Oracle. Rezultat
Aprobat de Marius (09.08.2026, consemnat in handoff intermediar (sters)). 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: diff aplicat (sters).
## 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.