Warning: A non-numeric value encountered in /home2/icentarb/public_html/icentar/classes/class.permissions.php on line 101

Warning: filesystem::file_put_contents(data/session_del.php): failed to open stream: Permission denied in /home2/icentarb/public_html/icentar/classes/class.filesystem.php on line 142
iCentar » Forum » Racunari i oprema » Programirannje i baze podataka » Access » Baza za skladište

Centar za edukaciju-BiH



Warning: filesize(): stat failed for uploads/topics/Relacije_1.jpg in /home2/icentarb/public_html/icentar/showtopic.php on line 406

Warning: getimagesize(uploads/topics/Relacije_1.jpg): failed to open stream: No such file or directory in /home2/icentarb/public_html/icentar/showtopic.php on line 414

#31 04.04.2011 09:18
zxz Van mreze
Administrator
Registrovan od:03.02.2009
Postovi:10,612


Predmet:Re: Provjera duplog unosa
Citat:
Tako je kako si zaključio.
Prodaja ispisuje otpremnicu, a skladište izdatnicu.
Ja na to ne mogu puno utjecati i to je procedura koja je uvriježena u firmi i ne daju mi da to promjenim.
I ne trebas to mijenjati jer ti pravis app. da olaksas ljudima a ne da ih ucis kako da rade svoj posao.
Citat:
Ja svakako želim slušati savjete, ali uvjek negdje zapnemo ili se ne razumijemo i posao ostane nezavršen.
Ja se ne sjecam da je ostalo nesto sto nisi zavrsio. Bez obzira kako si zahtijevao da to bude.
Druga je stvar sto sam ja primijetio da vecina ne pridaje znacaja pravljenju tabela gdje je i izvor svih problema.
Vidim to i po tome sto se u description skoro nikada ne napise nista. Znaci samo se iz glave po svojoj nekoj ideji naprave tabele.
Nikada skoro niko nije trazio pomoc oko pravljenja tabela i li pak predocio procedure po kojima se radi u firmi za koju zeli napraviti app.
Trazi pomoc tek kda zapne u realizaciji pa se onda krpi.
Getsbi je dao truda te opisao nacin na koji treba pristupiti pravljenju tabela ali malo ko je to i citao.
E sad tvoje tabele:
Ti samo treba da prilagodis svoje tabele ovome sto smo rekli.
Pa idemo redom:
Tvoje tabele tblProdaja i tblProdajaStavke trebale bi da imaju polja koja bi popunjavao referent prodaje. O tome smo se vec usaglasili pa cu ja dati predlog polja a ti dodaj jos polja ako bude trebalo.
Ove dvije tabele bi trebale biti vezane kljucem jedan na vise i i to smo se usaglasili.
tabela tblProdaja:
OrderID --->Primarni kljuc u ovoj tabeli Autonumber
PartnerID--->Sekundarni kljuc od tabele partneri koju vjerovatno imas (Number)
KorisnikID-->Sekundarni kljuc od tabele Korisnici (Number)
DatumNar--->datum kreiranja narudjbe (Mozda se trebalo zvati datum otpremnice ili pak samo datum)
Ovo je vjerovatno datum kreiranja nekog papira koji moze biti narudžba ili otpremnica ili jos nesto)
BrojNar ---->Vjerovarno broj papira (Text 30 karaktera) Po meni ovo polje bi trebalo da nema duplikata. Odnosno da se nesmije dva puta ponoviti isti.Mislim da je i puno 30 karaktera pa eto ti provjeri.

Polja:
ImeDostave
MjestoDostave
PostBrDostave
ZemjaDostave
Telefon
DatumDostave
MethodDostaveID
TrosakDostave

