Contabilitatea a fost si este dependenta de dezvoltarea economica. De aceea de -a lungul [615850]

Introducere

Contabilitatea a fost si este dependenta de dezvoltarea economica. De aceea de -a lungul
timpului contabilitatea parcurge un proces de modernizare accentuat in Europa, odata cu
dezvoltarea batran ului continent.
Sub influenta schimbarilor intervine in mediul economic, contabilitatea va parcurge la
randul ei drumul de la o forma primara catre una complexa, capabila sa satisfaca cerintele tot mai
diverse ale utilizatorilor informatiei contabile.
Contabilitatea din totdeauna a fost considerata o stiinta sociala, deoarece ea studiaza unele
din activitatile pe care le desfasoara oamenii si care influenteaza in mare masura existenta lor.
In contextul evolutiei tehnologiilor informationale si a comunicatiilor, nu mai ex ista astazi
practic domeniu de activitate care sa nu recurga la utilizarea calculatoarelor intr-un sens foarte
restrans, sau sa aibe implementate diferite sisteme informatice pentru executarea operatiunilor de
baza sau pentru sprijinirea deciziilor .
“Sist emul poate fi definit ca o entitate alcatuita din doua sau mai multe componente sau
subsiteme, care interactioneaza intre ele pentru atingerea unui scop (obiectiv). Orice sistem este
caracterizat prin faptul ca este legat de mediul ambiant, ca are o anumit a structura, functioneaza
dupa anumite reguli si urmareste un anumit scop”
Orice sistem se constituie din intrari, prelucrari si iesiri. Pentru o unitate economica,
intrarile sunt reprezentate de resursele econimice pe care intreprinderea le utilizeaza in activitatile
sale; prelucrarile sunt procese prin care intrarile sunt trans formate in iesiri; iar iesirile sunt
reprezentate de bunurile si serviciile obtinute de intreprindere si pe care le schimba cu mediul sau.
Se urmareste ca principal obiectiv dezvoltarea unei intregi apl icatii Windows care va ajuta
departamentul de contabi litate a unei fime, care va gestiona facturile si produsele. Bineintele,
structura aplicatiei nu este una standard ea se poate modifica, se pot aduce imbunatatiri in functie
de nevoile clientului (contabilului). Insa, in lucrarea prezenta vom privi aplicat ia standard pentru
inrari iesiri de stocuri, facturi de vanzare si cumparare.
Aceasta aplicatie este de altfel conceptul incat sa poata fi folosit si de catre persoanele
neinitiate in domeniul contabil. In momentul introducerii datelor din documentele pri mare,
aplicatia de contabilitate genereaza automat inregistrarile contabile aferente, acestea putand fi
vizualizate imediat prin diferite registre contabile.
Asadar, aplicatia poate fi descarcata sub forma unui executabil, pentru a fi functionala este
nevoie si de structura bazei de date care sa ruleze pe un server de baza de date.
Din punct de vedere al continuitatii acesteia, se urmareste amplificarea functionalitatilor.
Astfel se va acoperii o gama larga de cerinte, iar in viito actionarii se vor b ucura de o varietate de
extensii (rapoarte). Proiectul Prezentat reprezinta doar un prototip sau cadrul amanuntit a versiunii
finale care a fost initial conceputa.
Lucrarea de fata este alcatuita din patru capitole si prezinta rand pe rand cerintele unui
sistem existent, va fi realizata analiza domeniului ec onomic incadrat, tehnologiile si limbajele
utilizate in crearea produsului finit, si nu in ultimul rand implementarea sistemului sau punerea in
functiune a aplicatiei rezultate, rezultand totodata si im pactul economic.

Descrierea problemei economice
Specificarea textuala a sistemului existent

