Sunteți pe pagina 1din 51

ACADEMIA DE STUDII ECONOMICE

Facultatea de Cibernetic, Statistic si Informatic Economic

Lucrare de licenta

Profesor coordonator : Asist. Univ. Dr. Vlad DIACONITA


Studenta : DIMA Raluca Andreea

Bucureti -2012-

ACADEMIA DE STUDII ECONOMICE

Facultatea de Cibernetic, Statistic si Informatic Economic

Program informatic pentru inregistrarile contabile

Profesor coordonator : Asist. Univ. Dr. Vlad DIACONITA


Studenta : DIMA Raluca Andreea

Bucureti -2012-

Cuprins
Introducere ................................................................................................................................. 3 Capitolul I - Descrierea problemei economice ........................................................................... 4 1.1 Scurt istoric al contabilitii .............................................................................................. 4 1.2 Noiuni generale ............................................................................................................... 4 1.2.1 Principii contabile ...................................................................................................... 5 1.2.2 Cont, Debit i Credit................................................................................................... 7 1.2.3 Planul de conturi........................................................................................................ 8 1.2.4 Prezentarea potenialului utilizator al software-ului ................................................ 8 Capitolul II - Tehnologii informatice utilizate ........................................................................... 10 2.1. Oracle Database 11g Express Edition ............................................................................ 10 2.1.1. Scurt istoric ............................................................................................................. 10 2.1.2. Arhitectura sistemului ORACLE .............................................................................. 11 2.1.3. Oracle 11g Express Edition ..................................................................................... 11 2.2. SQL (Structured Query Language) ................................................................................. 13 2.3. Oracle Forms&Reports .................................................................................................. 16 Capitolul III - Analiza sistemului informatic .............................................................................. 20 3.1 Definirea problemei i specificarea funcionalitii........................................................ 20 3.2 Analiza cerinelor sistemului informatic ......................................................................... 21 3.2.1 Diagrama Cazurilor Generale de Utilizare ............................................................... 21 3.2.2 Diagrama de clase nedetaliat ................................................................................ 23 3.2.3 Diagrame de activiti.............................................................................................. 24 3.2.4 Diagrame de stare ................................................................................................... 27 Capitolul IV Proiectarea i implementarea sistemului .......................................................... 30 4.1 Proiectarea sistemului informatic .................................................................................. 30 4.2 Proiectarea machetelor de intrare-ieire ....................................................................... 31
1|P agi na

4.3 Proiectarea ierarhiei de ferestre .................................................................................... 32 4.4 Proiectarea bazei de date ............................................................................................... 37 Concluzii.................................................................................................................................... 41 Bibliografie................................................................................................................................ 42 Anexe ........................................................................................................................................ 43

2|P agi na

Introducere

Introducere

Am ales aceast tem de licen deoarece mbin, n mod armonios, cele dou domenii de care am fost atras nc din primii ani de studiu informatica i contabilitatea. Pasiunea pentru informatic a aprut din liceu, din primele ore de programare; acesta a fost motivul pentru care am ales ca, dup un an de studiu n cadrul Facultii de Finane, s m nscriu la Cibernetic, forma de nvmnt la distan. De asemenea, lucrul cu cifre i interpretarea indicatori financiari pe baza situaiilor financiare m-au fcut s mi dau seama c mi doresc s aflu ct mai multe informaii n domeniul contabil i fiscal n prezent urmez un master n contabilitate. Crearea unui program de contabilitate care s faciliteze nregistrarea i prelucrarea datelor financiar-contabile necesit att cunotine vaste n ceea ce privete limbajele/mediile de programare (baze de date i nu numai), ct i n domeniul contabil i fiscal. Lucrarea de fa este structurat n patru capitole. Astfel, n primul capitol este realizat o scurt introducere n ceea ce nseamn contabilitatea; astfel, am prezentat un scurt istoric al operaiilor economice, de cnd au aprut primele forme, pn la contabilitatea din ziua de astzi. De asemenea, primul capitol prezint i potenialul utilizator al programului informatic prezentat, i anume o societate centru de cost, bazat pe achiziii de bunuri i servicii. n cel de-al doilea capitol sunt descrise tehnologiile informatice utilizate n crearea acestui software, i anume Oracle Database 11g Express Edition, SQL i Visual C#. Cel de-al treilea capitol arat principalele principii utilizate n proiectarea programului informatic principii ce in de teoria relaional a bazelor de date - i chestiuni legate de dezvoltarea software-ului includerea ntr-o soluie de tip Visual C# a unei baze de date Oracle. Ultimul capitol prezint modul de funcionare al aplicaiei, principalele ferestre i funcionaliti ale acestuia.

3|P agi na

Capitolul I - Descrierea problemei economice

Capitolul I - Descrierea problemei economice


1.1 Scurt istoric al contabilitii
Primele forme de consemnare a operaiilor economice au aprut nc din cele mai vechi timpuri n urm cu peste 20000 de ani, sub forma crestturilor pe pereii grotelor, a sforilor nodate; inerea socotelilor se fcea cu pietricele. Primele evidene contabile propriuzise au nceput s fie inute odat cu apariia scrisului la sumerieni; n timp, dezvoltarea n domeniul scrisului i a pstrrii documentelor a fcut posibil apariia primelor forme de control al nscrisurilor apariia i utilizarea papirusului. Un obstacol important n calea dezvoltrii contabile a fost acela al lipsei unei uniti comune de raportare, obstacol care a fost depit cu ajutorul grecilor, care au introdus primele monede de schimb in anii 600 .HR aspect ce va dinamiza i activitile financiar bancare. Cel mai vechi fragment de contabilitate care a fost descoperit dateaz din anul 1211 i reprezint registrele unei bnci comerciale italiene, n care se foloseau termeni precum dare i avere, care, mai trziu, au devenit debit i credit. Sub influena schimbrilor intervenite n mediul economic, contabilitatea va parcurge, la rndul ei, drumul de la o form primar ctre una complex, capabil s satisfac cerinele tot mai diverse ale utilizatorilor informaiei contabile. n paralel cu dezvoltarea exponenial e mediului informatic, contabilii au simit, de asemenea, nevoia de trecere de la inerea contabilitii pe hrtie de mn (ceea ce dura extrem de mult), la o contabilitate informatizat, care permite ca nregistrarea,vizualiz area, controlul i raportarea financiar s se fac mult mai rapid i mai uor. Astfel, cu trecerea timpului, dezvoltarea tehnologic a fcut posibil trecerea de la programe simple de inere a evidenei documentelor financiare, la sisteme integrate care permit accesul la orice informaie dintr-o companie, n orice moment i n orice loc.

1.2 Noiuni generale


Contabilitatea, ca activitate specializat n msurarea, evaluarea, cunoaterea, gestiunea i controlul activelor, datoriilor i capitalurilor proprii, precum i a rezultatelor obinute din activitatea persoanelor juridice i fizice trebuie s asigure nregistrarea cronologic i sistematic, prelucrarea, publicarea i pstrarea informaiilor cu privire la poziia financiar, performana financiar i fluxurile de trezorerie, att pentru cerinele
4|P agi na

Capitolul I - Descrierea problemei economice

interne ale acestora, ct i n relaiile cu investitorii prezeni i poteniali, creditorii financiari i comerciali, clienii, instituiile publice i ali utilizatori. (1)

1.2.1 Principii contabile


Contabilitatea este o tiin ce are o teorie i metod proprie pentru nregistrarea tuturor operaiilor economice i financiare ce produc modificri patrimoniului, ntr-o anumit ordine i pe baza urmtoarelor principii (2): a) principiul gestionar i al reprezentrii exhuastive a strii i micrii patrimoniului; b) dubla reprezentare a strii i micrii patrimoniului; c) nregistrarea cronologic i sistematic; d) principiul nregistrrii analitice i sintetice; e) fundamentarea documentar a nregistrrii operaiilor n contabilitate. a) Principiul gestiunii i al reprezentrii exhaustive a strii i micrii patrimoniului. Acest principiu explic faptul c patrimoniul este privit ca o entitate gestionar, ca un raport de schimb ntre cele dou laturi ale sale bunurile economice ca obiecte de drepturi i obligaii, respectiv drepturile i obligaiile cu valoare economic. Micrile de valori sunt evideniate i analizate din perspectiva efectului lor asupra unui singur patrimoniu la entitate gestionar. n ceea ce privete reprezentarea exhaustiv a strii i micrii patrimoniului, aceasta presupune nregistrarea tuturor elementelor, precum i a tuturor micrilor de valori produse n masa patrimoniului ntr-o anumit perioad de gestiune funcia gestionar a contabilitii. Intervin, astfel, dou criterii: cel al continuitii activitii i al periodizrii acesteia. b) Dubla reprezentare a existenei i micrii patrimoniului. Dubla reprezentare a strii i micrii patrimoniului prezint structurile patrimoniale la un moment dat, precum i micrile de valori n masa patrimonial, determinate de operaiile economice i financiare ca un raport de echivalen ntre destinaia sau investiia valorilor i provenienelor lor. Semnificaia termenilor ecuaiei se difereniaz n raport de obiectul dublei reprezentri. Astfel, dac obiectul l constituie patrimoniul n ansamblul su (bunuri, drepturi,

5|P agi na

Capitolul I - Descrierea problemei economice

obligaii), termenii ecuaiei sunt cei de activ(alocarea, destinaia elementelor patrmoniale) i pasiv(proveniena elementelor patrimoniale). ACTIVUL = PASIVUL Din punct de vedere static, dubla reprezentare a patrimoniului (sub aspectul existenei materiale a bunurilor i cel a provenienei lor) este evideniat n bilan cu cele dou pri ale sale: activul i pasivul. Activul patrimonial cuprinde bunurile economice ca obiecte de drepturi i obligaii, iar pasivul cuprinde drepturile i obligaiile titularului de patrimoniu privind elementele constituite ca activ. Elementele de activ sunt grupate n bilan n funcie de gradul lor de lichiditate, iar elemntele de pasiv n funcie de gradul de exigibilitate. Dac obiectul dublei reprezentri l constituie micrile individuale ale elementelor ce compun patrimoniul, raportul de schimb este cel dintre debit i credit. DEBIT = CREDIT c) nregistrarea cronologic i sistematic a operaiilor economice i financiare. Acest principiu presupune nregistrarea micrilor de valori n conturi, att n ordine cronologic (succesiunea lor n timp), ct i ntr-o form grupat, pe elemente i structuri componente ale patrimoniului. d) Principiul nregistrrii analitice i sintetice. nregistrarea analitic presupune divizarea patrimoniului n prile sale componente n scopul cunoaterii trsturilor lor specifice, folosindu-se n acest scop conturile analitice (conturile de gradul II). n conturile analitice, exprimarea se face cantitativ i valoric; prin intermediul acestor conturi se asigur controlul gestiunii patrimoniului. Conturile sintetice de gradul I i II sunt conturile de baz ale contabilitii; soldurile finale ale acestor conturi apar ca posturi n activul i pasivul bilanului. e) Fundamentarea documentar a nregistrrii operaiilor economice i financiare n contabilitate Orice operaie economic sau financiar pentru a fi nregistrat n contabilitate trebuie s fie consemnat ntr-un document ntocmit la locul i momentul producerii ei. Privite din punct de vedere al procesului de cunoatere i gestiune a patrimoniului, documentele justificative ndeplinesc dou funcii: informaional i gestionar. Funcia informaional const n faptul c documentele justificative asigur datele de intrare n sistemul contabil, furniznd informaii de reflectare i control pentru cunoaterea fiecrei
6|P agi na

