UNIVERSITATEA “SPIRU HARET” CONSTANŢA

FACULTATEA DE MANAGEMENT FINANCIAR CONTABIL

SPECIALIZAREA CONTABILITATE ŞI INFORMATICĂ DE GESTIUNE

LUCRARE DE LICENŢĂ

APLICAŢIE INFORMATICĂ PENTRU

GESTIUNEA MIŞCĂRILOR DE VALUTĂ
LA O CASĂ DE SCHIMB VALUTAR

Coordonator ştiinţific: lector dr. Gheorghe Popescu

Absolventă:

Constanţa
- 2006 -

1
CUPRINS

Pag.

2
 INTRODUCERE .......................................................................................... 4

CAPITOLUL I Concepte de bază ale proiectării sistemelor

informatice .............................................................................................. 6
.......
1.1. Generalităţi despre metodele de proiectare şi realizare a sistemelor
informatice............................................................................................... 6
........
1.2. Modelarea conceptuală a datelor. Modelul entitate-asociere..................... 7
1.2.1. Concepte de bază …………………………………………………………... 7
1.2.2 Restricţii de integritate ……………………………………………………. 8
1.2.3 Subtipuri de entitati ………………………..……………………………… 9
1.2.4. Reguli referitoare la Modelul Conceptual al Datelor (MCD )………….... 10
1.3. Modelarea conceptuală al prelucrărilor. Concepte de bază ……………. 12
1.3.1 Concepte de bază …………………………………………........................... 12
1.3.2 Noţiunea de proces……………………………………................................. 15
1.4. Validarea modelelor ……………………...................................................... 18
1.4.1. Modelele externe ale datelor ………………………..................................... 18
1.4.2. Principiul validării modelelor ……………….............................................. 19
1.4.3. Reguli de validare în consultare …………………....................................... 19
1.4.4. Reguli de validare în actualizare ……………….......................................... 19
1.5 Modelarea logică a datelor (MLD)………………………………………… 19
1.5.1 Cadru general……………………………………………………………… 19
1.5.2. Modelul relaţional…………………………………………………………... 20
1.5.3. Trecerea de la MCD la MLD relaţional…………………………………... 21
1.6 Modelarea Logică a Prelucrărilor (MLP…………………………………. 21
1.7. Strategia de urmat pe timpul elaborării programelor prin care se va
materializa acest proiect................................................................................ 22

CAPITOLUL II Aplicarea teoriei proiectării sistemelor informatice în

cazul casei de schimb 23
valutar.........................................................................
2.1. Modelare globală …....................................................................................... 23
2.1.1. S.C. M&S Exchange S.R.L........................................................................... 23
2.1.2 Obiectivele aplicaţiei...................................................................................... 24
2.2. Modelarea conceptuală.................................................................................. 25
2.2.1. Intrările şi ieşirile aplicaţiei........................................................................... 25
2.2.2. Sistemul de codificare..................................................................................... 27
2.2.3. Modelul conceptual de comunicaţie (MCC)................................................. 27
2.2.4. Modelul conceptual de date (MCD).............................................................. 29
2.2.5. Modelul conceptual de prelucrare (MCP).................................................... 29
2.3. Modelarea logică............................................................................................. 29
2.3.1. Dicţionarul atributelor…………………....................................................... 29
2.3.2. Modelul logic de comunicaţie MLC)............................................................. 30
2.3.3. Modelul logic de date (MLD)........................................................................ 30
2.3.4. Modelul logic de prelucrare (MLP).............................................................. 31
2.4. Modelarea fizică…………………………………………………………….. 31
2.4.1 Modelul fizic de comunicaţie (MFC)............................................................ 31
2.4.2. Videoformatele de I/E.................................................................................. 31
2.4.3. Meniul aplicaţiei……………………………………………………………. 32
2.4.4. Scheme de proceduri logice utile pentru obţinerea unor rapoarte……… 32
2.5 Manual de utilizare a programului pentru casa de schimb valutar ......... 34
3
2.5.1. Funcţiile programului.................................................................................... 34
2.5.2. Implementarea programului......................................................................... 35
2.5.3. Procesarea mişcărilor..................................................................................... 37
2.5.4. Rapoarte.......................................................................................................... 39
2.5.5. Inchiderea zilei................................................................................................ 42

CAPITOLUL III Contabilitatea activităţii de schimb valutar………….. 43

3.1. Sinteză privind organizarea şi funcţionarea caselor de schimb valutar.... 43
3.2. Contabilitatea activităţii de schimb valutar 44

CONCLUZII ................................................................................................. 46

BIBLIOGRAFIE ........................................................................................... 48

ANEXA : Lista programelor sursă………………………………………... 49

4
 INTRODUCERE

Această lucrare de licenţă se referă la gestiunea mişcărilor de valute ce au loc la o casă de

schimb valutar, unde după cum se ştie au loc şi alte activităţi cum ar fi schimburile valutare şi
elaborarea documentelor de sinteză specifice unei case de schimb valutar. Ca urmare, este clar
că în practică, ea trebuie să fie una din funcţiunile programului de informatizare a casei de
schimb valutar şi împreună cu funcţiunea de gestiune a schimbului valutar să asigure datele
necesare pentru elaborarea documentelor de sinteză specifice unei case de schimb valutar.
Delimitarea ei de celelalte funcţiuni este una artificială impusă de limitele unei lucrări de
licenţă şi ca urmare lucrarea va face şi unele referiri la documentele de sinteză specifice unei
case de schimb valutar, în special acele documente care fac referire şi la mişcărilede valute.
Deşi în practică această aplicaţie nu este de conceput să fie folosită independent, pentru a
satisface cerinţele unei aplicaţii de sine stătătoare, ea poate îndeplini următoarele funcţiuni:
- implementarea aplicaţiei într-o casă de schimb valutar dată;
- preluare mişcări de valută între bănci şi casa de schimb sau un punct de schimb valutar
aparţinând casei de schimb care posedă programul;
- preluare mişcări de valută între casa de schimb sau un punct de schimb valutar şi alt punct
de schimb;
- înregistrarea automată în baza de date a sistemului a tuturor mişcărilor de valută;
- elaborarea de rapoarte specifice activităţii de schimb valutar:
- Raport BNR;
- Totaluri mişcări;
- Registru de casă;
- Lista de rotare;
- Jurnal indicatori sintetici;
- Jurnal solduri şi rulaje.
- consultarea tabelelor cu mişcări şi tabelului de încasări-plăţi pentru documentarea reviziilor
financiare, şi a verificărilor cu scop de investigaţii.

Lucrarea este structurată pe trei capitole:

- capitolul I conţine o sinteză a teoriei privitoare la proiectarea sistemelor informatice cu
accent pe prezentare a metodei MERISE;
- capitolul II este o aplicare a teoriei privind proiectarea sistemelor informatice în cazul
aplicaţiei de gestiune a mişcărilor de valută în cadrul unei case de schimb valutar.
- capitolul III, conţine o sinteză privind organizarea, funcţionarea şi rolul caselor de schimb
valutar şi se încheie cu contabilitatea activităţii de schimb valutar.
În cadrul acestei aplicaţii, am urmărit să ofer utilizatorului soluţii informatice pentru
momentele principale specifice mişcărilor de valută. Astfel aplicaţia este prevăzută cu o
opţiune bară numită Mişcări care permite utilizatorului să elaboreze buletine de mişcare de
valută sub toate formele sale, prin intermediul registrului electronic de încasări şi plăţi să
revadă mişcările de valută efectuate în trecut în cadrul casei de schimb valutar şi în final, să
elaboreze raportul numit Totaluri mişcări, cerut de legislaţia în vigoare.
Rapoartele se obţin cu opţiunea de meniu numită “Rapoarte“ de unde se pot alege opţiuni
pentru rapoarte ca registru de casă, raport BNR,lista de rotare, jurnalul indicatori sintetici şi
jurnalul de solduri şi rulaje.
La sfârşitul zilei, utilizatorul poate alege opţiunea “Închiderea zilei”, când se vor elabora toate
datele necesare pentru situaţiile zilnice, se vor obţine unele rezultate statistice pregătitoare
pentru situaţiile lunare şi se vor iniţializa câmpurile rezervate rulajelor, soldurilor şi cursului
mediu cu care va începe ziua următoare.
Din motive legate de protejarea aplicaţiei împotriva unor fraude, aplicaţia a fost astfel
concepută încât operatorul nu are acces la buletinele de schimbare de valută şi nici la cele de
operaţii cu banca sau între casa de schimb valutar şi punctele sale de schimb, decât din
5
momentul în care începe să le redacteze şi până le tipăreşte. Ulterior poate vedea oricare din
aceste documente, le poate chiar studia după diferite criterii, dar nu le mai poate modifica.
Tot pentru securitatea datelor stocate în sistem, la pornirea aplicaţiei operatorul trebuie să-şi
prezinte parola sa şi dacă a fost acceptat pentru corectitudinea parolei sale, atunci codul
operatorului este înregistrat în calculator pe fiecare schimb de valută şi pe fiecare tranzacţie
efectuată cu banca sau între casa de schimb valutar şi punctele sale de schimb.
În cadrul capitolului II sunt prezentate schemele logice ale unor proceduri de obţinere a
ieşirilor mai dificile ale acestei aplicaţii, scheme care demonstrează clar că prelucrările
necesare pentru obţinerea acestor ieşiri sunt suficient de complicate pentru ca mişcările de
valută în cadrul unei case de schimb valutar să se constituie într-o temă de sine stătătoare
adecvată pentru o lucrare de licenţă.

6
CAPITOLUL I

Concepte de bază ale proiectării sistemelor informatice

1.1.Generalităţi despre metodele de proiectare şi

realizare a sistemelor informatice
Acestea au avut o evoluţie
evoluţie structurabilă în trei generaţii de metode, determinată de:
- Creşterea ariei de utilizare a instrumentului informatic;

- Creşterea gradului de complexitate a aplicaţiilor şi a cerinţelor de

integrare;
- Necesitatea diminuării costurilor, creşterii productivităţii şi reducerii
riscurilor de realizare;
- Evoluţia structurii şi tipologiei aplicaţiilor de gestiune: SIG, SIAD, SE,
SIE, birotică, multimedia;
- Influenţa exercitată de evoluţia limbajelor de programamre, a
S.G.B.D., a reţelelor de calculatoare, a tehnicilor de gestiune în timp real etc.
Cele trei generaţii de metode sunt metodele ierarhice, sistemice şi orientate obiect
(obiectuale).
Metodele ierarhice
Ele aparţin primei generaţii care a apărut prin anii '70. Conform acestor metode sistemul
informaţional/informatic este structurat pe baza funcţiilor sale. Ele sunt centrate pe analiza
funcţională: adică fiecare funcţie identificată se subdivide ierarhic în subfuncţii, continuând în
această manieră până se ajunge la componente suficient de mici astfel încât acestea să poată fi
programate cu uşurinţă;
Avantaje:
Simplitate, bună adaptare la definirea cerinţelor utilizatorului;
Dezavantaje:
Concentrează efortul de analiză asupra funcţiilor (de prelucrare) neglijând coerenţa
datelor (a căror structură este totuşi mult mai stabilă decât a prelucrărilor); volatilitatea
cerinţelor utilizatorilor (funcţiilor) face ca aplicaţiile să fie într-o aproape continuă
reconsiderare.

Metodele sistemice reprezintă generaţia a doua, care a apărut prin anii '80;
- se bazează pe aplicarea teoriei sistemelor în analiza întreprinderii;
- sistemul informaţional/informatic este abordat sub două aspecte complementare: datele şi
prelucrările, care sunt studiate şi modelate independent şi reunite cât mai târziu cu putinţă;
- acordă prioritate datelor faţă de prelucrări;
- respectă cele trei nivele de concepţie introduse prin raportul ANSI/SPARC/X31: extern,
conceptual, intern;
intern;
- exemple : MERISE, AXIAL, Information Engineering (J. Martin).
Avantaje:
Avantaje: sistemele se axează pe conceptul de bază de date, care oferă mai multă coerenţă,
stabilitate şi elimină redondanţele;
Dezavantaje:
Dezavantaje: deficienţe în modelarea prelucrărilor, posibilitatea apariţiei de discordanţe între
modelele datelor şi ale prelucrărilor.

Metodele orientate obiect (obiectuale)

- se constituie în generaţia a treia, apărută prin anii '90;
- conform acestor teorii sistemul informaţional/informatic este perceput ca o structură de
obiecte autonome, ce se organizează şi cooperează între ele;
7
 - un obiect are un anumit comportament, definit prin ansamblul operaţiilor (serviciilor) pe
care le poate efectua; datele şi prelucrările prin care este implementat acest comporta-
ment sunt încapsulate (maschate) şi sunt inaccesibile celorlalte obiecte;
- fiecare obiect poate participa la compunerea altor obiecte mai complexe;
- fiecare obiect poate interveni în mai multe funcţii sau scenarii funcţionale diferite;
Avantaje: permite reutilizarea componentelor de program, favorizează modelarea şi
utilizarea de obiecte complexe.
Dezavantaje: percepţia şi reprezentarea monolitică de tipul " totul este obiect " nu
corespunde întotdeauna realităţii reprezentate.

Materialul care urmează în continuare se referă la modelele specifice metodelor sistemice.

Nivele de abstractizare şi modelare în cadrul metodelor sistemice
Legătura dintre nivelul de la care este privit sistemul informaţional şi modelele care se
întocmesc pentru acesta este dată în tabelul de mai jos.
Nivele Date Prelucrari
Conceptual Model conceptual MCD Model conceptual MCP
Organizaţional Model logic MLD Model organizaţional MOP
Fizic Model fizic MFD Model operaţional MOpP

1.2.
1.2. Modelarea conceptuală a datelor. Modelul entitate-asociere
1.2.1. Concepte de bază
Entitate:
- reprezentarea unui "obiect" concret sau abstract care:
- aparţine spaţiului problemei de rezolvat (face parte sau este relevant
pentru realitatea observată);
- are o existenţă de sine stătătoare;
- poate fi identificat în raport cu celelalte obiecte de acelaşi tip.
Exemple: angajat, produs, utilaj, operaţie tehnologică, client, factură
O entitate este reprezentată printr-un ansamblu de atribute.
Atribut: caracteristică sau proprietate a unei entităţi, semnificativă pentru spaţiul problemei
de rezolvat.
Entitatea este percepută aici ca un tip de “obiecte”. Fiecare obiect individual constituie o
realizare a entităţii respective.
Atributele au, la rândul lor, aceeaşi conotaţie tipologică, în sensul că despre orice realizare a
unei anumite entităţi se cunosc aceleaşi atribute, dar pentru fiecare dintre acestea conţinutul
sau valoarea atributelor respective diferă.
Tipuri de valori ale atributelor: un anumit ansamblu de valori, definite fie printr-o
proprietate fie printr-o enumerare.
- simplu: atunci când pentru o entitate sau o asociere poate lua o singură
valoare;
- repetitiv: dacă pentru o entitate sau o asociere poate lua mai multe valori (ex:
limbi străine cunoscute)

Reguli privitoare la atribute:

- fiecare atribut poate apare într-o singură entitate (principiul
nonredondanţei)
- un atribut poate avea numai valori elementare.

Identificatorul entităţii: un atribut sau un grup de atribute care primesc valori unice pentru fiecare
realizare a entităţii respective şi pot servi astfel pentru identificarea fără echivoc a acestora.

8
Pentru simplitate se recurge frecvent la coduri care sunt atribute construite special astfel încât să
răspundă cerinţelor de identificare (ex: marcă salariat) sau la atribute de tip "număr de ordine" sau
"număr de apariţie" (ex: numărul de inventar al unui mijloc fix).
În reprezentarea grafică, identificatorul entităţii se subliniază.
Asocierea:
Asocierea: reprezentarea legăturii sau corespondenţei existente între două sau mai multe
realizări de entităţi.
entităţi.
O asociere nu are existenţă de sine stătătoare,
stătătoare, depinzând de existenţa realizărilor de entităţi
pe care le leagă.; în consecinţă, nu are identificatori specifici.
O asociere poate avea atribute proprii.
Entităţile care participă la o asociere constituie colecţia acesteia.
Numărul de entităţi care participă la o asociere formează dimensiunea sau gradul acesteia
(mai mare sau egală cu numărul de entităţi al colecţiei).
Cardinalitatea minimală / maximală exprimă modul de participare al realizărilor fiecărei
entităţi la asociere ( valori uzuale:0,1; 1,1; 0,n; 1,n ).

Reprezentarea grafică:

Asociere

Nume Cardinalitate
asociere
minimalã maximalã

ANGAJAT ÎNCADRAT-LA COMPARTIMENT

1,1 0,n
Marcă Data încadrãrii Cod compartiment
Nume Den compartiment
Prenume
Data nasterii Atribut al asocierii
Salariu
unar
Colecţie: ANGAJAT, COMPARTIMENT
Dimensiune: 2 (asociere binarã)

Între realizările aceloraşi entităţi pot exista mai multe asocieri diferite, cu semantică şi
cardinalităţi distincte.
Asociere reflexivă: o asociere care leagă realizări diferite ale aceleiaşi entităţi (colecţie = 1).
În asemenea cazuri, este indispensabilă specificarea în schemă a rolurilor jucate de entitate.
Rol al entităţii: nume care serveşte pentru a desemna participarea entităţii la o asociere.

1.2.2. Restricţii de integritate. Sunt reguli suplimentare, nereprezentabile direct în

formalismul EA, care trebuie respectate permanent de date.
a) Restricţii de integritate structurale: inerente conceptelor folosite la modelare:
- integritatea entităţii:
entităţii: valorile luate de identificatorul entităţii trebuie să fie unice şi nenule;
- integritatea referenţială:
referenţială: pentru orice realizare a unei asocieri este obligatorie existenţa
realizările entităţilor participante.

- Cardinalitatea:
- Cardinalităţile minimale (0 şi 1)
- Cardinalităţile maximale (1 şi n

9
După momentul în care acţionează, există două clase de RI: statice şi dinamice.
dinamice.
R.I. Statice: condiţii care trebuie să se verifice permanent:
R.I. Dinamice: privesc evoluţia în timp a datelor.

b) Restricţii de domeniu
RI de domeniu sunt condiţii impuse asupra ansamblului de valori acceptate pentru un
atribut în cadrul tipului sau domeniului sau. Acestea pot viza:
- conţinutul unui singur atribut al unei entităţi sau asocieri;
- corelaţii între valorile mai multor atribute ale aceleiaşi entităţi sau asocieri;
- corelaţii între atributele mai multor entităţi sau asocieri diferite;
- corelaţii cu valori obţinute pe baza unor operaţii de sintetizare (numărare, însumare,
medie etc) a unui ansamblu de entităţi;
c) Incluziune, excluziune, egalitate de roluri
Acestea formulează reguli referitoare la rolurile jucate de un tip de entitate în diverse asocieri.
Incluziunea:
Incluziunea: dacă o entitate E joacă un rol r1 într-o asociere a1, a1, atunci trebuie să joace şi
rolul r2 într-o asociere a2.
a2.
Notaţia grafică: R1 I R2

Egalitatea: restricţia de incluziune între rolurile r1 si r2 ale entitătii este reciprocă.

Notaţia grafică:
R1 =
R2

Excluziunea:
Excluziunea: rolurile r1 si r2 ale entităţii se exclud reciproc.
Notatia grafică:
R1 R2
#

Incluziune, excluziune, egalitate de asocieri

Aceste restrictii impun condiţii care acţionează asupra tuturor rolurilor dintr-o asociere; cu
alte cuvinte, este vizată asocierea şi toate entităţile participante şi nu numai participarea unei
anumite entităţti, ca în cazul anterior.

