1. varijanta. Da prevlačiš 5,8, 10 puta čitačem preko bar koda ili da prevučeš jednom i ukucaš količinu. Isti problem imaju i kasirke u samopslugama.
2. varijanta. Šifriranje robe koje u sebi sadrži i informaciju o broju komada.



Trebalo bi verovatno uvesti nešto kao broj isporuke. Svaki broj isporuke bio bi vezan za isključivo jednog kupca, a broj naloga bi mogao da bude promenljiv. Tako bi sifra kupca bila na master formi gde i broj isporuke.

Da to i hocu. Da svako prevlacenje tj citanje koda bude jedinstveno bez obzira sto se iste sifre ponavljaju (sifra se sastoji od 13 karaktera prim 333111997777 gde su prva tri karaktera "333" artikal sledeca tri "111" dezen, naredna dva "99" velicina i poslednja cetiri "7777" broj radnog naloga). Znaci u kutiji za odredjenog kupca mogu biti 5 istih kosulja sto znaci da imaju iste sifre. Meni problem predstavlja obelezavanje broja kutije. Ako u kutiji staju recimo 5 kosulja hteo bih da se u podformi pojave polje za broj kutije koje bi bilo primarno, zatim 5 polja, koja su ujedno povezana sa brojem komada koje je zadato u formi, u kojima bi se unosili podaci sa bar koda tj sifra i na kraju sifra kupca. Druga varijanta je neizvodljiva u mom slucaju jer bih morao menjati bar kod. Prva je ok samo da pronadjem resenje za ogranicenje broja polja u podformi.

Promenljiv broj polja na formi je moguć. Postaviš kolonu za izbor vrste pakovanja i kontrolišeš osobinu Enabled na poljima. Polja koja sa: Enabled = Yes su dostupna. Ona druga nisu. Kursor ne ulazi u njih. Kad promeniš pakovanje, raspored ili bolje rečeno broj dostupnih polja na formi se menja. Ovo se rešava u VBA kodu i nije baš neka mudrolija. Dužina koda uglavnom zavisi od broja vrsta pakovanja. Međutim i ovde moraš bar jednom da upotrebiš tastaturu za odabir pakovanja, što znači da si na istom. Onda bolje ukucaj broj komada.

Ovo je vec nesto. Da pojasnim jos jednom, ako u formi tj zaglavlju unesem broj komada za pakovanje 5 ili bilo koji drugi broj u pod formi se pojavljuju 5 polja za unos podataka sa bar koda. Podforma bi izgledala ovako: "broj kutije", "sifra1","sifra2","sifra3',"sifra4","sifra5","sifra kupca" sledeci red: "broj kutije", "sifra1","sifra2","sifra3',"sifra4","sifra5","sifra kupca" i tako do poslednje kutije. Sada mi je samo potreban primer.

unapred zahvalan

Da li si razmisljao mozda da unapred na samu kutiju nalepis jedinstveni bar-kod koji bi sadrzao u sebi informaciju o velicini kutije? Ako kutije primaju razlicit broj kosulja, verovatno su one razlicite velicine. Mogao bi za razne velicine kutija unapred da pripremis bar-kodove i da ih odstampas na nalepnicma. Onda neko uzme i polepi nalepnice na kutije. Kad kutija dodje na red za punjenje, prvo se skenira barkod ba kutiji. Na osnovu toga utvrdis velicinu kutije i na osnovu toga se prilagodi forma za unos. A ostane ti u bazi i veza koje kosulje su u kojoj kutiji.

Ako sve kosulje koje su u kutiji imaju isti barkod, onda ti treba dodatna provera popunjenosti kutije, nezavisna od kompjutera. Radnik moze vise puta da skenira istu kosulju a u kutiju stavi samo jednu. Onda kompjuter misli da u kutiji ima 5 kosulja, a tamo samo dve ili tri. Ako su kosulje priblizno iste, imace priblizno istu tezinu. Kutije za odredjeni tip kosulja takodje treba da imaju priblizno istu tezinu. Na osnovu izmerenih tezina pune kutije mozes da utvrdis da li je kutija puna ili ne. Mze naravno i neki inspektor da na kraju linije prebroji kosulje u svakoj kutiji, ali to je neproduktivan posao, a i inspektori grese. Pokusaj da osam sati dnevno brojis kosulje u kutijama :-)

:-)

Vidim da su kolege skoro blizu rešenja, samo mi jedna stvar bode oči: Brojao sam par puta i smem da kažem da je ovo broj od 12 cifara, znao sam da ćeš pogrešiti ... Zato je bolje što više stvari prepustiti računaru

Ups, zbog pretrpanosti se i pogresi. Hvala "domaci_a_nas", upravu si bar kod ima 12 karaktera.

Hajde da pojasnim jos jednom, kada radnik napuni kutiju sa kosuljama (recimo da je kutija u kojoj se pakuju 5 komada) on ih tek tada (tj moj predlog) skenira kako nebi doslo do dupliranja i tek nakon skeniranja zatvara kutiju i salje je u magacin. Ako kutija nije puna ostaje dok se ne popuni a ako je zavrsen nalog i u kutiji od 5 upakovano 3 kutija se zatvara i takodje salje u magacin. Meni je samo problem kako da povezem formu sa podformom tj ako je u formi set od 5 komada da se u podformi otvore 5 polja za unos kodova plus polje za broj kutije pre kodova i polje kupaca posle. Takodje da se posle unosa poslednjeg polja (u ovom slucaju kupca) otvara novi red sledeci broj kutije.

Zidar, ako na kutiji nalepim jos jedan bar kod koji bi ima podatak o velicini ne dobijam nista vise no povecanje troskova. Mislim da je lakse da se taj broj, broj komada u kutiji upisuje rucno a sve ostalo je manje vise lako. Automatski dodeljen broj kutije, skeniranje kodova i sifra kupca na kraju pa ponovo, naredni broj, kodovi, kupac. Zaboravih da spomenem da bi kljuc forme bio radni nalog ili ako mislite da bi bilo lakse kupac ali bi se onda radnik zbunio menjanjam formi za unos jer se u proizvodnji radi nalog za nalogom pa stoga smatram da je bolje formu vezati za radni nalog a u podformi dodati kao sto sam rekao kupca.

Zahvaljujem se smima na savetima i nadam se pomoci do krajnjeg resenja.

Mozda sam ipak trebao ovu temu nazvati promenljiv broj polja u podformi zavisno od unosa seta u formi.

