Po onome sto si napisao, mnogo je slozenije nego sto sam ocekivao. bas kako i treba. kombinacija pracenja stanja robe i finansijskog dela. Samo polako, nesto cemo vec da vidimo, treba malo vremena da se shvati (bar meni)

:-)

Evo da ja još malo zakompliciram stvar. Napravio sam zadnju točku, a to je kontiranje. Mislim cijeli sistem može da funkcionira i bez toga. No opet se mora to ručno raditi, makar samo po mjesečnim rekapitulacijama, a ipak nama je krajnji cilj potpuna automoatizacija, ne? :-)

Evo, pa kad ćeš imati vremena bazi oko. :)

A ako ima kakvih nejasnoća rado ću iz razjasniti.

I ako mi možeš dati ocjenu na to kako sam u dosadašnjoj bazi riješio stvaranje knjige URA?

Unaprijed zahvaljujem! :)

:-)
Ovo je tipican priemr kad developer (ja) napravi pogresnu procenu i pocne da razmislja o sistemu pre nego zaista razgovara s klijentom. Ulza i izlez robe u kafic nije nista drugo nego magacinsko poslovanje. medjuti, klijent (vmaotic) hoce u stvari robno i finansijsko poslovanje kafica, sa knjizenjima po kontima i slicno. danas u toku dana mislim da cu imati neka pitanja (ja sam 6 sati iza vas, pa moze biti tek sutradan za vas)

Da to nije ništa drugo, no magacinsko poslovanje. :)

Samo što je caffe magazin. Ulaz robe je kalkulacija, a izlaz robe je blagajna. Na osnovu ulaza se radi knjiga URA, a na osnovu blagajne se radi IRA, a mjesečna razlika te dvije knjige je obveza za plaćanje PDV - a. A sve bi nekako trebalo biti vezano za dnevni datum, jer treba imati dnevni pregled "knjige Šanka" - sa stanjem od prethodnog dana, ulazom (ako ga ima), izlazom i konačno stanjem na dan - količinski i financijski.

I upravo tu knjigu šanka nisam siguran kako da uradim, ako se nadovezivam na gore upload - ani "program".


Evo malo jednostavnije pojašnjenje. :)

Znam da je malo teško ovako preko neta nekome u potpunosti objasniti što bi htio, no eto...

Čekam na pitanja.

Odstampao sa relationship diagram koji si dao. Evo ga zakacenog uz poruku. Uz relationship diagram, stavio sam i dijagram poslovnog procesa jednog kafica, onako kako ga ja vidim iz perspektive gosta u kaficu. Dotakao sam malo i finansijsko poslovanje - samo sam spomenuo da kafic mora da plati robu koju dobije od dobavljaca, i da mora da naplati robu koju proda gostima. Dalje od toga su detalji. Neke od detalaj sam uspeo da shvatim gledajuci u dokumente koje si prilozio, neke pocinjem da shvatam iz ove diskusije, a neke ces morati dalje da mi objasnis.

OK, evo prvog talasa pitanja, u vezi magacinskog dela procesa, na osnovu onoga sto vidim u Relationships dijagramu:

1) Razumem da je set table tbl_Zaglavlje_sanka->tblStavekSanka<-tblArtikli u stvari evidetiranje izlaza robe. Da li sam pogodio? Ako jesam, sta znaci polje PC u tabeli tblStavkeSanka?


2) Ono sto ne vidim jeste prodaja robe gostima kafica - kasa. Da li ja to samo ne vidim, ili nema u tvom modelu tabela koje to pokrivaju? Ako toga nema, onda mora da se vrsi dnevni inventar - brojanje. Jer, odakle dolaze podaci o prodanoj kolicini?
Pretpostavljam da polje tblStavkeSanka.Prodano nosi taj podataka - kolicina prodate robe. Preporuka: Mozda ne bi bilo lose da imena polja budu malo jasnija.
Preporuka: ako se i kasa ubaci u bazu, onda bi se prodana kolicina nekim kverijem dobijala iz baze, ne bi se brojalo niti prepisivalo iz nekih drugih papira.

3) Ulaz robe u kafic je predstavljen setom tabela

tblKomitenti-->tblZaglavlje-->tblStavke<--tblartikli

Jesam li pogodio? Ako jesam, sta znace polja u tabeli tblStavke: (S_PR, NC, Rabat, PC) Da li je neko polje rezultat izracunavanja? Ako jeste, kakvo je izracunavanje u pitanju?

4) Vidim polje PC u tabeli tblStavke, a bilo je polje PC i u tabeli tblStavkeSanka. Da li je to isto ili nije?

5) Takodje, vidm poja MPC i VPC u tblArtikli. Predpostavjam da je to maloprodajna cena i veleprodajna cena. Je li MPC ono sto se naplati gostu? Je li VPC ono sto mi platimo kad primimo robu od dobavljaca? Ili je VPC cena koju mi (kafic) naplatimo kad prodamo nekome 50 gajbi piva za svadbu koju ce on negde drugo odrzati?

Ovde cu da stanem s pitanjima. Ima jos, ali u finansijskom delu za koji ja nisam mnogo strucan, pa zasluzuju poseban paragraf.

Cekam odgovore

_{[Ovu poruku je menjao Zidar dana 07.09.2005. u 15:24 GMT+1]}

Evo odgovora:

1. Da to je evidetiranje izlaza robe - ja sam tu napravio isto jednu gresku, tako da mozemo tu formu sa subformom racunati zapravo kao blagajnu, samo cu preimenovati polja. Dakle od sad na dalje to je blagajna, a time i izlaz robe.

2. Odnosi se na prvi odgovor i preporuke prihvaćene (napravit ću ih za par dana). Dakle preko te blagajne se prodaje roba kupcima, gdje nas ne zanima ime kupca, već mu konobar samo za naručenu npr. kavu izdaje račun koji sadrži naziv artikla, količina i PC (prodajnu cijenu) koja se dobiva iz zadnje kalkulacije.

3. Tako je!
S_PR - šifra proizvoda; NC - nabavna cijena, Rabat - iznos popusta kojega odobrava dobavljač, PC - prodajna cijena.
I to su stavke koje sa računa dobavljača moram unositi u računalo ručno (nemože drukčije), te se na osnovu njih dobiva kalkulacija (koja se svojim stavkama obavezna po zakonu) - qry_STAVKE i qry_SUMA.

4. I opet točno! I tu očito nisam dobro uradio. A zato što nisam siguran kako to povezati. U tbl_STAVKE_SANKA (buduća tbl_BLAGAJNA), treba u polje PC za određeni artikl nuditi zadnju cijenu iz kalkulacije, tj. PC iz tbl_STAVKE.

