516 lines
37 KiB
Markdown
516 lines
37 KiB
Markdown
# Exista un canal fara politica de pret catre ACT_TEMP.SCC? (proiect #13)
|
|
|
|
Cercetare read-only. Continua `cont_venit_articol_fara_politica.md`, `nota_contabila_fara_politica.md`,
|
|
`coresp_cont_venchelt.md`, `verif_baza_vie_cont_venit.md`.
|
|
|
|
**Mandat schimbat pe parcurs — vezi sectiunea imediat de mai jos.** Sectiunile de la
|
|
"Verdict, in cinci randuri" incolo sunt cercetarea rundei cu mandatul vechi ("gaseste un canal
|
|
ocolitor, nu se atinge `pack_facturare`") si raman ca input de proiectare (harta intrarilor spre
|
|
`SCD`/`SCC`, DDL, ce face `V_CONT`) — nu mai sunt raspunsul principal.
|
|
|
|
**HANDOFF (predare de context, nu sarcina noua):** o a treia sarcina a fost primita de la team-lead
|
|
dupa livrarea proiectarii de mai jos — verificarea celor 37 de linii de comanda cu articol nemembru
|
|
al politicii lor (proiectul #13, decizia 32). **Nu a fost inceputa** — sesiunea a evaluat contextul
|
|
consumat pana la acel punct ca fiind aproape de pragul de predare (lectura extinsa de rapoarte mari +
|
|
export Oracle in aceasta sesiune) si a predat inainte de a deschide o interogare noua, conform Regula
|
|
zero. Livrabilul cerut pentru acea sarcina e alt fisier,
|
|
`docs\cercetare\linii_comanda_articol_nemembru.md` — **neinceput, nescris**. Nimic din
|
|
sesiunea curenta nu e intr-o stare periculoasa: doar `SELECT`-uri Oracle rulate (toate terminate),
|
|
niciun fisier de cod atins, niciun proces/tranzactie ramas deschis. Urmatorul agent poate porni
|
|
curat pe sarcina celor 37 de linii, cu contextul din mesajul team-lead-ului (re-confirma cifra,
|
|
extrage cele 37 de linii cu id_comanda/id_articol/id_pol/data/stare facturare, verifica daca vreuna
|
|
s-a facturat fara eroare, cauza daca se poate citi din audit, si validarea pe cod a conditiei
|
|
FACT-024 aplicata pe forma lor).
|
|
|
|
---
|
|
|
|
## Proiectarea parametrului de cont contabil (mandat nou, Marius 10.08.2026)
|
|
|
|
Marius a autorizat explicit modificarea punctuala a `pack_facturare` ("poți să adaugi parametrul
|
|
contul contabil la `contabilizeaza_articol`") — decizia 27-bis e relaxata. **Aceasta e o proiectare,
|
|
nu o implementare — niciun fisier de cod nu a fost atins.** Sursa Oracle:
|
|
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql` (17217 linii,
|
|
verificat `wc -l`); toate liniile citate mai jos sunt din **acest fisier**, citite direct in aceasta
|
|
runda (nu preluate din rapoarte anterioare).
|
|
|
|
### Verdict proiectare, in sase randuri
|
|
|
|
**Fezabil, cu o precizare importanta fata de formularea lui Marius**: `contabilizeaza_articol`
|
|
primeste azi un **singur parametru**, `detalii_articol VANZARI_DETALII_TEMP%ROWTYPE` — un rand
|
|
intreg, nu o lista de scalari. Deci "parametrul de cont" **nu intra ca parametru nou pe
|
|
`contabilizeaza_articol` insasi** (asta ar fi cosmetic, fara efect, pentru ca cei 3 apelanti interni
|
|
ii dau deja randul intreg dintr-un `TABLE OF VANZARI_DETALII_TEMP%ROWTYPE`) — intra pe drumul real:
|
|
**o coloana noua pe `VANZARI_DETALII_TEMP`, populata printr-un parametru nou pe
|
|
`adauga_articol_factura`** (procedura chemata direct din VFP), pe care `contabilizeaza_articol` o
|
|
citeste automat prin `detalii_articol.<coloana>`, **fara nicio modificare la `scrie_factura2`,
|
|
`scrie_factura_avize_retur` sau `scrie_aviz_retur`**. Efectul practic e exact ce a cerut Marius — un
|
|
cont de venit calculat de VFP ajunge in `ACT_TEMP.SCC` fara politica — doar mecanica de livrare e
|
|
alta decat "parametru pe `contabilizeaza_articol`" literal. Restul (SCD, CU_TVA, IN_VALUTA,
|
|
EXPLICATIE, ID_VENCHELT, ID_SECTIE, `descarca_gestiune` o singura data, FACT-024 ocolit doar pe
|
|
ramura noua) au surse identificate mai jos, cu 2 hardcodari explicite care cer confirmarea lui
|
|
Marius (`SCD='4111'`, `CU_TVA=1`).
|
|
|
|
### 1. Lantul real de apel — de ce parametrul trebuie sa intre pe `adauga_articol_factura`, nu pe `contabilizeaza_articol`
|
|
|
|
```
|
|
ff_...:7173 FUNCTION contabilizeaza_articol(detalii_articol VANZARI_DETALII_TEMP%ROWTYPE) RETURN NUMBER IS
|
|
```
|
|
|
|
Singurul parametru. Apelata de exact **3 locuri**, toate interne pachetului, toate ii dau un element
|
|
dintr-un array populat integral din tabel:
|
|
|
|
```
|
|
ff_...:6039-6040 TYPE tab_detalii_type IS TABLE OF vanzari_detalii_temp%ROWTYPE;
|
|
tab_detalii tab_detalii_type;
|
|
ff_...:6063 SELECT * BULK COLLECT INTO tab_detalii FROM VANZARI_DETALII_TEMP;
|
|
ff_...:6141 V_INCASAT_CALCUL := V_INCASAT_CALCUL + pack_facturare.contabilizeaza_articol(tab_detalii(i)); -- scrie_factura2
|
|
ff_...:6858 pack_facturare.contabilizeaza_articol(tab_detalii(i)); -- scrie_factura_avize_retur
|
|
ff_...:7140 pack_facturare.contabilizeaza_articol(tab_detalii(i)); -- scrie_aviz_retur
|
|
```
|
|
|
|
`SELECT * BULK COLLECT` (nu o lista explicita de coloane) inseamna: **orice coloana noua adaugata pe
|
|
`VANZARI_DETALII_TEMP` ajunge automat in `tab_detalii(i)` si deci in `detalii_articol` in
|
|
`contabilizeaza_articol`, fara sa atingi aceste 3 proceduri.** Asta e drumul cu cea mai mica
|
|
suprafata de risc posibila — nu exista un drum mai mic care sa duca un cont calculat de VFP pana in
|
|
`contabilizeaza_articol`.
|
|
|
|
Intrarea reala din VFP e `adauga_articol_factura` (nu `contabilizeaza_articol`):
|
|
|
|
```
|
|
ff_...:4989-5015 PROCEDURE adauga_articol_factura(V_ID_TEMP IN NUMBER,
|
|
V_ID_ARTICOL IN NUMBER,
|
|
... (23 parametri) ...
|
|
V_ID_UTIL IN NUMBER,
|
|
V_TAXCODE IN NUMBER DEFAULT NULL,
|
|
V_LOT IN VARCHAR2 DEFAULT NULL) IS
|
|
```
|
|
|
|
**Precedent direct pentru "adauga parametru nou la coada, cu `DEFAULT NULL`"**: `V_TAXCODE` si
|
|
`V_LOT` sunt deja exact asta — doi parametri adaugati ulterior, la finalul listei, cu `DEFAULT NULL`,
|
|
fara sa oblige la rescrierea apelantilor existenti. Propunerea de mai jos repeta acelasi tipar, nu
|
|
inventeaza unul nou.
|
|
|
|
Apelantul VFP confirmat (singurul gasit in sursa, dublat identic in doua locuri din aceeasi clasa —
|
|
vezi "Ce nu s-a putut stabili"):
|
|
|
|
```
|
|
COMUN\clase\ofacturare.vc2:14069-14091 (si identic la :18089-18114)
|
|
lcSql = lcSql + [pack_facturare.adauga_articol_factura(] + Alltrim(Str(poArt.id_temp)) + [,] + ;
|
|
... (pozitional, 26 de argumente) ... + ;
|
|
NVL(ALLTRIM(STR(poArt.taxcode)),[NULL]) + ;
|
|
[,'] + OracleSpecialCharacters(Alltrim(Nvl(poArt.lot,[]))) + ['] + ;
|
|
[);]
|
|
```
|
|
|
|
Apel **pozitional**, se opreste la `V_LOT` (ultimul parametru existent azi). Oracle permite ca un
|
|
apel pozitional sa se opreasca inainte de parametri opționali de la coada — deci un parametru nou
|
|
**dupa** `V_LOT` nu afecteaza acest apel existent (ramane identic, echivalent cu "trimite `NULL`" pe
|
|
noul parametru).
|
|
|
|
### 2. Schema propusa
|
|
|
|
**Coloana noua**: `VANZARI_DETALII_TEMP.CONT_VENIT VARCHAR2(4) NULL` (fara `NOT NULL`, fara `CHECK`
|
|
— acelasi tipar ca `ACT_TEMP.SCC`, vezi DDL mai jos). Recomandat, dar nu strict necesar pentru
|
|
mecanismul de nota (doar pentru trasabilitate/raportare ulterioara): aceeasi coloana pe
|
|
`VANZARI_DETALII`, plus adaugarea ei in `INSERT /*+ APPEND */ INTO VANZARI_DETALII (...) SELECT ...
|
|
FROM VANZARI_DETALII_TEMP` din `scrie_in_vanzari` (citat in `nota_contabila_fara_politica.md`
|
|
sectiunea 4 ca avand lista explicita de coloane — **linia exacta nu a fost re-verificata in aceasta
|
|
runda**, vezi "Ce nu s-a putut stabili"). Fara acest pas secundar, nota contabila tot se scrie corect
|
|
— doar `VANZARI_DETALII` nu ar pastra, dupa fapt, cu ce cont s-a facturat linia.
|
|
|
|
**Parametru nou pe `adauga_articol_factura`**, la coada, dupa `V_LOT`:
|
|
```
|
|
V_CONT_VENIT IN VARCHAR2 DEFAULT NULL
|
|
```
|
|
Plumbing identic cu `V_CONT`/`V_CONT2` (`ff_...:5004,5035-5037,5238,5268` — acelasi tipar de
|
|
"copiaza daca nu e sentinela/gol, altfel NULL"), adaugat langa `INSERT INTO VANZARI_DETALII_TEMP`
|
|
(`ff_...:5222-5282`): o coloana in plus in lista, o valoare in plus in `VALUES`.
|
|
|
|
**Niciun rand de cod nou in `scrie_factura2` / `scrie_factura_avize_retur` / `scrie_aviz_retur`** —
|
|
confirmat la sectiunea 1, `SELECT *` + `%ROWTYPE` absoarbe coloana automat.
|
|
|
|
### 3. Ramura noua in `contabilizeaza_articol`
|
|
|
|
Corpul complet citit `ff_...:7173-7547`. Structura propusa: un `IF detalii_articol.cont_venit IS NOT
|
|
NULL THEN <ramura noua> ELSE <tot codul de azi, neschimbat> END IF;` care **infasoara inclusiv
|
|
blocul FACT-024**, plasat imediat dupa declaratiile locale (inainte de `ff_...:7278`). Cand
|
|
parametrul e `NULL` (toti apelantii de azi, nemodificati), executia cade in `ELSE` si comportamentul
|
|
e identic bit-cu-bit cu azi.
|
|
|
|
**Continutul ramurii noi** (doar pentru "articol simplu" — articolele compuse, `V_COMPUS=1`, raman
|
|
in afara scopului, ca azi):
|
|
|
|
| Camp | Sursa in ramura noua | Argumentatie |
|
|
|---|---|---|
|
|
| `SCC` | `detalii_articol.cont_venit` | Chiar parametrul primit — asta e intreg scopul modificarii. |
|
|
| `SCD` | **hardcodat `'4111'`** pentru cazul "factura" (ramurile aviz raman `'418'`/`'461'`, deja hardcodate azi la `ff_...:7415,7420`, independent de politica) | **Hardcodare explicita, de confirmat cu Marius.** Azi, pentru factura normala, `V_SCD := crs_rand_articol.scd` (`ff_...:7409`) — vine din `NOTE_CONTABILE.SCD`. Pe baza vie (`verif_baza_vie_cont_venit.md` tabel sectiunea 4), **toate cele 7 note de vanzari active au `SCD='4111'`** (contul de clienti, standard pentru vanzare pe credit) — zero exceptii masurate. Decizia 31 (nu generaliza de pe datele din Dev) se aplica la *numere*, nu la *structura contabila* — `4111` = clienti e conventie standard de plan de conturi, nu un artefact al datelor de test, dar tot ramane o presupunere care trebuie confirmata explicit, nu deja "descoperita". |
|
|
| `ASCD` | `PACK_FACTURARE.GetAnaliticByGrupUtilizatori(pack_facturare.nid_util, V_SCD)` | Exact fallback-ul deja folosit necondiționat pentru ramurile de aviz azi (`ff_...:7416-7417,7421-7422`) — functioneaza fara cursor, deja verificat ca nu depinde de politica (`coresp_cont_venchelt.md` sectiunea 7). |
|
|
| `ASCC` | `PACK_FACTURARE.GetAnaliticByGrupUtilizatori(pack_facturare.nid_util, V_SCC)` | Acelasi tipar ca `V_ASCC` de azi (`ff_...:7426-7428`), care oricum e `NVL(crs_rand_articol.ascc, GetAnaliticByGrupUtilizatori(...))` — fallback-ul e calea normala, nu exceptia. |
|
|
| `EXPLICATIE` | `detalii_articol.explicatia` (coloana `EXPLICATIA` din `VANZARI_DETALII_TEMP`, populata de `V_EXPLICATIE` — parametru deja existent pe `adauga_articol_factura`, `ff_...:4992,5227,5257`) | **Mai buna decat sursa de azi**, nu doar un fallback — azi `crs_rand_articol.explicatie` vine dintr-un sablon static configurat pe nota; textul introdus de utilizator la adaugarea articolului e deja disponibil pe rand, fara politica. |
|
|
| `ID_VENCHELT` | `pack_facturare.nid_venchelt` | Acelasi fallback de sesiune pe care cursorul de azi il foloseste oricum ca prioritate (`NVL(pack_facturare.nid_venchelt, NVL(A.ID_VENCHELT, C.ID_VENCHELT))`, `ff_...:7244-7245`) — poate ramane `NULL` daca variabila de sesiune nu e setata, exact ca azi in acelasi caz. |
|
|
| `ID_SECTIE` | `pack_facturare.nid_sectie_stoc` | Acelasi tipar (`ff_...:7246`). |
|
|
| `IN_VALUTA` | `pack_facturare.nin_valuta` | **Nu e o presupunere noua** — e valoarea pe care cursorul de azi o **substituie deja** peste `D.IN_VALUTA` intr-un caz analog (`ff_...:7254-7260`, cand `A.ID_POL = pack_facturare.nid_politica_stoc AND pack_facturare.nin_valuta = 1`). Fiindca fara politica nu exista `D.IN_VALUTA` de citit, se foloseste direct flagul de document — acelasi flag pe care codul existent il trateaza deja ca sursa de incredere. |
|
|
| `CU_TVA` | **hardcodat `1`** | **Hardcodare explicita, de confirmat cu Marius.** `CU_TVA` (parametrul `V_CU_TVA` al `scrie_nota`, `ff_...:12347`) controleaza daca se scrie **separat** o linie de TVA (`ff_...:12537-12558`, `pack_facturare.scrie_tva(...)`) — nu trebuie confundat cu `V_PRET_ARE_TVA` (mapat pe `detalii_articol.pret_cu_tva`, deja disponibil independent de politica, controleaza doar interpretarea pretului). Pe baza vie, **toate cele 7 note de vanzari active au `CU_TVA=1`** (`verif_baza_vie_cont_venit.md` sectiunea 4) — nicio nota de vanzare reala cu `CU_TVA=0`. Semantic, `1` = comportamentul standard pentru o vanzare taxabila (TVA scrisa separat, necesar pentru raportarea de TVA); `0` n-are niciun exemplu real observat. Daca cota TVA a articolului e 0% (scutit), `scrie_tva` scrie oricum o linie cu suma 0 — inofensiv, nu gresit, dar de confirmat ca e acceptabil. |
|
|
|
|
**Apeluri, o singura data fiecare** (nu in bucla — nu exista cursor in aceasta ramura):
|
|
|
|
1. `pack_facturare.scrie_nota(...)` — aceiasi parametri ca la `ff_...:7443-7467`, cu valorile de mai
|
|
sus in locul celor din `crs_rand_articol`; restul (`cantitate`, `pret`, `discount_unitar`,
|
|
`pret_cu_tva`, `id_valuta`, `curs/multiplicator`, `id_ctr`, `proc_tvav`, `id_jtva_coloana`,
|
|
`taxcode`) vin din `detalii_articol`, exact ca azi — independente de politica.
|
|
2. `pack_facturare.descarca_gestiune(...)` — **aceeasi garda ca azi**
|
|
(`pack_facturare.nscadere_stoc=1 AND detalii_articol.id_gestiune<>-1000 AND
|
|
detalii_articol.in_stoc=1`, `ff_...:7473-7475`), cu `crs_rand_articol.id_sectie`/`.id_venchelt`
|
|
inlocuite de `pack_facturare.nid_sectie_stoc`/`.nid_venchelt` direct (fara cursor). **Ruleaza
|
|
exact o data, prin constructie** — nu exista `WHILE cursor%FOUND LOOP` in aceasta ramura, deci
|
|
defectul de "set multi-rand" (punctul urmator) nu poate aparea aici, fara sa fi fost nevoie sa se
|
|
repare nimic pe ramura veche.
|
|
3. Discount (`ff_...:7501-7518`), aceeasi garda (`discount_unitar<>0 AND ndiscount_evidentiat=1`),
|
|
cu `V_ASCD` si `V_CU_TVA` calculate mai sus in loc de cele din cursor.
|
|
4. `RETURN V_INCASAT_CALCUL;` — identic.
|
|
|
|
### 4. FACT-024 — ocolit doar pe ramura noua, garda neschimbata pe ramura veche
|
|
|
|
Blocul (`ff_...:7278-7302`) ramane **litera cu litera identic** in `ELSE`. Nu se slabeste nimic — o
|
|
linie fara politica **si** fara `cont_venit` continua sa primeasca FACT-024 exact ca azi. Bypass-ul
|
|
e strict conditionat de faptul ca VFP a trimis explicit un cont (`cont_venit IS NOT NULL`), nu de
|
|
absenta politicii in sine.
|
|
|
|
### 5. Bug-ul de set multi-rand — nemostenit, netratat
|
|
|
|
Documentat deja (`nota_contabila_fara_politica.md`, `verif_baza_vie_cont_venit.md` sectiunea 6.1):
|
|
`cursor_articol` face `LEFT JOIN NOTE_CONTABILE D ON C.ID_SET = D.ID_SET` fara `ROWNUM`/agregare, iar
|
|
bucla scrie venitul si descarca gestiunea o data per rand din set. **Ramura noua nu are cursor deloc**
|
|
— rezolva structural aceeasi clasa de bug, dar **nu e propusa ca reparatie a ramurii vechi**; ramane
|
|
un defect separat, de tratat separat, cum a cerut explicit team-lead-ul.
|
|
|
|
### 6. Suprafata de regresie
|
|
|
|
- **`contabilizeaza_articol`**: 3 apelanti, toti interni `pack_facturare` (`scrie_factura2`,
|
|
`scrie_factura_avize_retur`, `scrie_aviz_retur`) — **zero schimbari** la niciunul (sectiunea 1).
|
|
- **`adauga_articol_factura`**: **un singur apelant confirmat** in sursa citita,
|
|
`COMUN\clase\ofacturare.vc2:14069-14091`, duplicat identic la `:18089-18114` in aceeasi clasa
|
|
(posibil doua metode gemene, nu doua clase — neconfirmat, vezi mai jos). Apel pozitional, se
|
|
opreste la `V_LOT` — **neafectat** de un parametru nou dupa `V_LOT` cu `DEFAULT NULL`, pe acelasi
|
|
tipar deja folosit de `V_TAXCODE`/`V_LOT` insele.
|
|
- **Restul suitei** (ROAGEST, ROAAUTO, ROAACNPRO, ROAIMOB): pe baza cercetarilor anterioare
|
|
(`nota_contabila_fara_politica.md` sectiunea 4, `coresp_cont_venchelt.md` sectiunea 9b), aceste
|
|
produse folosesc `adauga_articol_factura_deviz`/`_stoc` (proceduri **separate**, semnaturi diferite,
|
|
**neatinse** de aceasta propunere) sau `pack_acn.salveaza_regdoc` (alt pachet complet). O cautare
|
|
directa, in aceasta runda, pentru apeluri catre `adauga_articol_factura(` (fara `_deviz`/`_stoc`) in
|
|
`COMUN`-urile celorlalte produse **nu s-a terminat in timp util** (comanda de fond nu a raspuns) —
|
|
vezi "Ce nu s-a putut stabili". Pe baza dovezilor deja existente (nimeni altcineva nu are un flux
|
|
documentat prin `adauga_articol_factura` simplu), riscul asteptat e **zero**, dar nu e demonstrat
|
|
exhaustiv pentru toata suita in aceasta runda.
|
|
- **Teste minime recomandate**: (a) factura normala cu politica, parametru `NULL` — verifica ACT
|
|
identic cu azi (regresie); (b) articol fara politica, `cont_venit` populat — un singur rand `ACT`,
|
|
`SCC`=valoarea data, `SCD='4111'`, linie TVA scrisa separat; (c) articol negestionabil
|
|
(`id_gestiune=-1000`) cu `cont_venit` populat — `descarca_gestiune` NU ruleaza; (d) discount pe
|
|
linie cu `cont_venit` populat; (e) document in valuta (`nin_valuta=1`) cu `cont_venit` populat —
|
|
`IN_VALUTA=1` pe nota, `SUMA_VAL` completat; (f) linie fara politica **si** fara `cont_venit` —
|
|
FACT-024 tot apare (regresie negativa, garda nu s-a slabit).
|
|
|
|
### 7. Alternativa mai mica — nu exista una reala
|
|
|
|
Propunerea de mai sus **e** deja varianta minimala: un singur parametru `VARCHAR2(4) DEFAULT NULL`,
|
|
zero schimbare de comportament cand e `NULL`, zero atingere a celor 3 apelanti interni. O varianta
|
|
"doar un flag care opreste FACT-024, fara sa transporte contul" tot ar avea nevoie ca `SCC` sa vina
|
|
de undeva — nu reduce suprafata, doar muta numele. Nu recomand separarea in doi parametri
|
|
(flag + cont) — complexitate in plus fara beneficiu; un singur camp nenul e semnalul suficient.
|
|
|
|
### Ce nu s-a putut stabili in aceasta runda, si de ce
|
|
|
|
- **Daca `ofacturare.vc2:14069-14091` si `:18089-18114` sunt doua metode/clase distincte sau o
|
|
duplicare literala a aceleiasi metode** — nu am identificat clasele-container ale celor doua
|
|
blocuri (ar necesita indexul de simboluri `vfp_symbols.ps1`, nefolosit in aceasta runda din lipsa
|
|
de timp). Nu schimba verdictul (ambele se opresc la `V_LOT`), dar conteaza pentru a sti cate locuri
|
|
VFP trebuie atinse ca sa se **foloseasca** efectiv noul parametru dupa ce va exista in Oracle.
|
|
- **Daca alte produse (ROAGEST/ROAAUTO/ROAACNPRO/ROAIMOB) apeleaza `adauga_articol_factura` simplu**
|
|
undeva neexaminat — comanda de cautare pe `COMUN`-urile celorlalte produse a ramas fara raspuns in
|
|
timp util in aceasta sesiune; de re-rulat separat inainte de implementare.
|
|
- **Linia exacta a `INSERT ... INTO VANZARI_DETALII ... SELECT ... FROM VANZARI_DETALII_TEMP`** din
|
|
`scrie_in_vanzari` — citata doar din raportul anterior (`nota_contabila_fara_politica.md`), nu
|
|
re-verificata pe fisierul curent in aceasta runda; necesara doar daca se decide sa se persiste si
|
|
`CONT_VENIT` pe `VANZARI_DETALII` (pasul optional de la sectiunea 2).
|
|
- **Comportamentul `scrie_tva` cu cota 0%** (linie scutita) cand `CU_TVA` e hardcodat la `1` — nu am
|
|
citit corpul `scrie_tva` in aceasta runda pentru a confirma ca o suma 0 nu produce vreun efect
|
|
secundar (ex. impact pe `nproc_tva_max`/`nid_jtva_coloana` la `ff_...:12538-12541`, care se
|
|
actualizeaza necondiționat de valoarea sumei).
|
|
- **Confirmarea explicita a lui Marius pe cele doua hardcodari** (`SCD='4111'`, `CU_TVA=1`) — sunt
|
|
presupuneri argumentate din date reale si din tiparul de cod existent, nu descoperiri; raman
|
|
decizii de proiectare deschise.
|
|
|
|
---
|
|
|
|
## Verdict runda anterioara (canal ocolitor, mandat vechi — pastrat ca input de proiectare)
|
|
|
|
**DA, exista un canal real, deja cablat si deja folosit in productie pentru categoria de document
|
|
"facturi emise"** — complet independent de `pack_facturare` si de politica de pret. E cursorul VFP
|
|
generic `actactan`/`tact` -> `oscrie_in_fisiere.prg` (INSERT generic in `ACT_TEMP` din campurile
|
|
oricarui cursor VFP) -> `pack_contafin.SCRIE_IN_ACT`/`STERGE_DIN_ACT` (nu `pack_facturare`!). Cel mai
|
|
relevant: **fluxul de editare a facturii emise, `ofacturare_comun.vc2:3796-3821` (proiectul #6
|
|
insusi), foloseste exact acest canal** ca sa lase utilizatorul sa editeze `SCD`/`ASCD`/`SCC`/`ASCC`
|
|
direct pe randul notei prin `frm_modific2024` (`omodificari.vc2`, fisier **nerestrictionat**), apoi
|
|
rescrie `ACT_TEMP` cu valorile din cursorul VFP editat. **Limitarea majora**: canalul e cablat pe
|
|
**editarea unei note deja scrise** (sterge + rescrie), nu pe **emiterea** unei facturi noi — emiterea
|
|
trece azi exclusiv prin `pack_facturare.scrie_factura2 -> contabilizeaza_articol`, care nu are nicio
|
|
ramura alternativa (confirmat in rundele anterioare, FACT-024). Pistele 1, 2, 4, 5 din cerere sunt
|
|
**toate NU** — niciuna nu ofera un canal catre `SCC`. DDL-ul `ACT_TEMP` nu blocheaza nimic din asta:
|
|
`SCD`/`SCC` sunt `VARCHAR2(4) NULL`, fara `CHECK`.
|
|
|
|
Sursa principala pentru citatele Oracle: **`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql`**
|
|
(17217 linii — confirmat `wc -l`). Fisierul din `docs\` nu mai exista, cum a semnalat cererea.
|
|
|
|
---
|
|
|
|
## Pistele cerute, in ordine
|
|
|
|
### 1. `V_CONT IN VARCHAR2` (parametru `adauga_articol_factura`) — **NU e canal pentru SCC**
|
|
|
|
Confirmat pe cod, nu doar preluat din raportul anterior (a carui concluzie pe acest punct era deja
|
|
corecta): `V_CONT` e contul de **gestiune/stoc** (clasa 3xx), nu de venit. E scris ca atare in
|
|
`VANZARI_DETALII_TEMP.CONT` (`adauga_articol_factura`, semnatura la
|
|
`ff_...:4989-5015` `V_CONT IN VARCHAR2`, folosire la `:5044-5046` `V_CONT2 := V_CONT`, `INSERT` la
|
|
`:5277`). **Niciodata folosit ca `SCD`/`SCC`** — `contabilizeaza_articol` isi ia `V_SCC` exclusiv din
|
|
`cursor_articol` (`D.SCC`, lantul `CRM_POLITICI_PRET_ART -> CRM_POLITICI_PRETURI -> CRM_NOTE_VANZARI
|
|
-> NOTE_CONTABILE`, `ff_...:7248-7253,7259-7260`), fara nicio ramura care sa citeasca `V_CONT`.
|
|
`V_CONT` alimenteaza doar `descarca_gestiune` (contul de iesire din gestiune, SCC pe nota de
|
|
**stoc**, nu de venit), nu nota de venit.
|
|
|
|
### 2. Variabile de sesiune `pack_facturare` — **NU exista setter pentru cont**
|
|
|
|
Am listat toate variabilele publice de pachet cu prefix `nid_` din specificatia `pack_facturare`
|
|
(`ff_...:72-211`, citat exhaustiv, cautare `grep -n "^ nid_"`):
|
|
|
|
```
|
|
nid_tipnir, nid_tipbon, nid_tipfactura, nid_tipaviz, nid_act, nid_serie, nid_fdoc, nid_part,
|
|
nid_part_rez, nid_lucrare, nid_sectie_stoc, nid_gestiune_sursa, nid_responsabil, nid_ordl, nid_set,
|
|
nid_util, nid_moneda_nationala, nid_fact, nid_factc, nid_partc, nid_jtva_coloana, nid_comanda,
|
|
nid_valuta, nid_politica_stoc, nid_sucursala, nid_venchelt, nid_vanzare, nid_beneficiar
|
|
```
|
|
|
|
Niciuna tipata pe un cont (`VARCHAR2(4)`/cod de cont) — toate sunt FK-uri numerice
|
|
(`%TYPE` pe alte tabele: `ID_SECTIE`, `ID_VENCHELT`, `ID_POL`, etc.). Cautare directa
|
|
`nid_scc`/`nid_scd`/`nid_cont` in tot fisierul: **zero rezultate**. `nid_venchelt` (folosit ca
|
|
fallback la `ID_VENCHELT` in `cursor_articol`, `ff_...:7244-7245`, deja documentat in
|
|
`coresp_cont_venchelt.md` sectiunea 7) e o clasificare dimensionala
|
|
(`NOM_VENIT_CHELTUIELI.ID_VENCHELT%TYPE`), nu un cont — **nu am gasit consumator care sa-l foloseasca
|
|
drept `SCC`**. Cautare separata `PROCEDURE SET_` in tot pachetul: zero rezultate — nu exista niciun
|
|
setter public de tip `SET_...` pentru cont. **Concluzie: NU.**
|
|
|
|
### 3. `ACT_TEMP` scris direct din VFP — **DA, canal real, dar pe fluxul de editare, nu de emitere**
|
|
|
|
Confirmat de `COMUN\docs\oracle_export.md:64-65`: *"Pachetul central de scriere a documentelor —
|
|
clientul VFP populeaza tabelele temporare `ACT_TEMP`/`RUL_TEMP` (prin `oscrie_in_fisiere`-ul din
|
|
COMUN), apoi pachetul distribuie"*. Mecanismul e generic si complet independent de `pack_facturare`:
|
|
|
|
**Mecanismul** (`COMUN\programe\oscrie_in_fisiere.prg`):
|
|
- `sql_temp_insert('actactan','ACT_TEMP')` (`oscrie_in_fisiere.prg:127`) face, pentru fiecare rand al
|
|
oricarui cursor VFP numit `actactan`, un `INSERT INTO ACT_TEMP (<coloanele care exista si in
|
|
cursor si in tabel>) VALUES (...)` construit dinamic din `user_tab_columns`
|
|
(`oscrie_in_fisiere.prg:190-280`) — **orice camp `SCD`/`ASCD`/`SCC`/`ASCC` prezent in cursorul VFP
|
|
ajunge direct in `ACT_TEMP`, indiferent de valoare, fara nicio validare de cont**.
|
|
- Scrierea efectiva in `ACT` se face prin `pack_contafin.init_scriere_act_rul_local` +
|
|
`final_scriere_act_rul_local` -> `SCRIE_IN_ACT`/`STERGE_DIN_ACT` (`oscrie_in_fisiere.prg:121-147`)
|
|
— **`pack_contafin`, nu `pack_facturare`**. Confirmat si in
|
|
`COMUN\docs\flux-modificare-stergere-nota-jurnal.md:20-28`.
|
|
|
|
**Cine populeaza `actactan` cu valori calculate/editate de VFP** — cele doua cazuri gasite, ambele
|
|
active in productie:
|
|
|
|
**(a) Registrul Jurnal — editare/stergere manuala de nota, orice document, generic**
|
|
(`COMUN\clase\comun.vc2`, clasa `afisjurcom`):
|
|
- `do_modifica` (`comun.vc2:2222-2562`): incarca nota existenta
|
|
(`Select * From v_act Into Cursor actactan`, `comun.vc2:2363`), instantiaza
|
|
`frm_modific2024` (`comun.vc2:2439`, `omodificari.vc2:6375`) — formular in care utilizatorul poate
|
|
edita direct `scd`/`ascd`/`scc`/`ascc` pe fiecare rand al notei (grid legat pe `tact`, verificare
|
|
prin `verific_analitic`/`do_verifica`, tipar prezent si in `omodificari.vc2:1714-1788` — comentat
|
|
azi, dar acelasi tipar activ e in `frm_modific2024`, vezi mai jos (b)). Dupa editare:
|
|
`oscrie_in_fisiere(2,...)` = sterge nota veche (`comun.vc2:2454`), apoi
|
|
`oscrie_in_fisiere(0,...)` = scrie nota noua **cu valorile din cursorul editat**
|
|
(`comun.vc2:2482`), apoi `pack_contafin.finalizeaza_modificare_nota(...)`
|
|
(`comun.vc2:2484-2486`). **Niciun apel catre `pack_facturare` in acest flux.**
|
|
- Documentat integral, cu aceleasi citate, in `COMUN\docs\flux-modificare-stergere-nota-jurnal.md`.
|
|
- E generic pe orice document din `ACT` (nu doar facturi) — daca o factura emisa are deja o nota,
|
|
poate fi editata de aici.
|
|
|
|
**(b) Editarea facturii emise — acelasi mecanism, scop specific "facturi emise" (proiectul #6
|
|
insusi)**, `COMUN\clase\ofacturare_comun.vc2:3769-3838` (functia `do_editare_factura`, citita
|
|
integral, **nu modificata**):
|
|
|
|
```
|
|
ofacturare_comun.vc2:3769 If IncarcaCursoareModificareNota(lnCod, pnAn, pnLuna, .F.) && ofacturare_editare.prg
|
|
...
|
|
ofacturare_comun.vc2:3787 Select a.*, Iif(Nvl(id_jtva_coloana,0)=0,0,1) As cu_Tva From tact a Into Cursor tact Readwrite
|
|
...
|
|
ofacturare_comun.vc2:3796 Omodif = Createobject([frm_modific2024], lnIdSet)
|
|
ofacturare_comun.vc2:3797 Omodif.Show()
|
|
ofacturare_comun.vc2:3799 If buton = 1
|
|
ofacturare_comun.vc2:3800 If Thisform.do_deschide_tranzactie()
|
|
ofacturare_comun.vc2:3801 Select actactan
|
|
ofacturare_comun.vc2:3802 lnSucces = OSCRIE_IN_FISIERE(2,.T.,.T.) && sterge nota veche
|
|
ofacturare_comun.vc2:3803 If lnSucces > 0
|
|
...
|
|
ofacturare_comun.vc2:3807 Select tact
|
|
ofacturare_comun.vc2:3808 Replace id_jtva_coloana With Null, proc_tva With 0 For cu_Tva = 0
|
|
ofacturare_comun.vc2:3809 Select * From tact Into Cursor actactan Readwrite && re-materializeaza tact (inclusiv orice SCD/SCC editat) in actactan
|
|
ofacturare_comun.vc2:3810 Replace All id_util With gnIdUtil, sters With 0
|
|
...
|
|
ofacturare_comun.vc2:3821 lnSucces = OSCRIE_IN_FISIERE(0,.T.,.T.) && scrie nota noua, direct din actactan, in ACT_TEMP
|
|
ofacturare_comun.vc2:3823 If lnSucces > 0
|
|
ofacturare_comun.vc2:3824 lcSql = [begin pack_contafin.finalizeaza_modificare_nota(...); end;]
|
|
ofacturare_comun.vc2:3828 If lnSucces > 0 And "OFACTURARE_EDITARE" $ Upper(Set("Procedure")) And Used('tvanz')...
|
|
ofacturare_comun.vc2:3829 lnSucces = Iif(ScrieArticoleFacturaEditate(tvanz.id_vanzare), 1, -1) && scrie si VANZARI_DETALII
|
|
```
|
|
|
|
`IncarcaCursoareModificareNota` (`COMUN\programe\ofacturare_editare.prg:32-71`) incarca nota
|
|
existenta a facturii (`vact_tot -> v_act -> actactan -> tact`, toate **READWRITE**) inainte de a
|
|
arata `frm_modific2024`. Linia `:3809` **rescrie `actactan` direct din `tact`** — orice valoare
|
|
aflata pe `tact.scd`/`tact.scc` in acel moment (editata manual prin `frm_modific2024`, sau setata
|
|
programatic de orice cod VFP inainte de linia 3809) devine noua nota, scrisa in `ACT_TEMP` prin
|
|
`OSCRIE_IN_FISIERE(0,...)` la linia 3821 — **fara niciun apel `pack_facturare`, fara politica de
|
|
pret**. `pack_contafin.finalizeaza_modificare_nota` (linia 3824) doar re-leaga `cod`-ul nou de
|
|
`VANZARI`; `ScrieArticoleFacturaEditate` (linia 3829) scrie separat `VANZARI_DETALII`.
|
|
|
|
**Aceasta e dovada cea mai puternica posibila pentru intrebarea pusa**: canalul nu e teoretic — e
|
|
**exact mecanismul pe care proiectul #6 il foloseste azi** ca sa permita editarea contului unei
|
|
facturi deja emise, complet in afara `pack_facturare`.
|
|
|
|
**Limitarea reala**: mecanismul opereaza pe **o nota deja existenta** (sterge randul vechi din `ACT`,
|
|
scrie unul nou cu acelasi `id_fact`) — presupune ca factura a fost deja scrisa o data (prin
|
|
`pack_facturare`, cu politica). Nu e (azi) un canal pentru **emiterea** initiala a unei facturi noi
|
|
cu un articol fara politica — `scrie_factura2 -> contabilizeaza_articol` (calea de emitere) nu are
|
|
nicio ramura care sa ocoleasca politica si nu apeleaza acest mecanism.
|
|
|
|
**Alte doua confirmari ale aceluiasi tipar, tot pentru categoria "facturi"**:
|
|
- `COMUN\ferestre\frm_initializare_facturi_balanta.sc2:458` — `CREATE CURSOR actactan (id_set I, an
|
|
N(4), luna N(2), Dataact D, datascad D, dataireg D, serie_act C(20), nract N(20), proc_tva N(5,2),
|
|
id_jtva_coloana I NULL, scd C(4), ascd C(4), scc C(4), ascc C(4), ...)` — cursor creat de la zero
|
|
in VFP, cu `scd`/`scc` campuri simple, editabile liber, fara nicio derivare Oracle. Foloseste tot
|
|
`frm_modific2024` (`:1806`) pentru editare/validare inainte de scriere.
|
|
- `COMUN\ferestre\frm_import_note_facturi_clienti.sc2:667,815,898,911` — acelasi tipar
|
|
(`actactan`/`tact` editabil + `frm_modific2024`), pentru import manual de note pe facturi de
|
|
clienti.
|
|
|
|
Ambele sunt scenarii de **initializare/import** (sold de deschidere, import de note), nu de
|
|
facturare curenta — dar confirma ca `ACT_TEMP` pentru **categoria "facturi"** se scrie deja, in mod
|
|
curent, direct din cursoare VFP construite de la zero, fara `pack_facturare`.
|
|
|
|
### 4. `ID_VENCHELT` / `CRM_NOTE_VANZARI` — **NU e canal alternativ catre SCC**
|
|
|
|
Deja stabilit exhaustiv in `coresp_cont_venchelt.md` sectiunea 7: `ID_VENCHELT` e o dimensiune
|
|
(`NOM_VENIT_CHELTUIELI.ID_VENCHELT`), citita cu fallback pe `nid_venchelt`
|
|
(`ff_...:7244-7245`), dar **nu participa la calculul `SCC`** — `V_SCC` vine exclusiv din
|
|
`cursor_articol.D.SCC`. Nu exista camp de tip cont pe `VANZARI`/`VANZARI_DETALII` — reconfirmat aici
|
|
prin cautare `grep -inE "SCC|CONT_VENIT"` in blocurile `CREATE`/`ALTER TABLE VANZARI` din
|
|
`ff_...` (fara rezultate suplimentare fata de ce era deja stabilit).
|
|
|
|
### 5. `GetAnaliticByGrupUtilizatori` — **doar analitic, nu cont sintetic**
|
|
|
|
Confirmat deja in `coresp_cont_venchelt.md` sectiunea 7: functia da fallback pentru `ASCD`/`ASCC`
|
|
(analiticul), nu pentru `SCD`/`SCC` (contul sintetic). Nu exista o functie analoaga pentru cont —
|
|
cautare `GetSinteticBy`/`GetContBy` in tot `ff_...`: zero rezultate.
|
|
|
|
---
|
|
|
|
## Lista exhaustiva a intrarilor catre `SCD`/`SCC` in `ACT_TEMP`, pe/langa fluxul de facturare
|
|
|
|
Sursa: `ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql` + fisierele VFP citate.
|
|
|
|
1. **`pack_facturare.contabilizeaza_articol -> scrie_nota`** (`ff_...:7218-7556` / `12338-12570`,
|
|
`INSERT INTO ACT_TEMP` la `:12458-12544`) — calea principala de **emitere**. `SCD`/`SCC` vin din
|
|
`cursor_articol` (`D.SCD`, `D.SCC`, lantul politicii). Blocheaza cu FACT-024
|
|
(`:7275-7311`) daca articolul nu e in politica — fara fallback (deja stabilit in
|
|
`nota_contabila_fara_politica.md`).
|
|
2. **Ramurile speciale din `scrie_factura2`** (transfer subunitati `ntip IN (23,25,30,41)`, custodie
|
|
`ntip IN (42,47)`, rata `id_rata<>0`) — tot `contabilizeaza_articol`, acelasi punct 1.
|
|
3. **`scrie_factura_avize_retur`** (`ff_...:6273-6666`, apel la `:6867`) si **`scrie_aviz_retur`**
|
|
(`ff_...:7094-7180`, apel la `:7149`) — tot `contabilizeaza_articol`.
|
|
4. **`descarca_gestiune`** (`ff_...:7476-7498`, apelata din interiorul buclei `cursor_articol`) —
|
|
scrie o a doua nota, de **iesire din gestiune** (`SCD`/`SCC` = conturi de stoc, din `V_CONT`/
|
|
`poArticol.Cont`, nu din politica) — parte a fluxului de facturare, dar nu e nota de venit.
|
|
5. **Discount pe linie** (`ff_...:7501-7518`) — scrie o nota separata (vazuta pe date live ca
|
|
`id_nota=2`, `SCD=667`/`SCC=4111`, `verif_baza_vie_cont_venit.md` sectiunea 4) — tot in interiorul
|
|
`cursor_articol`, deci tot dependenta de politica pentru a ajunge acolo.
|
|
6. **`oscrie_vanzare_din_stoc`** (`COMUN\programe\ofacturare_stoc.prg:104-450`) — flux ROAGEST
|
|
"vanzare din stoc". Apeleaza `pack_facturare.adauga_articol_factura_stoc` per articol
|
|
(`:357-378`) apoi `oscrie_in_fisiere(0,.F.,.T.)` (`:392`). **Neverificat complet**: codul citit nu
|
|
arata explicit unde/cum se populeaza `actactan` cu `SCD`/`SCC` inainte de linia 392 in acest flux
|
|
particular (cursorul `ACTACTAN` e doar *citit* la `:253-289` pentru alte campuri, nu am gasit
|
|
punctul de scriere in fisierul citit) — posibil populat de o procedura anterioara neexaminata.
|
|
Marcat ca zona neinchisa, vezi "Ce nu s-a putut stabili".
|
|
7. **Registrul Jurnal — editare/stergere manuala** (`COMUN\clase\comun.vc2:2222-2724`, clasa
|
|
`afisjurcom`) — canalul confirmat la pista 3(a). Genereic, orice document din `ACT`.
|
|
8. **Editare factura emisa** (`COMUN\clase\ofacturare_comun.vc2:3769-3838`, proiectul #6) — canalul
|
|
confirmat la pista 3(b), specific "facturi emise".
|
|
9. **`frm_initializare_facturi_balanta.sc2`** si **`frm_import_note_facturi_clienti.sc2`** — canalul
|
|
confirmat la pista 3, scop initializare/import pe categoria "facturi".
|
|
10. **eFactura import** (`COMUN\clase\anaf_efactura.vc2:12241,13087-13102,13244-13325`) — acelasi
|
|
tipar generic (`actactan`/`tact` + `frm_modific2024` + `oscrie_in_fisiere`), dar pentru facturi
|
|
de **achizitie** importate din XML ANAF, nu facturi emise — mentionat pentru completitudine, nu
|
|
aplicabil direct la #13.
|
|
11. **`ointroduceri.vc2`/`ointroduceri.prg`** (NIR, BON, RETUR, intrare din gestiune valorica) si
|
|
**`oschimbare_pret.prg`**, **`oproceduri_rulaje.prg`**, **`reglari_denominare2005.prg`** —
|
|
acelasi canal generic `actactan`/`oscrie_in_fisiere`, dar pentru alte categorii de document
|
|
(gestiune, nu vanzare/factura). Mentionate pentru completitudinea listei de consumatori ai
|
|
canalului, nu aplicabile la #13.
|
|
|
|
**Niciuna dintre intrarile 1-6 (fluxul de emitere efectiv) nu are o ramura care sa ocoleasca
|
|
politica.** Intrarile 7-11 folosesc toate acelasi canal generic (punctul 3), dar niciuna nu e
|
|
cablata pe fluxul de **emitere** — toate opereaza pe note deja existente sau pe alte categorii de
|
|
document.
|
|
|
|
---
|
|
|
|
## DDL `ACT_TEMP` (interogat 10.08.2026, schema `MARIUSM_AUTO`, `ROA_CENTRAL`)
|
|
|
|
| Coloana | Tip | Null |
|
|
|---|---|---|
|
|
| SCD | VARCHAR2(4) | **Y** |
|
|
| ASCD | VARCHAR2(4) | Y |
|
|
| SCC | VARCHAR2(4) | **Y** |
|
|
| ASCC | VARCHAR2(4) | Y |
|
|
| COD, NRACT, SUMA, PERECHED, PERECHEC, SUMA_VAL, CURS, NEIMPOZAB, NNIR, ID_UTIL, ID_UTILS, ID_RESPONSABIL, ID_VENCHELT, ID_SECTIE, ID_SET, ID_FACT, ID_PARTD, ID_PARTC, ID_FDOC, ID_LUCRARE, ID_GESTIN, ID_GESTOUT, ID_VALUTA, PROC_TVA, STERS, ID_FACTD, ID_FACTC, VALIDAT, TVA_INCASARE | numeric | N (29 coloane NOT NULL, restul optionale) |
|
|
|
|
Restul coloanelor (52 in total) sunt fie `NUMBER` (majoritatea `NOT NULL`), fie `DATE`/`VARCHAR2`
|
|
opționale (`DATAIREG`, `EXPLICATIA`, `DATASCAD`, `EXPLICATIA4/5`, `ID_SUCURSALA`, `ID_ACT`, `ID_CTR`,
|
|
`ID_JTVA_COLOANA`, `SERIE_ACT`, `ID_UTILV`, `DATAORAV`, `TAXCODE`, `PAYMENTCODE`).
|
|
|
|
Constrangeri: **29 `CHECK` constraints** (`SYS_C0014966`...`SYS_C0014994`) — corespund exact
|
|
coloanelor `NOT NULL` de mai sus (Oracle genereaza `CHECK (coloana IS NOT NULL)` pentru `NOT NULL`
|
|
declarat fara nume). **Niciun constraint pe `SCD`/`SCC`** (nici `NOT NULL`, nici `CHECK` de format,
|
|
nici FK catre un plan de conturi). **Nicio cheie primara/unica** — normal pentru un tabel `_TEMP` de
|
|
staging. Concluzie: schema **nu blocheaza in niciun fel** o valoare `SCC` calculata de VFP, oricare
|
|
ar fi ea, inclusiv `NULL`.
|
|
|
|
---
|
|
|
|
## Ce nu s-a putut stabilit si de ce
|
|
|
|
- **Punctul exact unde `ACTACTAN` primeste `SCD`/`SCC` in fluxul `oscrie_vanzare_din_stoc`**
|
|
(`ofacturare_stoc.prg`, intrarea 6 de mai sus) — codul citit (`:104-450`) nu arata sursa; ar
|
|
necesita urmarirea completa a apelantului (`initializeaza_vanzare_din_stoc`) si a modulului care
|
|
populeaza `ACTACTAN` inainte de acest punct (posibil `pack_facturare.adauga_articol_factura_stoc`
|
|
intoarce un ref cursor legat automat de `goExecutor` pe numele `actactan`, dar nu am gasit apelul
|
|
explicit). Nu schimba verdictul (oricum ar fi tot `pack_facturare`, deci tot politica), dar ramane
|
|
o zona neinchisa complet.
|
|
- **Daca discountul pe linie (`SCD=667`/`SCC=4111`) are vreo cale alternativa in afara
|
|
`cursor_articol`** — nu verificat aici, presupus dependent de politica la fel ca restul buclei.
|
|
- **Comportamentul practic al `frm_modific2024` cu privire la validarea contului tastat manual**
|
|
(daca exista vreo verificare `verific_cont`/plan de conturi la salvare, sau accepta orice text de
|
|
4 caractere) — nu urmarit pana la capat in `omodificari.vc2`; relevant doar daca se propune
|
|
reutilizarea canalului 3(b)/3(a) pentru scriere programatica (fara interactiune UI), caz in care ar
|
|
trebui verificat daca `frm_modific2024` insusi impune vreo validare care ar bloca o scriere
|
|
automata.
|
|
- **Daca fluxul de emitere (`scrie_factura2`) ar putea, teoretic, sa scrie intai o factura "goala" de
|
|
nota (sau cu o nota tehnica minimala) si apoi sa foloseasca imediat, in aceeasi tranzactie logica,
|
|
mecanismul de la pista 3(b) pentru a corecta `SCC`-ul** — nu explorat aici (ar fi o propunere de
|
|
design, in afara scopului acestei cercetari read-only); mentionat doar ca directie posibila care
|
|
reiese direct din ce s-a gasit.
|
|
- Nu am cautat/citit `pack_contafin.SCRIE_IN_ACT`/`STERGE_DIN_ACT` in `PACK_CONTAFIN.pck` pentru a
|
|
confirma ca acestea, la randul lor, nu re-deriva `SCC` din altceva — presupunerea (bazata pe
|
|
`oracle_export.md` si pe `flux-modificare-stergere-nota-jurnal.md`, care descriu deja aceste
|
|
proceduri drept "distribuie ce a scris clientul", nu "recalculeaza") e ca fac un simplu
|
|
`INSERT INTO ACT SELECT * FROM ACT_TEMP`-tip transfer, nu o derivare noua — dar nu am deschis
|
|
personal codul lor in aceasta runda.
|