Caffe - praćenje robe

Evo, pošto je postojala inicijativa ja ću prvo izložiti poslovanje jednog caffe-a iz knjigovodstvenog kuta, pa tko ima volje i želja neka se proba izraziti iz programerskog kuta (sa dijagramom, relaciom). :-)

Napomena: Niže objašnjen ulaz robe (pod stavkom 1.) sam obradio kao bazu podataka (zakačena je), pa bi me također zanimalo da li može da se ta baza kao takva koristi za daljnji razvoj da sad ponovo ne prolazimo ispočetka ono što je više - manje objašnjeno u temi: RunningSum problem? Također sam tu započeo samo relacijski stavku 2. Izlaz robe.

Evo knjigovodstvenog tijeka:

1. Ulaz robe:
a) Prvo dobijemo račun od dobavljača na osnovu kojega radimo "kalkulaciju" iz koje se vidi koliko je robe ušlo, koja je marža, PDV (0 i 22%), predporez i sl. (vidi zakačenu bazu) i sa tim dokumentom se zadužuje caffe.

b) Druga stvar koju možemo da dobijemo je račun dobavljača koji ide direktno u troškove prema određenom kontu na dokument koji se zove "temeljnica" (vidi zakačenu bazu). Razrada je po kontu iz razlog što se kasnije iz toga vade podaci za tromjesečni i godišnji statistički izvještaj.

c) Nakon što se iz računa napravi temeljnica i kalkulacija tada se u "knjigu ulaznih
računa - URA" upisuje – datum, broj računa, naziv dobavljača, ukupno iznos, iznos bez pretporeza i pretporez.

2. Izlaz robe:
a) Obavlja se preko blagajne i to po pojedinim artiklima koji su prodani taj dan

b) Nakon zaključenja blagajne tog dana podaci o prometu se prebacuju u "knjigu izlaznih računa – IRA", koja sadrži ista polja kao i knjiga URA, samo umjesto pretporeza je sada porez.

3. Knjige:
a) Razlika između knjige URA i IRA je osnova za mjesečni izračun PDV – a koji se uplaćuje državi.

b) Iz kalkulacija i blagajne se formira "knjiga šanka" sa poljima po danu: zaliha robe od jučer + ulaz robe - izlaz robe (po prodajnim cijena), sve po vrsti artikla, te sumarno taj dan. "Knjiga šanka" je osnova za plaćanje poreza na potrošnju po pojedinim vrstama robe po kojima se plaća različita stopa. (npr. pivo, sokovi i sl. imaju stopu 3%, a kava 0%). On mora biti iskazan dnevno, a izvještaj se dostavlja mjesečno.

4. Kartice:
a) Artikla
b) Komitenata
c) Konta

5. Financijsko zatvaranje:
a) Dobavljača (komitenata) – kada platim račun / e u banci, tada drugi dan dobijem izvod prema kojem zatvaram dobavljača i to na način - prema broju računa i nazivu dobavljača (gdje je moguće da se jednom plati dio računa, pa zatim kasnije drugi dio.

6. Kontiranje – svaka promjena trebala bi biti popraćena po kontima (npr. dobavljač je konto 220 i kad on isporuči robu tada konto 220 potražuje npr. 122,00 €, a konto pretporeza duguje 22,00 € i konto skladište 100,00 €). No, to ću još malo istražiti, pa ću napraviti u Excelu jednostavni prikaz da bude svima jasno.

Već i ovo mi se sad, kad je jednom napisano, čini previše za jednu poruku, pa ako neće nešto biti jasno rado ću pojasniti ili ako mislite da treba otvoriti novu temu i razglabati dio po dio!

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

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.

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?

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.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

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?

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

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.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

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? :)