Remontovanje železničkih vagona

Evo lepa igracka koja pomaze u prevodjenju SQL izraza u VB. Napises kveri, a onda ga ovo prevede u VB izraz.


http://www.dpriver.com/products/sqlpp/index.php

Ne razumem samo zasto bi sama sebi komplikovala i pisala glomazne SQL naredbe u VBA ako vec mozes kreirati jednostavnije i brze akcioni upit i kasnije ga samo preko VBA pozvati da izvrsi svoj zadatak, kao u primeru koji sam ti okacio. Za ovu prostiju bazu i mozes tako da radis ali kada ova jednostavna baza postane ozbiljnija i kompleksnija trebace ti gomila kodova da izvrsis neki proces koji bi mogla izvrsiti mnogo brze zahvaljujuci alatkama koje nam nudi sam Access.

Evo na primer koliko ti je bilo potrebno da napises sve ove kodove za Update, Add i Delete dok je sve to moglo da se resi sa akcionim upitima za 5 min.

---

MArija.Ana, Fox028 je u pravu, skoro 100%. Access je napravljen da bi radio na nacin suprotan od onoga sto pokusavas da napravis. Ti pokusavas da nateras Access da se ponasa kao VB. medjutim, Access nije napravlejn da se ponasa kao VB. U stvari, dobar VB program koji radi sa bazama podataka, treba da se ponasa kao Access, ali takvih programa je jako malo. Sta pokusavam da kazem? Access je baza podataka, kojojje dodata jedna varijanta VB jezika, da omoguci programiranje, kad je to potrebno. Sto se tice manipulacije podacima, programiranje absolutno nije potrebno. Zasto bi neko pisao kod za brisanje tacno jednog rekorda kad se to moze uraditi jednim klikom, bez programiranja? Vidis i sam kako se zakomplikovalo sve. Nije cilj da logiku programiranja u C i VB primenis u Accessu.

Logika Accessa: Access je baza podataka = skup tabela, koje se sto je moguce vise pokoravaju zakonima relacione teorije. To izmedju ostalog znaci: 1) rekordi su jedinstveni u svakoj tabeli (Primary Key), 2) rekordi iz jedne tabele mogu da zavise od rekorda u nekoj drugoj tabeli (Foreign Key). Zavisnost preko FK se moze prikazati preko ER dijagrama - Entity-Relationship, 1:vise, vise:vise itd. To si lepo napravila. Kako se iz toga izvodi plan aplikacije (plan u smislu arhitektonskih planova za izgradnju kuce)? Za tabele koje su na strani 1 kreira se po jedna forma, u Form View. Za tabele na strani vise kreiraju se datasheet forme. Onda se datashit forme postave na glavnu formu, kao vezane subforme. U tvom slucaju, treba ti datasheet za Dnevnik i forma za Osovine i jedna za Stanja. Otvori verziju koju ti saljem i pogledaj form koje su imenovane sa Z_ . nem bas mnogo koda, a sve moze da se uradi. Za nesto vise, treba kod, ali ne onako, rekordseti i slicno. Ne ni parameter kveriji kao sto predlaze Fox028, postoji kod u tri linije koji postize isto i bez cuvanja kverija.

I naravno, kad projektujes bazu, polja treba da su odgovarajuceg tipa. Na primer, datumi ne treba da budu text nego DateTime. U tom slucaju dobijes onaj lepi kalendar automatski i ne mozes da uneses recimo 31 Februar (u tekst polje naravno da mozes )

Znaci, ne gubi vreme prevodeci C ili VB kod u Access, nego pokusaj da projektujes bazu pravilno, kao i da aplikaciju razvijas onako kako se to u Accesu radi - sa sto manje koda (makroi su zabranjeni ABSOLUTNO). Bice vremena za kod, ali to ce biti pravoi kod, koji zaista nesto radi. ne vredi trositi snagu u vreme na elementarne stvari (insert/edit/delete/search) - sve to Access ima vec ugradjeno, samo se treba setiti i primeniti.

Zakacena aplikacija je kostur, prvi prototip, kasko treba da se razmislja kad radis u Accessu. Prototip jeste, ali prototip koji radi.