5. Točno - MPC i VPC u tbl_ARTIKLI su maloprodajna i veleprodajna cijena. Cijena po kojoj nabavimo robu i cijena po kojoj prodajemo robu. Te stavke zapravo i nisu nužne tu. One su tu da bi mi olakšale izradu kalkulacija (set pod točkom 3.). To su zapravo NC i PC u kalkulaciji. Kako nabavljam robu od samo dva dobavljača, cijene se uglavnom ne mijenjaju, pa mi na formi za unos nove kalkulacije kad ja upisem naziv artikla izbaci te dvije cijene, a ja ih prihvatim ili promijenim (code na sifri S_PR - AfterUpdate - Me![NC]=Me![S_PR].Column(2) i Me![PC]=Me![S_PR].Column(3)).
E, vidiš tu si mi dao ideju što bi bilo dobro napraviti, no opet nisam siguran kako, a to je da mi u tbl_ARTIKLI stavke MPC i VPC, puni po zadnje napravljenoj kalkulacije - kužiš što mislim? Zapravo isti problem kao i povezivanje pod točkom 4.

Eto, nadam se da je sve jasno, a ako nije tu sam. :-)

Hvala na iscrpnim odgovorima :-) Molim te ne trci da menjas nazive tabela, nije toliko vazno kako se zovu, sve dok razuemmo sta se desava. Sacekaj da jos malo proanaliziram odgovore.

Ono sa uvodjenjem blagajne u igru nece se zavrsiti samo prostom promenom imena tabele.

U trenutnoj tabeli ti imas zbirne vrednosti, a blagajna bi imala pojedinacne. Znaci, ono st imas u trenutnoj tabeli bilo bi rezultat izracunavanja, a ne podatak koji se cuva u tabeli. Drugo, ako uvedes blagajnu, tacno je da je kupac (gost kafica) nebitan. Ali, ulogu kupca moze da preuzme konobar. Ako ima vise konobara, svaki od njih je u stvari 'kupac', jer on uzima robu iz 'magacina'.

Moracemo da raspetljamo i ono sa cenama. Trenutno su na tri mesta, a cini mi se da ne bi trebalo da budu na vise od dva. O tome cu imati jos pitanja.

Zbog svega ovoga, ostavi meni da prekrojim tabele, uz konsultacije s tobom, dok ne dodjemo do neke strukture koja ce nam odraditi posao.

:-)

Primljeno na znanje. :) Ništa neću da diram dok ne ustanovimo sve što ustanoviti treba.

Ne kužim gdje imam zbirne vrijednosti? U trenutnoj tbl_ZAGLAVLJE_SANKA i tbl_STAVKE_SANKA? Pa ta tabela ili buduća blagajna treba imati podatke o pojedinačnoj prodaji koji se moraju čuvati. Zar ti misliš da sad nije tako? A ja sam zamislio da se samo iz trenutne tbl_STAVKE_SANKA napravi kasnije jedan query koji će davati sumarno po danu - slično ko za tbl_STAVKE. Pa to je isti princip - ne?

Slažem se ovo za konobara i to treba svakako uvesti!

A cijene i jesu dvije, ako se izbace one iz tbl_ARTIKLI za koje sam napomenuo da nisu nužne.

Eto, pa se čujemo poslje vikenda. :)

OK, na istoj smo talasnoj duzini. Ja sam pogresno razumeo. Gledajuci u prilozene Excel fajlove, ucinilo mi se da tablea tblStavkeSanka sadrzi zbirne vrednosti o prodaji robe - shvatio sam da za svaki artikl u tabeli tblStavkeSanka postoji tacno jedan rekord i vrednost u polju Prodano je ukupna kolicina prodana tog dana. Naravno da to nije dobro i naravno da to nisi napravio na los nacin. Ja sam pogresno razumeo.

1) Da li je ovo tacno: Tabela tblZaglavljeSank je kao neki racun koji konobar izdaje gostu, a tabela tblStavkeSanka jeste lista prodatih artikala na datom racunu. Ako jos neko prati diskusiju, primetite da je ovo jako slicno maloprodaji robe u bakalnici.

Imam jos pitanja. Mucim se oko cena i kalkulacije - nisam siguran u kom smeru idu podaci.

2) Razumo sam ovako:

a) Prodaja robe
2.1) tblartikli obezbedjuje cenu za tabelu tblStavkeSanka.
2.2) tblArtikli.MPC se prebacuje u tblStavkeSanka.PC, a korisnik moze da je prihvati ili promeni u momentu ptrodaje (momenat prodaje=momenat kada se INSERT rekord u tabelu tblStavkeSanka) dakle
2.3) tblArtikli.MPC------->tblStavkeSanka.PC, a onda korisnik moze da promeni tblStavkeSanka.PC u nesto drugo, ako treba

b) Prijem robe
2.4) tblStavke (kalkulacija) obezbedjuje cenu za tabelu tblArtikli
2.5) Kad stigne roba, radi se kalkulacija (tblZaglavlje, tblStavke) Za svaki artikl (S_PR) izracunava se (ili dolazi gotovo) NC,PC
2.6) Vrednsoti NC,PC iz tblStavke (kalkulacija) prenose se u tabelu tblArtikli kao
tblStavke.NC--->tblArtikli.VPC i
tblStavke.PC---->tblArtikli.MPC

Da li sam dobro razumeo? Ako je OK, onda sam spreman da poradim na tim tabelama i da mapiram proces.

3) Josjedno pitanje, sama kalkulacija. Rec kalkulacija sugerise da se tu nesto racuna, kalkulise. verovatno si u Execl fajlovima to i objasnio, ali mi je tesko da se snadjem. Mozes li mi objasniti sta se kalkulise? Da li su NC, RABAT i PC u nekoj medjusobnoj vezi, da li se neki od njih izracunava na osnovu druga dva ili su NC, RABAT i PC nezavisni medjusobno i dolaze odstampani na prijemnici robe?

Cujemo se posle vikenda :-)

Evo nakon vikenda smo valjda odmorniji i "pametniji"! :)

Evo ovako - odgovori po rednom broju prethodne poruke:

1. Sve je tako kako si razumio.

2. Tako je, ali opet kad se radi kalkulacija (tbl_ZAGLAVLJE, tbl_STAVKE) da nudi zadnju poznatu MPC i VPC iz tbl_ARTIKLI, koju ja mogu da promijeniti ako hoću.