Iz ovoga sledi da imas vezu 1: vise gde je na strani 1 tabela Kutija (BrojKutije, SifraKupca, DatumVreme) a na strani vise "Kosulje u Kutiji" (BrojKutije, RedniBroj, IDKosujlje). Broj kosulja u kutiji je kardinalnost (N) za tabelu KosulejUKutiji. Mozes da u tabeli KosuljeUKutiji imas kolonu RedniBroj, koju programski popunjavas brojevima 1 do N pri svakom skeniranju. Onda bi imao formu (Kutije) i subformu (KosuljeUKutiji). RedniBroj na subformi povecavas (na primer na BeforeUpdate za subformu) i ako RedniBroj postane veci od onoga sto si zadao na glavnoj formi, jednostavno program ne prihvati taj unos (Before Update na subformi). Kad dostignes maximalan broj kosulja u formi, onda pozoves proceduru "new Record" za glavnu formu. Kako znas da si dostigao maximum za kutiju? After Update za subformu. Kako bi radila procedura "new Record"? Imas dugme cmdNoviRecord na glavnoj formi koje dodaje novi rekord u tabelu Kutije. Iz subforme pozoves to dugme sa Call cmdNoviecord_Click.

Nadam se da je ovog puta savet razumniji.

Projekat ti je veoma zanimljiv i naucices mnogo dok ga napravis. Pre desatak godina radio sam slican sistem. Mi smo pakovali sveske u kutije i morao je da bude tacan broj svezaka u kutiji. Svaka sveska imala je jedinstveni ID, kao i svaka kutija. Kutije su isle na palete i znali smo u svakom momentu gde je koja kutija i gde je koja sveska (gde bi trebalo da bude). Isto je bio uslov da kad se ubaci poslednja sveska, sistem sam prekine unus i odstampa neku vrstu otpremnice - spisak svih svezaka u kutiji. Pored automatskog stampanja imali smo i dugme da se moze stampati po potrebi i pre kraja. Sistem je takodje posle zavrsenoe jedne kutije automatski otvarao formu za sledecu kutiju. Imali smo nalepnice na kutijama nalepljene unapred. Pokusali smo da sistem kreira broj kutije 'u letu' ali onda nam je trebala nalepnica sa tim brojem posle kreiranja kutije. A stampac nije mogao u to doba da drzi u jednoj fioci papir a u drugoj labele, pa smo kutije pripremili unapred.

To je prava stvar Zidar, jos kada bi mi poslao primer bio bih ti zahvalan. Zanam da za hvala nema nista da se kupi no...

U nadi da cu doci do resenja uz vasu pomoc,
pozdrav

Evo

Prvo hvala, drugo svaka cast kralju.

Jeste da sam zamislio da forma bude vezana za nalog i da unosi budu jedan posle drugog (a ne kao u tvom primeru jedno ispod drugog) i na taj nacin da broj polja bude ogranicen jer bih tako izbegao preterano tipkanje od strane radnika koji te podatke unosi i broj strana bi bio manji a samim tim i njihov posao laksi. Nadam se da mi neces zameriti ako te zamolim za takav primer, meni je takvo olaksanje potrebno. Super je ovo sto si uradio i stvarno sam ti zahvalan no ja bih ipak probao da njima, radnicima, uprostim posao. Od previse tipkanja mogu se pogubiti i time nismo dobili nista. Ako bih pak, formu koju si uradio, prepravili na gore pomenuti nacin i ona umesto za broj kutije i kupca bude vezana za radni nalog (u ovom slucaju polje broj kutije bih zamenio sa poljem broj dokumenta recimo a polje kupac sa poljem radni nalog) maksimalni broj kosulja je super i to nebih menjao, tako da forma ima takav oblik a subformu bi trebalo zameniti da sledeci nacin: broj kutije, zatim zavisno od maksimalnog broja kosulja toliko polja (jedno za drugim) i na kraju bih dodao sifru kupca pa sledeci red tj niz (ne kolonu kao u tvom slucaju), novi broj kutije, onoliko polja koliko je to naznaceno u polju maksimalan broj kosulja i sifra kupca. Sve ostalo je super. Ovo bi se mozda moglo uraditi ako subforma umesto Datasheet bude neki oblik forme. Ako bih to uradio to bi bilo vise nego super. Znam da je teoretski moguce ali ja ne znam kako pa mi je potrebna pomoc.

Nisam siguran da razumem problem. Ja sam pretpostavio da je kutija kontejner za kosulje. Svaka kutija pripada nekom radnom nalogu, a radni nalog je za nekog odredjenog kupca. Zato sam tako organizovao tabelu Kutije. Ako je drugacije, prvo treba da se prerade tabele. Ja sam ti dao primer kako se to radi, najprostiji, da pokazem kako se dobiaj efekat proizvoljnog broja kosulja po kutiji. Mozda pre ovoga sto sam napravio treba 'otvoriti' radni nalog, pa odatle ides na kutije i teras sa kutijama dok ne zavrsis ceo nalog (jedan nalog moze imati N kutij od po K kosulja u svakoj?)

Raspored polja na formi mozes da prepravi i sam, horizontalno ili vertikalno, nema veze.

Ne vidim da postoji neko preterano kucanje - ako se izbace nalog i kupac sa forme frmKutije (onda treba da se preradi i tabela tblKutije, ne treba ti i Nalog i Kupac) sve sto radnik treba da uradi ej da potvrdi kreiranje nove kutije pritiskom na Y. Kursor odmah odlazi na subformu i pocinje skeniranje. kad se skenira odredjen broj kutija, iskace poruka da je kutija gotova i pitanej da li se zeli nova kutija. Klik ili ptritisni Y i teraj dalje.

Ne razumem ono 'broj strana bi bio manji' Kojih strana?

Ako si zamislio da jedna kutija bude jedan red na subformi sa onoliko kolona koliko je maximalno kosulja dozvoljeno, to nece moci. Teorijski moze ali je isto tako vrlo pogresno teorijski i vrlo nugodno u praksi.

Ako nam zakacis primer baze (sa tabeleam i relacijama) mozda se bolje razumemo. Posto to nisi zakacio, ja sam morao da pretpostavljam tabele i izgleda da je tvoja ideja drugacija. Da vidimo ideju pa da nastavimo.

Imam utisak da si zamislio kako zelis da forma za unos izgleda pa pokusavas da napravis bazu (tabele) na osnovu toga. To je pogresan redosled stvari.

Možda može da ima temp tabelu sa onoliko polja koliko mu treba, a posle potvrde izmena da to sljušti u drugu tabelu koja bi bila normalizovana.
Video sam da niko nije pominjao ColumnHidden svojstvo, možda će to biti korisno u datasheet formi.

I da se odgovorim ničim izazvan na Zidarev komentar S ovim se ne bih složio jer su korisnici ti koji zamišljaju kako će nešto da izgleda, na nama programerima je da mozgamo kako ćemo to da ostvarimo.

