UNIVERSITATEA „LUCIAN BLAGA” SIBIU

Facultatea de Ştiinţe Economice

Master B08 – Expertiză contabilă şi audit

PROIECT LA DISCIPLINA

UTILIZAREA SISTEMELOR INFORMATICE ECONOMICE

Conducător ştiinţific:
Conf.dr. Marian Cristescu
Masterand anul I:
CINDULET ALEXANDRA-GEORGIANA

IUNIE 2019
SIBIU
 SISTEM INFORMAŢIONAL. SISTEM INFORMATIC

Conceptul de sistem informaţional

Sistemul informaţional reprezintă un ansamblu de proceduri cu privire la culegerea,
verificarea, transmiterea, stocarea şi prelucrarea datelor în scopul satisfacerii cerinţelor
informaţionale necesare managerilor sau altor categorii de utilizatori finali în procesul de
fundamentare şi elaborare a deciziilor.
Sistemul informaţional :
-sub aspect static presupune înregistrarea faptelor survenite în baza informaţională,
înregistrarea structurilor de date, a regulilor şi a restricţiilor în modelul datelor;
- sub aspect dinamic presupune procesarea informaţiilor (aducerea la zi a datelor
memorate) în baza de date şi schimbarea structurilor, regulilor şi restricţiilor de date.

Conceptul de sistem informatic

Sistemul informatic reprezintă un ansamblu de proceduri, metodologii şi tehnici de
culegere, validare, transmitere, stocare, prelucrare automată a datelor în scopul satisfacerii
cerinţelor informatice necesare factorilor de decizie sau altor categorii de utilizatori finali în
procesul de fundamentare şi elaborare a deciziilor.Din definiţie, se poate desprinde ideea că
sistemul informatic reprezintă partea automatizată a sistemului informaţional.
Prezenţa sistemului informatic în care sistemul informaţional imprimă acestuia din
urmă noi valenţe de ordin cantitativ şi calitativ, în sensul:
- sub aspect cantitativ oferă facilităţi sporite cu privire la prelucrarea unor volume mari
de date;
- sub aspect calitativ asigură sporirea calităţii informaţiei, sub aspectele sporirii vitezei
de răspuns a sistemului la cererile utilizatorilor ;
- reducerea costului informaţiei ;
- sporirea exactităţii (preciziei) şi realităţii informaţiei ;
- asigurarea oportunităţii situaţiilor de informare, raportare ;
- sporirea calităţii formelor de redare a rezultatelor finale.

Obiectivele sistemului informatic

Obiectivele sistemelor informatice sunt subordonate obiectivelor managerilor cu privire la
multitudinea activităţilor din cadrul societăţilor comerciale. Obiectivele sistemelor informatice pot
fi clasificate după mai multe criterii, astfel:
În funcţie de sfera de cuprindere a efectelor economice, acestea pot fi:
a) generale / principale
b) secundare
În funcţie de posibilitateacuantificăriiefecteloreconomice :
 Obiective cuantificabile au de ordin cantitativ
 Obiective necuantificabil sau de ordin calitativ
În funcţie de sistemul de referinţă :
a) Obiective referitoare la activitatile de baza - sistemul condus
b) Obiectivele referitoare la activităţile din cadrul sistemului informaţional.
 INTRODUCERE

Implementarea unui sistem informatic pentru comert cu material lemnos.

Obiectivul acestui proiect este de a concepe un sistem informatic pentru vanzarea
materialului lemnos.
Modelul ce urmează a fi implementat va trebui să permită înscrierea într-un nomenclator
furnizorii, gestiunea în care intră marfa recepționată și de asemenea clienții.
Astfel sistemul va urmări:
• Să evidențieze informații referitoare la valoarea cantitativă și prețurile de achiziție.
• Să permită stocarea produselor în gestiunea magazinului.
• Să permită verificarea în orice moment al stocului fizic și cel inițial, precum și evidența
vânzărilor.
• Să realizeze vânzarea efectivă către clienți.

