Upload
pejo051
View
33
Download
5
Embed Size (px)
DESCRIPTION
baze podataka
Citation preview
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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
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: 2.2 IZDAVANJE RACUNA
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