3. Da, kalkulise se. I to tako da su i NC, RABAT i PC u međusobnoj vezi. Pogledaj query qry_STAVKE i bit će ti sve jasno, no evo da malo objasnim. Taj dokumenat se zove kalkulacija (i zato ga ja tako zovem) i potreban je da se radi po zakonu, a mora sadržavati iznos poreza, pretporeza, marže, postotka marže i druge stavke koje se nalaze u prije spomenutom query-u. No, to nam i nije trenutno potrebno za izradu relacija među tabelama.

Uglavnom, mislim da si sve pohvatao na pravi način, pa kada stigneš molim te da mapiraš proces.

Pozdrav! :)

A) E, stop. Nesto opet nije jasno. U poslednjem postu sam pitao:

U tacki 2.6 lepo kaze da se VPC/MPC u tabeli tblArtikil dobijaju tako sto se prenesu iz tblStavke. Medjutim, ti kazes:

Ispada da je smer informacija drugaciji, ovako:
tblArtikli.VPC -----> tblStavke.NC
tblArtikli.MPC -----> tblStavke.PC

Ja sam razumeo da se podaci o (tblStavke.NC, tblStavke.PC, tblStavke.Rabat) nalaze na nekom dokumentu koji ti dobijes kad dobijes robu (BR_DOK koji ide u tblZaglavle). 1) Da li je ovo tacno? Ukoliko nije tacno, onda je Kolicina (tblStavke_Kol.KOL) jedino sto imas na pocetku kalkulacije (nemam nist protiv toga a sve ostalo (NC,PC) citas iz tblArtikli. Sta onda. 2) Kad zavrsis kalkulaciju onda proemnis PC i NC u tabeli tblArtikli?

B) qryStavke--->qryArtikli---->qryArtikliSUma mi je kao jasan - to je kao ULAZn a kalkulacija:
Ulazni podaci su tblStavke(NC,RAbat,PC,Kolicina) i tblArtilkli(StopaPoreza)
Rezultati od znacaja su:
qryStavke:
- IZNOS_RABAT: Round(([NC]*[RABAT])/100,2)
- NETO_NC: Round([NC]-([IZNOS_RABAT]),2)
- UKUPNO_NC: Round([KOL]*[NETO_NC],2)

- MARZA: Round([BEZ_PDV]-[UKUPNO_NC],2)
- POSTO_MARZE: [MARZA]/[UKUPNO_NC]

- PREDPOREZ: Round(([neto_nc]*[stopa_poreza])-[neto_nc],2)

- UKUPNO_PC: Round([PC]*[KOL],2)
- PDV: Round([UKUPNO_PC]-([UKUPNO_PC]/[STOPA_POREZA]),2)
- BEZ_PDV: Round([UKUPNO_PC]-[PDV],2)

- ZA_PLATITI: [PREDPOREZ]+[UKUPNO_NC]

qryARtikli i nije neophodan, on je samo SELECT nekoliko polja iz qryStavke.
qryArtikli_Suma mogao je da bude napisan i na osnovu qryStavke.

Onda se sve sumira u ovo:
qryARtikli_Suma:
- S_Ukupno_NC=SUM(Ukupno_NC) po sifri artikla
- S_Ukupno_PC=SUM(Ukupno_PC) po sifri artikla
Zar ne bi ovde trebalo da ide suma po (datum,SifraArtikla) umesto samo po (Sifra Artikla)?

3) Sta od ovoga navedenog ide (prikazuje se ) u Knjigu Ulaznih Racuna?

4) Da nije tvoja tabela tbl_Prijenos_Kalk u stvari Knjiga Ulaznih Racuna? Ako jest, sta bi bila Knjiga Izlaznih racuna? Imas li tabelu za to? (Ne kazem da TREBA da imas tabelu, samo pitam, da bih razumeo model baze podataka)

U sledecem postu pitacu o proracunu troskova (qry_Troskovi)

Zakacio sam mapu procesa, onanko kako ga sad vidim. PDF dokument ima dve stranice, prva je inicijalna mapa, od koje smo poceli, drugi list je gde smo sada. Verovatno ce se mapa procesa zimeniti, kako saznajemo vise. Kad mapa bude gotova, preko mape cemo staviti dokumente koji figurisu u procesu i pokusati da damo model baze podataka koji pokrivaju mapu i dokumente. Posle toga pokusacemo da damo plan aplikacije - koje forme, reporte i kverije trebamo. onda cemo zajedno da pisemo aplikaciju. A u to ce i Nova godina, pa cemo svi na odmor.





_{[Ovu poruku je menjao Zidar dana 12.09.2005. u 16:42 GMT+1]}

A) Evo ovako: Točno je da se tblSTAVKE.NC, i tblSTAVKE.Rabat nalaze na nekom dokumentu (računu dobavljača), a tblSTAVKE.PC određujem sam i obično se ne mjenja mjesecima.

A) Evo kako bi ja da to radi: Kad idem radit kalkulaciju, da mi na formi za unos stavaka kalkulacije ponudi zadnju NC i PC (sa zadnje kalkulacije), pa ih ja promjenim ili ne.
Pa sam ja otvorio NC i PC u tblARTIKLI samo iz razloga da ih sa naredbom Me! mogu pozvati u formu za unos kalkulacija (vidi Form - frm_ZAGLAVLJE_F, frm_STAVKE_DS).
Tako da uopće nije bitno imati polja MPC i VPC u tblARTIKLI, a ja sam ih stavio jer nisam znao kako zadati da Access uzima cijene za pojedine artikle s posljednje kalkulacije.

Smjer podataka kako sam ga ja zamislio (ako može):
tblStavke.NC -----> tblArtikli.MPC -----> frmStavke.NC
tblStavke.PC -----> tblArtikli.VPC -----> frmStavke.PC

Dakle - prvo upisujemo obje cijene u tbl_ZAGLAVLJE, tbl_STAVKE, pa se one prenose u tbl_ARTIKLI, gdje ostaju do iduće kalkulacije.
Kada opet dobijemo račun od dobavljača opet radimo kalkulaciju i tada da nudi cijene iz tbl_ARTIKLI, a koje ja prihvaćam ili ne (sa Me! pretpostavljam). I opet kada završim sa kalkulacijom da se zadnje cijene prenesu u tbl_ARTIKLI.

Eto, ne znam kako bi drukčije objasnio, ali ako hoćeš, možemo i bez toga, pa onda samo iz tbl_ARTIKLI izbacimo MPC i VPC i ostali protok podataka ostaje kao u bazi "program.mdb".

B) Da to je ulazna kalkulacija. I slažem se sa tobom što se tiče qry_ARTIKLI (ne znam zašto sam ga otvarao) i qry_ARTIKLI_SUMA moglo bi ići i po datumu i šifri.