U pocetku nisam ja predlagao da se koriste akcionu upiti niti da se preko VBA upravlja bazom vec kasnije jer je bilo jednostavnije od nacina na koji je krenula da radi mada ni to nije jednostavnije slazem se. I ja sam takdje predlagao da krene da radi slicnom metodom kao sto predlaze i Zidar.

Samo sam se drzao one nase izreke: Vezi konja gde ti gazda kaze. :)

Ali u principu podrzavam Zidarevu teoriju u potpunosti.

---

Ja podržavam svakog (pogotovo onog ko zna više od mene), a pretpostavljam da svi ostali korisnici ovog foruma znaju više od mene. Ono što mene zanima je kako da pomoću VBA da napravim dugme za brisanje ili update/edit. U mojoj Add/Update proceduri je sve u redu sem onog posle WHERE (add radi ali update ne radi)


Da zanemarimo moju bazu i sve ostalo, može li mi neko odgovoriti kako da pravilno postavim uslov posle WHERE.

U formi OsovineF (želim da zapis bude tamo gde je OsovinaID jednaka vrednosti polja txtID) to sam postigao sa:

Ovaj code iznad je ispravan


E sad u formi DnevnikF ((želim da zapis bude tamo gde je OsovinaID jednaka vrednosti polja txtID) i (želim da zapis bude tamo gde je Datum jednak vrednosti polja txtDatum)) znači otprilike ovako:

E ovaj code nije ispravan, može li neko da me uputi kako da ovo pravilno napisem?

Prvo sto moramo znati a to je kojeg su tipa polja u tabeli:
Broj
String
Datum

Broj:
OsovinaID ti je brojcana vrijednost pa cemo to upisati u memorijsku iz taga ovako:
Dim OsovinaID as integer

OsovinaID=Val(Me.txtId.tag)