1.2.
1.2.3. Subtipuri de entitati
În numeroase cazuri, în ansamblul entităţile ce aparţin unui anumit tip există subgrupuri cu o
anumită relevanţă pentru realitatea reflectată şi care, în consecinţă, trebuie reprezentate
explicit.
Grupurile de entităţi sunt numite subclase ale TE, acesta fiind, la rândul sau, superclasa
acestora. Spre exemplu, entităţile apartinând TE ANGAJAT pot fi grupate în MUNCITOR,
TEHNICIAN, INGINER, ECONOMIST etc. Fiecare entitate a unui asemenea grup este, în
acelaşi timp, o entitate a tipului ANGAJAT.
Definirea de subclase se poate face în două moduri:
- pe baza valorilor unui anumit atribut
- pe baza unor criterii definite de utilizator.
Prin definirea de subclase se efectuează specializarea entităţilor superclasei acestora (TE).
Acestea moştenesc toate atributele superclasei şi pot avea atribute proprii specifice,
inexistente la nivelul superclasei.
Spre exemplu, în subclasele MUNCITOR şi INGINER ale TE ANGAJAT dintr-o
întreprindere, alături de atributele comune, aferente oricărui angajat (Marca, Nume, Prenume,
Data nasterii, etc), pentru muncitori pot exista, suplimentar, atributele specifice Meserie şi
Nivel calificare iar pentru ingineri, atributul Specialitate.
Delimitând subansambluri de entităţi ale aceluiaşi tip de entitate, subclasele constituie
subtipuri ale acestuia.

10
 Generalizarea este procesul invers, prin care două sau mai multe tipuri de entităţi sunt
generalizate, pe baza proprietăţilor comune, într-un nou tip. În această relaţie, TE iniţiale
devin subtipuri ale tipului obţinut prin generalizare. Spre exemplu, tipurile de entităţi
ANGAJAT şi STUDENT dintr-o universitate pot fi generalizate prin tipul PERSOANa, care
va prelua atributele comune ale acestora: Nume, Prenume, Data nasterii, Adresa etc.
Maniera în care se procedează - prin specializare sau generalizare - depinde exclusiv
de cerinţele unei cât mai fidele reprezentări a realităţii.
Specializarea poate fi totală (orice entitate a tipului face parte, obligatoriu, dintr-un subtip)
sau partială (pot exista entităţi care sa nu aparţină nici unui subtip).
Între subtipuri poate exista un raport de excluziune, ceea ce traduce faptul că
fiecare entitate poate aparţine unui singur subtip (ca în exemplul anterior). Există însă şi
cazuri în care aceeaşi entitate poate aparţine mai multor subtipuri diferite (cu alte cuvinte,
submulţimile entităţilor aparţinând subclaselor respective nu sunt disjuncte). Aceasta RI este
reprezentată grafic prin intermediul simbolului de excluziune. În cazul în care nu există
exclusivitate, este foarte probabilă existenţa unei RI de incluziune, care să precizeze condiţiile
în care are loc "suprapunerea" entităţilor aparţinând fiecărui subtip.
Presupunând, spre exemplu, ca STUDENT si CADRU-DIDACTIC sunt subtipuri ale
TE PERSONAL-UNIVERSITATE, se poate formula următoarea restricţie de incluziune: pot
fi cadre didactice (preparatori, în speţă) numai studenţii de la studii aprofundate.
Cele două restricţii de integritate sunt total independente. Orice combinaţie între ele este
posibilă: parţial-exclusiv, parţial-inclusiv, total-exclusiv, total-inclusiv.
Introducerea de subtipuri prin specializare/generalizare prezintă două avantaje principale:
- factorizează proprietăţile comune la nivelul tipului (superclasei);
- face mult mai clară reprezentarea unor tipuri asocieri la care participă numai o parte dintre
entităţi.

1.2.4. Reguli referitoare la Modelul Conceptual al Datelor (MCD ( )

a) Unicitatea numelor.
Regula de unicitate a numelor se aplică tutoror elementelor ce apar în MCD: TE, TA,
atribute, roluri, RI. Prin urmare, se vor elimina eventualele posibile ambiguităţi prin utilizarea
de nume complete (ex: Nume angajat, Nume produs si nu, simplu, Nume, în ideea că
apartenenţa acestui atribut la un tip de entitate sau altul înlatură de la sine ambiguitatea).
Eliminarea omonimelor si sinonimelor. Atribute derivabile
Atributele derivabile sunt cele ale căror valori se obţin din valorile altor atribute, de
regulă prin relaţii de calcul (ex: Limita împrumut care poate fi determinat pe baza conţinutului
atributului Categorie cititor; Valoare produs comandat care poate fi obţinut înmulţind
Cantitatea comandata cu Preţul produsului respectiv).
În mod normal, aceastea trebuie eliminate din MCD, fiind redondante. Dacă însă prezintă o
semnificaţie particulară pentru problema studiată (facând, spre exemplu, obiectul unor RI
distincte), este posibilă menţinerea lor în schemă, însoţite de specificarea relaţiilor de calcul
sau derivare sub formă de RI.
b) Atribute repetitive sau decompozabile
Prezenţa acestora poate indica existenţa unor structuri care trebuie reprezentate ca atare. Ex:
pentru un student, reprezentarea rezultatelor la examene constituie un atribut repetitiv şi
decompozabil care indică existenţa unei asocieri între student şi disciplinele pentru care
trebuie să susţină examene.
Această regulă nu trebuie aplicată pentru orice atribut repetitiv sau decompozabil decât în
măsura în care conduce la evidenţierea unor elemente, entităţi sau asocieri semnificative
pentru problema reprezentată.
Spre exemplu, descompunerea atributului Adresa în Localitate, Strada, Numar etc va fi făcută
numai dacă delimitarea lor prezintă interes în raport cu percepţia existenta în realitatea
modelată.

11
c) Minimalitatea identificatorilor
Această regulă prevede ca, în cazul identificatorilor compuşi dintr-un grup de atribute sau
roluri, să nu existe un subgrup în interiorul acestora care să poată îndeplini funcţia de
identificator. Nerespectarea acestei reguli poate fi uşor evidenţiată prin examinarea
dependenţelor funcţionale dintre atributele sau rolurile ce compun identificatorul.
Existenţa unor atribute ale căror valori devin "nule" pentru anumite valori luate de alte
atribute. Această situaţie semnalează, în general, existenţa de subtipuri.

d) O asociere nu poate exista decât o singură dată între aceleaşi entităţi

Ca si entităţile, asocierilor trebuie să fie identificabile şi identificarea lor se face prin
entităţile participante (mai precis, prin identificatorii acestora). Condiţiile impuse
identificatorilor: valori nenule şi unice pentru fiecare element, trebuie respectate şi în cazul
asocierilor.
Considerând că ar exista cardinalităţi şi pentru asociere (nu numai pentru entităţi),
acestea ar trebui să fie întotdeauna 1,1.
Dacă pentru aceleaşi entiăţi apar mai multe asocieri (de acelaşi tip), înseamnă că restricţia de
unicitate este încalcată. Soluţia constă, în acest caz, în transformarea asocierii într-o noua
entitate.
Aceeaşi soluţie se impune şi în cazul în care participarea anumitor entităţi este opţională, ceea
ce face ca o parte din identificatorul asocierii să devină nedeterminată (nula). Spre exemplu,
produsele comandate de clienţi sunt livrate şi facturate.
Cum facturarea nu este făcută în acelaşi moment cu formularea comenzii, cardinalitatea
acesteia este 0,1. Rezolvarea constă şi aici în transformarea asocierii în entitate.

1.2.4.1. Dependenţe funcţionale (DF)

a) Dependenţe funcţionale simple.
Între două atribute A şi B există o dependenţă funcţională notată A®B dacă fiecărei valori a
lui A îi corespunde o singură valoare a lui B.
Spre exemplu,
exemplu, pentru un angajat se poate defini următoarea dependenţă funcţională:
Marca ® Nume
care exprimă faptul că unui angajat (identificat printr-un număr de marcă) îi corespunde un
singur nume. Relaţia inversă: Nume ® Marca nu este adevarată, deoarece pot exista mai
multe persoane cu acelaşi nume dar cu numere de marca diferite.
Pentru un angajat mai pot fi definite si alte DF:
Marca ® Prenume
Marca ® Data nasterii
Marca ® Functie
Atributul aflat în stânga DF este numit determinant.
determinant. Determinantul poate fi compus din unul
sau mai multe atribute.
b. Dependente funcţionale multivaloare
Între două atribute A şi B există o dependenţă funcţională multivaloare, notată:
A®®B
®®B
dacă o valoare a lui A determină un ansamblu de valori al lui B.
Dependenţa functională este un caz particular al dependenţei funcţionale multivalore.
multivalore.
Dependenţele funcţionale reprezintă RI.
- Identificatorul unei entităţi este un atribut sau un grup de atribute faţă de care toate
celelate atribute depind funcţional.
- Dependenţele funcţionale pot exista şi între entităţi şi asocieri.
- Cardinalităţile 1,1 corespund întotdeauna unor DF.

12
1.2.4.2.
1.2.4 Normalizarea
Normalizarea este un proces care asigură:
- eliminarea redondanţelor fără pierdere de informaţie semnificativă
- eliminarea anomaliilor manifestate în procesul actualizării.
Anomaliile se pot manifesta în procesul actualizării în cursul operaţiilor de adăugare,
ştergere şi modificare.
Există cinci forme de normalizare (FN) şi una intermediară între forma 3 şi 4 numită NFBC
după numele lui Boyce Codd - fondatorul modelului relaţional al bazelor de date..
FN1:
FN1: O entitate este în FN1 dacă toate atributele sale sunt elementare şi nerepetitive.
FN2:
FN2: O entitate este în FN2 daca respectă cerinţele FN1 şi toate atributele non-identificator
sunt dependente de întregul identificator.
FN3: impune FN2 + să nu existe dependenţe funcţionale tranzitive între caracteristicile non-
cheie. Pentru detalii despre celelalte forme de normalizare consultaţi anexa 1 din lucrarea de
laborator nr. 10.
FNBC (BOYCE_CODD ): ): O entitate este în FNBC dacă respectă cerinţele FN3 şi în plus
nici un atribut ce compune identificatorul nu depinde funcţional de un alt atribut.
FN4:
FN4: O entitate este în FN4 dacă:
- respectă cerinţele FNBC;
- nu prezintă dependente multivaloare.
FN5: impune FN4 + să nu aibă dependenţă ciclică (joints), sau dacă are să fie implicată printr-
o cheie secundară.

Normalizarea entitatilor
Normalizarea are drept scop eliminarea redondanţelor şi a anomaliilor de actualizare.
Deoarece prin cele menţionate anterior se elimină o parte dintre cazurile de nerespectare a
condiţiilor de normalizare (existenţa unui identificator, eliminarea atributelor repetitive sau
compuse), este necesar să se asigure o atenţie deosebită următoarelor două situaţii:
a) existenţa de DF tranzitive între atribute (FN3);
b) existenţa de DF parţiale între atributelor neidentificatoare şi identificator
(atunci când acesta este compus din mai multe atribute).
Ex: DF tranzitive existente între atributele entităţii UTILAJE conduc la descompunerea
acesteia în două tipuri de entităţi şi la introducerea asocierii corespunzătoare dintre ele.

Normalizarea asocierilor
Situaţia este similară entităţilor, cu observaţia că pentru asocieri nu există
identificatori proprii, rolul acestora fiind îndeplinit de identificatorii entităţilor participante.

1.3. Modelarea conceptuală al prelucrărilor.

1.3.1. Concepte de bază

Modelul conceptual al prelucrărilor prezintă succesiunea în timp a operaţiilor de
căutare la care este supus modelul conceptual al datelor, adică:
- ce trebuie făcut la nivel conceptual fără a indica
- cine, când şi unde se realizează aceste prelucrări (conceptul organizational);
- cum se vor realiza ele în mod concret (conceptul fizic);
- are drept scop să descrie conţinutul (ce operaţii ?, ce rezultate ?) şi dinamica (derularea în
timp) unei prelucrări într-o manieră independentă de utilizare a mijloacelor utilizate.
Modelul conceptual al prelucrărilor este modelul "eveniment-rezultat" al metodei
Merise, ce repune în discuţie procedurile (elementele) abordate de MCD formulând pentru
fiecare element intrebări de forma:
- acest element este indispensabil şi ce se întâmplă dacă îl suprimăm;
- există posibilitatea de a-l suprima (atenţie la normele juridice şi reglemantările legale;

13
- cât costă menţinerea acestui elemet în procedură sau ce avantaje se obţin din menţinerea lui.
Modelul conceptual al prelucrărilor, vede întreaga prelucrare ca o succesiune ordonată
şi logică de proceduri înlănţuite, toate în concordanţă strictă cu legislaţia în vigoare (este
vorba de un demers tipic de analiză a valorilor).
Nu se poate trece cu vederea impactul utilizării instrumentului informatic (SGBD) asupra
MCP. Astfel, anumite validări pot fi efectuate încă de la culegerea datelor, în loc să se constate
ulterior că datele sunt complete sau eronate, deci anumite operaţii din MCP pot fi eliminate.
Ca şi în cazul modelului conceptual al datelor, formalismul modelelor de prelucrare se
bazează pe construirea unei diagrame având patru elemente de bază:
a) evenimentul declanşator, reprezentat grafic printr-o elipsă, de la care pleacă o
săgeată de legătură pentru simplificare, dacă este necesar, elipsa poate fi omisă
b) operaţia, reprezentată grafic printr-un dreptunghi ;
c) rezultatul (evenimentul emis), reprezentat tot printr-o elipsă
d) sincronizarea, reprezentată grafic printr-un triunghi orientat către operaţie.

Evenimentul declanşator
Desemnează un fapt a cărui apariţie declanşează o reacţie în cadrul organizaţiei;
apariţia unui eveniment va antrena derularea de activităţi, de operaţii, reprezentând “motorul”
unei acţiuni, al unei operaţii ( de ex. sosirea unui document).
Pentru ca MCP să fie cât mai stabil, el trebuie să fie independent de aspectele
organizatorice şi tehnologice, chiar geografice.
De ex. Sosirea unei comenzi de la un client este un eveniment declanşator, de natură
extern. A satisface această cerere înseamnă a o transforma într-o livrare de produse.
Descrierea conţinutului prelucrărilor necesare trebuie să fie independentă de:
- aspectele tehnologice (se utilizează calculatorul sau nu ?)
- aspectele “geografice” (comanda este prelucrată la depozit sau în altă parte ?)
- aspecte organizatorice (livrarea este făcută de X la serviciul comercial sau de Y la magazie ?)
- aspecte temporale (livrarea se face dimineaţa sau seara ?).
Tip eveniment
Este un concept generic descriind toate apariţiile evenimentelor de aceeaşi natură.
Capacitatea sistemului de a percepe aceste apariţii este exprimată de doi parametri :
capacitatea : indică numărul maxim de apariţii ale acestui tip de eveniment care pot fi
percepute de sistem şi
frecvenţa : indică legea de manifestare a acestor apariţii.
Categorii de evenimente
Un eveniment poate fi :
 extern (recepţionat din exterior) : primirea unui CEC, a unui aviz de
plată, solicitarea unui credit, etc.

 intern (generat de activitatea sistemului întreprindere) : pana unei

maşini, găsirea unei soluţii, etc.
Pentru a avea un eveniment trebuie să coexiste anumite condiţii:
- să se întâmple ceva (în afară sau în interiorul întreprinderii)
- acest ceva trebuie să fie perceput de sistem (care trebuie să fie dotat cu mijloace
capabile să îl perceapă)
- întreprinderea să fie interesată, văzând în el un posibil eveniment declanşator al
activitătii sale.

Operatia
Se numeşte operaţie orice acţiune (sau secvenţă continuă de acţiuni), producătoare de
evenimente rezultat, care se execută fără întrerupere, ca reacţie la un eveniment declanşator

14
(sau a mai multor evenimente declanşatoare sincrone). O operaţie constituie un bloc
neîntrerupt (nu trebuie să apară rezultate intermediare în interiorul unei operaţii).

Tip de operatie
O categorie de operaţii ce prezintă aceleaşi caracteristici. Un anumit număr de
parametri caracteristici permit specificarea unui anumit tip de operaţie:
- desemnarea operaţiei însăşi;
- durata exprimata în unităţi de timp
- acţiunile elementare constitutive
- evenimentele emise şi condiţiile de emitere.
O operaţie se finalizează întotdeauna prin emiterea de evenimente funcţie de situaţiile
identificate pe parcurs şi de condiţiile exprimate de aceste situaţii (aşa-numitele reguli de
emisiune).
emisiune).

Cod Denumire
operaţie operaţie
Acţiune ( Acţiuni)
Reguli de emisiune

Evenimente emise - rezultate

Remarcă. O operaţie se desfăşoară în timp, având o anumită durată. La un moment dat ea
poate fi :
- în aşteptarea execuţiei;
- în curs de execuţie şi
- terminată.

Rezultatul (evenimentul emis) .

Numim rezultat produsul executării unei operaţii. Întotdeauna trebuie respectată următoarea
regulă: o operaţie produce unul sau mai multe rezultate. Descompunerea unei operaţii în mai
multe operaţii distincte implică apariţia unor rezultate intermediare. Un eveniment emis poate
fi în acelaşi timp un eveniment declanşator pentru o altă operaţie ( sau alte operaţii). De aceea
se şi utilizează acelaşi formalism.

Reguli de obtinere a rezultatului

În MCP toate operaţiile trebuie sa aibă rezultat. În anumite cazuri obţinerea unuia sau
mai multor rezultate poate fi supusă îndeplinirii anumitor condiţii. În această situaţie este
necesar să fie definite, formulate aşa numitele reguli de emisiune sau reguli de acţiune.
acţiune. (vezi
fig. de mai sus). Exemple :
- Relaţia date-rezultate este supusa anumitor condiţii logice : dacă valoarea facturată este mai
mare de 1 milion, atunci se acordă o remiză de 1o%, dacă nu, se acordă un scont de 2%.
- Lansarea unei livrări poate fi diferită dacă stocul este insuficient. În acest caz comanda este
plasată în aşteptare (nu se întocmeşte dispoziţie de livrare). Condiţia “stoc suficient” defineşte
o regulă de emisiune a rezultatului cu două cazuri diferite (“stoc suficint”; “stoc insuficient”).

Reprezentarea regulilor de emisiune

15
 Conform figurii alăturate, diferitele
