Prvo morate rjecima opisati sam proces. Odgovori koje date otvorice neka nova pitanja. Kada se sve razjasni do kraja tek mozete krenuti u formiranje tabela i relacija.

Hvala što ste se javili da pomognete, pokušaću bliže da vam objasnim o čemu se radi. Možda je najbolje da vam kažem kako se sada radi.

Trenutno se radi tako što mi šef kuhinje preda broj obroka koliko je danas pojedeno npr. 12 bečke šnicle uz to ide i lepinja i salata. Ja sam se nekako snašao i u excellu sam napravio da računa ali mislim da ovako bi mi se mnogo olakšao posao i mnogo manje bi se greške pravile. Ja onda u excellu imam definisane normative za svako jelo, lepinju, salatu i kucam broj obroka i excell mi sračuna i oduzimam od magacina (za koji dobijam i ulaze a izlaz mi je ono što mi sračuna po broju obroka) npr. 12 bečke šnicle tj. po normativu:



Bečka šnicla:
svinjsko meso 120g
Ulje 25ml
Brašno 8g
Mleko 10ml
prezla 15g
so 0,7g
jaje 1/3

lepinja:

toliko
toliko
toliko
toliko

Salata:

toliko
toliko
toliko


Svaku stavku množim sa 12 i rezultate koje dobijem oduzimam od namirnica u magacinu jednu po jednu (1,44 kg mesa, 96g brašna itd...). Kao izlazni dokument dobijam dnevni obračun stanja u magacinu, koji bi trebalo da bude tačan sa stanjem u magacinu, naravno postoje odstupanja sa realnim stanjem ali ne bi trebalo velika da budu.


Tako da ovde bi trebalo da ja napravim ulaz u magacin, zatim na taj i taj datum izdato toliko obroka tog i tog jela i toliko lepinja i toliko salata onda na osnovu normativa jelo, salata, lepinja koji sam prethodno uneo, pravi proracun, pravi dnevni obračun i skida sa magacina tj pravi izlaz iz magacina.

Mislim da sam uspeo koliko toliko da približim.

Nije bas najbolje objasnjeno, al od necega se mora krenuti. Koliko sam shvatio postoji magacin repromaterijala i kuhinja. Ocigledno radi se o restoranu. Za magacin postoji ulaz i izlaz. Za kuhinju takodje. Ulaz repromaterijala u magacin se mjeri u nekoj jedinici mjere. Izlaz prema kuhinji vjerovatno ide u istim mjerama. Kuvar ce zaduziti litar ulja, nece 20 ml. Isto je i za drugi repromaterijal. Prezla npr. Pakovanje 500 g i kao takvo ide na zaduzenje u kuhinju. Ovde se mora predvidjeti i otpis( pojeo miš, probusila se kesa sa prezlom, prosulo se ulje...)
U kuhinji se spremaju jela od tog repromaterijala.
Za svako jelo ima normativ. Taj normativ je vjerovatno cisto podatak za kalkulaciju. Nekad se utrosi malo manjr, nekad malo vise ali sumarno to jr to. Ovaj normativ je u manjim jedinicama mjere.
Kada se uvodi novo jelo pravi se normativ za njega.
Jela su klasifikovana po vrstama:
Supe, corbe
Jela sa rostilja,
Pecenje...
Peciva
Salate
A neke imaju i podkategorije:
Dezert(poslastice)
-Torte
Spanski vjetar
Moskva torta
Kolaci
Tulumba
Baklava
Palacinke...
Kuhinja evidentira koliko je kojih jela izbacila
Prema normativima za ta jela znamo koliko se cega utrosilo taj dan.
Da li se neutroseno vraca u magacin?
Da li je ovako ili ne, da bi isli dalje?

Tako je, postoji magacin repromaterjala (Ulaz/izlaz: brašno, ulje, sećer, meso, so... u merama jedinica), i kuhinja (izlaz:jela u obrocima)