Capitolul I - Descrierea problemei economice

operaii care provoac modificri n masa patrimoniului. Funcia gestionar a documentelor justificative rezult din faptul c ele fac dovada nfptuirii operaiilor economice i financiare. Pe baza lor se stabilesc i angajeaz rspunderi, drepturi i obligaii cu privire la micrile de valori produse n elementele patrimoniale.

1.2.2 Cont, Debit i Credit


n contabilitate, pentru a nregistra, calcula i controla existentul i modificrile de sens contrar (creteri, micorri) ale fiecrui element bilanier, pe o anumit perioad de timp, vom folosit instrumentul denumit cont. n structura contului sunt cuprinse urmtoarele: titlul i simbolul contului; debitul i creditul; explicaia tranzaciilor nregistrate n cont; rulajul contului; total sume debitoare i creditoare ale contului; soldul contului (3). Titlul contului exprim coninutul economic al elementului bilanier (bun economic, surs de finanare, proces economic sau rezultat financiar) a crui eviden se ine cu ajutorul contului respectiv. n general, denumirea unui cont reflect obiectul nregistrat n contul respectiv. n ara noastr, titlul i simbolul conturilor se stabilesc n mod unitar, prin planul de conturi general elaborat pe economia naional. Simbolurile deriv din poziia pe care o ocup contul respectiv n structura planului de conturi, faciliteaz identificarea conturilor i, respectiv, activitatea practic de contabilitate att n sistemul manual, ct i n sistemul informatic. Debit i credit. Partea stng a oricrui cont este denumit debit, iar partea dreapt este denumit credit. A debita un cont nseamn a nregistra o sum n partea stng a contului, iar a credita nseamn a nregistra o sum n partea dreapt. Legtura dintre debitul (D) i creditul(C) conturilor, stabilit cu ocazia nregistrrii operaiilor economice n conturi, poart denumirea de corespondena conturilor, iar conturile care reflect o astfel de legtur se numesc conturi corespondente. Micarea sau sumele nregistrate succesiv ntr-o perioad de gestiune n debitul sau credit unui cont, ca urmare a creterilor i micorrilor determinate de tranzacii reprezint rulajul contului. Acesta este de dou feluri: rulaj debitor (totalitatea nregistrrilor efectuate n debitul unui cont ntr-o perioad de gestiune) i rulaj creditor (totalitatea nregistrrilor efectuate n creditul unui cont n perioada de gestiune).

7|P agi na

Capitolul I - Descrierea problemei economice

1.2.3 Planul de conturi


Planul de conturi general este un tablou al ntregului sistem de conturi, n cadrul creia fiecare cont este delimitat printr-o denumire i un simbol cifric, fiind ncadrat ntr-o clas i grup. Astfel se asigur uniformitate i unitate de coninut, funcie, denumire i simbolizare a conturilor. Reguli de funcionare a conturilor. Regulile de funcionare a conturilor au drept scop stabilirea prii contului (debit sau credit) n care urmeaz s se nregistreze soldul iniial existent n fiecare cont la deschiderea acestuia, modificrile (creteri sau micorri) valorii elementului la care se refer contul, determinare de tranzaciile, evenimentele, operaiile economice i soldul final al conturilor existent la nchiderea acestora. Acestea au ca punct de plecare bilanul cu structurile sale (active, capitaluri i datorii) i cele dou principii de baz ale contabilitii: dubla reprezentare i dubla nregistrare.

1.2.4 Prezentarea potenialului utilizator al software-ului


Lucrarea de fa i propune crearea unui software pentru nregistrarea documentelor contabile din cadrul unei companii centru de cost multinaionale. Astfel, lunar, n contabilitate vor fi nregistrate, n proporie de circa 95%, documente pentru achiziia de bunuri i servicii de la furnizori. Fiind centru de cost, ntreprinderea nu nregistreaz vnzri propriu-zise; contractul cu firma-mam presupune ca, lunar, cifra de afaceri s se situeze la o valoare cu 5% mai mare dect totalitatea cheltuielilor din acea lun, pentru ca firma s poat s-i plteasc angajaii i furnizorii, pentru a avea profit i pentru a achita datorii ctre Bugetul de Stat. Plecnd de la premiza unei astfel de ntreprinderi, software-ul de contabilitate se va axa pe cumprri, i nu pe vnzri cum o fac cea mai mare parte a programelor existe pe pia. Astfel, cele mai des utilizate conturi vor fi 401 - Furnizori (cu analiticele 4011 Furnizori interni i 4012 Furnizori exteri), respectiv 404 Furnizori de imobilizri (cu analiticele 4041 Furnizori interni de imobilizri i 4042 Furnizori externi de imoblizri). n coresponden cu aceste conturi de pasiv se vor regsi urmtoarele conturi: Din clasa 2 Conturi de imobilizri 205 Concesiune, brevete, licene, mrci comerciale i alte drepturi i valori similare

8|P agi na

Capitolul I - Descrierea problemei economice

211 Terenuri i amenajri de terenuri 212 Construcii 213 Instalaii tehnice, mijloace de transport, animale i plantaii 214 Mobilier, aparatur birotic, echipamente de protecie a valorilor umane i materiale i alte active materiale 231 Imobilizri n curs 281 Amortizri privind imobilizrile Din clasa 3 Conturi de stocuri i producie n curs de execuie 301 Materii prime 302 Materiale consumabile 34X Produse 371 Mrfuri Din clasa 5 Conturi de trezorerie 5121 Conturi curente la bnci, n lei 5124 Conturi curente la bnci, n valut Din clasa 4 Conturi de teri 441 Impozit pe profit 442X Taxa pe valoarea adugat (TVA) Din clasa 6 Conturi de cheltuieli 60X Cheltuieli privind stocurile 61X Cheltuieli cu lucrrile i serviciile executate de teri Din clasa 7 Conturi de venituri 70X Cifra de afaceri

9|P agi na

Capitolul II - Tehnologii informatice utilizate

Capitolul II - Tehnologii informatice utilizate


Programul informatic de contabilitate este realizat prin mbinarea urmtoarelor tehnologii: Oracle Database 11g Express Edition, SQL Developer i Visual C#.

2.1. Oracle Database 11g Express Edition


Oracle este un sistem de gestiune a bazelor de date relaionale, realizat de firma Oracle Corporation USA. Sistemul este complet raional, robust, se bazeaz pe SQL standard extins. Arhitectura sistemului este client/server, permind lucrul cu obiecte i distribuit. Ultima versiune aprut este Oracle 11g. Sistemul Oracle este realizat de firma Oracle Corporation care a aprut n anul 1977 n California; acum este cel mai mare furnizor de software de gestiunea datelor, ctignd un segment destul de important i n Romnia. Acesta este operaional pe toat gama de calculatoare (micro, mini, mainframe) sub diverse sisteme de operare. (4)

2.1.1. Scurt istoric


