Putni nalozi - evidencija troškova za vozila

[img]Pozdrav svima,
planiram da kreiram aplikaciju za evidenciju troškova za vozila iz voznog parka i odlučio sam se za access. POgledao sam nekoliko slicnih tema na forrumu ali ni jedna nije dovedena do ozbiljnijeg nivpa. Ukratko cu opisati sistem pa nadam se da ce biti zainteresiranih koji ce se ukljuciti da razvijemo prvo dobar model podataka, pa onda i aplikaciju.

Vozni park se sastoji od n vozila na m lokacija. Jedno vozilo pripada samo jednoj lokaciji - poslovnoj jedinici. Svako dostavno vozilo vozi jedan vozač (izuzev nekih izuzetaka, godisnji, bolovanje..), a putničko ko prije ulovi :)
U bazu ce se putni nalozi najvjerovatnije unositi retroaktivno, bar u prvoj fazi pa onda mozda uvedemo i planiranje putovanja i rezervisanje automobila.
Na putnom nalogu cemo izmedju ostalog imati relaciju putovanja, broj predjenih kilometara i količinu prevezene robe (podatke o kilometrima mozda budem importao iz GPS sistema za pracenje vozila a kolicine iz MS SQL baze ali.. o tom kad dojde za to vrijeme).
Pored ovoga u bazu se unose podaci o troškovima za pojedino vozilo (gorivo, mazivo..), i evidencije o održavanju vozila (veliki servis, zamjena ulja, zamjena guma..). Da napomenem da neku vrstu održavanja samostalno izvodimo, a za neku dobijamo fakturu od različitih servisa.
Potrebno je na kraju odredjenog perioda, vjerovatno mjesec, dobiti podatak o troškovima po pojedinom vozilu, klasificirano po vrsti troška. potrebno je dobiti informaciju o cijeni kostanja prevezene robe po kg (svi troskovi vozila/prevezena količina) o potrosnji goriva po kg prevezne robe, prosječnu potrošnju..

Ja sam napravio početni model podataka (lakše je analizirati nešto i doraditi nego krenuti iz početka) pa bih zamolio za savjet iskusnije korisnike.

Uf, mislim da nisi ni svestan koliki je posao u pitanju. Radio sam na poslovima uvodjenja sistema koji se bavi ovim temama, pa sam delimicno upoznat sa ovom temom
Pokusacu da ti pomognem nekim savetima vezanim za probleme koje sam ja imao u praksi. Nemam vremena da se bavim samim modelom, pokusacu da ti dam neke prakticne savete vezano za probleme sa kojima smo se mi sretali u toku rada i kreiranju softvera.

Putni nalozi:
- Ne mora da samo jedan covek vozi vozilo, nemoj da ogranicavas bazu i softver time, vozaci mogu cesce da se promene nego sto mislis.
- Isto tako vozilo ne mora da pripada samo jednoj jedinici, ostavi mogucnost da se promeni celina.
- Za pracenje kretanja vozila u okviru naloga najbolje je da stavis relaciju 1-n, gde ces za svaku promenu rezima vozila moci da uneses pocestak i kraj rezima u posebnoj tabeli.
Na primer imaces za svaki radni nalog ovakve unose:
- krenuo u 10.30, stao u 15.30 presao 150 km
- krenuo u 16.15, stao u 18.20 , presao 130 km
- .....
Na ovaj nacin ces moci da dobijes najbolju analizu kretanja vozila. Ovo ti je posebno bitno ako imas teretna vozila i hoces da pratis prosecnu potrosnju goriva jer se kod njih ona razlikuje kada je vozilo puno i prazno. Isto tako ces time pratiti sta su ti radili vozaci, ako imas GPS mocis ces da pratis da li popunjavaju tacno naloge.

Gorivo i pracenje goriva:
- Tip goriva - obavezno stavi u okviru podataka o vozilu podatke o tipu goriva i zapreminu rezervoara.
- Svako sipanje goriva evidentiraj na kojoj je kilometrazi sipano.
- Da bi pravilo izracunao prosecnu potrosnju goriva moras da na prelasku iz meseca u mesec da evidentiras koliko je goriva ostalo u rezervoaru, veoma bitno ako su u pitanju teretna vozila jer to moze da bude velika kolicina i moras to uracunas kada racunas prosecnu potrosnju.

Registracije vozila i drugi podaci:
- Vodi racuna da registracija vozila moze da se menja i da nije kljuc za vozila, vec je kluc broj sasije koji jedinstveno identifikuje vozilo.
- Podaci o polisi osiguranja, eventualno ako je vozilo pod lizingm

Odrzavanje.
- To ti je posebne tema koje je prica sama za sebe, posebno ako i Vi radite u okviru vase firme. Moj savet je da probas da postavis sistem za pracenje naloga a da ga kasnije nadogradjujes jer to moze da bude veliki korak ako krenete od jednom sve.

Jedan generalni savet nevezano za samu strukturu baze. Uvodjenj bilo kakvog sistema je naporno. Ako ti budes odgovoran za tu bazu, gledaj da je istestiras na sve moguce gluposti koje korisnik moze da uradi, ma koliko bile malo verovatne. Problem je u tome da svaka greska otezava uvodjenje sisteme jer stvara inicijalnu odbojnost kod ljudi ka sistemu, u stilu "to nista ne radi".

