Mislim da bi trebalo da pokušaš sa pravljenjem tabele "tblKolicinaCena" u kojoj ćeš voditi koliko je koje robe i po kojoj ceni ušlo, odnosno koliko je koje robe i po kjoj ceni izašlo. Savetujem da dodaš količinu u tu drugu tabelu i zadržiš jedan datum. Cena po tom datumu važi, dok se ne isprazni količina. U međuvremenu možeš nabaviti novu količinu po istoj ili drugoj ceni i sa novim datumom nabavke. Uz pomoć VBA koda ili sistema akcionih query-ja trebaće da obezvediš ažuriranje te tabele. Na kraju to upakuješ u korisnički interfejs.

Na tebi je da se odlučiš koju ćeš metodu da koristiš: FIFO, LIFO ili prosečne cene. Zadatak je prilično obiman.

Mozda nisam najbolje objasnio pa da se popravim...

Kolicinu ulaza i ulaznu cijenu pamtim u jednoj tabeli tblUgovori
Kolicinu izlaza i izlaznu cijenu pamtim u drugoj tabeli tblRacunStavke
Hjeo bih da ne upisujem stalno cijenu izlaznu u tblRacunStavke nego da je za izvjestaje vucem iz cjenovnika.
Napravio sam tabelu tblCjenovnik koja je u vezi sa tabelom tblSifarnik...jedna Sifra artikla moze imati vise cijena, ali je samo jedna cijena aktuelna u momentu prodaje (datum i vrijeme).

Nemogu nikako skontati kako da napravim da mi query vuce odgovarajucu cijenu koja je vazila u momentu prodaje.

Ako nećeš da u tblRacunStavke upisuješ cenu onda moraš da upisuješ datum prodaje kako bi postojala veza sa tblCjenovnik. Iza toga bi sledilo traženje po šifri i datumu prodaje u tblCjenovnik, u intervalu VaziOd-VaziDo, što mi se čini nepotrebno. Čak je i komplikovanije. Mada, bez da vidim ceo model, teško da mogu bilo šta da kažem. Iz prve mi se ne sviđa što i tblSifarnik i tblCjenovnik imaju iste kolone u vezi cena.

Mozda moze ovaj model da vam pomogne...

Hvala na trudu ljudi...

@Getsbi U tblRacun imam polje datumRacuna i mislim da mi je nepotrebno polje datum racuna u tblRacunStavke, a iz razloga sto mi je onda isto ili cuvao podatak datum racuna ili cijena.Dakle veza postoji preko tabele tblRacun (DatumRacuna), ali mi je komplikovano napraviti taj parametarski upit koji ce mi vuci cijenu ciji je datum racuna izmedju Datuma VaziOd i VaziDo, a ako se cijena nije nikako mijenjala onda je ona cije je polje VaziDo Is Null.

@Zoran.Eremija Hvala u svakom slucaju, ali mi ne odgovara taj model, jer mi je komplikovano prepravljati bazu pa dodavati vec postojece rekorde.


CijenaMP i CijenaVP u tblSifarnik je ostala zato sto su mi u njoj podaci o cijeni, a kada napravim ovo sa tblCjenovnik svakako cu izbrisati ta polja.

Ova recenica je razlog sto se u 99.99% slucajeva u praksi vodi samo jedan cenovnik, sa tekucom cenom, a cena se prepisuje iz cenovnika u tabelu tblRacuniStavke. Ja bih to nazvao 'jednostavni cenovnik'. Na taj nacin imas u tabeli tblRacuniStavke cenu koja je vazila u u momentu prodaje (upisivanja u tabelu tblStavkeRacuna). To jeste na neki nacin dupliciranje podataka, ali su zato kveriji mnogo jednostavniji. To je primer razumne denormalizacije baze.

Ako bas zelis da vodis cenovnik sa vremenskom komponentom, tako da se u cenovnik upisuje
(Artikl, Cena, DatumOdKogaVaziCena),
kveriji se znatno komplikuju. To bih nazvao 'cenovnik sa vremenskom komponentom'. Potpuno te razumem kad kazes Vise ne gledas direktno u ceo cenovnik, nego izvlacis iz cenovnika samo one redove ciji DatumOdKogaVaziCena odgovara datumu prodaje. Sta ovo znaci?

Neka je datum racuna 10 Mart 2009. Neka imas u cenovniku za odrdjeni artikl ove unose:

Tabela tblCenovnikKrozVreme
ArtiklID Cena DatumOdKogaVaziCena
7 12.5 1 Jan 2008
7 18.5 30 Jun 2008
7 16.5 30 April 2009
7 22.5 30 May 2010