PREZENTAREA GENERALĂ A SOCIETĂȚII DNY EXPLO SRL

S.C. DNY EXPLO SRL este o societate comercială constituită sub formă de societate cu
răspundere limitată, persoană juridică română care s-a înfiinţat conform Legii 31/1990 (Legea
Societăţilor române). Denumirea societăţii este DNY EXPLO SRL, înregistrată la Registrul
Comerţului din judeţul Brasov în anul 2013 (J08/403/2013) având codul unic de înregistrare RO
31356300. Sediul social al societăţii este în judeţul Brasov, localitatea Oltet, nr. 155.

MODELAREA CONCEPTUALĂ A DATELOR

In modelarea conceptula a datelor se opereaza cu urmatoarele enunturi si urmatorii
termeni:
Modelul – o forma de abstractizare a realitatii economice pe care o luam in studiu.
Principalele caracteristici ale modelului sunt:
- generalitatea
- utilitatea
- usurinta in procesul de implementare care determina in mod implicit gradul sau
nivelul de aplicabilitate.
Orice model teoretic al unui viitor Sistem Informatic Economic este destinat de facto
implementarii cu ajutorul tehnologiilor informatice disponibile in economia reala.
Entitatea – este un termen abstract prin intermediul caruia determinam un obiect al lumii
reale (realitatea economica modelata), care are o experienta proprie cu o identitate
proprie(care il face identificabil in raport cu celelalte obiecte de acelasi tip) si o multime de
caracteristici (proprietati) care ne permit descrierea specificului sau.
Tip de entitate – un concept generic care descrie multimea tuturor entitatilor ce prezinta
aceleasi caracteristici constructive.
Atributul – defineste o proprietate distincta, fiecare atribut prezinta un domeniu de valori
admise.
 1. Modelul Entitate - Asociere (EA)

Caracteristica modelului este generalitatea. Pentru a obţine un model conceptual al datelor se

apelează la modele intermediare care sunt folosite ca suport al unei metodologii de proiectare. Un
model conceptual este un ansamblu de concepte şi reguli de combinare a acestor concepte
permiţând reprezentarea realităţii circumscrise domeniului supus informatizării. Modelele utilizate
se numesc modele semantice şi au drept obiectiv ca prin conceptele oferite săpermită reprezentarea
lumii reale.Un model semantic este modelul EA.
Entitatea, concept de bază al modelului EA, este un obiect al realităţii modelate caracterizat
prin existenţă proprie cu o identitate proprie, in cazul modelarii noastre un exemplu de entitate este
client,facturi,detalii factură,produs,etc.

Tip entitate Atribute Realizari ale Realizari ale atributelor

atributelor ex.1 ex.2
CLIENTI Cod_client 0001 0002
Nume_client Barlinek Romania OS. Padurile Fagarasului
Cod_fiscal Ro 5444241 22225284
Sediul Onesti, b-dul Voila
Marasesti 57 C
Judet Bacau Brasov
E-mail barlinekromania@yaho ospadurilefagarasului@yah
o.com oo.com
Telefon

Tip entitate Atribute Realizari ale atributelor Realizari ale atributelor

ex.1 ex.2
Specii Cod_specie 1 2
Denumire_specie Lemn rotund Gorun Lemn foc Gorun
Cantitate 300 100
U_M mc mc
Pret_produs 800 lei 70 lei

Structura entitatilor se prezinta astfel:

Clienti
Cod_client Facturi Furnizori
Nume_client Nr_factura Cod_furnizor
CNP Serie_factura nume_furnizor
Sediul Data_facturii CIF
Judet Cod_client Localitate
E-mail Cod_gestiune Judet
Telefon E-mail
Telefon
Produse Intrari Iesiri
Cod_produs Cod_factura Cod_factura
denumire_produs Numar_factura Numar_factura
Cod_gestiune cod_furnizor Cod_client
Cantitate Data_factura Data_factura
Unitate_masura Cod_produs Cod_produs
Pret_unitar Denumire_produs denumire_produs
Cod_Gestiune cod_Gestiune
Tva Tva
Unitate_masura Unitate_masura
Cantitate Cantitate
Pret_unitar Pret_unitar
Valoare Valoare
Valoare_tva Valoare_tva
Valoare_totala Valoare_totala

