Access baza radnici,vozila,mašine

Trebalo bi da je sada funkcionalni model u redu. Sledeca aktivnost je izdvojiti primitivne procese ( poslednje u hijerarhiji) i za svaki proces identifikovati kandidate za entitete. Pokusati identifikovati njihove atribute, tip podatka i tipove veza.
Prethodno Vi pogledajte funkcionalni model, pa razmislite za svaki primitivni proces da li postoji neki dodatni zahtjev ili dokument koji nismo pomenuli. Ako postoji takav dokument skenirajte ga.

---

Nastavite sa ovim modeliranjem, ali molim vas da zastanete kad dodjete do dizajna tabela i veza medju njima. Ovo sto gradite je veoma dinamicki sistem, parte se promene kroz vreme. Postojeca literatura, i na srpskom i na engleskom opisuje samo sluccajeve gde se radi o statickim sistemima - ne prate se promene nego samo trenutno stanje. Ako ignorisete cinjenicu da je sistem dinamicki i modelujete ga kao staticki ulecete u probleme. Podaci ce biti nepouzdani, nelogicni i u krajnjem neupotrebljivi. Ako ne postoji sistem koji korektno tretira dinamiku procesa (promene kroz vreme), onda su fizicki kartoni vozila/vozaca (tehnicka knjizica?) mnogo bolji metod nego bilo sta na kompjuteru.

Ako neko moze da iskopa temu koja je bila slicna ovoj, nesto o vozilima ko duzi koje vozilo, ko od koga preuzima. Tu smo prvi put nesto probali da pokazemo kako se prate promene.

U vasem konkretnom slucaju, ne prate se promene samo za vozila i masine, prate se i za vozace i mnogo toga drugog.

Ovo ni pod razno nije pocetnicki zadatak, ako se zeli ispravno resenje. Nije nemoguce napraviti sistem koji izgleda da radi sta se trazi, ali tu ide silno programiranje da bi se sprecile nelogicnosti u podacima. Na primer, vozilo zaduzio neko ko ne radi u firmi vec dve godine. Ili, datum zdravstvenog pregleda je ranije od datuma rodjenja. Ili, neko je zaduzio vozilo koje je odavno otudjeno. Neka mi niko ne kaze da se to ne moze desiti. Setite se samo koliko ste puta citali u novinama da se racuni za komunelije salju na adrese srusenih zgrada, ili se salju korisnicima koji su odavno odjavljeni, ili cak preminuli. To se desava svuda, ne samo na Balkanu. Svi slucajevi kojih se ja secam su u stvari iz Nemacke i USA.

Hvala na sugestiji. Ideja je bila da se pokaže važnost onoga što prethodi samoj izradi aplikacije, i na koji način se radi: uočavanje radnih procesa i prevod uočenog u grafički prikaz. Metodologija koja je korišćena za analizu je jedna od standardnih- IDEF0 . Sličan pristup ima i Strukturna sistemska analiza, a postoje i nestandardne metode. U daljem tekstu zelim da pokretaču teme prenesem( koliko to mogu i umijem) ono što sam ja do sada naučio i usvojio. Jedno od tih usvojenih znanja je i praćenje dinamike procesa kroz vrijeme koje ste u nekoliko tema prikazali pa ćemo pokušati i to da prikažemo. Jedna od komplikovanih stvari je ta što način obezbjeđivanja tog praćenja neće moći da se izmodelira kroz ERWin.
Imam trenutno obaveza pa ću pokušati večeras da krenemo dalje sa uočavanjem entiteta koji se javljaju u pojedinim procesima.
Tema koju ste pomenuli mislim da je http://www.elitesecurity.org/t...davanje-serijskih-brojeva-bazu

_{[Ovu poruku je menjao nenadmarkoni dana 04.03.2015. u 18:18 GMT+1]}

---