3 - 4) Knjiga ulaznih računa je qry_URA koji se suma tabela tbl_Prijenos_Kalk i tbl_Prijenos_Troškovi. Zapravo svaki dokument koji je ušao u poduzeće i koji moramo platiti ulazi u knjigu URA.
A Knjigu izlaznih računa nemam, a ona bi se dobivala iz blagajne. Znači kada svaki dan zaključimo blagajnu, ukupni zbroj taj dan je jedna stavka knjige IRA koja bi imala iste stavke kao i knjiga URA.

Da, ova mapa procesa ti je skroz dobra. :)

A troškovi nisu ništa drugo nego još jedan ulazni račun za koji se ne treba raditi kalkulacija, već se samo evidentiraju u dokumenat koji se zove "temeljnica" i koji se kao takav prenosi u knjigu URA.

Eto, toliko, ali nisi samo napomenuo koje će to Nove godina da bude. :))

P.S. U kojem programu radiš te mape procesa?

_{[Ovu poruku je menjao vmatoic dana 13.09.2005. u 08:29 GMT+1]}

Bavno sam se kaficima, ali sam digao ruke. Ma kako izgledalo sa strane program je dosta komplikovan, a gazde teske na parama.

Samo cu dodati malo teorije da vam olaksam jer ne znam sta kazu propisi kod vas.

U osnovi treba ti jako malo tabela. Maticne sa artiklima (tu cuvas sife i nazive, poreske grupe i cene), ulaz (kalkulacije), izlaz (prodaja) i promet (sto mozes realizovati putem view-a).

Ako vas zbunjuje knjiga ulaznih racuna, to je samo izvestaj sa ulaza. Slicno, knjiga izlaznih racuna je izvestaj sa izlaza. Knjiga sanka se izvodi, izvedes stanja na prethodni dan, dodas ulaze i oduzmes izlaze.

Hvala na brzom odgovoru i hvala draganescu na veoma korisnom komentaru

Celu ovu diskusiju razvlacim namerno da bismo se slozili da nam u stvari treba jako malo tabela, bas onako kako je darganescu rekao. Knjige ulaznih i izlaznih racuna jesu izvestaji i dobijaju se kverijima, nema potrebe da se zapisuju rezultati u tabele.
Sve sto se sumira po danu, mesecu ili bilo cemu, nema potrebe da se cuva u tabeli, sumiranje ce da se obavi (i odstampa) kada zatreba.

Znaci, sta se desava:
1) unose se podaci na ulazu,
2) unose se podaci na izlazu.
3) Azuriraju se cene u tabeli artikli, kalkulacija zapocinje ucitavanjem trenutnih vrednosti MPC, VPC iz tabele artikli, pa se onda to ponekad promeni. Ako se promeni, nova vrednost se prepisuje preko postojece u tblArtikli i tako se cuva za sledeci put. Ovo posebno vazi za MPC. VPC i ne moras da tretiras isto kao MPC, to ti stize od dobavljaca i ne koristi se nigde drugde nego samo na ulazu. MPC se kosristi i u prodaji, pa mora da bude u tabeli tblArtikli, da bi kleneri znali koliko da naplate.

E sad mozemo dalje. Deo sa placanjem cemo usput da odradimo, kad nam zatreba.

Da sad za trenutak zastanemo i napisemo sta zapravo hocemo da uradimo, u smislu razvoja naseg IS. Ovo do sada je bilo vise objasnjenje kako kafic funkcionise.

Prvo nam treba IS Mission Statement ili Svrha buduceg IS, tek toliko da ne zaboravimo sta zapravo radimo. To treba da je jedna recenica koja generalno opisuje stase zeli. Dakle:

Mission Statement:

Svrha baze podataka 'Kafic' jeste da omoguci uvid u promet robe kafica.
ili
Svrha baze podataka 'kafic' jeste da omoguci brz i tacan uvid u transakcije robom i novcem koje se desavaju u kaficu

Onda se daju IS Mission objectives ili Zahtevane funkcije (ciljevi) IS

Mission objectives:
1) Pratiti ulaz robe, na osnovu racuna dobavljaca i saciniti temljnicu
2) Izraditi na osnovu temelnjice ulaznu kalkulaciju cena i predporeza
3) Pratiti prodaju robe, evidentiranjem prodaje robe na blagajni
4) Saciniti knjigu sanka za svaki dan i izracunati porez koji treba platiti
5) Prikazati knjigu URA i IRA i zakonom propisane mesecne izvestaje
6) Evidentirati uplate dobavljacima
7) sve transakcije kontirati prema propisima
Omoguciti prikaz kartica artikala, komitenata, konta


Zlo i naopako ako bismo isporucili sistem koji radi tacno ovo sto kazu mission objectives. Rec 'tacno' znaci 'ni manje ni vise'. Deo 'ni manje' se podrazumeva. Problem je u delu 'ni vise'.

Zamislite da kupujete auto, pa kazete da hocete auto koji ima 5 mesta, ne trosi vise od 5 l/100 kmh u gradu, ide do 120 km/h, ima 120 KS, klima uredjaj, stereo urdedjaj i GPS, automatski menjac, grejana ogledala, remote keyless entry. Super, ima, sve za 10,000 Evra. Vi dobijete auto, a na njemu nema brisaca, nema ni prtljaznik. A prozori se ne otvaraju. Nema rucnu kocnicu. Pobunite se, a trgovac vam kaze 'Gospodine, evo vase specifikacije. Garantujem vam da vas auto ima sve ovo sto ste zahtevali. To ocemu pricate (brisaci, prtljaznik, rucna kocnica) i nije bilo u specifikaciji, to morate da platite naknadno'. Nazalost, tako izgleda 99.9% aplikacija koje se naprave po narudzbi. Imaju automatski menjac ali im fale brisaci i rucna kocnica. Zato je propao IT sektor, a gazde postale tvrde na placanju, izmedju ostalog.

Da ne zaboravimo, dakle da dodamo prtljaznik i brisace. Evo dakle kao neke specifikacije za aplikaciju:

- Napraviti aplikaciju koja izvrsava funkcije izlistane u Misssion Objectives.
- Detaljne liste izvestaja koji se zahtevaju u Mission Objectives date su u prilogu A (koji nisam ovde napisao, ali treba da se napravi)

- IS ce imati dva dela - back end (baza podataka) i front end (aplikacija)

- baza podataka ce biti Access MDB fajl.
- Aplikacija ce biti Access MDE fajl

