Seminar Dijagrami i Baze Podataka

SVEUČILIŠTE U RIJECI

EKONOMSKI FAKULTET U RIJECI

RIJEKA

IS AUTO KUĆE

SEMINARSKI RAD

Student: Damir Kvasić

Kolegij: Oraganizacija i analiza podataka

Mentor: Prof. dr. sc. Slavomir Vukmirović

Rijeka, Studeni, 2011.

Sadržaj Sadržaj ........................................................................................................................................ 2

1. Uvod ....................................................................................................................................... 3

2. Zahtjevi na IS ......................................................................................................................... 4

2.1 Funkcionalna raščlamba............................................................................................... 5

2.2 DTP .............................................................................................................................. 6

Dijagram konteksta: ....................................................................................................... 6

Dijagram toka podataka ................................................................................................. 8

2.3 Dokumenti informacijskoga sustava: ........................................................................... 8

Primjer računa .............................................................................................................. 10

Prijava kvara................................................................................................................. 11

Servisna primka............................................................................................................ 12

Primjer potvrde o uplati................................................................................................ 13

3. Dokumentacija modela podataka ......................................................................................... 14

3.1 Lista entiteta ............................................................................................................... 14

3.2 Model Entiteti-Veze ................................................................................................... 15

a) Prodaja...................................................................................................................... 15

b) Servis ...................................................................................................................... 16

4. Relacijska shema .................................................................................................................. 17

a) Prodaja...................................................................................................................... 17

b) Servis........................................................................................................................ 17

5. Relacijski model ................................................................................................................... 18

a) Servis........................................................................................................................ 18

b) Prodaja ..................................................................................................................... 19

6. Zaključak .............................................................................................................................. 20

7. Literatura .............................................................................................................................. 21

1. Uvod

Za ovaj projekt sam se odlučio iz razloga to je ovakvo okruženje vise ili manje svima poznato,

a informacijama koje smo dobili iz jedne određene auto kuće mislimo da bi mogli, svojim

radom, podosta ubrzati i pojednostaviti IS. Isto tako ta kuca već ima svoj IS koji sa svoji

procesima funkcionira dobro te bi naše rješenje trebalo na bolji način sa manje redundantnih

podataka i tokova podržati te procese, a izbaciti nepotrebne. Samim time dobivamo na brzini

pristupa podatcima, boljoj kontroli i na kraju učinkovitosti sustava.

Odmah na početku treba napomenuti da u izradi ovog rada, naglasak je stavljen na osnovne

procese funkcioniranja Auto kuće, pošto bi za dublju detaljizaciju bio potreban iscrpan

intervju, te mnoštvo podataka koji nam nisu bili dostupni.

Auto kuća Opel, je poduzeće specijalizirano za prodaju novih vozila ali u ponudi ima i

rabljena. U sklopu te auto kuće djeluje i službeni servis koji popravlja vozila kupljena u tom

salonu ali i drugome ovlaštenom salonu. To su dva odvojena sustava koji mogu djelovati

jedno bez drugoga ali određenim djelom imaju zajedničke financije i računovodstvo pa tako i

djelom zajednički informacijski sustav. Računovodstvo ovoga poduzeća sada dobiva račune

izdane u prodaji i servisu na papiru, prepisuje ih u njihov računovodstveni software i tada

proknjižuju dalje što treba. Trenutno nema načina da se vidi stanje na skladištu jer nema real

time obrade tih podataka. Uvid u stanje je moguće samo kada sa pozbrajaju primke i računi te

oduzmu stavke. Čak i tada to nije trenutno stanje jer informacije o prodaji tog dana još nisu

došle do knjigovodstva. Dodatni je problem taj što je svaka kasa odvojena sama za sebe i ima

svoju odvojenu bazu te je kod dodavanja, koje nije često no i dalje se dešava par puta

godišnje, potrebno ručno uskladiti baze što može dovesti do problema i razlika bazama.

Nepotrebno je spomenuti redundantnost i gubljenje vremena.

Kod servisa prvi je problem uočen pri izdavanju servisnih primki koje su se izdavale ručno na

papiru bez unosa i evidencije u digitalnome obliku. Kasnije je bilo vrlo teško tražiti primke po

knjigama i arhivama.

2. Zahtjevi na IS

S obzirom na gore navedeno uočeno je niz nelogičnosti i nepravilnosti koje bi mi trebali

ispraviti ili barem donekle ubrzati. Neki procesi su također potpuno nepotrebni pa ćemo njih

izbaciti automatizacijom i centralizacijom sustava. Ovo su trenutno dakle nedostaci koje smo

uočili do sada:

1. Nepovezanost baza – aplikacija

2. Izrada računa te kasnije ponovno utipkavanje u računalo

3. Trenutno stanje na skladištu je nemoguće odrediti

4. Nepovezanost prodaje sa računovodstvom

5. Nepovezanost servisa sa računovodstvom

