sync SVN r18006: inregistreaza ofacturare_editare.prg

SET PROCEDURE TO ofacturare_editare.prg ADDITIVE, langa ofacturare_comun.prg.
Fara el, pagina de articole ale facturii nu apare in registrul jurnal >
modificare; clasa comuna are garda si degradeaza fara eroare, dar pagina
lipseste.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3

CLAUDE.md

@@ -46,6 +46,25 @@ Editing: write-back text→binary via `txt2vcx.ps1` is supported **only for `.vc
 (vcx/scx); `.frx/.mnx/.lbx/.pjx/.dbc/.dbf` are editable **only in the VFP IDE** (no write-back).
 See `D:\ROA\UTIL\foxbin2prg\CLAUDE.md` and `COMUN\docs\flux-editare-vfp-text.md`.
 
+Grep can't tell **which class/method** a hit inside a `.vc2` belongs to (the class header may be
+thousands of lines above it, and ~2/3 of the file is properties/metadata). `vfp_symbols.ps1`
+indexes the line range of every class/method/procedure and labels hits with their owner — use it
+before any `txt2vcx.ps1` edit to get the exact line range of the method you are changing. Its
+built-in defaults target ROAACNPRO, so always pass this project's paths:
+
+```powershell
+$s = 'D:\ROA\UTIL\foxbin2prg\vfp_symbols.ps1'
+$c = @('-CacheRoot', 'D:\ROA\ROACONT', '-ProjectRoot', 'D:\ROA\ROACONT', '-IndexFile', 'D:\ROA\_vfp_textcache\roacont\_symbols.tsv')
+
+powershell -ExecutionPolicy Bypass -File $s @c -Grep '<expression>' -CodeOnly   # hits labeled class.method, code only
+powershell -ExecutionPolicy Bypass -File $s @c -Where '<file>.vc2:<line>'      # who owns this line
+powershell -ExecutionPolicy Bypass -File $s @c -Find '<name>'                  # where it is DEFINED
+powershell -ExecutionPolicy Bypass -File $s @c -Class '<class name>'           # inheritance chain + methods
+```
+
+The index (`_symbols.tsv`) rebuilds itself when the text is newer, so refresh the text first — it
+can't see IDE edits that were never converted. Full search guide: `COMUN\docs\cautare_vcx_vct.md`.
+
 Orphan cleanup: on each full run `git_sync` deletes `.??2` text whose binary was removed from
 SVN (and `.db2` whose table left the per-project list) and reports it, so git records the
 deletion.
@@ -170,6 +189,10 @@ ROACONT - X.Y.Z
 -->
 ```
 
+Regula de continut: changelog-ul e pentru utilizatori — se scrie **doar ce vede utilizatorul**,
+scurt si compact. Erorile introduse si reparate in aceeasi versiune nelivrata **nu se trec**
+(clientul nu le-a vazut niciodata); intrarea versiunii curente se rescrie, nu se acumuleaza.
+
 Tags in use: `:nou:` (new feature), `:modificare:` (change/fix to existing behavior),
 `:eroare:` (bug fix), `:adaugare:` (addition). Version numbers increment per entry (current
 series is `2.11.x`). When asked to log a change, follow this exact format/tag set rather than
@@ -215,6 +238,29 @@ Preferintele lui Marius pentru sesiunile pe acest proiect:
   (`.vcx`/`.scx`), diff-ul lizibil se face pe forma text `.vc2`/`.sc2` regenerata cu
   `git_sync.ps1`, inainte de write-back cu `txt2vcx.ps1`.
 
