Tema de proiectare-programare pentru contabilitatea financiara

I.       Destinatia aplicatiei

Aplicatia "Contabilitatea financiara" este destinata sa rezolve pe calculator principalele probleme legate de contabilitatea financiara a unei societati comerciale.

II.      Functiile aplicatiei

Aplicatia trebuie sa permita:

implementarea ei pe calculator si deschiderea exercitiului financiar in orice luna din anul calendaristic curent;

incheierea anului financiar si deschiderea noului an financiar;

adaugarea de noi conturi, oricand in interiorul unui exercitiu financiar;

tinerea la zi in calculator, a unei transe curente cu tranzactiile efectuate dupa ultima incheiere de luna;

simularea incheierii de luna pe baza transei curente si elaborarea unor documente simulate cum ar fi registru jurnal, fisele conturilor, cartea mare sah, balanta sintetica si balanta analitica, cu posibilitatea ca in cazul depistarii de catre utilizator a unor incompatibilitati sau inadvertente, acesta sa poata aduce transei curente corectiile ce se impun fara a apela la operatiuni de stornare;

validarea transei curente, elaborarea in forma definitiva a documentelor de la aliniatul precedent, tiparirea lor la imprimanta si arhivarea lor conform prevederilor legale;

deschiderea unei noi transe curente;

inchiderea anului financiar, elaborarea documentelor de sinteza si raportare, precum si deschiderea (initializarea) noului an financiar.

III.            Cerinte impuse aplicatiei

Aplicatia va dispune de un meniu care sa sugereze utilizatorului principalele momente din derularea contabilitatii financiare manuale, astfel incat acesta sa se simta cat mai confortabil cu aplicatia care tine contabilitatea pe calculator.

In principiu, aplicatia nu trebuie sa vina cu ingradiri in ce priveste activitatea contabila ci dimpotriva, trebuie sa aduca inlesniri, sa efectuieze si operatiuni la care utilizatorul nu putea aspira in regim manual, cum ar fi elaborarea de grafice, extrase din tabele dupa criterii formulate ad-hoc sau calculul unor indicatori sintetici greu de obtinut in varianta manuala a contabilitatii.

Alte precizari

- se recomanda ca simbolurile conturilor sa fie declarate de tip text(11);

matricile in care sunt stocate conturile corespondente sa poata stoca cel putin 27 de conturi corespondente pentru fiecare cont sintetic

in cazul in care se impune validarea transei curente si elaborarea documentelor in forma definitiva, inainte de incheierea lunii curente, utilizatorul va putea reveni ulterior, la situatia de dinaintea validarii transei si va putea continua completarea transei pana la sfarsitul lunii curente, pentru a putea efectua o incheiere normala de luna.

solutia adoptata va trebui sa permita incheierea anului financiar si resetarea bazei de date pentru inceperea noului an financiar.

Solutia propusa de proiectant (varianta)

Modelul conceptual al datelor (M.C.D)

(entitate-legatura)Cuprinsul solutiei

Meniul aplicatiei

Tabelele aplicatiei

Fluxul soldurilor

Evolutia transei

Situatiile lunare

Bilantul si anexele

Situatii speciale

- Implementarea

- Cont nou

- Inchiderea anului

Simulare transa

Modelul logic al datelor (MLD)

(relational)

Document

Operatie

Debiteaza Crediteaza

Cont

Corespondenta

1.   Meniul principal

Observatii In practica este necesar ca optiunile privitoare la fise conturi sa fie definite ca submeniuri prevazute cu optiuni cum ar fi conturi sintetice/conturi analitice, apoi acestea pot fi divizate pe vizualizare tiparire si in final ultimele submeniuri pot fi divizate in fise pentru un singur cont sau pentru mai multe conturi. La fel optiunea carte mare sah poate fi transformata in submeniu cu optiuni privitoare la zona din conturi corespondente pe care dorim s-o vizualizam sau s-o listam, stiut fiind ca zona conturilor corespondente se poate intinde la unele conturi sintetice pe 25-27 de conturi corespondente ceea ce ar fi imposibil sa incapa pe o coala fie ea si A3 culcata. La fel si optiunea privitoare la balanta se poate divide in balanta sintetica/balanta analitica.

Optiunile Intrare in contabilitate si Revenire in Access din submeniul Configurare se folosesc doar in perioada de testare a bazei de date pentru a vedea cum se comporta ea atunci cand fereastra DataBase este inlocuita cu un formular de tip Main care nu mai permite accesul la aceasta fereastra si nici la meniul ACCESS (LAB 7).  Cuprinsul solutiei

2. Principalele tabele necesare aplicatiei

Tabelul matrice_rulaj_debit contine 27 de locatii pentru rulajele a maximum 27 de conturi corespondente. Unele conturi sintetice au mai mult de 27 de conturi sintetice, dar nu toate sunt folosite intr-o societate. De aceea este de datoria utilizatorului sa faca uz de campul starea contului din tabelele de functionare conturi, camp care dispune de un combobox cu optiunile folosit si blocat si sa blocheze conturile nefolosite de el. Cuprinsul solutiei

Tabelul Matrice_rulaj_debit se incheie cu doua campuri care nu au fost prinse in capture: rulajtotal si data. Tabelul Sah_debit are si el spatiu pentru 27 conturi corespondente.

Tabelele Structura_bilant si Structura_profit au spatiu pentru 25 de conturi ce se pot insuma pe un rand si se incheie cu campurile Nr_conturi_pe_rand.

Contul de profit si pierdere are tabele similare cu cele ale bilantului.

Cuprinsul solutiei

Sa remarcam ca in afara de tabelele corespunzatoare registrelor contabile si documentelor de sinteza mai exista si alte tabele carora probabil un incepator nu le-ar duce lipsa! Acestea sunt tabele de manevra, adica tabele cu ajutorul carora trecem de la un stadiu la altul al prelucrarii datelor pana ce obtinem unul sau mai multe tabele de forma de care avem nevoie pentru a redacta rapoarte (documente contabile).