6. Servisne primke samo na papiru

Uz nedostatke treba voditi računa još nekim stvarima na koje smo bili upozoreni. Ne može

serviser izdati račun u prodaji a isto tako ne može prodavač raditi račun u servisu. Na

aplikaciji radi više korisnika od jednom i treba se znati tko je izdao račun u slučaju

reklamacija. Račun se i dalje izdaje na licu mjesta u jednom primjerku za klijenta. U servisu

postoje usluge i dijelovi. Usluge nemaju stanje na skladištu dok dijelovi imaju.

Rješenje je zamišljeno tako da se u prvome slučaju napravi centralna baza koja će se koristiti i

u prodaji i u servisu. Iz nje će računovodstvo moći vaditi račune koji su taj tren nastali što

automatski eliminira potrebu za ponovnim unošenjem računa koji je već u sustavu. Ujedno u

toku podataka eliminiramo nepotreban tok od prodaje prema računovodstvu. Računovodstvo

će trenutnim uvidom u stanje izdanih računa moći u bilo kojem trenu znati točno stanje na

skladištu na način da vidi ukupan broj dobavljenih i izdanih. Kasnije je zamišljeno da se

automatski oduzima i zbraja na artiklima pri prodaji ili primci robe no to je u ovome trenu

bilo nemoguće zbog nepoznavanja sustava računovodstva i njegovo funkcioniranje.

Iz gore postavljenog ciljeve na IS smo definirali:

1. Centralna baza

2. Računovodstvo, servis i prodaja spojeni na isti DB

3. Pri spajanju na bazu provjeriti username i password

4. Odvojiti Prodavače od Servisera

5. Servisne primke pohranjene u računalu

2.1 Funkcionalna raščlamba

Prije same izrade DTP dekomponirali smo sustav na pri podsustava sa svojim glavnim

dijelovima. 1. Prodaja, 2. Servis. 3. Komercijala. Prodaja se bavi, sa gledišta IS –a,

izdavanjem računa, servis prima na servis robu i izdaje za to račun, dok se komercijala bavi

financijama.

2.2 DTP

DTP se sastoji od sljedećih dijelova:

DTP: Dijagram konteksta

DTP: 0. IS Auto kuće

DTP: 1. PRODAJA

DTP: 2. SERVIS

DTP 3. KOMERCIJALA

DTP: 1.1 IZDAVANJE RACUNA

DTP: 2.1 ZAPRIMANJE ROBE

DTP: 3.1 KNJIZENJE

Dijagram konteksta:

Kod dolaska klijenta u auto kuću on donosi potvrdu o uplati za koju donosi potvrdu o

plaćanju. U vidu uplatnice ili bilo kojeg drugog papira koje potvrđuje prijenos novca na račun

firme. Za to dobije račun s kojim može kasnije dobiti kupljeno. Kod servisa, on prijavljuje

kvar za sto mu onda servise izdaje primku. Nakon sto je rad izvršen on dobije račun sa

specificiranim radovima i dijelovima koju su zamijenjeni.

Dijagram toka se nadovezuje na dijagram konteksta tako da se uvode tri banke. Banka računa,

računa servisa i primki servisa. Klijent pri dolasku u servis opisuje kvar na temelju kojega

serviser napravi primku sa opisom i nju predaje klijentu. Nakon sto je kvar gotov klijent

dobije račun za servis. U slučaju da klijent ima reklamaciju ili je vidio moguću grešku dati ce

račun na reklamaciju i on ce ili dobiti novi račun ili ce mu se objasniti sto je točno na tom

računu.

Kod prodaje priča je isto vrlo slična nakon što donese potvrdu o uplati ili prijenosu sredstava

on dobije račun s kojim može preuzeti robu koju je platio. U slučaju da je račun krivo

napravljen može reklamirati i dobiti novi. Banke služe tome da se računovodstvo može doći

direktno do informacija a isto tako u slučaju da treba ponovno napraviti reklamirani račun.

U slučaju da postoji određena reklamacija, klijent će to prenijeti prodaji koja će provjeriti

račun iz banke i izdati novi ako to potrebno.

Dijagram toka podataka

2.3 Dokumenti informacijskoga sustava:

1. Prodajni račun

2. Prijava kvara

3. Servisna primka

4. Potvrda o uplati

Prodajni račun se dobije pri kupnji u odjelu prodaje, sadrži naravno kupljenu robu, iznos,

informaciju o prodavatelju i kupcu, podatke o prodavaču. Račun je isprava prema kojoj

porezni obveznik obračunava isporučena dobra i obavljene usluge, bez obzira na to kako se ta

isprava naziva u poslovnomu prometu.

Račun sadrži ove podatke:

1. mjesto izdavanja, broj i nadnevak,

2. ime (naziv), adresu i matični. broj ili jedinstveni matični broj građana (porezni broj

poduzetnika), koji je isporučio dobra ili obavio usluge (prodavatelja),

