Intre tabela PartnerCompany si tabela Account exista o relație de many-to-one, astfel un

utilizator poate avea mai multe companii. De asemenea intre tabela Partner si tabela
PartnerCompany exista la rândul ei o relație many-to-one, deoarece o companie partenera poate
avea mai mulți furnizori (contacte). După cum se poate observa si intre compania Partner si
Account exista o relație many-to-one, acest lucru permite utilizatorului sa aibă o serie de
furnizori care sa nu fie alocați la nicio companie. In momentul in care un angajat invita într-o
licitație 3 contacte, daca acestea nu se regăsesc la nicio companie partenera, atunci aceștia sunt
adăugați in baza de date ca si contacte independente ale angajatului, putând fi mai târziu asignați
la diferite companii, daca este necesar. In momentul creării unei companii noi, angajatul are o
lista de contacte neasignate din care poate alege si le poate aloca la compania nou creata.
Pentru fiecare companie se poate atașa oricâte documente se doresc. Aceste documente
pot reprezenta garanții, aprobări sau diferite acte de care o sa avem nevoie pe viitor, astfel
oferindu-i utilizatorului o mai ușoară gestionare de documente nefiind nevoie sa caute după
aceste acte intr-un depozit de arhivare.

In cazul Companiei se poate salva in baza de date : numele acesteia, adresa, o mica
descriere care sa ne ajute pe viitor, numărul de telefon si faxul, o adresa de email si website-ul
acesteia. Iar in cazul furnizorilor din cadrul unei companii, se salvează numele, adresa de email,
poziția pe care o ocupa in companie, numărul de telefon, limba acestuia si o mica descriere
ajutătoare.
In figura 6 este prezentata structura bazei de date pentru crearea unei cereri de achiziție.
Tabelul Request este tabelul care stochează toate informațiile utile. Atât pentru cererile de oferta
cat si pentru licitațiile inverse se va folosit același tabel, diferența dintre acestea fiind făcută de
câmpul de tip bool IsAuction din tabelul Request, in cazul in care cererea este o licitație inversa,
acest câmp va fi True, in caz contrar acesta va fi False.
In momentul in care este creata o cerere de oferta, se stochează in tabelul Request id-ul
angajatului care a pornit cererea si id-ul companiei din care face parte angajatul. Apoi se
salvează numele cererii, o descriere cat mai cuprinzătoare care sa ii ajute pe furnizori sa înțeleagă
cererea si data la care cererea se închide si pana la care furnizorii pot oferi cotații de preț. Tot aici
este salvata si moneda in care se face cererea, inițial aceasta fiind populata cu moneda pe care
angajatul o are definita pe setările contului sau. In aceeași tabela se va salva si limba folosita
atunci când se vor trimite email-urile de invitație către furnizori.
Pentru cererea de oferta exista 3 tabele aflate in relație many-to-one cu tabelul principal:
 RequestItem – reprezintă tabelul in care sunt salvate produsele pentru care este
creata cererea de oferta. In acest tabel sunt definite numele produsului, cantitatea
 dorita, o mica descriere, unitatea de măsura si poziția lui in lista de produse cerute
( in funcție de importanta ).
 RequestDocument – este tabelul in care se va memora o lista de documente
atașate cererii, documente folositoare pentru furnizori. In acest tabel se salvează
numele documentului si documentul in format electronic.
 RequestQuestion – este tabelul in care sunt stocate întrebările pe care angajatul i-
le adresează furnizorului. Aici se salvează numele întrebării, o descriere pentru
fiecare, faptul daca este obligatorie, daca furnizorul poate sa atașeze documente la
răspunsul întrebării si numărul de ordine al întrebării in funcție de importanta ei.
Aceste întrebări pot fi de 3 tipuri :
1. Întrebare de tip - text – este o întrebare la care furnizorul trebuie sa
scrie răspunsul, neputând sa îl aleagă dintr-o lista predefinita.
2. Întrebare de tip - o singura varianta – este o întrebare la care furnizorul
trebuie sa aleagă o singura varianta dintr-o lista de variante date de
utilizator.
3. Întrebare de tip – mai multe variante – la care furnizorul poate sa
aleagă ca răspuns 1 sau mai multe variante dintr-o lista data de
utilizator.