Receptie
Nr_receptie
Data_receptie
Cod_gestiune
Cantitate
Cod_produs

Bon_fiscal gestiune Chitanta

Numar_bon Cod_gestiune Nr_chitanta
Cod_client denumire_gestiune Serie_chitanta
Data_bon Data_Chitanta
Cod_produs Cod_client
denumire_produs Nume_client
Unitate_masura Numar_factura
Cantitate Suma_incasata
Pret_unitar
Valoare
Valoare_tva
Valoare_total

Atributul defineste o proprietate distincta a unei entitati, fiecare atribut prezinta o multime de
valori admise.
Analizând tipurile de entităţi de mai sus putem evidenţia mai multe tipuri de atribute:

a) După complexitate atributele sunt:

 Atribute elementare: Cod client, Nume client, CNP (CLIENTI);

Numar factura, Data facturii, Cod client (FACTURI);
Numar chitanta, Nume client, Suma incasata(CHITANTE)
 Atribute decompozabile:Sediul (CLIENTI);

b) După realizările pe care le pot prezenta atributele pot fi:

 Atribute obligatorii: Cod client, Nume client, CNP (CLIENTI);

Numar factura, Data factura, Cod client (FACTURI);
Cod produs, Pret produs (material lemnos);
, Cod gestiune, Cantitatea (RECEPTIE)
Numar chitanta, Data chitanta, Nume client, Suma incasata
(CHITANTA)
 Atribute opţionale: Domeniu;
 Atribute monovaloare: Cod client, Cod fiscal(CLIENTI);
Cod produs, Denumire carte, UM (PRODUSE)
Cod gestiune, Nume gestiune (GESTIUNI);

 Atribute multivaloare: E-mail, Telefon (CLIENTI).

 Clasificarea atributelor:

Nr. Dupa Dupa Dupa

Atribut Entitate
Crt. complexitate obligativitate realizari
1. Cod_client Elementar Obligatoriu Monovaloare
2. Nume_client Elementar Obligatoriu Monovaloare
3. CIF Elementar Obligatoriu Monovaloare
4. Sediul Decompozabil Obligatoriu Monovaloare CLIENTI
5. Judet Elementar Obligatoriu Monovaloare
6. Nr_factura Elementar Obligatotiu Monovaloare
8. Serie_factura Elementar Obligatoriu Monovaloare
9. Data_facturii Elementar Obligatoriu Monovaloare FACTURI
10. Cod_client Elementar Obligatoriu Monovaloare
11. Cod_gestiune Elementar Obligatoriu Monovaloare
12. Cod_produs Elementar Obligatoriu Monovaloare
13. Denumire_produs Elementar Obligatoriu Monovaloare
14. Domeniu Elementar Obligatoriu Monovaloare MATERIAL
15. U_m Elementar Obligatoriu Monovaloare LENOS
16. Pret_unitar Elementar Obligatoriu Monovaloare
17. Cod_gestiune Elementar Obligatoriu Monovaloare
GESTIUNE
18. Denumire_gestiune Elementar Obligatoriu Monovaloare
19 Nr_receptie Elementar Obligatoriu Monovaloare
20 Data_receptie Elementar Obligatoriu Monovaloare
21. Cod_produs Elementar Obligatoriu Monovaloare RECEPTIE
22. Cod_gestiune Elementar Obligatoriu Monovaloare
23. Cantitate Elementar Obligatoriu Monovaloare
 24. Nr_chitanta Elementar Obligatoriu Monovaloare
25. Serie_chitanta Elementar Obligatoriu Monovaloare
27. Data_Chitanta Elementar Obligatoriu Monovaloare CHITANTA
28. Nume_client Elementar Obligatoriu Monovaloare
29. Suma_incasata Elementar Obligatoriu Monovaloare