3. ime (naziv), adresu i porezni broj poduzetnika kome su isporučena dobra ili obavljene

usluge (kupca),

4. količinu i uobičajeni trgovački naziv isporučenih dobara te vrstu i količinu obavljenih

usluga,

5. nadnevak isporuke dobara ili obavljenih usluga,

6. iznos naknade (cijene) isporučenih dobara ili obavljenih usluga,

7. iznos poreza,

8. zbrojni iznos naknade i poreza.

Prijava kvara služi da bi klijent opisao kvar pri prijemu auta. Na temelju tog opisa serviser

zaprima auto, radi servisnu primku koja kasnije služi kao potvrda da je auto zaprimljen

određenog datuma od određene osobe koje su tamo navedene.

Potvrda o uplati može biti bilo koji dokument koji dokazuje prijenos sredstava na račun firme.

Primjer računa:

Prijava kvara:

Servisna primka:

Primjer potvrde o uplati:

Ovo je ukratko sve o samome sustavu i kako on funkcionira. Dalje slijedi dokumentacija

entiteta i veza između njih te relacijski model.

3. Dokumentacija modela podataka

Temeljem zahtjeva na IS, opisa djelatnosti, skladišta podataka te dijagrama podataka možemo

napraviti sljedeći model podataka.

3.1 Lista entiteta

BR NAZIV OPIS

001 Klijenti Podatci o klijentima

002 Modeli Podatci o modelima

003 Prodavac Podatci o prodavačima

004 Rad Podatci u radu

005 Serviser Podatci o serviserima

006 Garancije Podatci o garancijama

007 Kvar Podatci o kvarovima

008 Nacin plac. Podatci o nacinima plac.

009 Dijelovi Podatci o dijelovima

010 Izved. Rad Podatci o izved radovima

011 Prom dijel Podatci o promijenjenim dijel

012 Popravak Podatci o popravku

013 Racun prodaje Podatci o prodaji

014 S. Primka Podatci o zaprimljenom autu

3.2 Model Entiteti-Veze

a) Prodaja

b) Servis

4. Relacijska shema

a) Prodaja

KLIJENTI (S_KLIJENTA, IME, PREZIME, ADRESA, TEL.V, GSM) PRODAVAC (S PRODAVACA, IME, PREZIME) MODELI (S MODELA, CIJENA) RAD (S RADA, OPIS, CIJENA_SATA_RADA) RACUN _PRODAJE (BROJ RACUNA, S_MODELA, S_PRODAVACA, S_KLIJENTA, NACIN PLACANJA, TRAJANJE_GAR, DATUM_KUPNJE)

b) Servis

SERVISER (S SERVISERA, IME, PREZIME) KLIJENTI (S_KLIJENTA, IME , PREZIME, ADRESA, TEL.V, GSM) GARANCIIJA (S_GAR, TIP) DIJELOVI (S DIJELA, NAZIV, MODEL, CIJENA) NACIN_PLACANJA (S_PLAC, OPIS_PLAC) KVAR (S KVARA, S_KLIJENTA, DAT. KVARA, OPIS_KVARA) IZVED. RAD. (BROJ_POPRAVKA, S RADA) PROM. DIJEL (SIF_DIJELA, BROJ_POPRAVKA) POPRAVAK (BR_POPRAVKA, S_KLIJENTA, S_GAR, S_PROM_DIJEL, S_IZV_RADA, S_SERVISERA, OPIS)

5. Relacijski model

a) Servis

b) Prodaja

6. Zaključak

Ovaj je IS rađen za potrebe Auto kuće s naglaskom na osnovne funkcije. Auto kuća

sama po sebi vrlo teško da će ikada preći broj od 30 -ak zaposlenika pa sam softver nije

preopsežan i kompliciran. Glavna namjena mu je da olakša evidenciju računa servisa i

prodaje, evidencija korisnika i sl. Ako se ovakva evidencije radi na klasičan „papirnati“ način,

kasnije vođenje i arhiviranje može biti iznimno mukotrpan posao. Ovako se sve odvija kroz

jednu aplikaciju na jednom centralnom mjestu pohrane.

Korisnik će moći u svakom trenutku dobiti trenutno stanje uplata, informacije o

korisnicima, stanju servisa i samoj ponudi auto kuće. Isto tako važno je da korisnik na

jednostavan način dođe do informacijama o moguće otvorenim – još ne naplaćenim

potraživanjima.

Dakle, svi procesi i tokovi podataka informacijskog sustava se ne moraju mijenjati, uz

značajno povećanje brzine unosa i pregleda podataka relevantnih za kuću, te uz neke dodatne

reporte koji prije nisu bili mogući.

7. Literatura 1. Thomas M. Connolly, Carolyn E. Begg: DATABASE SYSTEMS, Third Edition,

ADDISONWESLEY

2. http://office.microsoft.com/

3. http://en.wikipedia.org/wiki/Entity-relationship_model