Idemo dalje. Kao sto sam rekao , primitivne procese(poslednje u hijerarhiji) iz Funkcionalnog modela potrebno je izdvojiti i za svaki identifikovati osnovne entitete koji se u njemu javljaju. Obzirom da se su sami procesi povezani, pojedini entiteti će se pojavljivati u više procesa. Pošto je ova aktivnost detaljno opisana u predloženoj knjizi,a to poglavlje nije preopširno prenijeću ga ovde za one koje mrzi da je pročitaju knjigu.
Za aktivnost "Identifikacija kandidata za entitete" polazi se od objekata posmatranja. Objekt posmatranja je sve što se može jednoznačno identifikovati, pa samim tim i izolovati iz okoline i opisati. Tako je objekt posmatranja i "entitet". Entitet je osoba, stvar, događaj, pojam (realni ili apstraktni) koji je od trajnog interesa tj. nešto što se želi pojedinačno posmatrati. Za potrebe definisanja ER dijagrama, na primer, mogu se posmatrati sledeći objekti, i to: -fizički objekti (vozilo, mašina,...),osobe, mesta (adrese, koordinate na karti,...), organizacije (preduzeća, zavod,...), grupe/klase/tipovi (tip proizvoda, klasa poslova,...), ugovori, potraživanja (narudžbe, fakture,...), prenos/ premeštaj (stvari, vozila, novca,...), pridruženje (zadatak - osoba, vozila, vožnja,...), pripadnost/članstvo (komponente - sastavi,...) i dr. Za navedene moguće entitete treba: odrediti prikladne radne nazive; napraviti grupe entiteta (ako ih je više od 15); po grupama, tražiti dodatne entitete (posmatrati najvažniji entitet); po potrebi, rearanžirati grupe. Kako se entiteti opisuju preko svojih osobina, tj. atributa, to se identifikacija atributa može izvesti i na sledeći način. Treba poći od postavke da svaki atribut u jednom trenutku vremena ima neku vrednost, zatim analizirati tu vrednost i na osnovu toga proširiti listu entiteta na sledeći način: Na osnovu prethodne analize strukture teksta, imenicu po analogiji smatrati entitetom .Na osnovu sličnosti ATRIBUTA koji mogu pripadati entitetu, uočava se značajna razlika (sličnost), što može da ukaže na to da je reč o različitim (istim) objektima. U toku identifikovanja entiteta, za svaki tip entiteta mora postojati jedan atribut (ili grupa atributa) koji jedinstveno identifikuje konkretni entitet u okviru tog tipa. Atribut koji identifikuje drugi tip entiteta je entitet. Entitet je i atribut koji je istovremeno i atribut drugog entiteta. Na osnovu pasivne i aktivne uloge veze mogu se definisati odgovarajući tipovi entiteta npr. : RUKOVODI- RUKOVODILAC, RUKOVOĐEN - ODELJENJE, NARUCUJE- KUPAC , NARUCEN - PROIZVOD .Na osnovu atributa na dokumentima takođe se mogu identifikovati entiteti : BOJA - BOJA CEGA?-PROIZVOD , STAROST- STAROST CEGA? - RADNIK, DATUM -DATUM CEGA? -NARUDZBE . Na osnovu interesa posmatranja, atribut može biti entitet, a može biti i atribut entiteta, što zavisi od interesovanja, odnosno od toga koji se deo realnog sveta i koji pogled na njega želi predstaviti. Npr., ako je osnovni objekt od interesa-kuća, onda je entitet-kuća, a atribut-ulica, a ako su od interesa-ulice onda su atributi-kuće npr.: Entitet "KUCA" -Atributi (ulica ,kucni broj ,godina izgradnje ,broj spratova, broj stanova) ;Entitet "ULICA" -Atributi (broj kuca levo ,broj kuca desno ,duzina kolovoza ,sirina kolovoza ).

Kako rečeno da primjenimo na našem modelu?

