Sunteți pe pagina 1din 81

Ramona VASILESCU

SISTEME INFORMATICE DE CONTABILITATE

ISBN 978-973-687-710-0

UNIVERSITATEA TIBISCUS TIMIOARA


Facultatea de tiine Economice

Lect. drd. Ramona VASILESCU

SISTEME INFORMATICE DE CONTABILITATE


Note de curs pentru uzul studenilor de la FR

Editura Eurostampa TIMIOARA 2008

CUPRINS
Cuprins ...........................................................................................................5 Tema 1. Sistemul informatic instrument al contabilitii............................7 1.1 Date, informaii, sistem informaional..................................................7 1.2 Locul i rolul sistemului informatic de contabilitate ..........................11 1.3 Componentele sistemului informatic de contabilitate ........................13 Tema 2. Caracteristicile programelor de contabilitate.................................18 2.1 Caracteristici de calitate......................................................................18 2.2 Constrngeri .......................................................................................23 Tema 3. Realizarea sistemelor informatice de contabilitate ........................27 3.1. Metodologii de realizare a sistemelor informatice de contabilitate...27 3.2 Metoda Unified Modeling Language. Prezentare ..............................31 Tema 4. Modelarea sistemului informatic de contabilitate..........................37 4.1 Specificaii generale ale metodei Unified Modeling Language .........37 4.2 Diagrame utilizate de UML................................................................42 Tema 5. Analiza sistemului informatic de contabilitate existent.................52 5.1 Obiectivele analizei ............................................................................52 5.2 Elaborarea modelului fizic al sistemului existent...............................54 5.3 Elaborarea modelului logic al sistemului existent..............................63 5.4 Alegerea unui nou sistem informatic de contabilitate ........................65 Tema 6. Securitatea i controlul sistemelor informaticE de contabilitate ...72 6.1 Securitatea i valoarea informaiei .....................................................72 6.2 Surse de riscuri ...................................................................................75 6.3 Auditul sistemelor informatice de contabilitate..................................79

TEMA 1. SISTEMUL INFORMATIC INSTRUMENT AL CONTABILITII


CONINUT 1.1. Date, informaii, sistem informaional 1.2. Locul i rolul sistemului informatic de contabilitate 1.3. Componentele sistemului informatic de contabilitate REZUMAT Orice analiz economic a unei uniti economice are la baz informaia, privit ca o resurs, i modul n care aceasta este vehiculat. Culegerea, stocarea, prelucrarea, analiza i transmiterea informaiilor sunt activiti care trebuie s foloseasc eficient i eficace resursele informaionale i umane cu scopul obinerii succesului economic. n aceste condiii contabilitatea necesit existena unui sistem informatic de contabilitate performant, care s respecte anumite cerine organizaionale i legislative. OBIECTIVE Tema propus are ca scop: definirea sistemelor informatice de contabilitate; stabilirea locului i rolului unui sistem informatic ntr-o unitate economice.

1.1 DATE, INFORMAII, SISTEM INFORMAIONAL Legturile dintre diversele pri ale unei entiti economice trebuie s satisfac cerine de calitate i promptitudine care pot proveni fie din interiorul entitii economice (cum ar fi cele provenite de la nivelele ierarhice superioare) fie din exteriorul entitii economice (de exemplu de la clientul care vrea s tie starea n care se afl execuia unei comenzi lansate n producie). Orice analiz economic a unei entiti economice are la baz informaia i modul n care aceasta este vehiculat, astfel nct degradarea ei s fie minim i fr pierderi de semnificaie. Definiiile informaiei sunt numeroase i presupun cunoaterea semnificaiei noiunilor prin care este definit i, de multe ori, a contextului pentru care a fost definit. Astfel se vorbete despre informaie ca despre comunicare, veste, tire care pune pe cineva la curent cu o situaie1, informaie genetic, informaie contabil .a.m.d. Din punct de vedere economic, informaia este privit ca o resurs care poate mbunti raportul cost-eficien. Bine neles c era informaticii n care trim, aflat la debutul ei, i-a pus deja puternic amprenta asupra modului n care acest raport poate fi modificat, raport care
DEX. Dicionarul explicativ al limbii romne, Editura Univers Enciclopedic, Bucureti, 1998 7
1

este influenat continuu i de nivelul de dezvoltare a tehnologiei hardware i software de la un moment dat. Obinerea informaiilor i prelucrarea lor se face prin intermediul unor sisteme informaionale. De obicei, oamenii presupun existena unui calculator cnd aud pentru prima dat sintagma sistem informaional. Totui, un sistem informaional nu este neaprat un sistem computerizat i n fiecare zi vedem exemple de astfel de sisteme informaionale. De exemplu, suntei beneficiarul unui sistem informaional atunci cnd dorii s cltorii cu autobuzul i pentru aceasta cumprai un bilet. Atunci cnd prezentai biletul unui controlor, biletul reprezent suportul informaiei pe care controlorul o interpreteaz prin aceea c ai cumprat dreptul de a cltori cu acel mijloc de transport. Un sistem informaional este parte a unui sistem complet. Un sistem este o entitate compus din pri organizate i care interacioneaz pentru o funcionare ct mai eficient. Subsistemele sunt pri componente ale sistemului. De exemplu, Facultatea de tiine Economice este un subsistem al sistemului Universitatea Tibiscus. Un sistem informaional se compune dintr-o mulime de subsisteme intercorelate care lucreaz mpreun pentru colectarea, prelucrarea, stocarea, transformarea i distribuirea informaiei pentru planificare, luarea deciziilor i control. Fiecare sistem informaional se poate descompune n trei componente principale: intrrile, prelucrrile i rezultatele. Intrarea ntr-un sistem informatic poate fi format din date sau din informaii. Datele sunt fapte brute, neprelucrate despre evenimente care nu au semnificaie n sistem i nu sunt organizate. Datele pot fi totui organizate ntr-o manier n care pot fi utile sau pot primi semnificaie pentru sistem. Cnd datele se organizeaz astfel nct s aib semnificaie pentru sistem ele devin informaie. Rafinarea datelor i informaiilor de-a lungul timpului formeaz un ansamblu numit cunotine. Sistemele informaionale prelucreaz datele i/sau informaiile (sortare, organizare, calcule specifice) obinnd informaii care sunt structurate n funcie de cerinele utilizatorilor informaiei. Aceste cerine pornesc n general de la scopurile pentru care este folosit informaia, de exemplu persoanele de la nivelele de conducere folosesc informaia pentru planificare, luare de decizii i controlul activitilor organizaionale (decizia cumprrii unui echipament necesit informaii despre alternative, costul alternativelor i cerinele referitoare la echipamentul necesar pentru o entitate economic). Informaiile i cunotinele sunt folosite des n activiti de controlul. Contabilii pregtesc bugetele (aceasta este o funcie de planificare) astfel nct managerii s poat compara performanele actuale cu cele planificate i s poat controla activitile lor pentru a prentmpina schimbrile nedorite. Figura 1.1 reflect modul n care datele, informaiile i cunotinele (care compun aa numita piramid informaional) colaboreaz ntr-un proces permanent, n care datele pot fi folosite pentru a obine informaii i cunotine, iar cunotinele, la rndul lor, pot fi folosite pentru a obine informaii i date. Precizm c figura nu prezint subordonarea celor trei concepte ci vrea s sugereze un raport cantitativ dintre acestea. Fluxurile informaionale reprezint totalitatea informaiilor care se vehiculeaz ntre emitorul de informaie i receptor. Sistemul informaional comunic cu mediul su extern prin fluxuri informaionale (de

exemplu rapoartele pentru acionari), iar n interiorul su, subsistemele comunic ntre ele prin alte fluxuri informaionale.

Cunotine

Informaii

Date

Figura 1.1 Piramida informaional

Sistemele informaionale se studiaz n cadrul domeniului n care funcioneaz, pentru a se evidenia particularitile specifice, astfel se vorbete de sistemul informaional de conducere, sistemul informaional de marketing, sistemul informaional geografic1 etc. Contabilitatea este n sine un sistem informaional. Este un proces care colecteaz, stocheaz, prelucreaz i distribuie informaii celor care au nevoie de ele. De exemplu, contabilii unei entiti economice culeg date despre propria organizaie, le prelucreaz, obin rezultate pe care le distribuie sub form de informaii financiare, sau alte tipuri de rapoarte. Una dintre cele mai cuprinztoare definiii ale sistemului informaional contabil este cea dat de autorii Gheorghe, Mirela, Roca, I. Ioan n cartea Auditul informaiei contabile n condiiile utilizrii sistemelor informatice (pagina 21): Sistemul informaional contabil este format dintr-un ansamblu de elemente interdependente, orientat spre culegerea, stocarea, prelucrarea, analiza i transmiterea informaiilor privind starea i micarea patrimoniului. Conceptul de tehnologie a informaiei se refer la totalitatea componentelor software i hardware folosite n sistemele informaionale computerizate. Tehnologia informaiei a modificat modul n care se lucreaz n orice domeniu. n urm cu civa ani, nimeni nu i putea imagina c oamenii vor putea face cumprturile de la un magazin virtual localizat undeva i accesat prin intermediul Internetului. Comerul electronic este numai un exemplu din multele moduri n care tehnologia informaiei influeneaz viaa de zi cu zi dar i cea a afacerilor. Moscove2 remarc faptul c tehnologia informaiei a avut acelai impact asupra societii ca i revoluia industrial. n era informaiei, civa muncitori produc i un segment larg de populaie angajat este implicat n producia, analiza i distribuia informaiei, astfel c sistemele informatice au ajuns s joace un rol vital att n economie ct i n viaa fiecruia. Tehnologia informaiei afecteaz orice tip de contabilitate (financiar, de gestiune, managerial). Un sistem informatic de contabilitate este un tip special de sistem, care furnizeaz informaii despre procesele afacerilor i evenimentele care intervin n funcionarea unei uniti economice.
www.acad.ro/pro_pri/doc/st_b08.doc Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. Core Concepts of Accounting Information Systems
2 1

Dac la nceputurile tehnologiei informaiei, dependena de sistemele informatice nu se fcea simit, n ziua de azi nici mcar nu se mai poate imagina ca afacerile s nu foloseasc sisteme informatice. De la calculatoare se ateapt s ndeplineasc funciuni ca: planificarea unei linii de producie, pstrarea evidenei dintr-un depozit, verificarea datelor unui conductor auto etc. Sistemele informatice se folosesc nu numai de ctre unitile economice mari care manipuleaz foarte multe date ci i de ctre cele mici. Chiar i n ara noastr putem ntlni patroni de microntreprinderi care in o eviden contabil folosind un calculator acas. Atunci cnd este folosit tehnologia informaiei, de obicei ne referim la acest aspect ca fiind informatic. Definiia din DEX pentru informatic este tiin aplicat care studiaz prelucrarea informaiilor cu ajutorul sistemelor automate de calcul. n cartea Bazele computerelor. Hard & soft 1, autorii au definit sistemul informatic drept un sistem informaional care are ca element de culegere, stocare, transmitere i transformare un calculator electronic. Dac vom considera c sistemul informatic este acea parte a sistemului informaional prin care se execut prelucrri automate cu ajutorul sistemelor de calcul, devine evident c sistemul informatic este parte a sistemului informaional. innd cont de faptul c prelucrarea datelor n contabilitate se face preponderent automat, prin intermediul programelor specializate, vom considera c sistemele informatice de contabilitate acoper toate ariile unui sistem informaional de contabilitate. Sistemele informatice de contabilitate pot furniza o multitudine de tipuri de date i informaii: date financiare, date non-financiare, analize rezultate din managementul datelor, informaii de cutare sau anticipare, informaii despre management, despre acionari, etc. Sistemele contabile computerizate estompeaz demarcrile dintre sistemele contabilitii financiare i ale contabilitii manageriale. Multe programe software contabile actuale pot prelua ambele tipuri de date (financiare i non-financiare) i s le organizeze ntr-o manier prin care au semnificaie att pentru utilizatorii interni ct i pentru cei externi. Tehnologia informaiei de azi poate face posibil obinerea unor rezultate care necesit operaii complexe si periodice la intervale scurte de timp (cum ar fi actualizarea la fiecare minut vnzrilor de produse i raportarea acestor vnzri). Aceste rezultate se pot furniza aproape instantaneu prin fax, email, sau pe Internet, pe o pagin special sau pe propriul site. Posibilitatea tehnologiei informaiei de a produce rapid mari cantiti de informaie poate crea o problem cunoscut ca suprancrcarea informaiei ([MOS03]). Prea mult informaie i, n mod special, prea mult informaie banal, poate coplei utilizatorii informaiei, iar informaia relevant pentru luarea deciziilor se poate pierde. Contabilii sunt cei care decid natura i sincronizarea informaiei creat i distribuit printr-un sistem informaional contabil. Influena tehnologiei informaiei asupra raportrilor financiare primare se face simit n furnizarea informaiei financiarcontabile. Internetul poate aduce modificri n modul de furnizare a coninutul rapoartelor financiare, sau a disponibilitii informaiei referite n expunerile financiare de baz.
1

Lupulescu, M. coordonator, Dnia, Doina, Muntean, Mihaela Bazele computerelor. Hard & soft, pagina 23 10

1.2 LOCUL I ROLUL SISTEMULUI INFORMATIC DE CONTABILITATE Existena sistemelor informatice moderne, de mare vitez, a devenit posibil dup ce calculatoarele s-au rspndit n lumea afacerilor. Istoric, existena sistemelor informatice contabile a nceput cu informatizarea facturrii i a unor operaii contabile aferente. n cadrul oricrei uniti economice culegerea datelor, prelucrarea lor i obinerea rezultatelor se fac conform unor proceduri organizatorice reglementate fie prin lege (de exemplu componena i structura planului de conturi) fie prin regulamente de ordine intern (de exemplu, stabilirea persoanei i a timpului lansrii unei operaiuni de arhivare a datelor). n figura 1.2 intrrile se constituie din date sau informaii (care se preiau din documentele justificative), care sunt procesate obinndu-se informaii pentru planificare, luarea deciziilor i control. Documentele contabile se clasific n funcie de rolul lor i de modul de ntocmire ([TEA00], pagina 97) n: documente justificative (de eviden primar), registrele contabile (eviden contabil) i situaiile financiare (documente de sintez i raportare). nregistrarea n contabilitate se poate face pentru fiecare document, sau din documentele centralizatoare care cuprind date de aceeai natur dintr-o perioad oarecare. Intrri
Date/informaii din surse interne i/sau externe

Prelucrri
Sortare, organizare, calcul

Rezultate
Date/informaii pentru decideni interni i/sau externi

Figura 1.2 Fazele distincte ale funcionrii unui sistem Sursa: [MOS03] pagina 6

Rezultatul prelucrrilor contabile se poate folosi de ctre nivelele de conducere n cadrul unor procese decizionale, cu observaia c o aceeai informaie poate fi perceput cu valori diferite pentru persoane diferite. Aceia care sunt specializai n contabilitate dau importan mai mare rapoartelor financiare mai mult dect cei care nu au o asemenea pregtire1. Informaiile contabile trebuie s ndeplineasc urmtoarele caracteristici2: inteligibilitatea (informaiile pot fi uor de neles i de interpretat); relevana (sublinierea aspectelor care pot influena luarea deciziilor); credibilitatea (informaiile nu conin erori semnificative, nu sunt tendenioase, nici prtinitoare); comparabilitatea (informaiile s poat fi comparate prin elemente comune i de aceeai semnificaie). Existena erorilor poate crea incertitudine i luarea unor decizii greite. Figura 1.3 reflect o parte a unui sistem informaional a unei entiti economice i scoate n eviden faptul c sistemul informaional de contabilitate este subsistem al sistemului informaional al entitii
Hawker, A. Security and Control in Information Systems: A Guide for Business and accounting, Routledge 2000, pagina 14 2 Teaciuc, M. .a. Bazele contabilitii, Eurostampa 2000, paginile 7-8 11
1

economice. Sistemul informaional de contabilitate acumuleaz informaii de la subsisteme diferite. Pentru ca interaciunea dintre subsisteme s fie efectiv, este necesar c fiecare subsistem s neleag tipurile de informaii generate de subsistemele cu care interacioneaz.

Furnizori

Aprovizionare

Personal

Gestionarea comenzilor i contractelor de aprovizionare Baze de date sau fiier(e) de furnizori i clieni

Magazii, gestiune stocuri

Producie

Contabilitate

Magazie produse finite Cheltuieli materiale Studii de pia Calcul cost-pre

Comenzi, contracte de desfacere

Figura 1.3 Subsisteme informaionale organizate n funcie de activitile din cadrul unei uniti economice Sursa: Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare pagina 21

Un sistem informatic de contabilitate tradiional se ocup n principal de colectarea, prelucrarea i obinerea rezultatelor financiare care se vor transmite ctre externi (cum ar fi investitorii, creditorii i Ministerul Finanelor) i ctre interni (n general structurile de conducere). Un sistem informatic de contabilitate modern se ocup att de informaiile nonfinanciare ct i cu date i informaii financiare. Tradiional, fiecare parte a unei entiti economice (Personal, Producie) menin un subsistem informatic separat i fiecare subsistem i prelucreaz propriile date. Aceast mod de lucru are dezavantajul apariiei unor probleme cum ar fi duplicarea datelor pe spaii de stocare distincte, culegerea separat a unor aceleai date. Astzi entitile economice consider c este necesar integrarea funciilor lor ntr-o baz mare de date, sau ntr-un depozit de date. Aceast integrare permite managerilor i, cu oarecare extensii, prilor externe s obin informaiile necesare pentru planificare, luarea deciziilor i control, fie c informaiile sunt pentru marketing, contabilitate, sau alte arii financiare ale entitii economice1. Productorii de produse software au dezvoltat programe care leag toate subsistemele informatice ntr-o singur aplicaie. Produsele software pentru contabilitate vor fi discutate ulterior. Rolul sistemului informatic de contabilitate este de a furniza informaii importante referitoare la: venituri, urmrirea clienilor (facturi emise nencasate), dinamica ncasrilor i plilor, contabilitatea costului
Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. Core Concepts of Accounting Information Systems 12
1

(calculaia costului), cheltuieli, etc. Informaiile furnizate pot mbrca forme diverse att electronic (documente electronice, foi de prezentare electronice, notificri electronice (e-mail), imagini, imagini video, secvene audio, etc.), fie sub form tradiional (pe suport de hrtie sau folii pentru proiectoare, etc.). Furnizarea informaiilor trebuie s se fac n timp util, ct mai exact, pentru toi destinatarii informaiei contabile (manageri, personal aparintor altor subsisteme). Un sistem informatic de contabilitate modern este capabil s preia automat datele furnizate de ctre alte subsisteme.