Prima versiune de Oracle sistem de gestiune a bazelor de date raionale a fost realizat la sfritul anilor 70, respectndu-se teoria relaional. Teoria relaional a fost dezvoltat de E.F.Codd i echipa sa de cercetare pe parcursul acestor ani; imediat dup aceasta ncepnd s apar SGBD-uri care aveau la baz aceast teorie (modelul relaional, algebra relaional, calculul relaional, tehnici de proiectare) care fac trecerea spre a doua generaie de sisteme de baze de date. Urmtoarea versiune de Oracle a aprut la mijlocul anilor 80 Oracle 5 - i aducea nouti cum sunt: funcionarea n arhitectur client-server, limbaj procedural propriu PL/SQL, precompilatoare. Trecerea la o nou generaie de produse Oracle a fost realizat cu ajutorul Oracle 8, lansat n 1997, n mai multe ri simultan, printre care i Romnia. Ce aducea nou era trecerea de la arhitectura client-server spre arhitectura NC (Network Computing) i (Internet Computing), pune accent pe optimizri privind utilizarea resurselor de calcul (timpul i spaiul), pune accent mare pe analiz proiectare, este primul SGBD cu server Java inclus, reduce drastic costurile pentru realizarea unei aplicaii, are instrumente divers pentru

10 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

dezvoltarea aplicaiilor (bazate pe modulare Designer, Developer, Application Server; bazate pe componente Java; bazate pe HTML browsere, editoare WEB; XML). Au urmat, apoi, lansarea Oracle 8i (noiembrie 1998), Oracle 9i (2001) care marcau o nou generaie de servicii Internet. Oracle a devenit, astfel, o platform pentru sisteme de baz de date pentru Internet. n 2003 a fost lansat versiunea Oracle 10g care adaug noi faciliti sistemului Oracle 9i. Ultima versiune este Oracle 11g a fost lansat n 2009. (5)

2.1.2. Arhitectura sistemului ORACLE


Componentele care formeaz arhitectura de baz Oracle sunt dispuse ntr-o configuraie client/server. Aceste componente sunt plasate pe calculatoare diferite ntr-o reea asigurnd funcionaliti specifice, astfel: serverul asigur memorarea i manipularea datelor, precum i administrarea bazei de date iar clientul asigur interfaa cu utilizatorul i lanseaz aplicaia care acceseaz datele din baza de date. (4) Arhitectura Oracle se ncadreaz n tendinele actuale i anume este structurat pe trei niveluri: nucleul, interfeele i instrumentele de ntreinere. Nucleul Oracle conine componentele care dau tipul relaional pentru SGBD Oracle: limbajul relaional de regsire SQL i limbajul procedural propriu PL/SQL. Sistemul Oracle creeaz i ntreine automat dicionarul de date. Acesta face parte din baza de date Oracle i conine un set de tabele i viziuni (vederi) accesibile utilizatorilor doar n consultare. Dicionarul conine informaii de tipul: numele utilizatorilor autorizai, drepturile de acces, numele obiectelor din baza de date, structurile de date, spaiul ocupat de date, chei de acces etc. Interfeele sunt componentele care permit dezvoltarea aplicaiilor cu BD, astfel: Developer Suite (componenta destinat dezvoltatorilor de aplicaii Forms, Reports, Jdeveloper) , Designer, Pro*C; Datawarehouse Builder (destinat analizei datelor multidimensionale, folosind tehnologia OLAP), Oracle Applications.

2.1.3. Oracle 11g Express Edition


Tehnologia Oracle Database 11g Express Edition este ideal pentru ntreprinderile care au nevoie pentru a susine un volum mare de procesare a tranzaciilor on-line i de

11 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

aplicaii de depozitare intensive de date de interogare. Acesta ofer scalabilitate dovedit pe toate configuraiile hardware i poate fi folosit pentru a gestiona cantiti foarte mari de informaii, cu cel mai nalt nivel de asigurare de securitate din industrie.Oracle Database 11g Express Edition suport toate tipurile standard de date relaionale, precum i stocarea nativa a XML, text, documente, imagini, audio, video i date de locaie. Accesul la datele stocate se face prin intermediul interfeelor standard, cum ar fi SQL, JDBC, SQLJ, ODBC, OLE DB i ODP.NET, SQL / XML, XQuery i WebDAV. Logica de afaceri desfurat n baza de date poate fi scris att n Java ct i n PL / SQL.Odat stocate, toate datele pot fi transformate, indexate i sintetizate folosind n paralel operaiuni puternice. Oracle Database 11g Express Edition accept interogri distribuite i tranzacii ntre dou sau mai multe baze de date i include suport ncorporat pentru conectarea prin ODBC la pentru a treia baza de date comune. n plus, Transparent Gateways pentru baze de date specifice sunt disponibile, oferind o soluie extrem de optimizat de integrare a informaiei.Oracle Database 11g Express Edition ofer de asemenea un framework built-in pentru capturare, ateptare i prelucrare a evenimentelor n baza de date, cum ar fi cele care sunt cauzate de schimbrile de date sau create prin intermediul aplicaiilor de afaceri. Aceste evenimente, mpreun cu modificrile asociate datelor sau a mesajelor aplicatiei, pot fi repercutate n mod automat i aplicate de ctre unul sau mai multe baze de date sau aplicaii, oferind o solutie integrata pentru coada de mesaje i replicare a datelor.Oracle Database 11g Express Edition poate fi folosit ca un depozit central de stocare al datelor coordonat ntr-o ramur de mediu de birou, mpreun cu un Standard Edition local sau Standard Edition One database. Baza de date Oracle ofer cel mai puternic securitate disponibil n industria de azi. n ultimul deceniu Oracle a finalizat cerinele cu de succes 17 evaluri i de securitate independente.Consolidarea datelor, confidenialitate reglementrile

guvernamentale, cum ar fi HIPAA necesit caracteristici sofisticate de securitate. Oracle Database 11g ofer industriei funcii de securitate pentru conducere, cum ar fi nivelul de securitate bob /rnd, securitatea coloanei,filtrarea coloanei, criptarea datelor, autentificarea proxy, contextul de aplicare i roluri sigure de aplicare.Acestea sunt n plus fa de caracteristici de securitate banale, cum ar fi audit, controalele pentru complexitatea parolei, suport robust pentru rolurile bazei de date, proceduri stocate i funcii. (6) Oracle Database 11g uureaz instalarea i configurarea unui mediu de baze de date care folosete aceste servere hardware cu corturi reduse, aduce mbuntiri n ceea ce
12 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

privete performana sistemului, reduce costul de stocare al datelor prin sistemul Oracle Cloud File System i prin mecanismul de partiionare a tabelelor mari divide et impera respectiv prin tehnicile avansate de compresie.

2.2. SQL (Structured Query Language)


SQL (Structured Query Language - Limbaj Structurat de Interogare) este un limbaj de programare specific pentru manipularea datelor n sistemele de manipulare a baz elor de date relaionale, iar la origine este un limbaj bazat pe algebra relaional. Acesta are ca scop inserarea datelor, interogaii, actualizare i tergere, modificarea i crearea schemelor, precum i controlul accesului la date. A devenit un standard n domeniu (standardizat ANSI-ISO), fiind cel mai popular limbaj utilizat pentru creearea, modificarea, regsirea i manipularea datelor de ctre SGBD-urile relaionale. Pe lng versiunile standardizate ale limbajului, exist o mulime de dialecte i variante, unele proprietare, fiind specifice anumitor SGBD-uri i de asemenea coninnd extensii pentru a suporta SBD-urile (Sistemele de Baze de Date) obiectuale (obiectual-relaionale). (7) SQL este un limbaj neprocedural i declarativ, deoarece utilizatorul descrie ce date vrea s obin, fr a fi nevoie s stabileasc modalitile de a ajunge la datele respective. Foarte frecvent, este utilizat n administrarea bazelor de date client/server, aplicaia client fiind cea care genereaz instruciunile SQL. Pentru c exist o standardizare a limbajului SQL, multe SGBD-uri (Oracle, Access, Sybase) recunosc principalele instruciuni ale acestuia.Caracteristicile adugate standardului se numesc extensii. Conceptele necesare a fi cunoscute pentru lucrul cu acest limbaj sunt: tabela, cheie primar, coloan, rnd, viziune, index, sinonim, cluster, baz de date relaional, comand, blocul, cererea,raportul etc. (4) Tabela sau relaia este un ansamblu format din n coloane (atribute/subansambluri) i m rnduri (tupluri/linii) care respect urmtoarele condiii minime: nu conine date la nivel agregat (valorile aflate la intersecia liniilor cu coloanele s fie la un nivel elementar); liniile sunt distincte unele fa de altele; nu conine coloane repetitive n descriere. Cheia primar este un atribut care are valori distincte. Deci, fiecare linie se identific printr-o valoare distinct. Dou sau mai multe atribute care pot fi chei primare se numesc chei candidate.

13 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