2.Asocieri – Cardinalitati

Asocierea reprezinta legatura dintre doua sau mai multe entitati, legatura generata de
dependentele functionale dintre date.
 Asocierea Clienti – produs {material lemnos}

Cardinalităț
Clienți i Produs
Cod_client
Cod_produs
Nume_client
0, n denumire_produs
CNP 1, n Cod_gestiune
Sediul CUMPARA
Cantitate
Judet
Unitate_masura
E-mail
Pret_unitar
Telefon

Roluri

cumparator cumpara
t

 1,n –un client poate cumpara cel puțin un produs sau n produse;
 0,n–un produs poate fi cumparat de niciun client sau de n clienti.

 Asocierea Produs – Receptie

Cardinaliati
Produs Recepție
Cod_produs
Nr_recepție
denumire_produs
Cod_gestiune Data_recepției
Cantitate Cod_gestiune
Unitate_masura
 1, n 1, n
INCLUS

Roluri

Sunt incluse în recepție se includ produse

 1,n– un produs poate să fie inclus într-o receptie sau n receptii;

 1,n – o receptie poate include un produs sau mai multe produse.

 Asocierea Recepție – Gestiuni

Cardinalitati
Recepție Gestiune
Nr_recepție Cod_gestiune
Carti
Data_recepției
denumire_gestiune
Cod_carte
1, 1 1, n
Cod_gestiune Denumire_carte
repartizeaza
Cantitate Domeniu Um
Cod_produs Preț_carte Stoc_inițial

Roluri

Repartizata Se repartizeaza

 1,1– o recepție poate fi repartizată pe cel puțin și cel mult o gestiune;

 1,n – pe o gestiune se poate repartiza o receptie sau mai multe receptii.

 Asocierea Clienți – Chitanțe

Cardinalitati

Clienți Chitante
Nr_chitanta
Cod_client
Serie_chitanta
Nume_client
  1,n - un client poate primi cel puțin o chitanță sau n chitante;
 1, 1 – o chitanță este primită de cel puțin și cel mult un client.

 Asociere Clienti-facturi- chitante

Facturi
Cod_factura
Clienți Numar_factura
Cod_client 1,1 cod_client
Nume_client Data_factura
CNP Achita Cod_produs
Sediul Denumire_produs
Judet Cod_Gestiune
E-mail Tva
Telefo Unitate_masura
n Se elibereaza Cantitate
1,1 Pret_unitar
Valoare
Valoare_tva
Valoare_totala
1,1 Chitante
Nr_chitanta
Serie_chitanta
Data_Chitanta
primeste Cod_client
Nume_client
Numar_factura
Suma_incasata
  Asociere Furnizor- Produs

Cardinalitati

Furnizor Produs
Cod_furnizor Cod_produs
nume_furnizor denumire_produs
CIF 0,n 1,n Cod_gestiune
Localitate vinde Cantitate
Judet Unitate_masura
E-mail Pret_unitar
Telefon Roluri

vinde Este vandut

 0,1 - Un furnizor poate vinde niciunul sau mai multe produse;

 1,n – un produs poate fi vandut de unul sau mai multi furnizori.
 Asociere Furnizor- Factura

Furnizor Factura
Cod_furnizor Cardinalitati Cod_factura
nume_furnizor Numar_factura
CIF cod_furnizor
Localitate Data_factura
0, n 1,1
Judet Cod_produs
E-mail emite Denumire_produs
Telefon Cod_Gestiune
Tva
Unitate_masura
Cantitate
Pret_unitar
Valoare
  0, n – un furnizor poate emite nicuna sau mai multe facturi;
 1,1 – o factura poate fi emisa de un singur furnizor.

Modelul Entitate –Asociere

Intrare in gestiune

Furnizor Factura Recepție

