Racunanje prosecne nabavne cene u reportu.

Kako u reportu (Kartica robe) izracunati prosecnu nabavnu cenu po kojoj se razduzuje magacin. Ta cena se formira svaki put kada imamo ulaz robe (Vrednost na Stanju+Vrednost iz tog Ulaza)/(kolicina na stanju +kolicina iz ulaza). Ne znam kako da racunam vrednost na stanju, treba da bude nesto kao running sum polje nz(zaduzenje)-nz(Razduzenje), tako racunam kolicinu na stanju, ali mi za polje Razduzenje treba ProsecnaCena.
Stavicu posle primer ako nije jasno

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.

Potpis

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

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.