ROAFACTURARE · todos.txt punctul 13 · mockup, versiunea 9 (runda 17)

Un singur formular de facturare

Datele documentului si articolele in aceeasi fereastra, fara incarcarea prealabila a tuturor articolelor din toate politicile de preturi. Acelasi formular la introducere, la modificare, la copiere si la proforma.

Mockup, nu implementare. Campurile, etichetele si coloanele sunt cele reale, verificate pe cod la 09.08.2026 — rapoartele sunt in docs\cercetare\. Plan: docs\plan_13_unificare_formular_facturare.md Asezarea e varianta D (decizia 57, runda 15), cu motivul discountului in banda de totaluri (decizia 66, runda 17).

1Formularul

Deschis pe o factura in lei, emisa pe baza de comanda. Antetul e blocat — butonul din bara lui arata creionul. Asezarea e varianta D: antetul strans pe doua randuri, fara panou separat de discount, banda de totaluri lipita de grid pe toata latimea — cu procentul si motivul discountului chiar in ea — si randul de jos cu doua sectiuni colapsabile, incasare si alte date. La introducerea unui document nou arata identic, cu antetul deschis si campurile goale.

2Modificarea antetului, fara sa treci prin articole

Protectia antetului nu e o inventie: formularul de azi de modificare are deja patru bife, cate una pe camp, care deblocheaza serie, numar, data si scadenta. Ce se schimba e ca toate patru dispar, inlocuite de un singur buton in bara panoului, care isi schimba imaginea: creion cat timp antetul e blocat, discheta cat timp e deschis.

Un singur ciclu, doua stari: creion → deschis → discheta → salvat si blocat → creion. Termina ramane neschimbat si salveaza tot documentul; butonul de antet nu il inlocuieste, ci acopera cazul in care nu vrei sa treci prin articole.

de adaugat Un singur camp de antet nu are azi control nicaieri: eFactura. Procedura il scrie la fiecare apel, dar valoarea vine din inregistrare sau e fortata zero — nimeni nu il poate schimba. Daca butonul deschide tot antetul, il deschide si pe el, langa tipul SAF-T.

exista deja Comutatorul nu e un tipar nou in suita: fereastra de rulaje face exact asta pe acelasi buton but_modifica, schimbandu-i imaginea in save_sus.bmp cand intra in editare — verificat pe cod, rulaje.vc2:4716-4773. Se copiaza reteta de acolo.

Asta acopera cazul in care vrei sa corectezi doar delegatul sau data scadentei: apesi creionul, corectezi, apesi discheta, inchizi. Articolele nici nu se ating.

Ce deschide efectiv butonul — si de ce nu chiar tot, deocamdata. „Tot antetul” ramane intentia, dar campurile nu au aceeasi ruta de scriere. S-a cautat exhaustiv, si in Oracle si in tot codul VFP: pentru o parte din ele nu exista nicio procedura care sa le schimbe pe un document deja emis. Nu e o scapare de proiectare, e starea codului de azi.

Alegerea de a le tine blocate in etapa I, in loc sa se deschida cu avertisment: un camp care se lasa modificat dar nu se salveaza e o capcana. O modificare pierduta in tacere e mai rea decat un camp inca blocat, iar hover-ul spune de ce.

3Un singur buton de adaugare, cu meniu

In loc de doua butoane („adauga tot” si „alege”), unul singur care deschide un meniu — acelasi tipar folosit deja de butonul de modificare din lista de facturi. Optiunile se schimba dupa sursa documentului, cu doua constante: ultimele doua optiuni sunt aceleasi peste tot — Cauta in lista de preturi…, cu pretul din politici, si Alege din nomenclator…, cu pretul tastat. Sursa umple documentul, nu il inchide: pe o factura din comanda se poate adauga oricand un articol liber, si se poate si sterge — clientul mai vrea ceva, sau vrea sa schimbe.

„Alege…” deschide un dialog de selectie cu o coloana de bifat si criterii de cautare, dupa modelul importului din ROAACNPRO: buton activ doar cand documentul are sursa, populare aditiva in cursorul local, nicio scriere in baza pana la salvare. Spre deosebire de modelul acela, la zero rezultate se spune de ce, nu se inchide in tacere.

Azi „adauga tot” exista, dar e o iconita fara caption si fara tooltip, asezata lateral intre doua griduri — si nu acopera contractele: tipurile 2, 6, 26 si 52 lipsesc din conditiile lui de vizibilitate, desi avizele sunt acolo.