Cod_furnizo Cod_factura
Numar_factura Nr_recepție
rnume_furnizor
CIF cod_furnizor Data_recepției
Localitate emite Data_factura Cod_gestiune
Judet Cod_produs Se
Denumire_pro Cantitate
E-mail receptioneza
Telefon dus Cod_produs
emitent Cod_Gestiune
Tva
Unitate_masura
Cantitate
Pret_unitar emisa cuprinde
Valoare
Valoare_tva
Valoare_totala

Produs
Cod_produs
denumire_produs
Gestiune
Cod_gestiune
Cod_gestiune Cantitate
denumire_gestiun intra Unitate_masura
e Pret_unitar
Sunt stocate
Se stocheaza
 Modelul Entitate –Asociere
Iesire din gestiune

Gestiune Produs Facturi

Cod_gestiune Cod_produs
denumire_prod Cod_factura
denumire_gestiun Numar_factura
iese us cuprind
e Cod_gestiune cod_client
Cantitate e Data_factura
Unitate_masur Cod_produs
a Denumire_produs
Cod_Gestiune
Pret_unit
Tva
ar Unitate_masura
Sunt cuprinse Cantitate
Pret_unitar
Ies din gestiune Valoare
Valoare_tva
Valoare_totala

Se emite

Chitante
Nr_chitanta
Serie_chitanta emite
Data_Chitanta
Cod_client
Nume_client
Numar_factura Clienți
Suma_incasata Cod_client
Nume_client
achita CNP
Sediul Judet
E-mail
Telefon
 sau

MODELUL (EA)

1. Restricții
Restricțiile de integritate definesc cerințele pe care datele trebuie să le respecte pentru
a fi corecte și coerente în raport cu realitatea pe care o reflectă.

Restrictii de domeniu: statica, dinamica

ATRIBUTUL RESTRICȚIA TIPUL DE RESTRICȚIE

Data_facturii Data facturii>=data comenzii Dinamică

Să fie exprimată în bucăți, kilograme

UM Statică
sau litri

Cod_gestiune {11,22,33,44} Statică

Data_chitantei Data chitantei>=data facturii Dinamică

Implica proprietatea Validation Rule din accesss.

Restricţiile de integritate de asocieri vizează asocierea însăşi împreună cu entităţile

participante.Altfel spus, restricţiile se referă la mulţimea tuturor rolurilor aparţinând asocierii.

Restricţia de incluziune de asocieri

platitor Facturi
Clienți
Cod_factura
Cod_client
Numar_factura
Nume_client 1,n 1,1 cod_client
CNP Achita Data_factura
Sediul Judet numerar Cod_produs
E-mail
Denumire_produs
Telefon
Cod_Gestiune
Tva
primitor
Unitate_masura
Cantitate
Pret_unitar
Valoare
primesc I Valoare_tva
 1,1

sau

Tipul de asociere „primesc” este determinat de existenţa tipului de asociere „achită”

(clientul nu poate primi chitanta daca nu achită factura).
Asocierea”primesc” include asocierea”achita”.

Restricţia de excluziune de asocieri

Facturi
Clienți
Cod_client Cod_factura
Nume_client Numar_factura
CNP cod_client Data_factura
Achita
Sediul Judet Cod_produs
E-mail card Denumire_produs
Telefo Cod_Gestiune
Tva
n Unitate_masura
Cantitate
Pret_unitar
Valoare
Valoare_tva
Valoare_totala
primesc #

Chitante Bon fiscal

Nr_chitanta
Numar_bon
Serie_chitanta
Cod_client
Data_Chitanta
Data_bon
Cod_client
Cod_produs
Nume_client
denumire_produs
Numar_factura
Unitate_masura
Suma_incasata
 sau

Tipul de asociere „primesc” este determinat de existenţa tipului de asociere „achită”

(clientul nu primeste chitanta daca achită factura cu cardul).Rezulta ca intre “achita” si “primesc”
este o excluziune de asocieri.

Restricțiile de domeniu reprezintă condiții care privesc ansamblul de valori admise