Krenućemo od prvog procesa sa Funkcionlnog modela: 1.1 Evidentiranje tehničkog sredstva. Pokretač teme je u prvom javljanju naveo:

Najprije je uočeno da navedeni entiteti imaju sličnosti u nazivima i atributima te da se mogu grupisati u jedan generalizovani entitet :"Tehnička sredstva", koji je u posmatranom procesu ujedno i dominantni entitet., dok na drugu stranu imaju i svoje osobenosti te se mogu posmatrati i kao posebni entiteti koji bi bili specijalizanti tog generalizovanog entiteta. Obzirom da je jedan od glavnih ciljeva projektovanja da se izbjegne redudantnost(ponavljanje podataka), primjenom pravila normalizacije , sve zajedničke atribute potrebno je smjestiti u generalizovani entitet , a one koji su osobeni za pojedine vrste ostaviti u posebnim entitetima. Šta bi se dešavalo kada bi sve smjestili u jedan entitet? Pojedina polja bi za pojedine vrste ostajala prazna npr: za Putnicko vozilo ostala bi prazna polja: nosivost, broj osovina..., za Teretno vozilo polja: broj sjedista...,prikolice: broj motora,broj sjedista...čime bi se bespotrebno gubio prostor na disku i opterećivao sistem.
Ovo pravilo se u praksi ponekad ignoriše. Obično se očekivani broj zapisa uzima kao mjerilo, pa bi za mali broj zapisa ovakav pristup više opterećivao sistem nego prazna polja.
Neki navedeni atributi takođe se mogu posmatrati kao entitet, npr: "...vrsta(teretno,putničko,putarsko...). Ove tri tačke ukazuju na to da ih može biti još, a može se posmatrati i kao atribut, gdje se to polje kroz svojstvo polja Validation rule, i Lookup field defniše da može da prikaže i prihvati samo definisane vrijednosti. Sve zavisi od pogleda i budućeg očekivanja da li će se ovi podaci proširivati novim i odlučuje se da li će se posmatrati kao atribut ili poseban entitet.
Neki od navedenih atributa kao što su: registarska oznaka, broj polise osiguranja, datum početka osiguranja... su promjenljivi kroz vrijeme te ne samo što ukazuju na poseban entitet, već ukazuju i na poseban proces- proces osiguranja i registracije.
Ovi entiteti će kao podređeni biti povezani sa dominantnim entitetom Tehničko sredstvo, odnosno u njima će postojati strani ključ iz ovog entiteta koji će ukazivati o kom sredstvu je riječ. Oni će biti opisani u posebnim procesima.
Atributi: Vrsta,Marka,Tip su takođe atributi koji mogu biti kandidati za entitete. Opet po pravilima normalizacije podatak koji se uzastopno u više zapisa ponavlja npr: prikolica,prikolica,prikolica...ukazuje na to da taj podatak treba smjestiti u zaseban entitet, a njegovu vrjednost prenijeti povezivanjem sa primarnim kljuem tog entiteta kao FK(Strani-uvezeni ključ drugog entiteta,tabele). Uz to može se posmatrati i povezanost ovih atributa npr. Jedan Proizvođač(Marka) može proizvoditi više Vrsta: Mercedes-Teretna vozila(Actros, Atos), putnička(C220, E190), pa i gradjevinske mašine što ukazuje da ako se posmatraju kao entiteti ne samo što definišu Tehničko serdstvo, već se i međusobno definišu.
Šta će od navedenog ostati kao atribut, a šta prerasti u entitet zavisi od interesa onoga ko posmatra sistem. Ja mogu da dam samo predlog a da li će to odgovarati Vama morate sami procjeniti na osnovu Vaših interesa. Takođe od detaljnih zahtjeva i predviđanja budućih potreba zavisi i da li će se dodati još neki pojam. Predlog u grafičkom obliku rađen u ERwin-u ako stignem večeras.

---

