eFactura, verificare partener, istoric CF: numar pe bife, TVA la incasare, explicatii pe cota

- 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

docs/scripturi-migrare-db.md

@@ -16,6 +16,13 @@ Reguli confirmate de Marius (24.07.2026):
   final (conventia existenta).
 - Aplicarea prin ODBC/`goExecutor`: sintaxa SQL*Plus `exec pachet.procedura(...)` nu functioneaza
   — foloseste `begin pachet.procedura(...); end;`.
+- **Rularea manuala se face conectat pe schema tinta** (`CONTAFIN_ORACLE` pentru `co_`, schema firmei
+  pentru `ff_`), niciodata cu un user de lucru. DDL-ul neprefixat (`create or replace package ...`)
+  merge pe schema conexiunii: pe alt user iese `PLS-00304` si ramane un obiect orfan, iar pachetul
+  tinta ramane neschimbat. In acelasi script, DML-ul pe tabele cu sinonim public nimereste tabela
+  reala si pare ca totul a mers — verifica intotdeauna iesirea sqlplus si `all_objects`.
+  `PACK_UPDATE` face `CONNECT <schema>/<parola>@ROA` real per schema (`UpdateSchemaSQLPLUS`, parola
+  din `SERVER_INFO`), deci scriptul neprefixat e corect pentru livrare.
 
 ## Continutul unui script
 
@@ -24,6 +31,8 @@ Reguli confirmate de Marius (24.07.2026):
 - **Fara `select` de raportare in script** — nu-l citeste nimeni la aplicare si poate da eroare.
   Verificarile se fac inainte, separat, pe schema de lucru.
 - **Idempotent**: rulat de doua ori nu mai schimba nimic (`merge`, `where <coloana> is null`).
+- **Un pachet sta singur in scriptul lui**, fara alt DDL sau DML alaturi: modificarile de tabele si
+  curateniile de date merg in scripturi separate, cu numar propriu.
 
 ## Compatibilitate cu serverele clientilor
 

docs/todos.txt

@@ -32,4 +32,10 @@ Ca sa vand un articol, trebuie sa il introduc in nomenclatorul de articole oblig
 
 Am vazut la SAGA (alt ERP popular) ca in nomenclatorul de articole au cateva coloane de multe preturi, probabil pentru mai multe liste de preturi (todos-articole-preturi-saga.png)
 
-Ideea este sa se poata face configurarea mult mai repede, eficient, dintr-un singur loc, ca sa se poata face factura mai rapid. Acum este nevoie de mult suport tehnic/instructaj si configurari pana se ajunge la facturare, si daca apare un articol diferit (ex: vanzare auto, in loc de marfa in mod normal), trebuie creata o politica noua de preturi, ca sa ii spun ce nota contabila de vanzare (4111 = 7xx) sa aiba aiba articolul respectiv.
+Ideea este sa se poata face configurarea mult mai repede, eficient, dintr-un singur loc, ca sa se poata face factura mai rapid. Acum este nevoie de mult suport tehnic/instructaj si configurari pana se ajunge la facturare, si daca apare un articol diferit (ex: vanzare auto, in loc de marfa in mod normal), trebuie creata o politica noua de preturi, ca sa ii spun ce nota contabila de vanzare (4111 = 7xx) sa aiba aiba articolul respectiv.
+
+13. ROAFACTURARE - FORMULARUL DE FACTURARE SA INCLUDA SI FORMULARUL DATE_FACTURA/DATE_AVIZ ETC. SI SA NU MAI INCARCE DE PE SERVER TOATE ARTICOLELE DIN TOATE POLITICELE DE PRETURI - INTRUCAT ESTE POSIBIL SA FIE SI MII DE ARTICOLE SI DUREAZA MULT SA LE ADUCA DE PE SERVER. AM INCEPUT DEJA MAI DEMULT UN FORMULAR UNIFICAT, DAR ERA MULT DE INTEGRAT DIN FORMULARUL VECHI.
+FRONTEND SIMILAR PE CARE IL DORESC ESTE IN ROAACPRO > FACTURA, SAU IN IMPORTUL DE EFACTURA, IN CARE AM INTEGRAT DATELE FACTURI, DOAR CA FACTURAREA DIN ROAFACTURARE ESTE MAI COMPLEXA - ESTE FOLOSITA SI PENTRU POLITICI DE PRETURI SI PENTRU CONTRACT/COMANDA/AVIZ/RETUR ETC.
+INTERESUL MEU ESTE SA SIMPLIFIC INTERFATA, SA FIE MAI EFICIENTA, SA NU FIE 2 FORMULARE PENTRU FACTURA, SA FAC MAI RAPID.
+
+14. ROACONT - efactura se salveaza xml detaliat si xml zip efactura si ocupa mult spatiu. vreau sa stiu cand nu mai este nevoie de xml detaliat si daca se poate curata tabelul ca sa nu mai ocupe spatiu, cel putin pentru facturi mai vechi. este important zip pentru ca este factura originala anaf.