[es] - Organizacija podataka u bazi

golic
Doboj

Član broj: 91529
Poruke: 82
79.143.169.*

Profil

^{22.01.2011. u 00:38 - pre 161 meseci}

Svojevremeno sam napravio bazu za komisionu prodaju robe, ali nisam zadovoljan organizacijom samih podataka.

Za one koji ne znaju kako funkionise komisiona prodaja evo par podataka:

Komintent donosi robu u komision i pravi se ugovor o prodajnom komisionu koji sluzi kao ulaz robe i iz njega dalje slijedi Prijemnica/Kalkulacija.
Na kraju svakog mjeseca vrši se isplata komintenata.

Iz razloga što nisam znao kako da organizujem podatke, problem koji sam imao sa praćenjem (koji artikal pripada kojem komintentu) sam riješio na način da jedan artikal moguće nabaviti samo od jednog komintenta.U protivnom bi se desilo da dva komintenta donesu dvije iste lopte a da se ne zna čija je prodata.(Osim ako nije fizički obilježen vlasnik)

Grešku sam napravio a to je da sam omogućio da jedan artikal moguće nabaviti po različitim cijenama što je u neku ruku i normalno jer cijena je nekad viša, a nekad niža.

Sada imam problem sa praćenjem te nabavne cijene:
Primjer

01.01.2010 je ulaz nekog artikla 5 komada po cijeni od 10 dinara/maraka

04.01.2010 je izlaz tog artikla 4 komada po cijeni od 10 dinara/maraka-------na stanju ostaje 1 komad

05.01.2010 je ulaz tog artikla 4 komada po cijeni od 11 dinara/maraka------na stanje je sada 5 komada

06.01.2010 je izlaz tog artikla 2 komada po cijeni (Kojoj???) 1 po 10 dinara/maraka i 1 po 11 dinara/maraka.

Šta da radim u ovom slučaju?
Ako neko imam primjer ili model baze koji omogućuje praćenje nabavne cijene volio bi da mi pomogne?

Hvala unaprijed na odgovorima...

Odgovor na temu

banem
Kikinda

Član broj: 16619
Poruke: 583
*.dynamic.sbb.rs.

+15 Profil

Re: Organizacija podataka u bazi

^{22.01.2011. u 00:44 - pre 161 meseci}

Možda si previše normalizovao podatke. Piši ulaznu cenu uz svaki pojedinačni artikal, tako uvek znaš koji koliko košta, bez obzira da li su artikli isti. Što se tiče knjigovodstva, barem su pre bila dva metoda, prvi ulaz, prvi izlaz ili poslednji ulaz prvi izlaz (ako se dobro sećam, davno je bilo). Tebi je možda najbolje da primeniš metod prvi ulaz prvi izlaz, tako da ona dva na poslednjem izlazu jedan je iz one prve grupe od pet ulaza.

Pozdrav,
Branislav

Odgovor na temu

golic
Doboj

Član broj: 91529
Poruke: 82
79.143.169.*

Profil

Re: Organizacija podataka u bazi

^{22.01.2011. u 00:52 - pre 161 meseci}

Hvala na brzom odgovoru, ali meni opet neke stvari nisu jasne...

Jasno mi je da treba ici po FIFO metodi.
Jasno mi je i da treba da denormalizujem bazu.

Ono što mi nije jasno kako da je denormalizujem a da dobijem željeni rezultat?

Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2831

+45 Profil

Re: Organizacija podataka u bazi

^{22.01.2011. u 07:01 - pre 161 meseci}

Komisiona prodaja podrazumeva da svaki dobavljač, u različitim vremenima, donosi različite artikle, u različitoj količini na komisionu prodaju i da on odlučuje o nivelaciji cene na gore ili na dole u zavisnosti od toka prodaje. Učestalost nivelacija je takođe stvar dobavljača. FIFO metoda ovde ne može da se ispoštuje do kraja, jer dobavljač ima eksluzivno pravo odlučivanja o prodajnoj ceni pojedinog komada.

Nema modela, pa je teško dati sugestije. Banem je pretporstavio da si suviše normalizovao podatke. Možda je i to problem, a možda ne treba denormalizovati. Denormalizacija je okosnica za analitičke baze podataka tipa OLAP. U takvim bazama se ne radi ažuriranje, već samo agregacija. Ako sam ja dobro razumeo, ti treba da vodiš prostu evidenciju.

Prvi predlog je da za ključ artikla postaviš:
PK (SifraDobavljaca+SifraArtikla+DatumNabavke). To bi bilo dovoljno jedinstveno po stavci za praćenje cene u vremenu ukoliko se promene cena odnose na primljene artikle u jednoj sesiji. Znači, sve količine jednog artikla u istom danu.