De exemplu, pentru a sti care sunt conturile ale caror tranzactii trebuie luate in consideratie la calculul soldului unui cont sintetic de activ, am conceput tabelul Matrice debit care pe un articol, contine codul unui cont sintetic urmat de simbolurile conturilor corespondente ( de aici si numele de matrice-debit, dar tabelul se putea numi oricum. Important este sa stim ce vrem sa facem cu el si de aici rezulta si structura pe care i-o vom da tabelului). Dispunand de acest tabel si de ultima transa de tranzactii (tabelul Adaos_jurnal), putem parcurge secvential tabelul Matrice debit si pentru fiecare cont sintetic din articolul curent parcurgem secvential tabelul Adaos_jurnal. La fiecare articol din Adaos_jurnal ne intrebam daca contul sau este egal cu contul sintetic al carui sold il calculam si daca da, verificam daca contul corespondent (cont de credit) al articolului curent din Adaos_jurnal se afla printre conturile corespondente specificate in articolul curent din Matrice debit. Daca da, valoarea acelei tranzactii va fi adunata la soldul contului sintetic curent.

3. Fluxul soldurilor

In afara de informatiile specifice unui plan de conturi, tabelul Planconturi mai contine soldurile si rulajele fiecarui cont pe ultima luna (transa). Aceleasi informatii, dar pe intreaga perioada scursa de la inceputul anului pana in prezent, se afla stocata in tabelul Solduri.

In timpul anului financiar, mai exact la sfarsit de luna, pentru a opera tranzactiile din ultima transa, soldurile din luna precedenta sunt preluate din tabelul Planconturi de interogarea Extrag_solduri si depuse in tabelul Sold_conturi. In acel tabel, ele sunt actualizate pentru fiecare articol din transa noua de catre programul Impact_sold si raman acolo pana la rula-rea programului Transfer_sold_plan, cand se intorc inapoi in PlanConturi impreuna cu rulajele curente si cu soldul unic actualizat pentru ultima transa (insotit dupa caz de simbolul D sau C). Cuprinsul solutiei

Dupa trimiterea lor spre tabelul Planconturi, acelasi program lanseaza subrutina Creare_rulaj_total, care scoate un extras pe ultima luna din "Solduri" sub numele de

"Extras_din Solduri" si pe acest extras, aduce din PlanConturi rulajul curent. Cu rulajul curent si cu rulajul total de luna trecuta din extras, calculeaza rulajul total la zi, pe care-l depune in " Extras_din Solduri". In final, prin intermediul macroului si interogarii Transfer_Sinteza_Transei, aduce in tabelul Solduri noul extras, adica noile solduri, rulajele curente si rulajele totale pe luna incheiata. Ele sosesc aici prin Append, astfel ca din tabelul Solduri se poate vedea evolutia soldurilor, a rulajelor curente si a rulajelor totale de la inceputul anului pana la ultima transa validata. La initializarea exercitiului financiar, soldurile se trec in Planconturi si ajung in Solduri folosind macroul Transfer_sold_solduri. In plus, pentru conturile sintetice, se mai trec in Planconturi si soldurile initiale (cele de la sfarsitul anului trecut sau dupa caz cele de la inceputul exercitiului financiar). Chiar daca sunt aceleasi cu soldurile din rubricile sold_debit respectiv sold_credit, ele se mai trec odata in rubricile tip_sold_initial si sold_initial, pentru ca aici ele raman tot timpul anului si vor fi folosite pentru a fi puse in prima linie din fisa Carte mare sah a contului sintetic. Soldurile din rubricile sold_debit si sold_credit sunt solduri lunare. (Aceasta faza - adica initializarea exercitiului financiar - va fi prezentata in detaliu intr-un alt curs, dupa elaborarea bilantului si a rapoartelor de sinteza).

In ce priveste rulajele se poate deduce din cele de mai sus ca rulajele curente se calculeaza impreuna cu soldurile curente, in subrutina Transfer_sold_plan si se depun in PlanConturi. Rulajele totale se calculeaza in subrutina Creare_rulaj_Total, iar restul campurilor necesare pentru actualizarea tabelului " Extras_din Solduri" sunt preluate de aceeasi subrutina din PlanConturi. La terminarea rularii subrutinei Creare_rulaj_Total, tabelul " Extras_din Solduri" este gata pentru a fi adaugat la tabelul Solduri. Transferul se face cu macroul Transfer_Sinteza_Transei din subrutina Transfer_sold_plan.

4.     Evolutia unei transe

Transa se construieste in tabelul Adaos_jurnal. O transa noua incepe cu alegerea optiunii Transa noua din meniul Tranzactii, ale carui optiuni se pot vedea in figura din stanga. La alegerea acestei optiuni tabelul Adaos_jurnal este golit de tranzactii, iar butonul Validare_transa care la ultima sa apasare s-a autoblocat, devine din nou activ.

Pana la validare, transa trebuie simulata, pentru a vedea efectele sale asupra conturilor care au tranzactii. Simularea este obligatorie pentru ca daca transa este validata, o parte din prelucrarile facute pe timpul simularii raman definitive si pe baza lor se vor obtine documentele definitive de contabilitate (fisa contului, cartea mare sah, balanta, etc.) Cuprinsul solutiei

Dintre efectele simularii remarcam descompunerea tranzactiilor in doua randuri fiecare cu structura asemanatoare fisei cont, dar pastrand ordinea operatiilor din transa si alt efect, gruparea tranzactiilor pe coduri, pentru a vedea mai usor evolutia soldurilor (sumelor) conturilor afectate de tranzactii. Efectele sunt create de subprogramul Impact_sold (din modulul Impact-direct), la apasare butonului Simulare Efect Transa din meniul Tranzactii. Acest modul creaza tabelul Impact_rulaj_sold si in final printr-o interogare, creaza tabelul 'Evolutie_sold_cont'. Efectele simularii pot fi vizualizate la apasarea butoanelor Vizualizare efect si Efect pe Conturi, dar inainte de aceasta programul Impact_sold continua cu

rularea subrutinei "Transfer_sold_plan"din modulul "Valid" care face actualizarea datelor din tabelul Plan Conturi si anume: calculul rulajelor curente din ultima transa, a soldurilor si a rulajelor totale la zi (folosind in acest scop sumele din tabelul "Sold_conturi", soldurile de luna trecuta si rulajele totale de luna trecuta din tabelul Planconturi). In continuare se mai produc automat urmatoarele evenimente:

Rularea subrutinei "Creare_rulaj_total" care creaza tabelul Extras_din _ Solduri, face transferul rulajelor curente din tabelul Planconturi in tabelul Extras_din _Solduri si calculeaza celelalte campuri din tabelul Extras_din _Solduri;

Alipirea tabelului Extras_din _Solduri (continand soldurile, rulajele curente si rulajele totale la zi), la tabelul Solduri, (interogarea "Transfer_Sinteza_Transei" prin macroul cu acelasi nume, lansat din subrutina "Transfer_sold_plan"din modulul "Valid" );

Append fisier Adaos_jurnal la Registru_jurnal (interogarea Append_Adaos , prin macroul cu acelasi nume, lansat din subrutina "Transfer_sold_plan");

Append Evolutie_sold_conturi la Fisa_cont si apoi ordonarea tranzactiilor din acest fisier dupa conturi, iar in cadrul contului, dupa nr. crt. din registrul Jurnal, ceea ce se realizeaza printr-un index compus din cod si nr.crt (interogarea Append_miscari_fisa lansata de macroul Adaug_misc_fisa prin subrutina"Transfer_sold_plan");

Crearea tabeleleor "Matrice_rulaj_debit" si "Matrice_rulaj_credit" care contin rulajele totale pentru conturile corespondente ale fiecarui cont sintetic. Aceasta actiune este dusa la bun sfarsit de subrutina "Rulaj_coresp_debit" si respectiv

" Rulaj_coresp_debit" care are ca principala destinatie crearea unui extras din fisierul "Sold_sintetic_debit" si respectiv "Sold_sintetic_credit" . In actuala versiune "matrice_rulaj_debit" si "matrice_rulaj_debit" nu se arhiveaza nicaieri pentru ca ele se creaza ad_hoc, din "Adaos_ jurnal" folosindu-se "Matrice_debit" si respectiv credit. Subrutina "Rulaj_coresp_debit" lansata din modulul "Validare" o apeleaza pe

" Rulaj_coresp_credit" si apoi ele sunt urmate de macrourile care adauga noul "Extras_sintetic_debit" respectiv credit la "Solduri_sintetice_debit", respectiv credit. Urmeaza rutina "Combin_sintetice" care produce tabelul "Balanta" si apoi crearea tabelelor "sah_debit " si "sah_credit", create cu programele care poarta chiar numele tabelului . Aceste tabele contin principala parte din datele unei fise carte mare sah, pentru fiecare cont sintetic in parte (datele sunt ordonate pe conturi sintetice).

Daca toate operatiunile de mai sus, s-au incheiat cu succes, putem folosi optiunile Vizualizare efect si Efect pe Conturi din meniul Tranzactii.

Cuprinsul solutiei

Dupa aceasta enumerare de prelucrari cititorul s-ar putea intreba cum ar fi putut el, fara experienta, sa-si fi imaginat din proprie initiativa o asemenea secventa complicata de prelucrari. Secretul consta in a ne gandi cum s-ar putea ajunge prin intermediul programelor si obiectelor cu care opereaza ACCESS de la tabelul Adaos_jurnal ce reprezinta registrul jurnal la documentele de sfarsit de luna (fisa contului, carte mare sah, balanta). Peste aceasta secventa de prelucrari vom suprapune principalele momente din viata aplicatiei, reflectate deja in meniul de mai sus si necesitatea ca in final tabelul pe care se va construi raportul de obtinere a fiecarui document sa aiba o structura cat mai apropiata de cea a documentului pe care vrem sa-l obtinem. Acest deziderat se va putea urmari in continuare in descrierea modului referitor la felul in care s-a conceput obtinerea documentelor lunare. Sa remarcam ca in cele ce urmeaza nu vom vedea noi prelucrari, dar vom vedea care din etapele prelucrarii enumerate mai sus, este menita sa netezeazsca drumul spre un document sau altul. Inainte de aceasta mai trebuie remarcat ca organizarea secventei prelucrarilor care trebuie facute pentru a ajunge de la transa curenta la documentele lunare si ulterior la bilantul anual, mai trebuie sa tina seama de o cerinta specificata in tema de proiectare-programare formulata de beneficiar si anume aceea ca dupa fiecare simulare, daca este cazul, sa ne putem intoarce la situatia de dinainte de simulare si sa continuam editarea transei curente pana la sfarsitul lunii curente.

Aceasta cerinta impune ca sa lucram cu mai multe copii ale fisierelor de baza

(registrul jurnal, planul de conturi - partea care contine rulaje si solduri, tabelul solduri, solduri sintetice, etc.) Un efect asemanator asupra secventei de prelucrari va avea si necesitatea de resetare a aplicatiei, dupa incheierea anului financiar.

In solutia pe care o prezentam aici problema aceasta s-a rezolvat prin faptul ca programul atasat optiunii Simulare transa incepe cu restaurarea fisierelor de baza (de referinta). Acestea poarta numele fisierelor enumerate mai sus, dar au si o extensie sub forma _ini. Cand facem validarea transei, fisierele sub numele fara extensie (fisierele de lucru) sunt salvate peste cele cu extensie, astfel ca incepand cu urmatoarea rulare fostele fisiere de lucru devin fisiere de baza (de referinta). Pentru orice eventualitate, inainte de a salva fisierele de lucru peste cele de referinta, fisierele de referinta sunt salvate peste fisierele de siguranta care au extensia _prec. De fapt, acesta este singurul lucru ce se petrece atunci cand facem validarea transei.

Sa vedem in continuare cum secventa de prelucrari descrisa mai sus, "pregateste terenul " pentru fiecare situatie lunara. In cadrul orelor de laborator aceasta secventa va fi prezentata progresiv si va fi realizata efectiv de studenti pe baza schemelor de sistem de la sfarsitul acestei lectii.

5.     Situatiile lunare Cuprinsul solutiei