Magacin ima ulaz i izlaz, ulaz je od dobavljača dok je izlaz ka kuhinji, odnosno direktno utrošak po normativu, bez škarta. Škart je meni kao obračunskom radniku nebitna stvar, dakle koliko izađe iz magacina toliko se i utroši.

Iz magacina izlaze jedinice mere, a iz kuhinje su nam obroci izlaz komadno jelo po jelo.

Naravno ne poštuje se uvek normativ, ali što se tiče mog obračuna to mi je nebitno, ja računam striktno po normativu, toliko toliko toliko, da li se njemu pojavljuje višak ili manjak to kontroliše neko drugi, nije moj deo posla, ja dajem kontroloru kuhinje on proverava šta nedostaje šta je višak, ja radim samo sa brojevima.

Pa meni trenutno kako radim klasifikacija jela ništane znači, nadjem jelo ukucam broj obroka za svaku namirnicu posebno i on mi računa utrošak po svakoj namirnici pa copy/paste u drugi sheet i oduzima mi sve to od magacina. Hoću ovako u access da ga uradim da bi mi malo olakšalo i ubrzalo posao, može to i bolje u excellu da se uradi ali kada već radim daj da ga odradim kako treba.

Kako sam ja razumeo ovo što si mi rekao, trebalo bi da postoje 2 magacina jedan centralni koji duži magacioner i izdaje materjal kuvaru i drugi u kuhinji koji duži kuvar? Kod mene ne funkcioniše tako ili barem funkcioniše od onog dela magacina u kuhinji.

Model baze podataka (finkcionalni i informacioni model), i ono sto ce on obuhvatiti zavise od interesa posmatranja realnog sistema. Kazete da ste obracunski radnik i da Vam treba baza za Vas deo posla. Znaci u sustini Vas ne zanima ni magacin. Vjerovatno u magacinu postoji radnik koji prima robu u magacin i izdaje je kuhinji. Koji dokument od njega dobijate? Kazete ne zanima Vas ni kuhinja. Samo obracun. Koje dokumente dobijate od kuhinje?

Izvinjavam se što nisam odgovarao neko vreme.


Interesuje me magacin, dobijam ja ulaze za magacin napomenuo sam to, ne dobijam izlaz kao trebovanje repromaterjala (kuvar je uzeo ovoliko spremio ovoliko razlika je škart) , već izlaz iz magacina mi je obračun na osnovu normativa i broja obroka, što bi značilo u ovom slučaju da nema škarta (višak materjala) Koliko se trebuje toliko se utroši (spremi).

postupak rada je sledeći, kuvar ode u magacin uzme repromaterijal za 3 karađorđeve i spremi.

Ok. Znači magacin i kuhinju posmatramo kao jedno.
Kako tece proces nabavke odnosno ulaza u magacin? Da li imate dobavljace, koji dokumenti se javljaju u tom procesu?

Tako je :)

Ima jedan dobavljač i kada se isporuči roba dobija se otpremnica.

Onda kuvar daje meni tu otpremnicu, ja u exceluu dodajem stavku po stavku, u shettu koji imam kao magacin. Onda na osnovu broja obroka i normativa računam potrošnju i skidam sa magacina.

Moze li u buducnosti biti vise dobavljaca?
Ono sto ja po dosadasnjoj prici pretpostavljm da Vam treba su entitti:
Dobavljac
Otpremnica
Proizvod
Jedinica mere
Jelo
Normativ
Dnevni obracun- unos prodatih jela
i potreban nam je neki konverter jedinica mere gdje bi definisali odnos jedinica mere.

Ne neće biti više dobavljača, barem ne bi trebalo.

tako je to bi mogli da budu entiteti.

čitajući forum i primere ovo je neki početak kako sam ga ja zamislio

https://onedrive.live.com/redi...7UhMXmsd8&ithint=folder%2c

Nisam umeo drugačije da privežem fajl.