1.3 COMPONENTELE SISTEMULUI INFORMATIC DE CONTABILITATE Operaiile contabile care se realizeaz prin intermediul sistemelor informatice de contabilitate trebuie s ajute la rezolvarea unor probleme specifice ca evidena contabil a operaiilor pe conturi i calcularea balanelor contabile. Aceasta se face prin preluarea datelor din documentele de intrare i stocarea lor, prelucrarea datelor i obinerea rezultatelor (vezi figura 1.4). Preluarea datelor se poate face manual (cnd un operator uman parcurge fiecare document justificativ, operndu-l) i/sau automat (cnd exist echipamente periferice de intrare conectate la sistemul informatic). Stocarea datelor presupune existena unui sistem de gestiune a fiierelor i/sau un sistem de gestiune a bazelor de date. Obinerea unui sistem informatic se face urmnd cteva etape: analiz, proiectare i implementare, urmrindu-se activitile din cadrul sistemului informaional aferent i toate fluxurile informaionale care apar, de interes fiind cele care pot fi automatizate prin intermediul calculatoarelor (vezi figura 1.4 care prezint un exemplu cu activitile unui sistem informatic). Subsisteme emitoare/primitoare
Bonuri de consum, facturi, NIR, chitane, fie de amortizare etc.

Planul contabil
Operaii contabile

Documente justificative

nchideri i alte prelucrri periodice

Note contabile

Balane, rapoarte (cas, banc), bilan, jurnale de TVA, etc.

Jurnale Figura 1.4 Activitile unui sistem informatic

Registrul jurnal

Se impun cteva observaii referitoare la figura 1.4:


13

1. operaiile contabile cu documentele de intrare justificative nseamn contarea documentelor: de la subsistemul Producie: bonuri de consum, rapoarte de producie; de la Aprovizionare: facturi de intrare, NIR (note de intrare-recepie), de la Vnzri: facturi emise; de la Casa, Banca: chitane, foi de vrsmnt, ordine de plat; foaie de depunere; etc.; 2. operaiile contabile periodice: nchideri lunare i/sau anuale. Documentele care se pot obine pe baza operaiilor contabile au ca destinatari: nivelului de conducere (decizional), nivelului de control intern i audit. Componentele unui sistem informatic de contabilitate trebuie s rspund cerinelor de funcionare descrise pn acum i trebuie s fie intercorelate funcional: a. hardware; b. software; c. comunicaie; d. baza tiinific i metodologic (metodele, procedeele i mijloacele de prelucrare a datelor); e. baza informaional, fluxurile informaionale i suporturile de informaii; f. utilizatorii; g. cadrul organizatoric. Componenta hardware se constituie din totalitatea mijloacelor tehnice de culegere, stocare, transmitere i prelucrare automat a datelor. Acestea pot include calculatoare, scannere, case de marcat, dispozitivele de comunicare, dispozitivele de interconectare. Componenta software se constituie din totalitatea programelor i aplicaiilor care realizeaz funcionarea sistemului informatic. Din aceast categorie fac parte sistemele de operare utilizate, aplicaiile software de comunicaie n reea, programele de prelucrare n scopul obinerii unor informaii contabile, programele de editare de texte i de creare a rapoartelor, etc. Componenta de comunicaie se constituie din toate echipamentele i tehnologiile utilizate pentru comunicaia datelor ntre prile componente ale sistemului informatic. Baza tiinific i metodologic se compune din modelele matematice ale proceselor de contabilitate, din metodologiile, metodele i tehnicile de realizare a sistemelor informatice1. Baza informaional se constituie din totalitatea fluxurilor informaionale i ale datelor de prelucrat. Unii autori (Lungu I.) includ aici sistemele i nomenclatoarele de coduri. Cum codificarea i utilizarea codurilor este a ajuns un mecanism foarte utilizat chiar i n viaa de zi cu zi (de exemplu utilizarea codului CNP) considerm c acestea sunt de drept o
1

Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare, pagina 23 14

parte important a fluxului informaional, avnd n vedere urmtoarele: un produs i/sau serviciu se codific, de cele mai multe ori, printr-un mecanism intern al unitii economice; codurile folosite pot fi fcute vizibile (prin liste de selecie, prin afiare lng pre .a), iar cu timpul codurile pot memorate de ctre utilizatori i folosite cu uurin ntr-o manir direct. Utilizatorii sunt componenta format din totalitatea persoanelor angajate n funcionarea sistemului informatic. Se disting dou categorii mari de utilizatori: operatorii (de exemplu, cei de la casele de marcat) i informaticienii (cum ar fi analitii, inginerii de sistem, programatorii). Cadrul organizatoric este dat de regulamentul de ordine interioar i de actele legislative n vigoare, cum ar fi: legea nr. 82/1991 denumit Legea contabilitii; planul de conturi; codul privind Conduita Etica si Profesional a experilor contabili i contabililor autorizai din Romnia; legea nr. 15/1994 privind amortizarea capitalului imobilizat n active corporale i necorporale; ordinul nr. 1826/2003 pentru aprobarea precizrilor privind unele msuri referitoare la organizarea i conducerea contabilitii de gestiune; ordinul nr. 1040/2004 pentru aprobarea Normelor metodologice privind organizarea i conducerea evidenei contabile n partid simpl de ctre persoanele fizice care au calitatea de contribuabil; ordinul nr. 1753/2004 pentru aprobarea Normelor privind organizarea i efectuarea inventarierii elementelor de activ i de pasiv; ordinul nr. 1752/2005 pentru aprobarea reglementrilor contabile conforme cu directivele europene. n Anexa la Ordinul nr. 58/23 ianuarie 2003 se precizeaz: n condiiile utilizrii sistemelor informatice financiar-contabile este necesar sa fie respectate Criteriile minimale privind programele informatice utilizate n domeniul financiar-contabil, prevzute de Ordinul ministrului finanelor nr. 425/1998, cu modificrile ulterioare i Contribuabilii pot edita formularele cu regim special cu ajutorul tehnicii de calcul, n condiiile prevzute la art. 2 din Ordinul ministrului finanelor nr. 1.177/1998 privind aplicarea prevederilor art. 1 alin. (4) i (10) paragraful 2 din Hotrrea Guvernului nr. 831/1997. n general, sistemele informatice de contabilitate sunt organizate astfel nct s corespund arhitecturii contabilitii din Romnia n care se remarc trei mari componente ([TEA00]): 1. contabilitatea general (aprovizionare i furnizori; vnzri i clieni; cheltuieli; venituri; datoriilor; creanelor; stocuri i obiecte de inventar; mijloace fixe; capital; salarii; operaii diverse, de nchidere); 2. contabilitatea financiar / de gestiune financiar: trezoreria, investiiile financiare, finanrile ncasri de la clieni, pli ctre
15

furnizori, evidenierea plasamentelor, plata impozitelor i taxelor etc.; 3. controlul prin bugete elaborarea de bugete i urmrirea acestora prin intermediul contabilitii generale. Din aspectele descrise pn acum putem trage concluzia c majoritatea aciunilor desfurate n cadrul unei entiti economice necesit utilizarea sistemului informatic de contabilitate. BIBLIOGRAFIE 1. [HAW00] Hawker, A. Security and Control in Information Systems: A Guide for Business and accounting, Routledge 2000 2. [LUN03] Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti, 2003 3. [LUP99] Lupulescu, M. coordonator, Dnia, Doina, Muntean, Mihaela Bazele computerelor. Hard & soft, Editura Mirton, Timioara 1999 4. [MOS03] Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. Core Concepts of Accounting Information Systems, John Wiley & Sons Ltd, 2003 5. [TEA00] Teaciuc, M. .a. Bazele contabilitii, Editura Eurostampa, Timioara 2000 6. ***, http://www.cdep.ro, seciunea Repertoriul legislativ

16

TESTE DE EVALUARE 1. Definii sistemul informaional: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 2. Componentele unui sistem informatic de contabilitate sunt urmtoarele: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 3. Cadrul organizatoric este dat de: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 4. Folosind Monitorul Oficial sau alte surse de informare (de exemple revistele, site-urile i portalurile specializate n furnizarea de informaii de contabilitate i colaborare ntre contabili1) ncercai s gsii reglementri legislative aplicabile sistemelor informatice de contabilitate, altele dect cele enumerate n cadrul subcapitolului 1.3. _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 5. Caracteristicile pe care trebuie s le ndeplineasc informaiile sunt: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________

de exemplu: Revista ContaPlus, Revista Contabilitate i informatic de gestiune, http://contacafe.ro, http://www.contabilul.ro, http://www.e-contabilitate.ro 17

TEMA 2. CARACTERISTICILE PROGRAMELOR DE CONTABILITATE


CONINUT 2.1. Caracteristici de calitate 2.2. Constrngeri REZUMAT Msura n care un produs software de contabilitate ndeplinete cerinele utilizatorilor depinde direct de totalitatea nsuirilor sale pe care acesta le-a dobndit n procesul de producie. Din acest motiv, cunoaterea i determinarea lor este un aspect important al realizrii i utilizrii programelor de contabilitate. OBIECTIVE Tema propus are ca scop nelegerea cerinelor de calitate pentru produsele software de contabilitate i ale particularitilor acestora care provin din constrngerile impuse.

2.1 CARACTERISTICI DE CALITATE Informatizarea unitilor economice a nsemnat crearea unor programe specializate care au trebuit s respecte constrngerile impuse de legislaie. Diferenele dintre programe apar la nivelul interfeelor, documentrii, asistenei tehnice i al altor servicii. Programele trebuie s respecte anumite principii cum ar fi1: prevenirea defectelor; asigurarea faptului c defectele au fost detectate i corectate ct mai curnd posibil; stabilitatea i eliminarea cauzelor care produc anumite simptome; audit i conformitate cu standarde i proceduri. Preul programelor de contabilitate difer n funcie anumite criterii cum ar fi: productorul, numrul de calculatoare folosite, tehnologia utilizat .a. Cele mai ieftine sunt cele care au preul de achiziie zero lei (Saga C, ContaSQL) iar preul celor mai scumpe se ridic la cteva mii de lei (Ciel, EasyCont). La preul de achiziie trebuie adugat preul instruirii, asistenei tehnice i al abonamentului pentru actualizrile n funcie de modificrile legislative. Entitile economice pot opta pentru achiziionarea unui program de contabilitate prin dou metode: selectarea unei productor de produse software i crearea unui program de contabilitate special, n funcie de nevoile unitii economice; selectarea unui program de contabilitate existent.

Mihalca, Rodica, Fabian, C. Realizarea produselor program aplicative, Editura ASE, Bucureti 2003, pagina 4-2 18

Fiecare dintre aceste metode prezint avantaje i dezavantaje dar produsul software achiziionat trebuie s rspund unor cerine de calitate. Calitatea produselor software de contabilitatea Msura n care un produs software de contabilitate ndeplinete cerinele utilizatorilor depinde direct de totalitatea nsuirilor sale pe care acesta le-a dobndit n procesul de producie. Cunoaterea i determinarea lor este dificil din cauza numrului mare i divers al acestor nsuiri. De aceea, n practic, se iau n considerare acele nsuiri, pe care le vom numi caracteristici de calitate, care exprim direct sau influeneaz ntr-un fel sau altul utilizarea produsului. Calitatea produselor software de contabilitate reprezint totalitatea nsuirilor tehnice, economice i sociale1 i gradul n care ansamblul nsuirilor satisfac: nevoia utilizatorilor finali ai produselor, gradul de utilitate i eficiena economic n exploatare. Gradul de utilitate al produselor software de contabilitate are n vedere: calitatea proiectrii, realizrii i execuiei; calitatea de conformitate (dintre cerinele utilizatorilor i nsuirile actuale ale produselor software); capacitatea de utilizare n rezolvarea problemelor pentru care a fost dezvoltat i capacitatea de mentenan (msura n care disfuncionalitile pot fi reparate). Caracteristicile de calitate ale produselor software de contabilitate sunt: ergonomia, fiabilitatea, mentenabilitatea, corectitudinea, eficacitatea, stabilitatea, adaptabilitatea, portabilitatea, sigurana n utilizare i claritatea. Ergonomia este nsuirea care exprim relaia direct dintre om i produs prin urmtoarele caracteristici: uurina exploatrii produsului - aceasta se reflect n produsele software de contabilitate la interfeele care trebuie s fie prietenoase, cu un design plcut ochiului uman, fr elemente suplimentare care s ncarce inutil suprafaa de lucru afiat pe ecran; securitatea exploatrii produsului programele de contabilitate trebuie s fie prevzute cu elemente de siguran cum ar fi: protejarea fiierelor de lucru, imposibilitatea crerii unui cont de dou ori, imposibilitatea utilizrii unui cont nedeclarat, imposibilitatea modificrii datelor dintr-o perioad nchis etc. optimizarea solicitrilor fizice i psihice aplicaiile de contabilitate trebuie s prevad mecanisme ct mai simple de lucru: alegerea din liste ale denumirilor lungi, completarea automat a informaiilor despre un ter, completarea unor date implicite (cum ar fi data curent, cota de TVA) etc.; consumul de timp pentru obinerea rezultatului acest consum trebuie s fie ct mai mic pentru oricare dintre operaii. Fiabilitatea reprezint capacitatea unui produs de a funciona fr defeciuni n condiii de lucru bine stabilite. Exprimarea fiabilitii folosete
1

Mihalca, Rodica, Fabian, C. Realizarea produselor program aplicative, Editura ASE, Bucureti 2003, pagina 9-1 19

noiunea de defeciune care nseamn, n fapt, ieirea din funciune i const n pierderea total sau parial, instantanee sau progresiv a capacitii de funcionare a produsului. Funcionarea fr defeciuni const n meninerea capacitii de funcionare a produsului. Astfel dac se asigur alimentarea continu cu electricitate, un sistem de operare liber de virui, o reea stabil (dac este necesar) programele contabile nu au voie s i ntrerup execuia sau s lucreze imprecis. Fiabilitatea a dobndit o importan foarte mare odat cu dezvoltarea tehnologiei i a creterii complexitii produselor de contabilitate. Mentenabilitatea reprezint capacitatea ca un produs s poat fi ntreinut i reparat ntr-o anumit perioad de timp. Ca orice produs i programele de contabilitate pot prezenta defeciuni care se manifest n diverse moduri, att funcional ct i la nivelul interfeei (o list ataat unui buton nu se mai deschide, calcularea perioadelor de timp nu respect anul bisect, ignorarea cifrelor zecimale etc.). Cum aplicaiile software sunt produse de folosin ndelungat i de importan mare n cadrul unei uniti economice, ele trebuie s fie: - uor de meninut n stare de bun funcionare utilizatorii trebuie s cunoasc toate acele condiii suficiente pentru ca aceast stare s se menin; - uor de ntreinut dac programul este modular, utilizatorii trebuie s poate aduga cu uurin prile componente care repar produsul fr ca aceste componente noi s impieteze asupra datelor existente; dac programul nu este modular, productorul trebuie s prevad mecanisme simple cu ajutorul crora utilizatorii s poat nlocui versiunea defect cu versiunea nou; - uor de reparat este una dintre cerinele de baz a utilizatorilor, fcnd o analogie cu legile lui Murphy, putem spune c orice component se defecteaz tocmai cnd este cea mai mare nevoie de acea component. Productorii trebuie s ofere modaliti simple de contactare din partea utilizatorilor (telefon, e-mail, mesagerie instantanee) i aib capacitatea de a rezolva orice defeciune ntr-un interval de timp ct mai scurt. Putem trage concluzia c mentenabilitatea unui produs software de contabilitate depinde de urmtoarele caracteristici: - accesibilitatea lui uurina cu care productorii pot accesa orice modul constituent al sistemului informatic; - existena modulelor i/sau versiunilor necesare reparaiei; - activitatea de asisten tehnic i ntreinere (service) att n perioada de garanie, ct pe toat durata de utilizare a produsului. Corectitudinea reprezint capacitatea unui produs software de contabilitate de a prelucra datele i informaiile i de obine rezultate corecte cantitativ i calitativ, respectnd fluxurile transformrilor specificate n documentaia ce st la baza formulrii cerinelor utilizatorilor. Un program de contabilitate nu este corect dac, de exemplu, lucreaz intern cu aproximri zecimale de o cifr cunoscut fiind faptul c sunt permise aproximri de cel puin dou cifre.
20

Eficacitatea reprezint capacitatea produselor software de contabilitate de a utiliza resursele disponibile ct mai optim orict de complex este problema supus rezolvrii. Un program de contabilitate care, astzi, are prevzute mecanisme de arhivare numai pe suporturi de memorie de tip dischet, nu este un program eficient pentru c nu utilizeaz i alte echipamente periferice disponibile (memoriile de tip flash). Sigurana n utilizare reprezint capacitatea unui program de contabilitate de a nu permite nici modificarea datelor i nici distrugerea parial sau total prin acces neautorizat. Un program de contabilitate care permite tergerea unui cont sintetic pentru care exist nregistrri, nu este un program care ofer siguran n utilizare. De asemenea, nici dac permite ca o persoan cu cunotine minime de baze de date s poat efectua comenzi de tergere masiv a datelor din baz. Atragem atenia c distrugerea datelor din cauze pur hardware (distrugerea hard-disk-ului pe care sunt stocate datele) este o caracteristic de calitate a ntregului sistem informatic de contabilitate. Adaptabilitatea reprezint capacitatea programelor de contabilitate de a permite integrarea unor funcii i/sau componente noi care s mreasc performanele de prelucrare dup ce acestea au fost date n funciune. Dac un program de contabilitate extrage o list a produselor vndute n ultimele dou luni, ordonate doar dup dat, n cinci secunde, un exemplu de adaptabilitate este adugarea unei funcii noi de extragere, n doar trei secunde, a acelorai produse ordonate dup criterii compuse (cum ar fi: data calendaristic, client i nume). Portabilitatea reprezint capacitatea produselor software de contabilitate de a fi funcionale pe mai multe tipuri de calculatoare i/sau sisteme de operare. n practic, atingerea acestei caracteristici se face prin eforturi considerabile de programare i, din acest motiv, referirea la avantajele portabilitii poate apare n orice descriere a programelor de contabilitate. De exemplu, dintre avantajele soluiei GITS se scoate n eviden c sistemul este conceput 100% n Java, conferind portabilitate pe orice platform i sistem de operare. Aplicaia ruleaz pe sistemele de operare Windows 98/ME/2000/XP i Linux avnd suport pentru baze de date ORACLE, Microsoft SQL Server i MySQL1. Stabilitatea programelor de contabilitate poate fi exprimat: din punct de vedere prelucrrilor reprezint rezistena programului la modificarea datelor iniiale sau n secvenele ce compun modulele sale; aceast caracteristic trebuie urmrit att n timpul procesului de realizare a programelor/modulelor de contabilitate n cadrul testrilor ct i dup punerea n funciune prin auditul sistemului informatic de contabilitate; din punct de vedere software/hardware reprezint capacitatea produsului software de contabilitate de a pstra integritatea datelor atunci cnd apare o ntrerupere a disponibilitii sistemului. De exemplu, ntreruperea brusc a alimentrii cu
1

http://www.attosoft.ro 21

