. Aplicatie Informatica Pentru Casele de Schimb
C U P R I N S
Pag.
=== l ===
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 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ță.
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 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;
– exemple : MERISE, AXIAL, Information Engineering (J. Martin).
Avantaje: sistemele se axează pe conceptul de bază de date, care oferă mai multă coerență, stabilitate și elimină redondanțele;
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;
– 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.
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.
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: reprezentarea legăturii sau corespondenței existente între două sau mai multe realizări de entități.
O asociere nu are existență de sine 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ă:
Î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: valorile luate de identificatorul entității trebuie să fie unice și nenule;
– integritatea 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
După momentul în care acționează, există două clase de RI: statice și 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: dacă o entitate E joacă un rol r1 într-o asociere a1, atunci trebuie să joace și rolul r2 într-o asociere a2.
Notația grafică:
Egalitatea: restricția de incluziune între rolurile r1 si r2 ale entitătii este reciprocă.
Notația grafică:
Excluziunea: rolurile r1 si r2 ale entității se exclud reciproc.
Notatia grafică:
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.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.
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ă.
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ă AB dacă fiecărei valori a lui A îi corespunde o singură valoare a lui B.
Spre 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. 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ă:
AB
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.
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.
1.2.4.2. 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: O entitate este în FN1 dacă toate atributele sale sunt elementare și nerepetitive.
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: 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;
– 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 (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).
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. (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
Conform figurii alăturate, diferitele reguli de emisiune sunt reprezentate în partea inferioară a dreptunghiului ce descrie operația.
Reprezentarea este analogă unei formulări de genul :
Dacă regula de emisiune 1
atunci Rezultat A și Rezultat B
altfel (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.
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ă 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.
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.
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.
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.
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
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.
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.
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.
5) Atributele externe echivalente atributelor conceptuale trebuie să aibă același nume.
1.4.3. Reguli de validare în consultare
Atributele externe trebuie 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.
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.
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)
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
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.
Restricție de integritate referentială (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: tipul de entitate generică dispare iar atributele sunt adăugate la fiecare dintre subtipuri.
b) se favorizează 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 Logică a Prelucrărilor (MLP)
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).
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 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.
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.
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;
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:
Structura informațională a acestor rapoarte se prezintă în continuare:
CSV……..
PSV…….. cod: BM
Buletin de mișcare valută (chitanță)
CSV……..
PSV…….. cod: RC
REGISTRU DE CASĂ
la data D,8
CSV……..
PSV…….. cod: RBNR
RAPORT BNR
luna… C,10
CSV……..
PSV…….. cod: TM
TOTAL MIȘCĂRI
luna… C,10
CSV……..
PSV…….. cod: LR
LISTA DE ROTARE
la data D,8
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:
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ă:
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:
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ă 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)
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:
Transfer sume valută între PSV și CSV în mod direct sau prin intermediul băncii
Raportări lunare către BNR.
În aceste condiții, MCP referitor la reportările lunare către BNR este următorul:
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:
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;
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:
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:
2.4.3. Meniul aplicației
Meniul principal este format din următoarele opțiuni și subopțiuni descrise în ordinea utilizării acestora:
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ă
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“.
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“.
2.4.4.4. Inchiderea Zilei, Jurnal indicatori sintetici, 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 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.
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.
Î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.
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.
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.
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.
Cu opțiunea Lista de rotare se obține raportul cu același nume a cărui imagine este cea de mai jos.
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.
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.
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:
societățile bancare autorizate să efectueze schimburi valutare;
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;
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:
Obiectul unic de activitate, conform statutului și contractului de societate, trebuie să-l constituie schimbul valutar pentru persoanele fizice.
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.
Solicitantul trebuie să notifice numele și sediul băncii unde are deschis contul.
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.
Personalul angajat trebuie să prezinte certificatul de cazier juridic fără antecedente.
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);
Î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.
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:
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.
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ă
( 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.
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 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.
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.
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)
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"
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
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
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
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
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"
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)
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"
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
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
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)
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
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
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
!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
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
DoCmd.Close
rstdatefirma.Close
dbsexchange.Close
Exit_Iesire_Click:
Exit Sub
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
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: . Aplicatie Informatica Pentru Casele de Schimb (ID: 149001)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.