modelovanje lagera

Treba mi "malecna pomoc" oko modelovanja.

U pitanju je baza trgovinskog preduzeca. Roba tog preduzeca se moze nalaziti u nekoj radnji ili magacinu, ali moze biti izdata na revers nekom partneru, kupcu i sl.
Radnju i magacin sam modelovao kao jedan objekat (ObjekatPreduzeca, npr), dok su partner i kupac razliciti objekti.

Izmodelovao sam uvodjenjem jos jednog objekta (tabele) Mesto. Prilazem sliku ovog dela modela. Ovo mi ne izgleda najpametnije resenje, pa verujem da ima neko pametniji od mene.

Potpis

krdr
Mozda i proradi

cisto sumnjam da ce neko da ti to modeluje za dz.

ali vredi pokusati

Ovako na brzinu....

Roba je ili u VP magacinu ili nije u magacinu. Ukoliko nije u VP magacinu, moraš imati dokument "papire" o izlasku robe (prijemnicu, dostavnicu, međumagacinsku itd.). Ukoliko je u prodavnici imaš kalkulaciju. Ukoliko je data kao uzorak, kreiraj magacin uzoraka npr. ali zadrži vezu sa kupcem da bi znao kod koga je koji uzorak. Na revers se inače ne izdaje roba iz magacina, čisto da znaš, jer neko mora da plati PDV.

Postoji sva odgovarajuca dokumentacija. Ulazi, izlaz,....
Prva zelja mi je da izbegnem
kalkulacije koliko mogu (firma ima trgovinu na malo i vp). Ono sto je
meni problem kako smisleno da modelujem tu vezu robe sa vise objekata
(Kupac i Partner).

@drbogi
Niko mi nije rekao za revers i PDV :)

Ionako se radi o diplomskom, potrebno je pratiti samo stanje robe, a
ne i placanja, odnosno finansije

Potpis

krdr
Mozda i proradi

Kalkulaciju ne možeš za sada da izbegneš, pošto je to jedini način da se roba zaprimi u MP. Ukoliko nikako drugačije ne uspeš, /tu prvenstveno mislim preko izmišljanja novog magacina,/ ostaje ti mogućnost da sve lepo raskačiš pa iz početka. Koristi veze više prema više jer jedan artikal može biti od više dobavljača, a može ga kupiti i više kupaca.

Revers se izdaje kada uzimaš neko sredstvo od firme, alat, materijal, npr. kada majstori zaduže kolut žice pa ne potroše sve, a kada firma izda žicu iz magacina, dolazi do prometa robe i do obaveze plačanja PDV-a.

Ovo za PDV mi je skroz jasno. Treba ce mi kad budem dodavao finansijsko poslovanje u bazu (a to mi prevazilazi temu), ako ikad budem teo da je komercijalizujem.

Medjutim, meni nije jasno ostalo. Ili ja tebi ne obajsnjavam kako tebe (verovatno :) ) ili te ja ne razumem (takodje verovatno :) :) )

Ne bezim od uvodjenja posebnog magacina (i veze m:n). Da preformulisem problem:
Neki Proizvod se nalazi u Magacinu ili u Radnji ili kod Kupca ili kod Partnera (dakle, zaboravi sve sa finansijama). Podaci o Magacin (radnja), Kupac i Partner su u posebnim tabelama jer su podaci koji se cuvaju dosta razliciti

Pitanje:
Koja kolicina Proizvoda P se nalazi u Magacinu M (ili u Radnji R ili kod Kupuca K ili kod Partnera P).

Zadatak:
Izmodelovati model kojim se na najlaksi nacin dobija odgovr na pitanje.

Moj model (ciju sliku sam podigao) sam modelovao Konceptualnom metodom (orm). On me je naterao da izmodelujem kako sam prestavio, ali nisma siguran da je to dobro resenje. Kasnije sam preveo u ER (na slici)

Inace sam VETS.

Potpis

krdr
Mozda i proradi

Ajmo opet. Kada roba dođe od dobavljača, gde ide, verovatno u VP magacin.
Kada ide kod Kupca -ti ga zoveš partner, izlazi iz Vp magacina uz izdavanje otpremnice i fakture.
Kada ide u MP izlazi uz otpremnicu i fakturu, i zaprimi se u MP gde VP faktura postaje prijemnica, na osnovu koje kreiraš kalkulaciju. U tom slučaju te interesuje šta je koji kupac MP kupio od robe. to vidiš po fakturama.

Kada treba dati tvoje uzorke, ja bih to odradio tako što bi kreirao magacin uzoraka, i fiktivno premeštao međumagacinskom dostavnicom iz VP magacina. Onda prostim filterima možeš videti gde je koja roba.

Kada je roba kod MP-a, to više nije tvoj problem, kao kada je kupi drugi VP za dalju prodaju, tu se završava tvoja briga o robi, i počinje briga o plaćanju.