reguli de emisiune sunt reprezentate în Operaţie
partea inferioară a dreptunghiului ce descrie Regula de Regula de
operaţia. emisiune 1 emisiune 2
Reprezentarea este analogă unei formulări de
genul :
Dacă regula de emisiune 1
atunci Rezultat A şi Rezultat B A B C
altfel (regula
(regula de emisiune 2)
Rezultat B şi Rezultat C
Sincronizarea
În anumite cazuri, declanşarea unei operaţii poate solicita producerea simultană a mai
multor evenimente. Cu alte cuvinte, o anumită operaţie nu poate avea loc decât dacă sunt
îndeplinite anumite condiţii privind manifestarea evenimentelor ce concură la declanşarea
operaţiei respective. Expresia acestor condiţii se numeşte sincronizare.
sincronizare.
Principiul sincronizării
Sincronizarea exprimă sub forma unei propoziţii logice faptul că operaţia poate fi
declanşată sau nu. Ea se exprimă printr-o expresie booleană ce leagă evenimentele ce
declanşează operaţia.

Modul de funcţionare
Dacă E1, E2 şi E3 sunt evenimente declanşatoare pentru operaţia Oi şi dacă a, b, c
sunt apariţii corespunzătoare evenimentelor E1, E2 şi respectiv E3, atunci sincronizarea :
a si ( b sau c) , adică a Ù ( b Ú c)
indică faptul că operaţia Oi este declanşată dacă o apariţie a evenimentului E1 există simultan
cu una din apariţiile evenimentelor E2 sau E3.
Sincronizarea se exprimă deci sub forma unei propoziţii logice care trebuie să respecte
anumite reguli, dintre care cele mai importante sunt:
- condiţia trebuie pusă pe evenimentele participative conjugate şi
- trebuie să existe situaţii care permit declanşarea.
Conceptul de sincronizare exprimă o logică şi o dinamică a prelucrărilor. La un
moment dat, propoziţia logică poate fi verificată. Atunci sincronizarea este activă şi operaţia
este declanşată. La un alt moment este posibil ca un singur eveniment declanşator să fie
realizat; în acest caz sincronizarea este în aşteptarea realizării altor evenimente care să
declanşeze operaţia. Dacă nici un eveniment nu are loc, sincronizarea este inactivă.
Sincronizarea reprezintă
reprezintă concordanţa între două sau mai multe evenimente. Ea face ca
evenimentele să aibă loc simultan, în acelaşi timp, concomitent, sincron.
Nu trebuie uitat faptul că evenimentele “sincronizate”, prin sincronizare, declanşează
o singură operaţie. Totodată, pentru ca un eveniment să participe la o sincronizare, el trebuie
să fie utilizat în această declanşare.

Evenimentul A Evenimentul B Sfârsit operaţie

Timp
t1 t2 t3

Sincronizare Sincronizare
în asteptare activă (operatie
Sincronizare declanşata) Sincronizare
inactivă inactivă

16
1.3.2. Noţiunea de “Proces”
Un proces descrie dinamica prelucrărilor dintr-o activitate determinată. El este format din
operaţii executate ca reacţie la evenimente şi producând rezultate.
Un proces este:
- omogen : operaţiile şi rezultatele concură la o finalitate comună.
- limitat : are graniţe marcate de evenimentele de origine şi de rezultatele
terminale.

Etapele elaborarii unui proces.

Procesul este MCP ce corespunde unui domeniu de activitate. El este construit printr-un
demers metodologic de modelare (analiza, abstractizare, conceptie), ce cuprinde următoarele
etape:
1. Delimitarea obiectului de activitate
În cadrul acestei etape trebuie precizate graniţele domeniului de care sunt legate activităţile
care interesează.
2. Identificarea principalelor evenimente.
Aici trebuie revăzute principalele evenimente externe şi interne ale procesului; acestea sunt
elemente cheie în realizarea modelului.
3. Construirea tabelului evenimente-rezultate.
Acest tablou permite definirea conţinutului procesului, precizând pe coloane, evenimentele,
acţiunile induse şi rezultatele.
4. Identificarea si descrierea operatiilor.
Tabloul evenimente-rezultate, în coloana centrală, permite deja identificare acţiunilor induse
de evenimentele declanşatoare. O analiză mai completă a contextului permite relevarea
regulilor de gestiune, care sunt adesea elemente ale operaţiilor.
5. Reperarea sincronizarilor.
sincronizarilor.
Aparent, mai multe evenimente distincte pot să declanşeze aceeaşi operatţe. Odată stabilite
aceste elemente se poate construi schema de bază pentru fiecare operaţie. Această schemă
se numeste bloc operatie.
6. Precizarea condiţiilor de obţinere a rezultatelor.
Se caută, printre regulile de gestiune, acelea care definesc condiţii de obţinere a rezultatelor.
Se completează apoi schema de bază cu elementele respective.
7. Ordonarea blocurilor-operatie.
blocurilor-operatie.
Structura generală a procesului decurge din cronologia evenimentelor. Deci
evenimentele trebuie ordonate cronologic. Acest fapt permite ordonarea diferitelor blocuri-
operaţie şi legarea lor conform principiului: un rezultat (al operatiei n-1) declanşează operaţia
următoare (operaţia n).
8. Verificarea şi validarea modelului.
Se verifica dacă:
- orice operaţie duce la cel puţin un rezultat;
- orice operaţie este declansata de cel puţin un eveniment;
- toate blocurile sunt legate.
Validarea modelului se face de către persoanele implicate în proces. Numai ele pot judeca
pertinenţa modelului propus.
Descrierea detaliată a procesului
Schema procesului permite o percepţie rapidă a ansamblului prelucrărilor, dar dacă se
doreşte o prezentare mai detaliată, atunci este recomandat ca această detaliere să se facă la
nivel de bloc operaţie, fără să mai urmeze o înlănţuire a blocurilor detaliate, întrucât o schemă
detaliată a procesului ar fi greu de urmărit, de perceput. În acest caz se utilizează pentru
eveniment următorul formalism.

17
 Nume eveniment Ca exemplu, mai jos este dată des-
crierea detaliată a blocului corespun-
Nr max de Termen zător operaţiei “examinarea comen-
aparitii limita zilor în aşteptare” .

Comanda
in asteptare Această manieră de abordare aduce
complemente asupra restricţiilor de timp
20 1 zi şi volum.
Sfarsitul
Schema poate fi completată cu
zilei
descrierea conţinutului operaţiei, dar de
această dată sub formă de “fişă a
a operaţiei”, al cărei conţinut este
b
prezentat în continuare:
a si b

Examinarea
OP 6
comenzilor in
asteptare

Cerere de
fabricatie
30 1 zi

Descrierea operatiei Denumire: Examinarea comenzilor în aşteptare

Numar : 6
Proces : Gestiunea clienţilor
________________________________________________________________
Mod de sincronizare
- la sfârşitul zilei (ora 17)
- pentru toate comenzile în aşteptare
________________________________________________________________
Descrierea regulilor de gestiune
R1. Pentru fiecare produs:
- dacă totalul cerut este mai mic decât cantitatea din stoc
solicitaţi livrarea;
- dacă nu, cereţi fabricarea.
R2. Comenzile de fabricaţie sunt emise cel mai târziu a doua zi după examinarea comenzilor.
_______________________________________________________

Descrierea regulilor de emisiune

R1. Starea cererilor de fabricaţie
18
 Astfel de scheme trebuie elaborate pentru fiecare operaţie. Se aplică aici principiul
cunoscut al ierarhizării, mergând de la general (schema procesului) către particular (descrierea
operaţiei).
________________________________________________________

Revenind la reprezentarea grafică de mai sus putem afirma că parametri exprimând dinamica
procesului puneau restricţii doar la nivelul “nodurilor” şi anume:
- la nivelul sincronizării (propoziţia logică, durata limită) şi
- la nivelul operaţiilor pentru emisiunea de rezultate (reguli de emisiune care
orientează fluxurile către o cale sau alta).
Aceşti parametri pot fi completaţi cu alţii plasaţi pe săgeţile de legătură, în amonte şi
în aval de operaţie. Astfel vom avea ca parametri suplimentari:
- participarea si durata limită (pe săgeata eveniment --> sincronizare) şi
- cardinalitatea (pe arcul operaţie --> rezultat)
Participare şi durata limită (reglarea în amonte)
Uneori sincronizarea, pentru a fi activată, are nevoie de existenţa unui “lot” de apariţii ale
evenimentului declanşator. Acest număr constituie participarea tipului de eveniment la tipul
de sincronizare. Timpul de activabilitate a acestui lot se numeşte durata limită.
Cardinalitatea evenimentelor (reglarea în aval)
Operaţiile emit rezultate (evenimente emise). Uneori este posibil ca acestea să fie
emise în mai multe exemplare identice. Numărul de exemplare exprimă cardinalitatea tipului
de eveniment rezultat al operaţiei.

1.4. Validarea modelelor

1.4.1. Modelele externe ale datelor
Fiecare prelucrare are propriul/propriile sale modele externe (subscheme) de date ş MCD
construit prin prisma unei singure prelucrări. MED se construieşte independent de MCD.

prel1 MED1
modelare
Realitate MCD

prel2 MED2

O prelucrare are ME distincte pentru fiecare consultare şi pentru fiecare actualizare. Atât
pentru consultare cât şi pentru actualizare, ME se construiesc pe baza blocurilor logice de
date corespunzătoare.
Blocuri logice de date (BLD): fluxurile de date vehiculate de o anumită prelucrare.
Evenimentele care activează o sincronizare si care nu constituie o cerere de consultare
constituie un BLD.
Combinaţia de evenimente produse printr-o regulă de emitere a rezultatelor constituie un BLD.

e1 BLD E1 E2
e2

e3 D E

19
Reguli pentru construirea ME
1) Un ME pentru fiecare consultare sau actualizare efectuată de o prelucrare.
2) Fiecare ME se construieste pe baza BLD folosind formalismul EA.
3) Entităţile din ME pot să nu aibă identificatori.
4) Atributele, entităţile şi asocierile externe pot să nu fie atribute, entităţi sau asocieri
conceptuale.
conceptuale.
5) Atributele externe echivalente atributelor conceptuale trebuie să aibă acelaşi nume.

1.4.2. Principiul validării modelelor

Fiecare model extern trebuie să
să fie deductibil din MCD

Model extern

calcul echivalenta

Model conceptual

1.4.3. Reguli de validare în consultare

Atributele externe trebuie săsă fie atribute conceptuale. Dacă nu:
- dacă există omisiuni Þ se completează MCD;
- dacă există date calculate Þ se înlocuieşte în ME cu atributele conceptuale necesare
calculării lor; dacă acestea nu apar în totalitate în MCD, se adaugă;
- date ce nu trebuie memorate Þ se elimină din ME, urmând să fie tastate direct.
Trebuie să existe posibilitatea de-a avea acces la date în structura necesară
Accesul poate fi făcut:
- pe baza identificatorului;
- prin parcurgerea entităţilor sau asocierilor, una câte una, adică se verifică
existenţa criteriilor de selecţie necesare şi se compeletează MCD dacă este nevoie.
Dacă se fac consultări pentru care criteriul de acces nu este identificatorul, se adaugă în MCD
o nouă entitate al cărei identificator este acest criteriu de acces şi asocierea necesară pentru
consultare (căi de acces impuse de utilizare şi nu de DF).
Cardinalitatile asocierilor externe trebuie să fie incluse în cardinalităţile asocierilor
conceptuale ce le corespund semantic.
semantic.

1.4.4. Reguli de validare în actualizare

Orice atribut extern trebuie să servească fie la identificarea elementului conceptual de
actualizat fie la obţinerea valorii de adăugat sau de modificat a unui atribut conceptual:
- se suprimă atributele externe care nu servesc nici unuia din scopurile amintite;
- se adaugă cele absente.
Cardinalitatile asocierilor externe trebuie să fie incluse în cardinalităţile asocierilor
conceptuale ce le corespund semantic.

20
 Orice atribut conceptual trebuie să poată fi inserat (modificat sau şters) prin cel puţin
un model extern. Dacă nu, se adaugă modelele externe adecvate.

1.5. Modelarea logică a datelor (MLD)

MLD

1.5.1. Cadru general

Trecerea de la MCD, care este un model universal, spre o soluţie informatică se face gradat,
luând în considerare un anumit tip de soluţie şi apoi, în cadrul tipului respectiv, o soluţie
direct implementabilă.
Expresia MCD în termenii unui anumit tip de soluţie informatică constituie modelul
logic al datelor (MLD).
Deoarece aplicaţiile informatice de gestiune se caracterizează prin stocarea şi
prelucrarea relativ simplă a unor volume mari sau foarte mari de date, tipurile de soluţii luate
în considerare vizează modalităţile de gestionare a datelor pe suporturile de memorie externă.

1.5.2. Modelul relaţional

Conform acestui model, o entitate poate fi definită ca o relatie (în sens matematic), R  D1
xD2 xD3 x …..Dn , mai exact o submultime a produsului cartezian de <<n>> multimi
denumite domenii si notate cu D1, D2, D3 , …,Dn . Odată demonstrat acest lucru, pe obisnuitul
tabel cu date referitoare la o entitate s-au putut aplica toate conceptele unei metode logice si
riguroase de modelare a datelor, inclusiv algebra relatională. Astfel relatiei (tabelului) i se
poate asocia un grad <<n>> (numărul de coloane ale tabelului) si o cardinalitate <<m>>
(numărul de realizări sau rânduri sau articole), iar mai nou , un articol se identifică în cadrul
modelului relational cu ceea ce se numeste tuplu.
Modelul relational foloseste următoarele concepte fizice:
- relatie = tabel bidimensional format din rânduri (linii) numite tupluri si coloane numite
domenii. Relatiile abordate sunt finite; chiar dacă domeniile pe care sunt construite pot fi
infinite (de ex. domeniul numerelor întregi);
- tuplu = un rând dintr-o tabelă;
- caracteristica= numele/antetul unei coloane dintr-o tabelă (relatie);
- cheie = o caracteristică sau o multime de caracteristice a căror valoare identifică fiecare
tuplu dintr-o tabelă;
- cheie primară = cheia care permite identificarea în mod unic a unui tuplu (înregistrare);
- cheie secundară = cheia ce permite identificarea tuturor tuplurilor care au aceeasi
proprietate;
- cheie externă = cheie identică cu cheia primară a relaţiei asociate; prin construirea cheilor
externe se realizează un acces rapid la informaţiile continute în baza de date, datorită
legăturilor pe care le realizează;
- domeniu = multimea de valori ale unei caracteristici (o coloană dintr-o tabelă);
- grad = numărul de coloane din cadrul unei tabele; se notează G(R)=n, unde R este numele
tabelei;
- cardinalitate = numărul de rânduri din cadrul unei tabele; se notează C(R)=m, unde R este
este numele tabelei;
- dimensiunea relaţiei = produsul dintre cardinalitate si gradul relatiei.
Un model relational cuprinde trei elemente:
- structura datelor;
- reguli de integritate, care guvernează utilizarea cheilor în model;
- operatori.
- Atribut: o submulţime a unui domeniu căreia i s-a atribuit un nume. Numele exprimă rolul
sau semnificaţia atribuite elementelor domeniului respectiv.
Relaţiile se reprezintă grafic sub formă de tabele, în care se disting:
· gradul relaţiei: numărul de atribute utilizate
21
 · cardinalitatea relaţiei: numărul de tupluri (linii în tabel).
Cardinalitatea unei relaţii este variabilă în timp datorită operaţiilor de actualizare care pot
adăuga sau şterge tupluri.
Pentru o relaţie pot exista 3 tipuri de chei:
· cheie primară: cel mai mic ansamblu de atribute (eventual unul singur) care permite
identificarea fără echivoc al fiecărui tuplu al unei relaţii; atributele care
compun cheia primară nu pot avea valori nule.
· cheie candidat: o altă posibilă cheie primară, care nu a fost însă reţinută ca atare.
· cheie externă: un ansamblu de atribute (eventual unul singur) care este cheie
primara într-o alta relaţie.
relaţie.
Restricţie de integritate referentială (RIR):
(RIR):
dacă între un atribut A şi o cheie primară B există o RIR atunci A nu poate lua decât valori
care există şi în B. Prin definiţie, cheile externe sunt supuse RIR în raport cu cheile primare
corespunzătoare.

1.5.3. Trecerea de la MCD la MLD relaţional

a. Cazul entităţilor
Fiecare entitate devine o relaţie.
Atributele entităţii devin atribute ale relaţiei.
Identificatorul entităţii devine cheia primară a relaţiei
b. Cazul asocierilor
b.1 Cazul general
1) Asocierea devine o relaţie.
2) Atributele proprii ale asocierii (dacă există) devin atribute ale relaţiei.
3) Cheile primare ale entităţilor participante la asociere devin chei externe.
4) Identificatorul asocierii devine cheia primară a relaţiei.
b.2. Asocieri binare având cel puţin o cardinalitate maximală 1.
Se adaugă la atributele relaţiei corespunzătoare entităţii cu cardinalitatea maximală 1
identificatorul celeilalte entităţi (cheia primară a relaţiei corespunzătoare acesteia),
care devine cheie externă.
Dacă asocierea are atribute proprii, acestea se adaugă la rândul lor relaţiei care
reprezintă entitatea cu cardinalitate maximală 1.
c. Subtipuri de entitati (Generalizarea/specializarea)
c.1. Reprezentarea simplă a legăturilor dintre tip şi subtip
Se aplică regulile de la b.2.
c.2. Reprezentarea moştenirii
Reprezentarea moştenirii ca proces de transfer al proprietăţilor generice ale tipului spre
subtipuri nu beneficiază de o soluţie relaţională dedicată. Din această cauză, este necesar să se
recurgă la defactorizarea proprietăţilor comune. Aceasta se poate face în două variante:
a) se favorizează specializarea:
specializarea: tipul de entitate generică dispare iar atributele sunt adăugate
la fiecare dintre subtipuri.
b) se favorizează generalizarea:
generalizarea:
· tipul de entitate generică preia şi atributele specializate care, în funcţie de subtipul
reprezentat, primesc valori nule.
· atât tipul cât si subtipurile sunt conservate ca atare.

1.6. Modelarea
M Logică a Prelucrărilor (MLP
MLP)
a) Modelul logic de prelucrare are rolul de a preciza:
- frecvenţa de prelucrare;
- actorii implicaţi;
- fazele şi sarcinile asociate acestora, inclusiv evenimentele şi sincronizările aferente;
- tipul fazelor: A (automate) şi M (manuale).
22
 - Pentru aceasta se pleacă de la MCP. Mai exact operaţiile complexe sunt transformate
în faze iar operaţiile elementare sunt transformate în sarcini.
- se întocmeşte un tabel cu rubricile: frecventa, actori (defalcat pe actori nominalizaţi) şi
tipul fazei (A sau M).
Interesant este faptul că în rubricile destinate fiecărui actor nu se trece text ci se trece
chiar schema procesului din modelul conceptual al prelucrărilor, dar de data aceasta
continuată când pe o coloană, când pe cealaltă, în funcţie de actorul care preia sarcina ce i se
cuvine din procesul respectiv.

1.7. Strategia de urmat pe timpul elaborării programelor

prin care se va materializa acest proiect.
In elaborarea unui sistem informatic trebuie plecat de la obiectivele pe care pe care ni le
propunem să le atingem prin darea în funcţiune a acelui sistem. Aceste obiective sunt
specifice fiecărui sistem, dar pentru identificarea lor trebuie să ştim că ele derivă din cel puţin
cinci cerinţe ce se impun oricărui sistem sau aplicaţie informatică, şi anume:
- să rezolve problema ce face obiectul informatizării;
- în rezolvarea problemei să ţină seamă şi de cerinţele legislaţiei în vigoare
referitor la obligativitatea unor stocări de date şi prelucrări de date prin care să se
poată urmări transparenţa afacerii, a evoluţiei patrimoniului, contextul în care s-au
desfăşurat operaţiile ce decurg din activitatea ce face obiectul informatizării;
- să furnizeze informaţii statistice şi grafice ce pot fi folosite în procesul de
elaborare a deciziilor ce vor fi formulate în mod curent de către managerul
societăţii sau instituţiei în care se desfăşoară activitatea ce trebuie informatizată;
- dacă este cazul, prelucrarea datelor să poată fi făcută în contextul în care sursele de
date şi/sau utilizatorii datelor şi rezultatelor prelucrărilor ce au loc în cadrul sistemului sunt
distribuite local sau la mari distanţe folosindu-se Internetul;
- să asigure securitatea sistemului sau aplicaţiei informatice.
În continuare, în funcţie de metoda de abordare aleasă (baze de date, flux de date, proiectare
obiectuală, etc.), vom identifica documentele de ieşire şi de intrare, actorii care acţionează în
sistem şi vom elabora modelul conceptual al sistemului informational ce trebuie informatizat.
În elaborarea acestui model vom răspunde în principal primei cerinţe. În ce priveşte celelate
cerinţe, de ele vom ţine seamă în această fază numai în măsura în care putem prevedea câte
ceva din fiecare.
După identificarea entităţilor sau obiectelor ce acţionează în sistem, a atributelor sau
proprietăţilor acestora, a asocierilor şi agregărilor, după stabilirea restricţiilor de integritate şi
după validarea modelelor, vom face un inventar a tuturor atributelor sau proprietăţilor şi vom
stabili denumirea, tipul şi caracteristicile datelor prin care ele vor fi reprezentate în calculator.
De exemplu putem materializa această acţiune prin întocmirea dicţionarului atributelor.
Acesta ne va permite să avem garanţia că atunci când un atribut este prezent în mai multe
entităţi sau obiecte, în mai multe programe sub diferite denumiri, acestea să fie compatibile
între ele iar prelucrările să se facă corect şi fără incidente sau erori.
În continuare vom trece la proiectarea meniului aplicaţiei şi a interfeţelor. Aceasta conţine
două etape: identificarea obiectelor de control şi identificarea prelucrărilor sau metodelor
fiecărui obiect de control.
Pentru o identificare completă a tuturor prelucrărilor sau metodelor fiecărui obiect de control
putem dacă este posibil, să avem în vedere şi celelalte cerinţe care încă nu au putut fi
materializate în modelul viitorului sistem informatic.
Acum putem realiza o primă variantă a programelor din care se va compune sistemul nostru
informatic. Fiecare modul va fi testat individual şi apoi integrat în fluxul de prelucrare sau în
cazul de utilizare în care va fi folosit pe timpul exploatării sistemului informatic.
Când tot ansamblul de programe permite derularea corectă a fluxului prelucrării datelor impus
de logica desfăşurării activităţilor informatizate, vom lua în studiu fiecare din cele cinci