Ajd' i ja ničim izazvan.
Slažem se da korisnici treba da učestvuju u izradi projekta od početka do kraja. Njih kao eksperte za određeni domen intervjuišemo u vezi poslovnog problema, konsultujemo oko nejasnih činjenica i slušamo u vezi izgleda formi i izveštaja. Kada je model podataka u pitanju, mislim da treba da se osllanjamo na svoje iskustvo potkrepljeno svim pravilima teorije baze podataka. Projekovanje modela je vrlo važna stvar. Kao temelji na zgradi. Ukoliko bi dozvolili da nam se u taj deo mešaju korisnici, "zgrada" bi mogla da se sruši. Konkretno u ovom slučaju je dodatni problem što su projektant i korisnik jedno lice i Zidar je u pravu kad kaže da se na osnovu izgleda zamišljene forme ne može praviti baza podataka (tabele).
I opet da podržim korisnike. Treba im pridavati značaj u celosti i dozvoliti da se osećaju bitni. Tako će lakše prihvatiti konačno rešenje jer će ono postati deo njih samih. I na kraju, oni nas plaćaju.

O tome nisam razmisljao i nemam iskustva. Ako mozes, napravi primer da vidimo.

Ja razumem da je ponekad za korisnika veoma prirodno da se podaci unose horizontalno a ne vertikalno. Koliko bi trebalo da ima kolona? 5 ili 25 ili 100? Sta ce biti kad broj kolona bude toliki da se ne mogu sve videti odjednom pa mora dea se skroluje u stranu? Kolika je verovatnioca da ce nesto otkazati u procesu prebacivanja iz nenormalizovane temp tabele u nekakvu normalizovanu? Koliko je tesko i podlozno greskama stalno podatke prebacivati iz jednog oblike u drugi? Sa 20 racunara u mrezi u fabrickoj hali koji otvaraju i zatvaraju rekordsete kao ludi? Ovde je fabrika u pitanju, ne kancelarija. Ko ce toliki komplikovani proces da osmisli, isprogramira bez greske i istestira?

Suvise pitanja na koje ja nemam dobar odgovor. Ako neko ima - bujrum - sto kazali bosanci. ja sam preneo svoje sikustve.

Sto se tice uticaja korisnika na "kako ce nesto da izgleda" to je veoma slicno uticaju pacijenta na lekara kad prepisuje lekove. U ovom konkretnom slucaju niko korisnike (radnike) nista i ne pita (greska, to ce se videti kad aplikacija dodje radnicima u ruke prvi put, kad udje u produkciju). Ovde imamo ideju koju ima programer i nazalost ideja nije bas sjajna - da se koristi tabela sa mnogo kolona od kojih ce samo neke biti popunjene, a o tome ce da brine aplikacija koju programer ne ume da napravi. Nije sramota ne umeti tako nesto napraviti. Jos nisam video da je neko napravio kako treba pa ne vidim zasto bi bas sada neko to uspeo. Ponovo, mozda neko ume to da napravi, ali se jos nije javio.

Svaki dan gledam rezultate rada po principu 'programeri napravili sve kako je korisnik trazio' pa kad ne radi kako treba, oni (programeri) podnesu papir na kome se vidi da je korisnik bas to trazio. Onda bude "Da, tako pise, ali ja to nisam mislio tako..." Posto je korisnik uvek u pravu, ali i ugovor ima snagu, pare su isplacene a firma koja je radila sistem je izgubila posao. Neko ce reci 'ako se zoves IBM i naplatis nekoliko miliona, sta te briga sto si izgubio posao'. Pa, mogao si da naplatis jos mnogo puta po par miliona kod istog klijenta. A u ex YU uslovima tesko je naplatiti i ono sto dobro radi, a kamoli nesto sto nece raditi. U svakom slucaju gubis.

Posao programera je da napravi sistem koji ce da zavrsi posao korisniku. Kazana recenica se razlikuje od 'posao programera je da napravi da program izgleda kako korisnik hoce'. Ako korisnik zhateva glupost, ne treba raditi. Ako ti se cini da je glupost, onda ili stvarno jeste glupost ili ti nesto debelo ne razumes o zadatku. U oba slucaja tvoja reputacija (i buducnost) je na kocki.

Evo okačio sam najprostiji primer svoje zamisli, predviđen samo za jedan red u podformi, može se modifikovati po potrebi, ali pošto nisam siguran da sam na pravom putu da se ne mučim previše Mislim da za dobrog programera ne postoje nemogući zadaci, postoje samo nelogični.

@ domaci_a_nas
Kad god nisam imao rešenje za neki jednokratni problem koristio sam (a i danas to radim) privremenu tabelu. U najvećem broju slučajeva, naknadno bih ustanovio da mi model nije baš najbolji i da sam mogao na ovaj ili onaj način, boljim modeliranjem, da izbegnem pojavu tog jednokratnog problema. Ti si toga dakako svestan i ovaj primer je nastao u želji da izađeš u susret korisniku, a ne zato što ti neznaš da izmodeliraš bazu podataka. Samo je pitanje u kolikoj meri ćeš kao projektatnt-programer, uspeti da mu nametneš svoj pristup i eskiviraš neki njegov zahtev koji prkosi normalizaciji tabela i najčešće se svede na to budu zapisi kao u tvojoj privremenoj.

Moja osnovna zamerka bi bila, više korisniku nego tebi: Šta ako posle
.....cipele, patike, košulje, jakne, rukavice, kape, suknje, trenerke, čarape,
treba dodati :
....kaputi, šalovi, marame, pantalone, sakoi, kajševi, donji veš, podkošulje, majice, prsluci, spavaćice.....

Neću više, a i mrzi me da otvaram ormane. Predpostavljam da sam već iznervirao tvog korisnika koji mora da skroluje u desno. Ne daj bože da fabrika proširi asortiman proizvodnje i osim odevnih predmeta, počne u drugom pogonu da proizvodi sredstva za ličnu higijenu i kozmetiku.
Mada, kad malo bolje razmislim, ako taj korisnik ima moć plaćanja i želju da poveća bonus za 100%......Ko zna?

Oko dugmeta za sakrivanje. Konkretno „ Sakrij Kape“. Form View Datasheet ima ugrađenu mogućnost da sakriva kolone na desni klik tastera: Hide i Unhide Columns. Zato predlažem u cilju smanjenja broja dugmadi i dodatnog VBA koda ovu soluciju.
Inače, ja sam od onih koji voli da vidi parče dobrog VBA koda (a u tvojim postovima sam imao prilike), pogotovo kada nemam bolje rešenje.

@Getsbi
Dugme sakrij kape je više primer za kolegu xl_kid da vidi kako može programski da izmeni broj polja koja će da prikaže. Korisnicima bi mogla da se napravi tabela sa 100 polja (ja sam imao jednu sa 86 polja ) i samo da mu se da mogućnost da odaberu koliko polja od tih 100 hoće da prikaže, može preko formice i da bira caption za svako polje. To bi se snimalo u strukturi tabele kao Caption property i prikazivalo u subformi ako ostane datasheet, a ukoliko bi izmenio da bude continuous forms, morao bi programski da čita.

Argument da je skrolovanje zamorno treba iskoristiti pre ugovaranja posla, a kada korisnik dobije tačno ono što želi, izmene treba da plati.

Ah, da, zaboravio sam da živimo u Srbiji

