Merge branch 'claude/todos-roacont'

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.
 
 ## Sursa de referinta pentru DDL: MARIUSM_AUTO, nu productia
 
@@ -52,6 +59,8 @@ Marius ce nu e aplicat. Exportul sursei de referinta: `oracle_export.md`.
 - **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.