Programele, tabelele, interogarile, macrourile si rapoartele care concura la scoaterea fiecarei situatii lunare au fost incorporate in proceduri care se lanseaza automat la alegerea optiunii corespunzatoatre din meniul Rapoarte dupa cum urmeaza:

pentru Cartea mare sah, se folosesc doua tabele cu structura identica, valabila in principiu pe tot timpul anului (matrice_debit si matrice_credit . Deosebirea dintre ele se refera la continut; mai exact unul este pentru debitare si celalalt pentru creditare. Aceste tabele contin conturile cu care se debiteaza si respectiv se crediteaza conturile sintetice. Ele se actualizeaza la inceputul anului financiar din optiunea meniului Configurare, numita Plan de Conturi care lanseaza subrutinele Genmat_debit si respectiv Genmat_credit . Acestea lucreaza astfel: pentru fiecare cont din PlanConturi se verifica prin tabelul Funct_cont_debit respectiv Funct_cont_credit, daca acel cod este implicat in relatii cu alte conturi si daca da, toate conturile cu care acesta are relatii, sunt descarcate intr_un singur articol, din tabelul numit matrice_debit si respectiv matrice_credit. Trecerea de la Funct_cont_debit respectiv Funct_cont_credit la tabelul matrice se face printr-un tabel de tranzitie (extras_debit si respectiv extras_credit) care se editeaza pentru fiecare cont sintetic in parte, prin intermediul unei interogari, al carei cod SQL este incorporat in subrutina genmat_debit si respectiv genmat_credit din modulul Carte_sah. Inainte de a fi actualizate, tabelele de tranzitie trebuie sterse , pentru ca actualizarea lor se face prin Append. Stergerea se face cu interogarile si respectiv macrourile Sterg_extras_debit si Sterg_extras_credit. Si matrice_debit si credit trebuie sterse inainte de actualizare, deoarece ele se creaza cu AddNew, pe versiunea veche. Pentru aceasta exista interogarile si respectiv macrourile Sterg_matrice_debit si respectiv sterg_matrice_credit. Lunar, la Simulare transa, se construieste cate o matrice cu rulajele totale pe debit ("Matrice_rulaj_debit") si respectiv pe credit ("Matrice_rulaj_credit" ) ale conturilor corespondente. Concret, fiecare articol dintr-o astfel de matrice, contine rulajele totale ale unui cont sintetic., urmat de rulajele totale care il compun, adica de rulajele totale ale conturilor corespondente. Aceste matrici sunt produse de programul "Rulaj_coresp_debit" respectiv credit. Tot cu ocazia validarii transei, se creaza tabelele sah_debit si sah_credit, folosindu-se in acest scop subrutinele care le poarta numele.

O astfel de subrutina se bazeaza in principal pe tabelele matrice debit respectiv matrice_credit pe care le va parcurge secvential. Pentru fiecare articol curent din matrice debit respectiv matrice_credit se va parcurge secvential ultima transa (tabelul Adaos_jurnal) si anume: pentru fiecare articol din ultima transa, rutina verifica daca contul_debitor, respectiv cel creditor, se afla printre codurile-relatie ale codului sintetic curent din tabelul din matrice debit respectiv matrice_credit si daca da, articolului respectiv i se construieste o copie in tabelul sah_debit, respectiv sah_credit. In aceasta copie valoare este pozitionat indreptul contului-relatie la care se refera.

Cand transa a fost parcursa in intregime, se trece la urmatorul articol din tabelul matrice.

Subrutinele sah_debit si sah_credit incep prin a sterge continutul tabelelor sah_debit si respectiv sah_credit; pentru aceasta s-au prevazut interogarile si macrourile numite sterg_sah_debit si respectiv sterg_sah_credit. Tabelul sah_debit, respectiv sah_credit este sortat pe coduri sintetice, iar in cadrul codului pe nr.crt din registru jurnal.

Tabelul sah_debit, respectiv sah_credit se apropie mult de imaginea unei fise Carte Mare sah, doar ca pentru codurile relatie ale contului sintetic contine obligatoriu 27 de coloane ceea ce necesita unele adaptari ale acestor tabele, astfel ca fisa carte mare sah sa poata fi editata pe o coala A4 orizontala (landscape). De aceea activitatea calculatorului la faza Simulare transa se opreste aici. Ulterior, daca se preconizeaza generarea unor fise carte mare sah dupa tabelele sah_debit, respectiv sah_credit, se va apela la optiunea Carte mare din meniul Rapoarte. Aici utilizatorul are posibilitatea sa precizeze daca fisele carte mare sah sunt pentru debit sau pentru credit, ce pagina din fisa se doreste, daca pagina va fi vizualizata sau tiparita. Corespunzator optiunilor alese, in continuare se va lansa in executie o interogare sah_debit_i_j, respectiv sah_credit_i_j care pregateste terenul pentru lansarea raportului Fisa_sah_debit, respectiv Fisa_sah_credit. In aceste denumiri, i si j reprezinta numarul de ordine al contului corespondent cu care incepe si respectiv cu care se termina fisa respectiva. Aceasta interogare ataseaza la fiecare articol din tabelul sah_debit, respectiv sah_credit, cateva coloane din Planul de conturi (cod_cont, denumire cont si sold_sintetic), codurile conturilor corespondente asociate fiecarui cont sintetic - din tabelul matrice debit respectiv matrice_credit (pentru a fi folosite ca denumire de coloana in tabelul fisei) si rulajele totale ale conturilor sintetice si ale conturilor corespondente (preluate din "Matrice_rulaj_debit" respectiv "Matrice_rulaj_credit") pentru a completa ultimul rand din fisa. Acesta urmeaza dupa cel din subsolul contului sintetic curent, calculat cu functia SUM. Din aceasta interogare, cand se elaboreaza raportul pentru fisa Carte Mare Sah cu wizard-ul, in fereastra acestuia se vor prelua doar campurile specificate in imaginea din stanga, plus campul "numar_coduri_cumulate", care este folosit in prima coloana (cea pentru primele 6 conturi): Cuprinsul solutiei

- Pentru conturile sintetice se poate folosi raportul Fisa_conturilor_din_evolutie care se bazeaza pe interogarea "Evolutie_PlanConturi" . Aceasta pe langa campurile din Evolutie_sold_cont, mai aduce din planul de conturi campurile Cod_cont, Den_cont, Sold_debit, Sold_credit, TipSold, Sold, Tip_sold_init si Sold_init, iar din Sold_conturi aduce campurile Sold_debit si Sold_credit care de fapt sunt sume debit, respectiv sume credit

Pentru Fisele conturilor desfasurate pe conturi analitice, lucrurile sunt mai complicate. Pentru aceste conturi a fost introdus tabelul "Conturi_radacina" cu campurile radacina, nr-nivele_sub_cont si Nr_cifre_la_nivelul2. Acest tabel se creaza la implementare, odata cu PlanConturi, matricile_debit si credit si cu Functionare_cont_debit, respectiv credit. Se poate deduce din structura tabelului "Conturi_radacina" ca se pot defini si radacini cu doua nivele: un cont radacina de trei cifre la care se poate adauga a o a doua radacina formata dintr-o cifra sau doua, dupa care urmeaza inca doua cifre pentru identificarea conturilor legate de nivelul doi. De exemplu codul 401 clienti poate fi divizat pe judete sau pe tipuri de produse pe care clientii le cumpara si vom avea astfel contul 40101, 40102, 40103, s.a.m.d.

Individualizarea clientilor din fiecare categorie de mai sus, se va face atribuidu-le conturi ca 4010101, 4010102, respectiv 4010201, 4010202, s.a.m.d. Evident conturile cu 7 cifre vor fi luate in calcul rulajelor si soldurilor conturilor cu 5 cifre, adica a conturilor 40101, 40102, 40103, s.a.m.d. Conturile care apartin nivelului al doilea vor avea 7 cifre (5 ale radacinii si doua care fac distinctie intre codurile apartinand aceleiasi radacini de 5 cifre). Bineinteles ca se pot folosi si radacini cu un singur nivel, (de 3 sau 4 cifre) urmat de doua, trei sau patru cifre care fac distinctie intre codurile apartinand aceleiasi radacini. Rulajul contului 401 in cazul in care se folosesc doua nivele, presupune calculul rulajelor conturilor apartinand fiecarei radacini de nivel doi, adunarea rulajelelor conturilor care apartin aceleasi radacini de nivel doi, de exemplu a celor care apartin contului 40101 si in final, adunarea rulajelor tuturor radacinilor de nivel doi apartinand radacinii 401, adica rulajele conturilor 40101, 40102, 40103, s.a.m.d. Cuprinsul solutiei

Pentru codurile cu radacini pe doua nivele, radacina de nivel 2 poate avea una sau doua cifre, lucru ce trebuie specificat in coloana Nr_cifre_la_nivelul2.

Cand simulam o transa si facem pregatirile necesare pentru a obtine printre altele si fisele conturilor analitice, deoarece aceste fise necesita cunoasterea soldului precedent, vom face un extras din planul de conturi cu denumirea contului, soldurile din luna precedenta si cu spatiu pentru a stoca acolo si soldul actual al soldurilor analitice. Acest lucru il realizam cu interogarea 'Make_soldrad1' care creaza tabelul "soldrad1". Ulterior , in programul "solduri_noi_pentru_fise" acest tabel este multiplicat in alte doua exemplare ("soldrad2" si 'soldcont_analitic') ce vor fi folosite impreuna cu originalul, la elaborarea rapoartelor "fise_cu_1nivel" si "fise_cu_2nivele", bazate pe interogari ce le poarta numele. Deocamdata in continuarea actiunii de pregatire pentru a obtine rapoartele, respectiv fisele analitice, folosim un program ( numit separ_analitice) care preia toate inregistrarile din tabelul Evolutie_sold_cont, derivat din Adaos_jurnal si verifica daca primele trei caractere ale contului fiecarei tranzactii sunt prezente in tabelul "Conturi_radacina" . Daca da, programul genereaza numai pentru tranzactiile apartinand acestor conturi, un tabel numit 'evol_rad_cont'. In acest tabel apar doua coloane distincte: una cu contul radacina de nivel 1 si daca este cazul, a doua cu contul radacina de nivel doi precedat de radacina de nivel 1, in total 5 cifre). De exemplu pentru contul 4010102 vom avea in prima coloana 401, in a doua 40101 si in a treia va apare codul contului, adica 4010102. In acest fel articolele din tabelul 'evol_rad_cont' pot fi grupate in rapoarte, pe nivele: radacina1, radacina2 si in final pe coduri analitice, unde vor fi enumerate tranzactiile individuale ale contului analitic. S-a pregatit astfel terenul pentru elaborarea fiselor analitice, dar inainte de aceasta trebuie sa facem calculul rulajelor si a soldurilor conturilor radacina, care normal, n-ar trebui sa aiba tranzactii direct pe ele ci numai prin intermediul conturilor legate de nivelul 2 (in cazul radacinilor cu doua nivele) sau a celor legate de nivelul 1 (cand radacinile sunt concepute pe un singur nivel). Pentru calculul rulajelor pe doua nivele si respectiv pe un nivel vom folosi trei interogari : 'Rulaje pe conturi intermediare' care creaza tabelul rulaje analitice1 (pe conturi analitice si pe radacini de nivel 2) si 'Rulaje pe conturi sintetice2' care foloseste tabelul 'rulaje analitice1' pentru a crea tabelul 'rulaje analitice2' care contine rulajele radacinilor de nivel 1.