electricitate nu trebuie s determine apariia unor note contabile incomplete. Claritatea exprim msura n care produsul software de contabilitate este compus numai din instruciuni necesare prelucrrilor contabile. Tendina de a crea programe de contabilitate neclare este apanajul productorilor fr experiena punerii n funciune a programelor la mai muli utilizatori. Claritatea produselor software se poate exprima din dou puncte de vedere: al programatorilor i al utilizatorlor finali. Pentru utilizatorul final, un program de contabilitate este neclar dac interfaa este ncrcat (explicaii inutile, reclame referitoare la echipa de programare, legturi cu zone care nu sunt de interes, culori terse sau prea puternice, texte trunchiate, etc.). Alte caracteristici ale produselor software de contabilitate Integrabilitatea programelor de contabilitate este o caracteristic urmrit n contextul actual n care se face simit nevoia utilizatorilor de a utiliza sistemele informatice existente ntr-un mod unitar. Integrabilitatea reprezint capacitatea produselor software de a fi incluse n sisteme complexe de prelucrare a datelor ([MIH03], pagina 9-6). n cadrul sistemului informaional contabil putem delimita trei domenii de activitate si anume: contabilitatea general este acea parte care se ocup de intrri (de la teri, n gestiune), ieiri (spre teri, din gestiune), ncasripli, operaii diverse (salarii, nchideri periodice etc.); contabilitatea de gestiune este partea care se ocup de teri, gestiunea stocurilor, gestiunea lichiditilor, inventare, bugete etc.; analiza financiar analiza pe bata bilanului contabil. Un sistem informatic de contabilitate poate fi folosit pentru toate cele trei domenii sau numai pentru contabilitatea general. Flexibilitatea este o caracteristic important a unui sistem informatic de contabilitate pentru c, n domeniu contabil, schimbrile sunt permanente, se pot produce fr avertismente prealabile (conform unei politici guvernamentale cu care contabilii nc nu s-au obinuit dar n faa creia s-au resemnat). Cerinele de adaptare rapid a dus la clasificarea sistemelor informatice de contabilitate n dou categorii: aplicaii dedicate i aplicaii nededicate. Aplicaiile dedicate sunt acele aplicaii care rezolv punctual o problem specific. Dezavantajul acestor aplicaii este flexibilitatea sczut din cauz c este nevoie de intervenia productorului n cazul n care intervine vreo modificare referitoare la problema aferent programului. Acest mod de lucru este specific productorilor de produse software la nceputurile existenei loc, programul de contabilitate iniial cunoate o dezvoltare care l poate duce la o soluie general. Alte aplicaii dedicate sunt cele care rezolv problemele unei anume categorii de probleme; cum ar fi contabilitatea instituiilor publice. Aceste tipuri de aplicaii pot avea o flexibilitate medie provenind din chiar specificul acestui tip de contabilitate.
22

Aplicaiile nededicate reprezint un cadru general de rezolvare a unui tip de problem contabil, cu flexibilitate mare, orice modificare aprut fie prin reglementri noi legislative fie interne ale unitii economice se poate rezolva uor chiar de ctre utilizator (de exemplu modificarea sensului unui cont). Aplicaiile informatice de contabilitate, prin adaptarea n permanen la cerinele pieei, au cunoscut o dinamic pronunat care s-a datorat att dezvoltrii tehnologice ale componentelor hardware (de exemplu capacitate de stocare, vitez de acces) ct i inovaiilor software (cum ar fi interfeele grafice).

2.2 CONSTRNGERI Programele de contabilitate trebuie create respectnd anumite constrngeri care provin din constrngerile legislative (structura planului de conturi, nceputul i sfritul exerciiului contabil) i constrngerile unitilor economice (numrul de calculatoare folosite, numrul de societi pentru care se face contabilitatea etc.). Constrngerile administrative provin din resursele necesare pentru utilizarea programelor de contabilitate. Acestea includ: sistemul de operare, necesarul minim de spaiu de memorie extern, necesarul minim pentru capacitatea memoriei interne, diferenele dintre calculatorul server i cele utilizator. Toate aceste aspecte se au n vedere n funcie de dimensiunea unitii economice. Astfel o societate comercial cu un numr redus de angajai i poate propune utilizarea unui singur calculator cu un sistem de operare mai puin performant (cum ar fi Windows 95), cu un hard-disk de capacitate de 400MB. O unitate economic mare s-ar putea s aib nevoie de o reea de calculatoare cu un server dedicat stocrii datelor, de capacitate mare, la nivelul zecilor de gigabyte, cu programe care s asigure securitatea n reea i protejarea datelor n cazul unor incidente. Constrngerile de utilizare a calculatoarelor. Programele de contabilitate se achiziioneaz monopost (pentru un singur calculator) sau multipost (pentru mai multe calculatoare, atunci cnd lucreaz mai muli contabili la o unitate economic). Pentru programele de contabilitate multipost se folosesc dou arhitecturi1: partajat i arhitectur client-server. n cazul arhitecturii partajate, programul de contabilitate i fiierele se gsesc pe un singur calculator (de obicei acesta poart numele generic server), iar contabilii le acceseaz de la calculatoare conectate n reea. n cazul arhitecturii client-server, programul de contabilitate este instalat pe fiecare dintre calculatoarele din reea iar fiierele sunt stocate pe calculatorul numit server.

Boksenbaum, L. Informatic de gestiune, pagina 229 23

Constrngeri prin numrul de societi. Contabilitatea se poate ine pentru una sau mai multe uniti economice. n acest caz productorii programelor de contabilitate adopt dou moduri de lucru: se permite deschiderea unui numr mare (de ordinul sutelor) fr nicio intervenie a productorului i/sau fr plat suplimentar; acest mod de lucru este preferat de unitile economice specializate n furnizarea servicilor de eviden contabil; se permite deschiderea unei noi societi contra cost prin intervenia unui angajat al productorului; acest mod de lucru poate s fie preferat de ctre organizaiile care administreaz una sau mai multe uniti economice. Constrngeri de identificare se folosesc atunci cnd un utilizator acceseaz programul de contabilitate sau anumite zone protejate ale acestuia (cum ar fi raportrile profiturilor i/sau pierderilor) prin utilizarea unui nume de utilizator i a unei parole. Parolele pot fi generice caz n care controlul accesului este slab sau personalizate caz n care controlul este puternic i permite urmrirea activitii unui utilizator n interiorul sistemului informatic. Constrngerile planului de conturi provin din reglementrile legislative care prevd ca un cont s poat fi creat o singur dat, s nu poat fi ters (dac a fost folosit cel puin o dat ntr-o operaie). n mod obinuit programul de contabilitate este instalat cu un plan contabil predefinit i cu posibilitatea gestionrii acestuia. Adugarea unor conturi noi trebuie s permit stabilirea parametrilor de lucru specifici cum ar fi: codificarea (generic i/sau sintetic; numai numeric, de exemplu 5311, sau i n combinaie cu alte caractere, de exemplu 5121.1, 5121.TRA), sensul contului (credit, debit), taxa TVA etc. Constrngerile de nchiderea exerciiului se refer la urmtoarele aspecte: - nchiderea unui exerciiu trebuie s se fac la nceputul anului care l succede iar soldurile finale ale exerciiului nchis devin soldurile iniiale ale exerciiului nou; - atunci cnd un exerciiu contabil este nchis nu trebuie s se poat efectua modificri; - s existe posibilitatea deschiderii unui exerciiu nchis. Constrngerile introducerii datelor se refer la modul n care se prelucreaz intrrile fie prin jurnale fie prin nscrisuri contabile. Jurnalele se folosesc pentru pstrarea tuturor operaiunilor fie pe categorii de operaiuni (jurnal de vnzri, jurnal de intrri), fie de cont (corelat direct cu un cont cum ar fi cel de cas sau cel de banc). Un nscris contabil1 se identific prin: data calendaristic, numrul de cont, suma, sensul (debit sau credit) i o explicaie. nscrisurile contabile se folosesc cu scopul de a simplifica introducerea operaiunilor curente fie printr-un abonament de nscrisuri (pentru operaiunile care se efectueaz
Boksenbaum, L. Informatic de gestiune, Editura Economic, Bucureti 2002, pagina 230 24
1

periodic cu o aceeai sum) fie prin completarea automat a datelor pentru un cont (cum ar fi contul sintetic al unui ter). Acest mod de lucru necesit o atenie special atunci cnd se stabilesc conturile cu prelucrri automate. Dac nu se cunoate bine semnificaia conturile i funcionarea lor, se pot stabili parametri eronai cur urmri nedorite n balanele contabile. Constrngerile operaiilor periodice sunt urmarea faptului c anumite operaii trebuie s se desfoare periodic (obligaiile fiscale, nchiderea de lun, nchiderea exerciiului etc.). De multe ori, o msur de siguran pentru a preveni modificrile unei perioade despre care s-a constatat c e valid, se procedeaz la blocarea perioadei adic nu se mai permite modificarea datelor din perioada respectiv. Constrngerile personalizate apar ca urmare a formulrii cererilor speciale ale unei uniti economice i pot fi: modul n care se face imprimarea a unui logo, utilizarea de coduri de bare pentru marcarea documentelor eliberate, comunicarea unor situaii n alt mod sau la alte perioade dect cele predefinite, importarea unor date rezultate n urma unor prelucrri externe sistemului informatic de contabilitate i/sau chiar externe unitii economice, etc. Toate constrngerile descrise mai sus au ca punct central informaia contabil. Importana informaiei contabile este bine cunoscut i, la fel de bine, este cunoscut faptul c reprezint peste 40% din informaia existent / utilizat ntr-o unitate economic. Lipsa informaiei contabile sau inexactitatea ei poate determina un dezechilibru informaional care s influeneze negativ funcionarea unitii economice. BIBLIOGRAFIE 1. [BOK02] Boksenbaum, L. Informatic de gestiune, Editura Economic, Bucureti 2002 2. [MIH03] Mihalca, Rodica, Fabian, C. Realizarea produselor program aplicative, Editura ASE, Bucureti 2003

25

TESTE DE EVALUARE 1. Enumerai constrngerile pentru programele de contabilitate: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 2. Pentru un sistem informatic de contabilitate, planul de conturi: a) reprezint este o constrngere a unui sistem informatic de contabilitate; b) nu este nsoit de constrngeri; c) este o component nchis care nu permite modificri. Care dintre enunurile a), b) i c) este adevrat. Justificai. _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 3. Controlul accesului se asigur prin: a) constrngerile personalizate; b) constrngerile de identificare; c) constrngerile administrative. 4. Enumerai domeniile unui sistem informaional de contabilitate: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 5. Cerinele de calitate ale unui produs sunt: _____________________________________________________________ _____________________________________________________________ 6. Mentenabilitatea este: _____________________________________________________________ _____________________________________________________________ 7. Ergonomia este: _____________________________________________________________ ____________________________________________________________

26

TEMA 3. REALIZAREA SISTEMELOR INFORMATICE DE CONTABILITATE


CONINUT 3.1. Metodologii de realizare a sistemelor informatice de contabilitate 3.3. Metoda Unified Modeling Language. Prezentare REZUMAT Realizarea sistemelor informatice se desfoar n trei etape mari: analiz, proiectare i implementare. Metodologiile de realizare pot fi de ajutor n proiectarea i implementarea sistemelor informatice. OBIECTIVE Tema propus are ca scop nelegerea modului n care se pot realiza sistemele informatice de contabilitate.

3.1. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE DE CONTABILITATE Sistemele informatice, la fel ca oricare alt produs, au o existen limitat nlocuirea total sau parial fiind necesar din timp n timp. Ciclul de via al sistemului informatic este definit de intervalul de timp CV = [T1, T2] unde T1 reprezint momentul n care s-a decis elaborarea sistemului iar T2 reprezint abandonarea sistemului. Acest interval este abordat metodic n etape ca analiza, modelarea, dezvoltarea, testarea, utilizarea, mentenana pn la retragerea sistemului. Din punctul de vedere al utilizatorului final cele mai importante etape sunt utilizarea i mentenana. Ciclu de realizare este dat de intervalul CR=[T1,T2], unde T1 reprezint momentul lurii deciziei de realizare iar T2 momentul punerii n funciune. Acest interval este cel mai important din punctul de vedere al realizatorilor. Realizarea sistemelor informatice se desfoar n etape pe baza unor modele i strategii de implementare. ntre etapele de realizare a sistemelor informatice exist o legtur direct i indestructibil, calitatea unei etape fiind premisa calitii unei etape succesoare. Metodologiile aplicate trebuie s cuprind toate aspectele referitoare la realizarea unui sistem informatic: etapele/procesele de realizare a unui sistem informatic structurate n subetape, activiti, sarcini i coninutul lor; fluxul realizrii acestor etape/procese, subetape i activiti; modalitatea de derulare a ciclului de via a sistemului informatic; modul de abordare a sistemelor;
27

strategiile de lucru/metodele de realizare; regulile de formalizare a componentelor sistemului informatic; tehnicile, procedurile, instrumentele, normele i standardele utilizate; modalitile de conducere a proiectului (planificare, programare, urmrire) i modul de utilizare a resurselor financiare, umane i materiale etc.1

Cum fiecare teorie dezvoltat folosete proprii termeni, n condiiile n care se dorete alegerea celei mai potrivite metodologii de realizare, novicii pot ntmpina greuti n studiul tuturor metodologiilor. Clasificarea metodologiilor de realizare a sistemelor informatice de contabilitate Multitudinea de metodologii se clasific dup criterii diverse cum ar fi: gradul de generalitate, modul de abordare a sistemelor, modelul ciclului de via ([LUN03]). Clasificarea metodologiilor de realizare a sistemelor informatice dup gradul de generalitate: 1. metodologii generale cu grad nalt de generalitate (SSDAM Structured System Analysis and Design Methodology, OMT Object Modeling Technique); 2. metodologii dedicate care se aplic fie numai unor categorii de produse software fie numai unui singur produs software. Clasificarea metodologiilor de realizare a sistemelor informatice dup modul de abordare a sistemelor: 1. metodologii cu abordare structurat sistemul se poate mpri n subsisteme fie din punct de vedere funcional fie pe baza gruprii logice a datelor (STRADIS Structured Analysis and Design Information Systems, YSM Yourdon Systems Methods); 2. metodologii cu abordare orientat obiect folosesc conceptele tehnologiei orientat obiect (UML Unified Modeling Language, OOD Object Oriented Design, OOA Object Oriented Analysis, OOSD Object Oriented Structured Design) Clasificarea metodologiilor de realizare a sistemelor informatice dup modelul ciclului de via: 1. metodologii cu model n cascad etapele se parcurg succesiv, la terminarea unei etape se poate reveni la o etap anterioar (vezi figura 3.1);

Lungu, I., Sabu, G., Velicanu, M. Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti 2003, pagina 81 28

Definirea cerinelor

Analiza Proiectarea Implementarea Testarea Utilizarea i mentenaa

Figura 3.1. Etapele modelului n cascad Sursa: Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare pagina 87

2. metodologii care folosesc modelul prototipului se elaboreaz o prim versiune simplificat cu funcionare minim care este urmat de versiuni succesive mbuntite pn se atinge funcionarea complet conform cerinelor beneficiarului (vezi figura 3.2);

Prototip n

... Prototip 2

Prototip 1

Figura 3.2. Modelul prototipului Sursa: Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare pagina 87

3. metodologii incrementale se folosesc cnd sistemele informatice se pot pune n funciune modular prin realizarea subsistemelor. Etapele acestor metodologii sunt cele ale modelului n cascad cu deosebirea c proiectarea, implementarea, testarea i utilizarea i ntreinerea se realizeaz separat, pentru fiecare subsistem n parte;
29