decis „Adauga tot din comanda” / „Adauga tot din avize” raman incarcari complete — S4 nu se restrange la o lista de preturi (decizia 39). Grila care le alimenteaza (crsarticole) nu e doar sursa listei: e si registrul cantitatii ramase de facturat, citit ca sa se decida inchiderea automata a comenzii sau a avizului cand o linie se sterge. Cautarea pe server ramane cum se vede mai sus (fara incarcare in masa); ce se decupleaza e bookkeeping-ul cantitatii ramase, intr-un registru propriu — ca sa poata disparea incarcarea si pe comanda si pe aviz fara sa strice inchiderea automata a documentului sursa.

4Valuta si data cursului

Doua concepte diferite, care azi impart acelasi camp mereu vizibil. Campul „Data curs valutar” nu e eliminat niciodata in functie de valuta — doar pe retur — deci apare si pe facturi in lei unde nu are ce cauta.

Al treilea caz nu se alege din formular: e decis de tipul documentului la deschidere, iar selectorul de valuta e scos din formular cand documentul nu e de tip valuta. Deci „factura in valuta” nu e o bifa pe care o pune operatorul, ci felul documentului.

Unificarea rezolva o problema care azi nu e rezolvabila. Cazul al doilea nu se poate sti la deschiderea antetului — se afla abia dupa ce se incarca articolele, cand antetul de azi e deja inchis. In formularul unificat antetul si articolele sunt in aceeasi fereastra, deci campul poate aparea in momentul in care intra pe grid primul articol cu pret in valuta. Din acelasi motiv dispare si mecanismul bug-ului #16: nu mai exista un antet inchis la care sa te intorci din formularul de curs.

decis Validarea cursurilor se restrange la valuta cautata (decizia 42). Pe varianta filtrata a cursoarelor, verifica_cursuri_valute nu mai ruleaza global la deschiderea formularului, ci doar pe valuta articolului adus in grid. Un curs lipsa pe alta valuta nu mai e semnalat la deschidere, ci abia cand se ajunge la un articol pe acea valuta — diferenta e asumata, se consemneaza la testare, nu e regresie.

5Discountul pe linie

Verificat pe formularul de azi si pe tabela. Raspunsul e mai simplu decat parea: si procentul, si valoarea exista deja — dar nu in grid.

De verificat separat, inainte de a incepe: daca discountul unitar apare pe rapoartele tiparite si daca e transmis in eFactura si SAF-T. Daca nu apare pe hartie, documentul tiparit nu explica totalul.

decis Discountul de DOCUMENT (nu cel de linie, de mai sus) se repartizeaza proportional pe cote de TVA, nu pe cota maxima cum face codul de azi (decizia 59). E automat, nu cere nimic de la operator. In banda de totaluri (sectiunea 1) se vede o singura suma; pe factura tiparita, cu cote mixte, pot aparea mai multe randuri „Discount X % Factura", cate unul per cota.

6De unde se intra in formular

Cerinta e ca formularul sa poata fi deschis cu sursa deja completata, fara sa o mai alegi. Doua cai fac deja exact asta.

Ce merita schimbat, si atat: sursa se transmite azi prin variabile globale, nu ca parametru. De aceea calea generica de comanda e obligata sa goleasca explicit globalul inainte de apel, ca sa nu ramana precompletata cu ce era in sesiune — iar calea de contract nu face acelasi lucru. Un parametru explicit inchide subiectul. Nu presupune nicio integrare noua de contracte.

---

7Ce se scrie la Termina

Un singur formular, dar nu o singura cale de scriere. ID_FACT se pastreaza in toate cazurile.

decis Un singur cod de scriere contabila (decizia 35). Regenerarea de mai sus scrie pe acelasi drum si la emitere, si la editare (etapa II): scrie_factura2 → contabilizeaza_articol, cu parametrul de cont de la sectiunea 10. Canalul oscrie_in_fisiere, folosit azi de #6, nu intra in #13 — doua implementari ale aceleiasi reguli de contare, una in pachet si alta in VFP, ar trebui tinute in pas manual la fiecare schimbare. Nu exista in acest formular editare directa a randului din ACT_TEMP.

8Ce trebuie verificat inainte