Pentru inceput trebuie specificat ceea ce se doreste a fi creat pentru a ajuta departamentul
de contabilitate din cadrul unei companii intr-un mod pozitiv. Se doreste crearea unei aplicatii
Windows care va ajuta la gestionarea facturilor si a stocurilor unei companii, care are ca scop
introducerea facturilor in urma cumpararii sau vanzarii de produse.
Lucrarea de fata prezinta in primul capitol analiza sistemului existent utilizand diagramele
limbajului UML.
Aceasta aplicatie windows trebuie sa ruleze pe orice sistem de operare cu baza de date
locala sau la baza de date care este legata la retea. Descrierea tehnologiilor ce vor fi folos ite pentru
aplicatie specifice acestei lucrari vor fi prezentate in cel de -al doilea capitol. Acest capitol contine
detalii despre resursele necesare pen tru realizarea acestei lucrari. Prin tehnologiile utilizate se
aplica notiuni precum intranet , aplicati i windows, C# si baze de date SQL.
In cel de al treilea capitol vom descrie analiza si proiectarea sistemului informatic,
prezentarea cerintelor acestuia, proiectarea noului sistem informatic. In acest capitol vom prezenta
modul in care au fost utilizate resursele pentru a se ajunge la produsul finit si vom descrie utilitatea
fiecarei aplicatii utilizate. In alegerea arhitecturii aplicatiei am urmarit facilitatea extinderii
acesteia cu usurinta de catre un utilizator incepator dar si oferirea unei game vaste de posibilitati
unui developer experimentat pentru a o dezvolta in mai multe directii.
Aplicatia informatica va fi prezentata in capitolul patru, in care se explica pasii ce trebuie
parcursi pentru rea lizarea si functionalitatea acesteia.
Aplicatia creata va fi utilizata strict doar de membrii angajati din departamentul de
contabilitate al companiei. Nu este destinata clientilor sau altor parti externe. In momentul
deschidetii aplicatiei, ca prim pas s e va dori autentificarea utilizatorului astfel incat , daca
utilizatorul nu detine un cont, va avea posibilitatea de a se adresa administratorului pentru crearea
unui nou cont.
Noul cont creat de catre administrator nu nu trebuie ca coincida cu niciunul dintre conturile
existente. Administratorul are dreptul sa dea rolul unui nou cont de administrator sau de utilizator
pentru a se face diferentierea intre conturi. Vor exsita mai multi angajati cu drepturi de utilizator
si doar angajatii cu functii mai inalt e cu drepturi de administrator.
Utilizatorii aplicatiei vor putea urmarii stocul marfii la zi, vor intocmii documente de
vanzare si de cumparare si au posibilitatea de a actualiza stocul marfii.

Cazuri de utilizare

Unul dintre aspectele importante in integrarea si definirea cerintelor unui sistem este acela
al interactiunii dintre sistem si utilizatori sau alte componente externe.
Modelul cazurilor de utilizare (“Usr cases”) a fost introdus de Jacobson in 1992. El a fost
adoptat intr -o masura remarcabila, devenind un instrument folosit in mod frecvent in specificarea
sistemelor informatice.

Element Descriere Notatie
Actor Un actor este, in principiu, un utilizator al sistemului, dar poate
fi si un alt sistem informa ic care interactioneaza cu sistemul
analizat.

Use Case Use Case -urile se reprezinta sub forma unei elipse in interiorul
careia este scris numele Use Case -ului respectiv

Asociere Asocierea este utilizata pentru a indica legatura dintre un Actor
si un Use Case, in sensul ca acel actor participa intr -un fel
oarecare in acel Use Case.

Diagrama ofera o imagine de ansamblu asupra principalelor activitati desfasurate in cadrul
unei institutii. Actorii au fost intitulati “Administrator” si “Utilizator”(contabil) , sunt cei care
beneficiaza si in acelasi timp efectueaza toate activitatile prezente in diagrama (fig.1) . Fiecare
dintre actiunile reprezentate in diagrama generala a cazurilor de utilizare vor fi reluate si prezentate
pe larg punan du-se in evidenta toate activitatile care le compun.
Actorul – Administrator – se ocupa de crearea contuilor de utilizator i si de administrarea
lor, reseteaza parola unui utilizator daca acesta a uitat parola, activeaza sau dezactiveaza activitarea
unui cont. Administratorul are si dreptul de a se loga la baza de date pentru a efectua salvarea de
baza de date zilnic sau de crearea unui job in sql pentru salvarea automata de baza de data la o data
si ora stabilita.
Actorul – Utilizator (contabil) – conform diagramei din Fig.1, odata cu deschiderea
programului de contabilitate introduce numele de utilizator si parola, in continuare urmeaza
preze ntarea cazuurile de utilizare pentru un utilizator. Poate vizualiza produsele deja existene,
poate modifica denumir ea produsului, cota de tva dar si pretul de vanzare, pretul de cumparare nu
il poate modifica deoarece acesta se modifica automat atunci cand se introduce f actura de
cumparare, poate sterge un produs deja existent sau poate adauga unul nou. Utilizarea cont urilor
contabile aici discutam de conturi de clienti, furnizori, conturi de casa sau de banca, utilizatoru
poate vizualiza toate conturi le existente poate modifica, adauga sau sterge un cont contabil, se
poate sterge doar daca pe acel cont contabil nu au fost introduse inregistrari (facturi). La rubrica
de tranzactii in partea de contabilitate utilizatorul poate adauga o tranzactie contabila noua, poate
modifica o tranzactie deja inregistrata sau o poate sterge definitiv, in partea de gestiune se pot
intro duce facturi primite de la furnizori sau emise pentru clienti, pentru acestea sunt drepturi doar
de vizualizare, nu se pot sterge sau modifica.