A treia interogare 'Rulaje pe conturi sintetice2' creaza direct rulajele radacinilor cu un singur nivel in tabelul 'rulaje sintetice1". Acum putem folosi aceste rulaje pentru actualizarea in planul de conturi, cu ajutorul programului Act_date_PlanConturi, a datelor privitoare la conturile sintetice care exista prin intermediul conturilor analitice. Inainte de actualizare insa, in acelasi program, vom combina cele trei tabele cu solduri ale conturilor analitice in unul singur (numit rulaje sintetice1). Pentru aceasta vom folosi interogarile 'combin_analitice2_cu_sintetice1' si 'combin_sintetice1_cu_analitice1' Dupa actualizarea datelor din articolele din Planul de Conturi ce implica conturi analitice, folosim programul Solduri_noi_pt_fise care stocheaza noile rulaje din PlanConturi in tabelul "soldrad1" si apoi il multiplica pe acesta in alte doua exemplare numite "soldrad2" si 'soldcont_analitic'. Aceste tabele vor fi folosite de interogarile "fise_cu_1nivel" si "fise_cu_2nivele", care vor fi folosite de rapoartele cu acelasi nume pentru elaborarea fiselor analitice.

Motivul pentru care ne trebuie trei tabele cu solduri vechi si noi este acela ca daca tabelul este grupat pe trei nivele (de exemplu radacina1 - rad1, radacina2 -rad2 si cont analitic), nu putem sa-i asociem fiecarui nivel soldul de care are nevoie, decat daca dispune in interogare de un tabel numai al lui. Aceasta problema merita studiata pe calculator!