4. metodologii evolutive se folosesc n cazul realizrii sistemelor complexe; se face o descompunere n subsisteme de complexitate redus i pentru fiecare subsistem se realizeaz un sistem informatic. n finalul procesului toate subsistemele informatice se asambleaz. Clasificarea metodologiilor de proiectare a sistemelor informatice pe baza metodelor folosite ([ORZ05, pagina 170): metodologii bazate pe metode de proiectare pe msur sau la comand sistemele informaional se analizeaz pas cu pas, cu reveniri la paii anteriori, abordarea problemelor fcndu-se de la general spre detaliat; metodologii bazate pe metode de proiectare n serie nti se realizeaz sistemul informatic pentru o unitate economic pilot; acest sistem se extinde n funcie de prin adaptare i integrare n funcie de specificul i/sau domeniului unitii economice; metodologii bazate pe metode de proiectare automat sistemul se realizeaz prin instrumente software de asistare cu ajutorul calculatorului; Un aspect comun pentru toate metodologiile descrise este acela c trecerea de la o etap la alta se face numai dup o analiz a activitilor, i, pentru fiecare activitate, se stabilesc regulile, standardele de calitate i instrumentele i tehnicilor utilizate. Modelul n cascad Fiecare etap a modelului n cascad (vezi figura 3.1) are un scop bine stabilit i se bazeaz pe rezultatele etapei precedente ([MIH03]): - definirea cerinelor aceast etap are ca scop faptul c trebuie s identifice cerinele de realizare; - analiza aceast etap are ca scop descrierea cerinele de funcionare ntr-un document; - proiectarea are ca scop stabilirea arhitecturii sistemului informatic i se face n dou sub-etape: proiectarea de ansamblu (se rafineaz cerinele de funcionare i restriciile de funcionare, se stabilete arhitectura produsului software etc.) i proiectarea de detaliu (se specific algoritmii, modulele, interfeele, fluxurile de date, fluxurile de control etc.); - implementarea aceast etap are ca scop realizarea produsului software care poate fi compus din module, componente speciale, programe utilitare etc.; - testarea - fiecare element constituent ct i ntregul sistem informatic de contabilitate trebuie testat; testarea este o activitate important care trebuie s se desfoare nainte de punerea n funciune la utilizatorul final; - utilizarea i mentenana este etapa n care sistemul informatic este instalat la utilizatorul final i pus n funciune; de obicei, aceasta se face modular mpreun cu testarea fiecrei componente la locul de munc. Testarea se face att la nivel funcional ct i la nivelul interfeelor utilizatorul final poate avea obiecii referitoare la designul formularele de introducere a datelor, la listele afiate, la
30

rapoartele generate. n cadrul fiecrei etape se elaboreaz documentaia etapei care se constituie ca un rezultat al etapei. Dintre aceste documente amintim: Proiectul de ansamblu, Proiectul de detaliu, Specificaia de testare (precizeaz planul de testate, mediul de test, cazurile i procedurile de testare), Raportul de testare, Manualul de utilizare etc.

3.2 METODA UNIFIED MODELING LANGUAGE. PREZENTARE Modelarea este activitatea prin care se descrie un sistem prin intermediul unui ansamblu e notaii specifice. UML (acronim pentru Unified Modeling Language) este un limbaj de modelare care dispune de un sistem de notaii, de principii i procedee care pot folosi n procesul de abstractizare i, foarte important n dezvoltarea sistemelor informatice, dispune de mecanisme prin care s poat fi extins pentru a putea fi folosit n cazul unor sisteme informaionale speciale. UML este un limbaj de modelare care a fost standardizat de ctre grupul OMG1 pe baza unor metode de modelare existente n momentul standardizrii (OML Open Modeling Language, metoda Booch, OMT Open Method Technique, OOSE Object Oriented Software Engineering). Concepte utilizate Cteva dintre aceste metode se folosesc n reprezentri de: obiecte (object), clasa de obiecte (pe scurt clas), abstractizare, ncapsulare, motenire i polimorfism. Obiectul poate fi considerat un model abstract al oricrei entiti fizice sau ne-fizice. Un obiect se caracterizeaz prin: identitate, stare i comportament. Identitatea este unic i se poate cuantifica printr-un identificator unic (numeric i/sau text) prin care obiectele se difereniaz ntre ele. Factura numr 2254/22.09.2007 i Factura numr 2264/22.09.2007 sunt dou obiecte distincte care se identific n mod unic n anul 2007 prin numr 2254 respectiv 2264. Pe o perioad de mai muli ani, facturile se identific n mod unic prin ansamblul format din numrul facturii i din data calendaristic 2254/22.09.2007 respectiv 2264/22.09.2007. Unui obiect i se ataeaz un set de proprieti (atribute) care conin informaii despre acesta. De exemplu Beneficiar este o proprietate a unei facturi care poate lua valori ca SC Urania SRL, SA Pdurea de Aram, SC AmiciiContab SRL etc. Valoarea total este o alt proprietate a unei facturi care poate lua valori numerice. Starea unui obiect este reprezentat de toate valorile interne ale proprietilor. n momentul n care se modific starea unui obiect, identificatorul acestuia nu se modific. De exemplu, fie factura 2254 care
1

Object Management Group 31

are Valoarea total de 2345,56 lei pentru 3 produse, dac Valoarea total se modific la 3443,76 lei pentru N+1 produse, numrul de factur rmne nemodificat. Comportamentul este dat de mulimea operaiilor care se efectueaz de ctre obiect atunci cnd se acioneaz asupra lui; clienii obiectului (alte obiecte care l utilizeaz) emit cerine ctre obiect iar obiectul rspunde prin setul de operaii care i este ataat; de exemplu, obiectul factura 2254 are ataat operaia CalculeazTVA care este folosit n operaia de contare a TVA. Mulimea operaiilor se compune din metode care din punct de vedere programatic pot fi funcii i/sau proceduri. Clasa de obiecte, pe scurt clasa, grupeaz obiectele cu aceeai structur (adic aceleai proprieti) i acelai comportament. Clasa Facturi grupeaz toate obiectele factur care se identific n mod unic printr-un numr, au aceleai proprieti (beneficiar, valoare total etc.). Desigur, la o analiz mai atent, descoperim c putem folosi dou clase FacturiIntrare i FacturiEmise. ntr-un sistem informaional, clasa se identific n mod unic printr-un nume pentru care se recomand s se foloseasc un grupaj de unu sau mai multe cuvinte/prescurtri care s aib legtur direct cu obiectele din lumea real pe care le modeleaz. Pentru o analiz serioas, ar fi de-a dreptul ciudat ca pentru facturile emise s se modeleze clasa PiticiPlai sau HrtiiBicolore. Cum o clas este o abstraciune, care descrie toate caracteristicile comune ale unui grup de obiecte, clasa nu reprezint un obiect. Un obiect se obine dintr-o clas prin instaniere. Putem spune c o instan reprezint un obiect al clasei care se distinge de alte instane ale clasei prin valorile diferite ale atributelor/proprietilor. Abstractizarea este un proces pe care omul l folosete, contient sau nu, n permanen pentru a extrage ceea ce este esenial din lumea nconjurtoare. Fiind un proces subiectiv, care se face diferit de ctre oameni diferii (prin vrst, cultur, nivel de educaie), abstractizarea devine cel mai sensibil proces care se utilizeaz n informatic pentru modelarea sistemelor tocmai pentru c experiena i puterea personal de abstractizare a fiecruia dintre cei implicai n modelare sunt detalii care pot provoca succesul sau insuccesul unui sistem informatic de contabilitate. Cu toate c n viaa de zi cu zi fiecare se descurc n abstractizarea lumii reale, a explica unui neavizat ce este esenial n contabilitate (ce este un cont, cum funcioneaz, cum se face contarea unui document justificativ) poate deveni o munc pe care puini sunt dispui s o fac. Succesul unei echipe mixte format din contabili i inforrmaticieni vine i din modul n care fiecare poate nelege abstractizrile fcute de cellalt. Aceasta impune gsirea unui limbaj comun n care un obiect (cont, chitan, balan) s ajung s aib o aceeai semnificaie att pentru contabil ct i pentru informatician. ncapsularea este un proces prin care se ascund detaliile de implementare a comportamentului astfel nct interfaa (adic partea public a clasei) oferit de clasa de obiecte s fie clar, n concordan cu elementele obinute n urma abstractizrii. ncapsularea este proprie programatorilor i se poate considera c este bine fcut atunci cnd diagramele de clase stabilite pentru sistemul informatic nu sufer modificri profunde.
32

Motenirea se manifest ntr-o ierarhie de clase. n acest caz, ierarhia nu trebuie neleas ca o subordonare. Motenirea din cadrul claselor de obiecte se refer la modul n care clasele de obiecte i partajeaz proprietile i comportamentul. Exemplul clasic este cel al mamiferelor. Mamifere este clasa care are proprietile cu valorile: membre:4; tip_snge: cald i comportamentul dat de: NatePuiVii. O clas aflat pe un nivel inferior i care motenete clasa Mamifere este Canide care motenete proprietile i comportamentul clasei Mamifere dar care are suplimentar proprietatea CuloareBlan iar comportamentul se mbogete cu metoda Latr. n lumea contabilitii o clas poate fi Document care are proprietile Numr i Data iar o clas care motenete clasa Document poate fi clasa Chitane care are suplimentar proprietile Client i Suma. Despre clasele care motenesc se mai spune c sunt clase derivate iar despre clasele motenite se spune c sunt superclase sau clase prini. Conceptul de motenire este important n procesul de abstractizare pentru c permite ca prile comune (care se suprapun) s fie tratate n manier identic o singur dat n clasa printe dar fiind valabile n toate clasele derivate, prile care disting clasa derivat de clasa printe se trateaz doar n clasa derivat fr ca s fie influenat clasa printe.
MijlocTransport An fabricaie Capacitate motor Model

Autobuz NumrLocuri Etajare

Autoturism NumrLocuri NumarUi Tonaj

Camion

Figura 3.3 Reprezentarea relaiei de motenire dintre superclasa MijlocTransport i clasele derivate Autobuz, Autoturism, Camion

Polimorfismul reprezint capacitatea unei metode de a fi funcional n clase de obiecte distincte. De exemplu, pentru superclasa Documente se poate defini metoda Procesare care va fi definit n fiecare dintre clase n mod diferit. Alte concepte utilizate ([DAV03]): aciunea operaiile instantanee, nentrerupte, asociate evenimentelor; activitatea operaiile care dureaz n timp, ntreruptibile; agregarea obiectele sunt reprezentate de componente n cadrul unui obiect privit ca ntreg; asocierea un ansamblu de legturi; se identific prin nume unic i poate avea ataat o multiplicitate care exprim numrul de asocieri n contextul dat; relaia/legtura/asocierea dintre obiecte o conexiune logic/fizic dintre obiectele aparinnd unei clase;
33

mesajul cerere adresat unuia sau mai multor obiecte prin care se pot solicita date sau se modific starea obiectului (obiectelor); starea obiectului se definete prin valorile proprietilor unui obiect la un moment dat; starea se modific prin aciunea unor stimuli externi obiectului (evenimente); tranziia trecerea obiectelor de la o stare la alta prin utilizarea unor mesaje specifice. Etapele UML Utilizarea UML presupune parcurgerea urmtoarelor etape ([LUN03]): - definirea problemei se stabilesc caracteristicile principale i modul de funcionare a activitii de implementat; - structurarea soluiei se determin i se detaliaz cerinele utilizatorului final; - analiza sistemului se analizeaz cazurile de utilizare i se extrag conceptele cele mai importante cu care lucreaz sistemul; - construirea soluiei se realizeaz o analiz detaliat a modelului pentru a se obine o variant care s fie uor de translatat n cod scris ntr-unul sau mai multe limbaje de programare; - proiectarea sistemului care presupune proiectarea de ansamblu (se definesc subsistemele i relaiile dintre acestea) i proiectarea de detaliu (se detaliaz subsistemele i se rafineaz descrierea relaiilor dintre acestea); - implementarea sistemului se efectueaz programarea i se construiete diagrama componentelor software rezultate. Structurarea soluiei este etapa care trebuie s elaboreze modelul comunicrii dintre echipa de analiz informatic i echipa care reprezint utilizatorii finali (echipa care are cunotine despre funcionarea sistemului informaional contabil). Comunicarea dintre aceste dou echipe este foarte important pentru c noiunile folosite se deosebesc funcional; astfel echipa informaticienilor pot nelege prin tabel un obiect al unei baze de date care are ataat o structur de cmpuri cu atribute limitate din punct de vedere funcional; un membru al echipei utilizatorilor poate nelege tabel fie ca un document de ntrare care conine un registru scris de mn al ncasrilor dintr-o zi, fie un rezultatul unei sortri a denumirilor terilor. Documentele elaborate n cadrul acestei etape cuprind diagramele cazurilor de utilizare. Analiza sistemului este etapa n care se studiaz diagramele cazurilor de utilizare (create n cadrul etapei precedente) i se extrag elementele cu care lucreaz sistemul. Pentru a se evidenia relaiile dintre elemente, atributele i comportamentul lor, se construiesc urmtoarele diagrame: diagramele claselor; diagramele obiectelor; diagramele de stare i/sau diagramele de activitate; diagramele de secven; diagramele de colaborare. Cteva dintre aceste diagrame vor fi studiate ntr-un capitol viitor. Construirea soluiei este etapa n care se ncearc obinerea unui model mbogit care s fie mai uor de translatat ntr-un limbaj de
34

programare. Intervenia programatorilor poate determina crearea unor clase noi, relaii, diagrame noi care trebuie s reflecte gestionarea datelor (de exemplu n prezena unei baze de date), comunicare cu exteriorul sistemului (de exemplu pentru comunicarea prin e-mail etc.). Proiectarea de ansamblu definete arhitectura sistemului (prin subsistemele i interaciunile dintre ele) i, pentru fiecare subsistem, se descriu printr-o proiectare de detaliu clasele, se rafineaz comportamentele prin adugarea i/sau modificarea metodelor claselor obinute n etapele anteriore. Implementarea sistemului reprezint etapa de programare propriuzis. n aceast etap se folosesc diagramele create anterior i diagramele componentelor software, se scrie codul surs i se obin componentele software. BIBLIOGRAFIE 1. [DAV03] Davidescu, N. D. Proiectarea sistemelor informatice prin limbajul Unified Modeling Language, Editua All Beck, Bucureti 2003 2. [LUN03] Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti, 2003 3. [MIH03] Mihalca, Rodica, Fabian, C. Realizarea produselor program aplicative, Editura ASE, Bucureti 2003 *** 1. http://www.sparxsystems.com.au TESTE DE EVALUARE 1. Ciclul de realizare a sistemului informatic definit de: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ ____________________________________________________________ 2. Ciclul de via a sistemului informatic definit de: a) intervalul de timp CV = [T1, T2] unde T1 reprezint momentul n care s-a decis cumprarea sistemului iar T2 reprezint abandonarea sistemului; b) intervalul de timp CV = [T1, T2] unde T1 reprezint momentul n care s-a decis elaborarea sistemului iar T2 reprezint abandonarea sistemului;

35

c) intervalul de timp CV = [T1, T2] unde T1 reprezint momentul n care s-a decis documentarea sistemului iar T2 reprezint casarea sistemului. 3. Etapele realizrii sistemelor informatice prin intermediul Unified Modeling Language sunt: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 4. Completai schema de mai jos astfel nct s reprezinte un model incremental de realizare a sistemelor informatice:
Definirea cerinelor

Analiza Proiectarea subsistemului 1 Proiectarea subsistemului 2

...

Implementarea subsistemului 1

...

Testarea subsistemului 1

...

Utilizarea i ntreinerea subsistemului 1

...

Utilizarea i ntreinerea subsistemului n

5. Etapele modelului n cascad sunt: _____________________________________________________________ _____________________________________________________________ ____________________________________________________________ 6. Clasa grupeaz: a) obiecte cu acelai nume i numr de identificare; b) obiecte cu aceeai structur i stri diferite; c) obiecte cu aceeai structur i acelai comportament.

36

TEMA 4. MODELAREA SISTEMULUI INFORMATIC DE CONTABILITATE


CONINUT 4.1. Specificaii generale ale metodei Unified Modeling Language 4.2. Diagrame utilizate de UML REZUMAT Unified Modeling Language (UML) este potrivit pentru modelarea sistemelor informatice de contabilitate datorit unor caracteristici cum ar fi: folosete abstractizri prin care structurile complexe contabile devin accesibile pentru analitii informaticieni i designeri nespecialiti n contabilitate; utilizeaz modelarea vizual i permite dezvoltarea unei ierarhii de modele, vederi i diagrame. OBIECTIVE Tema propus are ca scop nelegerea primar limbajului UML i a modului n care se poate folosi n modelarea pentru realizarea sistemele informatice de contabilitate.

4.1 SPECIFICAII GENERALE ALE METODEI UNIFIED MODELING LANGUAGE Analiza i proiectarea sunt dou etape importante ale ciclului de via al unui sistem informatic de contabilitate. Scrierea programelor fr efectuarea acestor etape nseamn o decizie care, de cele mai multe ori, se dovedete a fi o decizie greit cu repercusiuni n etapele de implementare, testare i mentenan (ntreinere) timpul ctigat aparent prin ignorarea analizei i proiectrii se rzbun prin detectarea erorilor logice de ctre utilizatorul final, prin nerespectarea cerinelor de calitate i de funcionare contabil. Obinerea unui model se face printr-un proces de modelare prin care se definesc cerinele individuale ale sistemului informatic de contabilitate. Definirea acestor cerine poate lua forma unor modele de date, modele funcionale, de proces sau organizaionale, fiecare nsoit de o documentaie. Rolul jucat de un model pentru realizarea unui sistem informatic este similar rolului jucat de un proiect de cas ntocmit nainte de a ncepe construirea casei. Sistemul modelat prin intermediul UML va fi descris prin urmtoarele aspecte ([DAV03], pagina 12): aspectele organizaionale specificul activitii utilizatorului final, definirea modulelor etc; aspectele non-funcionale amplasament, coordonare, etc.;
37

aspectele funcional structura static, structura dinamic (comportamental), interaciunile etc. UML prezint urmtoarele caracteristici care l face potrivit pentru modelarea sistemelor informatice de contabilitate ([DAV03]): este un limbaj universal care se poate folosi pentru realizarea sistemelor informatice; folosete abstractizri prin care devin accesibile structurile complexe pentru analitii informaticieni i designeri nespecialiti n domeniul pentru care se modeleaz sistemul informatic; abordeaz modelarea obiectual care asigur eficien prin reutilizarea componentelor care pot fi privite ca un ansamblu de obiecte inter-cooperante i care se pot organiza ntr-o structur ierarhic ([DAV03]); permite dezvoltarea unei ierarhii de modele, vederi i diagrame (vezi figura 4.1; utilizeaz modelarea vizual. Vederile Vederile prezint, sub form de succesiune de diagrame, unele aspecte ale sistemului modelat: vederea cazurilor de utilizare descrie modul de funcionare a sistemului i se caracterizeaz prin: o folosete cazurile de utilizare i actorii. Actorii pot fi: interni (fac parte din sistem) sau externi (sunt exteriori sistemului clieni, furnizori, bnci etc); o conine diagrame ale cazurilor de utilizare i, opional, diagrame ale activitilor; o destinaia lor este format din utilizatorul final al sistemului informatic, designeri, dezvoltatori (analiti, programatori, testori); vederea logic descrie modul de funcionare al sistemului din dou perspective: static (prin intermediul diagramelor de obiecte, diagramelor de clase) i dinamic (cu ajutorul diagramelor de activitare, diagramelor de stri-tranziii, diagramelor de colaborri); destinaia este compus din designeri i dezvoltatorii sistemului noi; vederea componentelor descrie implementarea modulelor i componentele prin detalii cum ar fi: structurile i tipurile de date, resursele care trebuie alocate (memorie intern, hard-disk etc.); vederea concuren este o vedere non-funcional prin care se descrie structura sistemului prin structurare n procese i procesoare (cu scopul alocrii eficiente a resurselor); diagramele sunt destinate dezvoltatorilor; diagramele utilizate diagramele dinamice i diagramele de implementare; vederea amplasamentului se folosete pentru redarea n mod grafic a locurilor n care vor fi amplasate echipamentele utilizate n cadrul sistemului informatic (calculatoare, case de marcat, puncte n care apar tranzacii bancare etc.), se pot folosi
38

instrumente de reprezentare ale reelelor de calculatoare (topologii); diagramele folosite sunt diagramele de amplasament.
UML

Modele de analiz

Modele de proiectare

Modele de proiectare

Vederea cazurilor de utilizare Diagrama cazuri de utilizare

Vederea logic

Vederea componentelor Diagrama componentelor

Vederea concuren

Vedere static

Vedere dinamic

Diagrama partajrilor hardware

Cazuri de test Diagrama subsistemelor Fiiere de test Diagrama claselor Diagrama obiectelor Diagrama activitilor Diagrama stri+ tranziii Diagrama colaborrilor

Figura 4.1 Ierarhia de modele, vederi i diagrame utilizate de UML Sursa: Davidescu, N. D. Proiectarea sistemelor informatice prin limbajul Unified Modeling Language, pagina 2

UML pune la dispoziie o extensie pentru modelarea specific lumii afacerilor ceea ce constituie un avantaj n realizarea sistemelor informatice de contabilitate. Reprezentarea grafic a elementelor n modelele UML este prezentat n tabelul 4.1.

Tabel 4.1 Elementele diagramelor UML Element (1) Elemente structurale Clas a) Reprezentare (2)
Nume clas
Proprieti

Nume clas

b)

39

Nume clas

Nume clas

c)

Proprieti Operaii

d)

Proprieti Operaii Responsabiliti

Instan

Identificator
Proprietate 1: valoare 1 Proprietate 2: valoare 2 ... Proprietate N: valoare N Metoda 1 Metoda 2 ... Metoda M Responsabilitate 1 Responsabilitate 2 .... Responsabilitate P

Interfa

Nume interfa

Caz utilizare

Nume caz utilizare

Nod Colaborare

Nod

Nume colaborare

(1) Component Elemente comportamentale Interaciune Stare Relaii


40

(2)
Nume component

Nume

Nume stare