+## Stil de raspuns: scurt si concret
+
+Marius vrea raspunsuri **clare, concise, fara vorbarie**. Regula, nu preferinta.
+
+- **Starea si ce urmeaza, nu povestea.** Ce e gata, ce e stricat, ce trebuie decis, ce urmeaza —
+  in liste scurte, cu fisier si linie. Fara reconstituirea drumului pana la rezultat.
+- **Fara naratiune de proces**: ce a raportat fiecare agent, cine ce a corectat, cum au fost
+  coordonate benzile. Intra in `docs/`, nu in raspuns.
+- **Fara laude si fara reluari.** Nu repeta ce s-a spus deja in conversatie.
+- Detaliile tehnice lungi (dovezi, iesiri de test, metodologie) se scriu in fisier si se
+  **trimite la el**, nu se copiaza in raspuns.
+- Cand e ceva de decis: enunta decizia si optiunile in cateva randuri, cu recomandarea ta.
+
+**Formatul obligatoriu al raspunsului**, in aceasta ordine, maxim cateva randuri fiecare:
+
+1. **Am facut:** ce e gata (fisier:linie).
+2. **Urmeaza:** ce fac mai departe.
+3. **De la tine:** intrebarea, clar si simpla, cu recomandarea mea.
+
+Explicatiile, dovezile si descoperirile colaterale merg in `docs/`, cu un link. Nu se reia in
+raspuns rationamentul, nu se explica de ce a fost greu, nu se justifica alegerile decat daca
+sunt cerute.
+
 ## Skill routing
 
 When the user's request matches an available skill, invoke it via the Skill tool. When in doubt, invoke the skill.

Programe/orapoarte.prg

@@ -1991,9 +1991,10 @@ select *
 	Use In (Select('cIncasariBanca2'))
 
 	*** Verific pe ANAF starea split tva la data curenta
+	*!* 31.07.2026 marius.mutu: ordine explicita MASA (CACHE,ANAF) - corect pentru data trecuta pdDataI
 	SELECT distinct cod_fiscal FROM cFacturiTVA INTO CURSOR cCodFiscalTemp
 	loVerificareANAF = CREATEOBJECT("VerificareANAF")
