Verificare ANAF la alegerea partenerului

ocautare.prg - miezul functionalitatii:
- anaf_verif_cautare: verdictul ANAF pe randul curent din formularul de cautare
  (label sub grid), la data documentului; discordantele si codurile fiscale invalide
  cu rosu; F4 sau click deschide detaliile.
- ANAF_StarePartener, cu cache pe sesiune, excludere parteneri externi si persoane
  fizice; ANAF_ValidareCod pentru CIF/CNP.
- ANAF_NivelVerificare: cascada RC_ANAF_VERIF_SELECTIE (kill-switch settings.ini >
  optiuni utilizator > optiuni firma > implicit 1), cu cache invalidat la schimbarea
  firmei sau utilizatorului; ANAF_ComutaVerificare pentru punctul de meniu.
- Detalii: alegerea variantei corecte de partener din perechea RO / fara RO, cu
  discriminator "are documente in perioada"; dupa Da sau Nu se inchide cautarea si
  se revine in formular cu partenerul ales (AplicaInlocuirePartenerANAF).
- ANAF_CaData: data documentului poate veni si ca DateTime (tact.dataact).
- Banda proprie sub grid pentru label: formularul creste cu 54, gridul isi pierde
  ancorarea de jos si primeste inaltimea din AjusteazaBanda, legata de Resize si
  Activate - formularul isi reaseaza gridul dupa Show, deci Activate e momentul util.

validare.prg: ANAF_VerificaCuiSingle, wrapper single-CUI peste serviciul ANAF, cu
data verificarii si o singura eroare logata pe sesiune.

cauta_alfa.prg: hook generic - ataseaza poVerifAlegere pe formularul de cautare
inainte de Show si il detaseaza dupa.

Apelanti opt-in (lVerificaANAF): baza.vc2 (lookup-ul generic de partener din
formularele actbaza/actbaza2007 lansate din meniuri), onote_contabile.vc2 (partener
debit/credit), omodificari.vc2 (do_cauta din cele trei clase de modificare, cu data
notei), ofacturare.vc2 (client, furnizor). Casa/banca ramane in afara: acolo partenerul
se alege pentru imperecherea facturilor.

cauta_alfa_forms.vc2: F4 deschide detaliile, iar terminarea cautarii trece prin
VerificaAlegere.

Teste: suita headless pentru fluxul de verificare (utile/Teste/partener_anaf/), cu
mock pentru apelul ANAF si pentru dialoguri.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019H3r66sVojGhgaKq5niu1u

docs/conventie_ux_formulare.md

@@ -33,6 +33,22 @@ butoane grupate la margini, fără elemente lipite unele de altele.
   semnificație clară (verde = acțiune pozitivă/transmite, roșu = oprire/pericol, albastru =
   navigare/deschidere link extern); restul butoanelor rămân stilul implicit din `_baza.vcx`.
 
+## Clase de controale (confirmat de Marius, 24.07.2026, pe frm_verif_partener_anaf ROACONT)
+
+- **Intotdeauna controale din `_baza.vcx`, nu controale native VFP** — orice grid, label,
+  textbox, checkbox etc. dintr-un formular nou se bazeaza pe clasa corespunzatoare din
+  `COMUN\clase\_baza.vcx`, nu pe clasa nativa Visual FoxPro. Clasele din `_baza.vcx` au
+  fontul default **Arial 10** — nu se suprascrie FontName pe controale (explicit: fara
+  Arial Narrow).
+- **Butoanele de inchidere/confirmare stau in bara de titlu**, din `cmd_butoane.vcx` —
+  modelul Renunt/Termin (clasa de forma `frm_termin_renunt` din `_frm_child.vcx` le aduce
+  deja). Nu se dubleaza aceste actiuni cu butoane in corpul formei.
+- **Actiunile care au corespondent `but_*` in `cmd_butoane.vcx`** (Nou/Adauga, Modifica,
+  Salveaza, Sterge, Verifica etc.) folosesc CU PREDILECTIE clasa dedicata `but_*`
+  respectiva — nu se improvizeaza un buton generic pentru o actiune care are deja clasa ei.
+- **Doar actiunile FARA corespondent `but_*`** primesc butoane pe clasele `cmd_*` din
+  `cmd_butoane.vcx` (ex. `cmd_executa`) — nu clase improvizate si nu CommandButton nativ.
+
 ## Vocabular
 
 Funcțional, compact, aerisit, minimalist, grupat, ușor de înțeles de utilizatori, aer aerisit,
