Files
comun/docs/cercetare/rec_integrari.md
Marius Mutu 09ddeabb1c docs: cercetarile trans-proiect din ROAFACTURARE trec in COMUN
Paisprezece rapoarte care nu erau ale ROAFACTURARE traiau in docs\cercetare\ al
acelui proiect: valuta si curs in ofacturare, TVA calculat vs salvat plus
denormalizarea VANZARI, inventarul consumatorilor VANZARI din toata suita ROA,
integrarile de contracte/politici/nomenclator (#10, #11, #12), watchdog-ul VFP
de testare, proiectarea Oracle a scrierii din S5 si view-ul VVANZARI_ARTICOLE.

Motivul mutarii, nu doar al pastrarii: planurile #10, #11 si #12 sunt amanate,
iar indexul lor spune explicit ca se reiau din aceste rapoarte - deci sunt punct
de plecare, nu istoric. Iar tinta lor e COMUN plus ROAPRETURI/ROACONTRACTE.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
2026-08-11 22:31:53 +03:00

24 KiB

Cercetare: integrare CONTRACTE, politici de preturi, nomenclator ca lista de preturi

Metoda: vfp_symbols.ps1 (cache text ROAFACTURARE deja la zi) + Grep pe .prg/.vc2/.mn2. Fapte cu fisier:linie; ipoteze marcate IPOTEZA:.

SUBIECT A - Integrare pagina CONTRACTE (todo #10)

1. Unde exista azi contractele

Produs separat, working copy completa: D:\ROA\ROACONTRACTE (.git + .svn, roaContracte.pjx, roacontracte.exe). Structura: Clase\ (ofundal.vcx, onom_clienti.vcx, oOptiuni.vcx, roaclienti.vcx, ferestre_contracte.vcx - probabil formularele CRUD de contracte), Ferestre\, Programe\, Rapoarte\, Meniuri\, COMUN\ (propria copie a librariei partajate), Teste\, docs\.

Important: ROAFACTURARE NU e izolat de contracte azi - are deja o integrare de facturare partiala "pe baza de contract" (vezi punctul 4), care citeste direct din schema Oracle a ROACONTRACTE prin view-uri (vcontracte, fact_vcontracte, tipuri_contracte), fara pagina de editare. ferestre_contracte.vcx din ROACONTRACTE contine probabil formularele CRUD care ar trebui aduse in ROAFACTURARE (nu au fost deschise/citite - binar, necesita conversie separata daca se trece la implementare).

Exista deja urme ale unei integrari partiale de UI in ROAFACTURARE:

  • Meniuri\contracte.mnx/.mn2 (D:\ROA\ROAFACTURARE\Meniuri\contracte.mn2:1) - NU e un meniu de administrare contracte, ci un shortcut-popup cu 3 optiuni de facturare ("Factura fiscala lei / Invoice / Factura fiscala valuta") - cf. continut citit integral.
  • Grafice\icon_contracte1.png, icon_contracte2.png, Grafice\Originale\contracte.png - iconite deja pregatite in ROAFACTURARE.

2. Cum e integrata azi COMENZI in ROAFACTURARE (sablonul de urmat)

COMENZI nu e produs separat legat prin exe, ci cod montat direct in ROAFACTURARE din COMUN\ (librarie partajata gitea.romfast.ro:romfast/comun.git, cf. CLAUDE.md). Exista si un produs stand-alone D:\ROA\ROACOMENZI (cu .pjx propriu), dar in ROAFACTURARE comenzile sunt o pagina/panou montat direct in formularul principal (fundal), nu un exe separat lansat.

Reteta pas cu pas (comenzi ca model pentru contracte):

  1. Clasa container ct_comenzi din COMUN\clase\ocomenzi.vcx (.vc2 cache: COMUN\clase\ocomenzi.vc2) - contine formulare/containere CRUD comenzi (frm_optiuni_comenzi, cursoare vcomenzi_elemente etc.).
  2. Montare in formularul principal: containerul e plasat ca obiect copil in Clase\ofundal_facturare.vc2 (form fundal), cu comentariul < END OBJECT: ClassLib="..\comun\clase\ocomenzi.vcx" BaseClass="container" /> in jurul liniei Clase\ofundal_facturare.vc2:831; obiectul se numeste lb_comenzi (Clase\ofundal_facturare.vc2:824).
  3. Butoane de actiune ("Cw" = clase de tip buton-cu-drept, vezi punctul 3) legate la proceduri business, ex. Page2.Cw3.do_actiune -> DO facturare_comenzi IN oproceduri_facturare.prg (Clase\ofundal_facturare.vc2:899-902).
  4. Inregistrare in Programe\roafacturare.prg (entry point):
    • SET CLASSLIB TO ocomenzi ADDITIVE sub comentariul *** COMENZI (Programe\roafacturare.prg:180-181);
    • SET PROCEDURE TO orap_comenzi.prg / onom_comenzi.prg / update_comenzi.prg ADDITIVE (Programe\roafacturare.prg:239-242), tot sub *** COMENZI;
    • variabile module: PRIVATE pocomenzi,pocomenzielemente,polucrari,pocomenzi2,polucrarielemente (Programe\roafacturare.prg:246-247).
    • Toate cele 3 .prg (orap_comenzi.prg, onom_comenzi.prg, update_comenzi.prg) si clasa ocomenzi.vcx/.vct locuiesc fizic in COMUN\programe\ / COMUN\clase\, dar sunt inregistrate ca membri ai proiectului roafacturare.pjx (confirmat prin Grep pe .pjx: COMUN\clase\ocomenzi.vcx, COMUN\programe\orap_comenzi.prg etc. apar in el).
  5. Business logic de facturare din comenzi: Procedure facturare_comenzi in COMUN\programe\oproceduri_facturare.prg:139-141 - un simplu factureaza(3) (tip document 3 = "din comanda", motorul central factureaza() face restul).
  6. Meniu: nu exista Meniuri\comenzi.mnx separat in ROAFACTURARE - comenzile nu au intrare de meniu proprie, ci doar butonul Cw3 de pe pagina fundal (Page2 = "Facturare"). Contractele au deja Meniuri\contracte.mnx dar cu alt continut (shortcut factura), deci pentru pagina noua de contracte ar trebui fie extins acest fisier, fie creat altul.

Concluzie sablon: pentru CONTRACTE ar insemna (a) o clasa container tip ct_contracte (posibil adaptata din ferestre_contracte.vcx al ROACONTRACTE, mutata/duplicata in COMUN\clase\), (b) montarea ei ca obiect in ofundal_facturare.vc2 langa lb_comenzi, (c) inregistrare SET CLASSLIB/SET PROCEDURE in roafacturare.prg sub un bloc nou *** CONTRACTE, (d) adaugare in roafacturare.pjx.

3. Mecanismul de DREPTURI pe obiecte

Sursa: COMUN\programe\acces_meniu.prg (fisier citit integral).

  • Sursa de date: view Oracle contafin_oracle.vdef_util_obiecte, interogat cu select cheie,id_firma from contafin_oracle.vdef_util_obiecte where id_util=?gnIdUtil and id_program=?gnIdProgram and id_firma=?gnIdFirma (acces_meniu.prg:29-31), rezultat in cursorul crsdrepturi (o singura coloana cheie relevanta: cheie, string).
  • Codificarea cheii: concatenare de "caractere de nivel" - Chr(lnKey) pentru fiecare nivel de pageframe/pagina (dezactiveaza_obiecte_pageframe, acces_meniu.prg:103-165, recursiv pe subpageframe-uri), plus un cod de 2 cifre pentru fiecare buton Cw*: lcCheie = lcKey + Padl(Alltrim(Str(.Objects(l).nid_cw)), 2, '0') (acces_meniu.prg:138). Fiecare obiect Cw* are proprietatea nid_cw (numarul lui in cadrul paginii) si la runtime i se seteaza ccheie (acces_meniu.prg:140) si coptiuni_active (lista de operatii CRUD permise, citita din caracterele urmatoare cheii - acces_meniu.prg:141-149). Butonul apeleaza .Objects(l).activeaza() / .dezactiveaza() in functie de gasire (acces_meniu.prg:150-152).
  • Pentru imagini/iconite (nivel diferit, folosit pe alte forme): proprietate ccod pe obiect (acces_meniu.prg:48), aceeasi logica de cautare in crsdrepturi.
  • Cod de meniu (pad-uri): GetAccesByCod(tcCod, tcAccesDefault) (acces_meniu.prg:236-276) cauta o cheie explicita (cod optiune meniu, ex. "ZA01") in crsdrepturi si intoarce lista de operatii permise (ex. "1;2;3;4").
  • Punct de intrare: verifica_drepturi(tcObiectFundal, tcPageFrame) (acces_meniu.prg:9-15) apelat din formularul fundal (Ferestre\fundal.sc2:699: verifica_drepturi('gofundal','_pgfrmbase1')), care incarca crsdrepturi o singura data per firma (cache in memorie, citeste_drepturi, acces_meniu.prg:17-37) si dezactiveaza in cascada paginile/butoanele/meniurile fara drept.
  • Administrare drepturi (unde se declara catalogul de obiecte si se atribuie pe grupuri): COMUN\clase\drept_grupuri.vc2 - frm_grupuri, apel catre pachetul Oracle PACK_DREPTURI.grupdreptmodproc (COMUN\clase\drept_grupuri.vc2:39) si citeste_drepturi (loRec.id_grup) (COMUN\clase\drept_grupuri.vc2:205).

IPOTEZA: catalogul efectiv de "obiecte disponibile pentru ROAFACTURARE" (denumirile/codurile nid_cw/ccod/coduri de meniu, ex. cele pentru COMENZI) e definit partial in designerul VFP (proprietatea nid_cw seteaza pe fiecare buton la design-time in .scx/.vcx) si partial server-side in schema Oracle contafin_oracle (tabelul din spatele view-ului vdef_util_obiecte, populat probabil printr-un script de instalare/migrare, nu vazut in sursa VFP). Pentru "comasarea" drepturilor ROACONTRACTE + ROAFACTURARE mentionata in cerere, ar trebui inspectat acest tabel server-side (in afara sursei VFP disponibile aici) plus alocarea de noi nid_cw pentru butoanele noi de contracte, fara sa coincida cu cele deja folosite de COMENZI/ lista de preturi/avize pe aceeasi pagina.

Exemplu concret COMENZI: butonul Page2.Cw3 (facturare din comenzi) foloseste automat cheia <cheie_pagina>+'03' (Cw3 => nid_cw=3); pentru un buton nou de contracte pe aceeasi pagina ar trebui un nid_cw neutilizat (ex. 11+, dat fiind ca Page2 are deja Cw1..Cw9 conform Clase\ofundal_facturare.vc2:882-926).

4. Facturarea pe baza de comanda / pe baza de contract

Comanda -> factura: Procedure facturare_comenzi (COMUN\programe\oproceduri_facturare.prg: 139-141) => factureaza(3). Cautarea comenzii disponibile pentru facturare: Function caut_comanda_gestiune (COMUN\programe\oproceduri_facturare.prg:1961-1983), citeste din view-ul vcomenzi (... FROM ] + gcS + [.vcomenzi), filtru facturat = 0 and interna = 3 ... (linia 1977).

"Pe baza de contract" EXISTA DEJA, mai complet decat comenzile pe alocuri:

  • Procedure facturare_contracte(tcTip) (COMUN\programe\oproceduri_facturare.prg:119-136) - primeste tipul de document ("FACTURA LEI"/"INVOICE"/"FACTURA VALUTA") si apeleaza factureaza(2)/factureaza(6)/factureaza(52).
  • Buton pe pagina fundal: Page2.Cw2.do_actiune (Clase\ofundal_facturare.vc2:886-897) - meniu xmenu cu cele 3 optiuni, cheama facturare_contracte.
  • Cautare contract: Function caut_contract_facturare(tnIdPart, tcSirTipFacturare) (COMUN\programe\oproceduri_facturare.prg:1986-2021) - citeste din view-ul fact_vcontracte (select id_ctr, contract, numar, data, denumire, scadenta_incasare, opt_facturare, text_standard, afisare_scadenta FROM fact_vcontracte, linia 2001), filtrat pe opt_facturare in (...) si id_part.
  • Alegerea contractului la factura: frm_date_factura.do_cauta_contract (COMUN\clase\ofacturare.vc2:9067-9115) si frm_date_aviz.do_cauta_contract (COMUN\clase\ofacturare.vc2:7049-7051) apeleaza caut_contract_facturare.
  • Editorul de articole pe factura are un tab/grid dedicat contractelor: frm_facturare_articole cu controale grd_contracte, cb_contracte (combobox cu ratele / contractele), populate din cursorul crscontracte (COMUN\clase\ofacturare.vc2:15069-15107 si in jur). Optiunea opt_facturare din fact_vcontracte/crsfactura marcheaza randurile "din contract" (COMUN\programe\oproceduri_facturare.prg:176-177, Inlist(opt_facturare,1,2) in alt context legat de seturi).
  • Aviz pe baza de contract: exista si un tip de aviz "26 - catre clienti din contract" (COMUN\programe\oproceduri_facturare.prg:207, enumerat si in caut_avize, COMUN\programe\oproceduri_facturare.prg:2045), apelat din emitere_aviz_clienti(tnTip=3).

Concluzie: motorul de facturare din contract e deja complet functional in ROAFACTURARE (citire din schema ROACONTRACTE prin view-uri Oracle vcontracte/fact_vcontracte/tipuri_contracte). Ce lipseste conform cererii e (a) o pagina de editare CRUD a contractelor in ROAFACTURARE (azi doar in exe-ul separat ROACONTRACTE) si (b) rapoarte de contracte in ROAFACTURARE, plus (c) unificarea drepturilor. Nu a fost gasit niciun raport de contracte in ROAFACTURARE\Rapoarte\ (glob *contract* nu a dat .frx in Rapoarte, doar meniu/iconite).


SUBIECT B - Politici de preturi (todo #11)

5. Unde sunt azi definite/editate

Produs separat, mic, dedicat: D:\ROA\ROAPRETURI (.pjx propriu, roapreturi.exe). Structura: Programe\onom_preturi.prg, Programe\update_preturi.prg, Programe\update_nomenclator.prg, Clase\opreturi.vcx, Clase\onom_preturi.vcx, Clase\ofundal_preturi.vcx, Clase\ofundal_roapreturi.vcx, Ferestre\fundal.scx. (Continutul acestor clase nu a fost convertit in text - ROAPRETURI nu are un cache text propriu generat in aceasta sesiune; doar structura de fisiere a fost inspectata.)

Interfata de editare pare sa fie un produs desktop de sine statator, distinct de ROAFACTURARE si de ROACONT, focalizat strict pe politici/liste de preturi si pe actualizarea nomenclatorului (update_nomenclator.prg sugereaza ca ROAPRETURI scrie si in nomenclatorul comun de articole).

6. Tabele/view-uri implicate (identificate din ROAFACTURARE)

Din codul ROAFACTURARE care CITESTE politici de preturi (nu editeaza), gasite:

  • vcrm_politici_preturi - view folosit in cautare dupa drepturi utilizator (COMUN\clase\baza.vc2:10087, :10157, :10502-10512). Interogare efectiva: select nume_lista_preturi, id_pol from crm_vpolpretcurutil (COMUN\clase\baza.vc2:10504) - deci exista si view-ul crm_vpolpretcurutil ("politica de pret curenta pentru utilizator"), cheie id_pol.
  • vvanzari_detalii - contine coloana nume_lista_preturi folosita in rapoarte de marfa (COMUN\clase\configurare.vc2:3915-3972, frm_raport_marfa).
  • Meniu dedicat facturarii pe lista de preturi: Meniuri\politica.mnx/.mn2/.MPR in ROAFACTURARE; procedura facturare_lista_de_preturi = Do politica.mpr (COMUN\programe\oproceduri_facturare.prg:113-116), buton Page2.Cw1.do_actiune (Clase\ofundal_facturare.vc2:882-884).
  • Prefixul crm_/CRM in numele tabelelor/view-urilor (vcrm_politici_preturi, crm_vpolpretcurutil) sugereaza schema/modul Oracle numit "CRM", separat de schema principala de facturare (gcS). IPOTEZA: politicile de pret sunt un modul Oracle transversal (folosit si de ROAGEST, ROAPRETURI, ROACONTRACTE), nu proprietatea exclusiva a unui singur produs VFP.
  • Comenzile (ROACOMENZI/ocomenzi.vcx) au propriul mecanism de asociere pret-din-comanda: globale gnIdPoliticaPret, gnId_lista_preturi_PV (Programe\roafacturare.prg:467,469), folosite si in frm_optiuni_comenzi (COMUN\clase\ocomenzi.vc2:6488-6686, variabila gnID_LISTA_PRETURI_PV = politica de pret "de productie" folosita la generarea automata a comenzilor). Cursorul de articole al comenzii are coloanele id_pol, nume_lista_preturi, pret, pret_cu_tva, ptva direct in el (COMUN\clase\ocomenzi.vc2:1227-1229, cursor creat din view-ul vcomenzi_elemente).

Nu a fost gasita nicio schema DBF/DDL explicita pentru "politici de preturi" / "liste de preturi" in sursa VFP (tabelele reale sunt Oracle, definite server-side; VFP le vede doar prin view-uri enumerate mai sus). N-a fost identificat un tabel separat de "note contabile asociate politicii de pret" in codul cercetat - contul contabil de vanzare pare sa vina din nomenclatorul de articole (nom_articole.cont, vezi punctul 10), nu dintr-o tabela separata legata de politica.

7. Ce foloseste ROAFACTURARE azi din aceste date

  • Facturare pe lista de preturi (Do politica.mpr) - flux complet de vanzare pe baza unei politici de pret selectate (analog cu vanzarea din stoc/comenzi/contract), tip document distinct in motorul central factureaza().
  • Cautare/afisare politica dupa drepturi utilizator (COMUN\clase\baza.vc2:10502-10512) - ROAFACTURARE citeste crm_vpolpretcurutil pentru a limita politicile vizibile la cele pe care utilizatorul are drept (alt strat de drepturi, distinct de acces_meniu.prg - specific pe politici de pret, posibil gestionat tot server-side prin pachetul PACK_DREPTURI).
  • Rapoarte de vanzari pe lista de preturi (frm_raport_marfa, COMUN\clase\configurare.vc2:3915-3972) - grupare/însumare pe nume_lista_preturi.
  • Nu editeaza politici/liste - doar le CITESTE si le foloseste ca sursa de pret la facturare/ raportare. Editarea (adaugare politica, adaugare articole in politica, preturi) ramane in ROAPRETURI.

Concluzie pentru migrare: ce ar trebui mutat efectiv in ROAFACTURARE (conform cererii - "se folosesc numai in programul ROAFACTURARE") e interfata de editare (opreturi.vcx/ onom_preturi.vcx din ROAPRETURI), nu structura de date (Oracle, deja partajata/citita corect). Rapoartele si drepturile pe liste de preturi trebuie de asemenea aduse ca pagina/panou in ROAFACTURARE, dupa acelasi sablon COMENZI descris la punctul 2.


SUBIECT C - Nomenclatorul de articole ca lista de preturi virtuala (todo #12)

8. Structura tabelei de nomenclator

Tabela Oracle catalog_articole, expusa prin view-ul vnom_articole (si vnom_articole2 pentru un al doilea tip - vezi nom_articole2_nou, COMUN\programe\onomenclatoare.prg:1376-1396, tabela catalog_articole2).

Coloane identificate din interogari/scatter (nu e o lista exhaustiva - vin din SELECT-uri punctuale, nu din DDL): id_articol, denumire, codmat, codmatf (cod furnizor), codbare, um, grupa, subgrupa, id_grupa, id_subgrupa, dnf, cont (cont contabil, 3-4 caractere), acont, inactiv, sters, in_stoc, in_crm, tip (ex. 1 = manopera pt. ROAACNPRO), id_part/partener (pt. articole legate de furnizor/client). Surse: COMUN\clase\ocriterii.vc2:1531 (select denumire, codmat, um, grupa, subgrupa, id_grupa, id_subgrupa, dnf, cont, acont, inactiv, id_articol from vnom_articole), COMUN\programe\onomenclatoare.prg:1345-1353 (in_crm, in_stoc, tip), COMUN\clase\ointroduceri.vc2:9631 (in_stoc, cont).

Nicio coloana de pret nu a fost gasita direct pe nom_articole/catalog_articole (grep pret_v|pretv|pret_lista in onomenclatoare.prg = fara rezultate; scatter-ul din nom_articole_nou nu populeaza niciun camp de pret). Confirma punctul 11 mai jos.

Formular de editare: frm_catalog_articole (grid/cautare) si frm_catalog_articole_nou (fisa), ambele in COMUN\clase\onom_articole.vc2 (:531-599, :1655-1733), salvare prin cus_odata_catalog_articole.salvare si Adauga_Modifica_Inregistrare('catalog_articole', ...) (COMUN\programe\onomenclatoare.prg:1367,1443). Deschidere din meniu: Procedure viz_catalog_articole (COMUN\programe\oproceduri_articole.prg:62-122).

Important pentru subiectul B/C: nom_articole_nou (COMUN\programe\onomenclatoare.prg: 1343-1353) marcheaza acelasi articol cu in_crm = 1 cand programul curent e ROAPRETURI sau ROACONTRACTE, respectiv in_stoc = 1 in rest (inclusiv ROAFACTURARE) - nomenclatorul de articole e deja UNIC/PARTAJAT intre ROAFACTURARE, ROAPRETURI, ROACONTRACTE si ROAACNPRO (aceeasi tabela catalog_articole), flagurile in_stoc/in_crm/tip fiind doar clasificari de utilizare, nu tabele separate. Asta simplifica mult todo #12: nomenclatorul nu trebuie replicat, doar completat cu campuri de pret/tva/cont-vanzare si folosit direct ca sursa de pret la facturare.

9. Mecanismul actual de "lista de articole din stoc ca lista de preturi virtuala"

Confirmat: e mecanismul de "vanzare din stoc/gestiune", un tip de facturare paralel cu "lista de preturi"/"contract"/"comanda", identificat prin variabila globala gnTipGest:

  • Procedure vanzare_materii_prime -> gnTipGest = 2, Do vanzare1.mpr
  • Procedure vanzare_produse -> gnTipGest = 4, Do vanzare2.mpr
  • Procedure vanzare_marfa_pret_achi -> gnTipGest = 5, Do vanzare3.mpr (marfa la pret de achizitie)
  • Procedure vanzare_marfa_pret_vanz -> gnTipGest = 6, Do vanzare4.mpr (marfa la pret de vanzare)
  • Procedure vanzare_marfa_pret_achi_vanz -> gnTipGest = 7, Do vanzare5.mpr (toate in COMUN\programe\oproceduri_facturare.prg:1505-1534; butoane Page2.Cw5..Cw9 in Clase\ofundal_facturare.vc2:908-926).

Gestiunile disponibile per tip se filtreaza prin Procedure selecteaza_gestiuni (COMUN\programe\oproceduri_facturare.prg:1536-1565), pe view-ul vnom_GESTIUNI filtrat nr_pag = ?gnTipGest, plus un al doilea nivel de drept pe gestiuni (view-urile vgest_coresp_grupe_gestiuni / vgest_coresp_util_grupe, linia 1552-1555) - deci "lista de preturi virtuala" = stocul unei gestiuni, cu control de acces pe gestiune (nu pe politica de pret).

Motorul de scriere: Function oscrie_vanzare_din_stoc in COMUN\programe\ofacturare_stoc.prg: 104-..., apelat din initializeaza_vanzare_din_stoc (ofacturare_stoc.prg:31-99). Comentariu explicit in cod: "in vanzari_detalii scriu pretul cu tva daca am marfa la pret de vanzare, daca nu scriu pretul de vanzare fara tva" (ofacturare_stoc.prg:107), cu lnPretCuTva = Iif(INLIST(gnTipGest,6,7), 1, 0) (linia 111) - deci flagul "pret cu TVA" e determinat de TIPUL de vanzare din stoc ales (6/7 = la pret de vanzare), nu citit dintr-o coloana a nomenclatorului.

Cursorul-cheie crsvanztemp (ofacturare_stoc.prg:137-139) are coloanele: id_articol, Pret, proc_tvav, id_jtva_coloana, cantitate, discount_unitar, id_gestiune, Cont (c4), pret_cu_tva, serie, id_valuta, codmat, Curs, multiplicator, pret_achizitie, pretd, id_valuta_d, id_rul_aux, taxcode, lot.

10. Lantul de cod: pret, valuta, %TVA, pret_cu_tva, cont vanzare - la facturare "din stoc"

Din structura crsvanztemp (punctul 9) rezulta explicit lantul folosit azi cand se factureaza "virtual" din stoc (echivalentul cerut pentru nomenclator-ca-lista-de-preturi):

  • Pret: coloana Pret in crsvanztemp, luata din inregistrarea de gestiune/stoc (miscarea de intrare), nu din nomenclator - pret_achizitie separat pentru pretul de achizitie.
  • Valuta: id_valuta, Curs, plus varianta in alta valuta pretd/id_valuta_d (pret dublu, pentru afisare in a doua valuta).
  • %TVA: proc_tvav + id_jtva_coloana (coloana de defalcare TVA in jurnal) + taxcode (cod fiscal pt. integrari, ex. eFactura).
  • Flag pret_cu_tva: pret_cu_tva in cursor, calculat din gnTipGest (ofacturare_stoc.prg: 111), NU citit dintr-o coloana persistenta a articolului.
  • Cont vanzare (echivalent 4111=7xx): coloana Cont c(4) in crsvanztemp - cont contabil pe 4 caractere (ex. "707x"/"701x"), scris explicit in cursor la nivel de linie de vanzare. Sursa lui cea mai probabila (nu confirmata cu linie exacta de SELECT in aceasta cercetare, cursorul e populat mai jos in fisier, dincolo de zona citita) e coloana nom_articole.cont (confirmata ca existenta la punctul 8) sau contul gestiunii (nom_gestiuni) - IPOTEZA: trebuie verificat punctual restul lui oscrie_vanzare_din_stoc (fisierul continua dupa linia 140, necitit integral in aceasta trecere) pentru sursa exacta linie-cu-linie a lui Cont.

Pentru comparatie, la facturarea pe lista de preturi/politica (nu pe stoc), pretul/valuta/TVA vin din politica de pret (view crm_vpolpretcurutil/vcrm_politici_preturi, punctul 6), deci lantul e diferit dupa tipul de facturare ales (gnTipGest vs. id_pol).

11. Coloane de pret existente/partial folosite in nomenclator

Nu exista azi nicio coloana de pret pe nom_articole/catalog_articole (cautare explicita fara rezultate). Exista insa deja doua campuri reutilizabile direct pentru scenariul din cerere:

  • cont (cont contabil de vanzare/achizitie, deja pe articol - vezi punctul 8) - poate fi folosit ca "nota contabila" fara tabel separat.
  • Flagurile in_stoc / in_crm - clasifica deja fiecare articol dupa modul de utilizare (stoc vs. politica de pret / CRM), un precedent direct pentru un viitor flag suplimentar de tipul "articol cu pret propriu in nomenclator" daca se implementeaza todo #12.

Nu au fost gasite coloane de tipul pret, pret_vanzare, valuta_pret, ptva direct pe nomenclator - toate preturile de vanzare vin azi fie din politici de pret (Oracle, schema CRM), fie din miscarile de gestiune/stoc (nu din articolul insusi). Implementarea todo #12 ("nomenclatorul direct ca lista de preturi, fara politica + nota contabila asociate") ar necesita adaugarea a cel putin: pret (+valuta), procent TVA, flag pret_cu_tva pe catalog_articole/ nom_articole - camp nou, nu o coloana ascunsa deja existenta.


Rezumat surse cheie (fisier:linie)

  • Sablon COMENZI: Programe\roafacturare.prg:180-181,239-247; Clase\ofundal_facturare.vc2: 760-926; COMUN\clase\ocomenzi.vc2.
  • Drepturi: COMUN\programe\acces_meniu.prg (tot fisierul, 306 linii).
  • Facturare contract: COMUN\programe\oproceduri_facturare.prg:119-136,1986-2021; COMUN\clase\ofacturare.vc2:9067-9115,15069-15107.
  • Politici de pret: COMUN\clase\baza.vc2:10087,10157,10453-10512; COMUN\programe\oproceduri_facturare.prg:113-116.
  • Vanzare din stoc (lista virtuala): COMUN\programe\oproceduri_facturare.prg:1505-1534; COMUN\programe\ofacturare_stoc.prg:31-140.
  • Nomenclator articole: COMUN\programe\onomenclatoare.prg:1302-1373; COMUN\clase\onom_articole.vc2:531-599,1655-1733.