Strin:
Svaki strin u Vb moramo pisati pod znacima navoda a SQL kod prosledjujemo isto tako kao strin sto znaci da prakticno cio
SQL moramo pisati oivicen kao strin odnoano znacima navoda.
i SQL ima svoja pravila pa i u njemu tekstualni podatak moramo pisati kao string odnosno oviciti ga znacima navoda.
Sad ispada da imamo string u stringu sto bi vb protumacio kao dva stringa.
Doduse u SQL pored ovog (") znaka navoda strin mozemo oiviciti i sa ovim znakom (')
Znaci ako prosledjujemo sql string koji sadrzi podatak kao strin onda to mozemo uciniti ovako:

"WHERE imepolja=' nekiPodatakstr ' "
Ovo je i dosta lako ali sta ako imamo podatak u vb memorijkoj:
Dim Str as string

Str=Me.NekoPolje

Sada bi to izgledalo ovako:
"WHERE ImePolja='" & str & "'"
& Znak za sabiranje stringova a moze ga zamijeniti i znak +

Datum:
SQL baza podrzava forma datuma mjesec dan godina oivicen tarabama (#)

To se moze rijesiti ovako:
Dim MojDatum as string
MojDatum= "#" & fromat(Me.txtDatum.Tag,"mm-dd-yyyy") & "#"

Znaci tvoj Uslov bi izgledeao ovako:

Dim MojDatum as string
Dim OsovinaID as integer

OsovinaID=Val(Me.txtId.tag)
MojDatum= "#" & fromat(Me.txtDatum.Tag,"mm-dd-yyyy") & "#"
"WHERE OsovinaID=" & OsovinaID & " AND Datum=" & MojDatum

---

Hvala Izonic, Kralju! Objašnjeno i (ja se nadam) shvaćeno.


Taman mi ostaje "delete" da uradim da vidimo jesam li naucila nesto.



P.S. nije htelo da radi zbog 2x OsovinaID,

OsovID = Val(Me.txtID.Tag)
MojDatum = "#" & Format(Me.txtDatum.Tag, "mm-dd-yyyy") & "#"
"WHERE OsovinaID=" & OsovID & " AND Datum=" & MojDatum

Upomoc izonic,

Sve je funkcionisalo savrseno, i delete sam uspela srediti. Međutim, ukazala mi se potreba da promenim OsovinaID iz Autonumber u Text, pokušala sam ovako:




Ne radi i ne javlja nikakvu grešku. Jel može pomoć ne shvatam gde grešim?

Fali ti negde (ili ima visak) neki znak ' ili " ili &

Pokusao sam malo da sredim i formatiram tvoj kod. Sada bi trebalo da radi (nisam testirao, u obicnom editoru sam prepradio kod)

Imas primere kako se radi za datume i stringove.


Pitanje: zasto koristis Tag property? [code]OsovID = Me.txtID.Tag, Me.txtDatum.Tag[code]

:-)

Kada kliknem na neki zapis u subformi a zatim kliknem na Edit textbox-evi main forme se napune podacima iz selektovanog zapisa, tako mi je lepše a i sigurnije (nema direktnog unosa u bazu i tesko je slucajno pogresiti). Tag koristim da se zapamti primarykey u child tabeli (osovinaID i Datum) za slučaj da se greškom promeni datum ili id txtDatum txtStanje i ostali txtXxxx su unbound text i combo box preko kojih unosim podatke u tabelu.







U međuvremenu da prekratim sebi muke moram da pitam u vezi primary key-a.

Imam polja Broj i Godina (isti broj se može ponavljati u različitim godinama ali ne i u istoj), nezgodno mi je da bude kombinovani primary (stvara mi probleme sa relacijama kasnije), da li je bolje da koristim autonumber za ID polje ili je moguće da napravim da se ID dobija kombinovanjem broja i godine broj/godina? Ovo drugo bi mi bilo zgodnije ako je izvodljivo.



_{[Ovu poruku je menjao marija.ana dana 25.07.2014. u 23:36 GMT+1]}

Nije to tako komplikovano oko PK. Tvoja tabela Dnevnik u realnom sistemu ima nadređenu roditeljsku tabelu ali ti model verovatno nije dovoljno široko postavljen pa je ne vidiš. Ta roditeljska tabela je tabela RadneGodine sa zapisima (.....2011, 2012, 2013, 2014). Svaki zapis u tabeli Dnevnik je jednoznačno određen godinom i brojem u okviru nje od 1 do n. Prema tome kombinovani PK je preporučeno rešenje uz uvođenje pomenute tabele RadneGodine. Dobro postavljen PK smanjuje kasnije programiranje i olakšava održavanje aplikacije.
Bolje je da sad ispraviš model nego kasnije, kada ti većina formi i izveštaja bude napravljena.

---

Auuu, ovo je baš nizak udarac.

Moja tabela "Dnevnik" ima parent tabelu "Osovine" a model mi je postavljen taman onoliko široko koliko sam ja to htela. Tabela "RadneGodine" ne postoji niti će... Svaki zapis u tabeli Dnevnik određen je identifikacionim brojem osovine i datumom kada se promena desila (bar sam tako podesila ključ).

Moje pitanje (izgleda veoma nemušto postavljeno pošto niko nemože da ga razume) je glasilo:

Da li je izvodljivo da napravim formu za unos osovina gde će mi forma pri unosu broja i godine automatski sastavljati ID field u formatu broj/godina.




Da, pronađoh ovo al ne umem da zamenim "Registrator" sa "Osovina" i da izbacim "SifreRadnika", uvek na kraju neka greška.

Žao mi je ako sam te povredio. To mi nije bila namera.
Modeli se ne postavljaju “taman toliko koliko ja hoću“, već adekvatno realnom sistemu, a o njemu smo veoma malo saznali iz ove teme.
Iz tvog pitanja od pre 5 dana nije bilo jasno o kojoj tabeli se radi, pa sam zbog VBA koda u toj poruci zaključio da je to neka tabela dnevnik. Nebi bilo loše da kad postaviš pitanje uputiš link ka bazi, baš kao što si to uradila u tvom prethodnom postu.

Inače što se tiče odgovora na pitanje (broj + godina) i pravljenja govorećeg ključa, probaj da koristiš CStr funkciju za pretvaranje u tekst obe vrednosti ukoliko su brojčane, potom ampersend (&) za spajanje vrednosti, a možda i + ako nema navodnika i sve to recimo ponudiš na On Enter događaj tvom ključu u DefaultValue osbini.

Ovako nekako jer pišem napamet pa verovatno sintaksa nije dobra:


Me![TvojKljuc].DefaultValue = CStr(Me![Godina]) & CStr(Me!([Broj])


_{[Ovu poruku je menjao Getsbi dana 01.08.2014. u 06:15 GMT+1]}

---

Mozete li opisati problematiku, pa da se model postavi ispravno. Ostalo nece biti preveliki problem.

---

Iz postavljenog modela zakljucuje se da zelite pratiti promjene na nekim OSOVINAMA. O kakvim osovinama se radi? Sta je atribut BROJ u tabeli Osovine, da li je to serijski broj osovine? Da li je ovaj broj jedinstven za svaku osovinu? Sta je atribut GODINA? Da li je to godina proizvodnje osovine? Postoje li ogranicenja po pitanju ovog atributa, koja je minimalna a koja maksimalna godina koja se moze unijeti? Koliko TIP-ova osovina se moze pojaviti? Da li je to unaprijed odredjeno? Sta se upisuje u atribut NAPOMENA tabele OSOVINE? Pretpostavljam da u tabeli DNEVNIK pratite promjene koje su se desile na toj OSOVINI. Da li se u jednom danu mogu izvrsiti 2 i vise tih izmjena na nekoj Osovini? Opisite sta predstavljaju ostali atributi tabele Dnevnik( Stanje,Lokacija,Precnik i Izmjene), koje vrijednosti moze uzeti svaki od ovih atributa odn. postoje li ogranicenja po pitanju unosa u ove rubrike?

---

U pitanju su "Vagonske" osovine, atribut BROJ jeste serijski broj osovine (nije jedinstven jedan isti broj se može pojaviti u različitim godinama na pr. 10012 - 1987 i 10012 - 2012), "Godina" je godina proizvodnje. Osovina može biti stara maksimalno 40 godina. Tip je (ukratko) A ili B ne postoji drugi. Napomena su moja zapažanja nešto na šta treba obratiti pažnju.



U pravu ste, DNEVNIK prati stanje osovine i to stanje može biti: Zaliha, Ugrađena, Neispravna, Remont ili Škart. U jednom danu ne može biti dve promene stanja. Lokacija je mesto gde se trenutno nalazi. Ako je stanje "Neispravna" lokacija je "Neispravne" a u "Izmene" pišem kratak opis neispravnosti; za stanje "Zaliha" lokacija je isto "Zaliha" u "Izmene" pišem šta joj je popravljeno ako je došla sa remonta; za stanje "Škart" lokacija je isto "Škart" a u "Izmene" pišem šta je razlog otpisa. Ako je stanje "Remont", "Lokacija" je ime remontera a u "Izmene" ide šta se radi na njima. Ako je stanje "Vagon" "Lokacija" je broj mesta (broj mesta je jedinstven).

"Praćenje promene stanja" je otprilike idealan primer, samo što meni ne trebaju ograničenja koja su tamo postavljena (iz stanja u stanje). Moj plan je bio da krenem od "PracenjePromeneStanjaDex2+Z2" i da dodam polja "Lokacija", "Prečnik" i "Izmene". Htela sam da upotrebim i primer "povezani combo box-evi" sa ovog foruma i da se ponuđene vrednosti combo box-a "Lokacija" i "Izmene" respektivno menjaju u odnosu na izabrano stanje. Glavna prepreka u svemu mi je neznanje oko formata datuma i tipa podataka (ostalo nekako i naučim sa foruma ili Youtube).

Kao što to obično biva odgovori rađaju nova pitanja dok se stvari ne istjeraju na čistac.
-Da li je serijski broj osovine uvjek petocifren (10012)?

-Šta se dešava sa osovinama koje pune 41 godinu? Da li se zamjenjuju iako su ispravne, odnosno da li je ovo jedan od uslova za otpis?

-Da li se umjesto tipa A moze ugraditi tip B ili se ovi tipovi ne mogu mješati jedan sa drugim?

-Pojasnite malo ovaj atribut napomena. Za koga je u samom procesu bitno to što napišete. Dajte jedan primjer napomene.
U pravu ste da Vam prijer iz teme "Praćenje promjene stanja" adekvatan i za Vaš primjer uz male izmjene. Trebalo bi utvrditi koje je inicijalno stanje, a mislim da bi to bilo Ugrađena-Ugrađena.
-Da vidimo šta se dešava u raznim "stanjima"

"Zaliha" - Pretpostavljam da se stalno nabavljaju nove osovine koje će biti rezerva za one koje će biti otpisane. Uz njih u ovom stanju su i one osovine koje se vrate sa remonta. Da li sam u pravu?
-Gdje su smještene ove osovine, da li su sve na jednom mjestu-jednom magacinu. Da li je jedan rukovaoc- jedan odgovoran za sve ove osovine. Da li se u ovom procesu vrše još neke radnje ( na osnovu kojih se utvrđuje ispravnost pri prijemu u ovaj status)?
"Ugrađena" - Ovde jedna napomena - treba biti dosledan u imenovanju. U prvom dijelu teksta ste naveli status "Ugrađena",a kasnije u tekstu "Vagon". Ako se ovo desi u bazi teze se radi.

-Navedite primjer broja mjesta- primjer načina obilježavanja( Da li je to broj ili kombinacija slova i brojeva i šta označava)
"Neispravna"- Na osnovu čega se utvrđuje neispravnost, ko utvrđuje neispravnost? Šta se dešava kada se primjeti neispravnost- opišite ovaj proces.
"Remont" - Da li remont rade neke druge firme sa kojima imate ugovor ili neki sektor u Vašoj firmi. Šta prethodi remontu. Da li se na remont šalje samo osovina? Ako je tako ko skida osovinu sa vagona? Da li upućivanje na remont prate neki propratni papiri? Ako ima dobro bi bilo imati primjer tog papira.
"Škart" - Osovine koje se nađu u ovom statusu se otpisuju i više se ne mogu naći u ostalim statusima. Šta se dešava sa ovim osovinama, da li se negdje odlažu za rezervne dijelove ili se šalju u topionicu?
Niste dali opis atributa "PREČNIK". Pretpostavljam da se ova vrijednost u nekom procesu može mjenjati. U kom procesu se to dešava? O kakvom prečniku se radi, ko utvrđuje ovaj prečnik i na koji način.
Znam da Vam se čini previše pitanja, ali jedino na ovakav način može se doći do ispravnog modela.

---

Ne, ima šestocifrenih, dvocifrenih, sa jednom cifrom a ima i napisanih ovako "00040" pa pretpostavljam da mora da bude Text a ne Number

Da zamenjuju se svejedno, i to je jedan od glavnih uslova za otpis (uz neka teža oštećenja)

Svaka čast za ovo pitanje. Preporuka je da ispod jednog vagona uvek bude isti tip, ako se menja jedna mora da bude istog tipa ali ako se menjaju sve ne mora da bude istog tipa kao prethodna ali moraju sve da budu iste (to ne bi trebalo da bude uslov u bazi)

Napomena je nešto na šta moram da obratim pažnju u budučnosti i pišem je samoj sebi... na primer "Obrušen broj" ili "Ne poklapa se broj na čelu i na pločici" Vrednost polja napomena je jedina koju bih unosila ručno, sve ostale su tipske i mogu se spakovati u tabele.
Inicijalno stanje (ako mislite početno) ja mislim da bi trebalo da bude Zaliha (tu dolaze i nove i remontovane)

Apsolutno.

Sve na jednom mestu, jedan rukovaoc ne vrše se nikakve radnje ona kod mene stiže kao ispravna i ja je tako vodim dok majstor ne utvrdi neispravnost.

Pretpostavljam da onda stanje treba da bude "Vagon" a ne "Ugrađena"?

Broj mesta "000-1/2", "000-3/4", "000-5/6", "000-7/8"; trocifrena oznaka "000" je broj vagona a sledi pozicija, može biti 2,4 ili 8 pozicija po vagonu. Ja sam zamislila jednu tabelu sa tako upisanim pozicijama koja bi "hranila" combobox "Lokacija" ukoliko vrednost "Stanja" bude "Ugrađena".

U redovnom ili vanrednom pregledu, majstor utvrđuje neispravnost i onda to javlja meni, ja je šaljem na lokaciju "Neispravne" gde čeka red za slanje na remont. Red ja određujem u zavisnosti od više parametara (recimo približnog prečnika ili sličnog kvara)

Remont rade druge firme. Na remont šaljem ja samo osovinu. Osovinu skida majstor koji je utvrdio problem, i zatim meni šalje izveštaj (koju je skinuo i koju je stavio na njeno mesto). Upućivanje na remont prati jedna tabela u koju upisujem redom: godinu proizvodnje, serijski broj, tip, i opis kvara (polje izmene).

"Škart" se odlaže na lokaciju "Škart" (to je otpad, posle ide merenje i ja sa njima više nemam ništa, kad odu mogu ih izbrisati iz baze)

Prečnik se meri pri svakoj promeni stanja, pošto se stalno menja, prilikom eksploatacije ali i pri remontima ili oštećenjima, vrednost može biti od 900mm do 1000mm.

Pitanja nikad nije previše. Pitanja postavljena na ovakav način su me i naučila ponešto. Hvala.

p.s. nadam se da nisam ništa preskočila ili previdela.

Da rezimiramo ono što do sada znamo.
Zadatak baze koja se projektuje je praćenje promjene stanja za OSOVINE vagona.
Osovine imaju SERIJSKI BROJ (koji se nalazi na čelu osovine i na pločici. Ovi brojevi trebaju biti indentični. Može se desiti da se ovaj broj obrusi tj. da nedostaje) Serijski broj se može ponavljati u različitim godinama.
-Šta se dešava ukoliko nedostaje serijski broj? Da li se ukucava novi?
Osovine imaju godinu proizvodnje. Osovine mogu biti najveće dozvoljene starosti 40 godina. Ukoliko osovina prelazi ovu starosnu granicu mora se zamjeniti i na to bi nas sistem trebao upozoriti.
Ako sam ispravno shvatio ovo prethodno to znači da čak ni kombinacija SerijskiBroj-GodinaProizvodnje nije pouzdan Primarni ključ, ali svakako da bi mogao biti alternativni ključ tj. trebalo bi ovu kombinaciju indeksirati.
Osovina može biti tipa A ili B
Osovina ima prečnik koji može biti u rasponu od 900 do 1000 mm.
Osovine mogu biti u različitim statusima: "Zaliha","Vagon", "Neispravna", "Remont" ili "Škart".
Početni-inicijalni status svake osovine je "Zaliha"
Kada je u ovom statusu smatra se da je osovina ispravna i spremna za ugradnju u vagone. Poznat je njen prečnik i tip.
-Kada se osovina izda za ugradnju da li se odmah mijenja njen status iz statusa "Zaliha" u status "Vagon" i pri tome se konstatuje pozicija i ostalo ili se čeka izvještaj da je ugrađena i gdje je ugrađena. Da li ovo izdavanje osovine i slanje na ugradnju prati neki propratni papir? Da li se desi da se pri ugradnji osovine konstatuje da ona ustvari ima neki kvar odnosno da je neispravna.
Kada je u statusu "Vagon", znači da je u upotrebi- ugrađena je na neki vagon. Tada se obilježava kombinovanom oznakom "XXX-Y/Y" gdje je "XXX" brojčana (ne slovna) oznaka-broj vagona , a Y/Y pozicija na vagonu i može imati vrijednosti 1/2;3/4;5/6 i 7/8. Kada su na vagonu svaka osovina mora biti istog tipa A ili B. Ne mogu biti različitog tipa na jednom vagonu.
Ispravnost osovine se konstatuje u redovnim i vanrednim pregledima. Ove preglede vrše majstori.
Ukoliko se primjeti neispravnost majstor skida neispravnu osovinu i zamjenjuje je ispravnom. Da li je prethodno trebuje od vas ili je uzme pa vas poslije izvjesti, pomalo je nejasan ovaj proces.O izvršenoj zamjeni majstor dostavlja izvještaj. U ovom prcesu se vrši promjena statusa za dvije osovine- ona koja je skinuta prelazi iz statusa "Vagon" u status "Neispravna", a ona koja se postavlja prelazi iz statusa "Zaliha" u status "Vagon". Obe osovine moraju biti istog tipa osim ako se vrši izmjena svih osovina jednog vagona, ali tada sve postavljene osovine moraju biti istog tipa ( naravno i sve skinute su istog tipa).Da li se i pri ovim radovima mjeri prečnik? Šta sve piše u tom izvještaju (valjalo bi imati primjer tog izvještaja)? Da li je potrebno evidentirati i koji je majstor u pitanju?
Skinute osovine dobijaju status "Neispravna", i čekaju remont.
Na remont se osovine upućuju na osnovu sličnih karakteristika ( približne veličine prečnika ili sličnog kvara). Ovdje bi trebalo imati izvještaj koji bi se izlistao na osnovu upita.
Ako osovine već čekaju na remont, postoje li ovde neki kriterijumi. Da li čekate da se skupi više osovina da bi smanjili troškove transporta, da ne šaljete samo jednu osovinu nego kad se sakupi određeni broj ili šta?
Kada se ispune određeni uslovi za slanje na remont ove osovine prelaze iz statusa "Neispravne" u status "Remont". Slanje na remont prati propratni papir- tabela u koju se upisuje :godina proizvodnje, serijski broj, tip, i opis kvara. (Ovaj dio će se automatizovati i neće biti potrebe za pojedinačnim pisanjem )
Remont vrše druge firme. Da li ima više firmi kojima se šalju osovine na remont? Ako ima i njih bi trebalo evidentirati u bazi da bi znali gdje je koja osovina, kod kog remontera. Postoje li rokovi za koje vrijeme se mora odraditi remont? Da li se desi da se osovina vrati sa nemogućnošću remonta. Dobijate li izvještaj šta je odrađeno na osovini?
Kada se konstatuje neispravnost koja se ne može remontovati osovina dobija status "Škart" , odlaže se na otpad i vrši se njeno mjerenje. Nakon statusa "Škart" osovina ne može dobiti drugi status.
Da li sam nešto propustio što smatrate da je bitno pomenuti?

---

Serijski broj se ponekad ponavlja u različitim godinama (retko). To oko polja "Napomena" su sve nebitne informacije za stanje osovine (bitne su samo meni, ne menjaju stanje rade se u hodu).

Moglo bi upozorenje da je nastupila godina u kojoj osovina mora biti zamenjena, ali i ne mora.

Kombinacija SerijskiBroj-GodinaProizvodnje jeste pouzdan ključ ne postoji dve iste kombinacije. Retki su slučajevi da je isti broj a različita godina.

Da.

Sve je to posao majstora ja dobijam izveštaj (osovina broj XXX skinuta sa mesta A i njeno stanje je sada neispravna, na isto to mesto ugradjena je osovina YYY. (od tih neispravnih kasnije ja biram koje idu na remont)

Da. Taj redovni pregled se radi isto kod remontera i planirala sam da isto uzima stanje "Remont" pošto ima isti status kao i popravljane neispravne. Ponovo ste postavili izvanredno pitanje... Poslednji osovina mora ići na pregled svake 4 godine (Remont ima isti status kao i pregled).

Majstor sve radi sam, primeti, uzme, zameni, a mene samo izveštava (opisala sam u prethodnom redu kako).

Nekad se čeka da se nakupi, tada šaljem sve što imam. Nekad je remonter pretrpan poslom pa se nakupi puno neispravnih, tad biram da bude sličan kvar. Nekad mi majstor preporuči koje bih trebala poslati.

Ima više firmi koje remontuju, planirala sam da u lokacija upisujem ime remontera. Sve što je potrebno za svako stanje može se upisati u tri polja Stanje Lokacija i Izmene. Recimo:
Neispravna, Neisprave, Precnik, OpisNeispravnosti
Zaliha, Zaliha, Precnik, (prazno polje izmene)
Vagon, brojmesta, Precnik, (prazno polje izmene)
Remont, SifraRemontera, Precnik, sta je uradjeno (u ovom slučaju bi polje izmene i precnik bilo upisano po povratku sa remonta kada dobijam izveštaj t.j. tabelu "serijskibroj, godinaproizvodnje, tip, vrsta uradjenog remonta" )
To sam sve isplanirala uraditi pomoću kaskadnih kombo bokseva (after update Stanje). Za Neispravnost, Remontere, Broj mesta i vrstu uradjenog remonta sam planirala posebne tabele,
Rokovi ne postoje, može se desiti da se ne može popraviti i da se sa remonta vrati kao škart.

Škart je finalni status, posle toga može biti samo obrisana iz baze


Ništa niste propustili, naprotiv.