Prikazi cijelu temu
06.04.2011 11:14
06.04.2011 11:14
Predmet: Re: Provjera duplog unosa
E sad si ti mene pretekao. Ja sam mislio da radimo jednu po jedno ali dobro.
Evo prvo ova tabela koju smo vec uradili i njena dodatna tabela.
Polje:
IDGrupe. Ja sam mu dao ovako ime a odnosi se na ovo tvoje:
O tome cemo kasnije.
Vidim da imas i nacin placanja Kodnu tabelu. Pretpostavljam da se placanje vrsi nakon nastanka podataka u tabeli TblProdaja odnsosno kada kupac prezentira sta hoce kupiti kod ref. prodaje.
U svakom slucaju mislim da se vrsi prodaja na osnovu papira koji napravi ref. prodaje.
Ako sam u pravu onda u tabelu TblProdaja treba dodati i polje PlacanjeID. Preneseni kljuc iz kodne tabele vrste placanja
tabekla TblProdajaStavke
StavkeProdajeID-->autonumber i kljuc
OrderID----->Broj otpremnice.Ovo bi trebalo biti preneseni kljuc iz tabele TblProdaja da bi mogao povezati ove dvije tabele jer moraju biti vezane a za broj otpremnice dodati polje
BrOtpremnice ili nekako drugacije ako ti pase. Dali ce imati duplikata ili ne odluci sam ali trebalo bi ovo polje indeksirati
Sifra ----->Sifra artikla
Kolicina---->Kolicina
CijenaProdaje---->Povalci se cijena iz tabele artikli u kojoj ce se unositi cijene
To cemo poslije razjasniti.
Po meni treba dodati jos:
JM---->jedinica mjere koja bi se isto povlacila iz tabele artikli
Jos cu samo da pokusam objasniti tabelu TblArtikli.
TblArtikli je kodan tabela.
Cemu sluzi?
Sluzi tome da korisnik nebi non stop pisao naziv artikla cijenu jM i ostalo sto se tice odredjenog artikla.
Ukoliko imamo kodnu tabelu jednostavno iz nje prenosimo podatke u tabele ulaza izlaza i bilo gdje sto se tice artikala.
Ovim nacinom se izbjegavaju greske pri kucanju a i samovolja samih operatera koji bi mogli znaci u nekom momsentu namjerno da promijene cijenu a to je poslije tesko dokazati.
Operateru se ostavlja samo da unese kolicinu robe i za nju odgovara.
Zasto se prenose podaci pored sifre ili naziva artikla cijena i jm.
Svi podaci u tabeli artikli koji su u nekom vremenskom periodu podlozni promjenama prenose se u tabele ulaza i izlaza tako da tamo ostaju trajno zapisani onakvi kakvi su bili u momentu nastanka papira.
Pored ovih u vecini slucajeva trebaju jos:
PDV
ZadnjaKalkulacija--->Ako se radi kalkulacija.
Nacin na koji si ti zaposceo to praviti je izvodiv ali se rijetko koristi.
Ti si napravio tabelu cjenovnik zasbnu i u nju imas namjeru upisati novu cijenu kada god se promijeni.
Naravno u tvom slucaju mozes imati cjenovnik od bilo kog datuma i da kazemo da je to prednost ovog nacina ali kome treba neki stari cjenovnik.
Treba mu posto je neki artikal prodat napr. prosle godine u aprilu a to ima u tabeli Izlaza robe (U tvom slucaju u tabeli tblProdajastavke)
Mane:
Kao prvo nepreglesdnost i nekada zna doci do emnormnog povecenja ako inflacija bije pa se cijene mijenjaju svaki dan.
Kako god se ti odlucis tako cemo praviti.
E sad si ti mene pretekao. Ja sam mislio da radimo jednu po jedno ali dobro.
Evo prvo ova tabela koju smo vec uradili i njena dodatna tabela.
Polje:
IDGrupe. Ja sam mu dao ovako ime a odnosi se na ovo tvoje:
Citat:
Kodna tabela koju si ti napravio TblGrupeProizvoda mora biti vezana za tabelu artikala.Gotova roba
Rezervni dijelovi
Trgovačka roba (tuđa roba na našem skladištu)
Naša roba na konsignaciji kod drugih
Itd.
Ovo gore ide za IDGrupa u TbProdaja
O tome cemo kasnije.
Vidim da imas i nacin placanja Kodnu tabelu. Pretpostavljam da se placanje vrsi nakon nastanka podataka u tabeli TblProdaja odnsosno kada kupac prezentira sta hoce kupiti kod ref. prodaje.
U svakom slucaju mislim da se vrsi prodaja na osnovu papira koji napravi ref. prodaje.
Ako sam u pravu onda u tabelu TblProdaja treba dodati i polje PlacanjeID. Preneseni kljuc iz kodne tabele vrste placanja
tabekla TblProdajaStavke
StavkeProdajeID-->autonumber i kljuc
OrderID----->Broj otpremnice.Ovo bi trebalo biti preneseni kljuc iz tabele TblProdaja da bi mogao povezati ove dvije tabele jer moraju biti vezane a za broj otpremnice dodati polje
BrOtpremnice ili nekako drugacije ako ti pase. Dali ce imati duplikata ili ne odluci sam ali trebalo bi ovo polje indeksirati
Sifra ----->Sifra artikla
Kolicina---->Kolicina
CijenaProdaje---->Povalci se cijena iz tabele artikli u kojoj ce se unositi cijene
To cemo poslije razjasniti.
Po meni treba dodati jos:
JM---->jedinica mjere koja bi se isto povlacila iz tabele artikli
Jos cu samo da pokusam objasniti tabelu TblArtikli.
TblArtikli je kodan tabela.
Cemu sluzi?
Sluzi tome da korisnik nebi non stop pisao naziv artikla cijenu jM i ostalo sto se tice odredjenog artikla.
Ukoliko imamo kodnu tabelu jednostavno iz nje prenosimo podatke u tabele ulaza izlaza i bilo gdje sto se tice artikala.
Ovim nacinom se izbjegavaju greske pri kucanju a i samovolja samih operatera koji bi mogli znaci u nekom momsentu namjerno da promijene cijenu a to je poslije tesko dokazati.
Operateru se ostavlja samo da unese kolicinu robe i za nju odgovara.
Zasto se prenose podaci pored sifre ili naziva artikla cijena i jm.
Svi podaci u tabeli artikli koji su u nekom vremenskom periodu podlozni promjenama prenose se u tabele ulaza i izlaza tako da tamo ostaju trajno zapisani onakvi kakvi su bili u momentu nastanka papira.
Pored ovih u vecini slucajeva trebaju jos:
PDV
ZadnjaKalkulacija--->Ako se radi kalkulacija.
Nacin na koji si ti zaposceo to praviti je izvodiv ali se rijetko koristi.
Ti si napravio tabelu cjenovnik zasbnu i u nju imas namjeru upisati novu cijenu kada god se promijeni.
Naravno u tvom slucaju mozes imati cjenovnik od bilo kog datuma i da kazemo da je to prednost ovog nacina ali kome treba neki stari cjenovnik.
Treba mu posto je neki artikal prodat napr. prosle godine u aprilu a to ima u tabeli Izlaza robe (U tvom slucaju u tabeli tblProdajastavke)
Mane:
Kao prvo nepreglesdnost i nekada zna doci do emnormnog povecenja ako inflacija bije pa se cijene mijenjaju svaki dan.
Kako god se ti odlucis tako cemo praviti.
Podrska samo putem foruma, jer samo tako i ostali imaju koristi od toga.