Međutim, dobavljač može imati i ovakav zahtev. Prvih pet komada jednog donetog artikla pordajem po ceni X, a sve ostale po ceni Y.

Drugi predlog je da svaki komad bilo kojeg artikla posmatraš kao zasebnu instancu i da svaki ima svoju sopstvenu šifru. Ovo zahteva više truda pri unosu podataka. Mada, ako se dobro automatizuje, dodela sifara za 20 komada nečega može da se uradi automatski. Takođe zahteva veliki broj šifara. Pretrage za potrebe ažuriranja (nivelisanja cena) su nešto sporije ali se i dalje vrše po dobavljaču i datumu nabavke.

Prvi slučaj sa složenim ključem je teži za implementaciju, ali je sigurniji za ažuriranje.
I u jednom i u drugom slučaju moraš da vodiš tabelu Nivelacije. Zadnja nivelacija je merodavna za cenu pojedinog artikla.

Sad valja proceniti na osnovu realnog sistema koji od ovih predloga implementirati u informacioni sistem.

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Odgovor na temu

golic
Doboj

Član broj: 91529
Poruke: 82
188.124.196.*

Profil

Re: Organizacija podataka u bazi

^{23.01.2011. u 09:03 - pre 161 meseci}

Tri dana se vrtim oko ovog problema i ne vidim rješenje.Jedino ostaje da postavim da je jedan artikal moguće nabaviti samo od jednog dobavljača i po jednoj nabavnoj cijeni.
Molio bih i Zidara i Eremiju da se i oni oglase o ovom problemu.

Odgovor na temu

Zoran.Eremija
Zoran Eremija
SYSTEM ANALYST
Freelancer
Beograd

Član broj: 251342
Poruke: 855
212.178.237.*

Sajt: zoraneremija.wix.com/erem..

+47 Profil

Re: Organizacija podataka u bazi

^{23.01.2011. u 11:08 - pre 161 meseci}

Predlog koji Vam je Getsbi dao vodi ka resenju problema s time sto ne preslikava u potpunosti realnu situaciju koju ste naveli. Sustina Vaseg problema je Ugovaranje i identifikacija predmeta prodaje.O predmetu prodaje i o identifikaciji (Predmet poslovanja) ranije sam pisao. Specificnost oznacavanja u vasem slucaju cini ne poreklo tj komitent (Partner) vec Ugovor s tim partnerom. Sto znaci da bi svaki identifikovani predmet poslovanja trebao da se razlikuje po osnovu Ugovora. Da bi Vam preciznije pomogao bilo bi dobro da postavite Vas model baze sa nesto test podataka i to karakteristicnih.

http://zoraneremija.wix.com/eremijacv

Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: Organizacija podataka u bazi

^{24.01.2011. u 16:31 - pre 161 meseci}

Na zalost ne mogu da pomognem - ne znam dovoljno o toj vrsti poslovanja. Ti si lepo objasbnio sta i kako radis, tu nema zamerke, problem je sto se ja u to ne razume dovoljno da bih nesto pametno mogao da predlozim.

Getsbi Zoran i jos nekoliko ljudi sa foruma su u tome mnogo jaci. Pazljivo citam postove i posmatram, pa ako nesto uocuim, ubacicu se u pricu, ako budem imao sta korisno da doprinesem. :-(

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Organizacija podataka u bazi

^{24.01.2011. u 23:38 - pre 161 meseci}

Samo pročitaj zakon i primeni ga. U Srbiji je važeći PRAVILNIK O EVIDENCIJI PROMETA ROBE I USLUGA, verujem da je i kod Vas na neki sličan način regulisano. Kod računovodstva nema puno razmišljanja i nedoumica ako si upoznat sa principimina knjiženja. Ono što bi radio sa papirnom dokumentacijom prenesi u program, ali samo to i ne kombinuj previše.

Odgovor na temu

golic
Doboj

Član broj: 91529
Poruke: 82
188.124.196.*

Profil

Re: Organizacija podataka u bazi

^{25.01.2011. u 21:31 - pre 161 meseci}

Hvala svima na odgovorima...

Ono što je mene zbunilo jeste da moram sa jednim metkom 4 zeca...ispraviti neke greške koje su ranije napravljene, a da pri tom primarni ključ predmeta poslovanja ostane prost broj baš kao što je i u fiskalnoj kasi.......NEMOGUĆE

Sreća mi je samo što moram petljati sa nabavnim vrijednostima...

Odgovor na temu