Postovani Zidar,

upravo zbog vaseg znanja i umeca (svih vas na ovom forumu) sam potrazio pomoc bas ovde. Kao sto je neko od vas rekao ja ne znam da resim problem, znam nesto malo o access-u ali nisam bas ni pocetnik (mozda stepen vise :)). Od vas nisam trazio da se strogo pridrzavate onog sto sam trazio. Hvala ti na savetima i predlozima to mi stvarno puno znaci, mislim hvala svim vama.

Vratimo se problemu, sto se tice broja strana, mislim da se zove recordset (otvaranje novog zapisa "new record") u tvom primeru je to nova kutija. Nazalost primer jos nemam, kao sto sam rekao imam samo zamisao kako bih hteo da bude ali ne znaci i da mora tako kao sto si rekao. Pokusacu da ponovo i opsirnije objasnim proces pakovanja. Recimo nalog A999 (kosulja model xy) je izradjen u kolicini od 1000 komada i to je jedini nalog u tom procesu proizvodnje jer se nalozi pakuju jedan za drugim. Od te kolicine 500 komada je namenjeno maloprodaji (nasa radnje) a ostalih 500 kupcima i to 100 komada kupac A, 100 komada kupac B, 200 komada kupac C i 100 komada kupac D. Na osnovu takve specifikacije radnik odvaja robu i pakuje je u kutije. U kutiji staju izmedju 5 i 20 komada zavisno da li je kosulja, u ovom slucaju, upakovana u kesi ili kutiji tako da niz o kome ste pricali ne prelazi 25 polja (ako se pre i posle polja namenjenih za kosulje ubace i broj kutije i kupac) sto je mogu se sloziti sa vama mnogo ali 99% naloga se pakuje u kutijama od 10 komada. Mislim da je domaci_a_nas skoro resio moj problem, to je ono sto sam hteo. Ostalo je samo da se u subformi dozvoli unos novog rekorda a da kljuc bude broj kutije.

Primer
BrojKutije Sifra1 Sifra2 Sifra3 Sifra4 Sifra5 Kupac
1 1111 1111 2222 2222 3333 C
2 1111 2222 2222 3333 4444 C

Posle svih vasih sugestija ste me na kraju zbunili pa vise nisam siguran da li je moja zamisao za ovakvom aplikacijom ispravna i izvodljiva. Posto ste mi pomogli da uvidim problem niza nadam se da cete mi pomoci kako da resim problem. Mozda ce vam proces pakovanja koji sam gore opisao pomoci oko toga.

domaci_a_nas, da su vlasnici firme hteli da plate ja bih vam se obratio za izradu aplikacije i pronalazenje problema. Na zalost ovako je problem pao na moja ledja pa se ja moram ganjati oko izrade aplikacije. Pokusacu da bar izvucem koju kosulju da vam na kraju posaljem. Ipak, dosta ste mi pomogli i savetima. Potrudicu se, da na kraju barem posaljem poklon. Nadam se da ce vlasnici imati razumevanja. Meni je stvarno neprijatno da trazim usluge koje nemogu platiti tako da preostaje samo vasa dobra volja.

xl_kid, pre jedno godinu dana bio sam u civilnoj "vojsci". Došle su neke simpatične čikice iz privatne firme koja sarađuje sa školom u kojoj sam služio vojni rok i predložile mi da napravim bazu koja bi se koristila u školi, a u čijoj izradi bi mi oni pomogli. Ja rekoh, "nema problema". Posle mesec dana to još nije bilo gotovo, te ovako ćemo, te onako ćemo, a ja sam se pitao što lepo nisam rekao NE ZNAM, NE UMEM ???

Čini mi se da si i ti napravio istu grešku Ja sam pričao uopšteno o naplati svog rada. Nema potrebe da se izvinjavaš niti da šalješ košulje (nosim broj 46 btw), uostalom, kroz razmenu iskustava i ideja svaki učesnik na temi ponešto nauči. Meni lično je zadovoljstvo da nekome pomognem ako to ne iziskuje mnogo vremena, pošto ga zaista nemam, tako da mi je promaklo da radiš u toj firmi. Dugačke postove bez pasusa nekako nemam strpljenja da čitam, ali to je samo moja lenjost

Postavlja se pitanje ko je vlasnik tog softvera ?

Softver ne postoji tj imamo knjigovodstveni softver firme Absoft koji ce biti promenjen do kraja godine. Sad, sve sto ja hocu je, da se ponovim jos jednom, da olaksam posao sebi u izradi specifikacija spakovane robe i radnicima koju pakuju robu jer oni bukvalno pisu na papiru sta su spakovali a ja nakon toga rucno unosim podatke.

ps. mozda ce vam pomoci ova aplikacija koju koristim za specifikacije

Nicm izazvan, opet ja. Sada imamo pred sobom opis poslovnog procesa, bolji nego na pocetku.


Ovo moze da se napise ovako:
1) Kosulje se proizvode na osnovu radnog naloga.
2) Radni nalog definise koje kosulje ce se proizvseti, u kojoj velicini, dezenu i koliko ce se proizvesti.
3) Kosulje proizvedene po datom radnom nalogu se dele na maloprodaju i odredjen broj kupaca.
4) Da bi radnik koji pakuje kosulje znao sta treba da radi, sastavlja se Specifikacija pakovanja.
5) Specifikacija pakovanja kazuje raniku koliko koliko kosulja da spakuje ida usmeri na odrejeno masto (maloprodaja, kupac A, kupac B..)

Onda znamo i ovo:

Proizilazi da sada, pre izrade softvera, radnici spakuju robu u kutije, zapisu na papir pam onda xl_kid to unese u bazu podataka. Nesto nedostaje. Kako radnici znaju sta da spakuju i gde? Ako xl_kid unosi podatke pole pakovanja, to je naka vrsta otpremnice. Gde je dakle dokument koji kazuje radnicima sta i gde treba da spakuju?

Videli smo i bazu podataka koja se koristi i za koju treba napraviti program. Da li je baza koja je ponudjena ispravno modelira opisani problem? meni deluje da tu ima mesta za poboljsanje. I bas kako sam rekao, zamisljena je forma, pa je na osnovu forme napravljen model baze podataka. Pogresan redosled stvari. Predlazem da xl_kid provede malo vremena na doradi modela baze podataka i da se ne opterecuje izgledom forme u ovom momentu. Previse je rano za forme i aplikaciju.

Da ne bude da sam zloban starac, postavicu svoju verziju sakrivanja suvisnih polja. domaci_a_nas je dao jednu dobru ideju za takav zadataak, probacemo i nesto drugo. S anpomenom 'ne preporucuje se za praksu, iako je dobro za vezbanje programiranja, ako bas zaista mora'

:-)

Evo primer kako moze promenljiv boj kolona na formi da se dobije. Jos jednom, ne preporucujem da se to uradi u ovom slucaju. Iam mnogo rupa koje se na prvi pogled ne vide. I dalje stoji komentar o dizajnu tabela i relacija - nedovoljno dobro, prerano za forme.

