Da bi primenio sve mogućnosti Access-a, model podataka bi trebalo da bude bolji. Konkretno za ovaj slučaj, ulaz i izlaz bi trebalo da su posebni atributi (kolone u tabelama). Pogledaj primere na ovoj temi: http://www.elitesecurity.org/t471629-0#3383047

@nemkeal, ako se i dalje radi o varijanti magacina restorana koji smo radili u februaru, onda Vam ovaj model uopste ne odgovara. Zasto se niste potrudili da nastavite rad na modelu koji Vam je tada predlozen?

Hvala @NenadMarkoni nisam stigao puno sam posla imao. Sada preko zime nastavljam sa radom, družićemo se :D

Pokušaću sada da razvijem novi model za magacin.

Zasto mislite da onaj model ne valja? Uradjen je prema Vsem opisu realnog sistema(onako kako treba). Magacin robe-repromaterijala zaduzujete otpremnicom dobavljaca a rezduzujete kroz dnevni promet prema specifikaciji-normativu za jela. Ostaje "samo" da se aplikativno realizuje.

@nenadmarkoni Dobar je onaj model planiram dalje da nastavim sa radom ovih dana. Trenutno mi se pojavila potreba za drugom bazom magacina.

Znači, moram da pravim novi relacioni model.

@Getsbi jel može ovako relacioni?

Bolje je što se tiče ulaza i izlaza robe. Sad pogledaj temu koju sam ti predložio. Obrati pažnju na query QUplataIsplataStanje i kako su Nenad i Slobodan rešili izračunato polje Suma. Kasnije formu veži za izvor podataka tog querija.
To bi bilo rešenje tvog pitanja sa početka teme. Kako prikazati stanje nakon promene? Nešto kao Runing Sum Over All i Runing Sum Over Group kod izveštaja.
Ovo smatraj kao vežbu i nastavi da razvijaš model koji ti je Nenad započeo.

@nemkael , u temi http://www.elitesecurity.org/t411739-2 sa kojom sam ja ušao u svijet baza podataka imate doradjenu bazu iz teme Magacin ali prilagođenu mojim tadašnjim potrebama ( ne radi se o magacinu) gdje prilično sve funkcioniše po pitanju stanja proizvoda i ostalog.