Dependen
0..1 rol Clasa 1 1 rol *

Asociere

Agregare
* Clasa 2

Alte elemente Pachet

Nume pachet

Not

Nume not

Eticheta

a)

b)

Clasa se poate reprezenta n patru variante: a) numai numele clasei; b) numele clasei i proprieti; c) numele clasei, proprieti i operaiile care definesc comportamentul (metodele); d) complet: nume, proprieti, metode i responsabiliti. Un tip special de clas este clasa activ care poate iniia control i se reprezint grafic mpreun cu procesele sau firele de execuie. Componenta este o parte fizic nlocuibil a unui sistem. Nodul, element fizic, poate fi o resurs de calcul, poate deine memorie i capaciti de procesare. Interfaa unui obiect se constituie din mulimea de operaii prin care clasa realizeaz un serviciu. Colaborarea reprezint un ansamblu de elemente care prin comportament cooperativ sunt mai eficiente dect dac ar fi lucrat separat. Cazul de utilizare descrie sucesiunea de aciuni care sunt executate pentru a obine un rezultat de ateptat de ctre un actor al sistemului. Interaciunea reprezint mesajele schimbate ntre obiecte pentru atingerea unui scop. Etichetele se folosesc atunci cnd se linia, care reprezint trecerea de la o activitate la alta: a) este ntrerupt sau b) cnd mai multe linii trebuie unite pentru a reprezenta o jonciune. Numele etichetelor trebuie ales n aa fel nct s nu se confunde cu nume altor elemente (clase, actori); de obicei
41

se folosesc fie literele mari ale alfabetului fie cifre sistemului zecimal de numeraie. Un pachet se folosete pentru organizarea elementele n blocuri prin care se simplific reprezentarea unor diagrame detaliate n alt seciune a modelului. Nota se folosete pentru adugarea comentariilor referitoare la un element sau un grup de elemente. O relaie reprezint o conexiune ntre dou elemente; dup natura acestei conexiuni relaiile sunt: - de dependen (cnd modificarea strii unui element determin modificarea strii altui element cu care se afl n conexiune); - de asociere (cnd fiecare dintre elementele implicate n conexiune sunt independente, fiecare avnd rolul su n conexiune; - de agregare (cnd o clas conine pri care se pot modela prin alte clase; de exemplu o clas pentru clasa Factura poate fi modelat ca fiind o agregare a claselor AntetFactura i LiniiFactura. Cardinalitatea unei relaii reprezint numrul de instane care pot fi implicate n relaie la un moment dat. Cardinalitate de reprezint prin limita inferioar i limita superioar, cu observaia c dac nu se cunoate limita superioar aceasta se indic prin caracterul *; de exemplu, n cazul agregrii de mai sus, cardinalitatea pentru clasa AntetFactura este 1 iar pentru LiniiFactura 1..*.

4.2 DIAGRAME UTILIZATE DE UML Diagramele sunt prezentri grafice ale unui set de elemente, cel mai adesea exprimate ca un graf de noduri (elemente) i arce (relaiile)1. n continuare se vor prezenta diagramele care se pot folosi pentru construirea unui model utiliznd UML. Diagrama de clase Diagramele de clase se folosesc pentru reprezentarea grafic a claselor i a relaiilor dintre ele. Sunt cele mai folosite diagrame n modelarea sistemelor i ilustreaz vederea static de proiectare a unui sistem care ofer suport n primul rnd cerinelor utilizatorilor finali funcionale ale sistemului. Elementele coninute ntr-o diagram de clase sunt: clasele de obiecte, interfee i colaborri; relaii ntre clase; elemente de notare; mecanisme de extensie (constrngeri, valori etichetate); pachete sau subsisteme;

Mihalca, Rodica, Fabian, C. Realizarea produselor program aplicative, pagina 5-93 42

TER

1..* efectueaz

1.. * efectuat

OPERAIE BANCAR

conine

0..*

compune

1..*

INSTRUMENT PLAT

ORDIN DE PLAT

CAMBIA

CEC

Figura 4.2 Diagrama claselor Adaptat dup: [DAV03], pagina 14

1. 2. 3.

4.

n figura 4.2 diagrama claselor prezint: clasele implicate ntr-o operaiune bancar (ter, operaie bancar, instrument de plat, ordin de plat, cambia, cec); n aceast figur, pentru simplificare, nu s-au reprezentat atributele claselor; relaiile dintre clase (reprezentate prin sgei cu nume, de exemplu conine): Operaia bancar poate conine un document de plat de clas ordin de plat, cambie sau cec; cardinalitatea relaiilor n figura 4.2 semnificaiile lor sunt: a) 1..*, pentru clasa Ter, nseamn c unul sau mai multe obiecte de clas Ter poate face mai multe operaii bancare; b) 1..*, pentru clasa Operaie bancar, nseamn operaiile bancare pot fi efectuate de unul sau mai muli teri; c) 1..*, pentru clasa Instrument plat, nseamn unul sau mai multe instrumente de plat compun o operaie bancar; d) 0..* nseamn c un obiect de clas Operaie bancar poate folosi zero sau mai multe instrumente de plat de tipurile ordin de plat, cambie sau cec. rolurile claselor sunt: a) efectueaz pentru clasa Ter n relaia cu clasa Operaie bancar; b) efectuat pentru clasa Operaie bancar n relaia cu clasa Ter; c) conine pentru clasa Operaie bancar n relaia cu clasa Instrument plat; d) compune pentru clasa Instrument plat n relaia cu clasa Operaie bancar.

Diagramele obiect Diagramele obiect reprezint o variant a diagramelor claselor i care reflect instanele claselor coninnd pentru valorile atributelor, relaiile dintre instane i, pentru un model rafinat destinat i programatorilor, detalii specifice pentru tipurile atributelor (vezi figurile 4.5 i 4.6).
43

TER
J CUI Sediul Judetul Contul Banca

FACTURA
Numar Data Cota TVA Valoarea Valoarea TVA Total de plata Delegat

Figura 4.5 Diagrama claselor Ter i Factura

Figura 4.6 prezint o instan a clasei Ter i dou instane ale clasei Factura.
SC LUMIRA
J: 35/405/1999 CUI: 16257325 Sediul: Oravia Judetul: Timi Contul: RO56008978 Banca: BRLocal

TM ABA
Numar: 22348 Data: 17.07.2007 Cota TVA: 19 Valoarea: 210,10 Valoarea TVA:39,90 Total de plata:250 Delegat: Neacu Dan

TM ACD
Numar: 589632 Data: 25.01.2008 Cota TVA: 19 Valoarea: 917,60 Valoarea TVA:82,58 Total de plata:100,18 Delegat: Vesa Pavel

Figura 4.6 Instane ale obiectelor Ter i Factura

Diagramele cazurilor de utilizare Diagramele cazurilor de utilizare se utilizeaz pentru modelarea aspectelor dinamice ale sistemului (comportamentului unui sistem, subsistem sau al unei clase) i conine cazuri de utilizare, actori, relaii de dependen, de generalizare i de asociere, note i constrngeri i pachete. Simbolurile folosite sunt prezentate n figura 4.3 (Sursa: [DAV03], pagina 33).
numele sistemului sau a subsistemului
caz de utilizare numele cazului de utilizare

actor

asociere

caz de utilizare

caz de utilizare

Generalizare Figura 4.3 Simboluri folosite n diagrama cazurilor de utilizare 44

Diagramele cazurilor de utilizare se pot completa cu descrieri textuale care conin informaii privind cerinele i funcionalitatea sistemului. Cum actorii (ter este un actor n figura 4.4) se poate reprezenta prin clase, este evident c se pot modela i relaiile dintre acetia dac este necesar. Figura 4.4 prezint cazul de utilizare pentru eliberarea unei facturi.
cumprare

vnztor client
intocmete bonul de cas ntocmete factura

ghieu facturare

contare factur

serviciul contabilitate

Figura 4.4 Diagrama cazurilor de utilizare n cazul cumprrii unor articole i eliberrii unei facturi

Facem precizarea ca dreptunghiul n care sunt ncadrate cumprare, ntocmete bonul de cas, ntocmete factura i contare factur este grania unui subsistem. Diagramele de stare-tranziie Diagramele de stare-tranziie completeaz descrierea obiectelor prin: descrierea tuturor strilor posibile pe care le pot avea obiectele unei clase; evidenierea evenimentelor care determin schimbarea strilor. Diagramele de stare se ntocmesc pentru clasele care au un numr definit de stri.
datele sunt corecte s-a achitat contravaloarea facturii

Ciorn

Emis

nchis

Figura 4.7 Diagrama simplificat a strilor unei facturi

n figura 4.7, reprezint punctul iniial, iar punctul final al diagramei. Figura 4.8 prezint o diagram mbogit a strilor unei facturi.

45

Emitere

Neincasat

Achitare Refuzat la plat

Achitare parial

ncasat

Anulat

ncasat parial

A
Operare

Operat

nchidere

nchis

Arhivare

Arhivat

Figura 4.8 Diagrama strilor unei facturi

Diagramele de stare pot conine informaii despre timpul consumat, erori, condiii pentru ca o stare s devin adevrat (cum e datele sunt corecte din figura 4.7), expirarea timpilor de ateptare etc. Aceste diagrame sunt utile pentru a se identifica modul n care un obiect i poate modifica starea sub influena unor stimuli. Diagramele de stare pot fi nsoite de tabele n care se pot folosi formule de clacul (de exemplu, pentru a se indica matematic ce nseamn o factur neachitat).
iniializare

Deschis
ncasare ridicare numer

operare + n cas
nchidere

operare - n cas

nchis Figura 4.9 Diagrama strilor unei case de marcat

Strile operare + n cas i operare n cas se pot detalia pentru a se scoate n eviden operaiile contabile, documentele emise (de exemplu, chitana la ncasare). Mai multe diagrame de stri se pot conecta marcajul grafic este o sgeat ntrerupt (vezi figura 4.10).

46

iniializare

Deschis
ncasare

Nencasat

Emitere

Achitare

ncasat operare + n cas


nchidere

A
Operare

nchis

Operat

nchidere

Figura 4.10 Comunicare ntre subsistemele reprezentate de diagramele din figurile 4.8 i 4.9 n cazul plii unei facturi prin numerar

n figura 4.10 sgeata ntrerupt este folosit pentru a indica mesajul transmis din subsistemul diagramei strilor facturii n subsistemul casei de marcat. Liniile ondulate reprezint grania dintre partea vizibil i partea ascuns a fiecrui subsistem. Diagramele de activitate Diagramele de activitate modeleaz aspectele dinamice ale sistemului informatic i descriu activitile care se realizeaz prin operaii pentru care se pot prevedea condiii i decizii reflectnd astfel i rezultatele aplicrii acestora (vezi figura 4.11). O diagram de activitate conine ([MIH03], pagina 5-118): starea iniial reprezentat grafic prin ; starea final reprezentat grafic prin ; stri; tranziii; ramuri n urma evalurii unei expresii logice, fluxul de control al activitii trece de la o activitate la alta n funcie de valoarea de adevr a expresiei, punctul n care se evalueaz o expresie logic se reprezint grafic printr-un romb; bifurcaii i mbinri apar atunci cnd exist activiti care continu n paralel sau care se mbin ntr-un punct; reprezentarea grafic este o bar groas, vertical sau orizontal; culoarele se folosesc cnd strile de activitate se pot mpri n grupuri; culoarele se reprezint prin linii verticale; fluxul de obiecte se folosete atunci cnd n fluxul de control al activitii sunt implicate obiecte pentru care se poate specifica rolul, atributele i starea.

47

Lansare comand

A
Primire comand

[comand respins]

A
Realizeaz comanda nchide comanda

[comand acceptat]

Emite factura

Achit comanda

Accept plata

Factura

Figura 4.11 Diagrama activitilor n cazul unei comenzi

Diagramele de activitate pot fi folosite pentru a reprezenta ([LUN03], pagina 411) aciunile care se realizeaz atunci cnd se execut o operaie i activitatea intern a unui obiect. n figura 4.11 Factura reprezint o clas. Dac se face o detaliere mai amnunit, clasa se poate completa cu proprietile ei, metodele, rolul jucat n diagrama prezentat n figur. Figura 4.12 prezint diagrama de activitate pentru modulul de raportri manageriale. Utilizator, Modul raportare i Gestiune rapoarte sunt trei culoare ale diagramei cu ajutorul crora se grupeaz activitile. Refuzul cererii de listare se face pentru utilizatorii care nu au dreptul de listare ale unor raporte confideniale. Dup ce s-a listat un raport activitate, se poate continua pe una dintre ramurile prevzute: fie se nchide modulul pentru raportare fie se afieaz lista rapoartelor disponibile pentru a se emite o nou cerere de listare. Pentru exemplul din figura 4.12

48

UTILIZATOR

MODUL RAPORTARE

GESTIUNE RAPOARTE

afiare fereastr conectare introduce nume utilizator i parol validare utilizator

[utilizator valid]

construire lista rapoartelor

afiare lista rapoartelor cere listare raport

[utilizatorul nu are drepturi de listare a raportului selectat]

[utilizatorul are drepturi de listare a raportului selectat]

listare raport

A Figura 4.12 Exemplu de diagram a activitilor pentru listarea rapoartelor

Diagramele activitilor ajut la identificarea aciunilor care se pot realiza ntr-o ordine bine determinat. De asemenea, ele scot n eviden modul n care aciunile influeneaz obiectele cu care interacioneaz.

49

BIBLIOGRAFIE 1. [DAV03] Davidescu, N. D. Proiectarea sistemelor informatice prin limbajul Unified Modeling Language, Editua All Beck, Bucureti 2003 2. [LUN03] Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti, 2003 3. [MIH03] Mihalca, Rodica, Fabian, C. Realizarea produselor program aplicative, Editura ASE, Bucureti 2003 TESTE DE EVALUARE 1. Precizai cel puin trei caracteristici ale UML care l face potrivit pentru modelarea sistemelor informatice de contabilitate: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 2. Vederile utilizate de UML sunt: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 3. Diagrama din figura de mai jos reprezint:
Clasa 1 1

* Clasa 2

a. dou clase independente; b. un element de agregare; c. o asociere condiionat. 4. Dup natura conexiunii dintre dou elemente, relaiile sunt: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 5. Precizai diagramele folosie de UML:

50

_____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 6. ntocmii diagrama strilor unui aviz de expediie. 7. ntocmii diagrama activitilor n cazul unei facturi ncasate printr-un ordin de plat. 8. ntocmii diagrama activitilor pentru modulul de introducere a documentelor justificative cu contare automat al unui sistem informatic de contabilitate. 9. Fie clasa STUDENT cu proprietile Nume, Prenume, Anul de studiu, Nota i clasa FACULTATE cu proprietile Denumire, Specializare, An acreditare. S se ntocmeasc diagrama claselor i s se stabileasc rolul i cardinalitatea fiecrei clase. 10. Pentru clasele de la exerciiul 9, s se ntocmeasc diagrama obiectelor.

51

TEMA 5. ANALIZA SISTEMULUI INFORMATIC DE CONTABILITATE EXISTENT


CONINUT 5.1. Obiectivele analizei 5.2. Elaborarea modelului fizic al sistemului existent 5.3. Elaborarea modelului logic al sistemului existent 5.4. Alegerea unui nou sistem informatic de contabilitate REZUMAT Analiza sistemului informatic de contabilitate existent este o etap important prin care sistemul devine accesibil n activitatea de reproiectare a sistemului sau de formulare a unor cerine suplimentare. OBIECTIVE Tema propus are ca scop nvarea modului n care se poate studia un sistem informatic de contabilitate existent.

5.1 OBIECTIVELE ANALIZEI Analiza sistemului informatic de contabilitate existent este o etap important prin care sistemul devine accesibil n activitatea de reproiectare a sistemului sau de formulare a unor cerine suplimentare. Analiza sistemului informaional existent este cea mai sensibil parte a proiectrii unui sistem informatic i const n descrierea sistemului deja existent dar i a celui care urmeaz a fi introdus. Din cauz c n economia romneasc nu exist un standard referitor la sistemele informaionale ([BOB03, pagina 31), analiza sistemului informatic este o problem spinoas care isc divergene referitoare chiar i la timpul care trebuie alocat acestei etape: un timp prea scurt poate nsemna insucces n cunoaterea sistemului, nenelegerii modului sau nelegerea precar a modului n care funcioneaz acesta i nedetectarea locurilor i posibilelor situaii n care pot apare erori. Un timp prea lung dedicat acestei etape nseamn scurtarea timpilor celorlalte etape ceea ce poate duce la rezultate incorecte i/sau soluii incomplete. n ambele situaii rezultatul poate fi un produs care nu se ridic la nivelul de ateptare al utilizatorului final. Cunoaterea mediului n care funcioneaz sistemul informatic de contabilitate este primul pas care trebuie fcut etapa de analiz. Grania dintre sistem i mediu se poate reprezenta prin modelul mediului. Modul n care sistemul interacioneaz cu mediul se poate reprezenta n diagrama modelului mediului.

52

Mediul sistemului informatic de contabilitate Studierea mediului n care va funciona sau funcioneaz sistemul informatic de contabilitate ncepe cu culegerea de informaii despre unitatea economic elaborndu-se dou modele: modelul fizic: prezint structura tehnic i operaional, modul de funcionare ntr-o anumit implementare, cu anumite restricii de ordin tehnic; modelul logic: prezint modul de funcionare independent de implementare (acest model mpreun cu cerinele utilizatorului este folosit pentru proiectarea sistemului informatic nou). Studiul mediului intern al unitii economice n care funcioneaz sistemul informatic de contabilitate cuprinde urmtoarele activiti ([LUN03]): 1. specificare cunotinelor generale despre organizaie denumirea, sediul central, filiale, forma juridic, domeniul de activitate, sfera de activitate, oferta de produse, numrul de angajai, punctele de lucru, structura organizatoric (este de folos i alctuirea unei organigrame), informaii despre clieni, furnizori etc. 2. cunoaterea activitilor organizaiei, a normativelor i a legislaiei de reglementare a activitii: regulamentul de funcionare, regulamentul de ordine interioar, statutul de funcionare, informaii utile despre funcii, relaii dintre compartimente, activitile de interes i detalierea modului de organizare a acestora, resursele folosite etc. Prezentarea activitilor se poate face sub form de text liber, cu organigrame, tabele, imagini sau orice alte elemente prin care se poate descrie mai bine; 3. prezentarea caracteristicilor de management: metodele i tehnicile folosite n luare deciziilor, planificarea, organizarea, controlul etc.; 4. identificarea mijloacelor tehnice folosite pentru prelucrarea datelor, modul de utilizare, personalul implicat (nivelul de studii necesar, instruirea continu), performanele i punctele slabe. n cazul n care analiza sistemului se face pentru identificarea cauzelor unor deficiene n funcionare sau pentru proiectarea/reproiectarea unei componente sau a unei pri a sistemului, echipa de analiz trebuie s ia n considerare cerinele utilizatorului i opiniile managerilor care se pot prezenta sub form tabelar specificndu-se informaii referitoare la persoana care a emis cerina i descrierea ei (aciunea ataat, limitele calitative). Cerinele pot fi clasificate n dou grupe mari1: - cerine funcionale se refer la modul n care sistemul nou trebuie s realizeze activitile: modul n care sistemul interacioneaz cu alte sisteme, organizarea interfeelor grafice i obinerea rapoartelor, stocarea datelor, aceesarea i prelucrarea lor etc.;
1

Lungu, I., Sabu, G., Velicanu, M. Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti 2003, paginile 81-82 53

- cerine nefuncionale se refer la modul n care resursele trebuie s aduc performan la nivel funcional: timpul de acces a datelor, securitatea datelor, arhivarea i refacerea datelor, audit i control, automatizarea unor operaii etc. Structurarea sistemului informaional existent Unitile economice sunt sisteme complexe n care se manifest o multitudine de interaciuni ntre elementele constituente i cu mediul exterior. Sistemul se poate descompune dup mai multe criterii: 1. funciunile sistemului sistemul se descompune din punct de vedere funcional n subsisteme: financiar-contabil, cercetare-dezvoltare, resurse umane etc.; 2. activitile sistemului activitile sunt grupate n funcie de specific (gestiune, salarizare, evidena comenzilor, evidena produciei etc.); 3. organizarea sistemului fiecare compartiment sau departament este considerat un element de descompunere: personal, administraie, producie, marketing, contabilitate etc.; 4. natura componentelor sistemul se descompune n funcie de tipul componentelor: materii prime, produse finite, resurse umane etc. i se identific activitile asociate cu acestea (producie, desfacere etc.); 5. conducere se identific a) subsistemele de conducere strategic, operativ i tactic sau b) subsistemul decizional, subsistemul condus i subsistemul informaional. Pentru orice tip de descompunere, descrierea unui sistem se poate face pe trei nivele de detaliere ale caracteristicilor: - generic: cnd se folosesc caracteristici generice; - parial: cnd se detaliaz cel puin o parte constituent a sistemului prin specificarea complet a parametrilor care, prin cuantificri, definesc caracteristicile; - particular: cnd se detaliaz toate prile constituente ale sistemului prin specificarea tuturor parametrilor afereni caracteristicilor. Descrierea unui sistem va avea ca finalitatea realizarea unor documente care cuprind specificaii de proiectare i de implementare.

