Borderoul tine per factura ce mai are de completat si daca are articole de gestiune
(camp gest, coloana si filtru), coada contabilizeaza in serie facturile bifate si
incheie cu un rezumat, iar contul de furnizor/client se alege din planul de conturi.
Cheia normalizata de articol, rezolvarea automata a partenerului si anularea in bloc
intra tot aici. Pozitia in lista se pastreaza peste reaplicarea filtrului.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Aroafxp4z8bmM5oVECZRXY
Squash al branch-ului de lucru plan13-s2.
Clase: ofacturare (nucleul formularului unificat), ofacturare_comun,
ferestre_cere_date, ocomenzi, caut_ora (lista de preturi in combo-urile de
cautare), omodificari.
Programe: ofacturare impartit - ofacturare_antet, ofacturare_rutare_scriere si
ogrid_latimi sunt fisiere noi; oproceduri_facturare primeste discountul pe linie
si cota standard de TVA cand articolul nu are cota pe politica.
Documentatie: capcana SQLExec no_data_found, conventia de encoding, depanarea
testelor VFP si regulile de lucru - conflictele cu modificarile venite din alte
proiecte sunt rezolvate pastrand ambele parti.
Loguri de rulare a testelor scoase din versionare; testele raman.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PkyjGyrV2S7932om4kfSiK
Testul sintetic acopera CaenAnaf (completarea zeroului din fata, valori
neplauzibile) si CaenRevizie (format nou/vechi de numar de registru): 42 -> 53
verificari. Proba e2e goleste caen/caen_revizie inainte de rulare si le
verifica dupa, cu contoare SEPARATE de judet/localitate ca cifrele masurate in
rundele anterioare sa ramana comparabile. Mock-ul de dialog expune acum si
codul CAEN si numarul de registru brute de la ANAF.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015husoVS24ewJZr21ZoVR3v
Proba end-to-end ruleaza formularul frm_firme_nou_desktopf peste nomenclatorul
Oracle real; 997/1000 coduri fiscale reale potrivite corect. Testul sintetic
acopera 42 de verificari, fara Oracle si fara ANAF.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015husoVS24ewJZr21ZoVR3v
- validare.prg: cele 7 campuri de perioada (inregistrare TVA, TVA la incasare,
inactivare/reactivare) duse din raspunsul ANAF pana in cVerificareCod
- validare.prg: AnafDecodeResponseText - raspunsul HTTP se citeste din responseBody
prin ADODB.Stream cu Charset utf-8, cu cadere inapoi pe comportamentul vechi;
repara diacriticele pierdute la marshalling-ul COM al lui responseText
- oproceduri_comune.prg: perioadele in mesajul de detalii; fix id_part N(16), data D
in crsXMLParteneriVerificare (Insert Into esua tacit, lista ramanea goala)
- overificari.vc2: 7 coloane noi in grid, dublu-click pe Denumire/Cod fiscal deschide
fisa partenerului, captionuri corectate in "inregistrare TVA"
- oparteneri / ofacturare_comun / onomenclatoare: id_part in SELECT-urile care
alimenteaza verificarea
- teste headless noi: utile/Teste/test_todo21_perioade_anaf.prg, utile/Teste/todo21/
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GztNyTRxjHqBg5kyNMmcy1
origin/main aducea 6de4899 "sync SVN r18016", o sincronizare mai veche decat
copia de lucru (r18018), care retrograda ofacturare_editare.prg. Continutul lui
04a7d05 (diagnoza spatiu) e deja in arbore, adus prin svn update si comis in
5637fc2. Arborele local ramane neschimbat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013gYCNE26G1G7UoGu2ju7aS
Continut adus prin svn update din alta copie de lucru, identic cu 04a7d05 de
pe origin/main. Doua gauri prin care o baza blocata putea sa nu alerteze:
tablespace fara autoextend (maxbytes = 0 il scotea din verificare, acum
plafonul e GREATEST(maxbytes, bytes)) si disc plin sub datafile
autoextensibil (sectiunea DISC are prag propriu si ruleaza mereu, prima).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013gYCNE26G1G7UoGu2ju7aS
Pagina Articole din frm_modific2024:
- DblClick pe cele cinci coloane cu nomenclator (articol, gestiune, taxcode,
valuta, explicatie TVA). Explicatia TVA are ControlSource expresie, deci
tastarea nu putea declansa niciodata InteractiveChange; DblClick se sprijina
pe pccontrol si acopera uniform toate cele cinci.
- Pret si Pret cu TVA folosesc gnPPretV (precizie pret vanzare) in loc de
gnPPret (precizie achizitie). Coloana de pret achizitie ramane pe gnPPret.
- Culori dupa conventia de pe pagina Rulaje: verde pe coloanele care se
editeaza prin dialog, alb pe cele care se tasteaza direct.
- Serie, lot si explicatie devin editabile in celula. Garda .When ramane si
blocheaza in continuare liniile din seturi si facturile din e-Factura.
frm_facturi: textul optiunii de editare factura din meniul contextual devine
"Editare factura (note, rulaje, articole)".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013gYCNE26G1G7UoGu2ju7aS
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
Cele trei fisiere erau pe disc, netrackuite, iar ce se stia despre ele traia
intr-un handoff intre sesiuni. Handoff-ul a fost desfiintat: ce era durabil a
intrat in antetul harnessului - plaja de serii care chiar prinde (FACTURA cere
gnIdUtil=8 cu gnIdSucursala=167, AVIZ merge si cu -3), faptul ca alocarea
consuma numere ireversibil chiar cand documentul nu se scrie, ordinea gresita
de incarcare a lui mock_amessagebox care e suspectul principal pentru agatari,
si riscul de curs EUR ramas neconfirmat pe cursor_contract.
Harnessul nu a scris inca niciun document cu succes - antetul spune asta
explicit, ca sa nu fie luat drept unealta functionala.
test_init_env_auto_roafacturare.prg e generic si folosit deja de alte suite:
seteaza gcNumeProgram=[ROAFACTURARE], fara de care garzile proprii fluxului de
facturare nu se declanseaza.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
Enumerarea diferentelor dintre rulaje si articole capata interfata: buton pe
pagina de articole, dialog cu grid si comutator de directie, plus verificarea la
salvare. Dialogul propune, nu decide - aplicarea ramane o apasare explicita.
- omodificari.vc2: cmdSincronizeazaArticole pe PAGE3, dezactivat odata cu restul
paginii cand documentul e blocat in eFactura; frm_sincronizare_articole,
derivata din frm_termin_renunt. Gridul e legat de propunere_afisata, cursor
stabil creat in Load si doar golit si reumplut - propunere_sincronizare se
recreeaza la fiecare apel, deci o legare directa s-ar rupe la prima comutare
de directie.
- id_articol trece de la I la N(20), in toate cele 6 locuri scrise pentru acest
punct. Restul codebase-ului foloseste dintotdeauna N(20): valorile reale trec
de 2^31 pe 89.8% din NOM_ARTICOLE, iar un camp I le trunchia tacit, asa incat
potrivirea pe id_articol cadea si iesea perechea Adaugare+Semnalare in locul
unei Modificari. Nu e o schimbare de design, e revenire la conventia casei.
- doua accesari This. in loc de Thisform. in Click-ul butonului de adaugare
articol: proprietatile sunt ale formularului, iar scurtcircuitul OR le
evalua exact cand documentul avea articole - orice click real dadea eroare.
- teste: test_s4b_dialog (35/0) acopera instantierea, comutarea directiei si
aplicarea la salvare; test_s4b_sincronizare (42/0) capata cazul id_articol
3598545102, care ar fi picat inainte de schimbarea de tip.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
Rulajele contabile si articolele facturii sunt doua reprezentari independente ale
aceluiasi document, editabile separat. Helperele noi construiesc enumerarea
diferentelor dintre ele si o pot aplica, la cererea utilizatorului.
- ConstruiestePropunereSincronizare: potrivire pe id_articol, singura cheie
comuna - nu exista corespondent la nivel de linie intre rulaj si articol.
Agregarea RUL foloseste pretul mediu ponderat cand un articol are mai multe
randuri. Articolele nestocate, documentele in valuta si articolele cu mai
multe randuri RUL active raman N-A, cu motiv afisat: propunerea ar fi o
presupunere, nu un calcul.
- AplicaSincronizareArticole: scrie doar in tvd/trul, in memorie. Nu adauga
randuri de rulaj (conturile nu se deduc din articol) si nu sterge linii in
nicio directie - divergenta se semnaleaza, stergerea ramane manuala.
Scrierea reala in Oracle ramane calea existenta, la salvare.
- test_s4b_sincronizare: headless, fara Oracle, pe cursoare construite in test.
Butonul, dialogul si verificarea la salvare vin separat.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
flux-modificare-stergere-nota-jurnal.md descria doar nota contabila. Documentul
capata ramura de facturi: cele doua puncte de intrare cu garzile lor, pasul nou
din tranzactia manuala, contractul ScrieArticoleFacturaEditate, recalculul din
Oracle si comportamentul gridului de articole.
Doua lucruri contraintuitive, scrise explicit: ID_FACT nu se schimba la reeditare
(COD se realiniaza), deci tot ce se leaga prin id_fact supravietuieste; si garda
de referinte lipseste intentionat pe editarea generica de note din Registrul
Jurnal - protejeaza incasarile la operatia care sterge efectiv factura.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
Cand documentul e deja trimis in eFactura, pagina de articole ramane vizibila,
dar needitabila: cantitate, pret, pret achizitie, flagul pret cu TVA, discountul
de antet, plus adaugarea si stergerea de linii. Alegerea e "vizibil, dar blocat",
nu "pagina ascunsa" - contabilul trebuie sa vada ce contine factura trimisa.
- omodificari.vc2: flag lArticoleReadOnly calculat in frm_modific2024.Show, impins
peste .When-urile de celula, peste Enabled si peste garda din Click-ul butoanelor,
si peste txtDiscountArt.ReadOnly. Eticheta lblArticoleReadOnly explica motivul.
- ofacturare_editare.prg: id_fact adus pe tvanz, in IncarcaVanzareNota si in
CreeazaCursorTvanzGol. EsteInEFactura interogheaza anaf_efactura dupa id_fact,
nu dupa id_vanzare - fara asta garda nu s-ar fi declansat niciodata pe date reale.
- teste: test_efactura_readonly (headless, garda in ambele sensuri),
test_ui_efactura_readonly (formular vizibil - coloanele gridului nu se
materializeaza sub -A -T), test_s7_rotunjire, si test_s8_matrice_surse pentru
matricea S8 pe tipuri de sursa.
S8 rulat pe cate un document din fiecare tip de sursa (lista de preturi, contract,
aviz, factura din aviz), fiecare editat din ambele puncte de intrare: notele vechi
raman STERS=1, id_fact nu se schimba, totalurile si liniile raman coerente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
La salvarea unei facturi deja emise, modificarile facute liniilor de articole
se scriu acum real in VANZARI_DETALII, in aceeasi tranzactie cu restul salvarii,
si totalurile documentului se recalculeaza din liniile efectiv salvate.
- ofacturare_editare.prg: helper nou ScrieArticoleFacturaEditate. Idiomul e
"marcheaza tot sters, invie ce ramane", nu delta, pentru ca
actualizeaza_vanzari face UPDATE ... SET STERS = 0 pe tot documentul, fara
garda; o scriere delta ar lasa liniile sterse sa reinvie la fiecare salvare.
Cursor gol = no-op, ca o eroare la incarcare sa nu goleasca factura.
- comun.vc2, ofacturare_comun.vc2: agatarea apelului dupa
finalizeaza_modificare_nota si inainte de inchiderea tranzactiei, in ambele
puncte de intrare.
- omodificari.vc2: coloana Pret achizitie in grid, editabila doar pe liniile
noi; liniile de set devin needitabile, cu marcaj; cinci validari la salvare.
- teste: cinci suite noi (validari, grid UI, scriere reala, discount/valuta,
rollback, al doilea punct de intrare) si asteptari actualizate in
test_page3_articole.
- docs: oracle_export.md - exportul all_source cere linesize 32767, altfel
rupe liniile lungi prin mijlocul identificatorilor; scripturi-migrare-db.md -
UpdateVersiune adauga singur extensia .sql.
Cere scripturile ff_2026_08_09_01 (PACK_FACTURARE) si ff_2026_08_09_02
(VVANZARI_ARTICOLE).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
