roafacturare/docs/cercetare/canal_cont_venit_fara_politica.md

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.