Fig. 1 Diagrama de utilizarea UML (creare proprie)

Utilizarea rapoartelor: – in raportul de stocuri utilizatorul (contabilul) poate vizualiza stocul
disponibil pentru un articol sau pentru toate articolele la o anumita data, utilizatorul are
posibilitatea de a printa raporul; – rapotul fisa de magazie ii returneaza utilizatorului tranzactiile
pe un anumi t produs intrari/iesiri dar si stocul final intr -un interval de timp selectat de utilizator; –
in raportul de balanta utilizatorul selecteaza data pentru emiterea raportului unde afiseaza rulajele
pe toate conturile la data selectata cu posibilitatea de af isare si printare.

Diagrama de clase

Diagrama de clase (Class diagram) este un tip de diagrama utilizata pentru descrierea
structurii statice, adica a entitatilor sau claselor existenete intr -un sistem. Acest tip de diagrama
este utilizat cel mai adese a de catre dezvoltatori pentru specificarea claselor dar poate fi foarte util
si pentru specificarea structurii unor sisteme sau subsistem dintr -un business real.

Elemente utilizate si notatiile lor sunt urmatoarele:

Element Descriere Notatie
Clasa O clasa este reprezentata printr -un dreptunghi cu trei
compartimente: in cel de sus se trece numele clasei, in mijloc
se trec atributele clasei iar jos se trec operatiile specifice
clasei.
Mostenire Nostenirea este o relatie care indica faptul ca o clas a
mosteneste caracteristicile unei clase parinte. Sensul sagetii
indica sensul in care se poate spune despre clasa copil ca este
o<-i>, sau este de tipul < -i> clasa parinte

Asociere Asocierea este o relatie generica intre doua clase. Aceste
relatii pot fi de tipu rile, pot definii si regulile numerice de
asociere (unul la unul, unul la mai multi, mai multi la mai
multi)

Dependenta Atunci cand o clasa de o alta clasa, in sensul ca utilizeaza acea
clasa ca si atribut al sau, se foloseste relatia de depen denta.

Agregare Agregarea indica o relatie de tip intreg -peste (se poate spune
despre clasa parinte ca are clase de tip copil). In aceasta relatie,
clasa copil poate exista si fara clasa parinte.

Compozitie Aceasta relatie deriva din agregare dar se utilizeaza atunci
cand o clasa copil nu poate exista decat in cazul existentei
clasei parinte.