Da bi @mario.po shvatio o čemu pričam napravio sam tri modela za proces Evidentiranje tehnickog sredstva (u prilogu). Prvi model je slučaj generalizacije-specijalizacije gdje se zajednički atributi u generalizovanom entitetu, a oni koji su svojstveni za pojedine vrste u specijalizovanim entitetima. Takođe su radi prethodno izloženog povezani i entiteti Proizvođač(Marka), Vrsta(Tip) i Model. U specijalizovane entitete je prenešen i atribut VrstaTehničkogSredstva koji bi zbog Check konstante u njemu obezbjeđivalo da se u specijalizovanim entitetima mogu naći samo ona TehničkaSredstva koja pripadaju toj Vrsti.
U sledećem modelu je prikazana druga varijanta gdje su svi atributi svih VrstaTehnickogSredstva smješteni u jedan entitet.
U trećem je u pomoćnim tabelama prikazan tzv. sistem paralelnog označavanja koji u svojoj strukturi ima : IDBroj, Klasifikacioni broj, Standardizovan naziv i Sifru. Obzirom da se radi o malom broju zapisa preporučio bih drugu (treću)varijantu.
Ako može @mario.po da napravi popis atributa- ono što unosi iz servisne knjizice razvrstan po vrstama tehničkog sredstva da bi znali koje atribute da unesemo. Podaci o osiguranju i registraciji ne idu u to.

---

Kucao sam odgovor na desktop računaru i baš kada sam hteo da pošaljem restartuje mi se računar najverovatnije zbog pada napona... Poludeo sam... Ne mogu da verujem... Ajmo sad sve iz početka...

Prvo da se izvinim što nisam neko vreme bio aktivan, ali od silnih obaveza nisam mogao da stignem. Pročitao sam vaše postove i pozabavio se funkcionalnim modelom koji je postavio @nenadmarkoni. Mislim da su sva dokumenta obuhvaćena ali ako nešto primetim da nedostaje napisaću.



TERETNA VOZILA: Invetarni broj, Marka, Tip, Godina proizvodnje, Broj osovina, Nosivost, Masa, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije, tip tahografa, vrsta motornog ulja, dimenzije pneumatika,

PUTARSKA VOZILA: Invetarni broj, Marka, Tip, Godina proizvodnje, Nosivost, Masa, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije, tip tahografa(analogni, digitalni, bez tahografa), vrsta motornog ulja, dimenzije pneumatika,

PUTNIČKA VOZILA: Invetarni broj, Marka, Tip, Godina proizvodnje, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije,, vrsta motornog ulja, dimenzije pneumatika

PRIKOLICE: Invetarni broj, Marka, Godina proizvodnje, Nosivost, serijski broj

GRAĐEVINSKE MAŠINE: Invetarni broj, Vrsta, Marka, Tip, Godina proizvodnje, broj motora, broj šasije, serijski broj, snaga motora, zapremina motora, težina, vrsta motornog ulja, dimenzije pneumatika,

Ne znam samo da li proces Evidentiranje tehničkog sredstva formirati ovako sa 4 entiteta ili ipak formirati sa tri entiteta ( Vozila, Mašine, Prikolice)? Na sledeći način:

VOZILA: Invetarni broj, Marka, Tip, Vrsta (Teretno, Putarsko, Putničko) Godina proizvodnje, Broj osovina, Nosivost, Masa, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije, tip tahografa, vrsta motornog ulja, dimenzije pneumatika.

PRIKOLICE: Invetarni broj, Marka, Godina proizvodnje, Nosivost, serijski broj

GRAĐEVINSKE MAŠINE: Invetarni broj, Vrsta, Marka, Tip, Godina proizvodnje, broj motora, broj šasije, serijski broj, snaga motora, zapremina motora, težina, vrsta motornog ulja, dimenzije pneumatika

U ovom drugom slučaju javljalo bi se dosta praznih polja, kao na primer to da putničko vozilo nema tahograf, broj osovina...