23
cerinţe enumerate mai sus şi vom adăuga pe rând câte una din modificările impuse
programelor de către aceste cerinţe. Vom trece la următoarea modificare numai atunci când tot
ansamblul de programe funcţionează corect şi cu ultimele modificări.
Observăm deci că elaborarea sistemului informatic este un proces ce se desfăşoară în spirală,
plecând dela un soft minimal care va constitui nucleul viitorului sistem, iar acel nucleu se va
dezvolta pe măsură ce i se fac modificările impuse de toate cele cinci cerinţe enumerate mai
sus.

24
Capitolul 2

Aplicarea teoriei proiectării sistemelor informatice

în cazul casei de schimb valutar

2.1. Modelarea globală

2.1.1. S.C. M&S Exchange S.R.L.

SC. M&S Exchange SRL a fost înfinţată în aprilie 2000 prin deschiderea a două
puncte de lucru şi se constituie dintr-un singur asociat.
Capitalul social subscris al societăţii este de 2.000.000 lei constituit în numerar prin
depunere la bancă şi este divizat în 10 părţi sociale în valoare de 200.000 lei fiecare.
Societatea are ca obiect unic de activitate schimbul valutar pentru persoane fizice, des-
făşurându-şi activitatea în conformitate cu legislaţia română, prevederile actului constitutiv şi
ale actelor interne.
În urma publicării legii privind obligativitatea dotării cu case de marcat fiscale şi a
includerii explicite a caselor de schimb valutar, SC. M&S Exchange SRL a fost printre
primele firme care au adoptat acest sistem. Soluţia adoptată cuprinde:
- imprimanta de bonuri – este o imprimantă specializată de tipărire bonuri;
- afişajul client – este un dispozitiv care permite clientului să vadă câţi bani trebuie să
predea şi câţi bani va primi în urma schimbului valutar.
Punctele de schimb valutar respectă toate condiţiile necesare unei bune derulări a
activităţii de schimb valutar, adică: aparat de verificare a autenticităţii bancnotelor, casă de
bani, sistem de alarmă, desfăşurarea operaţiunilor în sistem computerizat, casă de marcat
fiscală iar pentru o şi mai bună siguranţă atât a clienţilor cât şi a operatorilor, SC. M&S
Exchange SRL are angajaţi agenţi de pază prezenţi la fiecare punct de schimb valutar şi
colaborează cu o firmă de pază şi protecţie pentru intervenţii rapide în caz de necesitate.
În cadrul firmei exista o buna comunicare între punctele de schimb valutar şi casa
centrală pentru preântâpinarea eventualelor lipsuri de disponibilităţi la anumite valute – pot fi
efectuate operaţiuni de alimentare sau remitere între puncte, între puncte şi casa centrală sau
între puncte, casa centrală şi bancă. Se urmăresc îndeaproape şi fluctuaţiile de pe piaţa
valutară în decursul unei zile pentru a se comunica eventualele modificări de cursuri şi
tendinţe ale anumitor valute.
Aplicaţia schimb valutar – este aplicaţia care efectuează operaţiunile specifice
activităţii de schimb valutar. Pe lângă toate operaţiunile întâlnite în schimbul valutar – cumpă-
rare/vânzare, alimentare/remitere, deconturi/plăţi, stabilirea cursurilor pentru valutele tranzac-
ţionate şi rapoartele aferente: registrele de casa în lei/valută şi registrul de tranzacţii – s-a con-
siderat necesar introducerea unui sistem de parole pentru interzicerea accesului persoanelor
neautorizate şi pentru o mai bună urmărire a operaţiunilor efectuate de operatorii punctelor de
schimb valutar, fiecare dintre acestia primind un nume de utilizator, o parolă şi un cod al ope-
ratorului care apare pe toate documentele întocmite de acesta.
Pentru o funcţionare cât mai bună şi mai eficientă a aplicaţiei se consideră necesar
restricţionarea accesului neautorizat al operatorului la anumite operaţii ( de exemplu: adăuga-
rea sau ştergerea unei valute).
Pentru urmărirea tranzacţiilor care depăşesc 10.000 de EURO pe lângă seria şi
numărul actului de identitate al clientului mai trebuiesc specificate CNP-ul şi adresa clientu-
lui. Se mai poate urmări şi altfel o tranzacţie de acest gen: dacă aceiaşi persoană face mai
multe tranzacţii în aceiaşi zi care depăşesc 10.000 de EURO, la sfârşitul zilei, când se face
închiderea programul trebuie să te avertizeze în privinţa acestui lucru.
Pe lângă toate aceste facilităţi programul mai trebuie să ţină şi o evidenţă a
persoanelor nerezidente şi a sumelor tranzacţionate.
25
 Datorită cererii mari de pe piaţă, a serviciilor bune practicate şi a comisioanelor avan-
tajoase SC. M&S Exchange SRL înregistrează profit în primii ani de activitate şi decide
extinderea punctelor de schimb valutar.
Acest lucru se produce treptat, în mai multe etape, astfel încât, în prezent, societatea are
deschise 8 puncte de schimb în Constanţa, urmând a-şi deschide filiale şi în alte oraşe ale ţării.
Se lucrează cu 9 valute: USD – Dolarul SUA, EUR – EURO, CAD – Dolarul canadian,
AUD – Dolarul australian, GBP – Lira sterlină, NOK – Coroana norvegiană, SEK – Coroana
suedeză, DKK – Coroana daneză şi CHF – Francul elveţian urmând ca pe viitor să se
introducă şi EGP – Lira egipteană, JPY – Yenul japonez şi TRL – Lira turcească.
Tot ca perspectivă de dezvoltare se urmăreşte ca în viitor să se lucreze şi cu cecuri de călă-
torie şi carduri.

2.1.2. Obiectivele aplicaţiei

Obiectivul fundamental al aplicaţiei constă în furnizarea de
informaţii corecte, relevante şi în timp util atât conducerii, cât şi
nivelelor operaţionale specifice unei unităţi economice, în scopul
creşterii eficienţei economice. Aceasta presupune creşterea calităţii şi
operativităţii informaţiilor contabile, pentru a se asigura cunoaşterea în
detaliu a proceselor economice, a fluxurilor de valori materiale sau
băneşti, a rezultatelor financiare obţinute.
Realizarea de sisteme informatice financiar-bancare creează
condiţii pentru introduce-rea unor metode moderne, eficiente, de
urmărire şi control al întregii activităţi.
Obiectivele manageriale constau în realizarea evidenţei şi
gestiunea tranzacţiilor valu-tare, astfel încât unitatea plătitoare să-şi cunoască exact
rezutatele economice şi să poată bene-ficia de implementarea sistemului informatic în
activitatea de zi cu zi.
Elaborarea documentelor de ieşire (Buletinul de Schimb Valutar, Borderoul de Cumpărări,
Borderoul de Vânzări, Lista de cursuri) pe baza datelor de intrare, reprezintă un alt obiectiv
important.
Obiectivele funcţionale presupun:
- preluarea corectă a informaţiilor de la tastatură, precum şi transmiterea acestora în
situaţiile de ieşire;
- elaborarea programelor cu o utilitate maximă, facilitând munca departamentului con-
tabil, reducând costul informaţiei;
- asigurarea unei interfeţe utilizator prietenoasă, cu posibilitatea obţinerii informaţiilor
suplimentare;
- asigurarea integrală a controlului asupra activităţii caselor de schimb valutar, evitarea
nerespectării cerinţelor de evidenţă şi raportare impuse de BNR.
Tinând cont de aceste obiective, aplicaţia facilitează evidenţa şi raportarea documentelor
referitoare la gestiunea mişcărilor de valută efectuate de casa de schimb valutar respectivă.
Un obiectiv derivat este şi acela de a da posibilitatea managerului firmei (al casei de
schimb valutar) de a cunoaşte în orice moment evoluţia cumpărărilor şi vânzărilor de valută,
de a avea la dispoziţie un puternic sistem de indicatori specifici pentru facilitarea luării
deciziilor, aplicarea lor în practică şi urmărirea efectelor acestora.
Obiectivele manageriale şi funcţionale ale aplicaţiei pot surprinde şi alte aspecte ce decurg
din:
- mărimea casei de schimb valutar;

26
 - gradul de participare a casei de schimb valutar la derularea operaţiunilor de vânzare-
cumpărare;
- cota de piaţă ce revine casei de schimb valutar respective.
Obiectivele aplicaţiei asigură utilizarea eficientă şi pe scară largă a calculatoarelor,
creşterea vitezei de circulaţie a informaţiei şi reducerea timpului de răspuns.

2.2. Modelarea conceptuală

2.2.1. Intrările şi ieşirile aplicaţiei

În vederea realizării practice a obiectivelor sistemului informatic, se urmăreşte satisfa-
cerea cerinţelor informaţionale ale gestionării casei de schimb valutar şi a structurilor organi-
zatorice din cadrul acesteia.
Din punct de vedere structural, ieşirile sistemului informatic reprezintă a treia compo-
nentă din triada ce caracterizează structura generală a orcărui tip de sistem informatic I-P-E.
Din punct de vedere funcţional, ieşirile sistemului informatic concretizează obiectivele
generale şi specifice ale sistemului proiectat. Pentru realizarea obiectivelor sistemului
informatic, satisfacerea cerinţelor informaţionale ale conducerii şi ale organelor de control, un
rol important îi revine proiectării situaţiilor de ieşire, calculul tuturor indicatorilor şi rezultate-
lor obţinute de către casa de schimb valutar.
Cerinţele informaţionale sunt reflectate prin intermediul unui sistem de indicatori econo-
mico-financiari grupaţi pentru fiecare situaţie de ieşire care asigură materializarea obiectivelor
propuse.
Rapoartele reprezintă situaţiile de ieşire cu ajutorul cărora casa de schimb valutar îşi
finalizează activitatea, acestea permiţând cunoaşterea rezultatelor economice obţinute şi
urmărirea activităţii ei pe parcursul mai multor luni. Rapoartele sunt situaţii de ieşire repre-
zentate sub formă de tabele, la realizarea cărora s-a ţinut cont de frecvenţa de întocmire, tipul
şi dimensiunea datelor. Modelele rapoartelor obţinute prin aplicaţie sunt redate în tabelul
următor:

27
Cod Denumire raport Frecvenţa Descrierea raportului
rap
ort
RBNR Raport BNR Lunar Arată codul valutei, soldul iniţial,
cumpărările de valută, alimentările,
vânzările de valută, remiterile şi
soldul final
TM Total mişcări Lunar Arată codul valutei, sumele încasate (de la
bancă, PSV etc.), sumele cumpărate,
vândute, intrate, ieşite şi soldul final
LR Lista de rotare Zilnic Prezintă felul valutei, nr. BSV, soldurile
initiale, cursul mediu initial, rulajele,
cursurile de schimb, soldurile finale,
cursul mediu final, şi venitul din
comisioane
RC Registru de casă Zilnic Prezintă felul valutei, soldul iniţial, sumele
cumpăra-te, vândute, intrate, ieşite şi
soldul valutei
JIS Jurnal indicatori Zilnic Prezintă soldurile iniţiale şi finale pe fiecare
sintetici valută, total inrări şi ieşiri pe timpul
unei zile provenite din m işcări de
valută.
JSR Jurnal solduri şi Zilnic Prezintă rulajele zilnice de valută prin
rulaje intermediul mişcărilor de valută.

Structura informaţională a acestor rapoarte se prezintă în continuare:

CSV……..
PSV…….. cod: BM

Buletin de mişcare valută (chitanţă)

COD Nr. Seria DATA Suma CURS Tip Tip Parte- Cod
VALUTA BM BM. OP MEDIU op. buletin ner PSV
C,3 C,10 C,10 D,8 N,12 N,8 C,8 C,5 C,20 C, 2
TOTAL GENERAL N,8 N,12 N,8 C,8 N,12 C,20 C, 2

CSV……..
PSV…….. cod: RC

REGISTRU DE CASĂ
la data D,8

Cod valută SOLDUL INIŢIAL CUMPĂRĂRI VÂNZĂRI INTRĂRI IEŞIRI SOLD FINAL
C,3 N,16,2 N16,2 N16,2 N16,2 N16,2 N16,2
TOTAL N,18,2 N18,2 N18,2 N18,2 N18,2 N18,2
GENERAL

CSV……..

28
 PSV…….. cod: RBNR

RAPORT BNR
luna… C,10

Cod valută Sold iniţial Cumpărare Alimentări Vânzări Remiteri Sold final
pers. fizică pers.fizică
C,3 N,16,2 N16,2 N16,2 N16,2 N16,2 N16,2

CSV……..
PSV…….. cod: TM

TOTAL MIŞCĂRI
luna… C,10

Cod valută Intrări bancă Intrări PSV Alte intrări Ieşiri bancă Ieşiri PSV Alte ieşiri
C,3 N,16,2 N16,2 N16,2 N16,2 N16,2 N16,2
TG (dolari) N,18,2 N18,2 N18,2 N18,2 N18,2 N18,2

CSV……..
PSV…….. cod: LR

LISTA DE ROTARE
la data D,8

Cod Nr. CO SOLD Curs RULAJE Curs COMISI SOLD

valuta BS D INITI mediu Rulaj Rulaj mediu ON FINAL
V OP. AL initial C. V. final
C,3 C,9 C,2 N,16,2 N,8 N,18,2 N,18,2 N,8 N,12 N,16,2

Obţinerea acestor situaţii la imprimantă permite utilizarea lor ca acte justificative, iar prin
faptul că respectă condiţiile de formă şi de font cerute, acestea pot înlocui tipizatele (conform
Regulamentului valutar).
Intrările reprezintă documentele prin care casele de schimb valutar îşi controlează
activitatea, acestea permiţându-le să urmărească desfăşurarea acesteia şi să actualizeze baza
de date aplicaţiei.
Primul document folosit este Buletinul de schimb valutar, care este folosit operativ, în
momentul încheierii tranzacţiei valutare.
Conform Regulamentului, casa de schimb valutar emite acest document în trei exemplare,
indiferent dacă operaţiunea este de cumpărare sau vânzare de valută. Un exemplar se
înmânează clientului, unul rămâne la casa de schimb valutar, iar cel de-al treilea se reţine de
către compartimentul financiar-contabil al unităţii.

2.2.2. Sistemul de codificare

Pentru a facilita prelucrarea şi pentru a satisface necesităţile de grupare a atributelor,
se impune codificarea acestora; codificarea permite utilizarea masivă a componentelor
hardware şi reducerii timpului de prelucrare a bazelor de date, optimizând accesul la baza
informaţională.
Unul dintre atributele codificate este tipul actului de identitate:
29
Tipul actului de identitate
Buletin de Adeverinţă de Paşaport turistic Paşaport de Paşaport străin
identitate identitate serviciu
BI AI PT PS XX

Această codificare este folosită zilnic la introducerea datelor necesare oricărei operaţii de
schimb valutar şi emiterii oricărui buletin de schimb valutar.
Un alt atribut este simbolul valutei, codificat în funcţie de ţara în care a fost emisă
valuta, după cum urmează:

Codul Numele valutei

valutei
AUD Dolarul australian
CAD Dolarul canadian
CHF Francul elveţian
DKK Coroana daneză
EUR Euro
GBP Lira sterlină
NOK Coroana norvegiană
SEK Coroana suedeză
USD Dolarul SUA
RON Lei

2.2.3. Modelul conceptual de comunicaţie (MCC)

Modelul conceptual de comunicaţie (MCC) este realizat pe baza următorilor actori şi fluxuri
informaţionale:
Secvenţă Actor sursă Actor Document/ Descriere flux
flux destinaţie situaţie
1 PSV CSV BMITPSV Transferul sumelor în valută între PSV şi CSV
2 CSV BNR BMITB Transfer valută între BNR şi CSV
3 CSV PSV BMSI Transferul sumelor în valută de la CSV la PSV
4 Persoană fizică PSV BI, AI, PT, Solicitarea vânzării/cumpărării de valută
română/străină PS, XX
5 PSV PSV BC, BV Elaborarea buletinului de vânzare/cumpărare
6 PSV PSV JCV Elaborarea JCV
7 PSV PSV JVV Elaborarea JVV
8 PSV PSV BOC Elaborarea BOC
9 PSV PSV BOV Elaborarea BOV
10 PSV PSV RC Elaborarea RC
11 PSV PSV TM Elaborarea TM
12 PSV PSV RBNR Elaborarea RBNR
13 CSV BNR RBNR Raportarea către BNR
14 CSV BNR BMETB Depunerea sumelor în valută la BNR

Pentru a se putea identifica mişcările de valută în raport cu celelalte aplicaţii specifice unei
case de schimb valutar, în continuare este prezentat MCC pentru toată PSU activitatea casei de
schimb valutar:
BMECH(8)
BC(7), BV(7)

Persoană fizică Bi(6),A(6),PT(6) BOC(14), BOV(14)

(română/străină) PS(6), XX(6)
JCV(9), JVV(9)
RZT(14) BC(12), BV(13)
RC(14)
BMITPSV(1)
BMITB(2)
EXC(3)
30 RBNR(16)

BMETB(17)
 BMSI(5)
BC(7)
BV(7)
BMSI(4)

BNR CSV RZT(13)

JCV(9), JVV(10)
BC(11), BV(12)
RC(13), RBNR(14)
TM(15), BOC(15)
BOV(15)

Notatii folosite:
BC – borderou cumpărări
BMETB – buletin miscare iesiri transfer bancă
BMITPSV – buletin mişcare intrări transfer PSV
BMITB - buletin mişcare intrări transfer bancă
BMSI – buletin mişcare sold iniţial
BI – buletin de identitate
AI – adeverinţă de identitate
PT – paşaport turistic
PS – paşaport de serviciu
XX – paşaport străin
BC – buletin cumpărare valută
BV – buletin vânzare valută
JCV – jurnal cumpărări valută
JVV – jurnal vânzări valută
BOC – borderou cumpărări
BOV – borderou vânzări
RC – registru de casă
TM – totaluri mişcări
RBNR – raport către BNR

2.2.4. Modelul conceptual de date (MCD)

Deoarece modelul conceptual de date a stat la baza elaborării modelului logic de date,
pentru a reduce volumul lucrării, structura entităţilor este prezentată indirect prin structura
tabelelelor, în cadrul modelului logic de date.

2.2.5. Modelul conceptual de prelucrare (MCP)

Procesele derulate la nivel conceptual sunt următoarele:
1. Transfer sume valută între PSV şi CSV în mod direct sau prin intermediul băncii
2. Raportări lunare către BNR.

În aceste condiţii, MCP referitor la reportările lunare către BNR este următorul:

PSV

BOC
B B R
C V C BOV
31
 JC
V JV
TM V

RAPORTĂRI LUNARE CĂTRE BNR

- calculul totalului mişcărilor la nivelul

CSV
- elaborarea RBNR

OK OK

TM RBN
R

BNR

2.3.Modelarea logică

2.3.1. Dicţionarul atributelor

Dicţionarul atributelor stabileşte identificatorii şi condiţiile de validare pentru
fiecare tip de atribut. Dicţionarul atributelor este redat în continuare:

Denumire atribut Identificator Tip, lungime Condiţii de validare

