Caffe - praćenje robe

To se treba odraditi kako knjigovodja kaze (a on uporno cuti i sve mu dobro) ili gazda (koji to ne mora da zna jer placa knjigovodju i tebe).

Moze kako god hoces ali uvek ispadne neki problem, recimo toceno pivo po kalkulaciji je 90 dinara litra. A prodaje se na manje pa 0,3 bude 35 dinara, 0,5 bude 50 dinara i slicno. Ugostiteljski standard je 7 g espreso kafe po solji. Nema dve iste boce od litre, a prodaje se po 0,03.

---

Pa dobro, no ja tu bas i ne vidim neki problem, ako se znaju normativi.
A ako litra pive košta 90 dinara, onda ne može 0,3 l koštati 35 dinara već samo 27 dinara. Zakon kod nas ne dopušta drukčije.
A gotovo je ne moguće da se dogodi da ne bude razlike u stvarnom stanju i stanju po knjigama, pa za to postoje inventure gdje se stanje usklađuje.

Ne misliš tako? :-)

:-(
Slutio sam da ce nesto ovako da se desi, i nisam se usudjivao da pitam. Zato se u analizi nikad ne razgovara sa jednom osobom, vec sa vise njih, od menadzera i/ili vlasnika, do kelnera, knjigovodje i svih ciji rad je u vezi sa buducim sistemo. I zato to traje duuugo i spominu se Nove godine. Brzo bismo napravili sistem koji bi zanemario ovo sto je pomenuto u poslednja tri posta. nema nist o tome u Mission objectives, nista u Busimess rules (da li imamo to uopste?)

Danas sam ceodan posastancima, pa samo ovoliko. Molim da nastavite da razradjujete tematiku tipa 'narucujem na gajbice a prodajem na casice'. ako to dobro odradimo, sistem ima enke sanse za uspeh. Ako ne, niko ga nece hteti.

Da, slažem se da je uvijek bolje imati više mišljenja. :)

Ja ne znam kako bi bolje obrazložio kasu.
I dal je problem napraviti tablicu sa normativima koja bi se vezala nekako na artikle, te bi se tako razduživalo?
Znači, ja naručim npr. kilogram kave, i za to tako napravim kalkulaciju. A iz kilograma kava izađe 150 kava. I sad je pitanje kako to najbezbolnije napraviti?
Osim kave kritični artikli su bamus (1 cola + 0,10 vina), gemišt (0,10 vina + 0,10 min. vode) i razni koktela kao juice-vodka (0,10 juice + 0,03 vodka).

Kad smo već kod Mission objectives i Busimess rules - vas dvojica ste se složili da je za knjigu URA i IRA dovoljan report.
To mi se činilo sasvim logički taj moment, no ja sam u međuvremenu pregledao par knjigovodstvenih programa i svaki ima "Prijenosu u knjigu URA ili IRA". Ja kontam da je to više zbog ljudske pogreške. Dakle onog časa kada smo mi isprintali i predali u poreznu upravu obrazac PDV-a (razlika URA i IRA), taj obrazac mora ostati isti i nakon godinu dana kada ga pozovemu u programu. Mora se onemogućiti slučajno mjenjanje tog obrazca. Dakle, netko bi mogao dobiti zakašnjeli račun i tada umjesto da ga uvede u trenutni mjesec uvede ga u prethodni i tada bi taj report bio drukčiji, što ne smije biti slučaj. Ili opet ako se izbriše slučajno račun iz prošlog mjeseca.
Također bi brisanje smijelo biti dopušteno samo u tekućem mjesecu.

Što mislite o tome?

Vise glava vise zna :-)

U poslednjem postu Vmaotic je zapazio dva interesantna pitanja.
1) sta da radimo sa 'slozenim' artiklima, tipa spricer, gemist (znate li da spricer NIJE isto sto i gemist?!), bambus, kao i razlicitim jedinicama mere za ulaz i izlaz robe (ulaz id e na flase, od 0.7 lit ili 1 lit aprodaje se na casice od 0.05, ili je ulaz u gajbicama i izlaz flasa). I jedan i drugi problem su resivi, mada je malo slozeniji data model za razumevanje. Sta da radimo? Mozemo da zakomplikujemo model i napravimo pravu stvar, ili da ignorisemo problem i ostavimo ga za neku sledecu verziju. Ako ignorisemo stvar, dobicemo ipak aplikaciju koja je lep skolski primer, pojednostavljeni, iz koje se mogu nauciti osnovni principi, bez mnogo detalja i konkretnih resenja jer je to razlicito od slucaja do slucaja. medjutim, trenutno na forumu ide i tema 'magacinsko poslovanje', a ovaj 'kafic' je jedna prosirena varijanata magacinskog poslovanja, i ja sam malo zanemario magacin zbog ove teme. kako bi bilo da za par dana zastabnemo sa ovom temom, mislim ja zatanem, ne diram model i aplikaciju, ali vas dvojica nastavite razradu problema? Za to vreme cu da zavrsim 'magacin', u minimalnom obliku, da ne bi ponavljai pricu ovde o nekim zaista zajednickim delovima. Kad zavrsim minimalni magacin, vracamo se na ovu temu i odradimo je profesionalno, kao da radimo za pare, za poznatog kupca? ne brinite, nece moci ni jedan gazda da ovo naprosto skine sa foruma i koristi, suvise ce biti komplikovan set up da bi se tek tako koristilo.