Setio sam se još jedne stavke koju nisam spomenuo, a to je da nisu sva vozila u našem vlasništvu, već imamo neka vozila koja su na lizingu koji ističe određenog datuma, ili će se možda desiti da neko vozilo nabavimo na lizing.

Za koji proces je bitno sto je vozilo na lizing? Potrebno je odobrenje za registraciju posto se vodi na lizing kucu, je li tako? Sta jos? Sve cemo smjestiti u jednu tabelu-entitet pa cemo uslovima u tabeli ograniciti unose. Koji je broj vrsta gradjevinskih masina koje se mogu javiti u sistemu? Mislim da se i VrstaGradjevinskeMasine moze smatrati entitetom.

---

Upravo to, bitno je zbog registracije a i zbog datuma isteka na lizing jer se u tom slučaju prilikom registracije menja i saobraćajna dozvola.
Imamo sledeće vrste građevinskih mašina:Bager točkaš, bager guseničar, Buldozer, Finišer, Glodalica, Grejder, mašina za bankine, mašina za obeležavanje, mlin za kamen, utovarivač, rovokopač, kombinirka, mini bager, sejačica, mlin za kamen, traktor, Valjak. To su vrste mašina koje za sada koristimo.

Za proces 1.1 Evidentiranje tehnickog sredstva urađen je model u prilogu. Baza je eksportovana iz ERWina u Access zbog onih koji ne koriste ERWin i u njemu malo doradjena. U pojedinim poljima postavljena su ograničenja. Da li još neko ograničenje treba postaviti ili popraviti postavljena nek prosudi @mario.po. Znači treba da prođete kroz svako polje tabele i vidite da li tip polja koji sam postavio odgovara onome što se u njih unosi. Da li uneseno ograničenje odgovara stvarnom stanju i da li se za neko polje može dodati još neko ograničenje? Da li se kod u validaciji tabele slaže sa stvarnim stanjem? U validaciji tabele je postavljeno da se za izabranu VrstuTehnickogSredstva može ili ne unijeti odrađena polja. Kad smo već kod toga, da li za Prikolice trebaju podaci : Masa, NajvecaDozvoljenaMasa, DatumPrveRegistracije, DimenzijePneumatika i pretpostavljam da imaju BrojŠasije( Ako nemaju onda se BrojSasije ne može uzeti za primarni ključ tabele TehnickoSredstvo) . Ako nemaju u validaciji tabele treba i to dodati.
Pogledajte malo pa se čujemo u nedelju ili ponedeljak da nastavimo ili da ispravimo ako nešto nije dobro. Pokušajte da unesete probne vrednosti u tabele. Najprije se unose vrijednosti u pomoćne tabele(Šifarnike) pa tek onda u tabelu TehnickoSredstvo.

---

Za prikolicu bi trebalo da moze da se unese datum prve registracije, dimenzija pneumatika i broj šasije.
Međutim, stavio bi da primarni ključ bude invetarni broj jer svako sredstvo u firmi mora da ima invetarni broj ( od stolice do kamiona), kao i to da invetarni broj bude requried.

Kada popunjavam tabelu dobijam grešku. Slika greške u prilogu. Kreirao sam formu za unos podataka jer se tako bolje vidi šta sam u koje polje uneo. Primetio sam da se greška javlja kada unesem vrednost u polje Tezina i onda se prebacim na sledece polje, a kad pomenuto polje ostavim prazno onda se greska ne javlja. Isto se desava i sa poljem broj sedista, broj mesta za stajanje. Koliko vidim mislim da nisam nigde prekršio validation rules prilikom unosa podataka.