- Aplikacija ce imati hard kodiran logo i adresu kafica na svim izvestajima i formama. Narucilac ce obezbediti logo u obliku JPEG fajla.
((ovo je efikasno srestvo za sprecavanje kradje aplikacije. Ako na svim izvestajima pise Kafic 'U Zdravlje', Beograd, Terazije 25' tesko da ce neko to upotebiti u kaficu 'Boom Boom', Paracin, Glavna ulica br 3)

Pored osnovnih radnih funkcija, aplikacija mora omoguciti
- povezivanje sa bazom podataka
- backup i kompaktiranje baze podataka
- unos i izmenu podataka maticnih tabela i sifranika
- dodavanje upita kreiranih od strane korisnika i lako odrzavanje liste upita
- dodavanje izvestaja od strane korisnika i lako odrzavanje liste izvestaja

Uz sistem izporuciti uputstvo za instalaciju ili install proceduru (ili ce isporucilac instalirati sistem)
Uz sistem isporuciti dijagram baze podataka i spisak osnovnih pogleda
Uz sistem nije potrebno isporuciti uputstvo za upotrebu. Umesto upotstva za upotrebu, isporucilac ce odrzati kurs u trajanju od tri dana, po sest sati dnevno.

Sve komponente sistema isporuciti na CD.

Moze i ne mora: sistem mora imati ugradjen security, koji zahteva logovanje korisnika, da bi se sprecilo da neovlascena lica pristupe sistemu. (Ovo izbegavajte koliko god mozete, sve se ovo moze postici i na druge nacine, lkse i cesto pouzdanije nego postavljanje Access security)


Bice ovo i pre Nove godine, mozde i oko Svetog Nikole

I treba dodati podrsku za fiskalnu kasu.

Sva prodaja mora biti evidentirana preko fiskalne kase. I tu nastaje jedan problem, da bi sve bilo tacno trebalo bi "povuci" podatke sa kase u aplikaciju, ali posto se najcesce nabavljaju najjeftinije onda je jasno da bi to trebalo prekucati sa trake: izvestaj o prodaji. Mozda je bolje resenje fiskalni stampac, dosta skuplje.

A serviseri su "objasnili" svima da je kasa sve sto im treba. U neku ruku to i jeste tacno, jer ostalo vec radi knjigovodja. Medjutim, kad vam treba stanje kada cete to dobiti od knjigovodje? Sutra?

Slazem se sa draganescu, treba dodati fiskalnu kasu u Mission Objectives. Na nesrecu, ja o tome pojma nemam :-(

Ako moze draganescu da nam opise proces sa fiskalnom kasom - povlacenje podataka, kakda, kako, koliko cesto - onda mozemo nesto da pokusamo.

Sve lijepo objašnjeno! :)

I koji nam je sljedeći korak?

Što se tiče fiskalne kase, ja prekucavam trenutno kako je draganescu rekao. Prekucavati znači izvući dnevni izvještaj prodanih artikala koje tada upisivam ručno u Knjigu šanka.

A nama je sada cilj to povezati Accessom.

Problem je u tome što je blagajna kafića fizički odvojena od ostatka firme. Tako da bi trebalo u kafiću imati blagajnu, pa se na kraju dana ili tjedna prodaja samo snimi na prenosni medij ili se šalje netom u knjigovodstvo i oni tada samo povuću podatke iz te datoteke. I isto tako se mogu slati podaci iz knjigovodstva (ulaz robe) u kafić kako bi oni imali u svakom trenutku stanje.

El tako nekako misli draganescu?

Pa treba imati kasu koja to omogucava. Radio sam sa Sharp-om, rezultat je ASCII fajl, pokrene se batch i saceka. Schollex kase imaju mogucnost da im se pristupi putem modema i skinu podaci. Navodno to moze i Sharp, ali nisam video pa da se ne izletim. To se radi na kraju dana, posto se napravi dnevni izvestaj.

Mozda je onda bolje imati fiskalni stampac, podaci su u racunaru pa je sva lakse.

I kod kafica ima jos jedna caka koju sam se snalazio ali mi niko nije rekao kako to uraditi: na neki nacin imate proizvodnju, recimo turska ili neka druga kafa. Vi nabavljate kafu, secer, mleko, slag,... a rezultat je kafa sa mlekom, kafa sa slagom. Slicno: nabavljate vino i kiselu vodu pa pravite spricer. Tocite pivo. Sokovi se navaljaju na litar ili dva, a prodaju na casu.

Sa hranom je jednostavnije, imate recepturu, recimo prstohvat soli, pa sad pogodi koliko je to.

Ma mi ti imamo kompjutorsku kasu u kafiću. Nekakvi athlon na 800 mhz, sa malim monitorom i POS pisačem. Tako da nije problem, što se kase tiče. Može biti i cijeli Access na njoj.
A što se robe tiče za sve postoje normativi. Znači kada netko hoće kavu s mlijekom, na računu mu piše kava 3,00 kn i mlijeko 1,00 kn. A iz kilograma kave se po normativu napravi 150 kava i iz litre mlijeka izađe 20 mjerica po 0,05 mlijeka.

E sad, dal je bolje to riješiti nekako sa jednom tablicom koja bi sadržavala te normative u sebi, pa bi se roba sama po njima razduživala, ovisno o grupi ili je bolje odmah kod ulaz (izrade kalkulacije) zadužiti umjesto 1 kg kave po 100,00 kn, zadužiti 150 kava po 0,67 kn. Time se javlja opet razlika u financijskom iznosu u decimalama.

Vjerojatno je bolje napraviti tablicu sa normativima koja bi se vezala na tablicu artikla? (npr. netko naruči gemišt i to tako piše na računu, a mi se razdužujemo za 0,10 vina i 0,10 vode i sl.).

Imate kakvu ideju kako bi to bilo najbezbolnije napraviti? :)

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.

A ne znam sto bi ti bilo lakse.

No, dosta detaljno smo prolazili korake u izradi ove baze, pa malo prouci temu maloprodaja gdje se o tome razglabalo i zakljuci sto ti je jednostavnije.

No, mislim da bi ti ipak u budusnosti bilo lakse da pocnes ispocetka raditi svoju bau, a ova baza neka ti sluzi kao smjernica kad zapnes. Tako sam ja radio. Kad je Zidar radio neke promjene tada sam ih proucio i ponavljao na svojoj zasebnoj bazi, tako da sad znam gdje je sto i sa cime, a ovako se inace u tudem poslu tesko snaci.

Pozdrav! :-)