Dakle imamo ulaz u magacin, koji je sa magacinom povezan sa UlazRobeID, izlaz je povezan sa Šifra to mi veza sa svakom daljom tabelom Obračun i normativ . Jel može ovo ovako?

tblDnevniObracun ima stavku TblStavkeobračuna, jer hoću forma da mi bude tako da može da se vidi šta se skida i po mogućnosti ako je po želji kupca promenjen normativ da može da se izmeni, dođe neko kaže stavite mi više origana ili nečega više ili dešava se neko da dođe traži da mu se spremi jelo bez nečega, alergičan je.

tblJela se vezuje sa tblNormativ preko ID-a, sa obračunom mi nije jasno kako da povežem, mislim da malo mešam babe i žabe :)

Ono što me dalje muči jesu upiti, koje još uvek razrađujem kako da postavim.

Jel sam na dobrom putu?

Trenutno nisam uz racunar pa ne mogu pogledati do veceras. Mislim da sa prepravkom normativa mozete samo zabrljati. Ako Vas ne zanima manjak, tj. otpis zasto bi se hvatali za malo vise origana, kecapa, luka...:-) tj. visak treba da pokriva manjak.

Stara narodna "Veži konja gde gazda kaže" :)


Ali hajde da probamo tako za početak.

Ako mozete konvertujte fajl u .mdb jer jos uvjek radim sa Office 2003. Kada napisete odgovor imate ispod odgovora Upload uz poruku. Prethodno spakujete fajl pomocu Win zip ili win rar i zakacite. Bilo bi dobro ako mozete skenirati dokumente koji se javljaju u sistemu.

Ja nemam ovu opciju

Izgleda sam neki napredan korisnik :)

Dodao sam na onom linku.

Iz gornjeg menija odaberi FAQ (česta pitanja). Pročitaj tačku 22. za kačenje fajla. Arhiver moraš da imaš (.zip ili .rar). Ako is u Access 2007 ili veći potraži: File, Save & Publish, Save Database As, odaberi format 2002-2003. Snimiće se kao .mdb.

Moj predlog baze. U Otpremnici i DnevniPromet predviđen je govoreći ključ koji se gradi od tekuce godine i rednog brojača. U ProizvodJedinicaMere definise se manja jedinica mere ali bice uslovljena tako da jedinica mere koja je definisana u tabeli Proizvod mora biti ista kao i NadredjenaJedinicaMere u tabeli JedinicaMere za odabranu jedinicu mere. Nisam znao kako bi drugacije rješio to sa jedinicama mjere. :-/

Nenade, pogledao sam .mdb fajl.
Mala sugestije oko termina. Jelo je gotov proizvod odnosno ono što se služi gostu. Ono što je proizvod kod tebe, je repromaterjal ili samo materjal.
Po meni, ako se nešto od materjala promeni u normativu, bilo po pitanju količine ili po pitanju sastojka, to je novi proizvod (tvoje jelo). To što ćeš dobiti novo JeloID za palačinke sa upotrebljenim jednim jajetom umesto dva (kuvaru je ispalo zadnje jaje) ne treba da te brine. Pametno si u tabelu Jelo dodao SifraJela koja se ponavlja. Jedino bih napravi novu tabelu ŠifarnikJela sa SifraJela i NazivJela, te spojio sa trenutnom tabelom Jelo zbog redudance (suvišnog ponavljanja).
Rešenje za jedinicu mere vidim u tome da ukineš tabelu ProizvodJedinicaMere i oslobodiš se stresa, jer u bilo kojoj proizvodnji postoji nešto što se zove RASTUR ili kaliranje. Zadrži samo postojeću vezu JedinicaMere - Proizvod.

U tom slucaju jedinica mere i za ulaz u magacin mora biti manja jedinica, npr. za brasno g(gram)....
Mislim da su na otpremnici vece jedinice mere a pri razduzenju kroz normativ i prodaju jela koriste se manje jedinice , zbog toga sam i uveo sporni mjesoviti entitet cije popunjavanje moze i da se automatizuje.