pentru un atribut în cadrul tipului sau domeniului său. Restricțiile pot viza realizările unui/unor
atribute aparținând unei aceleași entități sau asocieri, caz în care se numesc restricții
intraentitate, sau a unui/unor atribute aparținând unor entități și/sau asocieri diferite, caz în
care se numesc restricții interentități. Restricțiile de domeniu se pot exprima cu privire la:
 Conținutul unui singur atribut al unei entități sau
asocieri: Exemplu: UM = {ˮBUCˮ, ˮKGˮ, ˮMCˮ}
Cantitate ≥ 5
 Corelațiile ce trebuie să se respecte între valorile mai multor atribute sau asocieri aparținând
aceleași entități sau asocieri:
Exemplu: Cod_produs = ˮ1” atunci UM = ˮmcˮ
Cod_client =ˮ0001” atunci Nume_client = ˮS.C. Barlinek Romania SAˮ
 Corelații realizate pe baza unor valori obținute prin operații de sintetizare (însumare, calculul
mediei, valorii minime / maxime) a unui ansamblu de entități:
Exemplu: Valoarea produselor existente pe stoc.
Valoare = Preț_produs * Stoc_inițial

Restricții structurale
Fiecare entitate va trebui să poată fi identificată fără echivoc. Acest lucru impune ca
identificatorul entității să ia valori unice diferite de NULL (NULL înseamnă că nu s-a realizat
nici o valoare, deci valoarea NULL este diferită de zero sau spațiu).
ENTITATE IDENTIFICATOR
Clienți Cod_client
Carti Cod_carte
Gestiune Cod_gestiune
Facturi Nr_factură
Recepție Nr_recepție
Chitanțe Nr_chitanță
 Restricțiile de integritate de roluri exprimă legătura stabilită între entităţi
diferite,fiecare dintre acestea jucând un anumit rol.
Restricția de incluziune de roluri
- statuează faptul că, dacă o entitate E1 care joacă rolul r1 în asocierea A1 va trebui să
joace şi rolul r2 în asocierea A2. Rezultă că rolul r1 include (implică prin incluziune) rolul r2 .
Exemplu: Clienţii obtin produsele dacă au facturile achitate. Între rolul
„obtinute” şi rolul „achitate” se manifestă o restricţie de incluziune de roluri.

Clienți Produs
Cod_produs
Cod_client
denumire_produs
Nume_client
Cod_gestiune
CNP 1, n 1, n
Cantitate
Sediul Judet obtine Unitate_masura
E-mail
Pret_unitar
Telefon

1,n
1, n
obtinute

achita

1,1

Facturi
Cod_factura I
Numar_factura
cod_client
1,n achitate
Data_factura
Cod_produs
Denumire_produs
Cod_Gestiune
Tva
Unitate_masura
Cantitate
Pret_unitar
Valoare
Valoare_tva
Valoare_totala
Rolul „obtinute” il include pe rolul”achitate”

Restricția de excluziune de roluri

- specifică faptul că un rol r1 jucat de o entitate E1 în asocierea A1 exclude existența

rolului r2 jucat în asocierea A2.
Exemplu: Clienții cumpara produse, iar produsele sunt cumparate de clienti, însă clienții nu
vand produse.

cumparator cumparat
Produs
Clienți Cod_produs
Cod_client denumire_produs
Nume_client Cod_gestiune
CNP Cantitate
Sediul Judet 1,n 0, n Unitate_masura
E-mail cumpara Pret_unitar
Telefon

vand

MODELAREA CONCEPTUALA A PRELUCRARILOR (MCP)

Pasul 1: Definirea domeniului investigat

Problema supusă analizei acoperă în principal următoarele activităţi:

Achizitia marfii de la furnizor
Receptie marfa
 Achitarea facturii furnizorului
Vindera marfii
Se verifica stocul disponibil
Emitere factură
Emitere chitanta/ bon fiscal
Activitatea de încasare a contravalorii produselor livrate

Pasul 2: Evenimente identificate

E1: primire marfa de la furnizor