2) Knjiga URA i IRA, report ili cuvati podatke? Osetljivo pitanje. Razlog cuvanja je kako kazes 'a sta ako se podaci promene kasnije. Znaci, pravi problem je promena podataka. Ako se podaci ne promene, knjiga ce uvek izgledati isto. Ja bih uradio dvostruku zastitu. Prvo, sprecimo promenu podataka posle nekog momenta, tako sto ih na neki nacin zakljucamo, pokazacemo kako. Drugo, svakoga dana zaita odstampamo knjigu i cuvamo papirnu kpiju na sigurnom mestu. odstampamo i detalje o prometu tog dana, pa i to cuvamo i ne diramo, za zlu ne trebalo. Umesto stampanja, mozemo da kreiramo PDF fajlove iz Accessa, pokazacemo kako.

Sta mislite?

OK! Ja sam za. :)

Do završetka teme magacin još ću malo prozujati po nekim programima da vidim kako oni imaju riješeno neke stvari i ako nam nešto još zatreba.

I ako dragancesu imati nešto za dodati, pošto je, kako je rekao, imao iskustva sa kafićima.

Dajte mi nekoliko primera jedinica mere na ulazu i na izlazu robe za kafic. Na primer

Ulaz:
=======
Flasa 0.7
Flasa 1.0
Flasa 2.0 lit
Flasa 0.5 lit
Gajbica 12 flasa od 0.5


Izlaz:
=====
Pivo 0.5
Konjak 0.05
Dupli Konjak ili Konjak 0.1
Spricer 0.2 (=50 voda +50% vino)


Zatim, kako se knjize specijalni slucajevi, na primer, razbila se flasa i propalo pola litra konjaka? Ili, gazdina cerka malo zakidala na spriceru, pa za 20 spricera potrosila 0.5 litra vina umesto 1 litar?

Evo ovako:

Likeri mogu biti u flaši npr. 0,7 ili od 1 l (tako bar ja imam), a kada se prodaju mogu da se prodaju kao 0,03 ili 0,05 (mali i veliki)

Piva ulazi po komadu i izlazi po komadu, dakle tu nema frke, osim točene pive koja ulazi kao bačva od 30 l i opet izlazi kao pivo 0,20, 0,30 ili 0,50 l.

Bambus izlazi kao 1 cola + 0,10 vina, gemišt kao 0,15 vina i 0,05 min. vode (malo je jači :)), a kada se prodaju neki kao kokteli - npr. juice vodka, tada prodamo 0,10 juice (iz litrene flaše) i 0,03 vodke ili štok cola - 0,10 cola (iz bačve, kao i piva) i 0,03 štok.

Ali ne smije da se za te koktele proda pola nekog soka koji je ušao u komadu npr. cola 0,25 flaša ne smije da se toči na pola.

Iz kilograma kave izađe 150 kave, iz jedne tube šlaga 10 kom.

Ako se nešto razbilo tada se radi "zapisnik o otpisu" i to na kraju jednog tromjesječja, te se za tu količinu i iznos smanjuje zaliha, ali ne ide u prihode kao da smo to prodali, već u otpis.

A slučaj br. 2 je rijedak jer obično si konobarice uzmu taj višak tako da nekom ne izdaju račun za preostalih pola litre vina u ovom našem slučaju. :)

Eto!

Evo, ja sam malo proučio par programa za knjigovodstvo i evo još jedne stvari koju nismo uključili u svoj sistem - prijelaz iz godine u godinu. Jednom kad napravimo završni financijski izvještaj za jednu godinu više ne smije biti dopušteno mijenjanje podataka. Plus toga gdje ćemo upisivati početno stanje kada se počnemo koristiti programom. Već postoje artikli u našem kafiću.