Reprezentarea detaliata a unei clase, construita in etapa de analiza, precizeaza vizibilitatea
informatiilor din clasa, lista de paramentri a fiecarei ope ratii si tipul parametrilor. Regulile de
vizibilitate se aplica atat atributelor cat si operatiilor de clase si se refera la domeniul de acces
permis la un membru al unei clase. Fiecare nivel de vizibilitate este reprezentat printr -un simbol:
– Private ( -): accesibilitatea numai din interiorul clasei;
– Public (+): accesibilitatea la nivelul intregului sistem;
– Protected (#): accesibilitatea in arborele de mostenire;
– Package (~): accesibilitate din interiorul pachetului care contine clasa;

Folosirea diagramelor de clase:
a. In modelarea conceptuala (analiza orientata obiect), clasele corespund
conecptelor/obiectelor (entitatilor) din domeniul aplicatiei. Nu exista neaparat o legatura
directa cu clasele de obiecte utilizate in implementare si deci diagrama de clase n u face
parte din modelul structural al sistemului. De regula, nu sunt definite operatiile din clase
prin tipurile parametrilor si nici tipul atributelor. Diagrama de clase poate fi folosita in
modelarea conceptuala a unei baze de date, in modelul fizic al bazei de date clasele se
implementeaza prin tabele ale bazei de date.
b. Pentru specificarea software se pune accent pe interfata si nu pe implementare, adesea se
foloseste cuvantul “tip” in legatura cu interfata unei clase: un tip poate fi implementat de
mai multe clase si o clasa poate implementa mai multe tipuri.
c. In proiectarea de detaliu si implementare diagramele contin clase de obiecte intr -un limbaj
de programare, diagramele fac parte din modelul structural al sistemului.

Fig.2 Diagrama de clase (cre are proprie).

Detalierea claselor:
– Cont: c ontine atributele email, nume, nume utilizator(username), parola, prenume, rol si
operatorul salvare, aceasta clasa este utilizata pentru crearea de utilizatori in program.

– Produse: este clasa pentru crearea de noi produse, editarea, vizualizarea sau stergerea lor
si are urmatoarele atribure: cheie, cantitate, denumire suplimentara, denumire, numar(id),
pretul de cumparare, pretul ultimei cumparari, pretul de vanzare, sinteti c, tva (procentul de
tva cu care se cumpara sau se vinde acel produs, poate fi 5%, 9% sau 19% si unitarea de
masura dar si operatorii anuleaza sau salveaza. Un produs poate fi create doar de un
utilizator care are contul activ.
– Conturi: cu ajutorul clasei de conturi putem vizualiza, crea, edita sau sterge un cont , are
urmatoarele atribute: adresa, cheie, cod fiscal, cont bancar, cont principal (furnizor, client,
casa sau banca), denumire, email, fax, numar(id), observatii, oras, tara, telefon si operatorii
salveaza si anuleaza.
– Facturi: acesta clasa contine atributele: cantitate, produs, data, datele companiei(denumire,
adresa, cod fiscal, cont de banca), datele clientului sau furnizorului ( numele, adresa, email,
telefon, cont de banca, cod fiscal, numarul d e document si operatorii emitere si printare,
informatiile pentru produse sunt aduse din clasa produse si informatiile pentru
client/furniz or sunt aduse din clasa conturi.
– Stocuri: informatiile returnate sunt calculate din facturile de vanzare/cumparare em ise
anterior care in urma calcului afiseaza stocul disponibil la zi al produselor, contine
urmatoarele atribure : contitatea de iesire, cantitatea de intrare si stocul final.
– Raportul de stocuri: odata introduse atributele cheie produs si utilizand operator ul
genereaza va calcul si afisa stocul la zi al produsui, cu ajutorul operatorului printeaza
treimite informatiile afisate la imprimanta.
– Fisa de magazie: aceasta clasa afiseaza toate documentele de intrare si de iesire intr -un
interval de timp utilizand atributele cheie, data de la , data pana la si a operatoruli genereaza
va afisa raportul, operatorul printeaza va printa raportul.
– Balanta: are doar atribut ul data si operatorii genereaza si afiseaza, va afisa si printa un
raport cu sumele de pe facturile de intrare si de iesire pe fiecare client sau furnizor.

Diagrama de activitate (activity diagram)
a. Diagrama de activitate pent ru logarea -delogarea din aplic atie. Exista 2 ramuri de logare a
unui utilizator sau crearea de catre administrator si crearea unui cont de utilizator pentru
logarea in aplicatie. Logarea se poate face doar d e catre Administrator daca utilizatorul nu
are contul valid sau nu are cont, Ad ministratorul creaza un cont nou sau activaza contul de
utilizator daca este inactiv.

b. Diagrama de activitate pentru creare a unui nou cont de catre Administrator. Procedura din
baza de date verifi ca daca acel cont este existent, daca nu exista se completeaza datele
pentru cont si se creeaza, daca este deja un cont creat se verifica daca este activ sau incativ.

Diagrama de stare (State diagram)
a. Diagrama de stare a obiectuli factura. Se urmareste traseul al oricarui pr odus in general: se
deschide un nou document se trece un numar de factura, se alege clientul si se introdul
produsele pe factura, pentru fiecare produs se verifica stocul daca este sau nu pozitiv, daca
este pozitiv procesul merge mai departe daca nu acel p rodus nu va fi introdus pe factura.
Sistemul urmareste ca toti pasii sa fie realizati cu succes si in ordinea prezentata.

Diagrama de procese (Process diagram)
a. Diagrama de proces total. In diagrama de mai jos este prezentat tot procesul ce se deruleaza
in aplicatie: contabilul primeste facturi de la furnizori sau emite facturi catre clienti, intrare
sau iesire de marfa. Se actualizeaza stocul in urma documentelor introduse, se verifica prin
emiterea de rapoarte .

b. Diagrama de procese pentru accesarea articolelor din aplicatie. Procesul consta in logarea
utilizatorului, navigarea asupra unui produs sau asupra mai multor produse din aplicatie ,
acesarea ramurei si rasfoirea catalogului de produse, afiseaza produs ele in urma cauta rii.
Pe produse sunt afisate preturile si stocul disponibil pentru fiecare.