367 lines
22 KiB
Markdown
367 lines
22 KiB
Markdown
# Verificare — alegerea stocului pe proforma (runda de verificare)
|
|
|
|
Investigatie read-only, 10.08.2026. Raspunde la 4 intrebari punctuale cerute de team-lead, pentru
|
|
decizia de proiectare S5b (comutare FACTURA <-> PROFORMA cu linii deja adaugate).
|
|
|
|
Continua fara sa reia: `s5b_proforma_descarcare_gestiune.md` (mecanismul `gestionabil=0` /
|
|
`id_gestiune=-1000`) si `s5b_proiectare_proforma_copiere.md` (proiectarea de runda 12, care a
|
|
descoperit deja ca `scrie_proforma` nu cheama `contabilizeaza_articol` deloc).
|
|
|
|
Nicio modificare de cod, niciun `git_sync.ps1`/`txt2vcx.ps1`, niciun commit, nicio scriere Oracle
|
|
(numai `SELECT`/`Read`/`Grep` pe fisiere de pe disc). Sursa Oracle folosita:
|
|
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql` (citat mai jos
|
|
`PACK:linie`).
|
|
|
|
**Status: COMPLET.**
|
|
|
|
---
|
|
|
|
## Rezumat executiv
|
|
|
|
1. **Da, pe calea principala si pe toate celelalte surse (cu exceptia copierii), stocul NU se
|
|
alege la adaugarea unei linii pe proforma azi** — pentru ca `gestionabil` a fost deja fortat pe
|
|
`0` in VFP, in masa, **inainte** ca gridul de linii sa se deschida. Cand ruleaza `Do Case`-ul de
|
|
la `ofacturare.vc2:13803`, `poArticol.gestionabil` e deja `0`, nu valoarea reala din nomenclator.
|
|
2. **Marcarea negestionabila are un singur mecanism activ azi, exclusiv in VFP**:
|
|
`UPDATE (m.lcCursor) SET gestionabil = 0` (`ofacturare.prg:333-336`), rulat in interiorul
|
|
functiei `factureaza()`, imediat dupa incarcarea cursorului candidat (`crsarticole`) si
|
|
**inainte** de construirea `crsfactura` (`creeaza_facturacrs`, linia 338) — adica la
|
|
**deschiderea documentului / incarcarea liniilor candidate**, nu la Termina/salvare. **Exista si
|
|
un al doilea mecanism, in Oracle**, in `cursor_retur_document` (`PACK:3993-4000`,
|
|
`CASE WHEN V_PROFORMA=1 THEN 0 ...`), dar acesta e **mort in fluxul curent**: `cursor_retur_document`
|
|
se cheama dintr-un singur loc (`ofacturare.prg:268`, ramura de copiere), cu
|
|
`V_PROFORMA = poDate.eProforma` **al documentului nou**, care e **intotdeauna 0** dupa copiere
|
|
(`nIdTipDoc` nu se propaga de la sursa, `ofacturare_comun.prg:370`) — deci ramura `V_PROFORMA=1`
|
|
nu se activeaza niciodata azi. **Nu e o contradictie intre cele doua rapoarte anterioare — sunt
|
|
doua mecanisme reale in cod, dar doar unul (cel VFP) e activ pe traseul de creare a unei
|
|
proforme; cel Oracle exista doar pentru copiere si acolo nu se declanseaza cu valoarea curenta a
|
|
parametrului.**
|
|
3. **`pret_achizitie` depinde de sursa**: pe calea principala (`cursor_preturi`, lista de preturi)
|
|
NU se completeaza deloc din cursor (coloana nici nu exista in `SELECT`-ul lui `cursor_preturi`)
|
|
— ramane `0`, prin acelasi tipar de valoare implicita ca la `id_gestiune` (`do_initializeaza_articol`).
|
|
Pe sursele care incarca dintr-un document existent (`cursor_avize`, `cursor_retur_document` —
|
|
avize si copiere), `PRET_ACHIZITIE` **e** selectat direct din `VANZARI_DETALII`, deci ajunge real.
|
|
4. **Daca proforma ar pastra `id_gestiune` real pana la salvare, nimic din contabilizare/stoc nu
|
|
s-ar strica** — pentru ca blocajul real nu e sentinela `-1000`, ci faptul ca `scrie_proforma`
|
|
(calea Oracle aleasa la Termina cand `eProforma=1`) **nu cheama niciodata**
|
|
`contabilizeaza_articol`/`descarca_gestiune` (confirmat deja in raportul-sursa de runda 12).
|
|
`adauga_articol_factura` (care ar primi `V_ID_GESTIUNE` real) **se cheama oricum**, neconditionat
|
|
de `eProforma`, pentru orice linie — deci un `id_gestiune` real ar ajunge fara probleme in
|
|
`VANZARI_DETALII_TEMP`/`VANZARI_DETALII`, fara sa declanseze nimic in plus. **`do_alege_stoc` nu
|
|
rezerva stoc real** — face doar un `SELECT` (cursoare `cursor_gestiuni_articol*`) si scade local,
|
|
in memorie, cantitatile deja puse pe documentul curent (`crsfactura`), ca operatorul sa nu aleaga
|
|
de doua ori acelasi lot; nu scrie nimic in Oracle. Deci lasarea lui `do_alege_stoc` sa ruleze pe
|
|
proforma nu ar bloca stoc pentru nimeni. Singurul risc real gasit e cel deja semnalat in
|
|
`s5b_proiectare_proforma_copiere.md` §5 (drumul invers, proforma -> factura in aceeasi sesiune),
|
|
care ramane valabil indiferent de aceasta decizie.
|
|
|
|
---
|
|
|
|
## Intrebarea 1 — se alege stocul la adaugarea unui articol pe proforma azi?
|
|
|
|
**Raspuns: NU, pe niciuna dintre caile de creare directa a unei proforme** (nu prin copiere).
|
|
|
|
### Calea principala — `cursor_preturi`
|
|
|
|
`cursor_preturi` (`PACK:2138-2646`) e apelat pentru `tnTip` in `{45, 1, 22, 5, 29, 7, 10, 23}`
|
|
(`ofacturare.prg:275-282` — lista de preturi, inclusiv `restaurant`), adica cea mai comuna sursa
|
|
pentru o proforma noua. SELECT-ul lui `cursor_preturi` intoarce `GESTIONABIL` ca
|
|
`C.IN_STOC AS GESTIONABIL` (`PACK:2192`, `:2297` — valoarea reala din `NOM_ARTICOLE`, fara nicio
|
|
constienta de proforma; `cursor_preturi` **nu are parametru** `V_PROFORMA`, confirmat prin grep pe
|
|
tot fisierul: `V_PROFORMA` apare doar la declaratia si corpul lui `cursor_retur_document`,
|
|
`PACK:408, 3939, 3944, 3952, 3957, 3994`).
|
|
|
|
Insa, imediat dupa ce acest cursor e adus in `crsarticole` in VFP, **inainte** ca operatorul sa
|
|
apuce sa vada gridul de linii:
|
|
|
|
```
|
|
COMUN\programe\ofacturare.prg:330-336
|
|
* Daca este o proforma, consider toate articolele negestionabile, pentru a nu mai alege din stoc
|
|
* 12.03.2021
|
|
IF poDate.eProforma = 1
|
|
UPDATE (m.lcCursor) SET gestionabil = 0
|
|
GO TOP IN (m.lcCursor)
|
|
ENDIF
|
|
```
|
|
|
|
`m.lcCursor` = `crsarticole` (setat la `:310`). Acest bloc ruleaza **dupa** `Do Case`-ul de
|
|
incarcare (`:266-308`) si **inainte** de `creeaza_facturacrs([crsfactura])` (`:338`) — adica la
|
|
compunerea listei de articole candidate, nu la salvare. Cand operatorul adauga o linie mai tarziu,
|
|
`Do Case`-ul care alege dialogul (`ofacturare.vc2:13803-13809`) citeste `poArticol.gestionabil`,
|
|
care e deja `0` pentru **toate** liniile candidate (setat in masa mai sus), deci intra pe ramura
|
|
`frm_articol_factura`, **niciodata** pe `Thisform.do_alege_stoc`.
|
|
|
|
### Celelalte cursoare (fara copiere)
|
|
|
|
Verificat direct in `PACK_FACTURARE`, niciunul din urmatoarele cursoare, folosite pentru celelalte
|
|
surse ale unei proforme noi, nu are parametru `V_PROFORMA` si nici nu calculeaza `GESTIONABIL` in
|
|
functie de proforma — toate intorc valoarea reala din nomenclator/contract:
|
|
|
|
| Cursor | Apelat pentru (`tnTip`) | `GESTIONABIL` in SELECT | Linie |
|
|
|---|---|---|---|
|
|
| `cursor_preturi` | 45,1,22,5,29,7,10,23 | `C.IN_STOC` | `PACK:2192,2297` |
|
|
| `cursor_contract` | 2,26,6,52 | `A.GESTIONABIL` (coloana reala) | `PACK:2411,2487,2572` |
|
|
| `cursor_comanda` | 3,21,25,28,42,47 | `E.IN_STOC` | `PACK:2789` |
|
|
| `cursor_lucrare` | 27 | `C.IN_STOC` | `PACK:3029` |
|
|
| `cursor_articole_k` | 48,49 | `C.IN_STOC` | `PACK:3117` |
|
|
| `cursor_avize` | 4 | `C.IN_STOC` | `PACK:3634` |
|
|
| `cursor_aviz_nir` | 30 | `0` (hardcodat) | `PACK:3745` |
|
|
| `cursor_gestiune` | 41 | `A.GESTIONABIL` | `PACK:4104` |
|
|
| `cursor_retur` | 8,9,24 | (nu are coloana `GESTIONABIL` separata — vezi nota) | `PACK:3934-3948` |
|
|
|
|
Pentru **toate** aceste surse, aceeasi bucla `ofacturare.prg:330-336` e singurul loc care forteaza
|
|
`gestionabil=0` cand `poDate.eProforma=1` — mecanismul e identic indiferent de sursa, pentru ca
|
|
`UPDATE (m.lcCursor) SET gestionabil = 0` ruleaza pe `crsarticole` dupa orice ramura a `Do Case`-ului
|
|
de la `:266-308`, nu doar pe ramura lista-de-preturi.
|
|
|
|
### Ramura de copiere — singura cu parametru `V_PROFORMA` in Oracle
|
|
|
|
`Case m.llCopiere` (`ofacturare.prg:267-268`) e **singura** ramura care apeleaza
|
|
`cursor_retur_document`, singurul cursor cu parametru `V_PROFORMA`. Insa la copiere, documentul nou
|
|
pleaca intotdeauna cu `eProforma=0` (`nIdTipDoc` explicit necopiat, `ofacturare_comun.prg:370` —
|
|
deja stabilit in `s5b_proiectare_proforma_copiere.md` §2.3), deci `V_PROFORMA` trimis e `0`, iar
|
|
ramura `GESTIONABIL = B.IN_STOC` (valoarea reala) se activeaza, nu `WHEN V_PROFORMA=1 THEN 0`. Asta
|
|
e comportamentul **corect si dorit** la copiere (liniile redevin gestionabile) — dar confirma ca
|
|
`V_PROFORMA=1` nu apare niciodata cu valoarea `1` in vreun apel real azi (vezi Intrebarea 2).
|
|
|
|
**Concluzie Intrebarea 1**: pe orice cale de creare directa a unei proforme (nu copiere), la
|
|
momentul `Do Case`-ului de adaugare a liniei (`ofacturare.vc2:13803`), `poArticol.gestionabil` e
|
|
deja `0` — fortat de VFP la incarcare, nu valoarea reala din nomenclator. `do_alege_stoc` nu ruleaza
|
|
niciodata pentru o linie noua adaugata sub `eProforma=1`, indiferent de sursa.
|
|
|
|
---
|
|
|
|
## Intrebarea 2 — unde exact se face marcarea negestionabila si CAND?
|
|
|
|
**Doua locuri in cod, dar un singur loc activ azi:**
|
|
|
|
### 2.1 VFP — activ, la incarcarea documentului (nu la salvare)
|
|
|
|
`COMUN\programe\ofacturare.prg:333-336`, in interiorul procedurii `factureaza()`. Secventa completa
|
|
in `factureaza()`:
|
|
|
|
1. `:266-308` — `Do Case` pe `tnTip`/`llCopiere`, alege cursorul Oracle si il aduce in `crsarticole`.
|
|
2. `:311` — `goExecutor.oExecute(lcSqlCursor, lcCursor)` — executa efectiv apelul Oracle.
|
|
3. `:324-336` — daca sunt randuri, **si daca `poDate.eProforma = 1`**: `UPDATE crsarticole SET gestionabil = 0`.
|
|
4. `:338` — abia acum `creeaza_facturacrs([crsfactura])` construieste cursorul gol de linii ale
|
|
documentului; liniile candidate (`crsarticole`, deja marcate) raman disponibile pentru ca
|
|
operatorul sa aleaga din ele.
|
|
|
|
Acest pas ruleaza **la deschiderea ecranului de adaugare articole**, mult inainte de `Termina`
|
|
(`do_scrie_factura`, apelat doar la click pe butonul de finalizare — vezi 2.3 mai jos). Nu exista
|
|
niciun `UPDATE`/`REPLACE gestionabil With 0` la salvare in `do_scrie_factura` sau `do_scrie_articole`
|
|
— am cautat explicit `gestionabil` in ambele metode (`ofacturare.vc2:14197-14380`,`:13967-14150`) si
|
|
singura referinta la `gestionabil` in acea zona e citirea lui la `Do Case`-ul din `:13803` (decizia
|
|
de dialog), nu o scriere.
|
|
|
|
### 2.2 Oracle — exista in cod, dar mort in fluxul curent
|
|
|
|
`cursor_retur_document` (`PACK:3949-4064`), branch la `PACK:3993-4000`:
|
|
```sql
|
|
(case
|
|
when V_PROFORMA = 1 then 0
|
|
when V_COPIERE = 1 then B.IN_STOC
|
|
else A.GESTIONABIL
|
|
end) AS GESTIONABIL,
|
|
```
|
|
cu comentariu explicit in cod: `-- V_PROFORMA: Daca este proforma (1), fac articolele negestionabile
|
|
sa pot alege orice cantitate` (`PACK:3957`). Acest cod **exista si e corect scris**, dar
|
|
`cursor_retur_document` are un singur punct de apel in tot codul VFP (confirmat prin cautare in
|
|
`ofacturare.prg`, singura potrivire e la `:268`; potrivirile suplimentare gasite in
|
|
`COMUN\.svn\pristine\*` sunt copii istorice ale **aceleiasi** linii, nu apeluri suplimentare), si
|
|
acolo `V_PROFORMA` trimis e `poDate.eProforma` **al documentului nou** din copiere, care e
|
|
intotdeauna `0` (Intrebarea 1). **Deci acest branch Oracle nu se activeaza niciodata cu valoarea 1
|
|
in fluxul curent** — e cod mort din perspectiva efectului observabil, desi sintactic corect si
|
|
prezent.
|
|
|
|
### 2.3 Clarificare pe "inainte de compunerea documentului" vs. "la salvare"
|
|
|
|
Formularea raportului de runda 9 ("VFP marcheaza toate liniile proformei negestionabile inainte de
|
|
compunerea documentului") e **corecta** — "compunerea documentului" inseamna acolo constructia
|
|
listei de articole candidate/`crsfactura` (pasul 4 de mai sus), care se intampla la
|
|
**deschiderea** ecranului de facturare, nu la apasarea `Termina`. Nu exista o contradictie reala cu
|
|
mentiunea `V_PROFORMA` din `cursor_retur_document` din brief — acel `CASE` Oracle e un mecanism
|
|
separat, pentru un cursor diferit (candidati la copiere), care azi nu se declanseaza niciodata cu
|
|
`V_PROFORMA=1`. Ambele afirmatii din surse sunt adevarate simultan, pentru ca descriu lucruri
|
|
diferite.
|
|
|
|
**Concluzie Intrebarea 2**: singurul mecanism activ e `UPDATE` de masa in VFP
|
|
(`ofacturare.prg:333-336`), care ruleaza in `factureaza()`, la incarcarea/compunerea listei de
|
|
articole candidate — **cu mult inainte** de `Termina`/`do_scrie_factura`. Mecanismul Oracle din
|
|
`cursor_retur_document` exista in cod dar nu se activeaza cu valoarea curenta a parametrilor.
|
|
|
|
---
|
|
|
|
## Intrebarea 3 — se completeaza `pret_achizitie` pe liniile de proforma?
|
|
|
|
**Depinde strict de sursa cursorului, la fel ca la `gestionabil` — dar cu rezultat opus pentru
|
|
calea principala.**
|
|
|
|
### Ce cursoare selecteaza `PRET_ACHIZITIE`
|
|
|
|
Cautare directa in `PACK_FACTURARE` (`grep PRET_ACHIZITIE`): coloana **nu apare deloc** in
|
|
`cursor_preturi` (`PACK:2138-2646`), `cursor_contract` (`:2646-2952`), `cursor_comanda`
|
|
(`:2952-3173`), `cursor_lucrare` (`:3173-3595`), `cursor_articole_k` (`:3595-3703`),
|
|
`cursor_gestiune` (`:4158-4349`). Apare doar in:
|
|
- `cursor_avize` (in jurul liniilor `PACK:3754-3864` — sursa `VANZARI_DETALII`/`RUL`, articol
|
|
provenit dintr-un aviz existent);
|
|
- `cursor_retur_document` (`PACK:4026`, `A.PRET_ACHIZITIE` direct din `VANZARI_DETALII`, folosit la
|
|
copiere).
|
|
|
|
### Ce se intampla in VFP cand lipseste
|
|
|
|
`crsfactura` (structura din `creeaza_facturacrs`, `ofacturare_comun.prg:1777`) are un camp
|
|
`pret_achizitie` in schema — dar o linie noua nu se construieste prin copiere in masa din
|
|
`crsarticole`, ci prin `Scatter`/`Gather` pe obiectul `poArticol`, populat cand utilizatorul alege un
|
|
articol din grid. `do_initializeaza_articol` (`ofacturare.vc2:13715-13719`), apelat pentru orice
|
|
linie care trece prin `frm_articol_factura` (ramura negestionabila, deci si orice linie de
|
|
proforma):
|
|
```
|
|
If Type('toArticol.pret_achizitie')="U"
|
|
AddProperty(toArticol,'pret_achizitie',0)
|
|
Endif
|
|
If Isnull(toArticol.pret_achizitie)
|
|
toArticol.pret_achizitie = 0
|
|
Endif
|
|
```
|
|
Deci: **pe calea principala (lista de preturi), `pret_achizitie` ramane `0`** pe liniile de proforma
|
|
— campul nici nu exista in `crsarticole` sursa (cursorul Oracle nu-l selecteaza), asa ca proprietatea
|
|
lipseste pe `poArticol` si `do_initializeaza_articol` o creeaza cu valoare implicita `0`, exact
|
|
acelasi tipar defensiv folosit pentru `id_gestiune=-1000` (aceeasi metoda, linii apropiate,
|
|
`:13618-13623` vs `:13715-13719`).
|
|
|
|
**Pe sursele care carata un document existent** (`cursor_avize`, si `cursor_retur_document` la
|
|
copiere), `pret_achizitie` **e** populat real din `VANZARI_DETALII.PRET_ACHIZITIE` a documentului
|
|
sursa, deci proprietatea exista pe `poArticol` si `do_initializeaza_articol` nu o suprascrie.
|
|
|
|
### Unde ajunge
|
|
|
|
Indiferent de valoare (`0` sau reala), `poArt.pret_achizitie` merge neschimbat catre Oracle ca
|
|
parametru pozitional in apelul catre `adauga_articol_factura`:
|
|
```
|
|
ofacturare.vc2:14073
|
|
... + Alltrim(Str(poArt.pret_achizitie,18,gnPPret)) + [,] + ...
|
|
```
|
|
primit ca `V_PRET_ACHIZITIE_TEMP` (`PACK:4995`), copiat direct `V_PRET_ACHIZITIE := V_PRET_ACHIZITIE_TEMP`
|
|
(`PACK:5031`, fara sentinela, spre deosebire de `id_gestiune`) si scris ca atare in
|
|
`VANZARI_DETALII_TEMP.PRET_ACHIZITIE` (`PACK:5229/5259`), apoi in `VANZARI_DETALII` la
|
|
`scrie_in_vanzari`.
|
|
|
|
**Concluzie Intrebarea 3**: pe calea principala (lista de preturi), `pret_achizitie` ramane `0` pe
|
|
liniile de proforma — nu vine din `do_alege_stoc` (care nu ruleaza) si nici din cursorul Oracle (care
|
|
nu-l selecteaza pe aceasta ramura). Pe sursele avize/copiere, valoarea reala din documentul sursa se
|
|
pastreaza.
|
|
|
|
---
|
|
|
|
## Intrebarea 4 — ce s-ar strica daca proforma ar pastra gestiunea reala pana la salvare?
|
|
|
|
### 4a. `adauga_articol_factura` se cheama si pentru liniile de proforma?
|
|
|
|
**Da, neconditionat.** `do_scrie_factura` (`ofacturare.vc2:14197+`) cheama
|
|
`Thisform.do_scrie_articole()` la linia **14264**, **inainte** de `Do Case poDate.eProforma = 1`
|
|
(care alege intre `scrie_proforma` si `scrie_factura2`, la `:14282`):
|
|
```
|
|
ofacturare.vc2:14264
|
|
llReturn = Thisform.do_scrie_articole() && se deschide tranzactie manuala
|
|
...
|
|
ofacturare.vc2:14282
|
|
Do Case
|
|
Case poDate.eProforma = 1
|
|
* scrie_proforma are aceiasi parametri ca scrie_factura2
|
|
* salveaza doar in vanzari, nu si in contabilitate
|
|
lcSql = [{call pack_facturare.scrie_proforma(...)}]
|
|
```
|
|
`do_scrie_articole` parcurge liniile din `crsfactura` si cheama `adauga_articol_factura` pentru
|
|
fiecare (`ofacturare.vc2:14069-14073`, deja citat in raportul-sursa) — **acelasi cod, indiferent de
|
|
`eProforma`**. Daca `poArt.id_gestiune` ar fi real (nu `-1000`), `adauga_articol_factura` l-ar
|
|
traduce direct in `V_ID_GESTIUNE2 := V_ID_GESTIUNE` (`PACK:5032-5034`, gate-ul `<> -1000`) si l-ar
|
|
scrie ca atare in `VANZARI_DETALII_TEMP.ID_GESTIUNE` (`PACK:5237,5267`), apoi in
|
|
`VANZARI_DETALII.ID_GESTIUNE` la `scrie_in_vanzari` (`INSERT INTO VANZARI_DETALII SELECT FROM
|
|
VANZARI_DETALII_TEMP`, fara nicio conditie suplimentara pe `id_gestiune`).
|
|
|
|
### 4b. Are efect ca linia sa ramana cu `ID_GESTIUNE` completat, cata vreme `scrie_proforma` nu cheama `contabilizeaza_articol`?
|
|
|
|
**Niciunul, pe partea de contabilizare/descarcare.** Confirmat deja (runda 12,
|
|
`s5b_proiectare_proforma_copiere.md`, sectiunea "Descoperire centrala"): `scrie_proforma`
|
|
(`PACK:5637-5671`) cheama **doar** `scrie_in_vanzari` — insereaza antetul si liniile ca atare, apoi
|
|
seteaza `VANZARI.EPROFORMA=1`. **Nu cheama** `contabilizeaza_articol` in niciun caz. Sentinela
|
|
`-1000` conteaza doar **in interiorul** lui `contabilizeaza_articol` (`PACK:7472-7476`), care nu
|
|
ruleaza deloc pentru `scrie_proforma`. Deci `ID_GESTIUNE` real pe o linie de proforma nu ar declansa
|
|
`descarca_gestiune`, nu ar genera `NOTE_CONTABILE`, nu ar atinge `RUL`/`STOC` — pentru ca intreaga
|
|
functie care ar face asta nu se executa pe traseul `scrie_proforma`.
|
|
|
|
### 4c. Rapoarte/view-uri care citesc `ID_GESTIUNE` pe documente `eProforma=1` si ar arata altceva?
|
|
|
|
Cautare `eproforma` (case-insensitive) in tot `PACK_FACTURARE`: doar 3 potriviri, toate in
|
|
`scrie_proforma`/comentarii (`PACK:1408, 5666, 5668`) — nicio alta procedura/vedere din pachet nu
|
|
filtreaza sau calculeaza dupa `EPROFORMA`.
|
|
|
|
Pe partea VFP, `crsDetaliiListare` (folosit la **relistarea** unui document deja emis, inclusiv
|
|
proforma — `oproceduri_facturare.prg:1111-1126`, sursa `fact_vfacturi2`) **include** coloana
|
|
`id_gestiune` in schema si in `SELECT`, indiferent de `eproforma` (nu exista filtru pe
|
|
`eproforma` in acest `SELECT`). Deci daca `ID_GESTIUNE` ar fi real pe o proforma, acest cursor l-ar
|
|
citi ca atare la relistare — azi citeste `NULL`. **Nu am putut confirma daca vreun raport `.frx`
|
|
tiparit efectiv afiseaza `id_gestiune`/`nume_gestiune` pe documentul proforma insusi**
|
|
(rapoartele `PROFORMA`/`PROFORMA_VAL` nu au versiune text `.fr2` generata in `Rapoarte\`, deci nu
|
|
s-au putut grep-ui direct) — de regula gestiunea e un camp intern, nu unul tiparit pe un document
|
|
comercial, dar afirmatia ramane neconfirmata pe cod, nu doar presupusa corecta. Vezi "Ce nu s-a
|
|
putut stabili".
|
|
|
|
### 4d. `do_alege_stoc` rezerva stoc sau doar alege?
|
|
|
|
**Doar alege — nu scrie nimic in Oracle.** Corpul complet al `do_alege_stoc`
|
|
(`ofacturare.vc2:13200-13400+`) face exclusiv: (1) un `SELECT` prin
|
|
`cursor_gestiuni_articol`/`cursor_gestiuni_articol_retur`/`cursor_gestiuni_articol_stoc0` (toate
|
|
proceduri read-only, populeaza un cursor local `crsgestarticoltemp`), (2) o scadere **locala, in
|
|
memorie**, a cantitatilor deja adaugate pe **acelasi document, in aceeasi sesiune**
|
|
(`ofacturare.vc2:13273-13311`: `SELECT ... FROM crsfactura ... INTO CURSOR crsFacturaArticoleTemp`,
|
|
apoi `a.cantitate - Nvl(b.cantitate,0)` la afisare), ca sa nu i se ofere operatorului sa aleaga de
|
|
doua ori acelasi lot pe acelasi document. **Nu exista niciun `INSERT`/`UPDATE` catre Oracle in
|
|
aceasta metoda** — `goExecutor.oExecute` apare o singura data, pentru `SELECT`-ul de la pasul (1).
|
|
Blocarea/decrementarea reala a stocului se intampla abia la `descarca_gestiune`
|
|
(`PACK:7648-7797`), apelata doar din `contabilizeaza_articol`, care (per 4b) nu ruleaza niciodata
|
|
pentru `scrie_proforma`. **Deci chiar daca `do_alege_stoc` ar rula pe liniile unei proforme, nu ar
|
|
"tine" stoc blocat pentru nimeni** — nu exista mecanism de rezervare reala in aplicatie pe acest
|
|
traseu, doar o verificare locala de neduplicare in sesiunea curenta.
|
|
|
|
**Concluzie Intrebarea 4**: nimic din contabilizare, descarcare de gestiune sau stoc real nu s-ar
|
|
strica daca proforma ar pastra `id_gestiune` real pana la salvare — blocajul functional e la nivelul
|
|
routing-ului `scrie_proforma` (care nu cheama `contabilizeaza_articol`), nu la nivelul sentinelei
|
|
`-1000`. Singurul loc unde s-ar vedea o diferenta reala e la **relistarea** documentului
|
|
(`crsDetaliiListare`/`fact_vfacturi2`), unde `id_gestiune` ar aparea completat in loc de `NULL` —
|
|
efect cosmetic/informational, nu unul care sa afecteze stocul sau contabilitatea, cu rezerva ca nu
|
|
s-a confirmat daca vreun `.frx` chiar il tipareste. Riscul real ramas e cel deja identificat in
|
|
`s5b_proiectare_proforma_copiere.md` §5 (drumul invers, proforma comutata inapoi in factura in
|
|
aceeasi sesiune, inainte de Termina) — acela nu se schimba, indiferent de aceasta decizie, pentru ca
|
|
depinde de routing-ul de la Termina, nu de momentul in care se alege gestiunea.
|
|
|
|
---
|
|
|
|
## Ce nu s-a putut stabili
|
|
|
|
1. **Daca vreun raport `.frx` tiparit (PROFORMA/PROFORMA_VAL) afiseaza efectiv `id_gestiune` sau
|
|
`nume_gestiune` pe documentul insusi** — rapoartele nu au versiune text `.fr2` generata in
|
|
`Rapoarte\`, asa ca nu s-a putut grep pe continutul lor; ar necesita fie generarea textului cu
|
|
`git_sync.ps1`/`foxbin2prg` (in afara mandatului read-only), fie deschidere in IDE VFP.
|
|
2. **Nu s-a rulat nimic pe date vii** — toata analiza e trasare de cod static (VFP text + PL/SQL
|
|
text), conform mandatului read-only.
|
|
3. **Cautarea "eproforma" in Oracle** a acoperit doar `PACK_FACTURARE` — nu s-au verificat alte
|
|
pachete/view-uri/rapoarte Oracle care ar putea referi `VANZARI.EPROFORMA` impreuna cu
|
|
`ID_GESTIUNE` (de exemplu rapoarte de gestiune/stoc din alte module ROA). Zero rezultate in
|
|
`PACK_FACTURARE` nu e dovada de completitudine pentru intreaga schema.
|
|
4. **`cursor_retur`** (`PACK:3934-3948`, folosit pentru `tnTip` 8,9,24 — retururi) nu a fost citit
|
|
integral pentru coloana `GESTIONABIL` (tabelul de la Intrebarea 1 il listeaza fara valoare
|
|
confirmata) — nu are parametru `V_PROFORMA` (confirmat prin grep), deci concluzia generala
|
|
(marcarea vine doar din VFP) ramane valabila, dar valoarea exacta intoarsa de coloana nu a fost
|
|
verificata linie-cu-linie.
|
|
|
|
---
|
|
|
|
## Handoff
|
|
|
|
Cercetare incheiata intr-o singura sesiune, fara sa fie nevoie de predare de context. Toate cele 4
|
|
intrebari din brief au raspuns cu dovada `fisier:linie`, plus rezumatul executiv de mai sus. Niciun
|
|
fisier de cod atins, niciun `git_sync.ps1`/`txt2vcx.ps1` rulat, niciun commit, nicio scriere pe
|
|
Oracle.
|