Da Zidar, to je tacan prosec. Sto se tice pakovanja, kupci unapred poruce odredjeni broj kosulja tako da radnici pakuju na osnovu te porudzbine (recimo da su porucili 55 komada nekog modela, radnik na osnovu te porudzbine pakuje tih 55 komada. Nema nikakav drugi nacin odvajanja ili pakovanja, ako u kutiji staju 5, 6 ili 8 komada kosulja on ce ih tako pakovati i sve to upisati na papir i dostaviti meni pa tek onda je to unosim u pomenutu bazu, koju, slazem se s tobom, treba prepraviti.). 'ajde jedno pitanjce, sta predlazes da promenim kako bih je poboljsao? Problem mi trenutno pravi kada hocu da vidim sta je otpremljeno a st ostalo. Trenutno taj problem resavam tako sto cekiram svako polje u tabeli kada roba ode. Moram ti priznati da je veoma smorno ali mi je to bilo trenutno resenje koje sam "morao" uraditi. Da napomenem da nemam informaciju kada sta ide. Recimo da se u magacinu nalaze 5 gotovih naloga za kupca XY a mi isporucimo samo 3 i nema unapred utvrdjeno pravilo sta ide kako i kog datuma, uglavnom ide sve sto je spakovano ali se ponekad desi pomenuti problem. I jos jednom za kraj, posto ne predlazes skrivanje polja kao resenje (u svakom slucaju znas bolje no ja) sta mi je ciniti? Izgled forme mi stvarno nije bitan, bitno je da radi svoj posao.

Vec nekoliko dana ponavljam jednu recenicu iz domace serije "MIS'IM NEMO' SE LJUTIS ...." :-)
XL_KID ali moram nesto da ti kazem :

Na ovom forumu ima veliki broj ljudi koji su bili u tvojoj situaciji, i dobro znaju sta znaci necija pomoc. Kada sam ja pocinjao sa Access-om Interneta nije bilo (ili ja ga nisam imao), to su bile muke. Medjutim, upravo ta cinjenica je meni i verovatno drugima pomogla da stvorimo sistem razmisljanja kako da resimo problem na pravi nacin. Negde smo gresili a neke od tih principa i danas koristimo.

Koliko sam razumeo ti si NESTO ZAMISLIO i pokusavas da to ostvaris, a da li si se pitao da li je to ISPRAVNO razmisljanje ? Sta bi tek radio da ti je to neko nametnuo ? Nekada ne treba praviti KOMPROMISE ni po koju cenu (a ovde para jos i nema :) )

Pokusavam biranim recima da ti kazem da se vratis na pocetak, procitaj neku knjigu, POGLEDAJ primere Accessovih programa, googlaj i stvorices sasvim drugu sliku u glavi, veruj mi. ISKUSTVO je ono sto ti nedostaje a ako negde zapnes mi smo tu.

Pozdrav.

"MIS'IM NEMO' SE LJUTIS ...." :-) ... Ja sam sin Dragan i tko me zovu :)...

Zbog toga sam i ja ovde da pitam prave ljude za pomoc, misljenje, savet... Za ovih par dana sam dobio dosta odgovora koji su mi i koji mi pomazu da malko drugacije gledam na problematiku. Kao sto rece nemam iskustva.

OK, ovo smo culi dva puta

Sad pocinjem da shvatam da je problem pratiti sta je naruceno i sta je isporuceno zbog

Pocetna ideja za proces nije losa:
1. radnik dobije nalog za pakovanje (koji sledi iz porudzbenice)
2. radnik uzima praznu kutiju i u nju stavlja kosulje, dok se kutija ne napuni
3. radnik skenira barkod sa svake kosulje, na taj nacin se broje kosulje
Bar kod na kutijama nije ejdinstven za svaku kosulju, ali pokazuje koja vrsta kosulje je u pitanju
Isto kao sto se u samousluzi na kasi svaka od pet istih cokolada skenira zasebno.
4. Aako se kutija napunijla a ima jos kosulja za pakovanje, nazad na korak2, inace idi na korak 5
5. odstampa se "Otpremnica" - izvestaj na kome se zilistaju sve kutije, napise se koliko kojih kosulja je u kojoj kutiji i na dnu napravi rekapitulacija po vrsti kosulje za ovaj nalog za pakovanje

6. Onda ce neka kontrola da uporedi porudzbenicu i izvestaj sa naloga za pakovanje.

Zavisno od narucene kolicine, moze biti i vise od jednog naloga za pakovanje po istoj porudzbini. Ako neko naruci 10 kosulja vrste A, to ce verovatno biti isporuuceno odmah, jer verovatno to imate na lageru. Medjutim, ako neko naruci 10,000 kosulja vrste A i 12,000 kosulaj vrste B a vi na lageru imate samo po 5,000 od svake vrste, verovatno cete spakovati sta ima a ostatak kasnije. Iz ovoga sledi da u svakom momentu mozete odgovoriti na pitanja tipa "koja porudzbina jos nije pokrivena","koliko jos treba poslati kojih kosulja da bi se pokrile nezavrsene porudzbine", "koje su porudzbine pokrivene i treba ih zakljucati - spreciti dalje pakovanje i slanje"

Iz cele price sledi da mora postojati skup tabela koje prate porudzbine. Koje narucio i sta je narucio. To je klasican Ordering System, kakav imas i u Northwind bazi. Isto tako moza postojati skup tabela koje prate sta je spakovano i otpremljeno. Nalog z apakovanje je parce papira na kome psie sta je kupac porucio u datoj porudzbenici. Posto nikakva nova informacija nije dodata, ne treba nikakva tabela za "nalog za pakovanje". Za svaki nalog za pakovanje treba da postoji jedna ili vise otpremnica. Svaka otpremnica poktriva nekoliku kutija, a svaka kutija ima u sebi odredjen broj artikala (kosulja). Ovo su ti sve veze 1 : vise. Sve veze 1: vise se pretvaraju u dve tabele, otprilike ovako:

Porudzbenica (PorID, Kupac, Datum)
StavkePorudzbenice (PorID, ArtiklBarkod, Kolicina)

Otpremnica (OtpremnicaID, PorID, Datum)
Kutije (OtpremnciaID, KutijaUniqueID, VrstaKutije)
VrsteKutije (VrstaKutije, MaxBrojArtikala)
SadrzajKutije (KutiajUniqueID, ArtiklBarkod)

Sve tabele 1:vise se pretvaraju u (Forma, subforma) kombinaciju.