Vjerovatno se radi o dostavi proizvoda i dok ima i datu znaci da se ne upisuje istovremeno kada se i kreira gore navedeni papir.
Po meni ovo bi bila druga tabela koja bi bila vezana 1-1 sa ovom tabelom i po meni fali jos bar polje dostavio.
Ako imamo dostavu mora postojati i dostavljac, kome mi moramo dostaviti papire koji posjeduju sva polja iz obje ove tabele.
PDV-->ovo polje nemoze biti u ovoj tabeli nego u tabeli tblProdajastavke jer pdv se odnosi na stvke a ne na cijelu narudjbu otpremnicu itd..
Rabat--->Moze ostati jer on se moze odnositi na jedan papir mada moze biti i pojedinacno.
Treba provjeriti kako se to radi u preksi.
Dali se daje rabat na otpremnicu ili na stavke zasebno.
Popust----> Popust je po meni isto sto i rabat. Ovo nisam siguran sta se zeli sa ovim poljem ako ga ima na papirima.
Skladiste--->Po meni ni ovo polje nema smisla. Ako se ima vise magacina onda se i roba klasira po magacinima pa u jednom moze biti elektro u drugom masinska itd. referenta se nebi trebalo da tice iz kojeg ce se magacina izuzeti roba.
Jedina stvar koja moze biti a toj je da on verifikuje kojim je magacinima proslijedio svoj papir.
Neznam mozda se u tvom slucaju drugacije radi?
Proknjiženo----< Ni ovo polje ovdje nema smisla. Ako je ovo tabela u kojoj biljezis narudjbe otpremnioce itd. Ni narudjba ni otpremnica se ne knjizi nego izdatnica.
Znaci roba se knjizi na osnovu papira koji potvrdjuje izdavanje robe.

Eto ako imas volje i strpljenja ovako bi to izgledalo kada se generisu polja u bazi.
Naravno da prije toga moras dobro prouciti nacin rada i imati sve papire koji nastaju u toku tog rada.

Sledecu tabelu cu opisati kada se oko ovoga usaglasimo.
Podrška samo putem foruma, jer samo tako i ostali imaju koristi od toga.
↑  ↓

#32 05.04.2011 10:48
pmiroslav Van mreze
Clan
Registrovan od:02.02.2009
Postovi:1,458


Predmet:Re: Provjera duplog unosa
Kao što sam rekao, slažem se sa svim sugestijama koje će mi pomoći da baza dobro radi.
Što se tiče polja u tblProdaja sve je ok. Kako si rekao osim
Citiraj zxz:
[quote] BrojNar ---->Vjerovarno broj papira (Text 30 karaktera) Po meni ovo polje bi trebalo da nema duplikata. Odnosno da se nesmije dva puta ponoviti isti.Mislim da je i puno 30 karaktera pa eto ti provjeri.

BrojNar = broj narudžbenice koju je poslao kupac. Ovo polje može i ne mora biti popunjeno, a mogući su i duplikati jer postoji mogućnost da narudžbenice od različitih izvora imaju isti broj.

Polja:
ImeDostave, MjestoDostave itd su tu zbog toga što se račun dostavlja jednoj firmi (PartnerID), a roba se dostavlje drugoj (ImeDostave)

Također u bazi več imam tablice za Dostavljača i način dostave.

Polje PDV nalazi mi se u tablici prodaja zato što je to jedinstven podatak ne treba ga posebno upisivati za svaku stavku. Iznos svih stavki u otpremnici se zbroji i zatim se pomnoži sa postotkom PDV-a (porez na dodanu vrijednost)

ControlSource=CLng([iznos]*[PDV]*100)/100

Slična je stvar za Rabat koji je za sve stavke na jednoj otpremnici isti.

Imam formu frmOtpremnica i na njoj subformu frmOtpremnicaSub

Iznos Rabata jedamput upišem u polje na frmOtpremnica, a na subformi ga pozivam sa:

Polje Rabat, DefaultValue=[Forms]![frmOtpremnica]![Rabat]
Popust – kod nas u prodaji imaju preksu nda nekim kupcima uz rabat odobravaju i još dodatni popust, tako da mi je i to polje potrebno.
Skladište – je šifra skladišta sa kojega se roba izdaje i to mi je također važno. Npr u istoj bazi se obrađuje roba koja je na skladištima:
Gotova roba
Rezervni dijelovi
Trgovačka roba (tuđa roba na našem skladištu)
Naša roba na konsignaciji kod drugih
Itd.