-	loVerificareANAF.VerificaListaCIF("cCodFiscalTemp", m.pdDataI, "crsANAF")
+	loVerificareANAF.VerificaListaCIF("cCodFiscalTemp", m.pdDataI, "crsANAF", "MASA")
 	USE IN (SELECT('cCodFiscalTemp'))
 	IF USED("crsAnaf")
 *!*			crsANAF (cui N(13), data D, denumire V(100), firma V(100), adresa C(244), scpTVA L, data_inceput_ScpTVA D, data_sfarsit_ScpTVA D, data_anul_imp_ScpTVA D, mesaj_ScpTVA C(244), ;
@@ -2308,9 +2309,10 @@ select *
 	Use In (Select('cIncasariBanca2'))
 
 	*** Verific pe ANAF starea split tva la data curenta
+	*!* 31.07.2026 marius.mutu: ordine explicita UNIC (ANAF intai) - starea de azi, cache-ul ramane plasa de siguranta
 	SELECT distinct cod_fiscal FROM cFacturiTVA INTO CURSOR cCodFiscalTemp
 	loVerificareANAF = CREATEOBJECT("VerificareANAF")
-	loVerificareANAF.VerificaListaCIF("cCodFiscalTemp", Date(), "crsANAF")
+	loVerificareANAF.VerificaListaCIF("cCodFiscalTemp", Date(), "crsANAF", "UNIC")
 	USE IN (SELECT('cCodFiscalTemp'))
 	IF USED("crsAnaf")
 *!*			crsANAF (cui N(13), data D, denumire V(100), firma V(100), adresa C(244), scpTVA L, data_inceput_ScpTVA D, data_sfarsit_ScpTVA D, data_anul_imp_ScpTVA D, mesaj_ScpTVA C(244), ;

Programe/roacont.prg

@@ -209,6 +209,7 @@ SET PROCEDURE TO onomenclatoare.prg ADDITIVE
 SET PROCEDURE TO saft_d406.prg ADDITIVE 
 SET PROCEDURE TO ofacturare.prg ADDITIVE 
 SET PROCEDURE TO ofacturare_comun.prg ADDITIVE 
+SET PROCEDURE TO ofacturare_editare.prg ADDITIVE 
 SET PROCEDURE TO oproceduri_facturare.prg ADDITIVE 
 SET PROCEDURE TO anaf_efactura.prg ADDITIVE
 SET PROCEDURE TO import_efactura.prg ADDITIVE 

Programe/saft_d406.prg

@@ -564,6 +564,9 @@ Define Class d406 As Custom
 					lnEroriReale = 0
 					lnEroriFictive = 0
 					lcMesajErori = ''
+					* Mai astept 2 secunde pentru ca se deschide fisierul cu erori si DUKIntegrator inca scrie in fisier si fisierul deschis sau parsat este partial
+					Wait Window Timeout 2 "S-a generat fisierul raspuns. Se clasifica erorile..."
+
 					lcFisierExplicat = This.do_erori_saft(m.lcFisierRaspuns, @lnEroriReale, @lnEroriFictive, @lcMesajErori)
 					OPEN_DEFAULT_APP(m.lcFisierRaspuns)
 					IF !EMPTY(m.lcFisierExplicat)

TODOS.md

@@ -97,7 +97,8 @@ Sursa: `docs/design-alegere-partener-anaf.md`, REVIZIA 4 (implementata doar nive
   4,00 s cu SetTimeouts(2000,2000,3000,3000); WinHTTP asincron `Send()` 0,009 s,
   `WaitForResponse(0)` 0 s. Ramane nemasurat comportamentul la rafale (de la al catelea 429).
 
-## P4 — Contract 404 pe drumul batch ANAF (D406 si sincronizari)
+## P4 — Contract 404 pe drumul batch ANAF (D406 si sincronizari) — PRELUAT
+Preluat 31.07.2026, povestea S5 din transa `docs/contract-cache-anaf.md` (`docs/diff-S5-contract-404-batch.md`).
 - **Ce:** `validare.prg:1827` citeste corpul raspunsului doar pe `Status = 200`, la fel cum
   facea si wrapper-ul single-CUI. Pe loturi, un CUI inexistent si o cadere de serviciu ajung
   la utilizator ca acelasi lucru ("nu s-a putut verifica").
@@ -129,3 +130,98 @@ Sursa: `docs/design-alegere-partener-anaf.md`, REVIZIA 4 (implementata doar nive
 - **Conditie de intrare:** reclamatii pe parteneri externi marcati rosu, vizibile in logul de
   discordante (`anaf_verif_cautare`).
 - **Efort:** M. **Depinde de:** masuratoarea lantului scurt.
+
+## Amanari review /autoplan — cache ANAF pe ISTORIC_CODURI_FISCALE (29.07.2026)
+
+Sursa: `docs/design-cache-anaf-istoric-coduri-fiscale.md`, sectiunea GSTACK REVIEW REPORT.
+
+## P2 — Cascada de ferestre modale la verificarea in masa cu ANAF cazut
+- **Ce:** `AMESSAGEBOX` este apelat in interiorul buclei pe grupuri din
+  `ANAF_SincronWebService_PlatitorTva` (`COMUN\programe\validare.prg:1968`, `:1970`, `:1976`,
+  `:1993`, `:1996`). La 3000 de parteneri = 30 de grupuri, deci pana la 30 de ferestre modale
+  de inchis manual la o singura rulare de D406.
+- **De ce:** cu ANAF cazut, plasa de siguranta introdusa de proiectarea din 29.07 lucreaza in
+  spatele acestui zid de modale — castigul e invizibil pentru utilizator. Probabil mai valoros
+  decat cache-ul insusi.
+- **Fix:** un singur mesaj la sfarsitul rularii (numar de grupuri esuate), nu unul per grup.
+- **De ce nu acum:** atinge interpretarea raspunsului pe traseul in masa (acelasi cod ca P4 de
+  mai sus), deci cere runda proprie de teste pe declaratie.
+- **Efort:** S-M. **Depinde de:** mock-ul pe calea batch (T1 din review).
+
+## P3 — Bucla O(n^2) la imperecherea rezultatului ANAF cu lista de parteneri
+- **Ce:** `COMUN\clase\overificari.vc2:2722` face `LOCATE FOR ...` liniar in interiorul unui
+  `SCAN` peste cursorul de raspuns ANAF. Costul creste cu patratul numarului de parteneri.
+- **De ce:** tranșa de cache adauga peste bucla un apel de procedura Oracle per cod, deci
+  ambele cresc pe acelasi traseu.
+- **Conditie de intrare:** masuratoarea ceruta oricum la E4, pe un lot de ~500 de coduri.
+  Daca timpul e acceptabil, nu se atinge.
+- **Efort:** M. **Depinde de:** masuratoarea de la E4.
+
+## P3 — Parsarea sarita cand primul rezultat nu are `dcod_judet`
+- **Ce:** `COMUN\programe\validare.prg:1986-1994` — daca
+  `found_vfpsafe_[1].adresa_domiciliu_fiscal.dcod_judet` lipseste (cazul unui lot in care toate
+  codurile sunt `notFound`, deci `found` e gol), se afiseaza fereastra de eroare "Serviciul web
+  ANAF intors mesaj de eroare" si nu se parseaza nimic, desi raspunsul e valid.
+- **De ce:** face ca un lot legitim de coduri inexistente sa arate ca o defectiune de serviciu.
+- **Efort:** S. **Depinde de:** acelasi contract 404 pe calea batch (P4 de mai sus).
+
+## P3 — `DATATVAMFIN` ramane text
+- **Ce:** `VARCHAR2(30)` din 2012, afisat direct la `COMUN\programe\oproceduri_comune.prg:4783`.
+  Noile coloane de interval il fac redundant.
+- **De ce nu acum:** decizia explicita a proiectarii din 29.07 (Intrebarea deschisa 2).
+- **Efort:** S. **Depinde de:** livrarea coloanelor de interval.
+
+## Amanari transa cache ANAF — completare (01.08.2026)
+
+Sursa: `docs/diff-TRANSA-cache-anaf.md`, `docs/handoff_cache_anaf.md`.
+
+## P1 — Rulare reala prin `PACK_UPDATE` pe TEST, inainte de prima livrare (decizie de EXECUTIE)
+- **Ce s-a facut deja:** cele trei scripturi ale transei (`co_2026_07_30_02_RTVAI_PACK_ROARTVAI.sql`,
+  `co_2026_07_31_01_COMUN_ISTORIC_CF.sql`, `ff_2026_07_31_01_COMUN_ISTORIC_CF.sql`) figurau
+  "aplicate" in tabela `versiune` din rulari manuale sqlplus, desi coada reala `UPD_DATABASE` nu
+  avea niciun rand pentru ele. **Randurile s-au curatat** (`CONTAFIN_ORACLE` -9, `MARIUSM_AUTO` -7,
+  `ACN` -1, zero randuri ramase pentru cele trei scripturi) si **toate trei s-au dovedit
+  re-rulabile** (DDL gardat, inserturi `where not exists`, pachete `CREATE OR REPLACE`) — nu mai
+  e nicio decizie tehnica de luat.
+- **Ce ramane:** doar **executia** propriu-zisa prin `PACK_UPDATE`, netrasa inca.
+  `SCRIPTURI_CLAR` mai contine scripturi straine de transa, neaplicate — daca motorul ia tot ce
+  gaseste pe disc, ar rula si munca in lucru a altcuiva pe un server de test partajat. Banda Oracle
+  stabileste pe sursa daca fluxul se poate limita la cele trei fisiere ale transei.
+- **Efort:** S. **Depinde de:** decizia lui Marius de a executa `PACK_UPDATE` pe TEST (nimeni n-a
+  apasat butonul inca); detaliu complet `docs\audit-oracle-final.md`.
+
+## P3 — Export Excel din verificarea in masa (D406/D394) nu duce mai departe provenienta cache
+- **Ce:** `Programe\orapoarte.prg` (`Copy To ... Type Xl5`) nu adauga `sursa`/`data_sursa` in
+  fisierul exportat — un fisier trimis mai departe nu arata ca o parte din verdicte vin din cache,
+  nu dintr-un raspuns proaspat ANAF.
+- **De ce nu acum:** cursoarele exportate (`cFacturiTVA` si perechea de la a doua raportare) ar
+  cere o coloana noua, iar `ALTER TABLE ADD COLUMN` pica pe cursor liber cu nume de camp peste 10
+  caractere (`platitortva` are 11) — ar cere rematerializarea cursorului in doua situri de
+  raportare, cu schimbarea formatului unui fisier care ajunge la client. Amanat explicit de
+  Marius, 01.08.2026.
+- **Efort:** M. **Depinde de:** decizie separata daca merita rematerializarea cursoarelor.
+
+## P2 — Clarificare cu ANAF: marginea perioadelor scpTVA/splittva/inactiv
+- **Ce:** cache-ul ANAF (`ISTORIC_CODURI_FISCALE`) foloseste conventie inclusiva la sfarsitul
+  intervalelor `SCPTVA`/`SPLITTVA`/`INACTIV` (spre deosebire de `TVAINCASARE`, aliniat 01.08.2026
+  la conventia exclusiva a RTVAI). Nu exista ground truth local (registru echivalent
+  `rtvai_istoric`) pentru aceste trei campuri.
+- **De ce:** risc de verdicte gresite cu o zi pe declaratii D394/D406 la marginea perioadelor,
+  acelasi tipar de defect confirmat pe `tvaincasare` (vezi `docs\handoff_cache_anaf.md`,
+  sectiunea A-ter).
+- **Efort:** S (o intrebare catre ANAF) -> M (aplicarea raspunsului in cod, daca schimba
+  conventia). **Depinde de:** raspunsul ANAF.
+
+## P3 — Test UI pe gridul de verificare parteneri (coloana de provenienta cache)
+- **Ce:** confirmare vizuala (paint real, nu doar `EVALUATE` pe `ControlSource`) ca noua coloana
+  de provenienta (`sursa`/`data_sursa`, S8) se afiseaza corect in gridul de verificare.
+- **De ce nu acum:** cere write-back `.vc2` pe `overificari.vc2`, deci dupa aprobarea lui Marius
+  pe diff.
+- **Efort:** S. **Depinde de:** aprobarea write-back-ului `.vc2` al transei cache ANAF.
+
+## Curatenie mediu — randuri orfane in tabela `versiune` (MARIUSM_AUTO)
+- **Ce:** doua randuri `co_2026_07_30_01_COMUN_ISTORIC_CF.sql` in `MARIUSM_AUTO.versiune`, din
+  testarea manuala a lui S1 dinainte de redenumirea in `ff_`.
+- **De ce nu acum:** fara efect (motorul `PACK_UPDATE` dispecerizeaza dupa numele fisierului de pe
+  disc, nu dupa stringul din `versiune`) — curatenie de mediu de test, nu de productie.
+- **Efort:** S. **Depinde de:** nimic, se poate face oricand.

changelog_roacont.txt

@@ -1,30 +1,97 @@
+<!--
+04/08/2026
+ROACONT - 2.11.71
+
+:modificare:
+  Verificare cod fiscal. Starea partenerului arata acum si "TVA la incasare", cu perioada in detalii (F4).
+
+:modificare:
+  Modificare nota. Lista de explicatii TVA se filtreaza dupa cota TVA a liniei curente.
+
+:modificare:
+  Borderou eFactura si import eFactura. Bifele de cautare arata in eticheta numarul de documente, inca de la deschiderea ferestrei.
+
+:modificare:
+  Istoric coduri fiscale. S-au ascuns coloanele nefolosite si s-au adaugat datele venite de la ANAF (TVA la incasare, split TVA, inactiv si perioadele aferente).
+
+:eroare:
+  Istoric coduri fiscale. Verificarea repetata a aceluiasi cod fiscal nu mai adauga inregistrari inutile in istoric.
+-->
+<!--
+02/08/2026
+ROACONT - 2.11.70
+
+:modificare:
+  Verificarea in masa a codurilor fiscale este mai rapida. Cache-ul se citeste pe transe, deci nu mai apare eroare la un numar mare de coduri.
+
+:eroare:
+  La ANAF se trimit doar codurile fiscale valide. Codurile care nu sunt CUI valid nu mai sunt trimise la fiecare rulare.
+
+:eroare:
+  Verificarea putea lua din cache un verdict mai vechi. Acum se ia intotdeauna ultima verificare, dupa data ei.
+
+:nou:
+  Note contabile. La completarea partenerului pentru conturile de parteneri se face si verificarea ANAF, ca la introducerea documentelor.
+-->
+<!--
+01/08/2026
+ROACONT - 2.11.69
+
+:nou:
+  S-a introdus un cache pentru verificarea partenerilor la ANAF. Verificarea se face pe serverul ANAF, iar daca acesta nu raspunde se ia din cache-ul din baza de date. Cache-ul are valabilitate de 30 de zile. Verificarea in masa (D406, D394, registre) e mult mai rapida.
+
+:modificare:
+  Se vede provenienta fiecarui verdict: "ANAF" sau "CACHE <data>". La verificarea in masa, in coloana "Provenienta"; la alegerea partenerului, in fereastra cu datele partenerului.
+
+:eroare:
+  Verificare TVA la incasare la o data din trecut. Ultima zi a unei perioade deja incheiate era raportata gresit ca activa.
+-->
+
+<!--
+30/07/2026
+ROACONT - 2.11.68
+
+:modificare:
+  D406. Se asteapta 2 secunde suplimentare fisierul de erori generat de DUKIntegrator pentru ca fisierul sa fie complet.
+
+:eroare:
+  S-a corectat o eroare la verificare coduri fiscale daca nu exista internet.
+-->
+
+<!--
+28/07/2026
+ROACONT - 2.11.67
+
+:modificare:
+  Borderou eFactura, Import eFactura. Deschiderea listelor de facturi este mult mai rapida.
+  
+  Borderou eFactura. Imbunatatiri la potrivirea documentelor cu Registrul de TVA dupa numar document sau suma.
+  Numarul documentului se potriveste si cand a fost introdus in contabilitate fara separatori (eFactura "40-33-129052" introdusa ca 4033129052). Doua facturi cu aceeasi valoare, acelasi partener si aceeasi zi nu mai apar cu valoare dubla fata de Registrul de TVA.
+  
+  Facturile colorate "turcoaz" = eFactura exista in Registrul de TVA, dar valoarea difera cu peste 0,15 lei (sau diferenta nu se poate calcula - ex: eFactura in valuta)
+  Facturile colorate "gri" = eFactura nu se regaseste in Registrul de TVA (nu s-a introdus in contabilitate sau nu s-a potrivit numarul si nici suma)
+-->
+
 <!--
 28/07/2026
 ROACONT - 2.11.66
 
 :modificare:
-  Borderou eFactura, facturi primite. Facturile cu taxare inversa nu mai apar colorate ca avand diferenta fata de contabilitate. In eFactura taxarea inversa are TVA zero, dar in contabilitate se inregistreaza 4426 = 4427, iar diferenta afisata tine cont acum de acest TVA. Necesita actualizarea bazei de date.
+  Borderou eFactura, facturi primite. Facturile cu taxare inversa nu mai apar colorate ca avand diferenta fata de Registrul Cumparari. In eFactura taxarea inversa are TVA zero, dar in contabilitate se inregistreaza 4426 = 4427, iar diferenta afisata tine cont acum de acest TVA.
 
 :nou:
-  Note contabile. La salvarea notei, programul verifica incasarile si platile care au factura pereche completata si avertizeaza daca pentru vreuna dintre facturile cu TVA la incasare nu s-a adaugat nota de TVA exigibilizat. Notele de TVA exigibilizat se pot adauga pe loc. Verificarea poate fi oprita din settings.ini, sectiunea [tva], avertizare_exigibilizare=0.
+  Note contabile Exigibilizare TVA. La salvarea notei se avertizeaza daca nu s-a adaugat nota de TVA exigibilizat pentru incasarile/platile aferente facturilor cu TVA la incasare.
 
 :modificare:
-  Alegere partener. Starea de TVA de la ANAF arata si de cand este valabila, cu eticheta care spune ce reprezinta perioada: inregistrat TVA de la o data pana la alta, sau cod TVA anulat din data. In lista, perioada apare doar cand starea difera de nomenclator, partenerul este inactiv sau perioada s-a incheiat deja; tasta F4 arata intotdeauna perioada completa si mesajul primit de la ANAF, inclusiv atunci cand nu exista niciun partener cu codul fiscal corect.
+  Registre TVA. Corectare filtru "Diferenta sold" si lista TVA-ului exigibilizat din plati iau in calcul si facturile cu TVA neexigibil 24% sau 20%.
-
-:modificare:
-  Initializari > Optiuni utilizator > "Verificare ANAF la alegerea partenerului". Mesajul cu setarea curenta intreaba acum daca doriti sa o modificati, iar la raspunsul Nu setarea ramane neschimbata. Cand verificarea este oprita de pe calculatorul curent, se propune tot oprirea locala, nu valoarea care ar fi oprit verificarea pentru utilizator pe orice calculator.
-
-:eroare:
-  Registrele de cumparari si vanzari, incepand cu 01.08.2025. Filtrul "Diferenta sold" si lista TVA-ului exigibilizat din plati nu luau in calcul facturile cu TVA neexigibil la 24% sau 20%, deci facturile mai vechi cu TVA la incasare lipseau din rezultate.
-
-:eroare:
-  Exigibilizare TVA la incasare din Registrul de cumparari/vanzari. Butonul dadea eroare pe perioadele anterioare anului 2025, iar cota de 21% nu era luata in calcul la impartirea soldului pe cote.
-
-:eroare:
-  Alegere partener. La codurile numerice de 13 cifre (CNP) si la codurile fiscale invalide, detaliile verificarii (F4) spuneau gresit "ANAF nu a raspuns - verificarea a fost sarita". Acum se afiseaza "Persoana fizica - CNP corect", respectiv "Cod fiscal invalid - nu s-a interogat ANAF".
 
 :nou:
   D406 SAF-T. La validarea cu erori se deschide si un fisier de erori pe intelesul utilizatorului: pentru fiecare eroare - pagina, pozitia, partenerul sau contul in cauza si cum se rezolva. Erorile fictive "Cod taxa nu se afla in lista" (bug al validatorului ANAF) sunt separate la sfarsit si se pot ignora.
+
+:modificare:
+  Alegere partener. Starea de TVA de la ANAF arata si perioada de cand este valabila. 
+  Alegere partener. La CNP/CUI invalid se afiseaza "Persoana fizica - CNP corect", respectiv "Cod fiscal invalid - nu s-a interogat ANAF".
+  Corectare salvare optiune verificare ANAF la alegere partener "Initializari > Optiuni utilizator > "Verificare ANAF la alegerea partenerului".
 -->
 
 <!--

roacont.pj2

@@ -25,7 +25,7 @@ _LegalTrademark = ""
 _ProductName = "ROA - Financiar Contabilitate"
 _MajorVer = "2"
 _MinorVer = "11"
-_Revision = "65"
+_Revision = "70"
 _LanguageID = "Romana"
 _AutoIncrement = "0"
 *</DevInfo>

versiune_db.txt

@@ -1 +1 @@
-2026_07_28_01
+2026_08_02_01