Organizacija podataka u bazi

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...

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.

Potpis

Pozdrav,
Branislav

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?

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.

Potpis

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

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.

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.

Potpis

http://zoraneremija.wix.com/eremijacv

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. :-(

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.