Mislim da si u pravu, tako sam i mislio ali sam hteo da mi to jos neko savetuje da ne pomislim kako sam ja najpametniji.
HVALA TI PUNO!

Pozdrav!

Pozdrav svima i srecni praznici :-)
Zahvaljujem VMaoticu sto se trudi da aplikacija zaista lici na profesionalno uradjen posao.
Zakacicu verziju 10. U ZIPu su MDB fajl i word dokument. U MDB fajl sam dodao novu tabelu, tblMesavine i ubacio je u relacije. I to je sve. Ostatak sledi. Word dokument sadrzi objasnjenja o tome sta je i kako uradjeno. Proucite relacije, videcete da se nova tabela javlja dva puta u relationships dijagramu. razmislite zasto.

:-)

Evo samo sam na brzinu pogledao promjene koje je Zidar unio i javljam se samo da zakacim svoju najnoviju verziju, jer ako ce Zidar raditi izmjene onda neka to bude na najnovijem da se ne ponavljamo.

A ja cu mozda iduci tjedan biti kratak s vremenom, pa ne znam koliko cu se stici ukljucivati.

U svoju bazu sam samo importao tblMesavine i postavio relacije kako ih je Zidar napravio u caffe10. Od promjena na Caffe11 nema nista u strukturi, samo ima novih formi i izvjestaja.

A tblRoba se ponavlja drugi put na relationshipu samo kako bi ogranicili koje vrste roba se mogu unositi u tblMesavine. Pa mozemo kasnije u formi napraviti i combo box na to. El tocno?

A sta treba uraditi da se datumi sami upisuju ili generisu u tabeli datuma jer u slucaju da kucamo neki datum a nema ga u toj tabeli javlja gresku.
I kako bi isao SQL kod da izbaci izvjestaj o prodaji na osnovu kriterija "IDProdaja", recimo upise se ID prodaje 2 i ono izbaci ID, datum, sta je prodano. Ja sam pokusao, ali javlja gresku

Evo koda:

SELECT tblProdaja.ProdajaID, tblProdaja.ProdajaID, tblProdaja.Datum, tblProdajaStavke.ArtiklID, tblProdajaStavke.Kolicina, tblProdajaStavke.MPC, tblProdajaStavke.Porez
FROM tblProdaja INNER JOIN tblProdajaStavke ON tblProdaja.ProdajaID = tblProdajaStavke.ProdajaID
WHERE (((tblProdaja.ProdajaID)="ProdajaID"));

Usput sad se i ja ukljucujem akoi ima mjesta da se ovo dovrsi

Datumi: tacno je da ako se unese datum koji ne postoji u tabeli javlja 'gresku'. samo, greska nije u kodu, nego je da tako kazem, 'korisnicaka'. Knjigovodstvo i vodjenje kafica je ozbiljan posao i radi se planski. Recimo, potrebno jednom mesecno se na neki nacin u tabelu unesu datumi za neki period, recimo sledeci mesec. Mozes to uraditi rucno, jedan po jedan, a moze se i napisati nekoliko linija koda koje bi to odradile. onda se naprosto taj kod pozove od nekud, klikne se neko dugme i to je to.

Sto se tice izvestaja po zadatom ID, moras da napravis izvestaj prvo, pa da ga pozoves sa neke forme na kojoj zadajes kriterijum. U samoj aplikaciji imas vise od jednog primera gde se izvestaji pozivaju na osbpvu bas ID pa pogledaj kako to ide.

Inace, nije nam cilj da napravimo (zavrsimo) aplikaciju koju ce neko da skine sa foruma i da s tim vodi kafic. Cilj je da pokazemo kako se neke stvari rade, to jest kako mogu da se rade, ima sigurno i drugih nacina, boljih ili losijih, zavisno od situacije. Kako rece Vmaotic

Pogledao sam ovu vasu bazu, i nije mi jasno kako ubacujete nove artikle u kalkulaciju, znaci onih kojih nema u tblRoba tj na listi u combox?
Pozdrav

Imas formu Roba (otvara se na glavnoj formi) i tu unos novog artikla.

A jos treba napraviti i da se moze unositi kod unosa kalkulacije, kao sto je za dobavljace (probaj dupli klik na DobavljacMB kad otvoris unos nove kalkulacije).

No, to sve oko robe je jos u izradi jer ce sad jos Zidar pokazati mogucnost ulaza jedne robe, a izlaz će biti druga roba (koja je kombinacija dva ulazna artikla), tj. normativi.

Da to i jeste moj problem.Kada pocnes da unosis artikle u novu kalkulaciju i naidjes na novi artikal, trebalo bi da otvoris formu za unos artikla i da se vratis ponovo na kalkulaciju, znaci tamo gde si stao recimo na pola unosa i da novi artikal bude na listi.U ovoj bazi kada kliknes dvaput na dobavljaca otvori se forma za unos novog dobavljaca i to je Ok, ali kada se vratis na kalkulaciju njega nema na listi, pa moras da zatvoris kalkulaciju pa ponovo da otvoris da bi novi dobavljac bio na listi, sto je problem pri unosu kalkulacije kada si uneo vec odredjen broj artikala i treba samo da nastavis sa unosom i da ti je novi artikal dostupan na listi.
Mislim da bi bilo zanimljivo videti resenje ovog problema.
Pozdrav

Rjesenje tog problema se vec nalazi unutar baze, no evo da pojasnim kako ces to rijesiti. Otvoris formu frmRacuniOdDobavljacaKalkulacije, tj. unos nove kalkulacije i odes na event on activate i upises u code Me.Recalc.

Eto, dobro si uocio, pa cu to ubaciti u bazu i bit ce prilozena ispravljena verzija baze sa tim ispravama u slijedecem postu. :)

_{[Ovu poruku je menjao vmatoic dana 16.01.2006. u 07:29 GMT+1]}

Nisam nasao resenje u samoj bazi, pa sam uradio kako si rekao i epilog je da mi javlja gresku i kodu, tako da cekam da nakacis bazu sa resenjem ili Zidar da se javi

Evo kacim ti bazu sa promjenama. Jos sam danas stigao i napraviti report za kalkulacije.

Hm, zanimljiv problem.Resenje problema dodavanja novog artikla funkcionise samo ako je novi artikal prvi koji pokusavamo da unesemo u kalkulaciju,(isto vazi i za novog dobavljaca ili nove grupe) medjutim ako su vec kucani neki artikli u kalkulaciju tj ako novi artikal nije prvi u kalkulaciji, nastaje problem, ili javi gresku u kodu na "Me.Recalc" ili jednostavno prihvati unos novog artikla u tblRoba ali kada se vrati na Kalkulaciju nema ga na padajucoj listi, jedino resenje je da se izadje iz kalkulacije, pa ponovo udje, onda ga ima na listi, ali to vec nije elegantno resenje jer se prekida unos artikala u kalkulaciju pa se mora ponovo kucati ili ici u izmene.
proveri Vjekoslave jos jednom pa me ispravi ako gresim, a ako neko drugi zna resenje nek izvoli...
Pozdrav