Jedinu robu koja izlazi iz magacina, a o kojoj vodiš račun su ti tvoji uzorci. E za njih napravi magacin uzoraka ili udaljene magacine po kupcima kojima daješ takvu robu ito je to.


Tabele koje figuriraju su:
1. Kupac

2. Dobavljač

3. Vrsta magacina


Sada valjda razumeš kako sam ja shvatio tvoj slučaj, ako ništa drugo..

Vidim, samo sto ti vidis onako kako treba, a ne onako kako je zadato :)+)

Ali si mi dosta pomogao, hvala

Potpis

krdr
Mozda i proradi

Sta god da studiras lager se uvek isto racuna, a to je ulaz-izlaz. Lager je stanje u nekom trenutku.

Tabele koje se pominju: magacin, partner (jer neko moze biti i kupac i dobavljac) su potrebne za kontrolu ulaznih podataka. Isto tako ti treba i sifarnik roba, dokumenata.

Ono sto treba da napravis su najmanje dve forme: jedna za ulaz, jedna za izlaz. Zna se sta su ulazi, a sta izlazi. Potrebni su i odgovarajuci izvestaju koji proisticu iz toga. To samo treba unositi u tabelu promet koja ima strukturu (uprosceno)

magacin
vrsta dokumenta
broj dokumenta
datum promene
sifra robe
partner
ulaz
izlaz
...itd

mada bi bilo dobro da se vodi i kolicinski i vrednosno, dodas cenu i eto vrednosti, ali zanemarimo sada.

I sta sada? Kad imas promet napravis view

sifra robe, (ulaz-izlaz) kolicina : sto ti daje lager.

I onda napravis jos neke koji ukljucuju partnera, magacin i sta god ti treba. Lager je jedno, ali znaj da (svakom knjigovodji) treba i kartica.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

Sve je to predvijdeno, dao sam samo sliku onog dela modela koji me najvise buni (Baza trenutno ima cetrnest tabela. Kupac i partner posebne table).

Ako sam te dobro razumeo, lager ne treba da bude neka odredjena tabela, vec view, koji prikazuje trenutno stanje. Isto tako karticu robe mogu da modelujem.

Potpis

krdr
Mozda i proradi

Iz prakticnih razloga je bolje da se koristi partner, jer u isto vreme moze biti i kupac i dobavljac. Najcesce je jedan osoba zaduzena za te maticne podatke, pa je valjda jasno.

Promet ili kartica jer osnova svega, iz toga se vade izvestaji, recimo lager. Ali ako koristis neku bazu koja podrzava view onda je to najlakse.

Lager sam po sebi i nije tako znacajan izvestaj, mislim papirni. Ali je interesantan u pojedinim trenucima, recimo kad se pravi faktura da se zna stanje neke robe.

Mozda ti je zadatak samo teoretski, ali probaj da ubacis i cenu da bi dobio vrednsot. U prethodnom slucaju, fakturisanje, potrebno da se vidi stanje ali i neka cena po kojoj se vode zalihe, ili prodajna. Na racunu MORA da se nadje cena i vrednost robe.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

I jos jedno podpitanje



Da li treba praviti klasicno robno ili je u pitanju nesto drugo, konkretno mislim da je tema izrada optimalnog lagera. Ako je to onda je sve drugacije. Mada i u tom slucaju ne moze da se zanemari finansijska strana.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

@dragancesu
Pratim samo robu, ali ne zanemarujem finasijsku stranu.

Evo detalja zadatka. U pitanju je trgovina na veliko i malo, sa dva magacina (beograd i novi sad) i nekoliko radnji, koja povremeno iznamljuje svoju robu, konkretno, muzicki instrumenti i oprema. Moraju da se vode cene, kako bi se pratila vrednost robe na lageru, vrednost prodaje po mesecima (danima, godinama) i eventualno vrednost zaduzenja onoga ko je iznajmio robu.

Potrebno je u svakom trenutku znati gde se roba nalazi.

Prema mojoj koncepciji, razdvojio sam fizicka lica (tabela kupci) i pravna lica (tabela parteneri). Partner, u ovoj koncepciji, moze da bude proizvodjac, serviser, dobavljac ili kupac. Zbog prirode stvari, desava se da je neki partner i proizvodjac i dobavljac i serviser i kupac.

Zadatak je postavio profesor , a ja sam otisao do edne prodavnice muzickih instrumenata i raspitao se oko njihovog poslovanja.

Mozda profesor treba da uradi nekom bazu ;).

Poslacu ti ceo model koji sam sastavio na PP, ako zelis. kao vsd ili gif, sve jedno.

Potpis

krdr
Mozda i proradi

kada zavrsis aplikaciju mozes okaciti *.sql fajl tvoje baze da pogledam posto sam i ja nesto slicno pocinjao ali nisam imao zivaca da cackam do kraja....