1. Da li bi trebali imati jednu tabelu gdje bi upisivali početno stanje po inventuri?

2. I da li bi po završetku godine trebali zaključiti tu godinu i opet stanje na zalihi prenijeti za iduću? Zapravo, da li bi godine trebale biti odvojene jedna od druge?

U gotovo svim programima koje sam ja vidio postoji prijenos u novu godinu.

Što mislite?

Prenos iz godine u godinu, mesecni izvestaji, cuvaju se u papirnom knjigovodstvu jer je nemoguce obezbediti dinamicki tacan prpracun u bilo kom momentu. Tako se negde zapisuju sumarni iznosi po danimai to se cuva. Pa to isto za dati mesec. Zasto? Relativno je lako napraviti dnevni izvestaj o necemu i promet od celog dana zameniti jednim iznosom, koji se upise u mesecni list. Na kraju meseca, saberu se dnevni zbirovi i eto mesecnog zbira. Na kraju godine, sabere se 12 mesecnih zbirova i eto godisnjeg zbira. To sve ima smisla kad se radi na papiru i sabira se rucno (upotreba masine sa trakom ili digitrona je jos uvek RUCNO sabiranje ). Ideja je da se veliko sabiranje razbije na puno malih podzbirova koji se potom koriste za 'godisnji' obracun. Onda je lepo (i lakse) poceti sledecu godinu od nule, cisto zbog lakseg sabiranja.

U stvarnom zivotu, stvari su komplikovanije. Poslovanje kafane je kontinualno, ne prekida se na kraju godine, da bi s epocelo od nule 1. Januara. Dnevno brojanje prodatog pica ima smisla u neke obicne dane. Kako izgleda dnevna inventura na dan 31. Decembar? Sta ako kafana radi i posle ponoci? Da li u ponoc sankeri prekidaju rad da bi prebrojali pivo? Ako zatvore u 4 ujutru, da li tada broje pivo da bi u 11 sledeceg dana poceli od nule?

Uvodjenje racunara u proces pracenja izbacuje sve ove medjukorake iz radnog procesa. Ako zelis da vidis zbir necega za neki period (dan, mesec, godinu) jednostavno ces napraviti kveri ili printati reprt koji radi bas to - sumira neke podatke za period OD DO.

Iz ovoga sledi da neme potrebe razdvajati podatke po godinama. Na sta bi to licilo - po jedan MDB fajl za svaku godinu? Ili svaki mesec? Taman posla. Ako neki podaci zastare, mogu se arhivirati. Na primer, sv etransakcije starije od 2 godine se arhiviraju i zamnjuju jednom koja sadrzi zbirne vrednosti. U tom slucaju se pravi fiktivni dokument i unosi se u bazu podataka. Zatim se podaci prebacuju u arhivski fajl. Tako imamo dva afajla - operativni i arhivski. Imam jenog klijenta koji je hteo to da radi, posle 5 godina da prebaci podatke u arhivu i nastavi od nule. Posle dva dana je trazio podatke nazad. Zasto? Tad je shvatio da svrha upotrebe kompjutera u knjigovodstvu NIJE da olaksa posao kjigovodji, nego da omoguci bolji uvid u poslovanje gazdi. A za uvid, trebaju mu podaci. Ako gazda zeli kompjuter samo da bi manje platio knjigovodju, onda imamo delimicni promasaj.

Naravno da podaci moraju biti stabilni i zasticeni. U Accessu, to se postiz etako sto se za Prijemnice/Dostavnice i ostale dokumenta uved logicko polje IsLocked i kad tu stavimo vrednost TRUE, onda aplikacije kojepristupaju bazi ne mogu da menjaju/brisu/ddaju podatke tom dokumentu. Znaci da i aplikacije moraju da budu pametne za toliko. U velikim bazam, tipa ORACLE i MS SQL zakljucavanje je moguce na nivou tabela, pa niko ne moze ni rucno da promeni podatke. U Accessu, direktna promena u tabelama je uvek moguca.

Zato su izmisljene security, permissions i slicno, da se lako kontrolise makar KO moze da menja podatke, ako se ne moze spreciti promena u tabelama direktno. Access security NIJE izmisljena da progarmeri stitili svoja remek dela od neovlascenog kopiranja. Zar zaista mislite da su vasi programi toliko dobri da bi neko drugi pozeleo da ih kopira i koristi? A i ako pozeli, mislite li da su programi pisani tako dobro da omogucuju laku distribuciju, instalaciju i upotrebu? Ja nikada nisam zastitio ni jednu svoju aplikaciju, ponaked sam pravio MDE, samo zato sto se teze 'get corrupted' i nikada ih niko nije ukrao. Ako i jeste, nije uspeo da je upotrebi.