Svako od ovih skladišta ima svoju oznaku o mora biti izražena na otpremnici i u kartici proizvoda
Pozdrav
↑  ↓

#33 05.04.2011 13:53
zxz Van mreze
Administrator
Registrovan od:03.02.2009
Postovi:10,612


Predmet:Re: Provjera duplog unosa
Citat:
Skladište – je šifra skladišta sa kojega se roba izdaje i to mi je također važno. Npr u istoj bazi se obrađuje roba koja je na skladištima:
Gotova roba
Rezervni dijelovi
Trgovačka roba (tuđa roba na našem skladištu)
Naša roba na konsignaciji kod drugih
Itd.

kako sam te ja razumio.
Imas Vise skladista napr:
Skadište1
Skladište2
Skladisšte3.

a u skladištima možes imati roba po više osnova i to:
Gotova roba
Rezervni dijelovi
Trgovačka roba (tuđa roba na našem skladištu)
Naša roba na konsignaciji kod drugih

Ako je to tako onda polje skladište ostaje stim sto treba dodati i polje vrrsta robe i obje moraju imati kodne tabele.
Podrška samo putem foruma, jer samo tako i ostali imaju koristi od toga.
↑  ↓

#34 05.04.2011 13:57
zxz Van mreze
Administrator
Registrovan od:03.02.2009
Postovi:10,612


Predmet:Re: Provjera duplog unosa
Citat:
BrojNar = broj narudžbenice koju je poslao kupac. Ovo polje može i ne mora biti popunjeno, a mogući su i duplikati jer postoji mogućnost da narudžbenice od različitih izvora imaju isti broj.

Ovo stoji i to si u pravu moze se desiti tako.

Sto se tice PDV- to odluci sam.
Ako ga ostavis u ovoj tabeli onda korisnik nema mogucnosti manipulacije a PDV je izmjenjiva stavka.
Sutra se moze desiti da za neku robu uvedu drugu ili nultu stopu.

Do tebe je sta ces odluciti.

Ostalo sam uradio pa kad ovo rijesim postavit cu ti pa vidi.
Onda prelazimo na sledecu tablicu.
Podrška samo putem foruma, jer samo tako i ostali imaju koristi od toga.
↑  ↓

#35 05.04.2011 14:50
pmiroslav Van mreze
Clan
Registrovan od:02.02.2009
Postovi:1,458


Predmet:Re: Provjera duplog unosa
Što se tiče vrste robe ja sam već napravio tablicu koja se zove
tblGrupeProizvoda
IDgrupe - Autonumber
GrupaProizvoda - Text

PDV za proizvode o kojima se ovdje radi uvjek će biti ista stopa.
Pozdrav
↑  ↓

#36 05.04.2011 15:30
pmiroslav Van mreze
Clan
Registrovan od:02.02.2009
Postovi:1,458


Predmet:Re: Provjera duplog unosa
Evo i slike relacija za tablice koje sada imam

Slicice prilozenih slika:
Relacije.jpg
Tip datoteke:Informacije o tipu datoteke za:jpg jpg
Preuzimanja:23
Velicina datoteke: Bajt
Velicina slike: {@imagesize->0} x {@imagesize->1} Pikseli


Pozdrav
↑  ↓

#37 05.04.2011 16:12
zxz Van mreze
Administrator
Registrovan od:03.02.2009
Postovi:10,612


Predmet:Re: Provjera duplog unosa
Evo sad jos jednom pregledaj dobro.
Ja sam u dilemi sa poljem skladisteID jer i dalje mislim da je prikladno da stoji u tabeli za izlazaz robe a da je ovdje visak.
Polja koja si ti stavio procentualna tj. polja pdv rabat itd ja sam stavio broj iz prostog razloga sto je ljudima blize kada ukucaju 17 za 17% naprimjer nego da moraju kucati 0.17.
Treba napraviti i sve kodne tabele za ove.
Veceras cu pogledati sledecui tabelu tj. tabelu detaalja.
Do tada i ti mozes ovu pregledati i izjasniti se.