5.2 ELABORAREA MODELULUI FIZIC AL SISTEMULUI EXISTENT n timpul elaborrii modelului fizic al sistemului informatic de contabilitate existent se vor construi: - modelul mediului prin realizarea diagramei de context; - modelul comportamental prin realizarea modelului fizic al prelucrrilor i a modelului logic al datelor.

54

Modelul fizic al prelucrrilor conine descrierea datelor de intrare i a datelor de ieire, diagramele de flux a documentelor, descrierea entitilor externe sistemului i/sau modelului i descrierea proceselor elementare. Diagramele de flux a documentelor Diagramele de flux a documentelor, pe scurt DFD, sunt folosite pentru a reprezenta prelucrrile dintr-un sistem, parcursul documentelor de la intrarea n sistem pn la obinerea rezultatelor, de la emiterea lor pn la prsirea sistemului. Aceste diagrame scot n eviden modul n care documentele sunt distribuite, utilizate, ultimul loc n care sunt folosite, de fapt cam tot ce se ntmpl cu documentele ntr-un sistem. Diagramele se pot folosi pentru urmrirea i stabilirea controlului intern asupra documentelor, a responsabilitilor, slbiciunilor sau ineficiena comunicrii interne. Pentru a se elabora diagramele fluxului de documente trebuie executai urmtorii pai preliminari: 1. identificarea prilor sistemului implicate n fluxul documentelor; 2. prin chestionarea oamenilor din interiorul unitii economice, luarea notielor manuale detaliate despre fiecare document folosind simboluri distincte pentru fiecare document, tabele, liste, grafuri; 3. transpunerea n format electronic i folosind simboluri standardizate, dac exist; 4. verificarea diagramelor lund n considerarea urmtoarele aspecte: a. o diagram trebuie s aib un nceput i un sfrit n desfurarea evenimentelor; b. utilizarea comentariilor acolo unde aspectele surprinse nu sunt clare; c. definirea clar a intrrilor, prelucrrilor i ieirilor; d. documentele s nu fie conectate direct; e. cnd se utilizeaz mai multe copii ale unui document, se nscrie numrul de copii; 5. verificarea diagramelor din punct de vedere funcional mpreun cu oamenii chestionai anterior i refacerea acelor diagrame care nu corespund; 6. stabilirea datelor de identificare a diagramelor prin: numele documentelor, data i creatorul. Diagramele fluxurilor de documente se pot construi n manier simplificat (vezi figura 5.1) dar i n manier detaliat (vezi figura 5.2).

55

Document de plat

Client Factur (exemplarul 1) Cumprare

Lista preurilor

Contabilitate

Oferta de produse

Punct de vnzare

Factur (exemplarul 2)

Situaia lunar a vnzrilor Situaia zilnic a stocurilor Figura 5.1 Diagram de flux a documentelor

Diagramele simplificate ale fluxurilor de documente se elaboreaz rapid din arce direcionale (care pot fi nsoite de explicaii scurte care descriu aciuni i numrul de exemplare ale documentului) i din elipse (n care se ncriu numele entitilor implicate). Acest tip de diagrame sunt utile pentru a nelege interaciunile dintre prile componente ale sistemului. Figura 5.1 prezint diagrama de flux simplificat a documentelor n cazul unei uniti economice particulare. Aceast diagram poate fi mai complex n cazul unor uniti economice mai complexe, de exemplu n cazul unei ntreprinderi productoare pot exista departamente distincte pentru livrri, depozitare i livrare. Diagramele detaliate de flux a documentelor conin informaii referitoare la locurile i momentele n care apar evenimente sau se desfoar aciuni ca: documentul apare (este emis sau recepionat) sau se completeaz pentru prima oar un document tipizat; se modific, prin adugare sau tergere, coninutul unui document; se manipuleaz i/sau se deplaseaz un document de exemplu este transmis ntre departamente fr nicio modificare i fr nicio reflectare n contabilitate, se execut verificarea cantitativ i/sau calitativ a unui document; staionarea temporar a documentului; arhivarea sau distrugerea documentului; crearea sau generarea unui document din mai multe exemplare. Simbolurile folosite pentru elaborarea diagramelor de flux de documente sun prezentate n tabelul 5.1. Se observ c unele simboluri sunt folosite pentru a specifica dou sau mai multe aciuni care se pot desfura simultan, de exemplu simbolul care se poate folosi a specifica locul n
56

care se efectueaz deodat manipularea, modificarea i verificarea unui document. Tabel 5.1 Simboluri folosite n elaborarea diagramelor de flux a documentelor1 Simbol -1Utilizare -2Apariia unui document sau completarea pentru prima oar a unui document tipizat

Modificarea coninutului unui document

Manipularea unui document

Verificarea unui document

Deplasarea documentului

Staionare temporar

Arhivare sau distrugere

Crearea unui document avnd mai multe copii. Copiile se numeroteaz sau eticheteaz pentru a se distinge mai uor n diagram i n documentaia aferent

Manipulare i verificare a documentului

Manipulare, modificare i verificare a documentului

Linii de influen generare de documente noi, modificarea coninutului documentelor, manipularea documentelor

Bloc de simplificare care poate conine oricare din simbolurile de mai sus

Bob, C. A. Sisteme informatice n comer, Editura ASE, Bucureti 2002 57

Figura 5.2 prezint diagrama de flux a documentului factur n cazul folosirii unui facturier.
Cumprtor 1 Arhivare la cotor 3 Contabilitate 2

Arhivare electronic nregistrarea documentului n jurnal Figura 5.2 Diagrama de flux a unei facturi

Factura se ntocmete n trei exemplare care se distribuie astfel: primul exemplar la cumprtor, al doilea este transmis departamentului de contabilitate iar al treilea rmne la cotor. Diagramele de flux a datelor Diagramele de flux a documentelor se pot folosi i pentru elaborarea diagramelor de flux a datelor, pe scurt DFDs. Aceste diagrame se ntocmesc respectndu-se urmtoarele reguli ([LUN03]): 1. pentru a fi identificate mai uor, procesele i stocurile de date sunt numerotate secvenial; 2. entitile externe se plaseaz n jurul stocurilor de date; 3. stocurile de date i entitile externe se pot reprezenta multiplicat atunci cnd ntretierea liniilor din graf poate transforma diagrama n una puin lizibil. O diagram DFDs este constituit, de regul, din patru elemente de baz (vezi tabelul 5.2): 1. sursele i destinaiile datelor reprezint organizaii sau persoane care trimit sau recepioneaz datele utilizate sau recepionate de ctre sistem; 2. fluxurile de date reprezentate prin sgei cu nume monodirecionate sau bidirecionate; 3. procesele de transformare; 4. stocurile de date.

58

Tabel 5.2 Simboluri folosite n elaborarea diagramelor de flux a datelor1 Simbol


nr. localizare proces Procese

Utilizare

flux

Flux de date

entitate

Entitate

entitate

Entitate duplicat

et. et.

stoc stoc

Stoc de date Stoc de date duplicat

Tabelul 5.2 prezint simbolurile folosite pentru ntocmirea diagramelor de flux a datelor. Procesele, localizate ntr-un compartiment sau la o persoan, sunt etichetate cu texte care sugereaz modul n care se transform datele. Un flux apare ntre dou procese i este etichetat printr-un substantiv (simplu sau compus) n corelaie cu datele sau pachetul de date transmis, de exemplu stoc final, situaia vnzrilor, ncasri etc. Entitile sunt emitorii i/sau receptorii de date i pot fi interni sau externi sistemului. Dup modul de prelucrare a datelor, fluxurile de date sunt de dou tipuri: - de consultare n acest caz un proces folosete unu sau mai multe stocuri de date (vezi figura 5.3); - de actualizare n acest caz un proces modific datele dintr-un stoc de date (prin operaii de adugare, modificare, tergere); acest tip de fluxuri sunt reprezentate n unele lucrri de specialitate prin sgei birecionale (vezi figura 5.4). Stocurile de date sunt depozite temporare sau permanente de date i pot de trei tipuri, etichetate n funcie de tipul stocului i nsoite de un numr de identificare: - M: manuale registru, facturier, dosar, arhiv etc.; - D: electronice pe suport de memorie extern hard-disk, dischet, band magnetic, CD etc.; - T: temporar, de exemplu un fiier care conine o factur proforma i se stocheaz temporar pn la ntocmirea facturii finale. n figura 5.3 se observ c sunt consultate dou stocuri de date pentru a analiza o comand: stocurile de produse pentru a se verifica dac
1

Bob, C. A. Sisteme informatice n comer, Editura ASE, Bucureti 2002 59

exist cantitatea cerut i soldurile pentru a se verifica dac soldul acoper plata pentru comand. Figura 5.4 prezint cazul actualizrii conturilor contabile pe baza unui document.
M1 Stocuri produse M2 Sold plat

1.1

Livrare

Analiz comand Figura 5.3 Flux de consultare Sursa: [LUN03] pagina 195 5.1 ncasare

Analiz document

M5 Conturi contabile Figura 5.4 Flux de actualizare

Elaborarea diagramelor DFDs se poate face etapizat: n prima faz se vor elabora diagramele contextuale generale care se vor rafina pn la nivelul de detaliere cerut. Validarea diagramelor se face de ctre analiti i de ctre utilizatori. Investigarea i reprezentarea datelor Aceast activitate este o activitate de importan mare pentru analiti avnd un impact mare n etapa de programare. Scopul principal al acestei activiti este elaborarea: - modelului logic al datelor, pe scurt MLD care pune n evidena datele i relaiilor dintre ele n interiorul sistemului; - catalogul datelor pentru sistemul informatic de contabilitate existent. Construirea modelului MLD presupune executarea urmtorilor pai([LUN03], paginile 205-213): 1. identificarea entitilor se identific grupele de date pe care le folosete sistemul, fiecare grup constituindu-se ca o entitate, de exemplu: comand, produs, beneficiar etc.; 2. identificarea relaiilor dintre entiti se construiete matricea entitilor n care se vor marca prin caracterul * influenele dintre entiti (vezi tabelul 5.3), pe baza acestor influene se construiesc relaiile (asocierile sau legturile) dintre ele.
60

Tabel 5.3 Matrice entitate exemplu


Linie comand Linie factur Linie livrare Linie intrare *

Beneficiar

Comand

Beneficiar Comand Linie comand Livrare Linie livrare Factur Linie factur Produs Intrare Linie intrare Furnizor

* * * * * * * * * * *

Surs: [LUN03], pagina 206

Tabelul 5.3 a fost construit folosindu-se urmtoarele informaii culese n etapele anterioare: - un beneficiar poate lansa una sau mai multe comenzi, n acest caz asocierea este 1: N; - pentru o comand se execut o singur livrare; - o comand poate conine una sau mai multe linii, cte o linie pentru fiecare produs comandat; - o livrare se ncheie printr-o factur; o livrare poate conine una sau mai multe linii, una pentru fiecare produs livrat; - o factur poate conine una sau mai multe linii, una pentru fiecare produs facturat; - un produs poate apare n documentele de intrare ct i n documentele de ieire, mai corect spus n liniile acestora; n acest caz, cu oricare dintre documentele de intrare i/sau ieire produsul se afl n relaie M:M (de exemplu o factur poate conine mai multe produse iar un produs poate apare n mai multe facturi); - o intrare provine de la un furnizor i poate conine una sau mai multe linii, cte una pentru fiecare produs intrat. 3. elaborarea modelului entitate-asociere acest model integreaz toate entitile i relaiile dintre ele determinate n paii anteriori, relaiile sunt etichetate printr-un verb care exprim semnificaia legturii i prin cardinalitatea ei (vezi figura 5.5 unde simbolul reprezint o cardinalitate mai mare dect unu);

61

Furnizor

Factur

Livrare

Produs

Intrare

Beneficiar
emite

este emis

Comand

conine face parte din

Linie comand

este pentru este referit n

Produs

Figura 5.5 Exemplu de model entitate-asociere Surs: [LUN03] pagina 209

4. elaborarea diagramei de coresponden ntre stocurile fizice i entitile logice fiecare stoc de date este pus n coresponden cu entitile cu care au fluxuri de actualizare: - direct cum ar fi stocul de date pentru produse i entitatea produse, vezi figura 5.6); - indirect i sau multipl vezi figura 5.7; Stocuri fizice M1 Stocuri produse M2 Sold de plat Entiti
Produs

Beneficiar

Figura 5.6 Exemple de coresponden direct dintre un stoc fizic i o entitate Surs: [LUN03], pagina 209

n figura 5.6, stocurile fizice de date, manuale, pot fi registre tabelate care conin: - pentru Stocuri produse: denumirea produsului i cantitatea existent n stoc la un moment dat; - pentru Sold de plat: denumirea beneficiarului i suma care se constituie ca sold de plat. Stocuri fizice
Intrare
conine face parte din

Entiti
Linie intrare
este pentru

M1 Fi magazie
este referit de

Produs Figura 5.7 Exemplu de coresponden dintre un stoc fizic i mai multe entiti Surs: [LUN03], pagina 209

62

n figura 5.7, stocul fizic de date este un stoc manual pentru care se folosesc formulare tipizate. n elaborarea modelului logic, acest stoc de date poate fi dublat de un stoc electronic de date cu aceeai semnificaie i utilitate. 5. descrierea detaliat a entitilor, atributelor acestora i a relaiilor dintre acestea aceast descriere se face prin intermediul unor documente standardizate care conin urmtoarele informaii: - pentru descrierea entitilor: numele, descrierea, lista atributelor, lista relaiilor i observaii; - pentru descrierea unui atribut: numele, entitatea care l conine, tipul entitii, descrierea, domeniul de valori pentru care este considerat a fi valid (de exemplu M, F este domeniul de valori pentru sex), valoarea implicit (de exemplu 0,19 pentru cota TVA), observaii suplimentare, i informaii necesare pentru etapa de transpunere n limbaj de programare cum ar fi: formatul, i lista utilizatorilor cu drepturile de acces i drepturile de acces, domeniul de grup (care grupeaz atribute cu semnificaii i mod de funcionare asemntor; domeniile de grup se pot descrie detaliat, dac este necesar); - pentru descrierea asocierilor: explicaii descriptive; numele entitii, tipul de legtur, cardinalitatea i alte observaii. 6. validarea modelului logic al datelor se face mpreun cu beneficiarul verificnd toate aspectele luate n considerare cum ar fi: parcursul datelor, relaiile dintre ele, valorile i domeniile de validare, cardinalitatea. Crearea catalogului datelor este o activitate complex care presupune crearea unui dicionar al datelor care conine descrierea atributelor i descrierea domeniilor de grup. Catalogul va deveni un depozit, cu o structur dinamic, de mari dimensiuni folosit n etapa de programare n mai multe scopuri: pentru automatizarea fluxurile existente n cadrul aplicaiei, pentru construirea motoarele de integrare a aplicaiilor i pentru determinarea fluxurilor de date.

5.3 ELABORAREA MODELULUI LOGIC AL SISTEMULUI EXISTENT Modelul logic a sistemului informatic de contabilitate existent scoate n eviden urmtoarele aspecte: - ce face sistemul; - funciile de baz ale sistemului; - problemele legate de redundana datelor - problemele legate de duplicarea proceselor de prelucrare; - procesele manuale care nu pot fi automatizate complet.

63

Se obin diagramele de flux logic pe baza diagramelor DFDs care se descompun n nivele succesive, eliminndu-se: - toate procesele de natur fizic (cum ar fi cele de scriere pe hard-disk care nu intereseaz n mod direct utilizatorul final acesta presupunnd c tehnologia folosit este perfect adic poate ignora aspectele care in de scrierea efectiv pe hard-disk); - stocurile de date care se folosesc ca urmare a constrngerilor din sistem (cele temporare, de sincronizare etc.). Construirea modelului MLD presupune executarea urmtorilor pai([LUN03], paginile 214-222): 1. identificarea stocurilor logice de date se realizeaz prin gruparea datelor nrudite, care se utilizeaz mpreun frecvent sau care se utilizeaz des n acelai timp; gruparea trebuie s respecte urmtoarea regul: un stoc logic conine una sau mai multe entiti, dar o entitate poate s aparin unui singur stoc logic de date; n mod similar identificrii stocurilor fizice de date se stabilesc diagrama de coresponden ntre stocurile logice de date i entitile logice i diagrama de coresponden ntre stocurile logice de date i cele fizice; 2. nlturarea dependenelor fizice i temporale se elimin din diagramele modelului fizic informaiile urmtoare: localizarea proceselor, periodicitatea i momentele de timp ale execuiei proceselor, caracterizrile fizice ale documentelor (de exemplu, faptul c o factur se va tipri pe o coal de dimensiune A4); 3. derivarea proceselor logice acest pas trebuie s elimine redundanele care exist la nivel de procese i s nlocuiasc stocurile fizice de date cu stocurile logice de date; 4. derivarea fluxurilor logice acest pas trebuie s stabileasc numai fluxurile de informaii utilizate efectiv de fiecare proces; 5. gruparea proceselor elementare i construirea unei ierarhii ale entitilor; 6. verificarea diagramelor; 7. elaborarea documentaiei documentaia se compune din toate diagramele fluxurilor de date ale modelului logic. Odat ncheiat aceast etap se poate face evaluarea sistemului informatic de contabilitate existent prin evaluarea urmtoarelor: 1. performanele i limitrile sistemului: a. ndeplinirea obiectivelor, funciilor, sarcinilor de baz i de exercitare a conducerii; b. oportunitatea, completitudinea i suficiena informaiilor destinate conducerii; c. timpul de rspuns al sistemului intervalul de timp din momentul transmiterii unei cereri din partea conducerii pn la momentul primirii rspunsului trebuie s fie scurt; d. calitatea i precizia informaiilor obinute; e. calitatea i sigurana fluxurilor informaionale; f. posibilitile de control; g. timpii optimi privind reacia la apariia unor erori i corecia acestora;
64