Mislim da za tim nema potrebe. Osnovna jedinica za masu (čitaj težinu) u međunarodnom SI (International System of Units) je kilogram. Zapremiš tonu brašna, napišeše 1000 kg. Potršiš 250 grama za smesu od 15 palačinki, skineš 0,25 kg. Za jednu palačinku 0,017 kg.

:-) Potpuno jasno. Hvala!
Evo zašto je potrebno iskustvo za projektovanje informacionog sistema.

Po @Getsbi-jevim preporukama izmjenjeno.

Bazi koja je u NormativBE fajlu i koja sadrži samo tabele dodat je FE fajl u kom su linkovane tabele iz BE fajla i koji će sadržati ostale elemente aplikacije: Upite, Forme, Module, Reporte...
U FE dijelu je dodata i jedna tabela, tblErrorLog u koju će se upisivati istorija grešaka.
Tabela Godina će se popunjavati pomoću dva makroa: Autoexec i GodinaDodaj i akcionog upita QGodinaDodaj. Oni će automatski dodati novu godinu kada se pojavi u sistemskom datumu računara. Podatak o tekućoj godini će nam trebati za onaj govoreći ključ koji sam pomenuo u tabelama Otpremnica i DnevniPromet.
@nemkeal, kada skinete ove fajlove u prilogu potrebno je ući u FE fajl i ručno prelinkovati tabele iz BE fajla. Prije prelinkovanja javiće se poruka o greškama u Makoroima i to je normalno. Samo preskočite.

@nemkeal odradio sam Vam jedan dio aplikacije. Imate mnogo elemenata koje treba da uočite i ostalo odradite prema tome. Srećno!

Zahvaljujem Nenade, ovo nije lako kao što sam ja mislio. Ima dosta detalja, radim polako valjda ću da uspem do kraja nekako.

Javljam se ovih dana

Slika modela koji sam zakačio Vam može dosta pomoći. Relacije između tabela su prikazane linijama koje povezuju tabele. Tačka je okrenuta prema podređenoj tabeli. Za one tabele koje imaju ispod sebe podređenu tabelu pravi se datasheet ili tabular (countinious) forma u kojoj se vrši pretraga i columnar forma za prikaz. Za one koje su samo podređene dovoljna je samo datasheet ili tabular (countinious) forma jer su one uglavnom subforme neke nadređene forme i one su obilježene zaobljenim ivicama. Pretraga u datasheet ili tabular (countinious) formi se vrši na desni klik miša nad nekim poljem koje se želi pretražiti ili filtrirati gdje dobijate opcije za pretragu. Na isti način poništavate pretragu- filter.
Neke od nadređenih formi su samo šifarnici, kao što je JedinicaMere i njoj možete pristupiti dvoklikom na polje podređene tabele- forme koje je vezano za taj šifarnik. Slično je i sa tabelom Repromaterijal mada ćete kasnije kroz nju dodati pristup formi za prikaz stanja Repromaterijala-Magacina, a može se dodati i na njoj samoj. Ključ na formama
je programerski dobijen Autonumber. Dobija se kombinovanjem sadržaja sakrivenih polja Broj koje možete pronaći u Design modu, default vrjednosti pojedinih polja i kodom na tri događaja : On Curent, After Insert i Before Insert forme. U formama(tabelama) Otpremnica i DnevniPromet ovaj ključ je malo komplikovaniji jer se dobija kombinovanjem podataka u polju Godina koje prikazuje najveću Godinu iz tabele Godina i najveće vrijednosti rednog brojača za tu godinu uvećanu za 1. Ti podaci se takođe kombinuju u polju Broj i kroz pomenute događaje na formi. Kada se pojavi nova godina u sistemu automatski će se upisati u tabelu godina, a redni brojač će krenuti iz početka.
Brisanje i unos zapisa je omogućen kroz neke forme a u nekima je zabranjen. Sama relacija i uspostavljeni referencijalni integritet podataka neće dozvoliti brisanja ako postoje vezani zapisi u drugim tabelama. Brisanje zapisa se vrši tako što se obilježi zapis i pritisne Delete na tastaturi. Nisam odredio Default vrijednosti i opseg vrijednosti koje polja mogu uzeti kroz Validation rule, ali to možete odraditi kad se postigne puna funkcionalnost.

