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
- 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
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
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
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
frm_modific2024, pgfArticole.PAGE3 - editare in memorie, fara scriere in Oracle
(aceea ramane S5).
- sub-blocul A: cantitate/pret/pret_cu_tva editabile inline, marcaj lmodificat
pe linie, coloana valoare pe linie
- sub-blocul B: stergere logica de linii (sters/DynamicForeColor gri) si adaugare
de linii prin frm_articol_factura, cu alegerea articolului prin caut_articol()
- sub-blocul C: bara de totaluri sub grid (total linii convertit RON la cursul
documentului, discount de antet editabil, total net), ascunsa pe
transfer/custodie; verdict de corelatie ACT/RUL informativ, cu 3 stari
- suma ACT: sold net debit-credit, cont pe tip de document (4111 / 418 / 461,
iar pe rate/contract 4111, 411 sau 461)
- suma RUL: doar ID_TIP_RULAJ = 0, adica miscarile reale; perechile
ID_TIP_RULAJ = 3 sunt virtuale (tin locul procesului verbal de schimbare de
pret) si nu intra in suma. Corectie cu liniile nestocate, marcata "ajustat"
- adaugarea de linii pe document in valuta: dialogul primeste tip_valuta si
cursul documentului de pe tvanz, deci pretul se introduce direct in valuta;
ofacturare.vc2 ramane neatins
- cei 5 apelanti frm_modific2024 (afisjurcom, anaf_efactura, cele doua .sc2 de
import) pregatesc cursorul de articole inainte de Createobject, gardat pe
SET PROCEDURE - registrul jurnal din ROACONT/ROAGEST ramane neschimbat
Teste headless pe MARIUSM_AUTO, suite care isi descopera singure documentele:
test_page3_articole 14/2 (cele 2 = artefact de grid nematerializat headless,
acoperit pe ecran), test_incarca_vanzare_din_nota 5/0,
test_adauga_linie_articol 20/0, test_adauga_linie_valuta 16/0,
test_ui_sterge_linie 8/0, test_verdict_act_rul 26/0.
docs/todos.txt: punctele 13 si 20, scrise de Marius.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
ofacturare_editare.prg (nou): helpere comune - garda eFactura, cursoarele
notei si ale rulajelor, randul de vanzare corespunzator notei si liniile de
articole citite din view-ul VVANZARI_ARTICOLE.
omodificari.vc2 (frm_modific2024): pagina noua de articole ale facturii,
deocamdata doar afisare. Apare numai cand ofacturare_editare.prg e
inregistrat si documentul are rand in VANZARI; in ROACONT si ROAGEST, unde
fisierul nu e incarcat, pagina lipseste si registrul jurnal ramane neatins.
Randul de vanzare al notei se cauta pe toate tripletele distincte (nract,
serie_act, dataact) din nota, pentru ca primul rand poate fi o incasare.
ofacturare_comun.vc2 (frm_facturi): do_editare_factura si butonul aferent,
dupa modelul lui do_sterge, cu garzile de luna inchisa, luna curenta,
document sters, referinte si eFactura.
docs: comentariile se scriu strict necesar, si in cod si in scripturile de
migrare - fara referinte la planuri, stories, decizii sau erori, istoricul
doar in antetul fisierului. Plus regula zero (predarea contextului),
capcanele de la testarea headless si completari pe fluxul text -> binar.
utile/Teste: suita de regresie pentru editarea facturii si harness-ul
watchdog (nu sunt in SVN, unde utile/Teste e ignorat). .gitignore ignora si
capturile PNG si watchdog_out/, ramase din rulari.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
xmlefactura.prg: mentiunea despre cursul valutar din textul aditional se emite doar
cand documentul e chiar in valuta (in_valuta = 1).
ofacturare.vcx: scos SET STEP ON neconditionat din frm_facturare.do_scrie_factura.
- borderou si import eFactura: bifele de cautare arata numarul de documente in eticheta, inca
de la deschiderea ferestrei. Numararea se face local din cursorul deja adus cand nicio bifa
nu e bifata (cursorul e chiar setul de baza) si prin interogare doar cand o bifa e bifata,
ca sa nu apara interogari inutile. Latimile bifelor au fost marite: erau croite exact pe
textul original, iar " (N)" era taiat de marginea controlului.
- verificare cod fiscal: starea partenerului include "TVA la incasare", cu perioada in detalii;
sursa e ANAF live sau cache-ul ISTORIC_CODURI_FISCALE (ocautare.prg, validare.prg).
- modificare nota: lista de explicatii TVA se filtreaza dupa cota TVA a liniei curente
(omodificari.vc2, caut_explicatie_tva din oproceduri_comune.prg).
- istoric coduri fiscale: coloane nefolosite ascunse, adaugate cele venite de la ANAF
(TVA la incasare, split TVA, inactiv si perioadele aferente) - overificari.vc2.
- docs/scripturi-migrare-db.md: regulile de rulare manuala pe schema tinta si un pachet per script.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D8Ham1HJ8BB2v9nbtWgdZq
oDateFactura.Init completa clientul de pe contract fara cod fiscal, spre
deosebire de ramura de comanda. Formularul de cerere date arata acum codul
fiscal si permite verificarea ANAF fara a intra in cautarea de client.
todos: punct 10 - integrare contracte in ROAFACTURARE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HdKazj8DDksshTb2vB3gZz
- ooperatii_comune: verific_partener nu mai construieste SQL NULL cand contul
primit e NULL (EMPTY(.NULL.) e .F. in VFP)
- utile\context_watch.ps1 si utile\docs_revizie_check.ps1: masurarea contextului
sesiunii si cadenta reviziei de documentatie, prin hook-uri Claude Code
(instalare in docs\monitorizare-context.md)
- reguli_lucru: delegare la subagenti, modificari minime si scoped, scrierea si
revizuirea documentatiei, changelog strictul necesar (regulile 3, 6, 9, 11, 12)
- scripturi-migrare-db: continutul unui script (scoped, fara select, idempotent)
- teste noi pentru cele doua erori din achizitia de import
- restul documentatiei compactata, fara pierdere de reguli
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RYbiinqXxdEqXi53x4Ro7K
Nvl() evalueaza ambele argumente, deci .nume era citit chiar cand cursorul avea
doar denumire - eroare "Variable 'NUME' is not found". Inlocuit cu Iif() pe
Type() in Detalii si VerificaAlegere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RYbiinqXxdEqXi53x4Ro7K
VERIFICARE_CIF salva a doua oara in istoric ceea ce traseul ANAF (SalveazaIstoricDinCursor) tocmai
salvase, cu alte valori pentru PLATITORTVAMFIN si DATATVAMFIN, deci o apasare pe verificarea ANAF
lasa doua randuri in ISTORIC_CODURI_FISCALE. Pe traseul ANAF a doua salvare nu se mai face; traseele
MFIN/VIES raman neschimbate. Partea de baza de date: co_2026_08_02_05_COMUN_PACK_ISTORIC_CF.sql (SVN r17942).
Formularul de verificare in masa foloseste azi numai serviciul web ANAF (chkANAF fortat pe .T. in
Init), deci antetele arata sursa corecta: "Platitor TVA ANAF", "Firma ANAF" si "Data verificata"
(coloana arata data pentru care s-a interogat, nu data luarii in evidenta TVA). In fereastra cu
istoricul unui cod fiscal, coloanele DATATVAMFIN si PLATITORTVAMFIN sunt ascunse - dupa modificarea
din pachet raman inghetate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018LkXBVHUNkb7Quq36TfQcs
Dupa fuziunea istoricelor de coduri fiscale, ID-ul nu mai urmeaza ordinea cronologica,
deci row_number() ordonat pe id putea intoarce un rand vechi ca stare curenta.
Ordonarea trece pe dataorav_anaf desc, cu id desc ca departajare.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014sKVgMkowK4HpbFxBQVM22
caut_partener primeste tlVerificaANAF/tdDataDoc (acelasi bloc ca la caut_parteneri) si citeste
tip_persoana din vnom_parteneri, ca banda de stare sa distinga CNP de CIF, nu dupa lungimea codului.
Apelanti pe documente: factura si partenerul DVI din achizitia de import (data din formular,
dDataAct), furnizorul de la finalizarea NIR-ului (data cade pe poAct.dataact) si schimbarea
furnizorului pe rulaj.
verific_partener si verificare_note_contabile (ooperatii_comune.prg) cer verificarea si cand
completeaza partenerul lipsa pe cont, la salvarea documentului.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RYbiinqXxdEqXi53x4Ro7K
Lotul ramas pentru ANAF se construia cu un Scan fara filtru pe cui_n, deci codurile
care nu sunt CUI RO valid (cod gol, alta tara, peste 10 cifre) erau retrimise la fiecare
rulare - fereastra arata "Verific codurile fiscale 1..16 / 16" desi cele 903 coduri reale
veneau din cache, iar cererea plecata spre ANAF era goala: {"cui":0} -> 404.
- lotul ramas: Scan For cui_n <> 0.
- NormalizeazaCoduriCursor: cui_n se completeaza doar daca trece si algoritmul cifrei de
control (VerificareCod.VALIDARE_CIF), nu doar tara RO / numai cifre / maxim 10 caractere;
plus Val() <> 0, ca un cod de zerouri sa nu ajunga la ANAF drept cui:0. VALIDARE_CIF nu
s-a atins, e doar apelata.
- ANAF_SincronWebService_PlatitorTva: acelasi filtru la compunerea cererii (cele doua
trebuie sa ramana identice) si LOOP cand grupul nu are niciun CUI valid, deci fara
cerere HTTP goala.
Verificat: compilare curata; test headless pe NormalizeazaCoduriCursor (RO7320118, 7320118,
RO25501, "RO 1879855" trec; 7320119 cu cifra de control gresita, 0, cod gol, BG123456789,
CNP de 13 cifre sunt excluse). Fara fals-pozitive pe date reale: toate cele 903 coduri
confirmate de ANAF pe ROMFAST trec algoritmul.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JCzVWfqscv1xyo5uvJiWiW
Verificarea "in masa" (VerificaListaCIF ... 'MASA') pica pe ORA-01795 peste 1000
de coduri, iar esecul trimitea tot lotul la ANAF, cu pauze de o secunda la fiecare
100 de coduri. Pe langa asta, fiecare rand servit din cache era salvat inapoi in
istoric si logat separat.
- programe/validare.prg: CitesteIstoricPentruCoduri citeste pe transe de maxim
1000 de coduri legate cu OR in aceeasi interogare (fara obiecte noi in baza,
compatibil cu Oracle 10g); plasa de siguranta cere codurile neacoperite o
singura data, nu cod cu cod; SalveazaIstoricDinCursor sare peste randurile cu
sursa CACHE*; bucla de log per rand devine o singura linie cu totalul.
- clase/overificari.vc2: completarea tabelului de parteneri foloseste index pe
codul normalizat si SEEK in loc de LOCATE cu UDF (era patratic).
- utile/Teste/cache_anaf/: harness-uri de masurare si non-regresie pentru
timpii de mai jos.
Masurat pe MARIUSM_AUTO, cu ANAF blocat: 1000 de coduri 5,1 s -> 0,318 s;
1001 coduri 16,6 s cu ORA-01795 -> 0,553 s fara eroare; 3000 de coduri 1,565 s;
200 de coduri din cache 3,93 s -> 0,05 s, cu 0 randuri noi in istoric;
completarea tabelului pentru 2000 de parteneri 11,97 s -> 0,028 s.
Randurile intoarse si verdictele raman identice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JCzVWfqscv1xyo5uvJiWiW
Verificarile de partener nu mai depind exclusiv de raspunsul ANAF: se citeste
intai cache-ul din ISTORIC_CODURI_FISCALE (mutat in CONTAFIN_ORACLE), cu
provenienta afisata pe ecrane (sursa / data_sursa) si cu plasa de siguranta
cand ANAF tace. Ordinea cache/ANAF e configurabila; cache-ul expira.
- programe/validare.prg: verificare single si pe loturi peste cache, contract
404 separat de caderea de serviciu, expirarea cache-ului, corectii la
verdictul pe firma si la etichetarea CACHE_INDISP.
- programe/ocautare.prg: plasa de siguranta si banda de provenienta la cautarea
de partener.
- programe/oproceduri_comune.prg: VERIFICA_RTVAI_DATA citeste si cache-ul.
- clase/overificari.vc2: propagarea provenientei in interfata.
- utile/Teste/: harness-uri de testare headless - echivalenta cache/ANAF pe 200
de coduri reale, marginile pe inactiv si TVA la incasare, mock batch ANAF,
baseline D394 si sondele de diagnostic ANAF.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JCzVWfqscv1xyo5uvJiWiW
- TVA-ul de pe DVI poate avea valuta si curs proprii, diferite de ale facturii
(rand "protejat": rand_dvi/valuta_proprie pe introdc, sparge_tva_protejat).
- Discount financiar pe factura: rand tip_rand='G' (401 = 767), TVA calculat pe
baza diminuata, marfa si preturile articolelor pe valoarea integrala.
- Factura multi-cota: randurile S, G si T se sparg pe cotele articolelor, cu
explicatia TVA din familia coloanei si alinierea T -> S.
- Teste noi in utile/Teste/achizitie_import (discount, DVI, cote, e2e).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9uDgDfUQXbh2Neib36CN8
Pe toate cele trei pagini (Facturi emise, Primite, Trimise) doua bife noi, colorate
ca randurile pe care le filtreaza: turcuaz "Cu diferente Reg. TVA" (jtotctva
completat, dar diferenta peste 0,15 lei sau eFactura in valuta) si gri "Lipsa din
Reg. TVA" (jtotctva null). Bifate impreuna se aduna cu OR.
Culorile din grid: gri = nu e in registru, turcuaz = diferenta peste 0,15 lei sau
necalculabila, alb = se potriveste. Expresia DynamicBackColor e sparta in doua
siruri, VFP nu accepta constante peste 255 caractere.
diferenta ramane NULL cand jtotctva e NULL (nu 0 fals), la fel ca la facturile
primite/trimise; jtotctva si diferenta sunt acum nullable in cursorul de facturi
emise.
Corectat lcFiltru3, care se construia din lcFiltru2 si pierdea conditiile paginii.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FW7zDopcHo2fHq5L53MjMM
Galbenul de la randurile cu diferenta fata de Registrul TVA devine turcoaz in borderou,
ca sa insemne acelasi lucru in ambele ferestre: gri = factura nu e in registru,
turcoaz = e in registru dar valoarea difera cu peste 0.15 lei ori nu se poate compara
(factura in valuta), alb = se potriveste.
Importul preia regulile corectate ieri in borderou: diferenta ramane goala cand factura
nu e in registru sau e in valuta si tine cont de semnul notei de credit, iar jtotctva si
diferenta se declara nullable in cursor (altfel NULL devine 0 si gri-ul nu mai apare).
Pana acum importul colora orice diferenta de un ban si dadea turcoaz fals pe notele de
credit si pe facturile in valuta.
Filtrul initial al cursorului din fereastra de import compara data_act cu un interval
[prima zi a lunii, prima zi a lunii urmatoare) in loc de extract(year/month from data_act),
deci poate folosi IDX_ANAF_EFACTURA_1(FACTURA_EMISA, XDATA_ACT, DATA_RASPUNS). Filtrul
rula la fiecare deschidere a ferestrei, nu era amanat ca la borderou.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FW7zDopcHo2fHq5L53MjMM
Potrivirea pe numar compara nract cu grupurile de cifre extrase din xnumar_act,
in loc sa aplice un regex peste nract. Predicatul devine sargabil, deci foloseste
IDX_JC2007_003/IDX_JV2007_003 in loc sa scaneze toata luna din jurnal pentru
fiecare factura: borderoul de facturi trimise trece de la 97 de secunde la sub una
(masurat pe o firma cu 6006 facturi si 6466 randuri in jurnal).
Rezerva pe suma egala se pastreaza, dar in view se leaga prin COALESCE, nu prin OR:
se evalueaza doar pentru facturile pe care numarul nu le-a gasit. Legata prin OR,
potrivea nediferentiat orice document cu aceeasi suma la acelasi partener in aceeasi
zi - pana la 49 de documente pentru o factura - si afisa o "Diferenta" gresita.
jcnt si coloana "Pot." se elimina: dupa corectarea potrivirii numarul de documente
potrivite e practic intotdeauna 1, iar starea "nu e in registru" se citeste din
jtotctva IS NULL. jtotctva se declara nullable in cursor, altfel NULL-ul devine 0 si
randurile fara potrivire nu s-ar mai colora.
Pragul de la care un rand devine galben urca de la 0.01 la 0.15 lei: la 0.01 ieseau
841 de randuri galbene din 6006, toate diferente de rotunjire sub 0.11 lei.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FW7zDopcHo2fHq5L53MjMM
Dialogul din Initializari > Optiuni utilizator arata separat setarea
utilizatorului curent, setarea firmei, implicitul programului si starea
de pe calculator. Butonul "Nu" sterge setarea proprie (DELETE in
OPTIUNI_UTIL + reincarcarea cursorului), ca utilizatorul sa revina la
setarea firmei sau la implicit; setarea firmei nu se modifica de aici.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhJwsrFFe1ZNAAtS8Twuti