h. gradul de integrare a sistemului informaional n corelaie direct cu gradul de automatizare a prelucrrilor; 2. gradul de pregtire a unitii economice pentru implementarea sistemului informatic de contabilitate nou: a. existena cunotinelor i disciplinei tehnologice; b. posibilitile de instruire i autoinstruire n ceea ce privete utilizarea computerelor i a produselor informatice etc. Nivelul de pregtire al unei uniti economice pentru implementarea unui sistem informatic de contabilitate nou este greu de stabilit pentru c intervin o multitudine de variabile: de la suma limitat n ceea ce privete achiziionarea pn la intolerana personalului n faa schimbrii modului de lucru cu care s-au obinuit.

5.4 ALEGEREA UNUI NOU SISTEM INFORMATIC DE CONTABILITATE Decizia de schimbare a unui sistem informaional existent poate interveni ca urmare a etapei de analiz. n cazul existenei unui sistem de contabilitate care prezint deficiene majore (depire moral, insecuritate n funcionare) care se pot repara cu costuri mari n timp i bani, conducerea unitii economice poate prefera achiziionarea unui sistem de contabilitate nou. Alegerea unui sistem de contabilitate nou se nscrie n categoria problemelor mutiatribut sau multicriteriale pentru c este o decizie care trebuie s in cont de o mulime de atribute/criterii dintre care unele fiind contradictorii: - criterii obiective cum ar fi: preul, costul abonamentului de ntreinere a modificrilor n concordan cu legislaia; - criterii subiective, intangibile cum ar fi: ergonomia, interfaa prietenoas; - incertitudini cum ar fi: securitatea garantat a datelor. Problemele multiatribut se modeleaz sub form matriceal (vezi tabelul 5.4) unde: - Ci, i = 1, 2, ..., n sunt criteriile utilizate n luarea deciziei, se recomand ca n s nu fie mai mare de 10; - Aj, j = .1, 2, ..., m sunt aciunile posibile, n cazul nostru produsele software de contabilitate analizate; - aij, , i = 1, 2, ..., n, j = .1, 2, ..., m sunt consecinele posibile. Tabel 5.4 Matricea deciziilor pentru problemele multi atribut Aj A1 A2 ... Am Ci C1 a11 a21 ... am1 C2 a12 a22 ... am2
65

... ... ... ... ...

Cn a1n a2n ... amn

Aceast matrice se traduce n viaa real astfel: conducerea implicat n luarea unei decizii de achiziionare, va constitui o echip care format din m membri care va stabili criteriile care trebuie luate n considerare; de exemplu: operatorul va stabili ergonomia, inginerul de sistem sigurana n funcionare, contabilul ef automatizarea prelucrrii contabile a documentelor dar i preul mic i costurile de ntreinere ct mai sczute .a.m.d. Criteriile neobiective vor primi valori pe o scal subunitar, de exemplu pentru criteriul interfa se stabilete urmtoarea scal: 0,75 interfaa este foarte prietenoas (nu este ncrcat, culorile sunt potrivite, butoanele de declanare a unei operaii sunt la ndemn etc.); 0,5 interfaa este puin prietenoas; 0,25 interfaa nu este prietenoas; 0 interfaa este greoaie. Stabilirea criteriilor este urmat de ierarhizarea lor (stabilirea importanei) folosindu-se o scal de la 1 la p, unde p este numrul persoanelor implicate n luarea deciziei, vezi tabelul 5.5 unde linia K este linia sumei valorilor de ierarhizare i conine indicii de deprtare iar nij sunt notele de ierarhizare acordate de fiecare persoan fiecrui criteriu. Ierarhizarea criteriilor devine astfel un proces n are este implicat toat echipa. n funcie de valoarea urmrit, criteriile sunt: - de minim atunci cnd se dorete ca valoarea luat n discuie s fie ct mai mic, de exemplu preul produsului software; - de maxim cnd se dorete ca valoarea s fie ct mai mare, de exemplu, interfaa s fie ct mai prietenoas. Pentru fiecare criteriu, se calculeaz indicele de deprtare ( N j ) max unde N max reprezint nota maxim care se poate Kj = ( j) Nj acorda nmulit cu numrul de persoane care acord note criteriilor. Tabel 5.5 Ierarhizarea deciziilor Pj Ci C1 C2 ... Cn

P1 P2 ... Pp K

n11 n21 ... np1 K1= ni1


i =1 p

n12 n22 ... np2 K2= ni 2


i =1 p

... ... ... ... ...

n1n n2n ... npn Km= nin


i =1 p

Urmtorul pas este calcularea matricei de deprtare aceste valori sunt subunitare 1 q unde q se calculeaz n funcie de tipul criteriului (de minim sau de maxim) astfel:
66

- pentru criteriile de minim raportul se face ntre valoarea criteriului i cea mai mic valoare dintre toate valorile criteriului; - de maxim raportul se face ntre valoarea criteriului i valoarea cea mai mare dintre toate valorile criteriului.

n final se alctuiete matricea de apartenen folosindu-se linia K din tabelul de ierarhizare a deciziilor, matricea de deprtare prin formula X K Zij = e ij j unde Z ij sunt gradele de apartenen, X ij sunt valori din matricea de deprtare iar
Kj

sunt coeficienii de deprtare. n matricea de

apartenen pe ntr-o coloan distinct se nsumeaz valorile pe toate liniile i se alctuiete clasamentul unde alternativa cu suma cea mai mare ocup primul loc.
Exemplu: alegerea unui produs software de contabilitate utiliznd criteriile multiatribut Problem

La firma LocalAuto SRL se dorete implementarea unui sistem informatic de contabilitate n condiiile n care contabilitatea s-a efectuat manual.
Rezolvare

Admistratorul firmei a format echipa decizional format din nou persoane: el nsui, contabilul-ef, doi operatori pe calculator i specialiti ai firmei de consultan. n urma analizei sistemului informaional de contabilitate existent, sau elaborat urmtoarelor cerine minimale pentru produsul software: C1. preul s fie mai mic de 3500 de lei; C2. abonament pentru actualizarea modificrilor n concordan cu schimbrile legislaiei s permit actualizarea prin intermediul Internetului; C3. s existe posibilitatea plii n rate a aplicaiei i a abonamentului pentru actualizrile periodice; C4. s se fac instruirea la instalare i o instruire permanent prin intermediul telefonului i/sau Internetului; C5. interfaa grafic s fie prietenoas; C6. s existe suport tehnic in zilele lucrtoare pn la ore trzii; C7. utilizarea aplicaiei s se poat face pe minim trei calculatoare; C8. utilizarea aplicaiei s se fac sub incidena sistemului de operare Windows XP; C9. aplicaia s fie modular i s conin un modul special pentru contabilitatea financiar.

Pentru criteriul C3 plata n rate s-a stabilit urmtoarea scalare: 0 nu exist posibilitatea plii n rate; 0,25 plata n rate se face anual;
67

0,5 plata n rate se face trimestrial; 0,75 plata n rate se face lunar; 0,9 plata n rate se poate face printr-o perioad specificat de client. Pentru criteriul C4 instruire s-a stabilit urmtoarea scalare: 0 nu exist posibilitatea instruirii la instalare; 0,25 instruirea se face doar la instalare sau ulterior prin plata unui abonament de instruire; 0,5 - nu se face instruire la instalare dar exist posibilitatea instruirii permanente; 0,75 instruirea se face la instalare, prin ofert de documentaie i permanent (prin intermediul telefonului i/sau Internetului).