Znaci, stavri treba postaviti na svoje mesto:
1) aplikacije za magacine, kafice, biblioteke se ne prave da bi onome ko radi taj posao bilo lakse, to je samo besplatan dobitak, prave se da bi rukovodstvo firme moglo bolje da vodi posao
2) zastita potem Access security nije da bi se stitila aplikacija od kradje, nego da se na nivou tabela zastite podaci
3) medjurezultati se u kompjuterskim resenjim NE CUVAJU, ako su podaci stabilni i ne menjaju se , onda ce medjurezulatti uvek biti isti, kada pozelimo da ih vidimo

Nego, mi iamo da resimo dva problem pre nego sto nastavimo sa IS Kafic
1) problem spricera (pola vino, pola voda)
2) problem pakovanja (ulaz u flasam ili bacvama od 30l izlaz u casicama od 0.03)

Ima te li jos neke misli na ovu temu? Ja nisam radio kafice i oslanjam se na ono sto mi kazete. Ako mi ne kazete sve, zavrsicemo sa nepotpunom aplikacijomkoja ce stoga biti bezvredna. Jedina korist ce biti sto cemo mozda svi nesto nauciti, ali na kraci rok ucenje nije isplativo.

:-)

Dobro, slažem se sa tobom.

Nisam ja zabrinut da će netko ukrasti aplikaciju. Kada sam pristupio forumu rekao sam da ću sve što napravim ostaviti na forumu, no koliko će tko od toga imati koristi to je pitanje :-))

Nego, da mi imamo problem sa normativima. Prvo sam pomislio kako to neće biti problem, no sad moram priznati da pojma nemam kako to pametno odraditi.

Ti imaš nekih ideja?

Što se cijele aplikacije tiče, moglo bi se dodati da može postojati više ugostiteljskih objekata unutar jedne firme.

Neznam što više dodati. Ako itko prati ovu temu i ako misli da smo nešto propustili u prethodnim raspravama bio bih zahvalan da kaže.

:-)

Sta su normativi? Je l' to ono o spricerima, koliko sode i kolko vina?

Da, upravo to. :-)

I imaš kakvu ideju?

Hej je li ikad iko ovako nesto napravio da se download pa da se vidi kako je to uradjeno.

---

To cemo, nadamo se, do kraja godine zavrsiti. A imas na prvoj stranici ove teme jednu moju bazu na tu temu, no ne znam dal ces imati previse koristi od nje jer nije dovrsena. Ne znam sve stvari, pa kopam i ucim tu po forumu. No, mozes vidjeti, mozda ces biti malo pametniji. :-)

Kojim cemo sistemom?

Dal ce Zidar predloziti strukturu, pa cemo dalje ili?

@Zidar: ne znam dal si vidio zadnji post na temi maloprodaje jer smo istovremeno odgovorili na toj temi?

Evo nas nazad u kafcu, bas kako i prilici pred Novu godinu.
APlikacija od koje cemo da podjemo jeste ono cime smo zavrsili Maloprodaju robe.
Evo dakle ista aplikacija.

Treba da dodamo opciju za upravljanje mesavinama (spricer = vino + soda, gemist = vino + kisela voda, bevanda = vino + obicna voda, bloddy mary = votka + paradazjs sos + limun (?))

Za pocetak da probamo da predvidimo sta ce da se desi.

Dodajmo naprosto novu robu, imenom 'spricer' u tabelu roba. Posto se spricer pravi u radnji, a ne kupuje ni od koga, nece se nikada pojaviti na ulazu u kalkulaciji. ne bi smeo da se pojavi spricer u kalkulaciji. Ako pokusamo da prodamo spricer, dobicemo poruku da ne moze jer na lageru ima 0 komada a mi pokusavamo da prodamo X komada. Znaci, za sada dve stvari moraju da se promene na ulazu:
- onemoguciti pojavu spricera na menijima za izbor robe u kalkulaciji
- promeniti nacin na koji se proverava stanje robe, tako da za mesavina proverava komponente, a ne samu robu
Losa vest: to bas nije ejdnostavno
Dobra vest: to je otprilike sve sto se desava na ulazu u ovom slucaju, ne izgleda mi da ce biti drugih promena na ulazu (osim ako ne gresim ;-)