Cererea de oferta poate avea 5 statusuri distincte:

 Ciorna – este statusul in care cererea de oferta se afla inițial, când utilizatorul o
inițiază, completează câteva date, invita câțiva furnizori dar nu o trimite către
aceștia. In acest status se pot efectua oricând modificări fără ca nimic sa fie
afectat. Furnizorii nu primesc nicio notificare si nu sunt alertați in niciun fel ca
aceasta cerere a fost inițiata.
 Activ – este statusul in care cererea de oferta intra imediat după ce utilizatorul o
trimite oficial către toți furnizorii. In acest stadiu cererea este completata total,
sunt adăugate toate produsele si întrebările si toate câmpurile sunt valide.
Furnizorii primesc un email prin care sunt invitați sa participe la aceasta. In acest
moment se mai poate modifica doar data de finalizare a cererii, fiecare furnizor
fiind notificat de aceasta modificare. Exista însă si un caz special prin care se
poate modifica cererea, însă vom vorbi separat despre el.
 Terminat – după ce expira timpul alocat cererii, aceasta intra automat in acest
status, asta însemnând ca cererea s-a încheiat, niciun furnizor nu mai poate
oferta nimic iar utilizatorul nu mai poate modifica nimic la ea. Tot ce acesta mai
poate sa facă este sa selecteze un câștigător.
  Anulat – daca după ce a lansat cererea utilizatorul remarca ca a greșit ceva sau se
răzgândește in legătura cu aceasta, el poate sa o anuleze. Atunci cererea va fi
anulata, acesta neputând sa o pornească iar decât prin a o clona si a începe alta.
Furnizorii vor fi anunțați ca cererea s-a anulat iar toate răspunsurile lor nu vor fi
luate in considerare.
 Câștigata – in momentul in care o cerere se afla in statusul „Terminat” ,
utilizatorul are posibilitatea de a selecta un furnizor ( de obicei pe cel care a
oferit cel mai bun răspuns ) si sa îl aleagă câștigător. Daca utilizatorul marchează
un câștigător, cererea va intra automat in statusul „Câștigata” si furnizorul ales
va primi un mesaj de felicitare.

După cum se poate observa si in schema bazei de date pentru crearea unei cereri, este
prezenta si tabela RequestCopy. Aceasta tabela este folosita pentru cazul special in care o cerere
se afla in statusul „Activa” si utilizatorul remarca o greșeală pe care dorește sa o repare fără sa
anuleze întreaga cerere. In acest caz acesta poate sa intre in modul de editare a cererii, când s-a
intrat in acest mod se creează automat o copie a cererii inițiale, pe care acesta poate sa efectueze
orice modificare dorește si apoi sa o publice. Rolul acestei copii este de a ne asigura ca
utilizatorul face niște modificări permise de sistem iar schimbările nu vor aduce greșeli
adiționale cererii inițiale. Aceasta copie este utila in cazul in care utilizatorul face modificări pe
cererea principala si apoi se răzgândește si dorește sa renunțe la ele. Copia cererii este identica cu
cererea de oferta, nefiind nimic schimbat la ea, aceasta poate sa fie privita ca o clonare de cerere
fără a fi nevoie sa anulezi nimic.

După ce copia este salvata si toate datele modificate trec in cererea inițiala se va trimite
un email de informare către toți furnizorii invitați, informându-i pe aceștia de modificările făcute.
Toate răspunsurile primite de la furnizori pana in acest moment vor fi trecute înapoi in statusul
de „Ciorna” si aceștia vor trebui sa le retrimită in conformitate cu noile modificări aduse.