Uoci da sam stavio u tabeli Kutije KutijeUniqueID - svaka kutija koja se koristi za pakovanje MORA da ima jedinstven identifikator. Seti se mog predloga na pocetku da se na kutije nalepe nalepnice. Nalepnice kostaju, ali ne bas tako mnogo. Ako su kutije jedinstveno oznacene, enkakvim barkodom na nalepnici, onda takva kutije moze da se seknira tokom zivota. pri put se kutija skenira kad se dodeli otpremnici. Kad se zavrsi pakovanje, kutije verovatno odlaze negde gde cekaju utovar u kamion. Skeniraju se kad napuste pakovanje ili kad se zatvore. Time smo dobili vremenski interval izmedju dodeljivanaj kutije otpremnici i zatvaranaja (kraj pakovanja). Onda se skeniraju kad zatvorene stignu u magacin gde cekaju transport. Pa se jos jednom skeniraju kad se utovare u kamion. tako znamo kad je koja kutija utovarena na koji kamion. Kad kuopac dobije kutije, on potpise prijemnicu - na primenici su izliztane kutije koje kupac treba da dobije u toj isporuci. Potpisanu prijemnicu zadrzava sofer/kurir i to se vraca onome ko je poslao kutiju. tako on ima dokaz sta je stiglo do kupca. Za svako to skeniranej potreban je mala aplikacija koje radi samo to - skenira barkod i ubacuje rekord u nekakvu tabelu.

Tvoj sistem bi dakle trebao da ima puno nezavisnih aplikacija koje sve upisuju ili citaju podatke iz jedne iste baze podataka. A sve je to moguce ako i samo ako kutije imaju jedinstven identifikator - nalepnicu i bar kod. Za pocetak, treba ti baza i aplikacija koja ce da sakuplja podatke u procesu pakovanja. To ce biti najkomplikovanija aplikacija, sve ostale su lakse. I treba jedna za uvid u sistem, koju ce da vrte sefovi i direktori. Naravno, treba i jedna za belesenje poruzdbina koje ostave kupci.

Posla koliko hoces. Cak i ako pomislis da ti sve ovo ne treba i uradis samo neki delic, i taj delic proradi, ubrzo ce ti traziti jos. Zato je bolje da imas celu sliku na pocetku.

Na kraju, ovo nije posao za pocetnike ili amatere. bar jedan od ova dva uslova je neophodan:
a) visok noivo programerskog znanja (Trtko, Getsbi, domaci_a_nas)
b) inzinjersko znanje i iskustvo u oragnizobanju im pracenju proizvodnje (inzenjer - tehnolog, organizator proizvodnje)

Ako se ima samo jedan od ova dva zahteva, bolje je da bude onaj drugi - inzenjersko zannje. U tom slucaju se zahtev moze preneti nekom ko poseduje dovoljno programerskog znanja, ili covek sam moze da nauci sta mu treba. Ako ubacis geniaj programere koji ne zna puno o procesu, nakraju je vrlo verovatno da ces dobiti program koji radi bez greske, ali ne radi ono sto kompaniji zaista treba. Naravno, uvek postoji razlike izmedju "sta kompaniji zaista traeba" i "sta su oni meni dali u projektnom zadatku". I uvek ce progranmer biti kriv, sak i ako projetni zadatk nije dobar. Tvoj posao je da sa korisnikom dodjes do korektnog projektnog zadatka. Nijedan korisnik ti ne moze dati korektan projekltni zadatk, to je zajednicki napor u kme programer iam vecu odgovornost od korisnika.

Pa sad vidi sta ces.

Vidim da se drug Zidar lepo proveo sinoć bar bi se reklo po sledećim primerima

ejdinstven, napunijla, enkakvim, skeniranej, noivo, poktriva, moza (može), traeba, projetni zadatk, projekltni zadatk...

Baš sam mućak ? Šala mala, nadam se da mi Zidar neće zameriti, znam da nema vremena da pregleda toliko obiman post. Ja sam prvobitno hteo samo da se zahvalim na lepim rečima kolegi i da dopunim sledeću rečenicu sa njegovim imenom Možda bi bilo bolje da sam ostao pri tome, ali šta ću kad volim malčice da peckam ljude, nadam se da nisam preterao

Kamo sreće ali bar znam da mi misliš dobro

Zidar, shvatio si u potpunosti kako to funkcionise. Proces je upravo onakav kako si ga opisao. Nazalost, neverujem da mogu obezbediti sredstva za ovaj projekat pa cu morati sam da pokusam da izgradim bazu sa savetima koje ste mi, svi a posebno ti, dali. Jos jednom, hvala svima.

Zidar, ako podjem od tvog primera, kako da sumiram kolicinu spakovane robe u kutijama. Treba mi suma po KosuljaID u tvom primeru. Dodelio sam jos jedno polje koje se pojavljuje posle "KosuljaID" i koje ima default value 1 sto bi odgovaralo broju komada (u ovom slucaju svaki kod tj KosuljaID ima vrednost 1). Polje "KosuljaID" treba da bude text zbog bar kodova koji u sebi sadrze alfanumericke oznake a ne samo numericke. Mozda idem u pogresnom pravcu oko sumiranja i sacinjavanja otpremnica pa rekoh da te priupitam. I da li je moguce da formu sa subformom koju si uradio povezem sa jos jednom formom zbog broja komada u kutiji da smanjim unos tog polja vec da ga povezem sa nalogom?

Resio sam problem sumiranja. U upitu sam izbacio polja "BrojacRekorda" i "DateCreated" a preostala kombinovao i dobio potrebne upite. Probacu sada da napravim tabelu "ProizvodID" koja ce sadrzati kompletan opis sifre (artikal, dezen, velicina i RN) kako bih dobio paking listu.

Da li je moguce da, umesto u upitu, se vrsi sumiranje u samoj tabeli. U prilogu je tabela u kojoj zelim sumirati cetiri polja (polje ProizvodID=Artikal+Dezen+SifraVelicine+RadniNalog). Sve ovo je moguce uraditi u upitu ali me zanima da li je moguce uraditi i u samoj tabeli.

Mislim da si zapoceo nesto sto je mnoooogo iznad tvojih mogucnosti. Nisu u pitanju sredstav aza projekat, u pitanju je razumevanje i znanje. Cini mi se da ni jedno ni drugo nisu gde treba da budu. Drugim recima, u ovom momentu je rano da se uhvatis u kostac sa jednim ovakvim projektom.

Nasi saveti ti nece pomoci, samo ce ti dati laznu poruku da si kao nesto razumeo i da je to lako. Pusti sumiranje u tabeli i van nje. Ako mozes, pokusaj da napravis model baze podataka, znas ono, tabele i relacije. Ako si tabelu nazvao tblProizvodID znaci da si upao tesku paniku i samo se saplices. Pokusaj da definise sta je to proizvod i sta bi proizvod ID trebao da predstavlja. Sta je radni nalog i u kavoj su relaciji radni nalozi i proizvodi. Svakako ne onako kako si stavio u poslednjem primeru. Onda na sve dodas kupce, njihove narudzbe, pa kutije, pa same proizvode (kosulje). To sam ti opisao u nekom od prethodnih porujka, i kako sam kazes pogodio sam proces.

