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
1

DEX. Dicionarul explicativ al limbii romne, Editura Univers Enciclopedic, Bucureti,

1998
7

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.
1

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

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
1

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

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

Personal

Aprovizionare

Gestionarea
comenzilor i
contractelor de
aprovizionare

Magazii,
gestiune
stocuri

Baze de date
sau fiier(e)
de furnizori i
clieni

Comenzi,
contracte de
desfacere

Producie

Contabilitate

Magazie
produse
finite
Cheltuieli
materiale
Studii de pia

Calcul cost-pre

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
1

Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. Core Concepts of Accounting

Information Systems
12

(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.

Documente
justificative

Planul
contabil
Operaii
contabile

nchideri i
alte prelucrri
periodice

Note
contabile

Jurnale
Figura 1.4 Activitile unui sistem informatic

Se impun cteva observaii referitoare la figura 1.4:

13

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

Registrul
jurnal

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
1

Boksenbaum, L. Informatic de gestiune, Editura Economic, Bucureti 2002, pagina

230
24

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

Camion
Tonaj

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
proiectare

Modele de
analiz

Vederea
logic

Vederea
cazurilor de
utilizare
Diagrama
cazuri de
utilizare

Vedere
static

Vedere
dinamic

Modele de
proiectare

Vederea
componentelor

Vederea
concuren

Diagrama
componentelor

Diagrama
partajrilor
hardware

Cazuri
de test
Diagrama
subsistemelor

Diagrama
claselor

Diagrama
obiectelor

Diagrama
activitilor

Diagrama
stri+
tranziii

Diagrama
colaborrilor

Fiiere
de test

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

Reprezentare
(2)

a)

Nume clas

39

b)

Nume clas
Proprieti

Nume clas

Nume clas

c)

Proprieti

d)

Operaii

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

Nume caz
utilizare

Caz utilizare

Nod

Nod

Colaborare

Nume colaborare

(1)

(2)
Nume component

Component
Elemente comportamentale

Nume

Interaciune
Stare

Nume stare

Relaii
40

Dependen
0..1

Asociere

rol

rol
Clasa 1
1

Agregare
*
Clasa 2

Alte elemente
Pachet

Nume pachet

Nume not

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..*

1.. *

efectueaz

efectuat

OPERAIE
BANCAR

conine

compune

0..*

1..*

INSTRUMENT
PLAT

CAMBIA

ORDIN DE
PLAT

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

FACTURA

J
CUI
Sediul
Judetul
Contul
Banca

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

TM ABA

J: 35/405/1999
CUI: 16257325
Sediul: Oravia
Judetul: Timi
Contul: RO56008978
Banca: BRLocal

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

actor

numele cazului
de utilizare

caz de
utilizare

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
intocmete bonul
de cas

client

ghieu
facturare

ntocmete
factura

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.

Ciorn

datele sunt
corecte

Emis

s-a achitat
contravaloarea facturii

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

Achitare
parial

Refuzat la
plat

ncasat

ncasat
parial

Anulat

A
Operare

nchidere

Operat

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

operare - n
cas

nchidere

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

Nencasat

Deschis
ncasare

Emitere

Achitare

ncasat
operare + n
cas
A

nchidere

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

[comand
acceptat]

Emite
factura

Achit
comanda

nchide
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

GESTIUNE
RAPOARTE

MODUL RAPORTARE

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

Lista preurilor

Factur
(exemplarul 1)

Contabilitate

Cumprare

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
-1-

Utilizare
-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

Utilizare
Procese

flux

Flux de date

entitate

Entitate

entitate

Entitate duplicat

et.

stoc

Stoc de date

et.

stoc

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

M2

Stocuri produse

1.1

Sold plat

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

Linie intrare

Furnizor

Intrare

Produs

Linie factur

Factur

Livrare

Linie livrare

Linie comand

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

Comand

Beneficiar

Matrice entitate exemplu

*
*

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

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

Entiti

M1 Stocuri produse

Produs

M2 Sold de plat

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

Entiti
Intrare

conine
face parte din

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
Ci

Aj
A1
A2
...
Am

C1

C2

...

Cn

a11
a21
...
am1

a12
a22
...
am2

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

a1n
a2n
...
amn

65

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
Ci

C1

C2

...

Cn

P1
P2
...
Pp

n11
n21
...
np1

n12
n22
...
np2

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

n1n
n2n
...
npn

K1= ni1

...

Km= nin

Pj

i =1

K2= ni 2
i =1

i =1

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)

C2
Plata n rate
(criteriu de
maxim)

C3
Instruire
(criteriu de
maxim)

C4
Interfaa
(criteriu de
maxim,
intangibil)

350

0,25

0,5

0,5

156

0,75

0,75

0,25

1350

0,5

0,75

2200

0,25

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

P1
P2
P3
P4
P5
P6
P7
P8
P9
Kj

(d) K j =

( N ) max = 36
j

Nj

Nj

C1
4
4
3
4
4
3
1
2
1
26

C2
1
2
4
4
4
4
1
4
4
28

C3
4
4
4
4
4
1
2
1
1
25

C4
3
3
3
4
2
4
1
1
2
23

1,385

1,286

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

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 11 = 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 23 = X 24 = 1

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

Securitate nalt

Top
secret

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
1

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

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
Furtul
i frauda

Pierderea
confidenialitii

Pierderea
caracterului
privat

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

*
*
*
*
*

*
*
*
*
*

*
*
*
*
*

Risc
Aciune

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

*
*

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

Ieiri

Jurnal

Registru
Fiiere ale
documentelor
surs

Balana
provizorie

Extrase de cont
sau
rapoarte externe

Figura 6.3 Exemplu de urm-audit financiar

Sursa: [MOS03], pagina 10

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

http://www.conta-conta.ro/

http://www.conta-conta.ro/index.php?page=tarife