Prilozi:
Informacije o tipu datoteke za:zip  knjizenjezxz97.zip
Preuzimanja:247
Velicina datoteke:16.16 KB


Podrška samo putem foruma, jer samo tako i ostali imaju koristi od toga.
↑  ↓

#38 05.04.2011 19:44
pmiroslav Van mreze
Clan
Registrovan od:02.02.2009
Postovi:1,458


Predmet:Re: Provjera duplog unosa
Citiraj zxz:
Evo sad jos jednom pregledaj dobro.
Ja sam u dilemi sa poljem skladisteID jer i dalje mislim da je prikladno da stoji u tabeli za izlazaz robe a da je ovdje visak.
Problem je što ovu bazu koristi skladištar i prodaja dok knjigovodstvo ima svoju zasebnu aplikaciju i ona se puni opet ručno iz otpremnice koja im se dostavi, pa na njoj trebaju biti svi podaci.
Još da napomenem da na jednoj otpremnici idu samo artikli iz jednog skladišta.
Što se tiče tablica koje si napravio uočio sam da si moju tablicu tblProdaja razdvojio na dvije i u drugu stavio podatke o dostavi robe. Molim te da mi objasniš zašto je tako bolje.
U našoj praksi nema puno slučajeva da su naručitelj i primatelj robe različiti, a ja sam na Reportu za otpremnicu u polja za dostavu stavio nešto ovako:
=IIf(IsNull([AdresaDostave]);[AdresaKupca];[AdresaDostave])
Zato me zanima da li će kasnije u formama i Reportima biti više problema sa uzimanjem podataka iz dvije tablice umjesto iz jedne.

Također mislim da nije potrebno polje IDGrupe u Tbl_Prodaja
Pozdrav
↑  ↓

#39 05.04.2011 22:02
zxz Van mreze
Administrator
Registrovan od:03.02.2009
Postovi:10,612


Predmet:Re: Provjera duplog unosa
Citat:
Problem je što ovu bazu koristi skladištar i prodaja dok knjigovodstvo ima svoju zasebnu aplikaciju i ona se puni opet ručno iz otpremnice koja im se dostavi, pa na njoj trebaju biti svi podaci.
U ovu tabelu upisuje samo referent prodaje.
Skladistar upisuje podatke kada izda robu odnosno kada kupac dodje u skladiste da izuzme robu sa papirom koji mu je dao ref. prodaje i te podatke zapisuje u tabelu tbl transakcije a stavke koje je izdao smijesta u tabelu UlazIaz i ti si to dobro napravio.
Tu smo i dosli do onog koda koji bi trebao sad prebaciti stavke iz tabele tblProdajastvke u tabelu tblUlazIzlaz.
Ovo se radi iz mnogo razloga jedan je napr da se moze desiti da u magacinu nema neke stavke a da kupac zeli izuzeti ostatak robe a po ovo moze doci i kasnije.
Onako bi bio prinudjen vratiti se referentu prodaje.
Ima to jos mnogo razloga. refeerent prodaje napr ne odgovara za stanje robe u magacinu pa prema tome moras imati tabelu u kojoj ces verifikovati ko je izdao robu.
Da ne nabrajam dalje.
Citat:
Još da napomenem da na jednoj otpremnici idu samo artikli iz jednog skladišta.

to sam ja tebe i prije razumio i po toj teoriji id skladista moze biti u ovoj tabeli ali svakako po meni morao bi to polje imati i u tabeli koju koristi skladistar tj. tabeli tblTransakcije.
Citat:
Što se tiče tablica koje si napravio uočio sam da si moju tablicu tblProdaja razdvojio na dvije i u drugu stavio podatke o dostavi robe. Molim te da mi objasniš zašto je tako bolje.
Odmah da ti kazem ovu tabela ce biti rel. vezana 1-1 i kada je veza 1-1 sto se tice unosa podataka to funkcionise isto kao da je i jedna tabela.
jednostavno napravis Query od ove dvije tabele i od query-a formu.
Prednosti:
Jedna od prednosti je ako napr. kao sto ti kazes kada kupac sam izuzima robu onda se to verifikuje u tabeli izlaza robe tj. u tvojoj tabeli tbl transakcije i u ovoj tabeli nemoras unositi nista.
Ako robu dostavlja neko trece lice onda njega upisujes u tabeli ulazIzlaz da je preuzeo robu a u ovu tabelu upisujes njegove podatke da je dostavio robu i kada.
Po ovome se da primijetiti da ova tabela iako je 1-1 nece imati isti broj redova.