Ako sam pogodio proces, onda je sledeci korak da se napravimodel baze podataka - tebele i relacije. Zna se kako se to radi, ima za to i skola i fakultet, to ne mozes da naucis na forumu. kad budes us tanju da taj deo odradis sam, sve ce ici lakse. Za ovakav projekat to je osnovno, dok je specijalno znanje iz programiranja sekundarno.

Proizvod ID predstavlja 12 alfanumerickih simbola za bar kod. (polje ProizvodID=Artikal+Dezen+SifraVelicine+RadniNalog) Znaci da sadrzi sve potrebne podatke.

Ne vredi nam ovo nista. Ovaj barkod dodje na kraju. Ne mozemo nista da uradimo dok ne vidimo celu sliku i sta se hoce. Ja razumem da imas neki konkretan problem koji zelis da resis i da te veliki sistem i velika slika ne zanimaju. Medjutim, imamo problem da razumemo sta u stvari zelis i sta je sve u igri. U celoj prici, proces sam opisao ja a ne ti. To nije dobro. Ja sam dao generalnu sliku i maa bas svaki proces se moze opisati na taj nacin. To nije dovoljno. Da bi resio jedan problem, u ovom slucaju moras da razumes celu sliku. Ako nista drugo, da bi razumeo sta je ulaz u proces a sta izlaz. U tom slucaju tvoj posao je samo da transformises ulaz u izlaz.

Krenuli smo od pitanja kako na formu postaviti promenljiv broj kontrola, pa smo videli da to ne valja. Sad opet stalno gledamo neke detalje nezavisno od cele slike. Ovakav posao mora da se pocne od velike slike, koja prikazuje veliki proces. Kako se kreira radni nalog? Na osnovu cga se prave artikli? da li tek kad stigne nalog ili evc psotoje u nekom magacinu pa se odande uzmu i stave u kutije? sta se desava sa kutijama kad se napune? Koji se dokumenti zahtevaju u procesu? Koji dokumenti ulaze u proces (radni nalog?) a koji izlaze (otpremnica? paking lista? kakva je razlika? za svaku kutiju? za ceo nalog? za jednu posiljku? koliko posiljki po nalogu?)

Nemoj da dajes odgovore na nabrojana pitanaj jedno po jedno, ja sam ih samo nabacao. Odgovori trebaju tebi, ne meni. Treba ti (nam) cela slika i da se u celoj slici onda vidi detalj koji pokusavas da resis.

I jos jednom - nam sanse da se ovakva aplikacija napravi na forumu. Ne zato sto nek nece nego zato sto je nemoguce. Za ovo treba tesna saradnja pogonskog inzenjera/tehnologa i onga ko pravi aplikaciju. Ako ovo radis potpuno sam i nikoga drugog u fabrici nije briga za ovo, onda nema sanse da se ista uradi uopste. Zaboravi celu stvar. Jednostavno, takva je priroda ovakvih sistema.

'Ajde za kraj da ti opisem ceo postupak (ako zbog niceg drugog do iz razloga da nisam neupucen u ovaj proces ili da sve ovo radim zarad dokazivanja nekome). Jedino si upravu kada si rekao da u fabrici nikoga nije briga ali ja prosto nezelim da jednu stvar upisujem po par puta i povrh svega ostajem prekovremeno kada bude isporuka robe kako bih sacekao da oni popakuju robu pa tek onda ja radio papire. Nije tacno da si opisao proces, rekao sam da si pogodio prosec. Mozda ga nisam bas najbolje opisao, priznajem, ali valjda vidim sta se i kako radi u fabrici u kojoj sam. No vratimo se procesu, iz kreativnog tima (dizajneri, modelari i ostali koji se bave izradom samog modela, za ovu pricu nebito*1) dobijamo nalog za izradu modela (koji su ranije kreirali) i dodeli mu broj naloga, ime modela i artikal. Znaci da te podatke vec dobijamo kao i kolicine koje bi trebalo uraditi u vec odredjenim dezenima. Kazem trebalo jer se desava da se iskroji manji broj komada od broja u radnom nalogu. Broj iskrojenih komada tj ta informacija se salje kreativnom timu i prodajnom timu. Iz ovog dokumenta "Iskrojene Kolicine" se izradjuju male nalepnice (dve vrste) koje se lepe na visecoj etiketi jedne i pakovanju druge (pakovanje moze biti kesa ili kutija za kosulju). Preskocio sam proizvodnju jer u tom delu procesa nema korisnih informacija. Kada roba dodje u doradi (pogon gde se kosulje peglaju i pakuju) dobijamo informaciju o tome koliko kosulja (upakovanih) se pakuje u transportne kutije i na osnovu toga izradjuju nalepnice za transportne kutije*2. Ovaj postupak je u slucaju kada ceo nalog ide za nasu maloprodaju. U slucaju da deo naloga ide za kupce postupak je sledeci*3. Male nalepnice su iste, bez obzira da li roba ide i kupcima ili je namenjena samo nasoj maloprodaji. Pre nego udje nalog u proizvodnju imamo unapred odredjenu kolicinu koja ide kupcima koji su ranije napravili porudzbinu*4. Znaci od radnog naloga W999, model Donna, artikal 999 ide (da ne nabrajam dezene i velicine) 15 komada kupcu "A", 25 komada kupcu "B"... Ostatak naloga (uglavnom to bude oko polovine) ide nasoj maloprodaji. Znaci da se roba odvaja tj pakuje po porudzbenici koju su dostavili kupci. Izuzetak predstavlja kada je iskrojena kolicina manja od porucene pa se onda ne moze ispostovati porucena kolicina (prim. svi kupci su porucili 10 komada odredjenog modela u velicini XXL a iskrojeno je 5, znaci da ce biti uskraceni za 5 komada). Kada se napune, kutije idu u magacin i cekaju na isporuku.
Na kraju dana radnik koji radi na pakovanju dostavlja magacioneru sta je spakovano u toku tog dana (ukupno) a meni dostavlja sta je spakovano za kupce (dva puta upisuje jednu istu stvar, skoro dva puta jer je se ukupna kolicina razlikuje od kolicine koju su porucili kupci). U ovom delu se javlja problem koji zelim resiti. U procesu ulazi radni nalog u kome su sve potrebne informacije vezane za izradu a izlazi otpremnica i paking lista. Razlika izmedju otpremnice i paking liste je sledeca, otpremnica sadrzi ukupnu kolicinu po nalogu, dezenu i velicini (prim. RN W999, dezen 999 10 komada velicina M, 5 komada velicina L,...) a paking lista sadrzi podatke o tome sta je spakovano u odredjenoj kutiji (prim. kutija br 10: RN W999, dezen 999, velicina M 3 komada, velicina L 2 komada. Broj posiljki je N, tj nepoznati broj. Roba se ne salje ako nalog nije zavrsen do kraja bez obzira sto je deo naloga vec spakovan u magacin. Sada se vracem radnim obavezama. Nadam se da sam pojasnio proces.


*1 - izrada modela tj uzorka po kome ce se odredjeni model izradjivati
*2 - transportne kutije mogu sadrzati on 5 do 20 upakuvanih kosulja u zavisnosti od pakovanja
*3 - od modela koje je ranije izradio kreativni tim, uzoraka, imamo prezentaciju na kojoj se kupci (veleprodaja) odlucuju sta ce kupiti
*4 - u momentu prezentacije imamo samo model, artikal i dezene ali ne i broj radnog naloga koji se kasnije dodeljuje od zavisnosti kada je nalog planiran za izradu (broj naloga dodeljuje kreativni tim).

Pozdrav,

[Quote]'Ajde za kraj da ti opisem ceo postupak (ako zbog niceg drugog do iz razloga da nisam neupucen u ovaj proces ili da sve ovo radim zarad dokazivanja nekome).[/quote]
Ne radi se o dokazivanju. Ti znas postupak (proces). Mi na ovoj strani ga ne znamo. Posto ne znamo psotupak dovoljno detaljno, mozes dobiti samo generalne savete, koji mogu a li i ne moraju da budu dobri, jer ne uzimaju sve cinjenice (detalje)u obzir.

Dalje, postupak se opisuje na pocetku projekta, a ne pred kraj. ne mozes da ocekujes da mi na ovoj strani znamo tacno tvoj proces. Ako ga ne znamo, kako cemo ti pomoci? Dakle, ovo je trebalo uraditi na pocetku. I zbog tebe, i zbog nas.


Potpuno te razumem ali ne znam jos uvek da li i koliko mogu da pomognem. Da probamo.



Ovo nas vraca na pocetak, na moj prvi odgovor i zakacenu bazu koja ti se nije dopala:
1) Radnik zna da radi po nekom radnom nalogu - trabe forma frmRadniNalog
2) Radnik dodeljuje kutiju nalogu (unosi u bazu jedinstveni identifikator kutije (skenira neki barkod nalepljen na kutiju) ) - subforma frmTransportneKutije, na formi frmRadniNalog
3) Radnik obezbedjuje informaciju o tome sta je gde spakovao. Postoje dva nacina: a) Kutiji se dodeljuju kosulje tako sto se skenira nalepnica na kosulji - forma frmTransportnaKutija kao glavna forma i subforma ArtikliUTransportnojKutiji. U subformu radnik skenira svaku kosulju koju stavlja u kutiju. i 2) radnik samo upis kolicinu u svakoj kutiji. Pretpostavka je da su u svakoj kutiji svi artikli ist (istimodel, isti dezen, velicina)