Ako budem mogao pomocicu ti jos nekim savetima.

Zahvaljujem se na detaljnom pojašnjenju problema sa kojim ste se vi susreli, i to ce mi sigurno pomoci da na početku ne napravim veće greške.

ukratko cu dati pojasnjenja za ovo sto si dosad iznio:
1. Ne mora da samo jedan covek vozi vozilo, nemoj da ogranicavas bazu i softver time, vozaci mogu cesce da se promene nego sto mislis.
Uvazicu ovo i nece biti ogranicenja na nalozima - svaki vozac moze da dobije putni nalog za svako vozilo a onaj ko poptisuje naloge zna vec kako da rasporedi.

2. Isto tako vozilo ne mora da pripada samo jednoj jedinici, ostavi mogucnost da se promeni celina.
Dodacu jos jednu tabelu u kojoj cu drzati vozilo, poslovnu jedinicu i vremenski period u kojem to vozilo pripada toj PJ.

3. Za pracenje kretanja vozila u okviru naloga najbolje je da stavis relaciju 1-n, gde ces za svaku promenu rezima vozila moci da uneses pocestak i kraj rezima u posebnoj tabeli.
Kontrola vozaca je vec sredjena kroz GPS sistem nadzora i pracenja, pa ove podatke necemo unositi u ovu bazu, Ukoliko se javi potreba prepisacemo iz tog sistema po nekim pravilima.

4. Tip goriva sam vec planirao ukljuciti

5. Zapisivanje kilometarra na svakom tocenju
Ima mjesta za diskusiju oko ovoga (i njavjerovatnije cemo to uvesti)

6. Registracija nije kljuc, nego svako vozilo ima jedinstvenu sifru (veza za ostalim sistemima)

Znam da ovo nije nimalo jednostavno, ali kako ne napravimo prvi korak necemo nikad doci do cilja.. Krenucemo sa nekim modelom i uvidzajuci nedostatke ispravljati u toku rada.

Jos jednom hvala na savjetima. Kada sredim novi model uploadovacu ga ovdje, pa mozemo diskutovati na konkretnom primjeru.

Zamolio bih za malu pomoc u startu nekog od iskusnijih korisnika accessa.
U priloženom modelu imam nedoumicu kako najbolje vezati tabele vozilo - faktura - stavka..
Najlogicnije je Faktura- stavka - vozilo.. ali na koji način to povezati sa stavkama održavanja.
Mozda je rjesenje da imam posebno stavke fakture i stavke odrzavanja, ali na koji nacin napraviti relaciju izmedju tih stavki da bih znao recimo da sam zamjenu ulja platio nekom servisu.. a da smo samostalno promjenili uljni filter..

Malo je nejasno iz ove price, ali ako pogledate sliku u prilogu siguran sam da ce biti jasnije.

Predlozio bih Vam sledeci model kao osnovu...

Potpis

http://zoraneremija.wix.com/eremijacv

Zahvaljujem na odgovoru, odnosno modelu koji ste mi poslali.
Zanimljivo je da sam ja dolazio na istu ideju u pogledu DOkument,Stavke, Vrste dokumenta ali ne znam kako u accessu da realizujem sljedeci tip vize koji sam izdvojio iz cijelog modela.. pa ako moze pomoc oko toga.. preciznije kako povezati tabelu faktura, putni nalog sa vrstom dokumenta ili samim dokumentom.

Nakacio sam Vam primer Fakture. Sustina je da se napravi Query QFaktura koji u sebi sadrzi i tabelu Dokument i tabelu Faktura. Buduci da je ako ste videli u modelu entitet Faktura specijalizovan entitet od Dokumenta veza izmedju Dokumenta i Fakture je 0-1 Vrsta dokumenta je entitet koji sluzi da se po njemu vrsi diskriminacija i u ovom slucaju atribut VrstaDokumentaID u entitetu Dokument je Diskriminator i on predstavlja matematicki operator "ili", sto znaci da je neki dokument ili Faktura ili Putni nalog ili ...

U formi Faktura videcete da je RecordSouce u stvari Upit ili Query QFaktura, takodje polje FakturaID namerno sam ostavio da se vidi kao i polje VrstaDokumentaID i jedno i drugo polje moraju imati default vrednost s time sto je u polju VrstaDokumentaID vrednost ona koja je adekvatna vrednosti iz tabele VrstaDokumenta, a u polju FakturaID upisite bilo kuju vrednost zbog veze koja je napravljena sa osobinom Cascade Update cim se dodeli vrednost DokumentID automatski se dodeli i vrednost FakturaID.

Ovo je klasican primer Generalizacije i Specijalizacije kao tipa veze.

Na isti nacin cete odraditi i ostale slucajeve, kao i za Partnera s time sto za partnera imate primer Fakture dat na ovom forumu http://www.elitesecurity.org/t401604-Neaktivni-artikli-bazi

Nisam se bavio fizickom strukturom baze zato su svi tipovi podataka Text(50)

Potpis

http://zoraneremija.wix.com/eremijacv