Da napomenem po meni ova tabela bi mogla biti vezana za tabelu TblUlazIzlaz a ne za tabelu transakcije.
Primjer.
Ako je vezemo za tabelu transakcije i popunimo podatke tj. referent prodaje popuni podatke.
Da napomenem referent prodaje popunjava podatke prije no sto je roba izuzeta. Moglo bi se desiti da dodje do nekih promjena nepredvidjenih.
Ukoliko to vezemo za tabelu TbTransakcije znaci da onaj koji dodje i preuzme robu iz magacina a nije kupac robe magacioner ga pribiljezi da je izuzeo robu te upise njegove podatke u tabeli kao dostavljaca robe.
Citat:
U našoj praksi nema puno slučajeva da su naručitelj i primatelj robe različiti, a ja sam na Reportu za otpremnicu u polja za dostavu stavio nešto ovako:
ovo samo govori da trebaju biti dvije odvojene tabele sto se tice dostavljaca i onoga ko izuzima robu.
Zasto?
kao sto sam gore napomenuo ukoliko je sve u jednoj tabeli ili ces morati prepisati podatke izuzimaoca robe ili ce polja dostavljaca biti prazna.
Kao sto sam primijetio gore ti si to rijesio prepisivannjem istih podataka.
U ovom slucaju ako su dvije tabele jednostavno kada osoba koja je narucioc i izuzme robu znaci da nema dostavljaca i u ovoj tabeli neces nista ni pisati.
U tabeli transakcije imas polje partnerId sto znaci da je on i izuzeo robu a sve njegove podatke imas u tabeli partneri.
Podrška samo putem foruma, jer samo tako i ostali imaju koristi od toga.
↑  ↓

#40 05.04.2011 22:13
zxz Van mreze
Administrator
Registrovan od:03.02.2009
Postovi:10,612


Predmet:Re: Provjera duplog unosa
Tvoja sema baze je dosta jasna.
Primijetio bih samo da po svaku cijenu stvaras rel. veze cini mi se.
Sta nam relacijska veza daje ima opisano ovdje na forumu.
Ja cu pomenuti samo par tabela gdje nemoras praviti rel.vezu jer nema potrebe za njom.
Primjer:
tblJedinice.
Pretpostavljam da si je stavio kao lukap na svako polje gdje imas jednicu mjere.
Kada napravis formu na tom polju imas combobox sa opcijom limit to list yes. Neznam dali si primijetio ali kada pravis auto formu i ako na cobu imas u rowsource vise od jedne kolone automatski se postavlja limit to list yes.
Zasto?
Zato ako kodna tabela ima vise od jedne kolone nisi u mogucnosti popuniti ostale kolone.
Ako ovo na combu stoji sve ovako kako je navedeno znaci korisnik nije u mogucnosti nista napisati u to polje sto nema u tabeli jedmj. samim tim te stiti kao da si i rel. vezao tabelu.

Prednost ne vezanja:
Sada ako pogledamo da si objektivno to polje trebao imati i u tabeli tblProdajaStavke i u tabeli tblUlazIzlaz onda dolazis u dilemu gdje je vezati i dolazi do problema a moglo se desiti da je trebas i na vise mjesta.
ja kodne tabele obicno ne vezem.
ovo tvoje je dobro napraviti na pocetku dok pravis tabele i to ostavis kao semu jer je jasnije gdje je sta.
Podrška samo putem foruma, jer samo tako i ostali imaju koristi od toga.
↑  ↓

Stranice (11):1,2,3,4,5,6 ... 10,11


Sva vremena su GMT +02:00. Trenutno vrijeme: 7: 00 am.