E2: receptionare marfa
E3: furnizor existent
E4: furnizor neexistent
E5: furnizor inregistrat
E6:preluare cod pentru produse existente
E7:creare coduri pentru produse noi
E8: marfa intrata in gestiune
E9: vanzare efectuata
E10: Clientul există în baza de date
E11: Client existent
E13: Înregistrarea noului client
E14: Stoc în gestiune produse este mai mare sau egal cu cantitatea cerută
E15: Actualizarea stocului de produse
E16: Emiterea facturii
E17: Livrarea produselor
E18: Factura achitată
E19: Chitanţa eliberată
E20: Stingere creante

Pasul 3 : Întocmirea tabloului evenimente-rezultate

Nr. crt. EVENIMENTE ACŢIUNI EVENIMENTE

DECLANŞATOARE EXECUTATE REZULTAT
1. Primire marfa furnizor Receptionare marfa Verificare marfa dupa factura

2. Furnizor neexistent Inregistrare furnizor Furnizor nou inregistrat

3. Preluare cod pentru Preluare cod Cod existent/ neexistent

produse existente
4. Creare cod pentru Creare cod produs Generare cod nou
produse noi
5. Intrare marfa in gestiune Verificare stoc Vanzare marfa
 6. Client neexistent Inregistrare client Client nou inregistrat

7. Cantitate marfă Se actualizeaza stocul de Stoc de produse actualizat

produse, se scad
cantităţile de mărfuri
pregătite
8. Factura Emitere factura Factură emisă
9. Expediere Trimitere cantitate de Marfă expediată
marfă cu factura
110. Achitare Se achită contravaloarea Factura achitată
mărfurilor
11. Factura achitată Imprimare chitanţă Chitanţă eliberată
12. Chitanta Se inregistreaza chitanta Stingerea creantelor

Pasul 4: Identificarea operaţiilor

OP1 = Primire marfa

OP2 = Verificare existenţă furnizor
OP3 = Înregistrare furnizor nou
OP4 = Receptie marfa
OP5 = Verificare stoc de marfă
OP6= Completare stoc
OP7= Vanzare marfa
OP8 = verificare existenta client
OP9 =Inregistrare client nou
OP10 = Actualizare stoc
OP11 = Eliberare factură
OP12 = Expediere cantitate cerută de marfă
OP13 = Achitare factură
OP14 = Eliberare chitanţă

Pasul 5 : Identificarea sincronizărilor

Sincronizările ce apar au fost deja marcate în cadrul pasului 3, deoarece acestea

reprezintă cazurile unde în cadrul coloanei evenimentelor declanşatoare apar două sau mai
multe evenimente legate prin operatorul logic “sau”.

Pasul 6 : Identificarea regulilor de emisie

OPERAŢIE REGULI DE EMISIE
Operaţia 2 R2,1 – Clientul există în baza de date
Operaţia 5 R5,1 – Cantitate curentă ≥ Cantitate iniţială - Cantitate solicitată

Pasul 7 : Elaborarea modelului conceptual al prelucrărilor

După cum s-a specificat anterior, modelul conceptual al prelucrărilor va fi divizat
 ţinându-se cont de principalele procese care apar, şi anume:
• Achizitionare marfa
• Achitare factura furnizor
• Vanzare marfa
• Achitare factură client

MODELAREA LOGICĂ A DATELOR

Modelul logic al datelor este o reprezentare a modelului conceptual al datelor în

funcţie de posibilităţile oferite de tehnica de calcul a momentului.

EXEMPLU

Evidenta clientilor

Emitere facturi
Evidenta furnizorilor
Evidenta facturilor de intrare
Evidenta produselor

Interogare

Raport
Relatii intre tabelele bazei de date
 Informațiile prezentate anterior sunt redate în Microsoft Access.
În continuare se va prezenta situația entității D.N.Y EXPLO SRL cu ajutorul sistemului informatic SAGA
C.

Evidenta furnizorilor

Intrari furnizori
Evidenta client

Facturi client

Registru jurnal
Registru de casa