Upravo upozorenje koje Vam se javilo je upozorenje na ogranicenja koja smo unijeli. Za teretno vozilo se me moze unijeti tezina jer se moze unijeti samo za masine, broj sedista i broj mesta za stajanje je tipican podatak za putnicko vozilo,kombi,autobus( svi su u kategoriji putnicko). Ne znam koja su to putarska vozila i sta treba da bude ograniceno u toj kategoriji. Za teretno umjesto tezina mozete unijeti masu i najvecu dozvoljenu masu. Tako sam shvatio i tako uneo u ogtanicenje.

---

Pomenuto ogranicenje nalazi se u validation rule tabele. Mozete mu pristupiti tako sto cete otvoriti tabelu u design mod-u ,desni klik- properties, polje validation rule.

---

Sto se tice primarnoj kljuca. Prvo pravilo je da mora da jedinstveno identifikuje zapis, a drugo da je nepromjenjiv kroz vrijeme. Sta ako dodje novi direktor i zeli da se izvrsi novo inventarisanje sa novim inventarskim brojevima itd... Broj sasije u normalnim uslovima po zakonu ne bi smio da se izmjeni.

---

Nisam znao za ovo ogranicenje u validation rule tabele, zato sam se i zbunio kada sam dobio grešku. Super opcija. Taman kada se naprave forme za unos podataka, ta polja koja su na primer nepotrebna izbace se iz same forme i ne moze da dolazi do javljanja pomenute greske.
I ako se invetarni brojevi nisu menjali jos od trenutka kada su uvođeni, imate pravo, nikada se ne zna kome sta moze da padne na pamet pa odluci da promeni nacin evidentiranja sredstava, dok broj šasije nije sklon izmenama. Tako da, ostavljamo da primarni ključ bude broj šasije. :)

Što se tiče ostalih postavljenih ograničenja mislim da je sve OK. Mada, kada malo bolje razmislim, na saobraćajnoj dozvoli teretnog vozila ima podatak o nosivosti vozila, masi vozila i ukupnoj masi koja je jednaka zbiru nosivosti i mase.

Putarsko vozilo je vozilo koje se koristi za prevoz radnika koji na primer rade na sanaciji kolovoza. Po zakonu mora da poseduje tahograf, često ga svrstavaju u kategoriju polu-teretnog vozila ili čak i teretnog vozila. U njemu se najčešće mogu prevoziti 6-8 osoba + vozač. Evo slike jednog tipa putarca Slika

_{[Ovu poruku je menjao mario.po dana 08.03.2015. u 15:35 GMT+1]}

Zbir mase i nosivosti je najveca dozvoljena masa, a taj podatak imate. Sad kada ste shvatili ogranicenje mozete ga upotpuniti i izmjeniti prema stvarnim podacima. U prevodu zanci: kada je VrstaTehnickogSreddtva=Teretno vozilo ne smije se unijeti Tezina,BrojSedista,BrojMestaZaStajanje,... i tako za sve vrste.
Sto se tice buduce forme, za odabranu Vrstu moze se ograniciti polje koje se ne unosi da bude Enabled=False i tada mu se nece moci pristupiti. Otom potom...mozda forma nece uopste izgledati ovako :-)

---