Stvari se znatno vise komplikuju na izlazu. Na nekim dokumentima, spricer treba da se vidi kao spricer. na nekim drugim, treba da se vidi kao vino i soda. To ce biti problem da utvrdimo gde treba i sta treba menjati. Otprilike da cemo zavrsiti sa dva skupa kveriaj, za jednostavnu robu i za slozenu robu. Onda cemo to morati da za neke dokumente UNIONizujemo, da bi dokumenti i dalje izgledali onako kako izgledaju sada.

To je otprilike plan. Da li mozemo ovo do Nove godine da razresimo? Mozda, a i ako ne, uradicemo to u januaru. I velike firme kasne, pa sto ne bismo i mi.

Podsecam, ovo sto sam zakacio za poruku nema ni jednu od izmena koje sam pomenuo.Ovo je samo je kopija poslednjeg fajla koji smo zakacili na temu maloprodaja. U sledecem nastavku pocecemo sa promenama.



:-)

Evo iskustva bivšeg konobara:
1. Uključujem kasu. Provjerim br. stanje robe (pića) prethodne smjene. Obično smo bili limitirani da prijavimo manjak do 10h!
2. Normalno poslužujem jutarnje kave koje kucam (prijavljujem na blagajni)!
3. Stanje u novčaniku i pri provjeri blagajne mora štimati 100%, bolje manjak nego višak, znači nema bakšiša......
4. kuca se sve dok inspekcije rade, znači do 15h ili 16h
5. E onda se pojavljue šou! Naravno sve dalje kucam zbog kontrole mene kao konobara! Ali oko 23h ili kasnije kad prestane "gužva", znači pred sami fajrunat, gazda na kasi provjera trenutno dnevno stanje i" obriše račune" po stavkama npr 10 cola, 1 lit vina, 1/2 kg kave......., on uzima taj popis jer to mora unijeti u skladište, a uzima novac iz kase! To je ono što zovu siva ekonomija! Znam ali to je realna situacija! Balkane, balkane balkane moj.....J.B. Štulić
6. Dobro idemo dalje na kraju, taj gazda unese razliku da bi sve štimalo!!!! i onda odlazi s ljubavnicom trošiti pare...upsss, .....uglavnom ja zaključim kasu tvz Z izvještaj ja pravim obračun šanka znači količina pića u šanku i skladištu. napravim taj izvještaj i uz taj izvještaj prikačim taj tvz Z izvještaj.
7. Naravno sutra me moj kolega konobar ili gazda budi i javlja da mi po stanju šanka fali 3 pive koje sam prodao slučajnim prolaznicima koji su došli na još "jednu s nogu", ali ja sam već zaključio kasu a nesmijem otvoriti novi dan jer bi na računu bilo vidljivo da sam "točio poslije radnog vremena".
8. Znači za kolegu ostavljam polog 200,00kn + 3 ona piva, koja moj kolega kuca odmah ujutru, jer ulaze u njegopvu smjenu!
9. Ja sam to naravno sve zaboravio jer upravo na šanku me čekala "crnka" koja se lijepo smješi a ja sebi tumačim da bi moglo nešto biti...., znači žurim, zaključim da imam više bakšiša (nemojte zaboraviti 3 pive) uzmem lovu! Odvedem je na još jednu cugu.... kadli ona tamo spazi svog "bivšeg" koji je "slučajno sam" i od cjele večeri nebude ništa! Odem razočarano kući bacim se u postelju...kadli zvrrrr telefon e moj kolega fali ti 5 pivi, trićak votke...bla,bla,bla
10. Ako sam Vam uspio dočarati ono što nas Konobare muči to je to!¨

Naravoučenje: Dobra izračun je sve, bilo s ženama, bilo s kolegama (radnim), bilo sa stanjem u knjigi šanka,....

Evo ne mogu da odolim,a da ne zakacim zadnju verziju. :-)

Jer svaki korak u danjem razvoju za mene je uspijeh.

Tako i tako je Zidar u svojem zadnjem postu zaboravio zakaciti, pa cu ja (valjda se nece ljutiti kad ce opet morati za mnom ispravljati neke greske).

Nisam nista mjenjao u strukturi, samo sam dodao neke izvjestaje i malo promijenio izgled baze, te dodao startup formu.

Sta treba da bi se najlakse uradila izmena ovakve verzije aplikacije ali da pude sa PDV-om kako je po zakonu u SCG ili mozda vec neko ima uradjen primer.
Da li je moguca ispravka ovakve aplikacije ili je lakse da se napravi nova?
HVALA!
POZ.

---