romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
41d6c0c5fc3efb69bdf6034feefc25526e59c8b2
roafacturare/docs/cercetare/optiune_firma_cont_debit.md
Marius Mutu a7a7c098e3 sync SVN r18077
2026-09-09 22:19:22 +03:00

22 KiB
Raw Blame History

Optiune de firma pentru contul de debit (SCD) pe ramura fara politica de pret (#13, decizia 36)

Cercetare read-only, terminata. Continua canal_cont_venit_fara_politica.md (proiectarea parametrului de cont, sectiunea "Proiectarea parametrului de cont contabil", :27-241) si verificarea ei, parametru_cont_contabilizeaza_articol.md. Acolo, randul SCD din tabelul de sectiunea 3 propunea SCD hardcodat '4111', marcat explicit "de confirmat cu Marius" (canal_cont_venit_fara_politica.md:146). Decizia 36 (Marius, 10.08.2026): SCD vine dintr-o optiune de firma, cu 4111 ca implicit — motivul fiind ca se poate schimba la client fara recompilare. Aici e proiectarea acelei optiuni. Decizia 31 se aplica: datele din baza de dev arata ce exista, nu ce e configurat la client — nu se generalizeaza pe numere, doar pe tipar/structura.

Oracle interogat doar SELECT, schema MARIUSM_AUTO/ROA_CENTRAL. Niciun fisier de cod atins.

0. Rezumat, in cinci randuri

Mecanismul de optiuni de firma exista deja de 15+ ani (PACK_SESIUNE.getoptiunefirma, tabelul OPTIUNI, 458 randuri azi) si are exact tiparul cerut deja in productie, in acelasi pachet: pack_facturare.scrie_incasare2 seteaza V_SCD dintr-o optiune (RF_CONT_INCASARE_BONFISCAL etc., cate una per tip de incasare), cu fallback pe un cont hardcodat daca optiunea lipseste — acelasi camp (SCD), acelasi pachet, aceeasi sursa Oracle (ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql, liniile 13191-13233, tratate integral in sectiunea 2). Ecranul de editare (frm_optiuni/ frm_optiuni_nou, COMUN\clase\oOptiuni.vc2) e complet generic peste tabelul OPTIUNI — adaugarea cheii noi nu cere niciun cod VFP nou in ecranul de optiuni, doar randul in tabel. Propunerea (sectiunea 3): cheia noua FACT_SCD_ARTFPRET (sau numele ales de Marius), instalata cu valoare implicita '4111' chiar in randul din OPTIUNI (tiparul deja folosit de toate exemplele gasite), plus fallback hardcodat '4111' in cod langa getoptiunefirma, in oglinda exacta a tiparului scrie_incasare2 — dubla plasa de siguranta (instalare veche fara randul din OPTIUNI si rand editat gresit/gol raman amandoua acoperite).

1. Cum functioneaza mecanismul de optiuni de firma, azi

1.1 Stocare — tabelul OPTIUNI

Interogat direct (ALL_TAB_COLUMNS, schema curenta), 458 randuri azi:

Coloana Tip Null Rol
ID_OPTIUNI NUMBER N cheie surogat, PK implicita
VARNAME VARCHAR2(30) Y cheia optiunii — cautata UPPER(TRIM(...)), deci case-insensitive in practica
VARTYPE VARCHAR2(10) Y eticheta de tip pentru randare/parsare in VFP: CHARACTER/NUMERIC/CURRENCY/DATE/DATETIME/LOGICAL — descriptiva, nu impusa de Oracle; distinct azi: CHARACTER 156, NUMERIC 288, LOGICAL 11, DATE 3
VARVALUE VARCHAR2(1000) Y valoarea, mereu text, indiferent de VARTYPE
VARVALUE2 CLOB Y valoare alternativa, folosita de un mecanism separat (citeste_optiune(tcOptiune, tlValue2), oinit_optiuni.prg:802-823) — irelevant aici
VARDESC VARCHAR2(100) Y descriere afisata in ecran
PROGRAM VARCHAR2(30) Y produsul care a creat optiunea (metadata)
PROGRAME VARCHAR2(1000) Y lista CSV de produse pentru care optiunea e vizibila/relevanta (folosita la filtrare in incarcarea globala VFP, sectiunea 1.4)
ID_PRG_OWNER NUMBER Y neexaminat mai departe, neрелevant aici

Fara ID_FIRMA. Motivul: fiecare firma are schema Oracle proprie — tabelul OPTIUNI din schema curenta de conexiune este deja "optiunile firmei curente"; nu exista randare multi-firma in acelasi tabel. Confirmat si de codul VFP: frm_optiuni.cschema e setat la constanta de compilare CONTAFIN_ORACLE (oOptiuni.vc2:1089, acelasi simbol folosit peste tot in COMUN pentru "schema firmei curente"), iar getoptiunefirma(tcS, tcOptiune) primeste un parametru de schema (tcS, azi mereu USER) dar nu il foloseste in interogare — select varvalue from optiuni fara calificare de schema (cod exact la sectiunea 1.2) — pentru ca sesiunea Oracle e deja conectata direct in schema firmei. tcS ramane doar din compatibilitate istorica cu supraincarcarea getOptiuneFirma(tcOptiune) (fara schema), care apeleaza pe cea cu doi parametri cu user (sectiunea 1.2).

1.2 Semnatura si contract — PACK_SESIUNE.getoptiunefirma

Sursa curenta confirmata prin ALL_SOURCE pe pachetul live (PACK_SESIUNE, tip PACKAGE BODY) — identica, verificat, cu ultima versiune gasita in SCRIPTURI_CLAR (2014/04/ff_2014_04_24_01_COMUN_PACK_SESIUNE.sql:328-350; nicio modificare de atunci, cautare FUNCTION getoptiunefirma in SCRIPTURI_CLAR/2024, /2025, /2026 — zero rezultate):

FUNCTION getoptiunefirma(tcS IN VARCHAR2, tcOptiune IN VARCHAR2)
  RETURN VARCHAR2 IS
  lcValue Optiuni.Varvalue%Type := '';
BEGIN
  BEGIN
    select varvalue
      INTO lcValue
      from optiuni
     where UPPER(TRIM(VARNAME)) = UPPER(TRIM(tcOptiune));
  EXCEPTION
    WHEN OTHERS THEN
      lcValue := '';
  END;
  RETURN lcValue;
END;

FUNCTION getOptiuneFirma(tcOptiune IN VARCHAR2) RETURN VARCHAR2 IS
  lcValue Optiuni.Varvalue%Type := '';
BEGIN
  lcValue := getOptiuneFirma(user, tcOptiune);
  return lcValue;
END;

Contract, verificat pe RETURN, nu dedus din nume:

  • Parametru: numele optiunii (tcOptiune), cautat UPPER(TRIM(...)) — insensibil la caz si la spatii; a doua forma (getOptiuneFirma(tcOptiune), un singur parametru) e cea folosita azi peste tot in pack_facturare (vezi sectiunea 2) — deleaga la forma cu doi parametri cu user.
  • Cand optiunea NU exista (NO_DATA_FOUND, prins de WHEN OTHERS generic): RETURN '' (string gol), niciodata NULL explicit si niciodata exceptie propagata. Insa in Oracle un VARCHAR2 egal cu '' este NULL la nivel de reprezentare (Oracle nu distinge stringul gol de NULL) — deci orice apelant care testeaza IF V_X IS NULL THEN dupa un apel la getoptiunefirma prinde si cazul "optiune inexistenta", fara cod suplimentar. Acesta e exact tiparul folosit de toti apelantii gasiti (sectiunea 2).
  • WHEN OTHERS THEN lcValue := '' inghite orice eroare, nu doar NO_DATA_FOUND (de ex. si TOO_MANY_ROWS daca ar exista vreodata doua randuri cu acelasi VARNAME — nu exista constrangere UNIQUE pe VARNAME, doar convenția aplicatiei). Nu e un risc nou introdus de propunerea de fata — e comportamentul mecanismului de 15+ ani, pastrat ca atare.
  • Variante: o singura functie, intotdeauna VARCHAR2. Nu exista getoptiunefirma numerica/booleana separata in Oracle — conversia se face la apelant, in PL/SQL cu TO_NUMBER(NVL(...)) (exemplu confirmat, acelasi fisier, scrie_incasare2, ff_...:13177: TO_NUMBER(NVL(pack_sesiune.getoptiunefirma('D406'), '0'))) sau in VFP cu VAL()/CTOD()/etc., pe baza coloanei VARTYPE (vezi oinit_optiuni.prg:179-211, functia actualizeaza_optiuni_program, care materializeaza fiecare optiune intr-o variabila globala VFP cu prefix dupa tip: gc<nume> pentru CHARACTER, gn<nume> pentru NUMERIC, gl<nume> pentru LOGICAL etc.). Pentru un cont contabil (VARCHAR2(4)), varianta corecta e cea de baza, VARTYPE='CHARACTER' — exact tipul folosit de toate exemplele cu cont din sectiunea 2, fara nicio conversie necesara la citire in PL/SQL (V_SCD e deja VARCHAR2).

1.3 Ecranul de editare — complet generic peste tabel

COMUN\clase\oOptiuni.vc2, doua clase relevante:

  • frm_optiuni (:1064-1314) — grid pe view-ul VFP local v_optiuni (populat dintr-un SELECT * FROM <schema>.optiuni, vezi oinit_optiuni.prg:337 in viz_optiuni), 4 coloane (varname, vartype, varvalue, vardesc), cu cautare doar dupa varname LIKE (do_cauta, :1261-1278) si butoane Adauga/Modifica/Sterge care deschid frm_optiuni_nou.
  • frm_optiuni_nou (:1316-1462) — formular Adauga/Modifica cu 4 campuri: varname (text, Format="!K" = uppercase), vartype (combobox cu lista fixa CHARACTER,CURRENCY,NUMERIC, DATETIME,DATE,LOGICAL), varvalue (text), vardesc (text). Validare la salvare (inainte_de_do_termin, :1417-1450): doar "nu e gol" pe varname, vartype, varvalue — nicio validare de format sau de continut (nu verifica lungime, nu verifica daca varvalue e un cont existent in planul de conturi, nimic specific per optiune).
  • cus_odata_optiuni (:139-206) — clasa de persistenta: INSERT/UPDATE/DELETE generic pe optiuni (varname, vartype, varvalue, vardesc) — confirma ca orice cheie noua functioneaza fara nicio schimbare la acest cod; scrie exact cele 4 coloane editabile din ecran.

Concluzie la intrebarea "adaugarea unei optiuni noi cere cod nou in ecran": NU. Ecranul e generic peste tabel dupa cele 4 coloane editabile. Randul nou (FACT_SCD_ARTFPRET, sectiunea 3) apare automat in grid dupa ce e inserat, si e editabil din prima fara nicio modificare VFP.

Nota conexa, nu necesara pentru mecanismul Oracle: la fiecare pornire de sesiune, VFP materializeaza toate randurile din OPTIUNI in variabile globale (optiuni_firma, oinit_optiuni.prg:234-310), filtrate Isnull(programe) Or gcNumeProgram $ programe — deci coloana PROGRAME conteaza doar pentru vizibilitatea in acest mecanism global VFP, nu pentru getoptiunefirma (care nu se uita deloc la PROGRAME). Optiunea noua nu are nevoie de acest canal VFP (Oracle o citeste direct), dar completarea corecta a PROGRAME evita zgomot/confuzie daca cineva se uita in frm_optiuni din ROAFACTURARE si se asteapta sa vada optiunea listata acolo cu gcNumeProgram = 'ROAFACTURARE' in PROGRAME.

2. Exemple reale de optiuni existente, cu lantul complet

2a. RF_CONT_INCASARE_* — exact tiparul cerut, in acelasi pachet, pe acelasi camp SCD

Cel mai relevant exemplu posibil: patru optiuni care alimenteaza direct SCD pe o nota contabila, in pack_facturare.scrie_incasare2 — aceeasi functie Oracle pe care propunerea de la canal_cont_venit_fara_politica.md o modifica (acelasi fisier, ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql).

Randul din tabel (interogat direct, 4 randuri, VARTYPE CHARACTER la toate):

VARNAME VARVALUE azi VARDESC PROGRAM PROGRAME
RF_CONT_INCASARE_BONFISCAL 5311 CONTUL DEBITOR PENTRU NOTA DE INCASARE 5311 = 4111 ROAFACTURARE ROAFACTURARE,ROAACNPRO,ROACOMENZI,ROACONTRACTE,ROAGEST,ROARESTAURANT
RF_CONT_INCASARE_CARDBANCAR 5125 CONTUL DEBITOR PENTRU NOTA DE INCASARE 5113 = 4111 idem idem
RF_CONT_INCASARE_TICHETE 5323 CONTUL DEBITOR PENTRU NOTA DE INCASARE 5323 = 4111 idem idem
RF_CONT_INCASARE_CHITANTA 5311 CONTUL DEBITOR PENTRU NOTA DE INCASARE 5311 = 4111 idem idem

(VARDESC mentioneaza si = 4111 — nu e o eroare de copy-paste: e nota ca partea de credit a notei de incasare e contul de clienti 4111, deci descrierea documenteaza ambele parti ale notei, nu doar valoarea implicita a optiunii.)

Insertia originala (SCRIPTURI_CLAR/2010/08/ff_2010_08_11_01_OPTIUNI.sql:9-19), tiparul de migrare de urmat:

insert into optiuni (VARNAME, VARTYPE, PROGRAM, VARVALUE, VARDESC, ID_PRG_OWNER, PROGRAME)
values ('RF_CONT_INCASARE_BONFISCAL', 'CHARACTER', 'ROAFACTURARE', '5311',
        'CONTUL DEBITOR PENTRU NOTA DE INCASARE 5311 = 4111', null, 'ROAFACTURARE');

Apelul din PL/SQL (ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:13161-13234, PROCEDURE scrie_incasare2), citit integral — exact tiparul "optiune cu fallback hardcodat" cerut de decizia 36:

V_SCD := V_PSCD;  -- parametru explicit, daca a fost dat de apelant (ff_...:13185)
CASE
  WHEN V_TIP = nTipIncasareBonFiscal THEN
    ...
    IF V_SCD IS NULL THEN
      V_SCD := PACK_SESIUNE.getoptiunefirma('RF_CONT_INCASARE_BONFISCAL');
    END IF;
    IF V_SCD IS NULL THEN
      V_SCD := '5311';                                    -- fallback hardcodat, instalare veche
    END IF;
  ...
END CASE;

Trei niveluri, in ordine: (1) parametru explicit daca a fost dat, (2) optiunea de firma, (3) constanta hardcodata — folosita si daca randul din OPTIUNI lipseste complet (instalare veche, migrare neaplicata) si daca a fost sters/golit manual din ecran. Acest cont ajunge apoi direct in INSERT INTO ACT_TEMP (..., SCD, ...) (ff_...:13241-13249 in continuare), fara nicio validare suplimentara de format sau de existenta in planul de conturi — nici in Oracle, nici in ecranul de optiuni (sectiunea 1.3), nici la INSERT.

Ecranul de editare: acelasi frm_optiuni/frm_optiuni_nou generic (sectiunea 1.3) — niciun ecran dedicat pentru aceste 4 optiuni, se editeaza ca text simplu in grid.

2b. D406 — optiune numerica/booleana folosita ca flag, cu conversie explicita la citire

VARNAME='D406', VARTYPE='NUMERIC', VARVALUE='1', PROGRAM='ROACONT', PROGRAME='ROACONT,ROAAUTO,ROACONTRACTE,ROADEVIZE,ROAFACTURARE,...'. Citita in acelasi scrie_incasare2 (ff_...:13177): lnD406 := TO_NUMBER(NVL(pack_sesiune.getoptiunefirma('D406'), '0')) — tipar de citire pentru optiune numerica: getoptiunefirma intoarce mereu text, apelantul face NVL(...,'0') inainte de TO_NUMBER (aici fallback-ul '0' e in acelasi loc cu apelul, nu separat ca la RF_CONT_INCASARE_* — variatie minora de stil intre autori, nu o regula diferita).

2c. CONT411 si DEVCONTALTELE — optiuni "cont" mai vechi, azi orfane in cod

CONT411 (VARTYPE='CHARACTER', VARVALUE='4111', VARDESC='411 SAU 4111', fara PROGRAM) si DEVCONTALTELE (VARTYPE='CHARACTER', VARVALUE='704', VARDESC='CONT ALTE SERVICII FACTURA', PROGRAM='ROAAUTO') — cautare grep pentru ambele in tot SCRIPTURI_CLAR: niciun apelant activ gasit (doar insertiile originale din 2011). Probabil cod dezafectat sau folosit doar din alt produs/raport neexaminat aici. Mentionate pentru completitudine si pentru ca CONT411 confirma exact valoarea implicita ceruta de Marius (4111) ca precedent de configurare tot pe un cont de clienti — dar nu au un lant activ de apel, deci nu sunt un exemplu de "tipar in uz" la fel de tare ca RF_CONT_INCASARE_*.

2d. EFACTURA_CONT_ART_E/EFACTURA_CONT_ART_P — optiune "cont implicit pe articol", azi goala

VARTYPE='CHARACTER', VARVALUE goala azi (nesetata pe baza curenta), VARDESC='CONT ARTICOLE IMPLICIT FACTURI EMISE'/'...PRIMITE', PROGRAM='ROACONT'. Confirma ca tiparul "cont implicit configurabil, gol pana e setat manual" exista deja ca optiune (nu s-a putut verifica in aceasta runda cine o citeste — cautare in afara scopului, modulul ROACONT/eFactura nu a fost deschis). Relevanta doar ca a patra confirmare a conventiei de nume (EFACTURA_CONT_ART_<sufix>), nu ca lant complet verificat.

3. Propunerea concreta

3.1 Cheia optiunii

FACT_SCD_ARTFPRET — respecta conventia dominanta observata in tabel: prefix de modul (FACT pentru optiunile specifice pack_facturare/ROAFACTURARE, ca FACTSETURI, FACTALGREPCOM, FACTURACUCHITANTA, FACTURAEMAIL, FACTURASOLD — toate PROGRAM='ROAFACTURARE') plus sufix descriptiv scurt fara diacritice si fara spatii (SCD = campul contabil vizat, ARTFPRET = "articol fara politica de pret" — in oglinda cu numele deja folosit in proiectarea anterioara, "ramura fara politica"). Nicio cheie SCD/SCC existenta azi in tabel (cautare directa, zero rezultate) — nu exista risc de coliziune de nume. Alternativa mai scurta, daca Marius prefera: SCD_FARA_POLITICA (fara prefix de modul) — tiparul din tabel nu e strict, exista si chei fara prefix (D406, CONT411); prefixul FACT_ e recomandat, nu obligatoriu.

3.2 Valoarea implicita si unde traieste

Tiparul deja stabilit si folosit de RF_CONT_INCASARE_* (sectiunea 2a) se copiaza identic: implicitul traieste in doua locuri, nu unul:

  1. In randul din OPTIUNI, la instalare — valoarea VARVALUE='4111' scrisa direct de scriptul de migrare (sectiunea 3.4). Asta e valoarea pe care o vede si o poate schimba Marius/clientul din frm_optiuni, fara recompilare — exact cerinta deciziei 36.
  2. Hardcodat in PL/SQL, langa apelul getoptiunefirma, ca a doua plasa de siguranta pentru instalari vechi unde migrarea nu a rulat inca sau randul a fost sters/golit manual din ecran:
V_SCD := PACK_SESIUNE.getoptiunefirma('FACT_SCD_ARTFPRET');
IF V_SCD IS NULL THEN     -- acopera si randul lipsa, si VARVALUE gol/sters din ecran (sectiunea 1.2)
  V_SCD := '4111';
END IF;

Plasata in ramura noua din contabilizeaza_articol (canal_cont_venit_fara_politica.md:146, randul SCD din tabelul design-ului), in locul liniei SCD := '4111' hardcodat propuse acolo — inlocuire punctuala, restul ramurii (ASCD calculat din GetAnaliticByGrupUtilizatori(..., V_SCD), deja dependent de V_SCD) ramane neschimbat, primeste automat valoarea corecta indiferent de sursa (optiune sau fallback).

3.3 Comportamentul cand optiunea lipseste sau e invalida

  • Lipseste randul din OPTIUNI (instalare veche, migrare neaplicata): getoptiunefirma intoarce '' -> tratat IS NULL in Oracle -> fallback la '4111' hardcodat (sectiunea 3.2, pasul 2). Acoperit prin constructie, acelasi tipar ca RF_CONT_INCASARE_*.
  • Randul exista dar VARVALUE e gol (sters manual din ecran, fara sa fi fost stearsa cheia): identic cazului anterior — '' tot IS NULL in Oracle. Acoperit prin constructie.
  • VARVALUE contine un cont care nu exista in planul de conturi, sau un string cu lungime/ format invalid: nu exista nicio validare azi, nici in getoptiunefirma, nici in ecranul de optiuni (sectiunea 1.3, "nicio validare de format sau de continut"), nici la INSERT INTO ACT_TEMP (coloana SCD e VARCHAR2(4) NULL fara CHECK, fara FK, confirmat in DDL-ul deja citat in canal_cont_venit_fara_politica.md, sectiunea DDL). Un cont inexistent ar ajunge pe nota neschimbat — exact acelasi risc pe care il are deja RF_CONT_INCASARE_* de 15 ani, nu unul nou introdus de aceasta propunere. Daca se doreste o garda, ar trebui adaugata la citire (in ramura noua din contabilizeaza_articol, dupa cele doua atribuiri de mai sus, cu un SELECT COUNT(*) FROM PLCONT WHERE COD_CONT = V_SCD sau echivalent) — nu exista azi un precedent de validare pe niciuna dintre optiunile de tip cont examinate, deci adaugarea uneia ar fi o imbunatatire noua, nu o continuare a unui tipar existent; de decis explicit (sectiunea 4).
  • Lungime > 4 caractere in VARVALUE (campul din tabel e VARCHAR2(1000), mult mai lat decat ACT_TEMP.SCD VARCHAR2(4)): ar da ORA-12899 (value too large) la INSERT INTO ACT_TEMP daca cineva scrie din greseala un text lung in ecran — eroare Oracle standard, nu un NULL/gol tacut; comportament acceptabil ca gardă minimala "gratuita", fara cod suplimentar.

3.4 Scriptul de migrare — schita, neaplicata

Tiparul exact al insertiei RF_CONT_INCASARE_BONFISCAL (sectiunea 2a), idempotent prin verificarea existentei prealabile (tipar comun in scripturile de migrare vazute in SCRIPTURI_CLAR, desi insertia originala din 2010 nu avea garda — cea de mai jos o adauga, mai sigura pentru un script care ar putea rula de doua ori):

-- ff_<data>_NN_COMUN_OPTIUNI.sql (schita, neaplicata)
DECLARE
  V_CNT NUMBER;
BEGIN
  SELECT COUNT(*) INTO V_CNT FROM OPTIUNI WHERE UPPER(TRIM(VARNAME)) = 'FACT_SCD_ARTFPRET';
  IF V_CNT = 0 THEN
    INSERT INTO OPTIUNI (VARNAME, VARTYPE, PROGRAM, VARVALUE, VARDESC, PROGRAME)
    VALUES ('FACT_SCD_ARTFPRET', 'CHARACTER', 'ROAFACTURARE', '4111',
            'CONTUL DEBITOR (SCD) PENTRU ARTICOL FACTURAT FARA POLITICA DE PRET',
            'ROAFACTURARE');
  END IF;
END;
/
exec pack_migrare.UpdateVersiune('ff_<data>_NN_COMUN_OPTIUNI');
commit;

ID_PRG_OWNER omis (rand NULL in toate exemplele citate, coloana pare neutilizata activ pentru optiuni de firma simple). PROGRAME='ROAFACTURARE' — restrans, spre deosebire de RF_CONT_INCASARE_* care listeaza 6 produse; de largit doar daca se confirma (in afara scopului acestei cercetari, sectiunea "Ce ramane de decis") ca alte produse din suita ajung sa apeleze aceeasi ramura din contabilizeaza_articol prin adauga_articol_factura simplu.

3.5 Validare la salvare in ecran

Nu — confirmat la sectiunea 1.3: frm_optiuni_nou valideaza doar "camp nevid" pe cele 3 campuri principale, nicio validare specifica per-cheie. Optiunea noua se comporta identic cu restul tabelei: utilizatorul poate scrie orice text de pana la 1000 caractere in VARVALUE, cu riscurile descrise la sectiunea 3.3.

4. Ce ramane de decis

  1. Numele exact al cheii — FACT_SCD_ARTFPRET propus (sectiunea 3.1); Marius poate prefera alt nume sau formatul mai scurt SCD_FARA_POLITICA.
  2. Se adauga o validare a contului la citire (cont trebuie sa existe in planul de conturi) sau se pastreaza tiparul actual, fara validare, ca la RF_CONT_INCASARE_*? Niciun exemplu existent nu valideaza — a introduce validare ar fi prima data cand se face asta pe o optiune de tip cont.
  3. PROGRAME restrans la ROAFACTURARE sau extins ca la RF_CONT_INCASARE_* (6 produse)? Tine de raspunsul, inca deschis in parametru_cont_contabilizeaza_articol.md sectiunea 2d, la intrebarea daca alte produse din suita apeleaza adauga_articol_factura simplu.
  4. Textul exact din VARDESC — schita de mai sus e o propunere, nu o cerinta.

Ce nu s-a putut stabili

  • Cine citeste azi EFACTURA_CONT_ART_E/EFACTURA_CONT_ART_P (sectiunea 2d) — cautarea s-a oprit la insertia originala; modulul ROACONT/eFactura nu a fost deschis, in afara scopului cerut (exemplul a servit doar ca a patra confirmare de conventie de nume, nu ca lant complet).
  • Definitia view-ului VFP local v_optiuni (folosit ca RecordSource in frm_optiuni) — e un cursor/view generat dinamic prin gencursor()/goExecutor.oExecute() din oinit_optiuni.prg, nu un obiect Oracle persistent (interogare DBMS_METADATA pe V_OPTIUNI a esuat cu "object not found", asteptat) — nu schimba nimic din propunere, doar noteaza ca numele nu desemneaza o vedere Oracle.
  • Daca CONT411/DEVCONTALTELE (sectiunea 2c) mai au vreun apelant in alt produs din suita (ROACONT, ROAGEST etc.) — cautarea s-a limitat la SCRIPTURI_CLAR (tot codul PL/SQL istoric); nu s-a cautat in .vc2/.prg din alte COMUN-uri de produs.