Za tvoj datum 10 mart 2009 treba uzeti cenu koja je vazila vazi od 30 Juna 2008 - ocigledno iz tabele. kako u kveriju da dodjem do ovog datuma? Pa to je maximalni datum u tabeli tblCenovnikKrozVreme koji je manji od datuma na racunu. Drugim recima, za svaki artikl pogledaj u sve redove u tblCenovnikKrozVreme gde je DatumOdKogaVaziCena <= tblRacun.datumRacuna i onda uzmi najveci od njih. To je cena koja vazi za dat artikl na datom racunu. Nadam se da si shvatio logiku. Sad samo treba napisati kveri koji tu logiku realizuje.

Ako bi nam zakacio bazu sa tabelama tblCenovnikKrozVreme, tblRAcuni, tblStavkeNaRacunu, napisao bih ti kveri koji ovo radi. Kveri nije jednostavan, jer je u stvari to correlated subquery. To nije jednostavno za pisanje u Accesu. Dodatno, takvi kveriji se uglavnom izvrsavaju sporo. To bi mogao biti jedan od razloga sto ovaj metod nije bas uobicajen u praksi. Medjutim, kad ti resenje treba za jedan odredjeni racun, moguce je ubrzati ceo proces, pomocu nekih sitnih trikova. Za konkretan kveri zakaci bazu pa da probamo. Pa ako bas bude nedopustivo sporo razmislicemo o trikovima za ubrzanje.

A ti na kraju odluci sta ti se vise dopada:
a) metod prepisivanja tekuce cene iz prostog cenovnika u stavke racuna, ili
b) metod vodjenja cenovnika sa vremenskom komponentom

a) je klasican metod, siroko rasprostranjen. b) je torijski bolje resenje, ali se nekoristi u praksi dovoljno dugo da bi se steklo neko siroko iskustvo. Ja kod jednog klijenta koristim ovaj metod, ne za cenu nego za neke druge stvari promenljive kroz vreme, i mogu da kazem da radi. Sporije jeste, ali nije nedopustivo sporije.

Sve u svemu ovo ide u prilog mom zapazanju da se u bazama podataka stvari komlikuju za bar jos jedan red velicne, kada se u igru uvede vreme. Negde sam procitao da za to sluze normalne forme viseg novo, 5. i 6 cini mi se, mozad gresim. U svaom slucaju, stvari se komplikuju. Pa sta ako se komplikuju, to odvakja profesionalca od amatera i dunstera


Zakaci test bazu pa da probamo, ako hoces.

Evo me nakon tri dana...ubilo me fakturisanje situacija i rjesavanje gradjevinskih dnevnika i knjiga, a onda 1.maj dotukao skroz...

Test baza je u prilogu pa eto hvala unaprijed.

Pa sto ne kazes da si gradjevinac Evo sad ce odmah

Evo zakacio sam. Trik je u tome da se napravi kveri koji za zadati datum racuna 'vidi' odgovarajucu cenu u tabeli tblCjenovnik.

Moze sve da se napravi u jednom kveriju ali bi bilo komplikobvano za razumevanje. Zato sam napravio dva kverija:

1) qryDatumVazenjaCeneZaStavke = pronalazi datum vazenja cene u tabeli tblCjenovnik
2) qryStavkeRAcuna_Sa_Cijenama = pokazuje ceen koje su vazile na datum izdavanja racuna

Ovaj drugi, qryStavkeRAcuna_Sa_Cijenama treba da bude osnova za stampanje racuna i z aizvestaje. Prvi kveri sluzi samo kao 'medjurezultat' za drugi kveri.

qryDatumVazenjaCeneZaStavke :

Subkveri u zagradi daje rezultat za kolonu DatumCijene. To je i najveca muka da se napise, mora da se kuca u SQL prozoru. Tamo nazalost ne izgleda tekst ovako lepo, ja sam ga malo formatirao, da bi bilo razumljivije.

U sledecem koraku se qryDatumVazenjaCeneZaStavke poveze jos jednom sa tabelom tblCjenovnik. Kveri qryStavkeRAcuna_Sa_Cijenama nije nista posebno, videces kad ga otvoris u dizajnu.

Primetio sam da za neke artikle u primeru nemas cene. Prvom kveriju to ne smeta, ali drugi bi mogao da ih promasi, pa sma napravio da drugi kveri bude LEFT JOIN, d aih ne promasi.

Nadam se da je pomoglo.

E za ovo imas pivu...svaka cast majstore!
Ovo moze ladno u top temu...

Hvaal, drago mi je da je to to. Nece u top temu, ali ce ici u Bazu Znanja.

U zdravlje