nr. bsv NR. BSV N,10 NR. BSV < > “ “
serie bsv SERIE BSV N,8 SERIE BSV < > “ “
tip stare TIP STARE C,20 TIP STARE < > “ “
pjb PJB C,1 PJB = {P, J, B}
act ACT C,30 ACT < > “ “
cod valută CODVAL C,5 CODVAL = {AUD, CAD, CHF, …, SEK, USD}
nume valută NUMEVAL C,20 NUMEVAL < > “ “
nume NUME C,25 NUME < > “ “
prenume PRENUME C,25 PRENUME < > “ “
serie SERIE C,2 SERIE < > “ “
număr NR N,10
ţara ŢARA C,20 ŢARA < > “ “
cnp CNP N,13
adresa ADRESA C,100 ADRESA < > “ “
utilizator UTILIZATOR C,30 UTILIZATOR < > “ “
funcţia FUNCŢIA C,20 FUNCŢIA < > “ “
parola PAROLA C,10 PAROLA < > “ “
cod utililizator COD_UTIL N,4
cod operaţie CODOP C,1 CODOP ={C, V, D, S, N}
32
denumire DENUMIRE C,10 DENUMIRE < > “ “
tip TIP C,1 TIP ={T, O, S}
dataop DATAOP D
suma cumpărată SUMACUMP N,16,2 SUMACUMP <> 0 and SUMACUMP = <9(16,2)
suma vândută SUMAVÂND N,16,2 SUMAVÂND = 9(16,2)
explicaţie EXPLICAŢIE C,100 EXPLICAŢIE < > “ “
curs cumpărare CURSC N,8,2 CURSC >= 1000 and CURSC =<9(8,2)
curs vânzare CURSV N,8,2 CURSV >= 1000 andCURSV =<9(8,2)

2.3.2. Modelul logic de comunicaţie (MLC)

Având în vedere că sistemul informatic este realizat pentru o casa de schimb valutar cu
mai multe puncte de schimb valutar deschise, soluţia aleasă pentru MLC este o reţea de
calculatoare cu o arhitectură de tip LAN (local area networks – reţele locale).

2.3.3. Modelul logic de date (MLD)

Modelul logic de date (MLD) are rolul de a asigura transformarea MCD, stabilirea ordinii de
actualizare a BD şi obţinerii ieşirilor aplicaţiei.
Structura câtorva tabele mai importante pentru obţinerea de rapoarte este dată mai jos.
Tabelul nomenclator valută Tabelul Buletin (bon) de mişcare

Tabelul
mişcări Tabelul încasări şi plăţi

2.3.4. Modelul logic de prelucrare (MLP)

Modelul logic de prelucrare (MLP) are rolul de a preciza următoarele elemente:
- frecvenţa de prelucrare;
33
 - actorii implicaţi;
- fazele şi sarcinile asociate acestora, inclusiv evenimentele şi sincronizările aferente;
- tipul fazelor: A (automate) sau M (manuale).
Rezultă că din structura MCP se preiau operaţiunile complexe şi elementare şi se stabilesc
transformările acestora în faze A/M:
Operaţiuni Actori Frecvenţă Tip
1. transfer sume valută PSV – CSV PSV/CSV AL M
2. transfer sume valută bancă – CSV/PSV Banca/PSV/CSV AL M
3. raportări lunare către BNR BNR/PSV/CSV L A

2.4. Modelarea fizică

2.4.1. Modelul fizic de comunicaţie (MFC)

Modelul fizic de comunicaţie (MFC) folosit rezultă din descrierea hardware a staţiei
de lucru evidenţiată la MLC. În această viziune, MFC va prelua infrastructura acestei staţii de
lucru, după cum se prezintă în continuare:
- cerinţe software: unul dintre sistemele de operare Microsoft Windows 98/Me/2000/Xp.
- cerinţe hardware minime: Procesor Pentium II 233 Mh
Hdd 4G 5400 Rpm
Memorie 64 M RAM

2.4.2. Videoformatele de I/E

Videoformatele de I/E specifice CSV asigură introducerea datelor pentru actualizarea
BD şi vizualizarea rezultatelor (rapoartelor de ieşire). Aceste videoformate de I/E sunt
următoarele:

Videoformatul Descriere
Ti Denumire Identificator

I Buletin mişcare intrări trans- BMITPSV Asigură descrierea documentului, a operaţiei efectuate şi
fer la PSV codul valutei
I Buletin mişcare intrări de BMIAI Asigură descrierea documentului, a operaţiei efectuate şi
alte tipuri codul valutei
I Buletin mişcare ieşiri trans- BMETPSV Asigură descrierea documentului, a operaţiei efectuate şi
fer la PSV codul valutei
I Buletin mişcare alte ieşiri BMEAE Asigură descrierea documentului, a operaţiei efectuate şi
codul valutei
E Registru de casă RC Pentru fiecare tip de valută se afişează soldul iniţial,
cumpărările, vânzările, intrările, ieşirile şi soldul final
E Lista de rotare LR Pentru fiecare tip de valuta se afişează soldul iniţial,
cursul mediu iniţial, rulajele, comisionul, cursul mediu
final şi soldul final
E Raport BNR RBNR Pentru fiecare valută sunt afişate soldul iniţial,
cumpărările/alimentările, vânzările/remiterile, soldul
final
E Total mişcări TM Pentru fiecare valută sunt afişate intrările şi ieşirile de
orice fel ar fi acestea

2.4.3. Meniul aplicaţiei

Meniul principal este format din următoarele opţiuni şi subopţiuni descrise în ordinea
utilizării acestora:
Implemen- Mişcări Rapoarte Inchide- Editare Ieşire
tare rea zilei

34
 Societatea Emit bon de Registru de casă Cut
mişcare
Puncte de Vizualizare bonuri Raport BNR Copy
schimb de mişcare
Utilizatori Totaluri mişcări Lista de totaluri Paste
Nomenclator Registru încasări Totaluri mişcări
valute şi plăţi
Tipuri de acte Vizualizare Jurnal
de identitate indicatori sintetici
Vizualizare Jurnal
solduri şi rulaje

2.4.4. Scheme de proceduri logice utile pentru obţinerea unor rapoarte.

2.4.4.1. Schema procedurii logice de generare mişcări de valută

Formularul
Bonuri mişcări
Bon de mişcări

Raport mişcări
Butonul
Nomenclt_valută
Tipăresc bonul
Datefirma
Incaplat
Interogarea Raportul
Asamblare vanzare Bon_mişcare

Bonul de mişcare

Observaţie: programul asociat butonului Tipăresc bonul completează în tabelul

Nomenclt_valută, câmpurile referitoare la rulajul mişcărilor de valută, soldul curent şi soldul
în valută de referinţă (Euro) al valutei implicate, completează în tabelul încasări_plăţi câte un
rând pentru fiecare mişcare de valută. În tabelul Datefirmă acest tabel completează nr.
bonului pentru a permite cooptarea în interogarea Asamblare_raport_mişcări, care este
sursa de date pentru raportul Bon_de mişcare, a tabelului Datefirmă, care aduce în bon
datele despre firmă.
Această interogare se formează pe tabelul Raport_mişcări, care este golit şi umplut cu date
tot prin programul asociat butonului Tipăresc bonul.

2.4.4.2. Schema procedurii de obţinere a raportului “Totaluri_miscări“ stocată în

procedura Vizualizare_Click din modulul de clasă al formularului “Luna_Total_miscări“.

35
 QueryDef Tabel- Total_mis- Sub Vizualizare- Total_mis-
Miscări totaluri_misc Click
cări_table cări_tabel
Int. Completez
total_misc_final

Raport_total
Int. Completez Raport_total
total_misc_echiv miscări_final
miscări_echiv

Interogarea Raport_totaluri_misc2

Interogarea Raport_totaluri_misc1

Raport_total
Raport_total miscări_final
Datefirma miscări_echiv

2.4.4.3. Procedura de obţinere a raportului “Raport_BNR “ stocată în procedura

Vizualizare_Click din modulul de clasă al formularului “Luna_Raport_BNR“.

QueryDef Raport_BNR Sub Vizualizare- Raport_BNR

IncaPlat tabel_raport_BNR Click
0 _table _tabel

QueryDef Int. Completez_raport-

sold_init_sold_final BNR_tabel_final
QueryDef

Sold_init_BNR QueryDef Raport_BNR-

Jurnal_sold_rulaj_
QueryDef valute tabel_final

Sold_final_BNR

Interogarea Raport_BNR

36
Raport_BNR-
Datefirma Sold_init_BNR Sold_final_BNR
tabel_final
2.4.4.4. Inchiderea Zilei, Jurnal indicatori sintetici, Jurnal solduri şi rulaje pe valute

Nomenclt_valuta
Sub Jurnal_zilnice Jurnal_sold_rulaj_valute
(de astăzi)
Jurnal_indicatori_sintetici

Form
Jurnal_indicatori_sintetici
Nomenclt_valuta
(de mâine)

Form
Jurnal_solduri_şi_rulaje_pe valute

2.5. Manualul de utilizare a programului pentru casa de schimb valutar

2.5.1. Funcţiile programului

Programul prin care se materializează această lucrare de licenţă poate îndeplini următoarele
funcţiuni:
- implementarea sistemului într-o casă de schimb valutar dată;
- mişcări de valută între bănci şi casa de schimb sau un punct de schimb valutar aparţinând
casei de schimb care posedă programul;
- mişcări de valută între casa de schimb sau un punct de schimb valutar şi alt punct de schimb;
- înregistrarea automată în baza de date a aplicaţiei a tuturor mişcărilor de valută;
- calculul valorii indicatorilor sintetici şi elaborarea de rapoarte specifice activităţii de schimb
valutar:
- Totaluri mişcări;
- Registru de casă;
- Raport BNR;
- Lista de rotaţie;
- Jurnalul indicatorilor sinetici;
- Jurnalul solduri şi rulaje.
- consultarea tabelului cu buletine (bonuri) de mişcări şi a tabelului de încasări-plăţi, operaţii
necesare pentru revizii financiare, verificări cu scop de investigaţii, etc.
Pentru ca programul să permită îndeplinirea acestor funcţii el este prevăzut cu un meniu care
arată ca în imaginea de mai jos. Pentru că primul contact al utilizatorului cu un program este

37
impus de nevoia implementării programului în condiţiile specifice mediului în care va fi
folosit şi meniul acestui program începe cu implementarea.

2.5.2. Implementarea programului

Opţiunile submeniului care este activat la selectarea opţiunii Implementare se pot vedea din
imaginea de mai jos în stânga.
Prima opţiune este Societatea, la selectarea căreia se afişează formularul destinat să ne
faciliteze introducerea datelor despre casa de schimb valutar, sau după caz, a datelor despre
punctul de schimb valutar în care este instalat programul. La selectarea opţiunii Societatea
apare formularul Datefirmă, a cărui imagine se poate vedea mai jos, în dreapta.

Completarea acestui tabel nu ridică probleme deosebite.

Opţiunea Puncte de schimb deschide formularul DatePSV cu ajutorul căruia se pot
introduce date despre casa de schimb valutar - dacă programul este folosit la sediul casei de
schimb, sau despre punctul de schimb valutar - dacă programul se află instalat pe calculatorul
dintr-un punct de schimb valutar. Formularul asociat acestei opţiuni se poate vedea în
imaginea de mai jos.

38
 Date despre operatorii care vor lucra la
calculator se pot introduce cu opţiunea
Utilizatori care atunci când este
selectată deschide formularul destinat
acestui scop, iar imaginea lui se poate
vedea în stânga. La implementare, acest
formular este completat de regulă de
administratorul bazei de date.
Utilizatorii vor fi introduşi cu coduri
care ar trebui să fie numere (diferite de
1 care este rezervat administratorului),
diferite pe întreg efectivul casei de schimb valutar, de la un utilizator la altul.
Parola fiecărui utilizator trebuie să fie mai lungă de 5 caractere, să fie unică pe întreg efectivul
casei de schimb valutar şi provizorie, urmând ca la prima ocazie când un utilizator intră în
tură, după ce a fost recunoscut de calculator cu parola introdusă de administrator, să-şi
introducă o parolă nouă ştiută numai de el. Cu excepţia administratorlui, nici un utilizator nu
poate schimba decât propria sa parolă şi pentru aceasta el trebuie să fie acela care a pornit
calculatorul şi nu altcineva!
Parola introdusă la pornirea calculatorului identifică operatorul de servici şi automat codul său
va apărea pe bonurile pe care le va emite atât timp cât va folosi calculatorul. Când calculatorul
a fost oprit, el poate fi pornit de oricare alt operator care a fost introdus la implementare, în
lista utilizatorilor de către administartorul bazei de date, cu condiţia ca el să folosească o
parolă corectă.
Schimbarea parolei se poate face din
opţiunea bară Editare cu condiţia ca
utilizatorul să aleagă din submeniul
care apare, opţiunea Schimbare
parolă operator în tură. La alegerea
acestei opţiuni apare formularul din
imaginea alăturată. Schimbarea parolei
este posibilă numai dacă operatorul
vine cu o parolă veche corectă.
Următoarea opţiune a submeniului Implementare este Nomenclator valute, la alegerea
căreia apare formularul cu acelaşi nume.

39
În

afară de informaţiile specifice acestui nomenclator, formularul nomenclatorului de valută mai

conţine aşa cum se poate vedea din imaginea de mai sus, cursul fiecărei valute în raport cu
valuta de referinţă (euro), rata la cumpărare şi rata la vânzare în lei noi. Dacă o valută nu este
utilizată în mod curent atunci cursul în raport cu referinţa trebuie pus ca fiind zero.
Excepţie de la celelalte valute face leul nou pentru care nu se cere decât suma în lei noi
disponibili în casă şi valuta de referinţă. Celelalte date nu se cer pentru leul nou deoarece ele
rezultă de la valuta de referinţă unde se cer
ratele de schimb la cumpărare şi la vânzare
pentru valuta de referinţă exprimate în lei noi.
În acest nomenclator, leul trebuie să ocupe
prima poziţie, iar valuta de referinţă poziţia
doua. Restul poziţiilor pot fi ocupate oricum,
dar primele două poziţii sunt rezervate. Când
se schimbă doar cursul leu-euro, dacă celelalte
valute au completat cursul lor în raport cu
euro, ratele de schimb se pot calcula automat
apăsând butonul din stânga-jos de pe
formularul Nomenclator valută.

Ultima opţiune de pe submeniul

Implementare este Tipuri de acte de
identitate.
Formularul asociat acestei opţiuni este
prezentat în imaginea alăturată. Completarea
lui nu ridică nici un fel de probleme.

2.5.3. Procesarea mişcărilor

Procesarea mişcărilor se face cu ajutorul opţiunii bară
numită Mişcări. Imaginea submeniului care apare la
alegerea acestei opţiuni se poate vedea în dreapta. Prima
opţiune a acestui submeniu este Emit bon de mişcare.
La selectarea acestei opţiuni apare formularul Mişcări a
cărui imagine se poate vedea mai jos.

40
Diferenţa dintre mişcările de valută se poate indica prin tipul operaţiei (intrare, ieşire,
depunere sau ridicare) şi prin tipul buletinului de mişcare care poate fi pentru bancă, pentru
un PSV, cheltuieli sau alte mişcări.
Pentru a uşura introducerea datelor, dar mai ales pentru a evita posibilele erori de completare,
variantele de răspuns la ambele cîmpuri se iau din câte un combobox.
Buletinele de mişcare trebuie mai întâi vizualizate şi apoi tipărite. Cu ocazia tipăririi ele sunt
înregistrate automat în tabelul încasări-plăţi şi tot atunci se actualizează soldurile valutelor
afectate de mişcarea respectivă.
Imaginea unui buletin de schimb este prezentată mai jos.

Cu opţiunea Vizualizare bonuri de mişcare se obţine un formular aparent identic cu cel de

mai sus, doar că acesta nu permite modificări ale mişcărilor stocate în baza de date ci numai
vizualizarea lor. Formularul folosit pentru introducerea mişcărilor, nu permitea decât
introducerea unei mişcări noi, care odată tipărită nu mai poate fi vizualizată cu acest formular.

41
 Opţiunea Totaluri mişcări deschide
formularul cu acelaşi nume a cărui
imagine este cea alăturată.
În acest formular vom introduce luna
pentru care se doreşte obţinerea raportului
Totaluri mişcări şi apoi obligatoriu
trebuie apăsat butonul Vizualizare, altfel
butonul Tipărire nu are ce tipări, pentru
că toate prelucrările necesare pentru
obţinerea raportului se fac la apăsarea
butonului Vizualizare.
Dacă utilizatorului îi place cum arată raportul va apăsa butonul Tipărire, care nu face decât
să tipărească raportul pregătit de progarmul asociat butonului Vizualizare.
Ultima opţiune a submeniului Mişcări este Registrul încasări şi plăţi la alegerea căreia se
obţine formularul ce prezintă tabelul încasări şi plăţi. Imaginea lui se poate vedea mai jos.

2.5.4. Rapoarte ce se pot obţine din această aplicaţie informatică

La alegerea opţiunii bară numită Rapoarte se obţine submeniul prezentat în imaginea din
stânga de mai jos.

Cu opţiunea Registru de casă se obţine formularul cu acelaşi nume a cărui imagine este cea
de mai sus, dreapta.
După completarea datei pentru care se cere raportul numit Registru de casă, se apasă
obligatoriu butonul Vizualizare şi apoi Tipărire, când se va obţine raportul din imaginea de
mai jos.

42
 M&S EXCHANGE

Cu opţiunea Raport la BNR se obţine formularul cu acelaşi nume a cărui imagine se poate
vedea mai jos.
După completarea numărului lunii pentru
care se cere raportul se va apăsa butonul
Vizualizare şi apoi Tipărire, când se va
obţine raportul din imaginea de mai jos.

M&S EXCHANGE

Cu opţiunea Lista de rotare se obţine raportul cu acelaşi nume a cărui imagine este cea de
mai jos.
43
Alte două rapoarte care se pot obţine din această aplicaţie, sub forma unor formulare, sunt
Jurnal indicatori sintetici şi Jurnal solduri şi rulaje valută. Imaginile lor sunt cele de mai
jos.

44
2.5.5. Inchiderea zilei
Aceasta ar trebui să fie ultima rulare care se face în cursul zilei care se încheie (sau, dacă ea
nu s-a făcut în ziua precedentă, ar fi prima rulare înainte de a face Începutul zilei curente).
Prin această opţiune se calculează rulajele din ziua care se încheie pentru fiecare valută în
parte, apoi soldul curent devine sold iniţial pentru ziua următoare, se iniţializează rulajele la
fiecare valută cu zero şi în plus se calculează toţi indicatorii statistici în valută de referinţă:
soldul total în valută de referinţă, total intrări prin cumpărare de valută dar în valută de
referinţă, total ieşiri prin vânzare de valută dar în valută de referinţă, total intrări prin mişcări
în valută de referinţă şi total ieşiri prin mişcări în valută de referinţă, profitul în lei şi în valută
de referinţă la sfîrşitul zilei. Prin mişcări se înţelege în acest program, operaţii cu banca cu
celelalte puncte de schimb sau cu CSV, cheltuieli şi alte tranzacţii cu lei şi valută decât cele cu
clienţii prin vânzare-cumpărare de valută.
Indicatorii sintetici sunt afişaţi automat la terminarea operaţiunii de închidere a zilei.
Observaţie: Pentru că în mod normal zilele se succed una după alta, orice început al zilei este
precedat de închiderea zilei precedente. La terminarea activităţilor specificate la
implementare, problemele legate de începutul zilei (probleme carese rezolvă cu opţiunea bară
Actualizare date variabile) sunt rezolvate în mod implicit prin activităţile de implementare
care s-au derulat conform secţiunii 2.5.2. Totuşi în această zi, după implementare, este bine să
se facă închiderea zilei precedente, adică să se ruleze submeniul Inchiderea zilei, dar când
programul cere data zilei care se încheie să daţi data zilei precedente şi nu a zilei în care vă
aflaţi, pentru că ziua în care vă aflaţi va fi închisă seara la terminarea programului. Dacă la
implementare închideţi ziua de astăzi, seara la terminarea programului, nu o veţi mai putea
închide pentru că orice zi poate fi închisă doar o singură dată. Ca urmare a acestei restricţii,
dacă odată aţi întîrziat cu închiderea zilei curente după ora 24, atunci când faceţi închiderea
aveţi grijă să specificaţi nu data zilei în care vă aflaţi ci data zilei pentru care se face
închiderea. Aceste restricţii rezultă din faptul că închiderea unei zile de lucru se încheie cu
iniţializarea soldurilor pentru ziua următoare şi cu iniţializarea rulajelor de valute astfel ca ele
să înceapă în ziua următoare de la zero. Într-o zi obişnuită de lucru însă, după închiderea zilei
precedente, este necesar să se deruleze activităţile de mai jos, adică activităţile specifice unui
început de zi.