Dupa elaborarea celor trei tabele cu solduri vechi si noi, putem considera ca avem tot ce ne trebuie pentru a obtine fisele analitice. Lista programelor care se ruleaza in cadrul operatiunii de simulare continua cu programele amintite mai sus cand s-a prezentat procedura de obtinere a cartii mare sah , dar si cu programele specificate mai jos unde vom prezenta procedura pentru obtinerea balantei.

Cand se termina rularea tuturor acestor programe, vom selecta meniul Rapoarte si de acolo putem selecta oricare dintre optiunile fisa Cont, carte mare sah sau bilant.

Dupa aceasta plictisitoare descriere a procedurii credem ca apare evident rolul schemelor logice de sistem. De aceea la sfarsitul acestui material vom atasa si schemele logice ale fiecarei proceduri. Remarcam totusi ca ele nu pot elimina aceasta descriere decat atunci cand programatorul este suficient de experimentat ca sa deduca din schema nu numai operatiile si secventa lor, dar si justificarea (motivarea) fiecarei faze din cadrul procedurii.            Cuprinsul solutiei

- Pentru Balanta sintetica se foloseste interogarea un program (din modulul Pregatim_Balanta) numit Pregatire_balanta care creaza tabelul Balanta_tabel. Pe acest tabel se aplica interogarea cu parametru numita Balantaa sintetica care este apoi apelata de raportul cu acelasi nume. Tabelul Balanta_tabel se creaza din meniul Prelucrari, optiunea Pregatire balanta iar in meniul Rapoarte trebuie doar sa alegem optiunea Balanta si apoi vizualizare sau tiparire. In ambele cazuri utilizatorul este solicitat sa spuna intre ce grupe de coduri se va elabora raportul. Pentru un raport complet trebuie sa specificam intervalul 10-99 (99 fiind de fapt randul de Total General.)

6. Elaborarea bilantului si a documentelor anexa la bilant

Din analiza machetelor acestor documente, se poate vedea ca datele pentru aceste documente sunt disponibile in tabelul PlanConturi, actualizat cu ultima transa din anul care s-a incheiat. Totusi dat fiind continutul complex al acestor documente ele nu pot fi obtinute cu o interogare privitoare la PlanConturi, ci va trebui sa concepem o procedura logica mai complexa. In aceasta procedura, piesa cea mai importanta este un tabel numit Structura_bilant ce va contine cate un articol pentru fiecare rand din document. Pentru actualizarea tabelului Structura_bilant acestuia i se va asocia un formular.

Macheta tabelului Structura_bilant este urmatoarea:

Unde:

- Denumire categorie se refera la categorii de activ sau de pasiv (de ex. Imobilizari necorporale);

- Continut se refera la continutul campurilor cont1, cont2, s.a.m.d. pana la cont 20, care reprezinta locul de unde luam informatiile pentru a fi prelucrate: acesta poate fi un cont cu semn, sau un rand din bilant ( a se vedea indicatiile cu privire la conturi din macheta bilantului). De ex. pentru linia I. ACTIVE IMOBILIZATE _ TOTAL se face referire la randurile 1-3 a caror continut se aduna pentru a se obtine totalul;

- Tip sold poate lua valoarea 1 daca soldul este pe debit si 2 daca este pe credit.

Din macheta bilantului se poate constata ca din tabelul Structura_bilant nu va participa in raportul numit Bilant, decat coloanele Denumire categorie si Nr_rand. Restul informatiilor sunt folosite pentru a calcula soldurile ce vor fi stocate pe fiecare rand, din coloanele Inceputul anuluisi Sfarsitul anului. Pentru calculul soldurilor se disting doua situatii: solduri ale conturilor prevazute in planul de conturi si solduri ale unor subclase de conturi (de ex .20), care nu sunt disponibile direct in planul de conturi, ci trebuie folosit un program special care sa selecteze din planul de conturi conturile care apartin unei subclase si sa le adune pentru a obtine soldul subclasei. Initial soldurile subclaselor se depoziteaza intr-un tabel numit Solduri_subclase, avand macheta de mai jos:                            Cuprinsul solutiei

Dupa calculul soldurilor subclaselor, se poate trece la calculul soldurilor pentru coloanele Precedent si Incheiat. Acestea vor fi stocate in tabelul Solduri_bilant.