Pentru criteriul C5 interfaa grafic s-a stabilit urmtoarea scalare: 0 neprietenoas; 0,25 puin prietenoas; 0,5 mediu prietenoas; 0,75 foarte prietenoas. Ofertele luate n considerare sunt urmtoarele aplicaii contabile: SagaC. (http://www.sagasoft.ro), ContaSQL (www.cometa.ro), EasyCont (http://www.sasory.ro), CielConta (http://www.ciel.ro)
Tabel 5.6 Exemplu. Matricea deciziilor
Ci Aj
A1 (Saga) A2 (ContabSQL) A3 (EasyCont) A4 (CielConta) C1 Pre achiziie + preul abonamentului (criteriu de minim) 350 156 1350 2200 C2 Plata n rate (criteriu de maxim) C3 Instruire (criteriu de maxim) C4 Interfaa (criteriu de maxim, intangibil) 0,5 0,25 0,75 0,25

0,25 0,75 0 0

0,5 0,75 0,5 0,25

Dup studierea ofertelor disponibile s-a constat c urmtoarele cerine sunt respectate de ctre toate aplicaiile studiate: C6, C7, C8 i C9 aa c nu vor apare n matricea deciziilor, vezi tabelul 5.6. Determinarea coeficienilor de importan a criteriilor adic ierarhizarea criteriilor este prezentat n tabelul 5.7.

68

Tabel 5.7 Exemplu. Ierarhizarea criteriilor Pk \ Cj C1 4 4 3 4 4 3 1 2 1 26 1,385 C2 1 2 4 4 4 4 1 4 4 28 1,286 C3 4 4 4 4 4 1 2 1 1 25 C4 3 3 3 4 2 4 1 1 2 23

(d) K j =

( N ) max = 36
j

P1 P2 P3 P4 P5 P6 P7 P8 P9 Kj

Nj

Nj

1,440 1,565

Se calculeaz matricea de deprtare, prezentat n tabelul 5.8


Tabel 5.8 Exemplu. Matricea de deprtare Ai \ Cj A1 (Saga) A2 (ContabSQL) A3 (EasyCont) A4 (CielConta) C1 0,554 0,000 0,884 0,929 C2 0,667 0,000 1,000 1,000 C3 0,333 0,000 0,333 0,667 C4 0,333 0,667 0,000 0,667

X 11 = 1

156 156 =0 = 1 0, 446 = 0,554 X 12 = 1 350 156 , , 156 156 X 13 = 1 = 1 0,116 = 0,884 X 14 = 1 = 1 0, 071 = 0,929 1350 2200 , 0, 25 0, 75 0, 25 0,50 X 21 = 1 = = = 0, 667 0, 75 0, 75 0, 75 , X 23 = X 24 = 1

0 = 1 0 = 1 0, 75 0,5 0, 75 0,5 0, 25 X 31 = 1 = = = 0,333 0, 75 0, 75 0, 75


x Se calculeaz matricea de apartenen folosind (d) din tabelul 5.7 e

69

Tabel 5.8 Exemplu. Matricea de apartenen


A i \ Cj A1 (Saga) A2 (ContabSQL) A3 (EasyCont) A4 (CielConta) Kj C1 0,464 1,000 0,294 0,276 1,385 C2 0,424 1,000 0,276 0,276 1,286 C3 0,619 1,000 0,619 0,383 1,440 C4 0,593 0,352 1,000 0,352 1,565 Suma 2,101 3,352 2,189 1,288 Clasament III I II IV

n final alternativa candidat cea mai bun este produsul software de contabilitate ContabSQL.
BIBLIOGRAFIE

1. [LUN03] Lungu, I., Sabu, G., Velicanu, M. .a. Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti, 2003 2. [BOB02] Bob, C. A. Sisteme informatice n comer, Editura ASE, Bucureti 2002 *** 1. [AUGxx] http://mis.aug.edu

70

TESTE DE EVALUARE

1. Ca urmare a studierii mediului n care funcioneaz un sistem informatic de contabilitate se vor elabora dou modele: a. modelul contextual i modelul logic; b. modelul resurselor i modelul documentelor; c. modelul fizic i modelul logic. 2. Pentru a fi analizat, un sistem se poate descompune dup mai multe criterii cum ar fi: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 3. ntocmii diagrama simplificat de flux a documentelor n cazul unui punct de vnzare care elibereaz numai bonuri de cas. 4. ntocmii diagrama detaliat de flux a documentului factur n cazul n care facturile sunt emise prin intermediul unui calculator. 5. Dai cteva exemple de stocuri de date manuale, altele dect cele enumerate mai sus: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 6. Pentru construirea modelului MLD n cazul unei uniti de nvmnt public, determinai entitile de interes pentru contabilitate. 7. Schiai modelul entitate-asociere n cazul unui aviz de expediie. 8. Paii elaborrii modelului fizic al sistemului de contabilitate existent: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 9. Dai cteva exemple care pot fi folosite pentru a stabili gradul de pregtire a unei uniti economice pentru implementarea unui sistem informatic de contabilitate nou. _____________________________________________________________ _____________________________________________________________ ____________________________________________________________

71

TEMA 6. SECURITATEA I CONTROLUL SISTEMELOR INFORMATICE DE CONTABILITATE


CONINUT 6.1. Securitatea i valoarea informaiei 6.2. Sursele de riscuri 6.3. Auditul sistemelor informatice de contabilitate REZUMAT

Sistemele informatice de contabilitate funcioneaz ntr-un mediu n care conine surse de riscuri care trebuie studiate cu atenie pentru a se lua msurile de siguran i control care se impun astfel nct funcionarea sistemului s se realizeze corect.
OBIECTIVE

Tema propus are ca scop asimilarea unor cunotine referitoare la: - problemele legate de securitatea; - riscurile asociate mediului sistemului informatic de contabilitate; - auditul sistemului informatic de contabilitate.
6.1 SECURITATEA I VALOAREA INFORMAIEI

Valoarea unui produs software de contabilitate se poate exprima din dou puncte de vedere: al clientului ca suma maxim de bani pe care un client este dispus s o plteasc n schimbul produsului informatic, lund n considerare caracteristicile sale calitative, conjunctura relaiei cerere-ofert i preurile produselor similare ale concurenilor; al productorului ca suma minim a costurilor de producie. Ca urmare putem spune c valoarea unui sistem informatic de contabilitate este o caracteristic greu de cuantificat. A da valoare contabil unui ntreg sistem informatic este o problem dificil chiar i pentru contabili. Dei bunurile intangibile sunt incluse n balanele contabile, nu exist metode exacte de a le da o valoare bunurilor bazate pe tehnologie att din motive subiective, intangibile, ct i obiective, cum ar fi: valoarea nu se suprapune exact peste preul de achiziiei sau costurile de dezvoltare ale unui sistem informatic; percepia valorii unui aceluiai sistem informatic depinde i difer de la un utilizator la altul; valoarea depinde foarte des de criterii cum ar fi: rapiditatea cu care este obinut, oportunitate i relevana ei; informaiile interne ale unei uniti economice nu se pot testa pe pia.
72

Stabilirea unei valori a ntregului sistem informaional devine o preocupare atunci cnd trebuie nlocuit sau extins. n practic, de obicei, nu se face nici o analiz imediat dup implementarea sistemului nou, pentru a se verifica mbuntirile aduse de ctre acesta la nivelul valorii informaiei. Exist multe activiti pentru care securitatea i controlul sunt foarte importante1, de exemplu: serviciile bazate pe rspunsul imediat ctre consumator (de exemplu, dac un client al unei bnci face o tranzacie folosind un terminal sau Internetul, va dori s vad instantaneu modificrile din cont chiar dac tranzacia se face de fapt a doua zi); utilizarea unei baze de date centralizat (cum ar fi urmrirea traseului unui colet potal la nivel naional); utilizarea sistemelor informatice n procese care pot afecta sigurana i sntatea populaiei (de exemplu monitorizarea din centralele nucleare); lucrul ntr-un domeniu n care rspunsul trebuie dat n timp real (de exemplu, monitorizarea bursei de ctre broker-i); monitorizarea i controlul traficului (n aeroporturi, pe strzi etc.). Afacerile se desfoar n condiii de risc, dar aceasta nu nseamn c sunt binevenite alte riscurile noi. Tehnologia informaiei, implicat n cam toate ariile unei afaceri, i-a demonstrat n timp fragilitatea: a introdus incertitudini noi i riscuri noi, s-a dovedit a fi sensibil la erori, incidente, fraude i alte tipuri de atacuri cu impact negativ nu numai asupra activitii unei uniti economice dar i, de multe ori, asupra succesului n afaceri a acesteia. i totui, chiar i n aceste condiii de nesiguran, afacerile au devenit tot mai dependente de tehnologia informaiei. Securitatea calculatoarelor a fost gndit iniial pentru pstrarea informaiilor secrete din domeniul militar. n lumea afacerilor securitatea calculatoarelor a ptruns ulterior, dup ce afaceritii au ajuns la concluzia c nu doreau ca, nici ntmpltor nici cu intenie, propriile sisteme s fie deschise spre exterior i nici ca datele s fie distruse sau alterate din interior. Modelul de securitate militar (vezi figura 6.1) este unul construit pe patru nivele i rspunde unor exigene mari de securitate. Pornind de la acest model, ntr-un sistem informaional mai puin rigid se pot implementa diverse alte modele pe mai multe nivele, cu diverse grade de securitate, n funcie de natura, dimensiunea i rigoarea stabilit de ctre conducere.

Hawker, A. Security and Control in Information Systems: A Guide for Business and accounting, pagina 17 73

Top secret

Securitate nalt

Secret

Confidenial

Neclasificat

Securitate sczut

Figura 6.1 Modelul militar al securitii. Sursa: [HAW00], pagina 4

n mediul economic este foarte important ca modificarea datelor s nu se fac n mod neautorizat i nici ca datele s ajung la persoanele i/sau companiile nepotrivite1 (de exemplu, la posibilii concureni). Urmrirea securitii sistemului informatic de contabilitate (a posibilelor fraude, a integritii i acurateei datelor) se poate face n dou moduri: - prin jurnalul operaiunilor: fiecare operaie se salveaz ntr-un jurnal al operaiilor care nu permite dect adugarea unor date de genul: utilizator, data calendaristic, ora, operaia i toate datele despre operaia efectuat (de exemplu: suma, nume i numr al actului, beneficiar). Acest jurnal se poate folosi n situaii diverse cum ar fi pierderea complet sau parial a datelor. Jurnalul poate fi util i pentru nivelul de conducere care poate obine informaii nonfinanciare cum ar fi: urmrirea exact a activitii fiecrui contabil, calcularea timpii alocai operaiilor etc.; - prin separarea sarcinilor: sarcinile se distribuie distinct contabililor care se specializeaz n lucrul cu anumite operaii, cum ar fi ncasrile. Obiectivele securitii i controlului sistemelor informatice enumerate de Andrew Hawker2 sunt: protejarea secretelor, acurateea datelor, prevenirea falsificrii, pstrarea dovezilor despre operator, respingerea atacurilor, pstrarea cronologic a accesrii autentificate, asigurarea supravieuirii datelor, maximizarea posibilitilor de audit. Se presupune c toate unitile economice urmresc s aib ndeplinite obiectivele securitii i controlului. Trebuie fcut observaia c
Hawker, A. Security and Control in Information Systems: A Guide for Business and accounting, pagina 4 2 Andrew Hawker Security and Control in Information Systems: A Guide for Business and accounting, pagina 5 74
1

atingerea acestor obiective este foarte important pentru organizaiile care manipuleaz date cu caracter personal, date care trebuie s rmn confideniale pentru mediul extern al organizaiei.
graniele organizaiei

cereri de acces interne

controlul accesului

control automat

cereri de acces externe

Figura 6.2 Autorizarea accesului ntr-un sistem informatic Sursa: [HAW00], pagina 6

Implementarea unui model de securitate n cadrul unui sistem informatic de contabilitate presupune identificarea locului/locurilor n care controalele se pot aplica n mod automat sau parial automat. Aceasta implic stabilirea unor granie virtuale n jurul unor componente i activiti ale sistemului informatic. Ideal este ca toate sistemele informatice ale unei uniti economice s se gseasc n interiorul acestor granie. n practic s-ar putea s existe i n afara granielor aa c se impune verificarea acestora atunci cnd se face accesarea zonelor cu control intern automat (vezi figura 6.2). Ca urmare a verificrii se poate obine autorizaia de acces n sistemul informatic de contabilitate. n interiorul sistemului se vor aplica procedee de control n funcie de modul de urmrire a securitii (prin jurnal sau prin separarea sarcinilor). Delimitarea prezentat n figura 6.2 asigur faptul c se poate determina de unde provine o ameninare, adic din interiorul sau exteriorul organizaiei. Importana controlului i protejrii informaiei pornete din faptul c informaia are valoare. ntr-un mediu concurenial, dac informaia este de importan mare pentru rivali, informaia devine una care trebuie protejat i i se va aplica un nivel de securitate nalt. Dac informaia este de valoare mic, cum ar fi copia unei chitane eliberat pentru o persoan fizic, i se va aplica un nivel de securitate sczut.
6.2 SURSE DE RISCURI

Toate unitile economice trebuie s fac evaluarea complet a riscurilor i s implementeze controale interne adecvate pentru a putea stabili programe de management al riscului. Tipurile i severitatea ameninrilor cresc odat cu dependena afacerilor de sistemele informatice. Aceasta se ntmpl din motive cum ar fi: nivelul de operare multe sisteme informatice funcioneaz la nivel naional sau internaional. Astfel dac sistemul informatic
75

al unei bnci devine neoperaional, s-ar putea s apar probleme la nivel naional; viteza viteza de lucru i cea transmitere au crescut astfel c fiiere mari pot fi distruse, copiate sau transmise aproape instantaneu; inovaia tehnic tehnologiile noi modific regulile de baz dar mult lume nu le nelege att de bine nct s le foloseasc n siguran, putndu-se efectua operaii despre care nu se tie c sunt riscante. Pe de alt parte, bunii cunosctori ai tehnologiilor informaionale i pot folosi talentele pentru a produce daune fie direct la locul de munc fie prin ptrunderea din exterior (de exemplu, prin intermediul unei reele); cauze ascunse de multe ori e greu de descoperit cauza care a stat la baza producerii unei daune (de exemplu efectuarea unei tranzacii bancare duble n condiiile plii unei sume cu ajutorul unui card, blocarea unui card ntr-un terminal chiar dac s-au introdus corect datele de identificare). n continuare vom trata cteva dintre sursele de riscuri.
Sistemele de operare

Sistemele de operare sunt necesare pentru a face toate componentele sistemului de calcul s funcioneze corect i eficient. De obicei un calculator se cumpr cu sistemul de operare gata instalat i care deja are faciliti sub form de programe utilitare, de asistare i de mentenan a echipamentelor hardware. O atenie deosebit trebuie acordat modului n care se realizeaz protecia contra accesului neautorizat. Implicit sistemele de operare i aplicaiile pun la dispoziia utilizatorului drepturi depline de acces; aceste drepturi trebuie modificate conform necesitilor de securitate ale utilizatorului. Un alt aspect care reclam atenie e acela al utilizatorilor uitai adic un nume de utilizator cu o parol care se pot folosi de ctre productor sau de ctre persoana care a pus n funciune sistemul. Riscul este de accesare neautorizat cu drepturi de acelai nivel ca i ale unui administrator intern al unitii economice, pe care beneficiarii sistemului informatic de contabilitate nici nu l iau n considerare n cazul unei auditri a sistemului.
Sistemele de gestiune a bazelor de date

Sistemele de gestiune a bazelor de date, pe scurt SGBD, se compun dintr-o mulime de programe care se folosesc pentru definirea, interogarea, protejarea i manipularea unui volum mare de date. Bazele de date trebuie s fie protejate contra ameninrilor intenionate sau neintenionate, securitatea bazelor de date se refer la elemente de hardware i software, persoane i date1. Connolly consider c securitatea bazelor de trebuie asigurat corespunztor pentru a preveni situaii ca:

Connolly, T., Begg, Carolyn, Strachan, Anne Baze de date. Proiectare. Implementare. Gestionare, pagina 508 76

furtul i frauda (frauda poate apare ca urmare a introducerii intenionate de date eronate, de modificare a documentelor justificative etc.); pierderea confidenialitii sau pierderea caracterului privat este foarte important, pstrarea secretului despre date, mai ales despre acelea care intereseaz concurena; pierderea integritii sau pierderea disponibilitii pierderea integritii datelor are ca rezultat apariia unor date care nu corespund documentelor justificative; pierderea disponibilitii se refer la faptul c datele devin inaccesibile (fie bazele date s-au corupt din varii motive, fie a avut loc un eveniment hardware). Daunele pot fi tangibile (cum ar fi deteriorarea unei componente hardware) dar i intangibile (cum ar fi pierderea ncrederii unui ter ca urmare a furtului datelor).
Produsele software

Produsele software sunt folosite pentru ndeplinirea funciilor afacerilor. Multe dintre acestea (i care pot fi cumprate pe loc cu o funcionare complet) au fost concepute pentru a ndeplini sarcini generale. Dintre acestea amintim editoarele de documente (Microsoft Word, WordPerfect), programele de calcul tabelar (de exemplu Microsoft Excel, Lotus 1-2-3), i de baze de date (Microsoft Access, SQL Server, Oracle). Alte aplicaii au fost create pentru a ndeplini funcii specifice n domenii variate (transferuri bancare online, aplicaii de design pe computer pentru asistare n proiectare etc.). Contabilitatea se poate ajuta att de programe dedicate numai contabilitii ct i de programe integrate ntr-un sistem complex numit ERP1. Un sistem ERP este o soluie software ale crei elemente sunt integrate ntr-o platforma comun. Sistemele ERP actuale realizeaz integrarea tuturor funciilor de conducere ale unei uniti economice, (pornind de la planificare, la realizarea gestiunii financiarcontabile, a resurselor umane i terminnd cu gestiunea relaiilor clienii i partenerii de afaceri). Un sistem ERP permite, prin simulare a activitilor i prin caracterul flexibil i dinamic al aplicaiilor, s se realizeze previziuni, analize calitative i integrarea cu tehnologiile noi de genul e-business i ecomunicare. Exemple de sisteme ERP: Senior.ERP Suite, mySAP ERP, BOrg. Fiecare din aceste aplicaii poate sau nu s aib elemente de verificare concepute pentru a mpiedica accesrile neautorizate. Pentru o evaluare a unor verificri competente ale acestor aplicaii este necesar dobndirea unor cunotine detaliate ale caracteristicilor de verificare a fiecrei aplicaii folosite n mod curent ntr-o unitate economic.
Alte surse de riscuri

Multe sisteme informatice au prevzute mecanisme de control care sunt proporionale cu gradele riscurilor asociate cu funciile ndeplinite de ctre sisteme. De exemplu, tranzaciilor financiare li se asociaz un grad de

Enterprise Resource Planning sistemele de planificare a resurselor unitii economice 77

risc mare, un mecanism slab de control poate avea ca urmri furtul datelor celor implicai n tranzacie, alterarea datelor tranzaciilor i altele. Viruii, n toatele formele lor, sunt un risc care apare n situaii ca: - un angajat lucreaz cu o dischet pe care o folosete i afara unitii economice; - deschiderea e-mail-urilor cu ataamente; - vizitarea unor pagini de Internet i acceptarea execuiei unor componente software (script, fiiere executabile, ActiveX etc.) despre originea cruia nu exist date care se pot verifica i care pot avea un caracter distructiv i/sau de culegere a datelor confideniale.
Tabel 6.1 Riscurile asociate unor aciuni
Risc Aciune Utilizarea mijloacelor de acces ale unei alte persoane Modificarea, copierea, tergerea neautorizat a datelor Alterarea programelor Politicile i procedurile necorespunztoare care permit ieiri confideniale pentru un nivel de securitate nalt Interceptarea convorbirilor Accesul neautorizat sau ilegal Crearea unei bree n sistem Furtul de date, programe i echipament Permiterea unui acces prea larg Conflictele de munc Pregtirea necorespunztoare a personalului Vizualizarea i divulgarea neautorizat a datelor Alterarea datelor datorit ntreruperilor de energie sau supratensiunii Calamiti Introducerea de virui Conectarea la Internet Furtul i frauda Pierderea confidenialitii Pierderea caracterului privat Pirederea integritii Pierderea disponibilitii

* * * * * * * * *

* * * *

* * * * * * *

* * * * * * * * * * * * * * * * *

* * *

* *

Criminalitatea informatic a cunoscut o cretere spectaculoas n ultimii ani. Criminalitatea informatic face parte din crima organizat pentru c: s-a extins la nivel internaional, activitile ilicite se pot controla de la
78

distan (prin intermediul Internetului) i gruprile sunt bine structurate i organizate. Persoanele implicate n criminalitatea informatic se desemneaz ca fiind infractori informatici sunt persoane care nu trebuie s aib cunotine solide de informatic, pot fi n slujba celor care au resurse pentru construirea echipamentelor ajuttoare (bancomatele false). Infractorii informatici folosesc ceea ce este mai nou n domeniu (sisteme, posibiliti, modaliti de plat speciale) pentru a obine date personale cum ar fi nume de utilizator i parole, numere de cont bancar, numere de carduri, coduri PIN etc. Fraudele cu crile de credit cresc ca pondere n criminalitatea informaional. O posibil explicaie este aceea c banii se obin mai repede i mai uor dect din alte tipuri de activiti ale crimei organizate Nu este nevoie ca infractorul informatic s ntre n posesia fizic a cardului. Prin compromiterea bancomatelor (prin folosirea camerelor de luat vederi, feelor false de bancomat, tastaturi false, dispozitive pentru fanta cardului etc.) se fur informaia despre card i se scriu aa numitele blankuri care se folosesc apoi ca i cnd ar fi cardurile originale. Conectarea la Internet, pe lng beneficii, a nsemnat i expunerea n faa unor riscuri ce in de criminalitatea informatic. Furtul informaiilor despre clienii unui magazin online, este o primejdie la care se expun toi vnztorii i clienii care folosesc Internetul pentru tranzacii. Tabelul 6.1 prezint cteva dintre riscurile asociate unor aciuni ([CON01, paginile 510-511) care pot avea loc pentru sursele de riscuri descrise mai sus.

6.3 AUDITUL SISTEMELOR INFORMATICE DE CONTABILITATE

Auditul este partea contabilitii n care tehnologia informaiei i gsete o aplicabilitate deplin. Rezultatele financiare tradiionale ale auditului au devenit o industrie matur i se bazeaz pe legislaia de profil i pe standarde elaborate la nivel global (ISA1), cum ar fi: ISA 401 Auditul ntr-un mediu cu sisteme informatice (Auditing in a Computer Information Systems Environment), ISA 1008 Evaluarea riscurilor si controlul intern caracteristici i considerente ale sistemelor informatice (Risk Assessments and Internal Control CIS Characteristics and Considerations), ISA 1009 Tehnici de audit asistate de calclator (Computer-Assisted Audit Techniques). Standardele stabilesc modul n care trebuie s se fac operaii ca preluarea i prelucrarea datelor, nregistrarea n conturi. nregistrarea modificrilor ce se produc n bilan ca urmare a tranzaciilor incheiate de societate. Se stabilete i verificarea urmtoarelor aspecte: absena documentelor de intrare, justificative; absena probelor materiale de derulare a tranzaciilor; absena posibilitilor de accesare i/sau vizualizare a rezultatelor prelucrrii. Obiectivele generale si procesul de audit al situaiilor financiare nu difer structural de etapele i procedurile comune. Excepiile apar cnd
1

International Standard on Auditing, http://www.ifac.org/iaasb/ 79

auditorul dorete cunoaterea programelor de contabilitate, nelegerea profund a funcionrii acestora pas cu pas, precum i a modului n care acestea rspund cerinelor utilizatorului. Intrrile de baz pentru contabilitate sunt tranzaciile msurate n uniti monetare. O urm-audit a tranzaciilor contabile pstrat ntr-un sistem al unitii economice permite utilizatorilor informaiei s urmreasc fluxul datei de-a lungul sistemului. Figura 6.3 este un exemplu de o asemenea urm care prezint n paralel un ciclu contabil al unitii economice care ncepe cu datele tranzaciei reflectate din documentele de intrare justificative i se termin cu producerea, ca ieire, a extraselor de cont sau al altor rezultate financiare. Contabilitatea preia datele relevante de intrare din documentele justificative i arhiveaz documentele pentru o utilizare ulterioar n scopuri de control i auto-control (de exemplu, verificarea cursului valutar pentru o anumit intrare n jurnal). Un sistem informatic contabil care are o urm-audit bun permite, de exemplu, unui manager s urmreasc datele oricrui document justificativ, prin prelucrare pn la locul n care s-a obinut raportul de ieire. De asemenea sistemul poate s permit unui contabil urmrirea datelor financiare pornind de la balanele contabile napoi spre documentele de intrare originale care au determinat tranzaciile care au influenat balanele. Ca exemplu, o factur de intrare trebuie s poat fi urmrit prin intermediul urmei-audit de la conturile clientului pn la contul debitor i contul creditor. Similar, un contabil poate verifica balanele pentru conturile creditoare i debitoare prin examinarea tranzaciilor i a documentelor de intrare originale. Printr-o urm-audit dezvoltat eficient, un contabil poate urmri datele de-a lungul ntregului sistem; aceast urmrire fiind posibil dac oamenii dintr-un sistem pot nelege pe de-a ntregul metodele i procedurile pentru acumularea i prelucrarea datelor. Un rezultat este c se poate reconstrui de ctre contabili modul n care sistemul manevreaz datele. Un sistem computerizat bine proiectat poate mbunti urma-audit prin furnizarea unei liste, a mulimii tranzaciilor i a balanelor conturilor nainte i dup ce tranzaciile au modificat conturile. Pentru unitile economice care vor s-i dezvolte un sistem de control intern eficient, urmele-audit sunt elemente importante ale acestui control.
Intrri Documente de intrare Prelucrarea tranzaciilor Jurnal Ieiri

Registru Fiiere ale documentelor surs Balana provizorie


Figura 6.3 Exemplu de urm-audit financiar Sursa: [MOS03], pagina 10

Extrase de cont sau rapoarte externe

Auditorii interni trebuie s examineze componentele unui sistem informatic (hardware, software), mentenana acestora i alte caracteristici
80

prin care s se poat determina care dintre asemenea costuri s-au nregistrat corespunztor n balanele contabile. De exemplu, componentele hardware i cele software trebuie capitalizate i amortizate n perioade de timp care depesc cu mult durata de funcionare, perioada de via n care sunt utile funcionrii sistemului informatic de contabilitate iar costurile prepltite pentru ntreinere pot fi clasificate ca bunuri i cheltuite numai n perioada pentru care s-au fcut plile. Dac o unitate economic este mic i are numai unul sau doi auditori, aceste persoane trebuie s aib cunotine despre contabilitate, finane i altele. Acest tip de auditor este unul care auditeaz tratarea contabil a costurilor asociate cu calculatoarele i nu va fi un auditor specializat n auditul sistemelor informatice ([CHA03], pagina 126). Dac unitatea economic este mare i are un departament de audit intern, auditul se poate face de ctre unul sau mai muli auditori cu studii n diverse domenii. n acest caz, pentru un audit profund, se vor examina ntregul proces, auditul costului echipamentelor hardware i/sau software fiind doar o parte a auditului. Oricare ar fi modul de control intern, costurile asociate cu echipamentele hardware i cu cele software trebuie s se conformeze normelor legislative. Investitorii i creditorii care folosesc rezultatele financiare se pot folosi i de alte surse dect auditul pentru informaii care s i ajute n luarea deciziilor. Aceasta se ntmpl din cauza c rezultatele financiare de audit deseori nu devin disponibile ntr-un timp oportun.

BIBLIOGRAFIE

1. [CHA03] Champlain, J. Auditing information systems, John Wiley & Sons, 2003 2. [CON01] Connolly, T., Begg, Carolyn, Strachan, Anne Baze de date. Proiectare. Implementare. Gestionare, Editura Teora, Bucureti 2001 3. [HAW00] Hawker, A. Security and Control in Information Systems: A Guide for Business and accounting, Routledge 2000 4. [ION07] Ionescu, Gh. Nore de curs pentru uzul cursanilor de la coala doctoral, Timioara 2007 5. [MOS03] Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. Core Concepts of Accounting Information Systems, John Wiley & Sons Ltd, 2003 *** 1. http://www.ifac.org/iaasb

81

TESTE DE EVALUARE

1. Valoarea unui produs software de contabilitate se poate exprima din punctul de vedere al clientului ca: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 2. Specificai cteva aspecte care nu se pot cuatifica pentru a da o valoare exact bunurilor bazate pe tehnologie: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 3. Securitatea i controlul sunt importante pentru activiti ca: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 4. Obiectivele securitii i controlului sistemelor informatice sunt: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 5. Specificai cteva surse de riscuri: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ 6. Specificai caracteristicile urmei-audit ntr-un sistem informatic de contabilitate: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________

82

S-ar putea să vă placă și