45
CAPITOLUL III
Contabilitatea activităţii de schimb valutar

3.1 Sinteză privind organizarea şi funcţionarea caselor de schimb valutar

Conform Normei nr. 4 din 01.04.2005 emisă de Banca Naţională a Romaniei, operaţiile de
schimb valutar pentru persoane fizice pe teritoriul României pot fi efectuate de către
următoarele categorii de persoane juridice:
a) societăţile bancare autorizate să efectueze schimburi valutare;
b) casele de schimb valutar organizate ca persoane juridice conform Legii nr. 31/1990
privind societăţile comerciale, care au ca obiect unic de activitate schimbul valutar,
autorizat de Banca Naţională a României;
c) societăţile de turism, autorizate de Banca Naţională a României să organizeze ghişee de
schimb valutar în vederea încasării în lei a prestaţiilor turistice ( cazare şi servicii supli-
mentare) efectuate pentru turiştii străini.
Casele de schimb valutar sunt societăţi comerciale care au ca profil unic de activitate
schimbul valutar pentru persoanle fizice. Acestea sunt autorizate şi, în consecinţă, sunt
controlate de către Banca Naţională a României.
Pentru a putea funcţiona, casele de schimb valutar trebuie să solicite Băncii Naţionale a
României acordarea autorizaţiei de funcţionare. Pentru aceasta trebuie îndeplinite următoarele
condiţii:
a) Obiectul unic de activitate, conform statutului şi contractului de societate, trebuie să-l
constituie schimbul valutar pentru persoanele fizice.
b) Solicitantul trebuie să prezinte dovada posesiei spaţiului de lucru destinat exclusiv
schimbului valutar, cu acces public direct şi adresă identificabilă. În cazul în care casa de
schimb valutar solicită autorizarea unui punct de schimb valutar în cadrul unui spaţiu
comercial în care se desfăşoară şi alte activiţăţi, amplasarea punctului de schimb valutar
va fi strict delimitată de restul spaţiului prin pereţi despărţitori.
c) Solicitantul trebuie să notifice numele şi sediul băncii unde are deschis contul.
d) Solicitantul trebuie să prezinte dovada capitalului subscris şi vărsat în totalitate în
numele casei de schimb valutar ca persoană juridică. Pentru fiecare punct de schimb
valutar, solicitantul va prezenta dovada existenţei unor disponibilităţi în cont echivalente
cu 30 milioane lei, sumă ce trebuie să se regăsească permanent sub formă de
disponibilităţi în lei sau valută în conturile şi casieriei casei de schimb valutar.
e) Personalul angajat trebuie să prezinte certificatul de cazier juridic fără antecedente.
f) Casa de schimb valutar trebuie să aibă asigurată dotarea necesară derulării activităţii de
schimb valutar, adică:
- aparat de verificare a autenticităţii bancnotelor;
- condiţii necesare păstrării în deplină securitate a valorilor ( sistem de alarmă, casă de
bani);
g) În cazul societăţilor cu aport de caplital străin sau cu capital integral străin, solicitantul
trebuie să prezinte acordul băncii centrale din ţara de rezidenţă pentru transferuri de
capital şi deschidere de cont în străinătate.
h) Se urmăreşte plata comisionului de autorizare de 100.000 lei.
Casele de schimb valutar pot conţine un număr nelimitat de puncte de scimb valutar, fiecare
însă trebuie să obţină autorizarea BNR – Oficiul Control Devize.
Casele de schimb valutar pot începe efectuarea operaţiunilor numai după emiterea autoriza-
ţiei; în vederea obţinerii acesteia, solicitanţii vor depune o cerere scrisă însoţită de
următoarele documente:

46
 - certificatul de înmatriculare, statutul societăţii comerciale, contractul de societate şi
hotărârea judecătorească de înfiinţare;
- dovada posesiei spaţiului;
- certificatele de cazier;
- dovada existenţei în cont a 30 milioane lei;
- orice acte sau documente justificative solicitate de către BNR.
În termen de 7 zile, BNR va analiza documentaţia şi va verifica pe teren existenţa celor
prezentate; autorizaţia sau respingerea cererii vor fi trimise solicitantului.
Casele de schimb valutar îşi păstrează disponibilităţile în valută şi în lei în conturi deschise
numai la societăţi bancare autorizate din România. Aceste disponibilităţi pot fi, de asemenea,
păstrate parţial în caseriile caselor de schimb valutar.
Casele de schimb valutar pot utiliza disponibilităţile în valută numai pentru operaţiuni de
schimb valutar.
Casele de schimb valutar pot cumpăra şi vinde în mod liber valută pe piaţa interbancară,
prin intermediul societăţilor bancare, în limita disponibilităţilor proprii ( numerar şi disponibi-
lităţi în conturi bancare). Societăţile bancare care primesc ordine de vânzare/cumpărare de
valută de la casele de schimb valutar au obligaţia să aplice aceleaşi principii de cotare,
acceptare şi executare ca pentru ceilalţi clienţi.
Casele de schimb valutar îşi pot stabili în mod liber cursurile de schimb, atât cele de cum-
părare, cât şi cele de vânzare. Lista cursurilor de vânzare/cumpărare pentru valute va fi afişată
zilnic, la loc vizibil, la începutul programului de lucru. Se recomanda afişarea cursurilor de
schimb valutar fără includerea comisionului, acesta urmând să fie evidenţiat separat.
Listele de cursuri de schimb zilnice, semnate de persoanele împuternicite de conducerea
casei de schimb valutar şi purtând ştampila punctului de schimb valutar, se vor păstra ca
documente justificative, urmând ca la sfârşitul zilei de lucru să fie anexate la registrul tranzac-
ţiilor.
Este interzisă efectuarea de operaţiuni valutare unilaterale (numai cumpărare sau numai
vânzare de valută), cu excepţia cazului în care această situaţie este determinată de lipsa
temporară de disponibilităţi în valută sau în lei.
Pentru operaţiunile de schimb valutar, comisioanele se încasează numai în lei. Comisioa-
nele practicate vor fi evidenţiate distinct în listele de cursuri de schimb valutar afişate zilnic şi
nu mai pot fi modificate în timpul zilei de lucru. Procentul de comision aplicat asupra cursului
de vânzare trebuie să fie egal cu cel aplicat la cumpărare.
Pentru fiecare tranzacţie, punctele de schimb valutar trebuie să întocmească buletine de
schimb valutar tipizate. Acestea sunt executate, înregistrate, evidenţiate şi utilizate ca docu-
mente cu regim special, purtând în mod obligatoriu antet, serie şi număr de ordine imprimate
la tipărirea lor.
Buletinele de schimb valutar se întocmesc în trei exemplare, fiind obligatorie completarea lor
cu toate datele prevăzute în formular. Originalul buletinului de schimb valutar, datat, semnat
şi ştampilat de punctul de schimb valutar, se înmânează clientului, al doilea exemplar se
ataşează la registrul tranzacţiilor (folosit ca document primar în înregistrările contabile), iar al
treilea exemplar se păstrează ca document justificativ de casă la locul efectuării operaţiunii.
În cazul caselor de schimb valutar la care operaţiunile decurg în sistem computerizat,
buletinul de schimb valutar se poate întocmi pe calculatorul electronic, cu condiţia de a
respecta întocmai modelul de formular, precum şi regimul special al acestuia, prin înscrierea
seriei şi numărului de ordine.

3.2. Contabilitatea activităţii de schimb valutar

Casele de schimb valutar autorizate de BNR au obligaţia să organizeze şi să conducă

contabilitatea proprie potrivit Legii contabilităţii nr. 82/1991 şi regulamentului privind
aplicarea acesteia.

47
 Raportarea către Banca Naţională a României a operaţiunilor valutare derulate prin casa de
schimb valutar se face în conformitate cu normele emise în acest scop. Personalul casei de
schimb valutar este răspunzător de efectuarea operaţiunilor de schimb valutar în conformitate
cu reglementările în vigoare. În cazul în care casele de schimb valutar încalcă aceste
reglementări, vor atrage după sine suspendarea temporară a autorizaţiei sau revocarea
definitivă a autorizaţiei.
Pentru evidenţierea în contabilitate a mişcărilor de valută, se poate folosi una din urmă-
toarele metode:
metoda înregistrării operaţiilor la cursul zilei;
metoda înregistrării operaţiilor la curs fix.
În ambele cazuri, la încheierea exerciţiului financiar, se face evaluarea la cursul zilei,
diferenţa înregistrându-se, după caz, în conturile de venituri şi cheltuieli.
Sumele deţinute de casa de schimb valutar, în lei sau în valută, sunt gestionate distinct.
Aceasta presupune evidenţierea sumelor aflate în caseria unităţii în două subconturi:
5311 “Casa în lei”
5314 “Casa în devize”
Soldurile debitoare ale acestor conturi reflectă numerarul existent la data respectivă, în lei şi,
respectiv, în valută.
Diferenţele de curs valutar ( ce pot fi favorabile sau nefavorabile), se înregistrează astfel:
diferenţele favorabile de curs valutar (cursul zilei este mai mare decât cel din momentul
obţinerii valutei) se înregistrează ca venituri:
531 = 765
Casa în lei Venituri din diferenţe de curs valutar

difernţele nefavorabile de curs valutar ( cursul zilei este mai mic decât cel din momentul
obţinerii valutei) se înregistrează drept cheltuieli:
665 = 531
Cheltuieli din diferenţe Casa în lei
de curs valutar

Conform Regulamentului valutar în vigoare comisionul aplicat asupra cursului de vânzare

trebuie să fie egal cu cel aplicat la cumpărare. Comisioanle pentru operaţiunile de schimb
valutar se pot încasa numai în lei. Înregistrările contabile pentru evidenţierea comisionului
încasat sunt următoarele:
5314 = 5131
Casa în devize Casa în lei

cu suma fără comision (pentru cumpărare de valută), şi:

5131 = %
Casa în lei 5314
Casa în devize
765
Venituri din diverenţe favorabile
de curs valutar
768
Alte venituri financiare

Comisionul se reflectă în contul 768 “Alte venituri financiare”.

Cerinţele de evidenţă şi raportare impun, pe lângă documentele contabile clasice, utilizarea
unui Registru zilnic al tranzacţiilor în care se precizează cumpărările şi vânzările de valută

48
( cecuri de călătorie şi cărţi de credit – daca se tranzacţionează şi acestea), pe feluri de valute,
sumele în lei plătite, respectiv încasate, precum şi comisioanele practicate de casa de schimb
valutar.

49
 CONCLUZII

Realizarea practică a acestei lucrări de licenţă constă într-o aplicaţie informatică pentru
gestiunea mişcărilor de valută ce au loc într-o casă de schimb valutar. Această aplicaţie poate
îndeplini următoarele funcţiuni:
- implementarea aplicaţiei într-o casă de schimb valutar dată;
- preluare mişcări de valută între bănci şi casa de schimb sau un punct de schimb valutar
aparţinând casei de schimb care posedă programul;
- preluare mişcări de valută între casa de schimb sau un punct de schimb valutar şi alt punct
de schimb;
- înregistrarea automată în baza de date a sistemului a tuturor mişcărilor de valută;
- elaborarea de rapoarte specifice activităţii de schimb valutar:
- Raport BNR;
- Totaluri mişcări;
- Registru de casă;
- Lista de rotare;
- Jurnal indicatori sintetici;
- Jurnal solduri şi rulaje.
- consultarea tabelelor cu mişcări şi tabelului de încasări-plăţi pentru documentarea reviziilor
financiare, şi a verificărilor cu scop de investigaţii.
Aplicaţie informatică pentru gestiunea mişcărilor de valută la o casă de schimb valutar s-a
dovedit a fi o temă generoasă, pentru că pe de o parte m-a introdus într-un domeniu mai puţin
cunoscut celor care nu lucreză în domeniul financiar, iar pe de altă parte m-a pus în situaţia să
aplic nu numai cunoştinţele de proiectare de sisteme informatice ci şi să dobândesc noi
cunoştinţe despre securitatea datelor prelucrate cu ajutorul calculatorului, adică despre tehnici
şi metode de protecţie împotriva accesului neautorizat şi chiar a fraudelor, aspecte extrem de
importante în domeniul financiar bancar. Am în vedere lucrul cu parole şi cu formulare de tip
Data Entry, combinat cu formulare fără drept de modificări, ştergeri sau adăugări.
Formularul de tip Data Entry este folosit numai pentru introducerea mişcărilor şi el nu
permite decât introducerea unei mişcări noi, care odată tipărită nu mai poate fi vizualizată sau
modificată cu acest formular. Cu formularele de vizualizare poate fi văzută întreaga colecţie
de articole, dar ele nu mai pot fi modificate.
Tema acestei lucrări solicită mult capacitatea de analiză şi de asamblare a etapelor de
prelucrare din cadrul fiecărei proceduri. De exemplu, în cadrul procedurii de preluare a
mişcărilor, în afară de tipărirea buletinului, în calculator se mai produc câteva operaţii foarte
importante şi anume: se efectuează modificările de solduri ce decurg din mişcarea respectivă
de valută, se calculează echivalentul în curs mediu a sumei implicată în mişcare, iar mişcarea
este înregistrată în tabelul de încasări-plăţi. De asemeni mişcarea este marcată în tabelul cu
mişcări astfel încât dacă ulterior, operatorul mai doreşte să tipărească odată buletinul,
mişcarea la care se referă buletinul să nu fie operată din nou în soldurile de valută sau în
registrul de încasări-plăţi. Toate acestea sunt legate de tipărirea bonului, pentru că tipărirea
este dovada că mişcarea a fost acceptată şi nu există riscul să înregistrăm în gestiune efectele
unei mişcări care ulterior, din cine ştie ce motive să fie abandonată, ceea ce ar impune
refacerea soldurilor şi a tuturor înregistrărilor enumerate mai sus.
La fel de complicată s-a dovedit şi procedura de obţinere a raportului către BNR. Spaţiul
acestei lucrări nu permite comentarea tuturor procedurilor, dar shemele lor prezentate în
secţiunea 2.4.4 pot contribui la formarea unei imagini despre complexitatea unei proceduri
sau a alteia.
De asemeni, mi s-au părut interesante tehnicile prin care se vine în ajutorul utilizatorului şi se
evită tastări inutile de date ceea ce ar duce la suprasolicitarea acestuia, dar ar mări şi riscul
producerii unor greşeli de tastare. Am în vedere completarea automată a câmpurilor pentru
care se pot prelua date din tabele completate într-o etapă anterioară a procedurii sau câmpuri

50
ale căror valoaare poate fi calculată cu ajutorul câmpurilor pentru care datele sunt deja
introduse. De exemplu, în formularul Mişcări operatorul dispune de combox-uri pentru
câmpurile tip operaţie şi tip buletin de mişcare ceea ce îl scuteşte de a se mai gândi care
sunt tipurile de operaţii sau de mişcări şi îl fereşte de a riscul de a face greşeli de tastare. Cu
aceste combobox-uri operatorul trebuie doar să aleagă din lista oferită de combobox varianta
de răspuns care-i convine şi să o indice printr-un clic de mouse dat pe acea variantă.
În ce priveşte lucrul cu lei vechi şi lei noi, toată gestiunea se face în lei noi, dar când se pune
problema efectuării plăţii, aplicaţia dispune de posibilitatea fragmentării sumei incluse în
mişcare, în lei noi şi lei vechi ceea ce permite ţinerea la zi, automat, a monetarului.
Am convingerea că experienţa acumulată cu ocazia elaborării acestei aplicaţii informatice îmi
va permite ca în viitor să abordez nu numai aplicaţii dar şi subsisteme sau chiar sisteme
informatice.

51
BIBLIOGRAFIE

1. Nicolae Dumitru Davidescu, "Sisteme informatice financiar - bancare" vol. I şi II, Editura
All Beck, Bucureşti, 1998.

2. Dumitru Oprea, "Analiza şi proiectarea sistemelor informaţionale economice" Ed. Polirom,

Iaşi, 1999.

3. Iatan Elena, “Contabilitate aprofundată”, Editura Muntenia, Constanţa, 2004.

4. Iatan Elena, “Contabilitate de gestiune, Editura Muntenia & Leda, Constanţa, 2002.

5. Ştefan Florea, "Bazele contabilităţii", Editura Ex Ponto, Constanţa, 2003.

6. Ştefan Florea, "Contabilitate financiară. Sinteze teoretice, aplicaţii practice, teste grilă",
Editura Ex Ponto, Constanţa, 2004.

7. Gheorghe Dumitru, "Contabilitate financiară", Editura Muntenia, Constanţa, 2005

8. Gheorghe Popescu si Elena Popescu, " Sisteme informatice. Proiectare şi programare în

Aceess ", Ed. “Ovidius” University Press, Constanta, 2003.

9. Gheorghe Popescu, “Laborator şi ghid interactiv pentru programarea sistemelor informatice

de gestiune” , Ed. “Ovidius” University Press, Constanta, 2004.

10. Ioan Lungu, Gheorghe Sabău, ş. a., “Sisteme informatice: analiză, proiectare şi
implementare”, Ed. Economică, Bucuresti, 2003.

11. Ioan Roşca, Emilian Macovei, Nicolae Davidescu şi Vasile Răileanu, “Proiectarea
sistemelor informatice financiar-contabile”, Ed. Didactică şi Pedagogică, Bucureşti, 2003.

12. Dorin Zaharie şi Ioan Roşca, "Proiectarea obiectuală a sistemelor informatice", Ed.Dual
Tech, Bucureşti, 2003.

13. Nicolae Feleagă, “Tratat de contabilitate financiară”, Ed. economică, vol. I şi II,
Bucureşti, 2002.

14. Pavel Năstase şi alţii "BAZE DE DATE Microsoft ACCESS 2000 ", Editura Teora ,
Bucureşti, 2000.

52
Anexa cu programe sursă

Module program

Sub meniu_aplicatie()
Dim bara_meniu As CommandBar

Dim submenu As CommandBarPopup

Dim submenu1 As CommandBarPopup
Dim submenu2 As CommandBarPopup
Dim submenu3 As CommandBarPopup
Dim buton As CommandBarControl

Set bara_meniu = Application.CommandBars.Add(Name:="Exchange", Position:=msoBarTop, menubar:=False,

temporary:=True)

Set submenu = bara_meniu.Controls.Add(msoControlPopup)

submenu.Caption = "Implementare"
submenu.Visible = True

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Societatea"
buton.Style = msoButtonCaption
buton.OnAction = "Open_datefirma"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Puncte de schimb"
buton.Style = msoButtonCaption
buton.OnAction = "Open_PSV"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Utilizatori"
buton.Style = msoButtonCaption
'buton.OnAction = "Open_Util"
buton.OnAction = "Open_Utilizatori"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Nomenclator valute"
buton.Style = msoButtonCaption
buton.OnAction = "Open_nomenclt"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Tipuri de acte de identitate"
buton.Style = msoButtonCaption
buton.OnAction = "Open_actid"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Iesire din Access "
buton.Style = msoButtonCaption
buton.OnAction = "SetStartupProperties"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Revenire in Access"
buton.Style = msoButtonCaption
buton.OnAction = "SetarePropStartup"

Set submenu = bara_meniu.Controls.Add(msoControlPopup)

submenu.Caption = "Miscari"
submenu.Visible = True

Set buton = submenu.Controls.Add(msoControlButton)

53
buton.Caption = "Emit bon de miscare"
buton.Style = msoButtonCaption
buton.OnAction = "Open_Miscari0"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Vizualizare bonuri de miscare"
buton.Style = msoButtonCaption
buton.OnAction = "Open_vad_Miscari"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Totaluri miscări"
buton.Style = msoButtonCaption
buton.OnAction = "Open_luna_total_miscari"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Registrul încasări si plăti"
buton.Style = msoButtonCaption
buton.OnAction = "Open_inca_plat"

Set submenu = bara_meniu.Controls.Add(msoControlPopup)