• de verificat ID_FACT refolosit la reemitere. Azi se ia din secventa, neconditionat. Varianta care il cauta dupa numar, serie si data exista in pachet, dar e comentata — si filtreaza STERS = 0, deci trebuie citita inainte de stergere.
• de verificat Stergerea si reemiterea in aceeasi tranzactie, fara commit intre ele.
• decis La reemitere se scriu valorile din formular, nu se reciteste sursa (decizia 54). Intrebarea nu mai e ce garda punem peste re-derivare — e daca re-derivarea chiar se produce; raspunsul lui Marius: nu trebuie sa se produca. Fara avertizare si fara confirmare, a fost respinsa explicit.
• decis Atasamentul PDF al documentului vechi se sterge la reemitere, nu se remigreaza (decizia 53). Documentul reemis porneste curat; PDF-ul se regenereaza la prima listare.
• decis Facturile de marfa in custodie (tipurile 48 si 49) sunt editabile prin #13 (decizia 60). Cu restrictia pastrata: pe ele nu se pot adauga articole gestionabile (IN_STOC <> 0).
• decis Singura restrictie de modificare e ca documentul sa nu fi fost trimis in eFactura (decizia 62). Fara nicio conditie de data, fara retroactivitate.
• decis Auditul (data + utilizator pentru adaugare, modificare si stergere) se afiseaza in gridul din frm_facturi, nu in formularul unificat (deciziile 63 si 65). Formularul nu capata niciun control nou din cerinta de audit.
• decis do_modifica de pe frm_facturi ramane activ pentru multi-selectie (decizia 52). Formularul unificat preia doar cazul cu un singur document.
• de verificat Descarcarea de gestiune pe proforma, pe partea Oracle.
• de verificat Discountul unitar in listari si in eFactura / SAF-T.
• de verificat Validarea datei de curs pe avizul de lucrare — acolo e ceruta neconditionat, deci ascunderea campului ar bloca finalizarea. Se repara impreuna, nu doar se ascunde.
• de verificat Legatura dintre linia de retur si linia originala. In program se acumuleaza perechi articol-factura si se trimit la salvare, dar daca serverul le pastreaza intr-o coloana nu se poate stabili din codul de aici. De asta depinde daca formularul poate arata din ce factura vine fiecare linie de retur.
• raspuns Ce face pachetul ROAAUTO cand factura primeste o linie pe care devizul nu o stie: nimic — nu citeste deloc tabelele de vanzari. Nu mai blocheaza nicio estimare, vezi sectiunea 9.
• raspuns Nepotrivirea de afisare ROAAUTO intre ecranul de deviz si factura retiparita — decizia 28: acceptata. Conditia e ca MANOPERA si MATERIALE sa fie conform devizului; restul articolelor pot exista pe factura fara sa apara pe deviz. Nu se cere cod nou in ROAAUTO. Vezi sectiunea 9.
• raspuns Stergerea unei linii venite din comanda — decizia 29: fara protectie. Se sterge ca oricare alta; comanda ramane cu cantitatea nefacturata si va aparea, corect, facturata partial. Nu se cere confirmare, nu se marcheaza „refuzat”.
• raspuns Coordonarea cu #6 — decizia 30: nu se coordoneaza. #13 incepe dupa ce #6 se termina, deci nu exista doi scriitori simultan pe acelasi fisier. Decizia 26 (analiticele read-only in #13) ramane — motivul ei e semantic, nu de calendar. Decizia 38: fluxul de editare al lui #6 (editare directa a randului din ACT_TEMP, prin oscrie_in_fisiere) nu se retrage odata cu #13 — coexista cu regenerarea prin pack_facturare, iar decizia despre unificarea lor se ia mai tarziu, dupa ce #13 livreaza si se vede in practica daca intretinerea celor doua drumuri doare cu adevarat.
• decis Bug-ul de dezalocare POS se repara in trecere, odata cu mutarea antetului din sectiunea 2 (decizia 40) — nu e o mutare pur mecanica, testarea trebuie sa acopere si dezalocarea POS pe calea veche.
• raspuns Cu ce cont de venit intra un articol fara politica de pret. Nu printr-o politica de pret implicita — decizia 24 s-a retras. Decizia 27: contul de venit se deriva, din CORESP_CONT_VENCHELT pentru articolele gestionabile si din NOM_ARTICOLE.CONT (sau, implicit, 704) pentru cele negestionabile; derivarea se face in VFP (decizia 27-bis), pack_facturare ramane neatins. Reteta si costurile: sectiunea 10.

9Facturile venite din ROAAUTO

ROAAUTO emite facturi din formularul lui de devize, dar prin acelasi pachet si in aceleasi tabele. Formularul unificat le vede fara niciun cod special. Ce lipseste nu e recunoasterea, ci scrierea.

