Funkcija Avg racuna prosjek, npr. Avg([Ocjene]).

Ma nije to tako lako....

Ne kontam kako se magacin moze razduzivati po prosjecnoj cijeni, ali nema veze.

Ulaz:_____________________________________Izlaz :____________________________________ Stanje:
50 kom po 300,00din = 15000,00Din _______30 kom po 300,00Din =9000,00Din _____________ 20 kom

150 kom po 500,00din = 750000,00Din _________________________________________________170 kom


Ako prosjecna cijena racuna (Vrijednost na stanju+Vrijednost iz novog ulaza)/(Kolicina na stanju+kolicina iz novog ulaza)

(20 kom sa stanja) x( nova cijena 500,00)= 10000,00 Din
(150 kom novi ulaz)x( nova cijena 500,00)= 750000,00 Din
---------------------------------------------------------
170 kom 850000,00 Diin

850000,00/170 kom = 500,00Din

Ako je tako to znaci da je neko uradio nivelaciju i duzi ti tih 20 kom sa stanja po novoj cijeni i to je ok.Znaci ne treba ti nikakav prosjek vec primjenjujes najsvjeziju cijenu i na zatecenu kolicinu sa stanja.
Ako nije tako onda ne znam kako da ti pomognem.

Pa zalihe robe u magacinu se vode po prosecnoj nabavnoj ceni obicno(moze i drugacije npr FIFO, LIFO metoda, planske cene... ali ovako je najbolje). I ako se magacin zaduzi po nabavnoj ceni , mora i da se razduzi po nabavnoj da bi na kraju saldo bilo 0,00 kad se sve rasproda ( razduzuje se po prosecnoj a zaduzuje po stvarnoj nabavnoj ceni iz kalkulacije ili ulaza).

Ovo tvoje sto si napisao nista mi nije jasno , a i nisi dobro izracunao.

Evo u word fajlu kako treba to da izgleda. Kolone ULAZ IZNOS i IZLAZ IZNOS na kraju moraju da budu jednake, tj zaduzenje=razduzenje
Znaci CENA ostaje ista za svaki izlaz robe iz magacina sve dok ne stigne nova kolicina , pa se formira nova prosecna cena.

Pokusao sam da polje CENA racuna pomocu =IIf([KolicinaUlaz]=0;[StanjeIznos]/[Stanje];[Zaduzenje]/[KolicinaUlaz]) ali nije dobro.

Desi se i iskusnom matematicaru da pogrijesi.85000/170 =500.
Da sam juce umro nebi znao da se tako magacin razduzuje. Nista mi ne pada na pamet jedino da u IIf funkciju dodas jos jednu IIf funkciju ili u samoj tabeli dodati polje stara cijena. Probacu kasnije pa ti javim.Pozdrav

Pogledao sam model podataka iz prvog posta. Osim jedne kolone "Ukupno" ništa ne podseća na mogućnost vođenja cena po prosečnoj nabavnoj. Ni ta kolona mi ne daje mnogo nade, kao ni nepotpuni model.

Kategorija prosečne nabavne cene je jednako složena za realizaciju aplikacije kao i FIFO ili LIFO. Čak je možda za nijansu i zahtevnija. Radi se o sledećem. Svaki put kad nabaviš artikal koji već imaš na lageru prosečna nabavna cena mora da se preračuna. Ona opada ili raste u zavisnosti od toga da li je nabavka jeftinija ili skuplja. Samo izračunavanje na riportu bez prethodno dobro koncipiranog modela podataka neće ti doneti ništa dobro.

Po meni bi trebalo da postoji tabela u kojoj se vodi stanje količina po artiklu i trenutno ažurirana prosečna cena za taj artikal nakon zadnje promene (nabavke). Savetujem ti da sve izveštaje radiš nakon čiste situacije u bazi podataka. Ovo podrazumeva da izvor izveštaja možeš lako da pogledaš u tabeli ili query-ju.

Da, ali onda ne bi mogao da radim nikakvu ispravku na ranijim ulazima ako slucajno bude bilo potrebno , a desava se i to.
Prednost u odnosu na rucno vodjenje knjiga...

Nego nasao sam neko resenje na engleskom , samo ne znam kako da ga primenim na ovaj primer i nije bas najjasnije.

http://www.dbforums.com/micros...ng-weighted-average-query.html

Ako neko moze ovo da protumaci i da ubaci u db1 iz primera.




Ode je sve reseno na nivou query-ja i ubacio je polje [SN] da bi razlikovao ulaz od izlaza, mada za to moze da se koristi da je kod izlaza "KolicinaUlaz=0"

Neki predlazu i pozivanje funkcije iz excela, i to bi mi odgovaralo samo da radi.

Zanimljiva tema, naravno sve je jasno kada se svi dogadjaji odvijaju hronoloski, problem nastaje kada se menja ili dodaje neki dokument retroaktivno, moj savet je da se onda izvrsi preracun svih prosecnih cena u izlaznim dokumentima od pocetka, a razlike koje se pojave treba evidentirati u finansijskom knjigovodstvu, jel osnovna kontrola kod kartice robe (materijala) je nezavisno da li se vodi po prosecnoj ili prodajnoj ceni (nivelacija) sledeca - zbir vrednosti svih ulaza i izlaza treba da bude jednak poslednje stanje puta poslednja cena. Naravno moguce su razlike u decimalima zbog matematike.

Resio sam to tako sto exportujem celu karticu u excell file, a tamo se to lako izracunava i onda vratim sve u access report. A racunam sve na 4 decimale i radi dobro..

da li neko ima rešeno u query obračun prosečne cene robe

Imam jedan primer, ali kao što je rečeno, korišćenje prosečne cene je malo složenije jer posle svakog ulaza robe prosečna cena se menja.

da menja se kada ima ulaz i to je ok ali prosečna cena se menja kada ima izlaz

Valjalo bi da se definiše ta prosečna cena, mora da postoji neko pravilo računanja. Mi ovde možemo primenjivati pravila, ne i da ih definišemo. Ako imaš nešto tako dobro bi bilo da prezentiraš ovde.

Mozda nesto ovako?

ulaz izlaz saldo cena
8298 0 8298 211.25
0 100 8198 211.25
0 50 8140 211.25
... ... ...
0 500 4772.25 211.25
6000 0 10772.25 213

Ulaz u magacin od 8298kg po ceni od 211.25, zatim sledi izlaz od 100kg po istoj ceni od 211.25, zatim opet sledi izlaz...
Bitan je zadnji saldo pre novog ulaza:

4772.25 x 211.25 = 1008137.8125

Sledi novi ulaz po novoj ceni:

6000 x 213 = 1278000

Racunamo novu prosecnu cenu :
1278000 + 1008137.8125 = 2286137.8125

2286137.8125 / (4772.25+6000) = 212.22

Znaci, nova prosecna cena je 212.22 i sledeci izlaz bi bio po toj ceni.

Mozda je to objasnjeno u gore spakovanom fajlu ali nemam access