Za ovo ti trebaju sledece tabele:
Radni nalog - dve tabele
RadniNalog (BrNaloga, Model, Datum)
StavkeRadnogNAloga(BrNaloga, Dezen, KolicinaDaSeProizvede, StvarnoProizvedenaKolicina)

StvarnoProizvedenaKolicina bice poznata kad proizvodnja dostavi zivestaj "Iskrojene Kolicine"

Primer:
RadniNalog: (BrNaloga=1, Model = 'Dona', Datum = '4 Juni 2008')

StavkeRadnognaloga - pre proizvodnje:
Brnaloga Dezen KolicinaDaSeProizvede StvarnoProizvedenaKolicina
--------------------------------------------------------------
1 plava 20 0
1 zelena 30 0
1 zuta 50 0

StavkeRadnognaloga - Posle proizvodnje:
Brnaloga Dezen KolicinaDaSeProizvede StvarnoProizvedenaKolicina
--------------------------------------------------------------
1 plava 20 20
1 zelena 30 30
1 zuta 50 40


Porudzbine (sta su kupci porucili, kako ce se rasporediti ono sto je proizvedeno):
Porudzbine (BrNaloga, Dezen, Kupac, Kolicina)

Maloprodaja je jedan speciajalan kupac.
Zbir kolicina po (BrNaloga,Dezen) u tabeli Porudzbine ne sme biti veci od zbira KolicinaDaSeProizvede. To moras ua plikaciji da obebedis ili onaj ko sastavlja

Primer tabele Porudzbine:
BrNaloga, Dezen, Kupac, Kolicina
--------------------------------
1 zuta A 5
1 plava A 3
1 zelena C 10
1 zuta C 5
1 plava C 3
1 zelena B 10

Radnik treba da dobije 'Nalog za pakovanje' koji dolazi iz tabele Porudzbine

Za radnika, mora da psotoji tabela TransportneKutije ovako:
(TransportnaKutijaID, BrNaloga, Dezen, Kupac, DatumDodeljivanja)

1) radnik dakle 'otvori radni nalog' (otvori formu radniNalog, sa subformom TransportneKutije)
2) Onda unese jednu ili vise kutija za doticni nalog i zna tacno koja je kutija za kog kupca
3) Onda treba da se dobiju kolicine koje su ubacene u kutiju. To moze na dva nacina:

a) rucno upisivanje - dodamo kolonu za kolicinu u tabelu TransportneKutije:
(TransportnaKutijaID, BrNaloga, Dezen, Kupac, DatumDodeljivanja, UbacenaKolicina)

b) skeniranje - svaka kosulja se skenira (barkod) pre nego sto se ubaci u kutiju, ako u samousluzi roba na kasi
U tom slucaju nam treba jos jedna tabela - ArtikliUTransportnojKutiji. Moze da zigleda ovako:

(TransportnaKutijaID, Artikl, AutoNumber)


Sad ove sve tabele kreiraj u Accessu, i probaj da odradis ceo proces - da rucno, bez formi, uneses podatke gde treba u kom koraku. To ce ti pokazati da li je model baze podataka (tabele) dovoljno dobar - da li se slaze sa stvarnim procesom.

Tek kad utvrdis da tabele zaista prate proces i iams mesta za sve podatke i sve se lapo slaze, onda tek mozemo da razmisljamo kako da napravimo fome. Tada ce to biti mnogo laksi deo posla.

Ako nisi pocetnik u Accessu, trebalo bi da ovo testiranje modela baze podataka mozes da odradis. Ako ti to predstavlja problem, onda neces biti u stanju da odradis ono sto sledi i batali ceo posao. Ako uspes da testiras model baze podataka, postoji sansa da ces moci da odradis sta sledi (forme, izvestaji, skeniranje), ali nije zasigurno.

A ako nikog nije briga za ovaj projekat, razlog vise da odustanes. Ovo je veoma ozbiljna stvar i ne moze se raditi u vakumu. Ne moze se tek tako uneti softver u proizvodni proces. Proizvodni proces ne kontrolises ti nego vlasnik fabrike. bez aktivnog ucesca rukovodstva firme, sve ce propasti. Tacka i to velika.

Toliko od mene.

Hvala, mislim da ce mi ovo pomoci. Kada budem zavrsio poslacu ti da pregledas da vidis da li sam negde zabrljao ako imas vremena.

pozrav,