Ce se cere: aceeasi adaugare de articole si la modificarea documentului, nu doar la emitere — si nu numai pentru facturile auto, ci pentru orice tip de factura, din lista de preturi sau direct din nomenclator.

corectie „Alte servicii” nu e jumatatea de drum pe care o credeam. Mecanismul acela functioneaza tocmai pentru ca ocoleste contabilizarea: facturile de deviz merg pe o cale paralela, care nu genereaza nicio nota contabila de venit. Pe fluxul normal de facturare, unde nota se genereaza, un articol fara politica de pret e respins cu eroare. Deci nu se generalizeaza un mecanism existent — se rezolva altfel (mai jos).

rezolvat Devizul nu se dezechilibreaza. Pachetul ROAAUTO nu citeste deloc tabelele de vanzari — nici antetul, nici liniile. Legatura pe care o face dupa emitere e in sens invers: pune numarul documentului pe comenzile si lucrarile lui. Deci o linie adaugata din formularul unificat nu strica niciun total si nu cere niciun apel suplimentar catre ROAAUTO.

decis Nepotrivirea de afisare e acceptata (decizia 28). Totalul devizului se calculeaza din structura proprie ROAAUTO, deci nu va arata niciodata linia adaugata; in schimb factura retiparita o va arata, pentru ca relistarea citeste direct liniile documentului. Conditia ceruta de Marius e alta: MANOPERA si MATERIALE sa fie conform devizului — restul articolelor pot exista pe factura fara sa apara in ecranul de deviz. Nu se cere cod nou in ROAAUTO ca sa aduca ecranul de deviz la zi.

---

10Contul de venit pentru articole adaugate din nomenclator

Intrebarea ramasa deschisa in sectiunea 8: cu ce cont de venit intra un articol adaugat „Alege din nomenclator…”, fara politica de pret. Decizia 27 (mai jos) nu s-a schimbat; reteta prin care ajungea la pack_facturare s-a abandonat intre runda 8 si runda 9-10, in favoarea unui parametru nou.

respins Decizia 24 — articolul ales din nomenclator primeste id_pol-ul unei politici de pret implicite. Retrasa in runda 8: evita cod nou in pack_facturare, dar cu pretul unei configurari cu contabilul (care politica, cu ce SCC) si al unui cont de venit uniform pentru orice articol adaugat asa. Inlocuita de decizia 27.

Decizia 27 — contul de venit se deriva, pe doua ramuri

respins Decizia 27-bis — reteta VFP in 4 pasi: calculeaza contul, cauta o politica a carei nota il are deja, insereaza articolul in ea cu pack_preturi.adauga_politica_pret_art, trimite id_pol. Abandonata in runda 9 (decizia 34): intrebarea deschisa era cum alege programul nota contabila de vanzare pe factura din comanda, care nu are politica de pret (decizia 32) — iar raspunsul lui Marius se refoloseste direct pentru articolul ad-hoc. Nu mai e nevoie de politica tehnica, nici de interogarea inversa pe SCC, nici de inserarea articolului intr-o politica.

Decizia 34 — contabilizeaza_articol primeste contul, printr-un parametru nou

Marius, textual: „poti sa adaugi parametrul contul contabil la contabilizeaza_articol.” Verdictul de proiectare, in trei randuri, pentru ca schimba forma literala a cererii: contabilizeaza_articol ia azi un singur parametru, detalii_articol VANZARI_DETALII_TEMP%ROWTYPE — contul nu intra pe el literal, ar fi cosmetic. Intra ca coloana noua VANZARI_DETALII_TEMP.CONT_VENIT VARCHAR2(4) NULL, populata printr-un parametru nou V_CONT_VENIT IN VARCHAR2 DEFAULT NULL, adaugat la coada lui adauga_articol_factura (procedura chemata direct din VFP) — contabilizeaza_articol il primeste automat, fara sa i se schimbe semnatura. Precedentul e in aceeasi lista de parametri: V_TAXCODE si V_LOT sunt deja doi parametri adaugati ulterior, la coada, cu DEFAULT NULL, iar apelul VFP e pozitional si se opreste la V_LOT.

Cei trei apelanti interni nu se ating deloc — scrie_factura2, scrie_factura_avize_retur si scrie_aviz_retur fac SELECT * BULK COLLECT intr-un TABLE OF ...%ROWTYPE, deci coloana noua le traverseaza fara nicio schimbare de cod. Ramura noua se activeaza doar pe detalii_articol.cont_venit IS NOT NULL: infasoara blocul FACT-024 (garda ramane litera cu litera pe ramura veche — o linie fara politica si fara cont trimis continua sa cada pe eroare), n-are cursor deloc, deci descarca_gestiune ruleaza exact o data prin constructie — bug-ul de set multi-rand din ramura veche nu se mosteneste, fara sa se repare ramura veche.

