Forum SAGA

Avand in vedere faptul ca prin OMFP 1802 au fost introduse conturi noi, iar majoritatea dintre noi am dezvoltat conturi analitice, consider ca ar fi utila introducerea unui tabel de corespondenta a conturilor, prin care sa introducem corespondenta intre conturile utilizate pana la 31.12.2014 si cele ce vor fi utiizate incepand cu 01.01.2015. Prin intermediul tabelului vom pute introduce atat corespondenta dintre simbolurile conturilor cat si a denumirii acestora. In maniera aceasta nu vor fi dificultati la reluarile ulterioare. Am incercat preluarea planului de conturi, introdusa prin versiunea 449, dar nu este suficienta. Sunt conturi care nu vor fi preluate.

Eu sunt de acord. Am propus și eu o implementare de genul acesta, mai exact de trecere la 1 ianuarie prin articole de tip cont_nou=891 și 891=cont_vechi a soldurilor ce se transferă de pe un cont pe altul și privirea lui cont_nou în cazul ăsta ca fiind cu sold inițial în locul lui cont_vechi. O soluție și mai bună e așa cu tabel de corespondență, în planul de conturi. Momentan nu știu de vreo decizie în sensul ăsta.

pinteae scrie:Avand in vedere faptul ca prin OMFP 1802 au fost introduse conturi noi, iar majoritatea dintre noi am dezvoltat conturi analitice........... Sunt conturi care nu vor fi preluate.

Deci, cum ar veni, începe nebunia!Dar oare când breasla asta a noastră, o să aibă măcar un moment de linişte?
Altfel, sunt de acord cu oricare dintre propuneri, care să ne înlesnească munca!

Nu incepe nebunia ci intr-un fel sau altul trebuie sa existe o continuitate.
Sunt de acord, iar daca TomaC a iesit la "rampa" sunt sanse sigure de implementare.

Sczue, as dorii sa inteleg si eu.
Ce intelegeti prin "tabel de corespondenta" sau cum ar functiona mai exact, cu ce ar ajuta?

uite ceva cum a fost la bugentari anul trecut
vezi aici documentul de la pagina 238 in jos
http://www.google.ro/url?sa=t&rct=j&q=& ... 2s&cad=rja

Un mic exemplu: ai avans pentru imobilizări în 2014. Era înregistrat în 232. Acum, în 2014 el trebuie să apară în 4093.
Deci ar trebui mutat din 232 în 4093. Problema e așa. Dacă muți acum prin articol contabil la 31/12/2014 suma din 232 în 4093, când faci bilanțul pentru 2014 nu se va reflecta corect în bilanț, dar va fi preluat corect ca sold inițial la 01/01/2015. Dacă faci articolul contabil la 01/01/2015 se va prelua corect în bilanțul de la 31/12/2014, doar că nu se va prelua corect ca sold inițial în balanța lui ianuarie și e posibil să fie o problemă la bilanțurile următoare.
Logic transpunerea ar trebui efectuată cu 01/01/2015, dată de la care conturile nu mai există sau sunt nou apărute în planul de conturi. De aceea aș fi optat pentru articole de tip
4093=891 și 891=232 la 01/01/2015. Iar la generarea bilanțului la 31/12/2015 să fie introduse/operate/corectate soldurile inițiale conform bilanțului depus la decembrie 2014.

Multumesc de informatii, sper ca am inteles.
Si pana la urma ar fi optim introducerea unui ecran in care sa introducem data la care s-ar face transpunerea, precum am alege cele doua conturi care s-ar dorii sa fie transpuse, nu?

Si totusi.
Asta imi aduce aminte de schimbarea codurilor CAEN si COR (parca era si SOR)

De ce sa nu existe o "tabela" de genul 232 = 4093 pana la 2014.12, iar programul sa "stie" (si sigur va sti) ca pana la decembrie 2014, 232 trebuie sa fie 232, ce depaseste acea data sa fie 4093?

Si varianta propusa de Cristi este buna dar daca vom folosi contul intermediar 891, nu vom avea o oglinda a corespondentelor. Acesta este motivul pentru care am propus ca preluarea sa se faca sub forma unui tabel al corespondentelor. Asa vom putea lista formularul respectiv sa-l pastram la arhiva documentelor lunii ianuarie 2015. Tabelul ar trebui sa fie atasat planului de conturi, iar la completarea lui sa o poti face direct din planul de conturi, alegand contul existent la 31.12.2014 si atasandu-i noul cont , inclusiv denumirea acestuia, utilizat incepand cu 01.01.2015. Planul de conturi vechi si cel nou, sa fie vizibil si utilizabil, in functie de luna deschisa (pana in decembrie 2014 si incepand cu ianuarie 2015).
Asa cum intuia Cristi, impactul semnificativ va fi la intocmirea raportarii semestriale la 30.06.2015 si a bilantului la 31.12.2015.
Sper ca subiectul sa aiba ecou in cadrul echipei SAGA.

Referitor la subiectul propus prin acest topic, am trimis un mail echipei SAGA, iar raspunsul a fost urmatorul:

Buna ziua,

Solutia indicata este foarte complexa si consumatoare de resurse. Ar trebui ca toate situatiile contabile din program sa tina cont de cele doua planuri de conturi, in functie de data generarii acestora. Nu se pune problema unei astfel de abordari.
Daca aveti dificultati legate de aceasta transpunere, puteti efectua o repreluare cu 01.01.2015.

Cu stima,
Sorin Nica


Ca urmare a acestui raspuns, le-am trimis un alt mail prin care le-am sugerat ca totusi sa gaseasca o alta solutie, deoarece pentru noi, utilizatorii, este total neproductiv sa "rupem" contabilitatea firmelor. Cred ca argumentul este la indemana tuturor.
Cel putin noi, care am inceput sa prelucram luna ianuarie, nu stim ce sa facem. Eu sper ca totusi sa se gaseasca o solutie pentru aceasta modificare legislativa.
SPER!

Daca dl. NICA a dat raspunsul inseamna ca - din nefericire - nu poate fi gasita o solutie care sa-l multumeasca in primul rand pe dansul.
Sa nu uitam ca este CAPO DI TUTTI CAPI
Daca ceva nu-i place (ca profesionist in programare) sansele sunt nule de a fi implementat ceva.

Stati asa ca solutia exista (cel putin asa reiese din postare), doar ca nu se gaseste a fi una optima.

PintaE a deschis acest topic pentru a ne da cu parerea.
Atunci cand tu ai propus ca sa se mai introduca o coloana cu DATA DOCUMENT pentru declaratia 394 intr-un final s-a implementat pentru ca am fost mai multi cu solutii.
Daca Administratorul vede ca este de munca foarte mult (si are dreptate sa-i treaca absolut tot prin fata ochilor; as face la fel) trebuie sa gaseasca solutia.
Noi suntem 2% inspiratia iar restul vine dinspre SAGA.
Daca noi cerem fara sa si gandim precum un programator, DEGEABA!
Asta e problema
Mai era un coleg de la Sibiu AndreiS

Ne ajuta chestia asta?
Daca DA, ganditi-va sa "nu fie consumatoare de resurse si prea complexa" aceasta solutie.

N-am zis ca nu sunt de acord cu propunerea, precum mi se pare chiar una corecta.
Sa speram ca se va gasii solutia, dar poate mai trebui sa venim si noi.

Eu deja am patit ca desi am sesizat bug-ul, pana cand n-am dat si rezolvarea nu s-a rezolvat.