@@ -43,6 +59,6 @@ regulile mecanice de mai sus, pe orice aplicație ROA*.
 
 - `PROMPT_cautare_vfp.md` din acest folder — cum se caută/editează cod în binarele VFP text-cache
   (relevant când aplici aceste reguli prin fluxul `.sc2`/`.vc2` + write-back).
-- Capcana de encoding cp1252 la editarea `.sc2`/`.vc2` (corupere diacritice) — documentată în
-  proiectul unde a fost descoperită (ROAAUTO `docs/conventie_encoding_cp1252.md`); relevantă ori
-  de câte ori editezi text-cache-ul unui formular/librărie pentru a aplica aceste reguli de UX.
+- `conventie_encoding_cp1252.md` din acest folder — capcana de corupere a diacriticelor la
+  editarea `.sc2`/`.vc2`; relevantă ori de câte ori editezi text-cache-ul unui formular/librărie
+  pentru a aplica aceste reguli de UX.

docs/flux-editare-vfp-text.md

@@ -28,7 +28,7 @@ rularea `git_sync.ps1`; restul pasilor raman la fel. Fluxul cu cache extern (`vc
 3. Patch review: `git diff --no-index <bak> <editat> > docs/diff_runda<N>_<subiect>.patch`
    (exit 1 = normal). Utilizatorul revizuieste FISIERUL de patch si aproba; write-back-ul
    (pasul 5) se face DOAR dupa aprobare. Commit doar dupa confirmare pe patch + test in IDE.
-   Comentariile in cod: maxim o linie (`*!* DD.MM.YYYY autor - motiv scurt`), fara explicatii lungi.
+   Comentariile in cod: conventia din `reguli_lucru.md` (punctul 2).
    Obligatoriu inainte de a preda patch-ul la review: skill-ul de code-review rulat pe bucatile
    de cod din diff (nu doar citire manuala) - prinde defecte gen IIF cu numar gresit de
    argumente, deduplicari care nu se declanseaza niciodata, interogari mai largi decat e nevoie.

docs/git_svn_parallel_init_prompt.md

@@ -1,86 +0,0 @@
-# Prompt: init git in paralel cu SVN pentru un proiect ROA
-
-Foloseste acest prompt intr-o sesiune Claude Code noua, deschisa in radacina proiectului
-tinta (ex. `D:\ROA\ROAIMOB`). Functioneaza generic pentru orice proiect VFP din `D:\ROA\`
-care are structura ROAACNPRO (proiect + subfolder COMUN\ partajat, ambele in SVN).
-
----
-
-```
-Vreau sa initializezi git pentru proiectul VFP din directorul curent, in paralel cu SVN-ul
-existent (nu atinge SVN, nu rula comenzi svn, doar adauga .svn/ in .gitignore).
-
-Structura e identica cu D:\ROA\ROAACNPRO: acest folder e propriul proiect VFP (are un .PJX
-al lui), si contine un subfolder COMUN\ care e framework-ul PARTAJAT intre toate aplicatiile
-ROA, versionat separat prin SVN (are propriul .svn\).
-
-Fa exact ce s-a facut deja pentru ROAACNPRO (poti citi acolo ca referinta/sablon):
-- D:\ROA\ROAACNPRO\.gitignore (sablon pentru .gitignore-ul proiectului principal)
-- D:\ROA\ROAACNPRO\COMUN\.gitignore (sablon pentru .gitignore-ul din COMUN)
-- D:\ROA\ROAACNPRO\CLAUDE.md (conventii proiect) si docs\cautare_vcx_vct.md (cum se cauta
-  cod in interiorul .vcx/.scx binare, via D:\ROA\UTIL\foxbin2prg\vcx2txt.ps1)
-
-Pasi:
-
-1. Verifica intai ce exista deja: `git status`/`.git` in radacina si in COMUN\, si
-   `git remote -v` daca exista deja vreun remote configurat gresit (asa cum a fost cazul la
-   ROAACNPRO, unde originul proiectului principal pointa gresit catre repo-ul comun.git).
-
-2. REPO PRINCIPAL (radacina acestui folder):
-   - Daca nu exista .git, `git init -b main`.
-   - Creeaza/adapteaza .gitignore dupa modelul ROAACNPRO/.gitignore (artefacte VFP compilate:
-     *.fxp, *.mpx, *.bak, *.mpr, *.err, log.txt, *.tmp, *.dct, *.exe, cruft Windows), plus
-     obligatoriu `COMUN/` (COMUN e gestionat de git-ul lui separat, nu de-al acestui repo)
-     si `.svn/`.
-   - Deduce numele repo-ului gitea dupa conventia romfast/<nume-folder-lowercase>.git
-     (ex. romfast/roaimob.git). INAINTE sa creezi/pushezi orice, verifica cu
-     `git ls-remote git@gitea.romfast.ro:romfast/<nume>.git` daca exista deja si ce contine
-     (clone --depth 1 intr-un folder temporar din scratchpad daca ai dubii). Daca exista deja
-     cu istoric care nu se potriveste cu ce ai local, OPRESTE-TE si intreaba-ma inainte sa
-     faci push sau orice suprascriere.
-   - Daca remote-ul e gol/nou: add -A, commit "Initial commit — sursa <PROIECT>", adauga
-     origin, push normal (fara --force).
-
-3. COMUN\ (subfolder-ul partajat):
-   - Initializeaza un git SEPARAT, propriu, in interiorul COMUN\ (COMUN are propriul .git,
-     nu e tracked de repo-ul principal — de-asta l-am exclus mai sus).
-   - .gitignore propriu in COMUN\ dupa modelul ROAACNPRO/COMUN/.gitignore (artefacte VFP +
-     `.svn/` + `bash.exe.stackdump`).
-   - Origin-ul din COMUN\ trebuie sa fie EXACT acelasi repo pentru toate proiectele ROA:
-     git@gitea.romfast.ro:romfast/comun.git — repo-ul asta e deja populat (din COMUN-ul lui
-     ROAACNPRO). NU face commit+push orbeste peste el.
-   - Fa intai `git fetch origin`, compara continutul de pe origin/main cu fisierele locale
-     din acest COMUN\ (diff pe folder, nu doar pe nume). Daca sunt identice sau diferentele
-     sunt neglijabile, seteaza pur si simplu branch-ul local sa urmareasca origin/main (fara
-     sa strici fisierele din working copy SVN). Daca sunt diferente reale intre COMUN-ul
-     acestui proiect si cel deja impins pe gitea, arata-mi un rezumat al diferentelor si
-     intreaba-ma explicit cum procedez (nu face force-push fara aprobarea mea explicita —
-     ar sterge ireversibil istoricul comun tuturor proiectelor ROA).
-
-4. Cautare in cod VFP binar (.vcx/.scx) pentru acest proiect:
-   - Foloseste acelasi vcx2txt.ps1, dar parametrizat pentru proiectul curent (nu ROAACNPRO):
-     powershell -ExecutionPolicy Bypass -File D:\ROA\UTIL\foxbin2prg\vcx2txt.ps1 `
-       -Project D:\ROA\<PROIECT>\<proiect>.PJX -ProjectRoot D:\ROA\<PROIECT> `
-       -CacheRoot D:\ROA\UTIL\foxbin2prg\_textcache_<proiect>
-   - Cache separat per proiect (nu-l amesteca cu _textcache al ROAACNPRO). Grep in cache-ul
-     respectiv, la fel ca in docs\cautare_vcx_vct.md.
-
-5. La final, adauga/actualizeaza CLAUDE.md al acestui proiect cu o sectiune scurta: git ruleaza
-   in paralel cu SVN legacy (SVN ramane sursa "vie" pentru COMUN, sincronizat manual catre git);
-   COMUN e partajat intre toate aplicatiile ROA prin acelasi git@gitea.romfast.ro:romfast/comun.git;
-   cautarile in .vcx/.scx se fac cu vcx2txt.ps1 parametrizat pentru acest proiect (vezi mai sus).
-
-Inainte de orice `push --force` sau orice operatie care ar suprascrie istoric remote deja
-existent (mai ales pe romfast/comun.git, care e comun mai multor proiecte), opreste-te si
-intreaba-ma explicit — nu decide singur.
-```
-
----
-
-## Note
-
-- Cel mai sensibil pas e COMUN\: daca versiunea de COMUN a noului proiect difera de cea deja
-  impinsa pe `comun.git` (din ROAACNPRO), Claude trebuie sa se opreasca si sa intrebe cum se
-  reconciliaza, nu sa faca force-push automat.
-- Daca `romfast/<proiect>.git` nu exista inca pe gitea, trebuie creat gol acolo inainte de push
-  (manual sau prin API) — altfel push-ul esueaza cu "repository not found".

docs/reguli_lucru.md

@@ -5,11 +5,19 @@
    Write-back in binar (txt2vcx) si commit DOAR dupa aprobarea patch-ului de catre utilizator.
    Patch-urile sunt intermediare de review: NU se comit NICIODATA in git (sunt in
    .gitignore ca `docs/diff_runda*.patch`); raman doar local, pe disc.
-2. Comentarii in cod: max o linie `*!* DD.MM.YYYY autor - motiv scurt`, DOAR la
-   functionalitati noi/schimbate. La rezolvari de erori NU se adauga comentarii.
+2. Comentarii in cod: NU se pun comentarii in corpul codului (nici la functionalitati noi).
+   In ANTETUL fisierului se tine o singura intrare CUMULATIVA per functionalitate, in stilul
+   existent (`*!* DD.MM.YYYY` / `*!* autor` / `*!* ce face, 1-2 fraze`): la revenirea pe aceeasi
+   lucrare se rescrie intrarea, nu se adauga alta. Autorul e persoana care semneaza livrarea
+   (ex. `marius.mutu`) - niciodata "claude" sau alt nume de agent.
+   Se descrie doar comportamentul final, fara referinte la revizii, runde, patch-uri sau la
+   corectii facute pe parcurs. La rezolvari de erori NU se adauga comentarii deloc.
    Explicatiile merg in docs/ sau in mesajul de commit, nu in cod.
-   Changelog (`changelog_<aplicatie>.txt`): text minimal, pe limba utilizatorului,
-   nu tehnic - o fraza scurta per intrare `:nou:`/`:modificare:`/`:eroare:`.
+   Changelog (`changelog_<aplicatie>.txt`): text minimal, pe limba utilizatorului, nu tehnic,
+   o fraza scurta per intrare. Cat timp lucrarea nu a ajuns la utilizatori (fara deploy),
+   erorile introduse si corectate in interiorul ei NU se pomenesc - intrarea descrie
+   functionalitatea asa cum ajunge la utilizator, `:nou:`/`:modificare:`; `:eroare:` ramane
+   doar pentru erori care au fost in productie.
 3. Modificari minime: doar ce s-a cerut; fara refactorizari sau curatenie din oficiu.
 4. Testare headless (fara IDE): `vfp9.exe -A -T "<script.prg>" <param>` din PowerShell.
    Mediu, sabloane, capcane si metoda de depanare: `depanare_testare_vfp.md`.

docs/scripturi-migrare-db.md

@@ -5,3 +5,14 @@ Scripturile de migrare a schemei (si modelele pentru scripturi noi) sunt in
 `gcDirMare`/`dirgen` — ex. `D:\ROA\DATABASE\SCRIPTURI_CLAR`).
 Sursa SVN: `http://svnroa:3001/svn/ROA/DATABASE/Branches/RB-1.00`.
 Pentru un script nou, urmeaza formatul/conventiile celor recente de acolo.
+
+Reguli confirmate de Marius (24.07.2026):
+
+- **Line-endings CRLF obligatoriu** in scripturile `.sql` — tool-urile agentului scriu
+  implicit LF; dupa orice scriere, verifica si converteste byte-safe LF -> CRLF (fara
+  decodare/reincodare). Parsarea pe fluxul ROA (ex. `ALINES` pe `CHR(13)+CHR(10)`)
+  esueaza silentios pe LF: tot fisierul devine un singur rand.
+- `versiune_db.txt` (marker-ul `YYYY_MM_DD_NN` din radacina aplicatiei) se scrie fara
+  newline la final (conventia existenta).
+- Aplicarea prin ODBC/`goExecutor`: sintaxa SQL*Plus `exec pachet.procedura(...)` nu
+  functioneaza — foloseste `begin pachet.procedura(...); end;`.