Coloana tabelei este format din valorile pe care le ia atributul n liniile tabelei respective. Rndul/tuplul/linia este format din valorile coloanelor ce se refer la o entitate a tabelei. Baza de date relaional este un ansamblu de tabele normalizate, grupate n jurul unui subiect, n principiu, bine definit. ntr-o baz de date relaional, entitile i legturile sunt transpuse n tabele. Viziunea este o tabela logic i reprezint o fereastr la date, dintr-una sau mai multe tabele. Pentru ca accesul la date sa se fac mai rapid, se utilizeaz indexarea. Un index reprezint o cheie pe una sau mai multe coloane. Indexarea este dinamic deoarece se pot adaug sau terge indeci oricnd, fr ca datele memorate sau aplicaiile scrise s fie afectate. Pentru realizarea unor operaii sau pentru a utiliza n cereri nume mai scurte, se pot defini sinonime ale unor nume de tabele sau viziuni. Un cluster reprezint o anumit modalitate de grupare a rndurilor uneia sau mai multor tabele. Aceast grupare mrete viteza de execuie a unor operaii consumatoare de timp. Comanda este o instruciune emis din SQL ctre o baz de date Oracle. Blocul reprezint un grup de instruciuni SQL i PL/SQL. Cererea este o comanda SQL (SELECT) care regsete date din baza de date. Rezultatul cererii l formeaz datele regsite din baza de date. Raportul este rezultatul cererii formatat cu ajutorul comenzilor SQL. Numele unei baze de date, al unei tabele, coloane sau variabile utilizator trebuie s aib lungimea ntre 1 i 30 caractere. Un nume nu poate conine apostrofuri. Cu att mai puin, un nume utilizat ntr-o comand nu va fi introdus ntre apostrofuri. Literele mici i mari sunt echivalente (nu se face distincia ntre literele mici i mari). Un nume trebuie s nceap cu o liter, s conin numai anumite caractere (A-Z, 0-9, $, #, @, -), s nu duplice numele unui alt obiect de acelai tip i s nu fie un cuvnt rezervat ORACLE. Exist 3 metode de baz privind implementarea limbajului SQL: apelare direct (Direct Invocation - const n introducerea instruciunilor direct de la prompter), modular (Modul Language - folosete proceduri apelate de programele aplicaie), ncapsulat (Embedded SQL - conine instruciuni ncapsulate n codul de program). Instruciunile SQL pot fi grupate n: instruciuni de definire a datelor, care permit descrierea structurii bazei de date; instruciuni de manipulare a datelor: adaug, terge, modific nregistrri; instruciuni de selecie a datelor, care permit consultarea bazei de date ; instruciuni de procesare a tranzaciilor; instruciuni de control al cursorului; instruciuni pivind controlul accesului la date.
14 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

Elementele limbajului: clauzele (care sunt n unele cazuri opionale, sunt componente constitutive ale declaraiilor i interogrilor), expresiile (care pot produce fie valori scalare sau tabele constnd din coloane i rnduri de date), predicate (care precizeaz condiiile care pot fi evaluate n SQL three-valued logic - 3VL - i care sunt folosite pentru a limita efectele declaraiilor i interogrilor, sau pentru a schimba fluxul de program), interogri (care preiau date pe baza unor criterii specifice), declaraii (care pot avea un efect persistent asupra schemelor i datelor, sau care pot controla tranzacii, fluxul de program, conexiuni, sesiuni, sau diagnosticare), spaiile libere nesemnificative (sunt n general ignorate n declaraiile i interogrile SQL, ceea ce uureaz formarea i citirea de cod SQL). Scrierea comenzilor SQL - O instruciune SQL este format din cuvinte rezervate i cuvinte definite de utilizator. Cuvintele rezervate au o denumire fix, iar cuvintele definite de utilizator reprezint denumirile diverselor obiecte din baza de date (BD). Instruciunile SQL ajut la realizarea accesului la datele unei baze de date, alturi de instruciunile PL/SQL (Procedural Language). Astfel, instruciunile SQL se mpart n (4): instruciuni de definire a datelor DDL (Data Definition Statements acestea permit definirea, ntreinerea i tergerea unor obiecte ale bazei de date); instruciuni de m anipulare a datelor DML (Data Manipulation Statements permit regsirea, inserarea, actualizarea i tergerea unor rnduri de date din tabele); instruciuni de control a tranzaciilor (Transaction Control Statements permit controlul instruciunilor DML: COMMIT, ROLLBACK, SAVEPOINT etc.); instruciuni de control a sistemului Oracle (System Control Statements permit utilizatorului s controleze proprietile sesiunii curente prin activarea sau dezactivarea rolurilor sau setarea limbii); instruciuni imprimate ntr-un limbaj gazd (Embeded SQL Statements ncorporeaz instruciuni DDL, DML i de control al tranzaciilor). O tranzacie este o unitate logic de lucru care cuprinde una sau mai multe instruciuni SQL executate de ctre un singur utilizator. Tranzacia ncepe cu prima instruciune SQL executabil i se termin n mod explicit cu finalizarea (commit) sau, dup caz, anularea tranzaciei (rollback). Finalizarea unei tranzacii face ca modificrile efectuate de intruciunilor SQL n baza de date s fie permanente, iar anularea (roll back) unei tranzacii duce la renunarea la actualizrile efectuate de instruciunile SQL pn la un moment dat.

15 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

Tranzaciile mari pot fi marcate cu puncte intermediare de salvare. Acest lucru permite ca activitile efectuate ntre punctele de salvare s fie considerate finalizate, iar la momentul anulrii (rollback) acest lucru s se execute pn la un anumit punctul de salvare specificat. PL/SQL este un limbaj procedural Oracle care combin instruciunile SQL cu instruciunile de control a prelucrrii (IF THEN, WHILE i LOOP). Utilizarea procedurilor PL/SQL memorate n baza de date duce la reducerea traficului pe reea. n baza de date pot fi stocate proceduri, funcii, pachete, triggeri. Triggerii (declanatorii) sunt blocuri de instruciuni scrise de programatori pentru a aduga funcii suplimentare unei aplicaii. Fiecare trigger are un nume i conine una sau mai multe instruciuni PL/SQL. Un trigger poate fi asociat cu un eveniment i poate fi executat i ntreinut ca un obiect distinct. Numele unui trigger corespunde unui eveniment (runtime events) care se produce la momentul execuiei unei aplicaii. (4)

2.3. Oracle Forms&Reports


Oracle Developer este un set de produse software, orientate pe obiect, care ajut la uurarea realizrii aplicaiilor pe baze de date Oracle. Acest set conine i Form Builder (permite crearea aplicatiilor client/server cu ajutorul videoformelor, meniurilor i bibliotecilor. Aplicaiile construite cu Form Builder permit regsirea, introducerea, modificarea i salvarea informaiilor n baze de date.), respectiv Report Builder (permite crearea de rapoarte, practice n orice format, incluzand tabele, relatii master-detaile, matrice, etichete postale, scrisori, liste, statistici etc). Elemente generale despre Form Builder. Instrumentul Forms este o componenta principala a setului de produse Developer i are trei componente: Form Builder, care permite crearea aplicatiilor, priectarea si stocarea definitiilor

videoformelor, meniurilor si bibliotecilor. Meniul principal al lui Form Builder contine submeniurile: File, care include optiuni ce permit deschiderea unui modul al aplicatiei,

salvarea lui, conectarea la o baza de date si alte activitati de administrare; Edit, care include optiunile Cut, Copy, Paste etc; View, care permite restrangerea sau extinderea gamei obiectelor care apar in

arborescenta din Object Navigator; Navigator, care permite manipularea obiectelor din Object Navigator;

16 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

aplicatiei; -

Program, care include optiuni de compilare, rulare, depanare etc. a modulelor

Tools, care include optiuni Wizard, pentru setarea functionalizarii Form Builder

si pentru apelarea unor editoare specifice; Window; Help, care furnizeaza informatii despre modul de utilizare Form Builder. Form Compiler, care permite compilarea aplicatiilor create cu Form Builder; Form Runtime, care permite executarea modulelor create cu Form Builder si

compilate cu Form Compiler.

Structura unui videoformat Obiectele cu care se interactioneaza la momentul executiei unui videoformat: canvasul este o suprafata pe care sunt aranjate elementele vizuale ale

videoformatului. Un videoformat poate avea mai multe canvasuri. Un canvas poate afisa elementele din unul sau mai multe blocuri. Pentru a vedea elementele incluse in canvas acesta trebuie vizualizat intr-o fereastra. Elementele unui bloc pot aparea in mai multe canvasuri si mai multe ferestre. fereastra este o modalitate de vizulizare a canvasului. Daca fereastra este de

dimensiune mai mica decat canvasul pe care-l afiseaza, atunci aceasta este prevazuta cu sageti de scroll la stanga-dreapta sau sus-jos, pentru a putea astfel vizualiza intregul canvas. Obiectele de interfata a aplicatiei: blocul este un container care grupeaza oricare dintre elementele obiect prezentate mai sus. Blocul nu are o reprezentare fizica, el fiind regasit numai la nivelul logic al unei aplicatii. In videoformat sunt vizibile doar elementele grupate in blocuri. Un videoformat poate contine mai multe blocuri. Blocurile pot fi de doua tipuri: - blocuri de date (Data block) care sunt associate cu o tabela dintr-o baza de date si pot contine un singur rand sau mai multe randuri de date; - blocuri de control (Control block) care nu sunt associate cu o tabela din baza de date. - elemental permite utilizatorului sa vizualizeze datele din baza de date sau sa interactioneze cu interfata aplicatiei. - frame sau rama este un obiect grafic utilizat pentru aranjarea obiectelor blocului. - trigger este un bloc PL/SQL care se executa la aparitia unui eveniment.

17 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

Proprietatile elementelor de structura ale unui videoformat Obiectele unui videoformat pot avea urmtoarele categorii de proprieti, care pot fi vizualizate n fereastra Property Palette: - General n care se definesc numele i tipul elementului; - Phisical n care definete atributele fizice ale elementului: numele canvasului, coordonatele n cadrul canvasului, limea i nlimea etc.; - Records care cuprinde informatii despre inregistrarile afisate; - Font and Color care definesc atributele fontului utilizate si atributele de culoare; - Prompt care defineste elementele de caracterizare ale prompteru-lui (eticheta) elementului in cadrul canvasului si imoplicit in cadrul blocului; - Data care defineste caracteristicile datelor ce vor fi afisate sau manipulate ajutorul elementului in cadrul blocului; - Navigation care defineste modul de navigare pana la element. cu

Crearea unui modul videoformat Modulele videoformatului prezentate mai sus se creaza folosind instrumentele: Object Navigator care asigura vizualizarea ierarhica a obiectelor din toate

modulele deschise (module Form, Menus, Libraries, Object Libraries, Built-in Package, Database Obejects); Layout Editor care este un instrument grafic de proiectare sau aranjare a interfetei

sau structurii unui bloc. Elementul creat cu Layout Editor este automat atasat blocului deschis la momentul lansarii acestui editor; PL/SQL Editor care permite scrierea si compilarea subprogramelor PL/SQL

(treiggeri, proceduri, functii, comenzi associate optiunilor de meniu etc.); Property Palette care este o fereastra in care se pot seta proprietatile obiectelor

create in modulul videoformat si modulul meniu; Project Library care este o fereastra asemanatoare cu fereastra Property Palette si

permite crearea , stocarea intretinerea si distribuirea obiectelor reutilizabile; Menu Editor care este un instrument grafic pentru crearea modulelor meniu. Intre

Menu Editor, Object Navigator si Property Palette exista osincronizae in inregistrarea modificarilor effectuate asupra elementelor videoformei si a elementelor meniului. Pentru
18 | P a g i n a

Capitolul II - Tehnologii informatice utilizate

crearea unei aplicatii nu este necesar sa se creeze un meniu specific pentru ca Form Builder atasaza automat un meniu orcarei videoforme, meniu care permite efectuarea operatiilor principale asupra unei baze de date (regasire, actualizare, salvare). (8)

19 | P a g i n a

Capitolul III - Analiza sistemului informatic

Capitolul III - Analiza sistemului informatic


3.1 Definirea problemei i specificarea funcionalitii
Problema propus spre rezolvare se ncadreaz n domeniul financiar-contabil i are ca scop implementarea unui software care s ajute la inerea evidenei facturilor intrate i ieite, respectiv a ncasrilor i plilor unei ntreprinderi centru de cost. Prin realizarea aplicaiei informatice se dorete eficientizarea procedurilor de nregistrare contabil a activitii economice n cadrul unui centru de cost, punndu-se accent pe fluxul de documente cu care intr n contact o astfel de ntreprindere. Deoarece oferta de pe pia de programe informatice de inere a contabilitii este majoritar axat pe firmele care au activiti de comercializare, m-am gndit s implementez un software simplificat, axat pe evidena facturilor primite i emise, respectiv a ncasrilor i plilor prin banc. Astfel am luat exemplul unei corporaii globale, care are o filial n Romnia. Aceasta se ocup cu implementarea de software pentru firma mam, ns, n Romnia nu se realizeaz vnzarea direct a acestor programe, ci doar proiectarea lor i implementarea lor, urmat de vnzarea ctre firma mam. Deci, n Romnia, costurile sunt reprezentate de totalitatea achiziiilor pentru buna funcionare (hardware, licene pentru software, chirie, servicii de consultan, recrutare, curenie, cheltuieli de protocol etc), iar veniturile sunt reprezentate de sumele primite de la firma mam sub form de cifr de afaceri, avnd o valoare cu 5% mai mare dect cheltuielile, pentru a le acoperi i a genera i impozit pe profit care este pltit ctre bugetul de stat. Menionez c ntreprinderea nu folosete numerar, toate ncasrile i plile fiind fcute strict prin banc evidena acestora se ine pe baza extraselor de cont primite de la banca partener astfel nu are rost implementarea n program a facilitii de ntocmire a Registrului de Cas. Deci, programul informatic propus spre implementare are n vedere evidena facturilor primite de la furnizori (interni i externi) i emise ctre firma mam i a extraselor de cont pentru ncasrile i plile efectuate.

20 | P a g i n a

Capitolul III - Analiza sistemului informatic

3.2 Analiza cerinelor sistemului informatic


n crearea unei aplicaii informatice trebuiesc avute n vedere fazele de analiz i proiectare a proiectului. Pentru acestea s-au creat limbajele de modelare, unul dintre acestea fiind limbajul de modelare unificat UML (The Unified Modeling Language). UML este un limbaj de modelare care ofer o exprimare grafic a structurii i comportamentului software. n cadrul UML-ului descoperim mai multe tipuri de diagrame, cele mai folosite fiind diagrama cazurilor generale de utilizare, diagrama de clase (detaliat sau nedetaliat), diagrama de activiti, diagrama de stri etc. Analiza unei aplicaii implic realizarea mai multor categorii de modele, dintre care cele mai importante sunt: (11) Modelul de utilizare realizeaz modelarea problemelor i soluiilor acestora n maniera n care le percepe utilizatorul final al aplicaiei. Modelul structural se realizeaz pe baza analizei statice a problemei i descrie proprietile statice ale entitilor care compun domeniul problemei. Modelul comportamental: privete descrierea funcionalitilor i a succesiunii n timp a aciunilor realizare de entitile domeniului problemei.

3.2.1 Diagrama Cazurilor Generale de Utilizare


O diagram a cazurilor de utilizare este format dintr-un ansamblu de cazuri de utilizare i actori, fiind folosit, n general, pentru a indica sau caracteriza funcionalitile i comportamentul ntregii aplicaii, sistemul interacionnd cu unul sau mai muli actori. Un actor este definit prin utilizatorii ce pot interaciona cu sistemul. Cazurile de utilizare sunt construite plecnd de la nevoile pe care le au actorii. n urma definirii problemei i a prezentrii funcionalitii aplicaiei informatice, se deduc urmtoarele cazuri de utilizare: administrarea bazei de date; emiterea de facturi; nregistrarea facturilor emise i primite; nregistrarea extraselor de cont; actualizarea planului de conturi; actualizarea listei de parteneri;
21 | P a g i n a

Capitolul III - Analiza sistemului informatic

actualizarea schemelor de contare; vizualizarea fielor analitice; vizualizarea partenerilor; vizualizarea ncasrilor i a plilor; vizualizarea facturilor emise i primite. Actorii care interacioneaz cu sistemul informatic sunt:

administratorul sistemului - administreaz baza de date a sistemului; contabilul emite facturi, nregistreaz toate documentele care intr i ies din companie, nregistreaz ncasrile i plile, actualizeaz planul de conturi, schemele de contare, introduce noi parteneri, genereaz diferite rapoarte; managerul vizualizeaz rapoartele ntocmite de contabil, situaia partenerilor, fiele analitice, stadiul facturilor intrate i ieite din companie. n urmtoarea figur se prezint diagrama cazurilor generale de utilizare:

Figura 3.1. Diagrama cazurilor generale de utilizare (Sursa proprie) 22 | P a g i n a

Capitolul III - Analiza sistemului informatic

Dup cum se poate observa din diagrama cazurilor generale de utilizare, actorul contabil este cel care are cele mai multe sarcini, i anume emiterea de facturi, pe care apoi le nregistreaz n aplicaie, nregistrarea de facturi primite (att interne, ct i externe), nregistrarea plilor i ncasrilor ctre i de la parteneri, poate actualiza planul de conturi, lista partenerilor, schemele de contare. De asemenea, contabilul generaz rapoarte pentru management, rapoarte privind ncasrile i plile, fie analitice ale conturilor etc. Administratorul bazei de date, dei are acces la toat aplicaia informatic, inclusiv la datele ncrcate de contabil, se ocup doar cu administrarea bazei de date i cu acordarea de acces la aceasta. Managerul poate observa n orice moment, care e situaia general a fluxurilor de documente i nu numai.

3.2.2 Diagrama de clase nedetaliat


Diagrama folosit n modelarea obiect se numete diagrama de clase i ea ofer o imagine asupra reprezentrii tabelelor i a relaiilor dintre ele. Diagramele de clase descriu cazuri generale n modelarea sistemului. Diagrama claselor este cea mai important n cadrul analizei i proiectrii orientate obiect, avnd cca scop structurarea naturii statice a claselor. n Figura 2 este prezentat diagrama claselor, coninnd clasele nedetaliate i asocierile dintre ele. Diagrama claselor a fost construit pe urmtoarele principii: Unui tip de document i corespund una sau mai multe operaii contabile. O operaie contabil are o singur schem de contare. Unei operaii contabile i corespund una sau mai multe note contabile. O not contabil are una sau mai multe linii. Facturile emise, facturile primite n RON, n devize i extrasele de cont sunt derivate din operaiile contabile. O factur primit n RON poate avea unul sau mai multe rnduri. De asemenea, o factur primit n RON are un singur furnizor (partener). O factur primit n devize poate avea unul sau mai multe rnduri. O factur primit n devize are un singur furnizor (partener). O factur emis poate avea unul sau mai multe rnduri. O factur emis are un singur client (partener).
23 | P a g i n a

Capitolul III - Analiza sistemului informatic

Figura 3.2. Diagrama de clase (Surs proprie)

O linie din factura primit n RON, n devize sau facturile emise are asociat un singur tip de TVA. Un extras de cont poate avea unul sau mai multe rnduri. Unui rnd din extrasul de cont i corespunde un singur partener.

3.2.3 Diagrame de activiti


Diagrama de activiti reprezint o modalitate de modelare vizual a fluxurilor. Cu ajutorul acestei diagrame pot fi modelate foarte bine cazurile de utilizare, dar, n aceeai msur, aceste diagrame pot fi folosite pentru modelarea proceselor de business, fr nicio legtur cu sistemul informatic. (12) n cele ce urmeaz voi prezenta o diagrama de activiti privind procesul nregistrrii unei facturi primite n devize, n linii mari.

24 | P a g i n a

Capitolul III - Analiza sistemului informatic

Figura 3.3. Diagrama de activiti privind nregistrarea unei facturi n devize (Surs proprie)

Astfel, paii pe care i urmeaz activitatea de nregistrare a unei facturi n devize sunt urmtorii: primirea unei facturi n devize, apoi verificarea existenei furnizorului (partenerului) n baza de date. Daca furnizorul exist, se trece mai departe. Dac acesta nu exist, se continu prin nregistrarea acestuia n baza de date i asocierea unui cont analitic n tabela plan de conturi. Deoarece regulile contabile prevd nregistrarea tuturor documentelor n moneda naional, va trebui cutat cursul valutar de schimb ntre valuta de pe factur i RON din ziua anterioar datei facturii (aa cum se prevede n Codul Fiscal). Dup ce a fost realizat acest pas, urmeaz analiza liniilor nscrise n factur pentru asocierea cu conturile d in planul de conturi. Orice operaie contabil are asociat o not contabil. Dup aceast analiz, se trece la nregistrarea propriu-zis a facturii n aplicaia de contabilitate, dup care aceast activitate este ncheiat.

25 | P a g i n a

Capitolul III - Analiza sistemului informatic

Mai jos, n Figura 4, este prezentat o diagram de activiti specific procesului de nregistrare a unui extras de cont.

Figura 3.4. Diagrama de activitati specifica inregistrrii unui extras de cont

Fiecare extras de cont este generat la o anumit dat, de o anumit banc, pentru o anumit perioad. Extrasul de cont poate conine o list de ncasri i pli pentru mai multe zile sau poate fi generat la sfritul fiecrei zile. Fiecare linie din extrasul de cont conine informaii despre data plii sau ncasrii, suma pltit sau ncasat, documentul asociat i partenerul (furnizor sau client). Astfel, activitatea de nregistrare a unui extras de cont are mai muli pai. Un prim pas, elementul generator al acestei acitiviti, este primirea extrasului de
26 | P a g i n a

Capitolul III - Analiza sistemului informatic

cont. Acest pas este urmat de nregistrarea n contabilitate a informaiilor din header-ul extrasului de cont. Dup asta, se adaug o linie nou pentru fiecare rnd din extrasul de cont. Pentru fiecare linie nou de nregistrat, se verific dac este o plat sau o ncasare, mergnd pe ramura specific. Urmeaz nregistrarea sumei ncasat sau pltit, partenerul i data operaiunii. Dup aceasta, se verific dac mai sunt linii de nregistrat, urmnd nregistrarea unui nou rnd sau ieirea din activitate, dac a fost nregistrat tot extrasul de cont.

3.2.4 Diagrame de stare

Diagramele de stare sunt utilizate sunt utilizate pentru a specifica posibilele stri prin care poate trece un obiect i modul n care se poate trece de la o stare la alta (modelare work flow-uri, modelare fluxuri de documente, diagrame de stri). Trecerea de la o stare la alta este determinat de tranzaciile intermediare acestea corespund aciunilor pe care le-am ntlnit n diagrama de activiti (pn la urm, diagrama de stare reprezint un alt mod de a vedea un flux ce poate fi modelat exclusiv prin diagrama de activiti, inventat pentru a exprima mai elocvent trecerile de la o stare la alta). Mai jos sunt prezentate diagramele de stare pentru cele dou activiti prezentate la punctul anterior: o diagrama de stare pentru nregistrarea unei facturi externe primite i o diagram de stare pentru nregistrarea unui extras de cont. n cazul diagramei de stare pentru nregistrarea facturilor externe primite, strile sunt prezentate n ceea ce urmeaz. Evenimentul primirii unei facturi externe face trecerea din starea iniial n starea n care acest document ajunge la contabil, care urmeaz s o nregistreze n aplicaie. Urmtorul eveniment, de verificare al furnizorului, face trecerea fie la etapa de nregistrare a unui furnizor nou, apoi la crearea unui analitic n planul de conturi pentru acesta, apoi la starea de furnizor verificat, fie direct la aceast stare, n funcie de existena acestui partener n baza de date. Dup acest pas se trece la cutarea cursului valutar de schimb aferent zilei anterioare datei facturii, apoi la analiza rndurilor acesteia pentru determinarea schemei de contare. Dup ce aceti pai au fost fcui, se trece la nregistrarea propriu-zis a facturii, apoi se iese din modul.

27 | P a g i n a

Capitolul III - Analiza sistemului informatic

Figura 3.5. Diagrama de stare pentru nregistrarea unei facturi externe primite

n urmtoarea figur este prezentat diagrama de stare pentru nregistrarea unui extras de cont. Starea iniial este generat de primirea unui extras de cont, care trebuie nregistrat. Evenimentul de nregistrare a datelor generale ale extrasului de cont genereaz starea de date generale nregistrate, dup care se dorete nregistrarea fiecrui rnd din extrasul de cont, att timp ct acesta ofer date valabile. nregistrarea fiecrei linii este precedat de ntrebarea dac e vorba despre o plat sau o ncasare; apoi, dac e vorba despre o sum ncasat, obiectul trece prin starea de sum ncasat nregistrat, client ncasat, dat ncasare nregistrat; dac e vorba despre o plat, se trece prin urmtoarele stri: sum pltit nregistrat, furnizor pltit i dat plat nregistrat. Se observ c verificarea existenei partenerului n baza de date nu28 | P a g i n a

Capitolul III - Analiza sistemului informatic

i mai are rostul, ncasarea sau plata fiind nregistrat dup emiterea sau primirea unei facturi. Urmeaz apoi analiza logicii de contare, finalizat prin alegerea unei scheme de contare, dup care se verific dac extrasul de cont mai conine sau nu linii de nregistrat. Dac rspunsul e afirmativ, se reia procesul de nregistrarea a unei noi linii; dac rspunsul e negativ, se iese din modul.

Figura 3.6. Diagrama de stare pentru nregistrarea unui extras de cont

29 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Capitolul IV Proiectarea i implementarea sistemului


n acest capitol se realizeaz definitivarea diagramei de clas e prezentat n capitolul anterior (completat cu atribute i metode), proiectarea machetelor de intrare-ieire (descrierea succint a celor mai importante formulare i rapoarte), proiectarea ierarhiei de ferestre ale aplicaiei, proiectarea bazei de date (schema conceptual a bazei de date, precum i descrierea succint a tabelelor i a legturilor dintre acestea) i stabilirea necesarului de resurse hardware i software pentru rularea fr probleme a aplicaiei.

4.1 Proiectarea sistemului informatic


Definitivarea diagramei de clase presupune completarea diagramei nedetaliate cu informaii despre atribute (numele acestora i tipul) i despre metode. Astfel, n figura urmtoare se prezint diagrama definitivat de clase. Diagrama de clase detaliat rezult prin rafinarea diagramei de clase din etapa de analiz, implementndu-se anumite detalii precum specificarea atributelor i tipului acestora. Majoritatea claselor prezentate n diagram permit urmtoarele operaii: creearea unui nou element, modificarea sau tergerea unui nou element. Se observ c tabelele Plan_Conturi, TipuriDocumente, Schema_Contare, Parteneri i TVA nu permit dect adugarea de noi elemente. Acest lucru se datoreaz faptului c tabelele cu care sunt n relaie pot avea informaii care in de nregistrrile din aceste tabele i nu trebuie s existe posibilitatea de tergere sau modificare a acestor nregistrri. Unele tabele ofer i posibilitatea de a li se terge nregistrri. Aceste tabele sunt: Fact_Prim_Ron, Fact_Prim_Dev, Fact_Emise, Extras_De_Cont (n cazul n care, din greeal, se introduc nregistrri eronate), precum i tabelele care rein informaii despre liniile facturilor. Ca regul general, pot fi terse nregistrri din tabelele care nu sunt chei externe n alte tabele.

30 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Figura 4.1 Diagrama definitivat de clase

4.2 Proiectarea machetelor de intrare-ieire


Aplicaia i propune nregistrarea i stocarea n baza de date a informaiilor de natur contabil. Astfel, ca documente de intrare vom avea facturile emise (care pot fi i interne, i externe), facturile primite de la furnizorii romni, facturile primite de la furnizorii strini i extrasele de cont.

31 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Pe lng acestea, n aplicaie mai trebuie s existe informaii despre tipurile de documente de intrare, despre operaiile contabile i, nu n ultimul rnd, schemele de contare ca pot fi folosite pentru nregistrri. De asemenea, ca date de intrare se prezint i informaiile despre partenerii de afaceri. Planul de conturi nu trebuie s lipseasc din baza de date. Deci, ca date de intrare n aplicaie avem informaii despre: facturile emise i primite (n lei i devize), extrasele de cont, partenerii de afaceri, planul de conturi, documentele, operaiile i schemele de contare aferente. Ca informaii de ieire, se pot implementa diferite rapoarte, n funcie de nevoi i de informaiile din baza de date. Astfel, cele mai utilizate rapoarte ar putea fi: fiele analitice ale furnizorilir i clienilor, sumele pltite i ncasate etc.

4.3 Proiectarea ierarhiei de ferestre


Aplicaia descris este format din 7 ferestre, utile pentru nregistrarea datelor din documentele primite i nu numai. Astfel, pentru nregistrarea, vizualizarea, modificarea sau tergerea informaiilor despre Parteneri, se folosete form-ul urmtor:

Figura 4.2 Fereastra de Parteneri

32 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Dup cum se poate observa, pentru a se introduce un nou Partener n baza de date, trebuiesc completate informaii despre ID-ul acestuia, Denumire i CUI, ara de provenien, localitatea (se completeaz doar dac partenerul este din Romnia), respectiv tipul de Partener (acesta poate fi Furnizor, Client, i Furnizor i Client sau altceva). Form-ul pentru vizualizarea, introducerea, modificarea sau tergerea informaiilor despre conturile din planul de conturi este prezentat n continuare:

Figura 4.3 Form pentru Planul de Conturi

Pentru a se putea nregistra un nou cont n baza de date, trebuiesc completate, n mod obligatoriu, informaiile despre simbolul acestuia, explicaii i funcionalitate (dac e de activ sau de pasiv), i, doar dac este nevoie, informaia despre ID-ul partenerului. Acest tabel este folosit n condiiile n care contabilul nu tie conturile i funcionalitatea lor n orice condiii. Informaii despre tipurile de documente cu care intr n contact firma, operaiunile contabile pe care aceasta le desfoar, respectiv schemele de contare care ar trebui folosite se regsesc cu ajutorul urmtorului form:

33 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Figura 4.4 Form pentru documentele contabile

Cu ajutorul acestui formular, putem nregistra, vizualiza, modifica sau terge informaii despre schemele de contare folosite pe fiecare tip de operaiune contabil. De asemenea, fiecare operaiune contabil are un document contabil aferent. n continuare sunt prezentate form-urile pentru vizualizarea, nregistrarea, modificarea sau tergerea informaiilor legate de facturile primite i emise (att n lei, ct i n devize). n cazul facturilor emise, pentru a putea fi nregistrate, trebuiesc furnizate informaii despre numrul facturii, data, valuta n care se emite factura, precum i cursul valutar aferent i partenerul de afaceri. Dup cum se observ, pe form exist un buton numit Parteneri_LOV (List Of Values). Acest buton ajut la alegerea partenerului cu ajutorul unei liste derulante.

34 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Figura 4.5 Form pentru Facturile emise

Figura 4.6 Form pentru Facturile primite in lei 35 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Figura 4.7 Form pentru Facturile primite n valut

Figura 4.8 Form pentru extrasele de cont

36 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Dup cum se observ, att n form-ul pentru nregistrarea facturilor intrate n lei, ct i n formul pentru nregistrarea facturilor intrate n devize, exist dou butoane (Operatii_LOV i Parteneri_LOV) acestea permit alegere informaiilor despre operaiile contabile la care se refer i despre partenerii de afaceri pe baza unei liste derulante. Diferena dintre cele dou formuri este reprezentat de cmpurile valut i cursul valutar. n formularul de nregistrare a extraselor de cont exist, pentru fiecare linie din extras, cte un buton pentru alegerea dintr-o list derulant a partenerilor care sunt pltii sau ncasai.

4.4 Proiectarea bazei de date


Schema conceptual a bazei de date este prezentat n Figura 4.9 Schema conceptual a bazei de date. Se observ c principalele tabele din baza de date sunt: Parteneri (practic centrul bazei de date, ceea ce e i normal, n condiiile n care o ntreprindere nu are cum s existe fr operaiunile contabile cu partenerii din mediul de afaceri), facturi primite i emise, mpreun cu liniile din facturi. n continuare se prezint componena ctorva din cele mai importante tabele, urmnd ca, n anexe, s fie prezentate codurile de creare ale acestora: Parteneri ( ID_Partener number, Den_Part varchar2(40), CUI-CNP varchar2(20), Tara varchar 2(20), Localitate varchar2(20), Adresa varchar2(50), Tip_partener varchar2(30)) Facturi_Emise ( ID_Fact_Emise varchar2(20), ID_Parteneri number, Data date, ID_operatie number, Valuta varchar2(3), Curs_valuta number(5,4)) Fact_Prim_Ron (ID_Fact_Ron varchar 2(20), ID_Parteneri number, Data date, ID_operatie number )

37 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Figura 4.9 Schema conceptual a bazei de date

38 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului

Exemplu de creare a unei tabele din baza de date (restul vor fi prezentate n anexe):
CREATE TABLE LINIE_EXTRAS ( ID_LIN_EXTRAS NUMBER NOT NULL , NR_DOC VARCHAR2(12 BYTE) NOT NULL , DATA_DOC DATE NOT NULL , SUMA_PLATA NUMBER(10, 2) DEFAULT 0.00 , SUMA_INCASARE NUMBER(10, 2) DEFAULT 0.00 , ID_PARTENERI NUMBER , ID_EXTRAS NUMBER NOT NULL , CONSTRAINT LINIE_EXTRAS_PK PRIMARY KEY ( ID_LIN_EXTRAS , ID_EXTRAS ) ENABLE ) LOGGING TABLESPACE "SYSTEM" PCTFREE 10 PCTUSED 40 INITRANS 1 STORAGE ( INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT );

ALTER TABLE LINIE_EXTRAS ADD CONSTRAINT LINIE_EXTRAS_EXTRASE_CONT_FK1 FOREIGN KEY ( ID_EXTRAS


39 | P a g i n a

Capitolul IV Proiectarea i implementarea sistemului ) REFERENCES EXTRASE_CONT ( ID_EXTRAS ) ENABLE;

ALTER TABLE LINIE_EXTRAS ADD CONSTRAINT LINIE_EXTRAS_PARTENERI_FK1 FOREIGN KEY ( ID_PARTENERI ) REFERENCES PARTENERI ( ID_PARTENER ) ENABLE;

ALTER TABLE LINIE_EXTRAS ADD CONSTRAINT LINIE_EXTRAS_CHK1 CHECK (DATA_DOC LIKE 'DD/MM/YYYY') ENABLE;

ALTER TABLE LINIE_EXTRAS ADD CONSTRAINT LINIE_EXTRAS_CHK2 CHECK ((SUMA_PLATA > 0.00 AND SUMA_INCASARE = 0) OR (SUMA_PLATA = 0 AND SUMA_INCASARE > 0)) ENABLE;

40 | P a g i n a

Concluzii

Concluzii
Aplicaia a fost creat cu scopul de a simplifica i personaliza necesitile n materie de software pentru nregistrrile contabile n cadrul unei companii centru de cost. Aceasta are nevoie de o baz de date special creat pentru a fi axat pe facturile, documentele intrate n firm, mai puin (sau chiar deloc) pe bunurile sau serviciile vndute. De asemenea, aplicaia este creat pornind de la premiza c ntreprinderea nu lucreaz cu cash, toate fluxurile de numerar fiind nregistrate prin contul bancar; de aceea, nu este nevoie nici de modul pentru nregistrarea registrului de cas. Aplicaia realizat reprezint punctul de pornire pentru o baz de date complet pentru o companie centru de cost. Dup cum se observ, costurile pentru ntreinerea i administratea bazei de date ar fi extrem de mici, tocmai pentru c aceasta este axat direct pe nevoi, deavnd module n plus. Lucrarea de fa a fost structurat n patru pri, fiecare avnd cte un capitol corespondent. Astfel, n primul capitol s-a fcut introducerea n problema economic tratat, i anume nevoia de nregistrare a documentelor unei ntreprinderi. n cel de-al doilea capitol au fost prezentate tehnologiile folosite pentru dezvoltarea aplicaiei (i anume Oracle Database 11g Express Edition, SQL i Oracle Forms). Urmtoarele dou capitole s-au axat pe analiza, proiectarea i implementarea programului informatic, avnd n vedere crearea de diagrame UML (diagrama cazurilor generale de utilizare, diagrame de stare, diagrama de clase etc), prezentarea ferestrelor aplicaiei i, nu n ultimul rnd, schema conceptual a bazei de date. n anexe vor fi prezentate codurile de creare ale tabelelor din modelul relaional. n continuare voi avea n vedere detalierea bazei de date, pentru calculul TVA-ului pentru ntreprindere, crearea rapoartelor pentru Balana de Verificare i Bilan, introducerea de noi tabele pentru diferite alte tipuri de documente i, nu n ultimul rnd, rafinarea interfeei grafice.

41 | P a g i n a

<Bibliografie

Bibliografie
1. Legea Contabilitii - nr 82/1991. 1991. Capitolul 1, Art.2, Alineatul 1. 2. Maria, ROBU Doina. Contabilitate General. Bucureti : Editura Didactic i Pedagogic, 1993. 3. CARAIANI, Chirata i DUMITRANA, Mihaela. Bazele Contabilitii. Bucureti : Editura Universitar, 2009. UNV973-749-426-9. 4. Ion, LUNGU. Baze de date Oracle - Limbajul SQL. Bucureti : ASE, 2005. 5. VELICANU, Manole, LUNGU, Ion i MUNTEAN, Mihaela. ORACLE - Platform pentru baze de date. Bucureti : Editura Petrion, 2002. 6. Mark, TOWNSEND. Oracle Corporation. Oracle Corporation Web Site. [Interactiv] February 2011. [Citat: 15 June 2012.] http://www.oracle.com/us/products/database/039448.pdf. 7. WIKIPEDIA. SQL. Wikipedia - Enciclopedie liber. [Interactiv] Wikipedia, 26 Mai 2012. [Citat: 14 Iunie 2012.] http://ro.wikipedia.org/wiki/SQL. 8. Scritube. Prezentarea produsului software. ScriTube. [Interactiv] [Citat: 10 Mai 2012.] http://www.scritube.com. 9. Alex, BACIU. UML - Concept - Prezentare generala. IT Zone. [Interactiv] [Citat: 20 May 2012.] http://www.itzone.ro. 10. techit.ro. Tutorial UML. TechIT. [Interactiv] [Citat: 13 Mai 2012.] http://www.techit.ro/. 11. MICROSOFT. Introduction to the C# Language and the .NET Framework. Visual Studio. [Interactiv] Microsoft, 2010. [Citat: 17 Iunie 2012.] http://msdn.microsoft.com/library/z1zx9t92.aspx. 12. Cristian, CIUREA. Introducere in C#. Ciurea Cristian-Eugen Personal Web Site. [Interactiv] [Citat: 21 Mai 2012.] http://cristianciurea.ase.ro/PAW/IntroducereInCSharp.pdf. 13. O`BRIAN, Larry i ECKEL, Bruce. Thinking in C#. s.l. : Prentice Hall PTR, 2002.

42 | P a g i n a

Anexe

Anexe

43 | P a g i n a

CREATE TABLE DATESOC ( DENUMIRE VARCHAR2(30 BYTE) NOT NULL , CUI VARCHAR2(20 BYTE) NOT NULL , REGCOM VARCHAR2(20 BYTE) , BANCA VARCHAR2(30 BYTE) , CONTBANCA VARCHAR2(25 BYTE) , LOCALIT VARCHAR2(20 BYTE) , JUDET VARCHAR2(20 BYTE) , ADRESA VARCHAR2(50 BYTE) , CONSTRAINT DATESOC_PK PRIMARY KEY ( DENUMIRE , CUI ) ENABLE ) LOGGING TABLESPACE "SYSTEM" PCTFREE 10 PCTUSED 40 INITRANS 1 STORAGE ( INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT );

CREATE TABLE EXTRASE_CONT ( ID_EXTRAS NUMBER NOT NULL , NUMAR_EXTRAS VARCHAR2(12 BYTE) NOT NULL , DATA DATE DEFAULT SYSDATE NOT NULL , VALUTA VARCHAR2(3 BYTE) DEFAULT 'RON' NOT NULL , ID_OPERATIE NUMBER DEFAULT NULL NOT NULL , CONSTRAINT EXTRASE_CONT_PK PRIMARY KEY ( ID_EXTRAS ) ENABLE

CREATE TABLE FACT_EMISE ( ID_FACT_EMISE VARCHAR2(20 BYTE) NOT NULL , ID_PARTENERI NUMBER NOT NULL , DATA DATE DEFAULT SYSDATE NOT NULL , ID_OPERATIE NUMBER DEFAULT NULL NOT NULL , VALUTA VARCHAR2(3 BYTE) DEFAULT 'RON' NOT NULL , CURS_VALUTA NUMBER(5, 4) DEFAULT 1.0000 NOT NULL , CONSTRAINT FACT_EMISE_PK PRIMARY KEY ( ID_FACT_EMISE ) ENABLE )

CREATE TABLE FACT_PRIM_DEV ( ID_FACT_DEV VARCHAR2(20 BYTE) NOT NULL , ID_PARTENERI NUMBER NOT NULL , DATA DATE DEFAULT SYSDATE NOT NULL , ID_OPERATIE NUMBER DEFAULT NULL NOT NULL , VALUTA VARCHAR2(3 BYTE) NOT NULL , CURS_VALUTA NUMBER(5, 4) DEFAULT 1.0000 NOT NULL , CONSTRAINT FACT_PRIM_DEV_PK PRIMARY KEY ( ID_FACT_DEV ) ENABLE )

CREATE TABLE FACT_PRIM_RON ( ID_FACT_RON VARCHAR2(20 BYTE) NOT NULL , ID_PARTENERI NUMBER NOT NULL , DATA DATE NOT NULL , ID_OPERATIE NUMBER DEFAULT NULL NOT NULL , CONSTRAINT FACTPRIMRON_PK PRIMARY KEY ( ID_FACT_RON ) ENABLE )

CREATE TABLE LINIE_EXTRAS ( ID_LIN_EXTRAS NUMBER NOT NULL , NR_DOC VARCHAR2(12 BYTE) NOT NULL , DATA_DOC DATE NOT NULL , SUMA_PLATA NUMBER(10, 2) DEFAULT 0.00 , SUMA_INCASARE NUMBER(10, 2) DEFAULT 0.00 , ID_PARTENERI NUMBER , ID_EXTRAS NUMBER NOT NULL , CONSTRAINT LINIE_EXTRAS_PK PRIMARY KEY ( ID_LIN_EXTRAS , ID_EXTRAS ) ENABLE )

CREATE TABLE LINIE_FACT_DEV ( IDFACTLINDEV NUMBER NOT NULL , EXPLICATIE VARCHAR2(30 BYTE) NOT NULL , CANTITATE NUMBER DEFAULT 1 NOT NULL , PRET_VALUTA NUMBER(10, 2) NOT NULL , ID_TVA NUMBER NOT NULL , ID_FACT_DEV VARCHAR2(20 BYTE) NOT NULL , CONSTRAINT LINIE_FACT_DEV_PK PRIMARY KEY ( IDFACTLINDEV , ID_FACT_DEV ) ENABLE )

CREATE TABLE LINIE_FACT_EMISE ( IDFACTLINEMISE NUMBER NOT NULL , EXPLICATIE VARCHAR2(30 BYTE) DEFAULT NULL NOT NULL , SUMA NUMBER(10, 2) NOT NULL , ID_TVA NUMBER NOT NULL , ID_FACT_EMISE VARCHAR2(20 BYTE) NOT NULL , CONSTRAINT LINIE_FACT_EMISE_PK PRIMARY KEY ( IDFACTLINEMISE , ID_FACT_EMISE )

ENABLE )

CREATE TABLE LINIE_FACT_RON ( IDFACTLINRON NUMBER NOT NULL , EXPLICATIE VARCHAR2(30 BYTE) NOT NULL , CANTITATE NUMBER(6, 2) DEFAULT 1 NOT NULL , PRET NUMBER(7, 2) NOT NULL , ID_TVA NUMBER NOT NULL , ID_FACT_RON VARCHAR2(20 BYTE) NOT NULL , CONSTRAINT LINIE_FACT_RON_PK PRIMARY KEY ( IDFACTLINRON , ID_FACT_RON ) ENABLE )

CREATE TABLE LINIE_NOTA_CTB ( ID_NOTA_CTB NUMBER NOT NULL , ID_NOTA NUMBER NOT NULL , CONT_DEBIT VARCHAR2(20 BYTE) NOT NULL , CONT_CREDIT VARCHAR2(20 BYTE) NOT NULL , VALOARE_DEBIT NUMBER(12, 2) NOT NULL , VALOARE_CREDIT NUMBER(12, 2) NOT NULL , CONSTRAINT LINIE_NOTA_CTB_PK PRIMARY KEY ( ID_NOTA_CTB , ID_NOTA ) ENABLE )

CREATE TABLE NOTA_CONTABILA ( ID_NOTA NUMBER NOT NULL , DATA DATE , ID_OPERATIE NUMBER NOT NULL , CONSTRAINT NOTA_CONTABILA_PK PRIMARY KEY ( ID_NOTA ) ENABLE

CREATE TABLE OPERATII_CONTABILE ( ID_OPERATIE NUMBER NOT NULL , DENUMIRE_OPERATIE VARCHAR2(40 BYTE) NOT NULL , IDTIPDOC NUMBER NOT NULL , CONSTRAINT OPERATII_CONTABILE_PK PRIMARY KEY ( ID_OPERATIE ) ENABLE )

CREATE TABLE PARTENERI ( ID_PARTENER NUMBER NOT NULL , DEN_PART VARCHAR2(40 BYTE) NOT NULL , CUI_CNP VARCHAR2(20 BYTE) NOT NULL , TARA VARCHAR2(20 BYTE) NOT NULL , LOCALITATE VARCHAR2(20 BYTE) , ADRESA VARCHAR2(50 BYTE) , TIP_PARTENER VARCHAR2(30 BYTE) NOT NULL , CONSTRAINT FURNIZORI_PK PRIMARY KEY ( ID_PARTENER ) ENABLE )

CREATE TABLE PLAN_CONTURI ( SIMBOL_CONT VARCHAR2(10 BYTE) NOT NULL , DENUMIRE_CONT VARCHAR2(100 BYTE) NOT NULL , TIP_CONT VARCHAR2(1 BYTE) NOT NULL , ID_PARTENER NUMBER , CONSTRAINT PLAN_CONTURI_PK PRIMARY KEY ( SIMBOL_CONT ) ENABLE )

CREATE TABLE SCHEMA_CONTARE (

ID_SCHEMA_CONTARE NUMBER(*, 0) NOT NULL , EXPLICATIE_SCHEMA VARCHAR2(30 BYTE) NOT NULL , DEBIT1 VARCHAR2(6 BYTE) NOT NULL , CREDIT1 VARCHAR2(6 BYTE) NOT NULL , DEBIT2 VARCHAR2(6 BYTE) , CREDIT2 VARCHAR2(6 BYTE) , ID_OPERATIE NUMBER , CONSTRAINT SCHEMA_CONTARE_PK PRIMARY KEY ( ID_SCHEMA_CONTARE ) ENABLE )

CREATE TABLE TIPURIDOCUMENTE ( IDTIPDOC NUMBER(3, 0) NOT NULL , DENUMIRE VARCHAR2(30 BYTE) , CONSTRAINT TIPURIDOCUMENTE_PK PRIMARY KEY ( IDTIPDOC ) ENABLE )

CREATE TABLE TVA ( ID_TVA NUMBER(*, 0) NOT NULL , TIP_TVA VARCHAR2(20 BYTE) NOT NULL , CONSTRAINT TVA_PK PRIMARY KEY ( ID_TVA ) ENABLE )