Kad smo malo razjasnili ono što smo uradili, i ustanovili da je to otprilike to ( može se o tome još razmišljati npr. Dimenzije pneumatika mogu biti osnovne-preporučene i dodatne koji se takođe mogu postaviti zar ne? Kod nekih sportskih modela naprijed su jedni a nazad drugi pneumatici :-) itd.) ,da pređemo na sledeći proces " 2 Kontrola tehnicke ispravnosti". Njega smo razložili na dva podprocesa 2.1 Evidentiranje periodičnog pregleda i 2.2 Evidentiranje kontrole tehničke ispravnosti. Sve kontrole tehničke ispravnosti možemo podjeliti u nekoliko vrsta :
-Pregled prije upotrebe koji se evidentira na radnom nalogu pri upućivanju na radni zadatak
-Periodični pregled koji vrši Referent tehničke ispravnosti uz još par članova kao komisijom za bezbjednost saobraćaja i evidentira se na obrascu Zapisnika.
-Redovni tehnički pregled koji je propisan zakonom i preduslov je za registrovanje tehničkog sredstva i koji vrši specijalizovana ustanova a kao potvrdu tehničke ispravnosti izdaje neko Uvjerenje-potvrdu( trebali bi znati kako izgleda taj dokument ako je moguće)
-Vanredni tehnički pregled koji je proceduralno isti kao i redovni ali nije obavezan.
Naveli ste da periodični pregled vršite na svaka tri mjeseca, a vanredni tehnički pregled na svakih šest. Predpostavljam da se redovni tehnički pregled radi na svakih godinu dana.
Ono što nismo naveli je šta se dešava u slučaju da se umjesto ispravnosti ustanovi neispravnost? Opet pretpostavljam da se za manje tehničke probleme sredstvo upućuje u tehničku radionicu preduzeća a za veće kvarove u ovlašćeni servis ( naročito kada se radi o novom sredstvu koje je uz to i kasko osigurano i pod lizingom)
U tim slučajevima javlja se ona vremenska dimenzija - promjene kroz vrijeme koju je pomenuo @Zidar. Ukoliko je vozilo upućeno na otklanjanje neispravnosti ne može se uputiti na radni zadatak. Neke neispravnosti se rješavaju u hodu-brzo , dok je za neke potrebno značajno vrijeme. Zbog toga će morati da se prati raspoloživost sredstva kroz promjene stanja koje može doživjeti .
@mario.po sada se koncentrišite na ove procese i kako oni teku. Da li se javljaju još neki dokumenti ( Zahjev za vršenje tehničkog pregleda, zahtjev za servisiranje, zahtjev radionici za popravku-otklanjanje sitnih neispravnosti, zamjenu pneumatika...) i ako se javljaju skenirajte ih i priložite. Da li se zapisnik o periodičnom pregledu zavodi na neki način i kako se čuva?
Kako se čuva potvrda-uvjerenje o vanrednom, redovnom tehničkom pregledu i ako može skenirajte primjerak.

---

Što se tiče procesa Kontrola tehničke ispravnosti vozila meni su najpotrebnije sledeće stvari:
- informacija o tome kada je poslednji put vršen periodični tehnički pregled tehničke ispravnosti vozila (koji se radi na svaka 3 meseca) i kada bi trebalo da se vrše naredni
- da mogu da štampam pomenuti zapisnik za vozila
- informacija o tome kada je poslednji put vršen 6-mesečni tehnički i kada bi trebalo da se vrši naredni (i da mogu da štampam izveštaj o tome koje vozila u kom mesecu treba da vrše vanredni tehnički pregled). Ovaj vanredni tehnički pregled nismo u obavezi da radimo, ali mi ga radimo kao da nam je obavezan.

Redovan tehnički pregled se vrši onda kada se vozilo i registruje (na svakih godinu dana), odnosno nekoliko dana pre nego što bi trebalo vozilo registrovati. Potvrdu o tehničkoj ispravnosti (kada vozilo prodje tehnički pregled) kolega zajedno sa svim ostalim dokumentima odnosi u policiju prilikom registracije vozila i isti se kod nas ne zadržava pa ne mogu da ga skeniram.

Pošto imamo sopstvenu radionicu, sve kvarove koje možemo otkoniti otklanjamo u našoj radionici, a sve kvarove za koje nismo u mogućnosti da otklonimo, šef radionice upućuje vozilo u neki od servisa sa kojima sarađujemo, tako da sa tim ja nemam dodirnih tačaka. Kada se vozilo popravi, dobijam usmeno obaveštenje da je vozilo ponovo na raspolaganju (pokušavao sam da ih naučim da tu informaciju dobijam e-mail-om jer onda imam pisani trag ali nažalost to nikako ne uspevam).

