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
80 lines
3.9 KiB
Markdown
80 lines
3.9 KiB
Markdown
# Cercetare: de unde se citesc `id_set` / `id_fact` / `id_factd` in `do_editare_factura`
|
|
|
|
Context: decizia 24 din `docs\progres.md` cere **scoaterea completa** a garzii pe `id_set` adaugata in
|
|
runda 3, cu avertismentul ca pozitionarea din care se citesc `id_fact`/`id_factd` nu are voie sa cada
|
|
pe un rand de discount. Nota de fata verifica premisa pe date si stabileste pozitionarea corecta.
|
|
|
|
Sursa: `MARIUSM_AUTO@ROA_CENTRAL`, 08.08.2026, interogari directe pe `ACT` si `VANZARI`.
|
|
|
|
## 1. Premisa "randurile de discount au `ID_FACT = -1`" **nu se confirma in `ACT`**
|
|
|
|
Distributia `ACT.ID_FACT` pe toata tabela:
|
|
|
|
| valoare | randuri | ani |
|
|
|---|---|---|
|
|
| pozitiv | 66360 | 0-2026 |
|
|
| negativ | 32 | 2008-2019 |
|
|
| NULL | 0 | — |
|
|
| zero | 0 | — |
|
|
|
|
Zero randuri cu `id_fact <= 0` din 2020 incoace. `ACT.ID_FACTD` nu e niciodata NULL (65849 de zerouri,
|
|
541 pozitive, 2 negative in 2006).
|
|
|
|
Pe cele 27 de note cu randuri `DISCOUNT` / `TVA DISCOUNT`: randurile de discount au **acelasi
|
|
`id_fact` si acelasi `id_set`** ca restul notei, si `id_factd = 0`. Coerent cu decizia 24 —
|
|
`cumuleaza_note_act_temp` normalizeaza inainte de `ACT`; `-1` din `scrie_discount` nu ajunge acolo.
|
|
|
|
**Concluzie**: randul de discount nu e periculos. Constatarea din `rec_garda_idset.md` pct. 1 era
|
|
corecta pe sursa PL/SQL, dar valorile nu supravietuiesc pana in `ACT`.
|
|
|
|
## 2. Randul periculos e **INCASAREA**, si problema e reala
|
|
|
|
Note legate de `VANZARI` cu mai multe `id_fact` distincte: **78**. Tiparul, verificat pe exemple:
|
|
primul rand dupa `id_act` este `INCASARE` / `INCASARE NUMERAR`, cu `id_fact` = `id_fact`-ul facturii
|
|
**minus 1** (chitanta isi are propriul `id_fact`, alocat inaintea facturii).
|
|
|
|
```
|
|
COD TIP AN LUNA VANZARI.ID_FACT primul rand ACT explicatia
|
|
1137874 44 2009 8 5040267 5040266 INCASARE
|
|
1138549 1 2014 1 8001118 8001117 INCASARE NUMERAR
|
|
```
|
|
|
|
**39 de facturi** in schema de dev pe care un `Go Top` orb pe `actactan` (ordonat dupa `id_act`)
|
|
preia `id_fact`-ul **chitantei**, nu al facturii. E comportamentul codului din runda 1/2, nu ceva
|
|
introdus de runda 3.
|
|
|
|
Pe 38 din cele 39, `VANZARI.ID_FACT` **exista** ca `id_fact` pe cel putin un rand al notei, deci o
|
|
pozitionare `Locate For id_fact = <id_fact-ul din crsfacturi>` il gaseste. Al 39-lea e un rand vechi
|
|
fara corespondent.
|
|
|
|
## 3. Cat conteaza fiecare valoare, la destinatie
|
|
|
|
`PACK_CONTAFIN.finalizeaza_modificare_nota` (`COMUN\docs\PACK_CONTAFIN.pck:8601-8651`):
|
|
|
|
- `tnIdSet` — conduce `CASE`-ul; pentru facturi (25xxx) cade pe `ELSE`, deci nu face nimic in plus
|
|
fata de `actualizeaza_vanzari`;
|
|
- `tnIdFact` — folosit **doar** pe ramura `tnIdSet IN (31003, 31004, 31005, 31011)`:
|
|
`UPDATE NOM_LUCRARI SET ID_FACT = tnIdFact ... WHERE ID_FACT IS NULL`. Ramura e **vie** si pentru
|
|
documente din `VANZARI`: 35 de note cu `id_set = 31011`, 5 cu `31003`, 1 cu `31005`. Semantic
|
|
trebuie sa fie `id_fact`-ul **facturii**, adica exact `VANZARI.ID_FACT`;
|
|
- `tnIdFactD` — apare doar in cod comentat (ramurile 90011/90013). Azi e **complet nefolosit**.
|
|
|
|
## 4. `id_set` unic pe nota — confirmat
|
|
|
|
Note legate de `VANZARI`, dupa numarul de `id_set` distincte: **558 cu unul singur**, 1 cu doua — si
|
|
aceea e randul-gunoi `cod = 0, an = 0, luna = 0` (`id_set` 46 si 10208), nu o factura. Decizia 24 se
|
|
confirma pe date; garda din runda 3 poate iesi fara inlocuitor.
|
|
|
|
## 5. Pozitionarea corecta
|
|
|
|
`lnIdFact` e deja citit corect din `crsfacturi` (`VANZARI.ID_FACT`) la inceputul metodei si folosit
|
|
pentru garda eFactura. Nu trebuie rescris din `actactan` — poate doar sa se strice. Deci:
|
|
|
|
- se cauta in `actactan` randul cu `id_fact = lnIdFact`; daca se gaseste, de acolo se iau `id_set` si
|
|
`id_factd`;
|
|
- daca `lnIdFact` nu e utilizabil (0/NULL — 283 de randuri `VANZARI` au `ID_FACT` NULL, in principal
|
|
avize si transferuri) sau nu are corespondent in nota, se cade pe `Go Top` si se ia `id_fact` de
|
|
acolo, ca inainte.
|
|
|
|
Fara garda, fara mesaj de refuz.
|