Nasao sam malo vremena, pa evo...
Izracunavanje stanja nisam bio uradio dobro pa sam prepravio...

_{[Ovu poruku je menjao nenadmarkoni dana 28.08.2016. u 09:36 GMT+1]}

Pozdrav,
pratim ovu temu pa bi se nadovezao sa novim pitanjem/idejom.

Pretpostavimo da se proces satoji iz više faza pripremanja jela pa imamo i određene poluproizvode (nedovršene proizvode) sa svojom šifrom i pripadajućim normativom za repromaterijale.
Hipotetski, gotovo jelo bi se sastojalo od 2 poluproizvoda i 3 repromaterijala. A svaki poluproizvod bi imao svoj normativ koji bi sadržavao po x repromaterijala sa pripadajućim količinama.

Zamolio bi nekog iskusnijeg da da svoje viđenje i razmisljanje o modelu podataka za ovaj scenario.
Unaprijed hvala

Ovaj model može da „istrpi” takav scenario. Recimo da praviš pitu sa sirom. Iako kore za pitu gledaš kao poluproizvod, one mogu da budu repromaterjal za to jelo bez obzira da li ih kupuješ od dobavljača i provčeš preko otpremnice ili ih praviš iz prethodnih sopstvenih zaliha reproaterjala (brašno, jaja, so, ....). Jedino će u tabelama Jelo i Normativi biti dve različite šifre i dva različita JeloID. Pita sa kupovnim korama i pita sa domaćim korama.

Hvala Getsbi na podjeli mišljenja i odgovoru. Još jedno pitanje u vezi s ovim.
Na koji način bi onda za gotovo "jelo sa domaćim korama" dobio sve repromaterijale jednim upitom. Logička postavka je da prvo treba da na osnovu prve šifre gotovog jela učitam sve repromaterijale koji idu direktno u jelo, pa onda sve repromaterijale iz poluproizvoda na osnovu šifre poluproizvoda koja opet ima svoj normativ. Ako je ispravna logika, kako bi ovo tehnički riješili?

Nismo se razumeli. Ovo je model za preduzetničke radnje. U restoranima se ne vodi evidencija o sopstvenim poluproizvodima. Ako te brine tačnost potrošnje repromaterjala i slaganje na inventaru, onda za to postoji „kalo” ili „rastur”. Postoji neki dozvoljeni procenat za to, koji inspekcija priznaje. Ili se piše zapisnik.
Ti u proizvodnji ne praviš poluproizvod koji ćeš da ugradiš u sopstveni proizvod pa ga onda vodiš u vedenciji, već kompletan normativ za tvoje jelo ima sve sastojke iz repromaterjala. Receptura ili normativ se vodi za porciju. U ovom slučaju JeloID. Broj porcija je u tabeli „SpecifikacijaPrometa” za dnevni promet.

Znači u piti sa domaćim korama ne postoji poluproizvod.
JeloID = 1 Pita sa kupovnim korama:
(kore 50 gr., sir 70 gr., so 0.5 gr., jaja 0.5 kom. kisela voda 0.3dl. )
JeloID = 2 Pita sa domaćim korama:
(brašno 50 gr., 0.3 jaja , so 0,3 gr., topla voda 0.5 dl., sir 70 gr., so 0.5 gr., 0.5 jaja, kisela voda 0.3 dl.)

Evidencija o poluproizvodima bi mogla da bude obaveza za D.O.O. Ali ni za to nisam siguran.

Isprobavanje recepta ne preporučujem.