Zapisnik o periodičnom pregledu arhiviramo u registratorima, odnosno za na primer mesec januar sva vozila su u jednoj fascikli koja je u registratoru, i tako za svaki naredni periodični pregled. Popvrda o izvršenom vanrednom tehničkom pregledu čuva se u dosijeu vozila ( primer potvrde u prilogu).

Čini mi se da je obrazac zapisnika standardni obrazac. Pitanje je svrhe štampanja tog zapisnika jer je dokument koji, čini mi se ,ovjeravaju potpisima tri člana komisije. Možda je svrsishodnije čuvanje skenirane slike tog zapisnika a da se u bazi čuva podatak koji je rezultat pregleda te ako je utvrđena neispravnost unijeti opis te neispravnosti a dokument koji se može štampati može biti propratni dokument sa opisom kvara prema radionici.
Pitanje je koliko Vam je bitno evidentirati ko su ta tri člana koji su vršili periodični pregled? Ako Vam je to bitno može se evidentirati. Ko su u suštini pored Referenta ostala dva člana?


Koliko sam ja pročitao MUP dozvoljava da potvrda o tehničkoj ispravnosti pri registraciji može biti stara do 30 dana, ali dobro....


Koliko razumijem Vi ste odgovorni za vozilo dok ono ne ode u radionicu, pa ste opet za njega odgovorni kada se vrati, ali ne znate šta se sa njim u međuvremenu dešava ni gdje je? Upisuje li se šta u servisnu knjižicu, dobija li se kakav račun ili potvrda šta je rađeno? Čuva li se to u dokumentaciji-dosijeu vozila.Da li opet neko pregleda sredstvo kada se vrati sa popravke.


Ovde mi je opet nelogičnost. Koliko shvatam odradite periodični pregled za sva tehnička sredstva u januaru, pa u aprilu, pa julu... i to se čuva odvojeno od ostalih dokumenata iz dosijea vozila?
Za vanredne i redovne tehničke preglede čini mi se da je i podatak "Ko je vršio taj pregled" bitan. Znači da bi trebali da čuvamo i podatak o spoljnim saradnicima?

---

Kako otprilike za sad treba da izgleda ovaj proces u prilogu. Dodaćemo ono što još budemo saznali. Ovde nema Lookup pogleda jer svakako dizajniramo BE baze, padajuće liste ćemo dodati na FE, a bio sam ih postavio da bi @mario.po bilo jasnije o čemu se radi.

---

Jeste standardan, nego taj zapisnik ja imam u Word-u (tako nasledio od kolege) i na svakih 3 meseca štampam za sva vozila, pa sam mislio da može da se odradi da isti štampam iz Access-a, ali kad malo bolje razmislim i suštini i nema potrebe da gubimo vreme na to.

U pravu ste, ovako je najbolje.

Nije mi bitno evidentiranje članova komisije. Nisu uvek isti članovi. Pored referenta od članova obično budem ja i šef radionice ili rukovodilac mehanizacije.

Upravo tako. Kada nam se desi da na primer na 15 vozila ističe registracija istog dana, onda tehnički pregled počnemo da radimo i po nedelju dana pre isteka registracije.

Ja raspolažem vozilom dok je ispravno, odnosno upućujem ga na rad i njime koordiniram, kada se pokvari i vozilo uđe u radionicu, za njega odgovara šef radionice, u slučaju da kvar ne može da otkloni radionica šef radioncie me obaveštava da vozilo mora u drugi servis i ako je moguće voziti vozilo do servisa ja dodeljujem vozača koji će to da uradi, kada se popravi, šef radionice me obaveštava o tome i opet mi je na raspolaganju. Tako da ja u svakom trenutku znam gde je vozilo i šta se sa njim dešava.

Upravo tako. Čuva se odvojeno od ostalih dokumenata iz dosijea vozila jer nam tako traži policijski inspektor koji dolazi u kontrolu. Da, trebali bi da čuvamo podatke o spoljnim saradnicima.