de retinut la implementare Parametrul se cableaza in doua locuri VFP, nu unul: frm_facturare_articole.do_scrie_articole si frm_facturare_articole2.do_scrie_articole sunt doua clase distincte, fiecare cu apelul ei RPC propriu. Daca se vrea CONT_VENIT pastrat si dupa fapt in VANZARI_DETALII, lista de coloane explicita din scrie_in_vanzari (24 de coloane azi) trebuie extinsa — altfel coloana traieste doar in VANZARI_DETALII_TEMP si ACT_TEMP. Articolul compus nu e o gaura aici: e exclus structural — proprietatea COMPUS traieste pe perechea (articol, politica), prin ID_POL_ART, iar o linie fara politica n-are asa ceva.

Decizia 36 — SCD si CU_TVA pe ramura fara politica

Nota veche mai furniza si SCD, CU_TVA, IN_VALUTA, EXPLICATIE, ID_VENCHELT, ID_SECTIE — nu doar contul. Verificarea n-a gasit nicio sursa alternativa in cod pentru primele doua (nici optiune de firma existenta, nici cont pe partener, nici flag de scutire pe articol sau client), deci sunt decizii de produs, si Marius le-a luat:

Lista de parametri noi ramane la unul singur, V_CONT_VENIT: SCD vine din configurare, CU_TVA se deriva in pachet din date deja prezente pe rand.

Decizia 37 — cheia optiunii de firma

RF_CONT_ART_FARA_POL, aliniata la familia RF_CONT_INCASARE_* — aceleasi optiuni care alimenteaza azi SCD in acelasi pachet, deci apar grupate alaturi in ecranul de optiuni. VARTYPE = 'CHARACTER', VARVALUE = '4111', PROGRAM = 'ROAFACTURARE', dar PROGRAME larg — apelul traieste in COMUN\clase\ofacturare.vc2, prezent in toate cele sapte produse ale suitei. Fara validare de cont, nici la salvare nici la citire — acelasi tipar ca RF_CONT_INCASARE_*, care nu valideaza de 15 ani. Garda gratuita ramane lungimea: un VARVALUE peste 4 caractere da ORA-12899 la INSERT INTO ACT_TEMP — esec zgomotos, nu cont tacut gresit. Un cont inexistent in planul de conturi, scris din greseala in ecran, ajunge pe nota neschimbat — risc acceptat constient, acelasi pe care produsul il are deja pe optiunile de tip cont.

Intrebarea lui Marius, verificata: „In ROAACNPRO si pe factura din comanda / contract se adauga articole fara politica — de ce nu si aici?” Raspuns, neschimbat fata de v7: ROAACNPRO nu cheama deloc contabilizeaza_articol — are propria contabilizare, pack_acn.salveaza_regdoc. Pe contract, articolele vin din cursor_contract / cursor_preturi, cu id_pol deja atasat de cursor. Deci FACT-024 ramane blocantul pe linia ad-hoc — parametrul de mai sus e cum se evita, nu un motiv sa fie sarit.

Ce nu e gratuit

• Regresie pe toata suita, nu doar ROAFACTURARE. pack_facturare e comun la ROACONT / ROAGEST / ROACONTRACTE / ROAAUTO / ROAACNPRO, si ramura noua e atinsa de apelul comun din ofacturare.vc2.
• Doua clase VFP cablate separat. frm_facturare_articole.do_scrie_articole si frm_facturare_articole2.do_scrie_articole isi construiesc fiecare propriul apel RPC — parametrul se adauga in ambele, nu o singura data.
• Lista de coloane a lui scrie_in_vanzari trebuie extinsa explicit daca se vrea CONT_VENIT pastrat si dupa fapt in VANZARI_DETALII, nu doar in VANZARI_DETALII_TEMP / ACT_TEMP.
• Un cont fara precedent (cazul 704) intra direct pe linie, fara sa mai treaca printr-o politica sau o nota existenta — spre deosebire de reteta veche, nu mai cere configurare cu contabilul, dar nici nu mai e validat impotriva planului de conturi (decizia 37).

---

11Puncte marunte ramase

Nu blocheaza nimic din ce e mai sus; se inchid la implementarea povestii respective. Enumerate ca sa nu se piarda intre runde — se merge pe recomandare daca Marius nu spune altfel.