Acest tabel contine campurile: Nr_rand, Sold_initial si Sold_inchiat. Pentru completarea acestui tabel se aduc solduri din Planul de conturi (in cazul conturilor) sau din tabelul Solduri_subclase (in cazul subclaseor), dupa cum in tabelul structura_bilant este specificat un cont sau o subclasa. Daca in tabelul Structura_bilant, la continut este specificat rand, atunci se cauta in tabelul Solduri_bilant, la randul specificat in acelasi tabel.. Inainte de a asambla nr_rand, denumire categorie, solduri_subclase, solduri_bilant si solduri de pe alte randuri care participa la calculul totalurilor, mai trebuie actualizata in tabelul Societatea, data la care s-a facut validarea ultimei transe pe anul incheiat. Aceasta se ia din tabelul Solduri si va apare sub titlul bilantului. Dupa aceea se va rula interogarea Asamblez_tabel_bilant care ia date din tabelele Structura_bilant , Solduri_bilant si Societatea. Ultimele doua tabele sunt legate direct de tabelul Structura_bilant prin campul Nr_rand. Interogarea va produce un tabel cu aspect foarte apropiat de cel al formatului cerut pentru bilant. Pe acest tabel se poate rula raportul Bilantul, care este folosit pentru a vizualiza si pentru a tipari bilantul. Daca este cazul, operatiunile de mai sus, pot fi precedate de actualizarea structurii bilantului si a datelor din tabelul Societatea (altele decat data validarii transei) care sunt folosite pentru antetul bilantului. Lansarea procedurii logice de mai sus se face din submeniul Prelucrari, prin optiunea Pregatire bilant, care ofera un submeniu cu optiunile Actualizare structura bilant, Actualizare antet bilant si Elaborare bilant. Ultima optiune lanseaza automat, unul dupa altul programele Actualiz_sold_subclase, Actualiz_sold_bilant, Actualiz_datei_ultimei_transe si interogarea Asamblez_tabel_bilant.

Vizualizarea sau tiparirea bilantului se poate face din submeniul Rapoarte/Bilant cu optiunile Vizualizare si Tiparire.

7.     Solutii pentru situatii speciale aparute pe timpul exploatarii aplicatiei

7.1 Implementarea aplicatiei

Implementarea presupune parcurgerea urmatorilor pasi:

actualizarea planului de conturi: programul vine cu planul de conturi complet, dar la implementare se vor sterge din el toate conturile care nu se folosesc. In acest scop se va folosi optiunea Plan Conturi/actualizare din meniul Configurare. Pentru conturile ramase, acolo se vor completa si datele initiale: sold initial, total suma, sold_precedent, etc (conform machetei tabelului Planconturi prezentata in sectiunea 2). Dupa iesirea din formularul Plan Conturi, acesta atrage dupa sine formularul Functionare_cont_debit, care la randul sau aduce in atentie formularul Functionare_cont_credit. In aceste tabele se afla toate combinatiile legale posibile intre un cont sintetic si conturile sale corespondente si in dreptul fiecarei combinatii exista un camp cu starea acelei combinatii. Starea poate fi folosit sau blocat. Pentru combinatiile pe care nu le folosim vom alege optiunea blocat.

resetarea tabelului Solduri ( prin rularea interogarii Transfer_sold);

stabilirea conturilor sintetice care se desfasoara pe nivelul doi si a conturilor care se desfasoara pe conturi analitice. Pentru fiecare cont analitic se va stabili pe cate nivele se desfasoara, cate cifre se adauga la radacina initiala pentru a se genera un nou cont analitic. In acest scop se va completa formularul Conturi_radacina (detalii despre conturi analitice se gasesc la aliniatul Fisele conturilor desfasurate pe conturi analitice din sectiunea 5, iar macheta tabelului se gaseste in sectiunea 2), comun atat pentru conturile sintetice care se desfasoara pe nivelul doi cat si pentru conturile care se desfasoara pe conturi analitice. La stabilirea acestor conturi se va tine seama de particularitatile celor doua categorii de conturi mentionate in tabelul urmator, unde rubricile Functionare cod si Tranzactii se refera la participarea codului in tabelele referitoare la functionarea conturilor si respectiv in registrul jurnal in tranzactii, iar celelalte rubrici specifica daca contul (radacina) poate fi inclus in documente de contabilitate cum ar fi fisa contului, carte mare sah si balanta.

Cuprinsul solutiei

actualizarea tabelelor Matrice_debit si Matrice_credit cu ajutorul subrutinelor

Genmat_debit si Genmat_debit din modulul Carte_sah

actualizarea tabelelor Solduri_sintetice_debit si Solduri_sintetice_credit: pentru aceasta se vor rula subrutinele Setare_sintetice_debit si Setare_sintetice_debit din modulul Sintetice ( se va prevedea o optiune de meniu pentru aceasta operatiune);

copierea fisierelor de lucru create mai sus in fisiere de referinta si in fisiere de siguranta;

7.2    Introducerea unui cont nou in timpul anului financiar.

(Stergerea unui cont nu este permisa)

Simularea transei care contine unul sau mai multe conturi noi se va desfasura in bune conditiuni numai daca vom efectua urmatoarele operatii:

se va parcurge primul aliniat de la punctul 7.1 si apoi se va deschide formularul Solduri_sintetice_debit si ulterior Solduri_sintetice_credit, unde se vor introduce manual datele despre combinatiile noului cont.

daca este vorba de un cont care se desfasoara pe nivelul doi sau unul care se desfasoara pe conturi analitice, vom parcurge aliniatul 3 de la punctul 7.1

vom copia fisierele de lucru modificate mai sus in fisiere de referinta. Cele de siguranta mai raman. Ele vor fi inlocuite automat la urmatoarea validare a transei, dar pana atunci, daca ne rasgandim in privinta noului cont vom restaura aceste fisiere.

7.3    Inchiderea anului financiar si deschiderea altuia nou

a) Inchiderea presupune urmatoarele operatii:

- validarea transei (aceasta operatiune salveaza fisierele de lucru in fisirele de referinta, blocheaza optiunea Simulare transa care va fi deblocata numai la alegerea optiunii Transa noua cand se va goli si tabelul Adaos_jurnal).

- tiparirea in prealabil a tuturor documentelor necesar a fi arhivate conform legii. In continuare se vor crea copii-arhiva ale fisierelor de referinta. Copiile-arhiva sunt fisiere cu extensia _arh;

b) Deschiderea noului exercitiu financiar presupune:

- modificarea tabelului PlanConturi cu datele ce se cer pentru inceperea exercitiului financiar ( de exemplu soldurile initiale vor lua valorile soldurilor curente din tabelul PlanConturi_ini, soldurile init vor fi adaptate valorilor soldului initial actualizat, soldurile curente raman in PlanConturi cum sunt, rulajele devin zero, sumele totale devin egale cu soldurile curente, rulajele totale se fac zero, soldurile precedente nu conteaza cu ce valoare raman pentru ca ele inainte de actualizarea soldului curent la viitoarea simulare, vor primi valoarea soldului curent);