Hm, zanimljivo. U pravu si.

Neznam zasto je tome tako?!

Molim nekog tko bi znao rijesiti to osvjezavanje forme da nam objasni!

_{[Ovu poruku je menjao vmatoic dana 17.01.2006. u 08:10 GMT+1]}

Probajte na 'On Got Focus' forme, i na 'On Got Focus' ComboBox-a upisati cmbNaziv.Requery i nebi više trebalo biti problema, a onaj Recalc treba obrisati.

Na on got focus comboboxa u code treba upisati ArtiklID.Requery i to rjesava stvar. Zahvaljujem na pomoći.

Nadam se da ce raditi i kod drugih.

Stavi i na 'On Got Focus' forme, to ne može smetati a sigurnije će obavljati svoj posao.

Evo nesto i od mene napokon. Sada Spricer moze da se izabere i sacuva na prodaji. I ne moze da se izabere u kalkulaciji.

MDB fajl je porastao toliko da kada se ZIPuje bude veci od 200K pa ne moze da se upload kao jedan fajl. Zato sam odvojio tabele od aplikacije i imamo sada dva fajla, jedan u ovoj poruci, a jedan u sledecoj. U ZIPu se nalazi i word file sa objasnjenjima. Word je isti kao pre, uz dodatak jedna stranice na karaju. Mozda nije kompletno objasnjenje, ali su pomenuti svi objekti koji su dodati ili promenjeni.

_{[Ovu poruku je menjao Zidar dana 18.01.2006. u 16:10 GMT+1]}

Evo fajla sa tabelama:

Hm, mislim da to ne radi kako treba.

Ne generira stanje robe na lageru dobro.

Probao sam ovako:

1. unio sam sa kalkulacijom 10 l vode (umjesto voda 0,25 mjesavina je voda, tj. umjesto sifre 30 u mjesavinama je sifra 16) i 10 l vina.

2. idem na prodaju 01.10.2005. i imam prodaju 0,5 l vina i 0,5 l vode, pa provjeravam stanje koje je 9,5 l vode i 9,5 l vina i to je Ok

3. idem na prodaju 02.10.2005. i imam prodaju 5 spricera, pa provjeravam stanje koje je opet 9,5 l vode i 9,5 l vina.

4. idem na prodaju 03.10.2005. i imam prodaju 100 spricera i javlja mi gresku kako je vino samo 9,5, a meni treba 10 i isto za vodu.

Znaci nije oduzeo u stanju robe prodaju spricera. I pojma nema kako zaokruziti ovu pricu i sad mi je tek jasno da je to sve mozda malo prekomplicirano.

Mozda bi trebalo odustati patiti se sa ovim, pa ko treba nek ima na prodaji i umjesto spricera pise 0,10 vina i 0,10 i gotovo.

Mislio sam da ovo probamo pokazati, no moze se raditi i bez toga.

Zidar - sto ti mislis?

Da li nastavljamo dalje sa ovim mjesavinama?

Znam da ne radi kako treba, ali jos nismo stigli do toga. To nam je sledeci korak - da u stanju ispravno oduzme kolicine. Ovo ce zakomplikovati malo stvari sa kvarijima, ali sta se moze. Necemo da stanemo kad smo stigli dovde. Ovako cemo:
- moj deo je da napravim da radi sve ovo sto si naveo u poslednjem postu
- ti ces onda da vidis sta ti se dalje ne svidja - dnevni izvestaji mozda, tamo se spricer pokazuje kao negativna kolicina, sto je i logicno, posto nigde na ulazu nismo imali spricerem, niti mozemo da ih imamo, a na izlazu ih imamo. nemoj mi sad odgovoriti sta da radimo za dnevne izvestaje, sacekaj dok resimo stanje, pa onda.

To ti je ona prica 80:20. Recimo da kompletna aplikacija radi mesavine potpuno korektno, svuda. Nekompletna radi sve osim mesavina. To 'nekompletna' je 80% od kompletne aplikacije i to trazi 20% rada. Ostatak od 20% aplikacije, moze da pojede 80% rada. To onda znaci

80% apliakcije <-----> 20% rada
20% aplikacije <-----> 80% rada
--------------------------------
100% aplikacije 100% rada

U nasem slucaju nece biti bas 80:20 ali se posao znatno uvecava.

:-)

OK. Onda cemo da nastavimo. :)

U meduvremenu sam se raspitao i prema Zakonu kaze da dnevni izvjestaj ne treba sadrzavati stanje i stanje od jucer, tako da mozemo koristiti samo onaj "brzi" izvjestaj, a ovaj izbaciti iz baze.

Tako cemo i smanjiti velicinu bazem, koja je postala problem.

A da u tblRoba ubacimo Yes/No polje prema kojem bi razlikovali mjesavine od "ciste" robe, tako da kad printamo stanje na lageru, ne printa ovu robu u minus?

P.S. Sto se tice problema velicine baze - ima jedan freeware program za zipanje koji se zove 7zip i kad se zazipa u tom njegovom .7zip formatu tada baza zauzima nekih 150 k. A ako se dogovorimo da cemo time razmjenjivati datoteke, napisem adresu gdje se moze skinuti (zauzima oko 1 MB)?

Sa ovim netreba da gledate na velicinu samo okacite i kazite nam link za skidanje inace fajlovi se cuvaju jedan mesec.
free server
http://zalil.ru/

_{[Ovu poruku je menjao manijac dana 21.01.2006. u 15:41 GMT+1]}

Private Sub KalkulacijaID_DblClick(Cancel As Integer)

Dim strWhere As String
Dim strFormName As String

strFormName = "frmKalkulacijaAdd"
strWhere = "KalkulacijaID=" & Me!KalkulacijaID
DoCmd.OpenForm FormName:=strFormName, view:=acNormal, WhereCondition:=strWhere

End Sub

Ovim otvaramo formu frmKalkulacijaAdd po polju KalkulacijaID, a kako bi trebalo nadopuniti ovaj kod kad bi htjeli otvarati po dva polja.

Npr. uz KalkulacijaID, dodamo jos jedno primarno numericko polje Godina.

Pa bi imali

KalkulacijaID Godina Dobavljac ...

