189 lines
11 KiB
Markdown
189 lines
11 KiB
Markdown
# Datoria 6 — ce s-a intamplat cu baza de regresie #6/S4 si cum a fost re-ancorata
|
|
|
|
09.08.2026. Schema `MARIUSM_AUTO@ROA_CENTRAL`. **Strict citiri pe Oracle** — nicio scriere, niciun
|
|
commit.
|
|
|
|
## 1. Ce s-a intamplat cu documentul (dovada pe randuri)
|
|
|
|
Ipoteza de plecare **se confirma**: documentul nu s-a pierdut, i s-a **realocat `cod`-ul**.
|
|
`ID_VANZARE = 1050` exista, e activ si nu si-a schimbat niciun total — doar `COD` a trecut de la
|
|
**1140888** la **1140895**.
|
|
|
|
```
|
|
ID_VANZARE COD STERS TIP NUMAR_ACT SERIE DATA_ACT ID_FACT TOTAL_CU_TVA
|
|
1050 1140895 0 1 547 SSS 07.08.2026 8009660 1924.59
|
|
1047 1140885 0 -12 544 SSS 07.08.2026 8009657 747.79
|
|
1048 1140894 0 1 545 SSS 07.08.2026 8009658 302.51
|
|
1049 1140887 0 1 546 SSS 07.08.2026 8009659 573.81
|
|
```
|
|
|
|
Pe intervalul 1140880-1140900 exista **doar** aceste 4 randuri; `max(cod)` in `VANZARI` e
|
|
**1140895**, `max(id_vanzare)` e **1050**. Nu exista niciun rand pe `cod = 1140888`.
|
|
|
|
Nota contabila arata acelasi lucru — acelasi antet, acelasi total, doar `STERS` si `COD` diferite:
|
|
|
|
```
|
|
COD AN LUNA STERS N NRACT SERIE DATAACT ID_FACT SUMA_TOT
|
|
1140888 2026 8 1 24 547 SSS 07.08.2026 8009660 4836.67
|
|
1140895 2026 8 0 24 547 SSS 07.08.2026 8009660 4836.67
|
|
```
|
|
|
|
24 de randuri vechi marcate `STERS=1` pe `cod` vechi, 24 de randuri noi active pe `cod` nou, cu
|
|
`nract`/`serie_act`/`dataact`/`id_fact` identice si aceeasi suma. Este exact semnatura lui
|
|
`finalizeaza_modificare_nota` + `pack_facturare.actualizeaza_vanzari(cod_vechi, cod_nou)`.
|
|
`VANZARI_DETALII` pe `id_vanzare = 1050` are in continuare **4 linii active** — neatins, corect
|
|
(scrierea in `VANZARI_DETALII` e S5, inca neimplementata).
|
|
|
|
**Cand**, pe secunda (`ACT.DATAORAS` = marcarea ca sters, `ACT.DATAORA` = crearea randului):
|
|
|
|
| Actiune | Moment |
|
|
|---|---|
|
|
| `cod=1140893` marcat sters, `cod=1140894` creat (`id_vanzare=1048`) | 08.08.2026 09:16:29 / 09:16:30 |
|
|
| `cod=1140888` marcat sters, `cod=1140895` creat (`id_vanzare=1050`) | 08.08.2026 14:05:15 / 14:05:16 |
|
|
|
|
Deci **nu** testul de write-back aprobat a mutat documentul de regresie: acela a lucrat pe
|
|
`id_vanzare = 1048` dimineata la 09:16 (`1140886 -> 1140893 -> 1140894`, consemnat in `progres.md`).
|
|
Mutarea lui `1050` e o **a doua salvare, la 14:05**, pe un alt document — cel folosit ca ancora de
|
|
regresie. Nu exista in `ACT` niciun `cod` intermediar intre 1140888 si 1140895 (1140889-1140892 n-au
|
|
randuri), deci a fost o singura realocare.
|
|
|
|
**Nimic de recreat.** Datele nu s-au pierdut; ancorarea suitelor era gresita. Prin urmare **nu se
|
|
cere nicio decizie de INSERT/UPDATE** din partea lui Marius pe partea de date.
|
|
|
|
Ancorele celorlalte cazuri sunt neatinse: `id_vanzare` 1047 (`cod=1140885`), 506 (`cod=1137874`),
|
|
882 (`cod=1139934`) sunt toate active pe acelasi `cod` ca inainte — se realoca doar documentele care
|
|
chiar se salveaza, adica cele din luna curenta, singurele care trec de garzile din
|
|
`do_editare_factura`.
|
|
|
|
## 2. Cifrele masurate azi, inainte de modificare
|
|
|
|
Cifra din `progres.md` (`7 PASS / 3 FAIL`) era **veche**: numara doar cele 10 asertii de la runda 2,
|
|
inainte ca blocul 3A sa adauge alte 5. Masurat azi, pe starea de pe disc:
|
|
|
|
| Suita | Inainte | Dupa |
|
|
|---|---|---|
|
|
| `test_page3_articole.prg` | **8 PASS / 7 FAIL** (15 verificari) | **13 PASS / 2 FAIL** |
|
|
| `test_incarca_vanzare_din_nota.prg` | **4 PASS / 1 FAIL** | **5 PASS / 5** |
|
|
|
|
Ambele rulari (inainte si dupa): `exit code 0`, **0 dialoguri native**, sub
|
|
`COMUN\utile\Teste\watchdog_vfp.ps1 -AutoDismiss` (care sterge `.fxp`-ul inainte de fiecare
|
|
lansare). `loForm.ClassLibrary` e asigurat de blocul existent
|
|
`RELEASE CLASSLIB omodificari` + `SET CLASSLIB TO D:\ROA\ROAFACTURARE\COMUN\clase\omodificari.vcx`,
|
|
neatins de modificarea de fata.
|
|
|
|
Motivul concret al esecurilor: `IncarcaCursoareModificareNota` filtreaza `STERS = 0`, iar toate cele
|
|
24 de randuri `ACT` de pe `cod=1140888` sunt `STERS=1` — deci `tact` venea **cu 0 randuri**, iar
|
|
suita nici nu ajungea sa instantieze formularul (`PageCount = -1` in log).
|
|
|
|
## 3. Ce s-a schimbat in suite si de ce
|
|
|
|
Principiul aplicat e **varianta 1 din brief**: suitele isi descopera singure documentul de test, dupa
|
|
**proprietatea ceruta de asertie**, nu dupa identitatea lui. Ancorarea pe `cod` era condamnata prin
|
|
constructie (se realoca la fiecare salvare); ancorarea pe `id_vanzare` ar fi rezistat, dar tot cere
|
|
un numar scris de mana intr-un fisier de test.
|
|
|
|
### Fisier nou: `COMUN\utile\Teste\editare_factura\descopera_caz_test.prg`
|
|
|
|
`DescoperaCazTest(<nume caz>, <alias>)` lasa in alias un rand cu `cod, an, luna, id_vanzare, tip,
|
|
nlin` si intoarce `.T.`/`.F.` Sase cazuri, fiecare o proprietate:
|
|
|
|
| Caz | Proprietatea ceruta | Rezolvat azi la |
|
|
|---|---|---|
|
|
| `FACTURA_ARTICOLE` | `tip=1` activa, cu linii active, a carei nota are **primul** rand (`min(id_act)`) pe acelasi `(nract, serie_act, dataact)` ca vanzarea | `cod=1140895`, `id_vanzare=1050`, 4 linii |
|
|
| `NEFACTURA_ARTICOLE` | la fel, dar `tip <> 1` (decizia 19 — detectia merge pe orice tip) | `cod=1140885`, `id_vanzare=1047`, `tip=-12` |
|
|
| `FARA_RULAJE` | linii active + **zero** randuri in `vrul_tot` si `vrul_obinv_tot` | `cod=1140885`, `id_vanzare=1047` |
|
|
| `PRIM_RAND_ORB` | nota al carei **prim** rand NU duce la vanzare, dar un triplet ulterior da | `cod=1140401`, `id_vanzare=1005` |
|
|
| `COLIZIUNE_COD` | idem + `cod` cu 2+ randuri active in `VANZARI` + un triplet din nota fara corespondent | `cod=1139934`, `id_vanzare=882`, `nract` fara corespondent = 13 |
|
|
| `NOTA_FARA_VANZARI` | nota activa fara rand in `VANZARI` pe **niciun** triplet | `cod=1140883`, an 2026, luna 7 |
|
|
|
|
Doua lucruri contau la proiectare:
|
|
|
|
- **Independenta fata de codul testat.** Interogarile merg pe `VACT_TOT` / `VRUL_TOT` /
|
|
`VRUL_OBINV_TOT` / `VANZARI` / `VANZARI_DETALII` cu join direct, adica pe **alt drum** decat
|
|
`IncarcaVanzareNota` / `IncarcaVanzareDinNota` / `IncarcaArticoleFactura`. Valoarea asteptata
|
|
(`id_vanzare`, `tip`, numarul de linii) nu vine de la functia verificata, deci asertia nu devine
|
|
tautologica.
|
|
- **Ordonare determinista** (`order by v.id_vanzare desc`, respectiv `an/luna/cod desc`), ca doua
|
|
rulari succesive pe aceleasi date sa aleaga acelasi document. Cazul ales e scris in log la
|
|
inceputul fiecarei rulari, ca sa se vada pe ce document s-a masurat.
|
|
- **Nicio potrivire = FAIL explicit**, nu test sarit: `caz_negasit` scrie in log
|
|
`niciun document din schema nu satisface conditia cazului` + `FAIL`.
|
|
|
|
Interogarile au fost validate intai direct in `sqlplus` (fiecare intoarce documentul asteptat), abia
|
|
apoi puse in cod.
|
|
|
|
### `test_page3_articole.prg`
|
|
|
|
Toate cele sase documente hardcodate (`1140888`, `1140885`, `1125486`, `1139934`, `1137874`) au fost
|
|
inlocuite cu cazul descoperit corespunzator. Structura asertiilor e neschimbata; procedurile de
|
|
verificare si-au pastrat corpul, doar au primit prin parametru ce inainte era scris in ele:
|
|
|
|
- `verifica_coliziune_cod` primea zero parametri si continea `1139934 / 375 / 'SSS' / 31.12.2021` si
|
|
`nract=13`; acum primeste `cod`, tripletul care **trebuie** gasit, `id_vanzare` asteptat si
|
|
**tripletul complet** care **nu trebuie** gasit. Descoperirea intoarce cele trei coloane ale
|
|
randului negativ de pe acelasi rand (`keep (dense_rank first order by nract)`), ca sa nu se combine
|
|
`nract`-ul unui rand cu `serie_act`-ul altuia — altfel asertia negativa ar fi trecut din alt motiv
|
|
decat cel testat.
|
|
- **O asertie s-a intarit, niciuna nu s-a slabit.** Cazul B (`tip <> 1`) trecea inainte cu
|
|
`tnLiniiAsteptate = -1`, adica verificarea numarului de linii era dezactivata; acum primeste
|
|
numarul real din `VANZARI_DETALII` (2) si il verifica.
|
|
|
|
### `test_incarca_vanzare_din_nota.prg`
|
|
|
|
Aceleasi patru cazuri, plus cazul EOF, trecute pe descoperire. Nicio schimbare de asertie.
|
|
|
|
## 4. Ce a ramas neacoperit
|
|
|
|
**Doua asertii din blocul 3A raman FAIL, si NU din cauza datelor** — sunt artefactul de mediu deja
|
|
consemnat ca datoria 7 in `progres.md`:
|
|
|
|
```
|
|
EROARE 1925 [VERIFICA_EDITARE_GRID:353] Unknown member COLUMN5.
|
|
structura grid/cursor (ColumnCount=14, lmodificat L, valoare N) = FAIL
|
|
ReadOnly (cantitate/pret/pret_cu_tva editabile, checkbox pe pret_cu_tva, restul readonly) = FAIL
|
|
stare initiala (lmodificat=.F., valoare calculata corect) = PASS
|
|
dupa editare cantitate (lmodificat=.T., valoare recalculata) = PASS
|
|
```
|
|
|
|
Sub `vfp9.exe -A -T` grid-ul nu se materializeaza: `ColumnCount` raporteaza `0` si `ColumnN` nu
|
|
exista ca membru, oricat de complet ar fi definita clasa. Repartitia 2 FAIL (structura, `ReadOnly`)
|
|
/ 2 PASS (cursor, calcul) e **exact** cea prezisa in `progres.md`, datoria 7 — deci suita e acum
|
|
inapoi la starea ei dinaintea degradarii bazei, nu mai bine si nu mai rau.
|
|
|
|
Cele doua asertii **nu au fost atinse, slabite sau sterse**. Ele sunt oricum acoperite corect pe
|
|
ecran de `COMUN\utile\Teste\editare_factura\test_ui_fix_editabil_subtotal.prg` sub
|
|
`vfp_ui_harness.ps1` (11/11 PASS, `ColumnCount=14`, consemnat in `progres.md`). Daca se doreste
|
|
curatarea zgomotului, varianta corecta e cea deja propusa la datoria 7 — rescrierea lor ca
|
|
verificare **statica** pe memo-ul `Properties` din `.vcx` — dar asta e alta lucrare, nu re-ancorare.
|
|
|
|
Altele:
|
|
|
|
- Nu s-a verificat comportamentul suitelor pe alta schema decat `MARIUSM_AUTO`. Descoperirea e
|
|
scrisa sa mearga pe orice schema, dar nu a fost probata pe `ROMFAST` sau `VENDING`.
|
|
- Cazurile `PRIM_RAND_ORB` si `NOTA_FARA_VANZARI` se rezolva azi la alte documente decat inainte
|
|
(`1140401` in loc de `1137874`, `1140883` in loc de `1125486`) — proprietatea testata e insa
|
|
aceeasi, iar ambele trec. Vechile documente raman valide, doar ca nu mai sunt primele in ordinea
|
|
determinista.
|
|
- Nu s-a atins nimic din `omodificari.vc2`, `ofacturare_comun.vc2`, `ofacturare_editare.prg` sau
|
|
binarele lor. `git status` in `COMUN` confirma: singurele fisiere de test schimbate sunt cele doua
|
|
suite plus fisierul nou.
|
|
|
|
## 5. Fisiere
|
|
|
|
| Fisier | Stare |
|
|
|---|---|
|
|
| `COMUN\utile\Teste\editare_factura\descopera_caz_test.prg` | **nou** |
|
|
| `COMUN\utile\Teste\editare_factura\test_page3_articole.prg` | modificat |
|
|
| `COMUN\utile\Teste\editare_factura\test_incarca_vanzare_din_nota.prg` | modificat |
|
|
| diff aplicat (sters) | diff-ul celor trei |
|
|
|
|
Comenzile de rulare:
|
|
|
|
```powershell
|
|
powershell -ExecutionPolicy Bypass -File D:\ROA\ROAFACTURARE\COMUN\utile\Teste\watchdog_vfp.ps1 -Script 'D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_page3_articole.prg' -AutoDismiss -TimeoutSec 300
|
|
powershell -ExecutionPolicy Bypass -File D:\ROA\ROAFACTURARE\COMUN\utile\Teste\watchdog_vfp.ps1 -Script 'D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_incarca_vanzare_din_nota.prg' -AutoDismiss -TimeoutSec 240
|
|
```
|
|
|
|
Logurile: `..._log.txt` langa fiecare suita; rezumatul watchdog-ului in
|
|
`COMUN\utile\Teste\editare_factura\watchdog_out\`.
|