- daca avem de introdus conturi noi, putem s-o facem acum, completandu-le toate datele initiale in concordanta cu cerintele exprimate in aliniatul precedent , dar adaugand si modificarile ce se impun in tabelele de functionare conturi.

Cuprinsul solutiei

- efectuarea operatiilor prevazute mai sus la aliniatele 2-5 de la punctul 7.1 (implementarea).

Observatie: Pentru toate cele 4 situatii speciale descrise mai sus (7.1, 7.2, 7.3a si 7.3b) se vor prevedea optiuni in meniul Configurare astfel:

pentru implementare, optiunea implementare;

pentru introducerea de cont nou, optiunea cont nou;

pentru 7.3a si 7.3b se va introduce meniul Exercitiu cu doua optiuni: inchidere si redeschidere.

Schema procedurii logice ce se ruleaza la alegerea optiunii Simulare transa:

Consola (monitor)

Simulare_efect_transaoptiune din

meniul TRANSA

Macroul Resetare_Impact

Sold_conturi Sterge_sold_conturi: intrg-delete

PlanConturi Extrag_sold: intrg-append Sold_conturi

Impact_rulaj_sold Sterge_impact: intrg-delete

Adaos_jurnal Impact_sold: subprg Sold_conturi

Macroul Resetare_efect Impact_rulaj_sold

Evolutie_sold_cont Sterge_evolutie: intrg-delete

Impact_rulaj_soldEfect_sold_cont: intrg-appendEvolutie_sold_cont

Cuprinsul solutiei

Cuprinsul solutiei

Procedura logica continua cu schema urmatoare unde blocurile hasurate pregatesc datele pentru obtinerea fiselor conturilor analitice.

Subroutine Transfer_Sold_Plan

Intrg: make table

Planconturi Make-soldrad1 Soldrad1

Subroutine

Sold_conturi Transfer_Sold_Plan Planconturi

Subroutine Separ_analitice

Macro

Intrg: delete

Evol_rad_cont Golesc_evol_rad_cont

Macro

Intrg: append

Evolutie_sold_cont Split_simbol_conturi Evol_rad_cont

Subroutine

Conturi_radacina Separ_analitice Evol_rad_cont

Evol_rad_cont               Intrg: select

Rulaje pe conturi analitice

Conturi_radacina

Intrg: make table

Rulaje pe conturi intermediare Rulaje analitice1

Intrg: make table

Rulaje analitice1                  Rulaje pe conturi sintetice2 Rulaje analitice2

Evol_rad_cont               Intrg: select

Rulaje pe conturi analitice1

Conturi_radacina

Intrg: make table

Rulaje pe conturi sintetice1 Rulaje sintetice1

1

Cuprinsul solutiei

1

Subroutine Act_date_planconturi

Intrg: append

Rulaje analitice2                  Combin_analitice2_cu_sintetice1 Rulaje sintetice1

Intrg: append

Rulaje analitice1                  Combin_ sintetice1_cu_ analitice1 Rulaje sintetice1

Subroutine Planconturi

Rulaje sintetice1 Act_date_planconturi Sold_conturi

Subroutine Solduri_noi_pt_fise

Subroutine

Planconturi Solduri_noi_pt_fise Soldrad1

Soldrad1 Docmd.CopyObject Soldrad2

Soldrad1 Docmd.CopyObject Soldcont_analitic

Subroutine Creare_rulaj_total

Solduri Querydef: QdefTemp Extras_din_solduri

Subroutine

PlanConturi Creare_rulaj_total Extras_din_solduri

Macro

Extras_din_Sold Transfer_sinteza_transei Solduri

Macro

Adaos_jurnal Append_adaos Registru_jurnal

Macro

Evolutie_sold_cont Adaug_misc_fisa Fisa_cont

Cuprinsul solutiei

2

2

Subroutine Rulaj_coresp_debit

Macro

Matrice_rulaj_debit Golesc_ rulaj_debit

Macro

Extras_sintetice_debit Golesc_ extras_sintetice_debit

Solduri_sintetice_debit Querydef: QdefTemp Extras_sintetice_debit

Matrice_debit

Rulaj_coresp_debit Matrice_rulaj_debit

(cu rulaje curente)

Adaos_jurnal

Matrice_debit                    Extras_sintetice_debit

Rulaj_coresp_debit

Matrice_rulaj_debit Matrice_rulaj_debit (cu rulaje curente) (cu rulaje totale)

Apeleaza Subroutine Rulaj_coresp_credit

subroutine

Combin_sintetice

Subroutine Rulaj_coresp_credit

Macro

Matrice_rulaj_credit Golesc_ rulaj_credit

Macro Cuprinsul solutiei

Extras_sintetice_credit Golesc_ extras_sintetice_credit

Solduri_sintetice_credit Querydef: QdefTemp Extras_sintetice_credit

Matrice_credit

Rulaj_coresp_credit Matrice_rulaj_credit

(cu rulaje curente)

Adaos_jurnal

Balanta1 (compressed)

Matrice_credit Extras_sintetice_credit

Rulaj_coresp_credit

Matrice_rulaj_credit Matrice_rulaj_credit (cu rulaje curente) (cu rulaje totale)

Macro

Extras_sintetice_debit Adaug_extras_sintetice_debitSold_sintetice_debit

Macro

Extras_sintetice_credit Adaug_extras_sintetice_credit Sold_sintetice_credit

subroutine

Matrice_debit

Adaos_jurnal

subroutine

Matrice_credit

Adaos_jurnal

Schema procedurii logice utilizate pentru a elabora bilantul

Structura bilant Formular actualizare

Societatea Formular actualizare

Subprg

Planconturi Actualiz_sold_subclase Solduri_subclase

Planconturi                Subprg

Solduri_subclase Actualiz_sold_bilant Solduri_bilant

Structura_bilant

Subprg

Solduri Actualiz_datei_ultimei_transe Societatea

Structura_bilant    Intrg: make-table

Solduri_bilant Asamblez_tabel_bilant Tabelul_bilant

Societatea

Raport

Tabelul_bilant Bilantul Bilantul

Cuprinsul solutiei