Evo za sada sta ja vidim kao neke dileme ili probleme u pokusaju da razumem sistem:
- Ceo problem se posmatra na nivou jednog poslovnog sistema. To znaci da ti ne treba tabela POSLOVNI SISTEMI. Ona bi ti bila potrebna ukoliko bi tvoje resenje moralo da prati proces reklamacije u vise poslovnih sistema, sto nema logike. Kada izbaci tabelu POSLOVNI SISTEM, odmah izbacujes i sva SifraPS obelezja, jer se ionako svaki entitet u svakoj tabeli odnosi na jedan te isti PS.
- Datum izdavanja racuna je isto sto i datum kupovine, bar sa aspekta reklamiranja proizvoda. To znaci da ti oblezje DatumKupovine ne smes da imas i u tabeli Reklamacije. Dovoljno je da znas o kom racunu se radi, onda imas i informaciju o datumu.
- Isto vazi i za kupca. Dovoljno je da znamo za koji je racun vezana reklamacija da bismo znali koji je kupac u pitanju.
- Racun i Pozicije racuna:
Nije potrebna sifraKU u stavkama racuna, dovoljno je da znamo kom racunu stavke pripadaju.
Isto vazi i za sifru ovlascenog lica.
Podatak Vrednost Racuna ne sme se smestati u bazu racuni, on se izracunava upitima na osnovu stavki racuna i cena proizvoda.
Cena proizvoda je tema za sebe. To jeste osobina proizvoda, i zato treba da je u tabeli prozivodi ali na tom mestu Cena prozivoda je samo Aktuelna Cena Proizvoda. Nama je bitno koja je cena bila u trenutku svake prodaje ("istorijska cena"). Ako te bude zanimalo kako to da izvedes, a da izbegnes redundantnost podataka, mozemo da pricamo i o tome. Za skolske potrebe mislim da je tvoje resenje dovoljno dobro.
- Kako je resena reklamacija? Uz svaku reklamaciju treba ti polje npr. STATUS koje ce datu informaciju kako je resena (i da li je resena svaka od reklamacija) npr. Status moze da bude (1) razmatra se (2) zamenjen proizvod (3) vracen novac proizvod stavljen u prodaju (4) vracen novac proizvod povucen (5) odbijena itd...
- U celom sistemu najvise skripi StanjeZaliha. Cela ta tabela ustvari bi trebalo da bude samo jedan upit koji na osnovu nabavki, prodaje i izdavanja robe povodom reklamacije racuna trenutno stanje. Posto vec pratimo prodaju preko racuna, i reklamacije preko reklamacija, ja bih dodao i jednu tabelu nabavke koja bi kompletirala sistem. Taj sistem onda bi ti omogucio da pravis more izvestaja za desetku, i ekipa sa foruma bi se utrkivala ko ce koji upit da ti napravi :)
Inace, u tom sistemu Stanje jednog prozivoda je ukupna nabavka, minus ukupna prodaja, minus reklamacije ciji je status 2.
- Tipovi podataka:
To je skroz tehnicko pitanje, ali si vecinu tipova pogresno odabrala. Savetujem ti da procitas
http://casovi.klikeri.net/?p=111
http://casovi.klikeri.net/?p=115
Tu ces lako pokapirati tipove, i lako popraviti resenje.
Zapalo mi je za oko da ti je Maticni broj tipa Number. Jedno od retkih polja koje nisi napisala da je tipa Text ustvari jeste tipa text. Ako je neko rodjen 8. juna njegov maticni broj pocinje sa 0806.... i ako je to broj onda ce se videti kao 806.... sto nije dobro... itd.
- Primarni kljucevi
Savetujem ti da se ne zapetljavas sa slozenim primarnim kljucevima (sastavljenim od vise obelezja), kao ni sa prirodnim kljucevima (kao sto je npr. broj racuna) vec da se drzis vestackih kljuceva kao SifraKupca, SifraProizvoda, SifraRacuna itd. Sve njih stavi da budu Autonumber i resila si sve probleme u vezi sa primarnim kljucevima. Ne samo da je lakse, nego je i provereno bolje resenje.
Nadam se da nisam samo otvorio nove dileme nego da sam i ponudio neka resenja i pomogao.
IS za reklamacije poslovnog sistema (maloprodajnog objekta)
Re: IS za reklamacije poslovnog sistema (maloprodajnog objekta)