submenu.Caption = "Rapoarte "
submenu.Visible = True

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Registru de casă"
buton.Style = msoButtonCaption
buton.OnAction = "Vad_raport_registru_casa"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Raport BNR"
buton.Style = msoButtonCaption
buton.OnAction = "Vad_raport_la_BNR"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Lista de rotare"
buton.Style = msoButtonCaption
buton.OnAction = "vad_lista_de_rotare"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Jurnal indicatori sintetici"
buton.Style = msoButtonCaption
buton.OnAction = "vad_jurnal_indicatori_sintetici"

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Jurnal solduri si rulaje"
buton.Style = msoButtonCaption
buton.OnAction = "vad_jurnal_solduri_si_rulaje"

Set buton = bara_meniu.Controls.Add(msoControlButton)

buton.Caption = "Inchiderea zilei *"
buton.Style = msoButtonCaption
buton.OnAction = "Jurnale_zilnice"

Set submenu = bara_meniu.Controls.Add(msoControlPopup)

submenu.Caption = "Editare "
submenu.Visible = True

Set buton = submenu.Controls.Add(msoControlButton)

buton.Caption = "Schimbare parola operator in tura"
54
buton.Style = msoButtonCaption
buton.OnAction = "Open_schimb_parola"

Set buton = submenu.Controls _

.Add(msoControlButton, CommandBars("Edit") _
.Controls("Cut").ID)
buton.Style = msoButtonCaption

Set buton = submenu.Controls _

.Add(msoControlButton, CommandBars("Edit") _
.Controls("Copy").ID)

Set buton = submenu.Controls _

.Add(msoControlButton, CommandBars("Edit") _
.Controls("Paste").ID)
'*****************************************

Set buton = bara_meniu.Controls.Add(msoControlButton, CommandBars("File") _

.Controls("exit").ID)
buton.Caption = "Iesire"
buton.Style = msoButtonCaption

'MsgBox "Meniul este instalat close"

bara_meniu.Visible = True
End Sub

Sub Not_Yet()
MsgBox "Programul pt. ac. optiune inca nu este disponibil"
End Sub

Modulul Jurnale

Sub Jurnale_zilnice()
Dim dbsexchange As Database
Dim total_stoc_initial_valuta_ref As Single
'ACESTA ESTE PROGRAMUL PENTRU INCHEIEREA ZILEI
Set dbsexchange = CurrentDb

'Dim rstoperatii As Recordset

Set rstNOMENCLATOR = dbsexchange.OpenRecordset("nomenclt_valuta", dbOpenTable)
Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)
Set rstjurnal_valute = dbsexchange.OpenRecordset("JURNAL_SOLD_RULAJ_VALUTE", dbOpenTable)
Set rstjurnal_sintetici = dbsexchange.OpenRecordset("jurnal_indicatori_sintetici", dbOpenTable)
If rstjurnal_sintetici.RecordCount > 0 Then
rstjurnal_sintetici.MoveLast
If rstjurnal_sintetici!data = Date Then
MsgBox "SITUATIA PE DATA DE ASTAZI A FOST DEJA STOCATA" & vbCr & _
"ORICE TRANZACTIE STOCATA DUPA INCHEIEREA ZILEI TRECE IN CONTUL ZILEI
URMATOARE"
Exit Sub
End If
End If

rstdatefirma.MoveFirst
rstNOMENCLATOR.MoveFirst

' Calculam Casa_in_valuta_echiv

Do While Not rstNOMENCLATOR.EOF

'Daca Rata_in_raport_cu_referinta=0 inseamna ca valuta nu este utilizata in mod curent

If rstNOMENCLATOR!Rata_in_raport_cu_referinta > 0 Then
rstNOMENCLATOR.Edit
55
 rstNOMENCLATOR!Casa_in_valuta_echiv = rstNOMENCLATOR!Casa_in_valuta * rstNOMENCLATOR!
Rata_in_raport_cu_referinta
rstNOMENCLATOR.Update
End If
rstNOMENCLATOR.MoveNext
Loop

Dim TOTAL_SOLD_VALUTA_REF, TOTAL_INTRARI_REF, TOTAL_IESIRI_REF As Single

Dim Total_intrari_ref_misc, Total_iesiri_ref_misc As Single
TOTAL_SOLD_VALUTA_REF = 0
TOTAL_INTRARI_REF = 0
TOTAL_IESIRI_REF = 0
Total_intrari_ref_misc = 0
Total_iesiri_ref_misc = 0
total_stoc_initial_valuta_ref = 0

rstNOMENCLATOR.MoveFirst
Do While Not rstNOMENCLATOR.EOF
'Daca Rata_in_raport_cu_referinta=0 inseamna ca valuta nu este utilizata in mod curent
If rstNOMENCLATOR!Rata_in_raport_cu_referinta > 0 Then
TOTAL_SOLD_VALUTA_REF = TOTAL_SOLD_VALUTA_REF + rstNOMENCLATOR!
Casa_in_valuta_echiv
TOTAL_INTRARI_REF = TOTAL_INTRARI_REF + rstNOMENCLATOR!Rulaj_intrari_valuta *
rstNOMENCLATOR!Rata_in_raport_cu_referinta
TOTAL_IESIRI_REF = TOTAL_IESIRI_REF + rstNOMENCLATOR!Rulaj_iesiri_valuta *
rstNOMENCLATOR!Rata_in_raport_cu_referinta
total_stoc_initial_valuta_ref = total_stoc_initial_valuta_ref + rstNOMENCLATOR!
Stoc_initial_in_valuta_echiv
Total_intrari_ref_misc = Total_intrari_ref_misc + rstNOMENCLATOR!Rulaj_intrari_valuta_misc *
rstNOMENCLATOR!Rata_in_raport_cu_referinta
Total_iesiri_ref_misc = Total_iesiri_ref_misc + rstNOMENCLATOR!Rulaj_iesiri_valuta_misc *
rstNOMENCLATOR!Rata_in_raport_cu_referinta
With rstjurnal_valute

.AddNew
'Urmatoarea instr. obliga sa rulam acest program la sf .zilei curente, pt. maine!
!data = DateAdd("d", 1, Date)
!Codvalut = rstNOMENCLATOR!Codvalut
!Casa_in_valuta = rstNOMENCLATOR!Casa_in_valuta
!Casa_in_valuta_echiv = rstNOMENCLATOR!Casa_in_valuta_echiv
!Stoc_initial_in_valuta = rstNOMENCLATOR!Stoc_initial_in_valuta
!Stoc_initial_in_valuta_echiv = rstNOMENCLATOR!Stoc_initial_in_valuta_echiv
!Rulaj_intrari_valuta = rstNOMENCLATOR!Rulaj_intrari_valuta
!Rulaj_iesiri_valuta = rstNOMENCLATOR!Rulaj_iesiri_valuta
!Rulaj_intrari_valuta_misc = rstNOMENCLATOR!Rulaj_intrari_valuta_misc
!Rulaj_iesiri_valuta_misc = rstNOMENCLATOR!Rulaj_iesiri_valuta_misc
!Cod_PSV = rstdatefirma!Cod_PSV
.Update
End With
End If
rstNOMENCLATOR.MoveNext
Loop

rstNOMENCLATOR.MoveFirst
Do While Not rstNOMENCLATOR.EOF
'Daca Rata_in_raport_cu_referinta=0 inseamna ca valuta nu este utilizata in mod curent
If rstNOMENCLATOR!Rata_in_raport_cu_referinta > 0 Then
rstNOMENCLATOR.Edit
rstNOMENCLATOR!Stoc_initial_in_valuta = rstNOMENCLATOR!Casa_in_valuta
rstNOMENCLATOR!Stoc_initial_in_valuta_echiv = rstNOMENCLATOR!Casa_in_valuta_echiv
rstNOMENCLATOR!Rulaj_intrari_valuta = 0
rstNOMENCLATOR!Rulaj_iesiri_valuta = 0
rstNOMENCLATOR!Rulaj_intrari_valuta_misc = 0
56
 rstNOMENCLATOR!Rulaj_iesiri_valuta_misc = 0
rstNOMENCLATOR.Update
End If
rstNOMENCLATOR.MoveNext
Loop

With rstjurnal_sintetici
.AddNew

!data = InputBox("Introduceti data zilei care se inchide. De ex. 24.08.05")

!Sold_initial_valut_ref = total_stoc_initial_valuta_ref
!Sold_sf_zilei_valut_ref = TOTAL_SOLD_VALUTA_REF
!Total_intrari_valut_ref = TOTAL_INTRARI_REF
!Total_iesiri_valut_ref = TOTAL_IESIRI_REF
!Total_intrari_ref_misc = Total_intrari_ref_misc
!Total_iesiri_ref_misc = Total_iesiri_ref_misc
!Profit_ref_la_sf_zilei = !Sold_sf_zilei_valut_ref - (!Sold_initial_valut_ref + !Total_intrari_ref_misc - !
Total_iesiri_ref_misc)
!Profit_lei_la_sf_zilei = !Profit_ref_la_sf_zilei * rstdatefirma!Curs_BNR_leu_dolar
!Curs_BNR = rstdatefirma!Curs_BNR_leu_dolar
!Cod_PSV = rstdatefirma!Cod_PSV
.Update
End With
MsgBox "Gata! Inchiderea a decurs normal."
DoCmd.OpenForm "jurnal _indicatori_sintetici"

rstNOMENCLATOR.Close
rstjurnal_sintetici.Close
rstjurnal_valute.Close
rstdatefirma.Close
dbsexchange.Close
End Sub

Private Sub Form_Open(Cancel As Integer)

Dim dbsexchange As Database
Dim i As Byte

Set dbsexchange = CurrentDb

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

' Initializam nr de incercari la parola

rstdatefirma.MoveFirst
rstdatefirma.Edit
rstdatefirma!nr_incercari_parola = 0
rstdatefirma.Update

meniu_aplicatie

Set v = CommandBars("exchange")
For i = 1 To 5
Set ultimul = v.Controls(i)
ultimul.Visible = False
Next i

rstdatefirma.Close
dbsexchange.Close
End Sub

Private Sub Text27_AfterUpdate()

' Aceasta caseta verifica codul utilizator si daca este corect verifica parola
Dim dbsexchange As Database
57
 Set dbsexchange = CurrentDb
Set rstutil = dbsexchange.OpenRecordset("util", dbOpenTable)
Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst
If rstdatefirma!nr_incercari_parola > 2 Then
MsgBox "Accesul blocat. Abandonati acest formular!"
Text25.Visible = False
'Text27.Visible = False

Exit Sub
End If

rstutil.Index = "primarykey"
rstutil.MoveFirst
'MsgBox Me!Text25
rstutil.Seek "=", Me!Text25

If rstutil.NoMatch Then
MsgBox " cod operator gresit!"
Exit Sub
End If

rstdatefirma.Edit
rstdatefirma!nr_incercari_parola = rstdatefirma!nr_incercari_parola + 1
rstdatefirma.Update
If rstutil!parola <> Me!Text27 Then
MsgBox "parola gresita!"
Exit Sub
Else
rstdatefirma.Edit
rstdatefirma!Cod_utilizator_in_tura = Me!Text25
rstdatefirma.Update
Me!Command4.Visible = True
End If

rstutil.Close
rstdatefirma.Close
dbsexchange.Close
End Sub

Private Sub Command4_Click()

Dim dbsexchange As Database

Set dbsexchange = CurrentDb
Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst
If rstdatefirma!nr_incercari_parola > 3 Then Exit Sub

Set v = CommandBars("exchange")
For i = 1 To 5
Set ultimul = v.Controls(i)
ultimul.Visible = True
Next i

Me!Label26.Visible = False
Me!Text25.Visible = False
Me!Label28.Visible = False
Me!Text27.Visible = False

58
 Me!Box5.Visible = False
Me!Command4.Transparent = True
rstdatefirma.Close
dbsexchange.Close

End Sub

Private Sub Form_Close()

'Set v = CommandBars("exchange")
'For i = 1 To 5
'Set ultimul = v.Controls(i)
'ultimul.Visible = False
'Next i
End Sub

Formularul Nomenclt_valuta
Private Sub Form_Current()
Me.Rata_in_raport_cu_referinta_Label.Visible = True
Me.Text22.Visible = True
Me.Label24.Visible = True
Me.Rata_in_raport_cu_referinta.Visible = True
Me.Command21.Visible = True
Me.Rata_cumpar_lei_Label.Visible = True
Me.Text25.Visible = True
Me.Rata_cumpar_lei.Visible = True
Me.Label19.Visible = True
Me.Rata_vand_lei_Label.Visible = True
Me.Text26.Visible = True
Me.Rata_vand_lei.Visible = True
Me.Label20.Visible = True
Me.o_singura_valuta.Visible = True
Me.Command21.Visible = False
If Me.Codvalut = "USD" Then Me.Command21.Visible = True

If Me.Codvalut = "Leu" Then

Me.Rata_in_raport_cu_referinta_Label.Visible = False
Me.Text22.Visible = False
Me.Label24.Visible = False
Me.Rata_in_raport_cu_referinta.Visible = False
Me.Command21.Visible = False
Me.Rata_cumpar_lei_Label.Visible = False
Me.Text25.Visible = False
Me.Rata_cumpar_lei.Visible = False
Me.Label19.Visible = False
Me.Rata_vand_lei_Label.Visible = False
Me.Text26.Visible = False
Me.Rata_vand_lei.Visible = False
Me.Label20.Visible = False
Me.o_singura_valuta.Visible = False

End If
End Sub

Private Sub Rata_in_raport_cu_referinta_Exit(Cancel As Integer)

If Me.nrcrt < 3 Then Exit Sub
Dim dbsexchange As Database
Set dbsexchange = CurrentDb
'Dim rstoperatii As Recordset
Set rstNOMENCLATOR = dbsexchange.OpenRecordset("nomenclt_valuta", dbOpenTable)
rstNOMENCLATOR.Index = "primarykey"

59
 rstNOMENCLATOR.MoveFirst
Me.Rata_cumpar_lei = Me.Rata_in_raport_cu_referinta * rstNOMENCLATOR!Rata_cumpar_lei
Me.Rata_vand_lei = Me.Rata_in_raport_cu_referinta * rstNOMENCLATOR!Rata_vand_lei
rstNOMENCLATOR.Close
dbsexchange.Close
End Sub
Private Sub Command21_Click()
On Error GoTo Err_Command21_Click
If Me.nrcrt = 2 Then
Dim dbsexchange As Database
Dim rata_cumpar, rata_vand As Single
Set dbsexchange = CurrentDb
'Dim rstoperatii As Recordset
Set rstNOMENCLATOR = dbsexchange.OpenRecordset("nomenclt_valuta", dbOpenTable)
Set rstISTORIC = dbsexchange.OpenRecordset("ISTORIC_RATE_SCHIMB", dbOpenTable)

rstNOMENCLATOR.Index = "primarykey"
rstNOMENCLATOR.MoveFirst
rstNOMENCLATOR.Move 1
rata_cumpar = rstNOMENCLATOR!Rata_cumpar_lei
rata_vand = rstNOMENCLATOR!Rata_vand_lei

rstNOMENCLATOR.Move 1
Do While Not rstNOMENCLATOR.EOF
'Daca Rata_in_raport_cu_referinta=0 inseamna ca valuta nu este utilizata in mod curent
If rstNOMENCLATOR!Rata_in_raport_cu_referinta > 0 Then
rstNOMENCLATOR.Edit
rstNOMENCLATOR!Rata_cumpar_lei = rstNOMENCLATOR!Rata_in_raport_cu_referinta * rata_cumpar
rstNOMENCLATOR!Rata_vand_lei = rstNOMENCLATOR!Rata_in_raport_cu_referinta * rata_vand
rstNOMENCLATOR.Update

rstISTORIC.AddNew
rstISTORIC!data = Date
rstISTORIC!ora = Time()
rstISTORIC!cod_valuta = rstNOMENCLATOR!Codvalut
rstISTORIC!rata_cumpar_in_lei = rstNOMENCLATOR!Rata_cumpar_lei
rstISTORIC!rata_vand_in_lei = rstNOMENCLATOR!Rata_vand_lei
rstISTORIC.Update
End If

rstNOMENCLATOR.MoveNext
Loop
End If
rstISTORIC.Close
rstNOMENCLATOR.Close
dbsexchange.Close
Exit_Command21_Click:
Exit Sub

Err_Command21_Click:
MsgBox Err.Description
Resume Exit_Command21_Click

End Sub
Private Sub o_singura_valuta_Click()
On Error GoTo Err_o_singura_valuta_Click
' Acest buton creaza un articol cu cele doua rate noi introduse din formular
Dim dbsexchange As Database

Set dbsexchange = CurrentDb

Set rstISTORIC = dbsexchange.OpenRecordset("ISTORIC_RATE_SCHIMB", dbOpenTable)
60
 rstISTORIC.AddNew
rstISTORIC!data = Date
rstISTORIC!ora = Time()
rstISTORIC!cod_valuta = Me.Codvalut
rstISTORIC!rata_cumpar_in_lei = Me.Rata_cumpar_lei
rstISTORIC!rata_vand_in_lei = Me.Rata_vand_lei
rstISTORIC.Update

rstISTORIC.Close
dbsexchange.Close
Exit_o_singura_valuta_Click:
Exit Sub

Err_o_singura_valuta_Click:
MsgBox Err.Description
Resume Exit_o_singura_valuta_Click

End Sub
Private Sub Command29_Click()
On Error GoTo Err_Command29_Click

DoCmd.Close

Exit_Command29_Click:
Exit Sub

Err_Command29_Click:
MsgBox Err.Description
Resume Exit_Command29_Click

End Sub

Formularul Luna Raport la BNR

Private Sub Command4_Click()
On Error GoTo Err_Command4_Click

DoCmd.Close

Exit_Command4_Click:
Exit Sub

Err_Command4_Click:
MsgBox Err.Description
Resume Exit_Command4_Click

End Sub

Private Sub luna_Exit(Cancel As Integer)

Dim dbsexchange As Database
Dim lunile(12) As String
Set dbsexchange = CurrentDb
lunile(1) = "ianuarie"
lunile(2) = "februarie"
lunile(3) = "martie"
lunile(4) = "aprilie"
lunile(5) = "mai"
lunile(6) = "iunie"
lunile(7) = "iulie"
lunile(8) = "august"
lunile(9) = "septembrie"
61
lunile(10) = "octombrie"
lunile(11) = "noiembrie"
lunile(12) = "decembrie"

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst

rstdatefirma.Edit
rstdatefirma!Nume_luna = lunile(luna)
rstdatefirma.Update
rstdatefirma.Close
dbsexchange.Close
End Sub
Private Sub vizualizare_Click()
Dim Interogare As QueryDef
Dim prmdata1 As Parameter
Dim dbsexchange As Database
Set dbsexchange = CurrentDb

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst
DoCmd.OpenQuery "Golesc_Raport_BNR_table"
Set Interogare = dbsexchange.CreateQueryDef("", _
"INSERT INTO Raport_BNR_table ( cod_valut, suma_incas, suma_plat, tip_op, data_doc, Luna )" & _
" SELECT incaplat.cod_valut, incaplat.suma_incas, incaplat.suma_plat, incaplat.tip_op, incaplat.data_doc,
Month([data_doc]) AS Luna" & _
" FROM incaplat RIGHT JOIN datefirma ON incaplat.Cod_PSV = datefirma.Cod_PSV" & _
" WHERE (((Month([data_doc])) = [prmdata1]))" & _
" GROUP BY incaplat.cod_valut, incaplat.suma_incas, incaplat.suma_plat, incaplat.tip_op, incaplat.data_doc")
Interogare.Parameters("prmdata1") = rstdatefirma!luna
Interogare.Execute
'MsgBox "Am facut tabelul Raport_BNR_table cu tranzactii pe luna crt extrase din incaplat"

DoCmd.OpenQuery "golesc_raport_BNR_tabel"

Set rstTable = dbsexchange.OpenRecordset("Raport_BNR_table", dbOpenTable)

