118 lines
17 KiB
Plaintext
118 lines
17 KiB
Plaintext
DONE 1. ROACONT. verificarea codurilor fiscale pe ANAF sa foloseasta istoricul de verificari drept cache 1 luna, in loc sa verifice mereu pe anaf. DE FAPT VREAU VERIFICARE ANAF CARE ACTUALIZEAZA SI CACHE, SI DACA NU MERGE ANAF, SA FOLOSEASCA CACHE
|
|
|
|
Vreau acelasi sistem de cache si pentru Registrul TVA la incasare care acum se descarca in schema comuna de baza de date CONTAFIN_ORACLE, pe serverul de baza de date, arhive zip de la anaf si se actualizeaza tabelele de rtvai_*
|
|
Poate folosesti exact datele de la anaf descarcate pentru verificarea codurilor fiscale, in cazul in care exista informatia.
|
|
|
|
Vreau ca verificarile de coduri fiscale din D406, D394, Registrele de TVA sa foloseasca direct ANAF, si sa actualizeze cache-ul istoricul din baza de date (ISTORIC_CODURI_FISCALE)
|
|
|
|
DONE 2. ROACONT - Borderou eFactura, checkbox-urile diferente fata de Registrele de TVA sa aiba in caption si numarul de inregistrari cu diferente, astfel incat utilizatorul sa stie daca este cazul sa filtreze pentru afisarea facturilor cu diferente
|
|
|
|
DONE 3. ROACONT - modificare nota, explicatia tva sa filtreze dupa procent tva din tabel, ca sa arate o selectie mai mica de explicatii tva. vezi cum ai facut la explicatia tva din ointroduceri.vcx > import_nota.
|
|
|
|
DONE 4. ROACONT - overificari.vcx > formularul istoric coduri fiscale are coloane care nu mai au relavanta sau nu mai sunt completate din tabel. in tabelul contafin_oracle.istoric_coduri_fiscale, campul regcom are spatii si nu se afiseaza in formularul istoric. verifica
|
|
|
|
DONE 5. ROACONT - VERIFICARE cod fiscal, label-ul de sub grid-ul cu rezultate si detalii F4 sa contina si status "TVA Incasare"
|
|
|
|
DONE 6. ROAFACTURARE - EDITARE FACTURA EMISA ANTERIOR, CARE NU A FOST TRIMISA INCA IN EFACTURA (anaf_efactura.id_fact). punctul critic este ca notele contabile si eventual rulajele generate se genereaza complicat la emiterea facturii prin pack_facturare, iar editarea este o simpla editare, si nu sincronizeaza si notele contabile si rulajele. si sunt diverse tipuri de facturi sau de avize (pe baza de lista de preturi, pe baza de comanda, pe baza de contract, pe baza de aviz) si fiecare genereaza note contabile sau rulaje si articole de vanzare (vanzari si vanzari_detalii)
|
|
|
|
DONE 7. ROAFACTURARE - TVA unitar si valoarea TVA pe o linie de articol este calculata si nu salvata in vanzari si vanzari_detalii. din aceasta cauza, daca o factura are valoare totala 99.99 lei, dar utilizatorul doreste 100.00 lei total cu tva (pentru ca politica de preturi are bifat preturi fara TVA si se porneste calculul incepand de la pretul fara TVA al articolului) tva-ul se calculeaza rotunjit si nu se poate edita, ca sa dea factura fix 100.00 lei. implicatiile calculului TVA in loc de salvare sunt foarte mari si adanci in program, la introducerea facturii, listarea facturii initiale, relistarea facturii
|
|
Sau de fapt este posibil sa poata utilizatorul sa modifice "preturi_cu_tva" la nivel de fiecare articol, la introducerea facturii si ulterior la editare factura, tocmai pentru ca utilizatorul doreste sa ajusteze tva-ul total pentru ca are restrictie sa dea facturii o valoare totala rotunjita, si se poate ajusta exact din pretul cu tva individual. pret_cu_tva se salveaza in vanzari_detalii pe fiecare articol.
|
|
|
|
DONE 8. ROAFACTURARE - in pack_facturare am salvat in vanzari valori totale denormalizat (fara tva, tva, cu tva, numarul avizului/comanda/contract etc.) ca sa nu le calculez in view din vanzari_detalii pentru ca view-ul de facturi este foarte complex, cu functii si expresii si nu era optimizabil si acceseaza total tabelele vanzari si vanzari_detalii. folosesc un view pe modelul original, si un view cu valorile totale din vanzari. doar ca am observat un bug, la facturile din avize, nu se salveaza corect in vanzari avizul sau numarul/data/suma chitantei daca factura este achitata numerar. trebuie depanat. schema de verificare productie este VENDING@ROA_VENDING
|
|
|
|
DONE 9. ROAGEST - MODIFICARE REGISTRU JURNAL - SA SE POATA MODIFICA SI "NNIR" in notele contabile si sincronizat in rulajele asociate. nu exista coloana NNIR in formularul de editare.
|
|
|
|
10. ROAFACTURARE - Integrare pagina contracte si rapoarte contracte in ROAFACTURARE, similar COMENZI in ROAFACTURARE - facturare pe baza de comenzi/contracte. trebuie comasate si drepturile pe obiectele din roacontracte cu obiectele noi din ROAFACTURARE.
|
|
|
|
11. ROAFACTURARE - Integrare politici de preturi in ROAFACTURARE - sunt numai editari de liste de preturi, note contabile, nomenclator articole, drepturi pe liste de preturi, care toate se folosesc numai in programul ROAFACTURARE.
|
|
|
|
12. ROAFACTURARE - sa pot sa folosesc direct nomenclatorul de articole pe post de lista de preturi, sa nu mai definesc liste de preturi, note contabile asociate. Acum am un echivalent (lista de articole din stoc ca o lista de preturi virtuala)
|
|
|
|
Ca sa vand un articol, trebuie sa il introduc in nomenclatorul de articole obligatoriu. Acum trebuie sa il introduc si intr-o lista de preturi, ca sa am valuta, nota contabila de vanzare si daca are pret_cu_tva sau nu, procentul de tva vanzare, si bineinteles, pretul.
|
|
|
|
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.
|
|
|
|
DONE 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 frm_facturare_articole2, 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. in plus vreau si editare factura/aviz in toate variantele (politici preturi, comanda, contract, aviz etc) prin regenerare, adica sa arate formularul completat ca si cum ar fi inainte de salvarea initiala, ca sa pot sa fac editari ca si cum as fi la introducerea initiala - bineinteles cu stergerea facturii initiale (sters = 1) si salvarea celei noi, pentru a se vedea ce s-a modificat
|
|
|
|
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.
|
|
|
|
15. ROACONT - ce locuri din program mai folosesc frm_modific2007 in loc de frm_modific2024. trebuie migrat la formularul mai nou.
|
|
|
|
16. ROAFACTURARE - in date_factura/date_aviz etc, la finalizare se verifica cursul valutar necesar pentru politicile de preturi care se factureaza. la revenire din formularul de curs valutar, focusul revine inainte de numar document, cred ca pe TIP DOCUMENT, si la iesire din serie se regenereaza numar act, ceea ce este periculos daca utilizatorul l-a schimbat si se modifica automat.
|
|
|
|
17. ROAFACTURARE - daca o nota contabile de vanzare nu are configurat tip de venit/cheltuiala, si nici articolele din lista de preturi, si nici nu se completeaza tip venit/cheltuiala la facturare, la finalizarea facturii apare o eroare oracle ORA ca id_venchelt nu are voie sa fie null. eroarea nu este user friendly si nu se poate recupera usor, pentru ca trebuie sa se dea renunt la toata factura si sa se reia tot porcesul, cu completarea tip venit cheltuiala. si nici nu stiu de ce este obligatoriu tip venit/cheltuiala.
|
|
|
|
18. ROAFACTURARE - EMITERE FACTURA DIN PROFORMA
|
|
|
|
19. ROAFACTURARE - EDITARE PROFORMA
|
|
|
|
20. ROAFACTURARE - FACTURA DIN COMANDA, COMANDA SE CONSIDERA FACTURATA DACA EXISTA FACTURI CU ACELEASI CANTITATI. AS VREA SA PUN MARKER DE FACTURAT PE COMANDA, CA SA NU MAI CAUT FACTURI - ESTE COSTISITOR. DOAR CA TREBUIE SA FII ATENT CA O COMANDA SE POATE FACTURA TOTAL/PARTIAL, SAU DIN MAI MULTE FACTURI, SAU SE POATE INCHIDE FORTAT. ACUM INCHIDEREA FORTATA ADAUGA CANTITATI NEGATIVE PE COMANDA, CA SA FACA CANTITATILE NEFACTURATE ZERO.
|
|
|
|
DONE 21. ROACONT - in formularul de verificare coduri fiscale, ar trebui sa fie si perioadele de tva, tva incasare, inactivitate, la fel ca in istoric, pentru ca utilizatorul sa nu mai caute altundeva. de asemenea, in messagebox pentru verificarea automata pe ANAF individuala ar trebui sa fie toate aceste informatii. sa se poata edita partenerul din formularul de verificare coduri fiscale prin dublu-click pe numele/codul fiscal al partenerului, similar cu formularul saft.
|
|
|
|
22. ROADEF - la datele firmei, dupa completarea codului fiscal sa existe buton de preluare date de pe ANAF, similar cu cel din ROACONT partener nou. vezi ca trebuie completate localitatea si judetul cu id-uri. am inceput sa lucrez ceva - poate trebuie doar continuat si corectat - am ramas la judet si localitate.
|
|
23. ROACONT - importul de eFactura recunoaste articolul doar pe text identic; cheie normalizata (fara cifre) + prefix configurabil per firma duce recunoasterea de la 52% la 72,3%. (rec_directie_roacont_2026_09.md, 1.1)
|
|
|
|
24. ROACONT - contabilizare in lot a eFacturilor primite, cu semafor verde/galben/rosu pe furnizor si anulare in bloc: 41,3% din facturi intra pe verde cu 93,8% precizie. (rec_directie_roacont_2026_09.md, 1.2)
|
|
|
|
25. ROACONT - LLM doar pe liniile fara precedent in istoric (~28%) si pe furnizorii noi, cu eticheta vizibila ca sugestia vine de la AI. (rec_directie_roacont_2026_09.md, 1.3)
|
|
|
|
26. ROACONT - la importul de extrase, partenerul sa se invete din istoric (IBAN + text de descriere normalizat, propus doar cand cheia a dus mereu la acelasi partener): 4,6% -> 28,5% acoperire la 97,9% precizie. (rec_directie_roacont_2026_09.md, 2.1)
|
|
|
|
27. ROACONT - importul de extrase sa salveze IBAN-ul pe partener cand operatorul confirma potrivirea; azi nomenclatorul are IBAN la 4,5% dintre parteneri si cheia cea mai sigura nu are pe ce lucra. (rec_directie_roacont_2026_09.md, 2.2)
|
|
|
|
28. ROACONT - la extrase, dupa ce partenerul e cunoscut sa se arate lista scurta a documentelor lui deschise, ordonate dupa potrivirea sumei; automatizarea completa a facturii e limitata structural - numarul facturii apare in textul bancii doar in 25% din cazuri. (rec_directie_roacont_2026_09.md, 2.3)
|
|
|
|
29. ROACONT - importul de extrase Banca Transilvania citeste denumirea si IBAN-ul de pe pozitii fixe in descriere, dar la platile prin OP catre alta banca apare un camp in plus si denumirea se citeste ca numar de OP. (rec_directie_roacont_2026_09.md, 2.4)
|
|
|
|
30. ROACONT - la asocierea platii cu factura, bucla iese neconditionat dupa primul numar incercat (oproceduri_import.prg:736), deci o plata care acopera mai multe facturi ramane nepereche. (rec_directie_roacont_2026_09.md, 2.4)
|
|
|
|
31. ROACONT - cand acelasi numar de document se potriveste pe mai multe randuri, GetDocumentByContPartenerAct doar scrie in log fara sa arate operatorului candidatii. (rec_directie_roacont_2026_09.md, 2.4)
|
|
|
|
32. COMUN - VerifIBAN (oproceduri_comune.prg:7885) intoarce raspuns gresit cand apelantul are selectat un cursor cu camp iban: variabilele nu sunt declarate si citirile neprefixate se rezolva la camp, nu la parametru. Afecteaza si validarea IBAN-ului la introducerea partenerului. (rec_directie_roacont_2026_09.md, 2.4)
|
|
|
|
33. ROACONT - de aflat de ce doar 7 din 21 de firme ale cabinetului folosesc importul de extrase; la restul extrasele se bat integral de mana. (rec_directie_roacont_2026_09.md, 2.5)
|
|
|
|
34. ROA2WEB - drepturile de utilizator nu sunt implementate; pana nu se rezolva, nimic nu poate fi aratat unui client. (rec_directie_roacont_2026_09.md, 3.1)
|
|
|
|
35. ROA - punte MCP peste Oracle: intrebi in Claude Code si el ruleaza interogari pregatite, modelul primeste rezultatul, nu baza. (rec_directie_roacont_2026_09.md, 3.2)
|
|
|
|
36. ROA - tablou de bord pe toate firmele cabinetului, cu alerte de noapte (luna neinchisa, token SPV expirat, facturi necontabilizate); singurul candidat de abonament nou. (rec_directie_roacont_2026_09.md, 3.3)
|
|
|
|
37. ROACONT - inchiderea de luna ca flux unic: azi sunt 13 comenzi in doua meniuri, fara ordine si fara bifare. (rec_directie_roacont_2026_09.md, 3.4)
|
|
|
|
38. ROACONT - sablon reutilizabil de mapare la preluarea unui client din alt program; azi maparea de conturi se reface manual la fiecare preluare. (rec_directie_roacont_2026_09.md, 3.5)
|
|
|
|
39. ROA - asistent de suport pe documentatia proprie; butonul de chat exista deja in mesajele de eroare, ii lipseste continutul (manual, versiuni, dictionar de erori). (rec_directie_roacont_2026_09.md, 3.6)
|
|
|
|
40. ROACONT - e-Transport: azi nu exista nimic, concurenta are modul dedicat. (rec_directie_roacont_2026_09.md, 3.7)
|
|
|
|
41. ROACONT - sa se poata genera xml efactura stornare si sa se trimita in SPV. Acum se poate face manual prin Borderou eFactura > Listare > Editare in browser > Stornare > Salvare xml stornat > meniul eFactura > Trimite xml efactura > trimitere in SPV xml storno salvat anterior.
|
|
Vreau sa fie operatia mai simplificata pentru utilizatori, pentru cazul in care s-a trimis in SPV o factura eronat (exemplu - client gresit). Sa se poata genera si trimite xml stornat. Utilizatorul poate apoi sa stearga factura originala din contabilitate si sa o reemita corectata (ex cu clientul corect) si sa o trimita din nou in eFactura.
|
|
In felul acesta se rezolva, chiar daca nu oficial, imposibilitatea de anulare a unei facturi trimise in SPV. O stornez doar cu xml, si o sterg din contabilitate.
|
|
|
|
42. ROACONT - daca se permite modificarea manuala a sumelor de la TVA, nu se poate si o atentionare daca TVA este altul decat procentul din explicatia de TVA selectata?
|
|
|
|
43. ROAFACTURARE - configurarea initiala pentru a putea factura un articol - este foarte complexa si vreau mai fluid, poate si cu un wizzard
|
|
- definire grup TOTAL in ROADEF si asociere utilizatori in grupul TOTAL
|
|
- creare articol in ROAPRETURI
|
|
- creare nota contabila vanzare
|
|
- creare politica preturi si introducere articol
|
|
- definire serii numere facturi
|
|
- completare optiuni document factura, aviz, documente incasare, bon fiscal, bon pos
|
|
Poate un wizzard
|
|
|
|
44. ROACONT - sa se poata genera xml efactura stornare si sa se trimita in SPV. Acum se poate face manual prin Borderou eFactura > Listare > Editare in browser > Stornare > Salvare xml stornat > meniul eFactura > Trimite xml efactura > trimitere in SPV xml storno salvat anterior.
|
|
Vreau sa fie operatia mai simplificata pentru utilizatori, pentru cazul in care s-a trimis in SPV o factura eronat (exemplu - client gresit). Sa se poata genera si trimite xml stornat. Utilizatorul poate apoi sa stearga factura originala din contabilitate si sa o reemita corectata (ex cu clientul corect) si sa o trimita din nou in eFactura.
|
|
In felul acesta se rezolva, chiar daca nu oficial, imposibilitatea de anulare a unei facturi trimise in SPV. O stornez doar cu xml, si o sterg din contabilitate.
|
|
|
|
45. ROACONT - la verificarea D406 SAFT, verificare facturi achizitie, daca sunt facturi de achizitie din import, unde tva-ul se declara pe Declaratia Vamala de Import (adica alt document), in Registrul TVA Cumparari, suma cu TVA de pe factura de achizitie nu include si TVA, si apare diferenta fata de totalul facturii din SAFT, care calculeaza automat TVA bazat pe procentul TVA al articolelor.
|
|
Vreau sa apara in xlsx de verificare si o coloana cu verificarea daca acesta este cazul, pentru ca sa stie utilizatorul ca nu este o greseala, ci este normal.
|
|
|
|
46. COMUN - roa_sync.ps1 (COMUN\scripts): la pasul 4, cand repo-ul COMUN e pe un branch claude/* cu tree curat, face checkout main INAINTE de a prelua revizia SVN in git. Checkout-ul suprascrie in working copy SVN sursele urmarite si de git (.prg, .txt, .vc2) cu versiunea veche din main, iar apoi raporteaza "nimic de comis". Vazut 14.09.2026 dupa svn commit r18103 (oproceduri_comune.prg, todos.txt, omodificari.vc2 revenite la vechi; reparat cu svn revert + git checkout de pe branch + roa_sync din nou).
|
|
Vreau ca roa_sync sa nu mai strice working copy-ul: inainte de checkout main sa verifice ca fisierele urmarite de SVN nu difera fata de SVN (svn status / svn diff) si, daca difera, sa se opreasca cu avertisment; sau sa comita sync-ul fara checkout (ex. git stash / worktree pe main).
|