1 2005 Promet d.o.o.
2 2005 Pero d.o.o.
1 2006 Mika d.o.o.
...

Probao sam dodati u cod jos jedan redak: strWhere = "Godina=" & Me!Godina, no to bas i nije dobro rjesenje.

Ovo necu sad dodavati u nas model, nego me to za nesto drugo zanima. :)

Malo samo strpljenja, u velikoj sam guzvi na poslu, sve ce se razjasniti u sledecem postu, do kraja sedmice

:-)

Nema zurbe za ovo, stignemo. Do kraja veljace bi i moglo biti gotovo. :)

Trenutno cu u narednih tjedan, dva i ja biti zauzet, pa necu stici nista vise raditi na ovome.

Ajde kad uspijes naci vremena vidi moj prethodni post, pa ako znas odgovor... :)

OK, radimo koliko stignem. nesto sam zapoceo, ali ne stizem da zavrsim.

Pitanja:
Da li dodati polje u tabelu Artikli Yes/No da nam kaze da li je mesavina. Absolutno NE. Dzaba ti Yes u polju ako nisi uneo komponente. A ako unses komponente, onda ti Yes ne treba, obican kveri ce ti reci sta imas u mesavinama. Koji artikl nije mesavina? Pa onaj koji nije u tabeli gde drzimo komponente.

Nesto u vezi otvaranja reporta/forme, kad su dva polja kriterijum - to je u principu lako, resicemo lako kasnije.

:-)

Evo najzad verzija koja uzima u stanju uzima u obzir i komponente (vino stolno Id=30 i soda voda Id=15) koji s eprodaju pod zbirnuim imenom (spricer Id=34)

Uspelo je sve da stane u 194 K ZIP. Promene su u kverijima koji daju qryStanje. Nacrtajte stablo zavisnosti kverija z aprethodnu verziju i za novu, pa cete videti razliku. Nemam sad vremena da objsanjavam, valda cu moci kasnije.

Back end nisam menjao, onaj sa brojem 13 iz prethodnog posta trebalo bi da radi.

:-)

_{[Ovu poruku je menjao Zidar dana 30.01.2006. u 18:26 GMT+1]}

Vmaotic je pitao

Probaj ovako:
[code]
strWhere = "KalkulacijaID=" & Me!KalkulacijaID & " AND Godina=" & me!godina
[code]
Podrazumeva se da je Godina u ovom slucaju numericko polje. U suprotnom, trebali bi navodnici da se dodaju.

To je to!

Hvala!

Imam pitnje? kako da kod aplikacije vidim design view?
ovako kako je sada, VBA se pokrene i mogu da se "sluzim" aplikacijom, ali ne i da analiziram, ulazim u kod......
Ili je to samo dozvoljeno odabranim članovima grupe?

Kad kliknes na MDB, drzi SHIFT ENTER pritisnuto

:-)

U tabeli Roba gde su uneseni podaci o artiklima, se ne sme menjati nista osim prodajne cene, znaci ako je jedan artikal prodat i vise se nece nabavljati, on se ne sme dirati iz tblRoba, jer se automatski brise naziv artikla iz tbl prodanih artikala.Da li moze da se uradi tako da se artikli mogu dirati u tblRoba bez posledica u ostalim tabelama?
Pozdrav

Tacno, ne sme se dirati. Brisanje ne dolazi u obzir, ako postoje podaci o prodaji ili nabavci, data integrity na nivou tabela to nece dozvoliti. Tako rade relacione baze, eh. A ne sme se ni editovati naziv artikla, jer ce se u svim reportima i kverijima pojaviti novi naziv. Zasto bi menjao naziv? Ako je artikl 18 bio "pivo", kakvog smisla ima da posle dve godine artikl 18 postane "keks"? Pazi, ovaj sistem proizvodi neke dokumente koji su zakonom propisani i mnogo toga se NE SME menjati kasnije. Zamisli da prodas robu nekome, 20 komada, odstampas racun i naplatis. Onda uzmes i promenis kolicinu u tabeli prodaja sa 20 na 16. Ili kazas nije to bilo 20 piva, to je bilo 20 mleka. Knjigovodstvo tise nece sloziti i ici ces u zatvor. Ovo je pre svega knjigovodstveni alat, a u knjigovodstvu se nista ne brise i nista se ne zamenjuje. Ako je napravljena greska, pogresan broj se ne brise, on se precrta i tacan napise pored njega. Ako je neka transakcija (racun, uplatnica, bilo sta) pogresna, ona se ne brise iz knjiga i kartica. Pogresna transakcija se proglasi nevazecom i upise se druga, tacna transakcija, uz objasnjenje sta se desilo. Svrha knjigovodstva je da belezi stvari onako kako su se desile.

Tacno je da ova aplikacija nema alate za ponistavanje transakcija, niti ima nacina da se kaze 'ova roba se nece vise nabavljati, stoga je ne zelimo videti u listi za nabavku'. Cilj nije bio napraviti sistem koji cete da downloadujete sa foruma i koristite u poslu. Cilj je bio da pokazemo neke principe (kako se prenose cene iz tabele roba u tbl. prodaja, kako kalkulacija menja tabelu roba i obratno, kako se vode ostali troskovi, kako se u principu prati stanje robe na lageru, kako se vodi kartica dobavljaca, i na kraju kako se vode slozeni artikli tipa "spricer"). I usput smo pokazali kako ide proces uzimanja zahteva od korisnika, kako se dokumentuje poslovni proces i kako se dizajnira baza podatak, i kako se pravi 'arhitektonski nacrt' sistema (baza plus front end). Posto smo mi samo forum, a ne skola niti consulting firma, mislim da je dosta i ovoliko :-)


Sigurno da moze, ali razumes valjda da bi to bilo veoma stetno za biznis.

:-)

Evo kako sam malo u guzvi ovih dana uspio sam samo baciti pogled na promjene koje je Zidar uradio i cini mi se da sve funkcionira kako treba.

Detaljnu analizu cu uciniti za koji tjedan, jer mislim da prije necu stici, pa cu dodati i izmjeniti neke promjene kojih bi moglo biti na nekim izvjestajima.

No, mislim da smo sa ovim zadnjim promjenama obuhvatili sve sto se zeljelo pokazati u izradi jedne, mozemo tako reci, kompleksnije baze.

Kako sam ja pokretac ove teme, zelio bih se zahvaliti svima na pomoci, a ponajvise Zidaru koji je imao rjesenja na sve prohtjeve! :-)

Evo, predlazem da ostane ova tema jos neko vrijeme otvorena ako ima jos netko koje pitanje.