Set rstTabel = dbsexchange.OpenRecordset("Raport_BNR_tabel", dbOpenTable)
'Acum completez tabelul Raport_BNR_tabel cu date din tabelul raport_BNR_table
rstTable.MoveFirst
Do While Not rstTable.EOF
If ((rstTable!cod_valut = "LEU") Or (rstTable!cod_valut = "Lei")) Then GoTo nextart
With rstTabel
.AddNew
!cod_valut = rstTable!cod_valut
Select Case rstTable!tip_op
Case "cumparare"
!cumparat = rstTable!suma_incas
Case "cump_pers"
!cumpar_pers = rstTable!suma_incas
Case "ridicare"
!alimentari = rstTable!suma_incas
Case "intrare"
!alimentari = rstTable!suma_incas
Case "vanzare"
!vanzari = rstTable!suma_plat
Case "iesire"
!remiteri = rstTable!suma_plat
Case "depunere"
!remiteri = rstTable!suma_plat
Case Else
'MsgBox "tip operatie eronat !" & rstTable!tip_op
End Select
.Update
62
 End With
nextart: rstTable.MoveNext
Loop

'MsgBox "am dispersat campurile din Raport_BNR_table in tabelul Raport_BNR_tabel"

' Interogarea "Completez_raport_BNR_tabel_final" insumeaza tranzactiile pe coduri
DoCmd.OpenQuery "golesc_BNR_tabel_final"
DoCmd.OpenQuery "Completez_raport_BNR_tabel_final"
'MsgBox "Am facut totalurile pe fiecare cod valuta in tabelul Raport_BNR_final"

DoCmd.OpenQuery "golesc_sold_init_final"

Set Interogare = dbsexchange.CreateQueryDef("", _

"INSERT INTO sold_init_sold_final ( Codvalut, Stoc_initial_in_valuta, Casa_in_valuta, DATA )" & _
" SELECT JURNAL_SOLD_RULAJ_VALUTE.Codvalut,
JURNAL_SOLD_RULAJ_VALUTE.Stoc_initial_in_valuta,
JURNAL_SOLD_RULAJ_VALUTE.Casa_in_valuta, JURNAL_SOLD_RULAJ_VALUTE.DATA" & _
" FROM JURNAL_SOLD_RULAJ_VALUTE" & _
" WHERE (((Month([data])) = [prmdata1]))" & _
" GROUP BY JURNAL_SOLD_RULAJ_VALUTE.Codvalut,
JURNAL_SOLD_RULAJ_VALUTE.Stoc_initial_in_valuta,
JURNAL_SOLD_RULAJ_VALUTE.Casa_in_valuta, JURNAL_SOLD_RULAJ_VALUTE.DATA")

Interogare.Parameters("prmdata1") = rstdatefirma!luna
Interogare.Execute

'MsgBox "Am extras din JURNAL_SOLD_RULAJ_VALUTE articolele referitoare la luna crt" & vbCr & _
"si le-am depus in sold_init_sold_final "

Dim INCEP_LUNA, sf_luna As Date

DoCmd.OpenQuery "GOLESC_SOLD_INIT_BNR"
Set rst_init_final = dbsexchange.OpenRecordset("sold_init_sold_final", dbOpenTable)

If rst_init_final.RecordCount = 0 Then
'MsgBox "in aceasta luna nu au fost tranzactii"
Exit Sub
End If

rst_init_final.MoveFirst
INCEP_LUNA = rst_init_final!data

Set Interogare = dbsexchange.CreateQueryDef("", _

"INSERT INTO SOLD_INIT_BNR ( Codvalut, Stoc_initial_in_valuta )" & _
" SELECT sold_init_sold_final.Codvalut, sold_init_sold_final.Stoc_initial_in_valuta" & _
" FROM sold_init_sold_final" & _
" WHERE (((sold_init_sold_final.DATA)=[prmdata1]))")

Interogare.Parameters("prmdata1") = INCEP_LUNA
Interogare.Execute

'MsgBox "Am extras in SOLD_INIT_BNR soldurile initiale din prima zi din luna crt"

DoCmd.OpenQuery "GOLESC_SOLD_FINAL_BNR"
rst_init_final.MoveLast
sf_luna = rst_init_final!data

Set Interogare = dbsexchange.CreateQueryDef("", _

"INSERT INTO SOLD_FINAL_BNR ( Codvalut, Casa_in_valuta )" & _
" SELECT sold_init_sold_final.Codvalut, sold_init_sold_final.Casa_in_valuta" & _
" FROM sold_init_sold_final" & _
" WHERE (((sold_init_sold_final.DATA)=[prmdata1]))")

Interogare.Parameters("prmdata1") = sf_luna
63
Interogare.Execute

'MsgBox "Am extras in SOLD_FINAL_BNR soldurile finale din ultima zi din luna crt"
Set rstTABEL_final = dbsexchange.OpenRecordset("Raport_BNR_final", dbOpenTable)

'Completam tabelul final cu codul PSV, cu sold initial si sold final

rstTABEL_final.MoveFirst
Do While Not rstTABEL_final.EOF
rstTABEL_final.Edit
rstTABEL_final!Cod_PSV = rstdatefirma!Cod_PSV
rstTABEL_final.Update
rstTABEL_final.MoveNext
Loop
'MsgBox "acum se poate rula interogarea Raport BNR"

DoCmd.OpenReport "Raport_BNR", acViewPreview

rstTable.Close
rstTabel.Close
rstTABEL_final.Close
rstdatefirma.Close
dbsexchange.Close
End Sub
Private Sub tiparire_Click()
DoCmd.OpenReport "Raport_BNR", acViewPrint
DoCmd.Close
End Sub

Formularul luna Total Miscari

Private Sub Command4_Click()
On Error GoTo Err_Command4_Click

DoCmd.Close

Exit_Command4_Click:
Exit Sub

Err_Command4_Click:
MsgBox Err.Description
Resume Exit_Command4_Click

End Sub

Private Sub luna_Exit(Cancel As Integer)

Dim dbsexchange As Database
Dim lunile(12) As String
Set dbsexchange = CurrentDb
lunile(1) = "ianuarie"
lunile(2) = "februarie"
lunile(3) = "martie"
lunile(4) = "aprilie"
lunile(5) = "mai"
lunile(6) = "iunie"
lunile(7) = "iulie"
lunile(8) = "august"
lunile(9) = "septembrie"
lunile(10) = "octombrie"
lunile(11) = "noiembrie"
lunile(12) = "decembrie"

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

64
 rstdatefirma.MoveFirst

rstdatefirma.Edit
rstdatefirma!Nume_luna = lunile(luna)
rstdatefirma.Update
rstdatefirma.Close
dbsexchange.Close
End Sub
Private Sub vizualizare_Click()
Dim Interogare As QueryDef
Dim prmdata1 As Parameter
Dim dbsexchange As Database
Set dbsexchange = CurrentDb

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst
DoCmd.OpenQuery "golesc_total_misc"
Set Interogare = dbsexchange.CreateQueryDef("", _
"INSERT INTO Total_miscari_table ( Cod_valut, Suma, Tip_operatie, Tip_buletin_miscare, Data_operatie,
incas_in_valuta_echiv, plati_in_valuta_echiv )" & _
" SELECT Miscari.Cod_valut, Miscari.Suma, Miscari.Tip_operatie, Miscari.Tip_buletin_miscare,
Miscari.Data_operatie, Miscari.incas_in_valuta_echiv, Miscari.plati_in_valuta_echiv" & _
" FROM miscari" & _
" WHERE (((Month([Data_operatie])) = [prmdata1]))" & _
" GROUP BY Miscari.Cod_valut, Miscari.Suma, Miscari.Tip_operatie, Miscari.Tip_buletin_miscare,
Miscari.Data_operatie, Miscari.incas_in_valuta_echiv, Miscari.plati_in_valuta_echiv")

Interogare.Parameters("prmdata1") = rstdatefirma!luna
Interogare.Execute
'MsgBox "Am facut tabelul Total_miscari_table cu tranzactii pe luna crt extrase din miscari"

DoCmd.OpenQuery "golesc_total_misc_tabel"

Set rstTable = dbsexchange.OpenRecordset("Total_miscari_table", dbOpenTable)

Set rstTabel = dbsexchange.OpenRecordset("Total_miscari_tabel", dbOpenTable)
'Acum completez tabelul Total_miscari_tabel cu date din tabelul Total_miscari_table
rstTable.MoveFirst
Do While Not rstTable.EOF
If ((rstTable!cod_valut = "LEU") Or (rstTable!cod_valut = "Lei")) Then GoTo nextart
With rstTabel
.AddNew
!cod_valut = rstTable!cod_valut
If ((rstTable!Tip_operatie = "intrare") Or (rstTable!Tip_operatie = "ridicare")) Then

Select Case rstTable!Tip_buletin_miscare

Case "banca"
!intrari_banca = rstTable!Suma
!intrari_banca0 = rstTable!incas_in_valuta_echiv
Case "PSV"
!intrari_PSV = rstTable!Suma
!intrari_PSV0 = rstTable!incas_in_valuta_echiv
Case "alte"
!alte_intrari = rstTable!Suma
!alte_intrari0 = rstTable!incas_in_valuta_echiv
Case Else
MsgBox "tip buletin miscare eronat"
End Select
Else

Select Case rstTable!Tip_buletin_miscare

Case "banca"
!iesiri_banca = rstTable!Suma
!iesiri_banca0 = rstTable!plati_in_valuta_echiv
65
 Case "PSV"
!iesiri_PSV = rstTable!Suma
!iesiri_PSV0 = rstTable!plati_in_valuta_echiv
Case "chelt"
!cheltuieli = rstTable!Suma
!cheltuieli0 = rstTable!plati_in_valuta_echiv
Case "alte"
!alte_iesiri = rstTable!Suma
!alte_iesiri0 = rstTable!plati_in_valuta_echiv
Case Else
MsgBox "tip buletin miscare eronat"
End Select
End If
.Update
End With
nextart: rstTable.MoveNext
Loop

'MsgBox "am dispersat campurile din Total_misc_table in tabelul Total_misc_tabel"

' Interogarea "Completez_total_misc_final" insumeaza tranzactiile pe coduri
DoCmd.OpenQuery "golesc_total_misc_final"
DoCmd.OpenQuery "Completez_total_misc_final"
'MsgBox "Am facut totalurile pe fiecare cod valuta in tabelul Raport_total_misc_final"
'In tabelul Raport_total_miscari_echiv calculam total general pe tipuri de intrari si
'iesiri in valuta
DoCmd.OpenQuery "golesc_total_misc_echiv"
DoCmd.OpenQuery "completez_Total_miscari_echiv"

'Acum completam campul cu codul_PSV din tabelul raport_Total_miscari_echiv

Set rstechiv = dbsexchange.OpenRecordset("raport_Total_miscari_echiv", dbOpenTable)
rstechiv.MoveFirst
rstechiv.Edit
rstechiv!Cod_PSV = rstdatefirma!Cod_PSV
rstechiv.Update
'Acum completam campul cu codul_PSV din tabelul raport_Total_miscari_final
Set rstfinal = dbsexchange.OpenRecordset("raport_Total_miscari_final", dbOpenTable)
rstfinal.MoveFirst
Do While Not rstfinal.EOF
rstfinal.Edit
rstfinal!Cod_PSV = rstdatefirma!Cod_PSV
rstfinal.Update
rstfinal.MoveNext
Loop

'MsgBox "Acum raportul "Raport_totaluri_misc" va rula interogarea

' Raport_totaluri_misc1 si apoi Raport_totaluri_misc2"

DoCmd.OpenReport "Raport_totaluri_misc", acViewPreview

'Prezentul formular se va rula cu macroul "View_raport_total_misc"

rstTable.Close
rstTabel.Close
rstTABEL_final.Close
rstdatefirma.Close
dbsexchange.Close

DoCmd.Close
End Sub
Private Sub tiparire_Click()
DoCmd.OpenReport "Raport_totaluri_misc", acViewPrint
End Sub

66
Formularul Miscari
Private Sub Nr_Buletin_miscare_Enter()
Dim dbscontabil As Database
Set dbscontabil = CurrentDb
Set rstbuletin = dbscontabil.OpenRecordset("miscari", dbOpenTable)

If rstbuletin.BOF Then
MsgBox "Deocamdata nu este inregistrata nici o cumparare, deci puteti pune orice nr si serie"
Exit Sub
End If
rstbuletin.MoveLast
Me!Nr_Buletin_miscare = rstbuletin!Nr_Buletin_miscare
Me!Seria_buletin = rstbuletin!Seria_buletin
MsgBox "Noul buletin este completat cu nr si seria celui precedent. Faceti modificarile ce se impun!"
rstbuletin.Close
dbscontabil.Close
End Sub

Private Sub Suma_AfterUpdate()

Dim dbsexchange As Database
Set dbsexchange = CurrentDb

Set rstnomenclt = dbsexchange.OpenRecordset("nomenclt_valuta", dbOpenTable)

rstnomenclt.Index = "cod_valuta"

rstnomenclt.MoveFirst
rstnomenclt.Seek "=", Me!cod_valut
If rstnomenclt.NoMatch Then MsgBox "Cod valuta eronat sau nu este trecut in nomenclator"
If ((Me!Tip_operatie = "intrare") Or (Me!Tip_operatie = "ridicare")) Then
Me!incas_in_valuta_echiv = Me!Suma * rstnomenclt!Rata_in_raport_cu_referinta
Me!plati_in_valuta_echiv = 0
End If
If ((Me!Tip_operatie = "iesire") Or (Me!Tip_operatie = "depunere")) Then
Me!incas_in_valuta_echiv = 0
Me!plati_in_valuta_echiv = Me!Suma * rstnomenclt!Rata_in_raport_cu_referinta
End If
rstnomenclt.Close
dbsexchange.Close
End Sub

Private Sub vizualizare_Click()

Dim dbsexchange As Database
Dim suma_echiv As Single
Set dbsexchange = CurrentDb

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst
Me!Cod_utilizator = rstdatefirma!Cod_utilizator_in_tura
rstdatefirma.Edit
rstdatefirma!Nr_Buletin_miscare = Me!Nr_Buletin_miscare
rstdatefirma.Update
Set rstraport = dbsexchange.OpenRecordset("Raport_miscari", dbOpenTable)
begin: If rstraport.RecordCount > 0 Then
rstraport.MoveLast
rstraport.Delete
GoTo begin
Else
With rstraport
.AddNew
!Nr_Buletin_miscare = Me!Nr_Buletin_miscare

67
!Seria_buletin = Me!Seria_buletin
!Tip_operatie = Me!Tip_operatie
!Tip_buletin_miscare = Me!Tip_buletin_miscare
!Sursa_Destinatia = Me!Sursa_Destinatia
!Data_operatie = Me!Data_operatie
!Descriere_miscare = Me!Descriere_miscare
!cod_valut = Me!cod_valut
!Suma = Me!Suma
!plati_in_valuta_echiv = Me!plati_in_valuta_echiv
!incas_in_valuta_echiv = Me!incas_in_valuta_echiv
!Cod_utilizator = Me!Cod_utilizator
.Update
End With
End If
DoCmd.RunMacro "vad_raport_miscari"

rstdatefirma.Close
rstraport.Close
dbsexchange.Close

End Sub

Private Sub tiparire_Click()

Dim dbsexchange As Database
Dim suma_echiv As Single
Set dbsexchange = CurrentDb

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst
Me!Cod_utilizator = rstdatefirma!Cod_utilizator_in_tura
Me!Cod_PSV = rstdatefirma!Cod_PSV
rstdatefirma.Edit
rstdatefirma!Nr_Buletin_miscare = Me!Nr_Buletin_miscare
rstdatefirma.Update

If Me!descarcat_in_incaplat = 1 Then GoTo raport

'Actualizare tabel Incasari-plati

Set rstincaplat = dbsexchange.OpenRecordset("incaplat", dbOpenTable)
Set rstnomenclt = dbsexchange.OpenRecordset("nomenclt_valuta", dbOpenTable)
rstnomenclt.Index = "cod_valuta"
With rstincaplat

.AddNew
!Cod_PSV = Me!Cod_PSV
!Cod_utilizator_in_tura = Me!Cod_utilizator
!tip_op = Me!Tip_operatie
!document = "buletin miscari"
!nr_doc = Me!Nr_Buletin_miscare
!seria_doc = Me!Seria_buletin
!data_doc = Me!Data_operatie
!cod_valut = Me!cod_valut

rstnomenclt.MoveFirst
rstnomenclt.Seek "=", Me!cod_valut

rstnomenclt.Edit
If ((Me!Tip_operatie = "intrare") Or (Me!Tip_operatie = "ridicare")) Then
!suma_incas = Me!Suma
!suma_plat = 0
Me!incas_in_valuta_echiv = Me!Suma * rstnomenclt!Rata_in_raport_cu_referinta
!incas_in_valuta_echiv = Me!incas_in_valuta_echiv
!plati_in_valuta_echiv = 0
68
 Me!plati_in_valuta_echiv = 0
rstnomenclt!Casa_in_valuta = rstnomenclt!Casa_in_valuta + Me!Suma
rstnomenclt!Rulaj_intrari_valuta_misc = rstnomenclt!Rulaj_intrari_valuta_misc + Me!Suma
End If

If ((Me!Tip_operatie = "iesire") Or (Me!Tip_operatie = "depunere")) Then

!suma_plat = Me!Suma
!suma_incas = 0
Me!incas_in_valuta_echiv = 0
!incas_in_valuta_echiv = 0
Me!plati_in_valuta_echiv = Me!Suma * rstnomenclt!Rata_in_raport_cu_referinta
!plati_in_valuta_echiv = Me!plati_in_valuta_echiv
rstnomenclt!Casa_in_valuta = rstnomenclt!Casa_in_valuta - Me!Suma
rstnomenclt!Rulaj_iesiri_valuta_misc = rstnomenclt!Rulaj_iesiri_valuta_misc + Me!Suma
End If
rstnomenclt.Update

Me!descarcat_in_incaplat = 1
.Update

End With

raport:
Set rstraport = dbsexchange.OpenRecordset("Raport_miscari", dbOpenTable)
begin: If rstraport.RecordCount > 0 Then
rstraport.MoveLast
rstraport.Delete
GoTo begin
Else
With rstraport
.AddNew
!Nr_Buletin_miscare = Me!Nr_Buletin_miscare
!Seria_buletin = Me!Seria_buletin
!Tip_operatie = Me!Tip_operatie
!Tip_buletin_miscare = Me!Tip_buletin_miscare
!Sursa_Destinatia = Me!Sursa_Destinatia
!Data_operatie = Me!Data_operatie
!Descriere_miscare = Me!Descriere_miscare
!cod_valut = Me!cod_valut
!Suma = Me!Suma
!plati_in_valuta_echiv = Me!plati_in_valuta_echiv
!incas_in_valuta_echiv = Me!incas_in_valuta_echiv
!Cod_utilizator = Me!Cod_utilizator
.Update
End With
End If
DoCmd.RunMacro "Print_raport_miscari"
rstincaplat.Close
rstdatefirma.Close
rstraport.Close
dbsexchange.Close

End Sub
Private Sub Iesire_Click()
On Error GoTo Err_Iesire_Click
Dim dbsexchange As Database
Set dbsexchange = CurrentDb

Set rstdatefirma = dbsexchange.OpenRecordset("datefirma", dbOpenTable)

rstdatefirma.MoveFirst
Me!Cod_utilizator = rstdatefirma!Cod_utilizator_in_tura

69
 Bi
Decizii r
SISTEM
Rolul ro DE i lo
nestructurate
ti c
p e rt
INFORMAT
CONDUCE
sistemelor a +S
ae
x
ist DoCmd.Close
IRE
IONAL em in i re
informaţion
I(neprogramate)
E
Sisteme
ISN
e
i j
dep r a l e
rstdatefirma.Close
es dbsexchange.Close
ale
(inclusiv
IE
N SISTEM în
(decizional) e d g r up
IT
Deciziitem
informatic)
s ur Exit_Iesire_Click:
conducerea
E
T
R i
CONDUS
SSISTEME
S
semistructurate
i lo
rd
lu e Exit Sub
cr
u
Err_Iesire_Click:
MsgBox Err.Description
Resume Exit_Iesire_Click

End Sub
Private Sub renunt_Click()
On Error GoTo Err_renunt_Click

If Me!descarcat_in_incaplat = False Then

DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70
Else
MsgBox "Articolul a fost validat. Nu se mai poate sterge!"
End If
Exit_renunt_Click:
Exit Sub

Err_renunt_Click:
MsgBox Err.Description
Resume Exit_renunt_Click

End Sub

70