Popust zaboravi, odmah, nije predvidjen trenutnim propisima u Srbiji. Jedini način je da radiš nivelacije cena...

Ovo čisto da ne gubiš nepotrebno vreme...

Aha, ima popusta, još kako. Recimo, u bazu ili fiskalnu kasu uneseš ISTI artikal sa dve različite cene.

Ako ipak mozes u svoj model ubaciti prijemnicaID u tabelu IsplateDobavljacu. Razumijem da ne treba za svaku prijemnicu posebno biljeziti, no ja zapravo nemam prijemnica. Imam direktno samo racune i prema njima placam.

Prema ovom tvojem modelu znam napraviti query i kasnije report kao karticu dobavljaca, no kada to mora biti popraceno odgovarajucim brojem racuna, tj. u tvojem slucaju otpremnice tu mi nastaje problem. Pa ako ti nije problem to ubaciti u model?



Ja sam i knjigovoda i vlasnik jednog malog kafica, tako da mogu oko toga pomoci, no kako sam spomenuo nemam prijemnica nego direktno racun i direktno se zaduzuje caffe i nema izmedu nikakvih skladista. A primjer kalkulacije kakav je u Hrvatskoj mozes pronaci u onom mojem primjeru u temi caffe.

Zakaci onda kopiju jednog prosecnog acuna da je vidimo, ako nije poslovna tajna.

Sto se tice broja racuna uz uplatnicu, dodacemo. Cini mi se da je isto i u Srbiji, pa ce valjati svima.

Primjer kalkulacije u Hrvatskoj.


_{[Ovu poruku je menjao vmatoic dana 27.10.2005. u 11:46 GMT+1]}

Hvala za primer kalkulacije. Sad je mnogo jasnije (videces dole)

Medjutim, moram da vidim Racun koji dobijas od dobavljaca. Izvini sto sam toliko dosadan, racun pa racun, ali to je kljucni dokument, to je ono sto je ulaz u proces. Onda cu moci da postavljam bolja pitanja. Znam da si verovatno sve ovo odgovorio u temi kafic, ali moj mozak ne moze to da svari tom brzinom, mora korak po korak i neke stvari moram da vidim, nije dovoljno da mi objasnis

U stvari, najbolje je ovako:
1) primer racuna koji dobijes od dobavljaca
2) kalkulaciju za taj konkretni racun, prva dva-tri artikla

Nazad na kalkulaciju:

Razumeo sam za sada ovoliko:
Ulazni podaci za kalkulaciju:
- Naziv artikla
- Kolicina (u jedinici mere za datu robu)
- NC (valuta)
- Rabat (%), 3.5%=0.035

NettoNabavna = NC*(1-Rabat/100)
priimer NC=2.5, Rabat=3% => NettoNabavna = 2.55 * (1-3/100) = 2.47

Ovo dalje nagadjam, ispravi me molim te ako gresim:

- Marza = ulazni podatak, citas sa racuna, izrazen u valuti

Marza% = Marza / (NettoNabavna *Kolicina) * 100%,
primer: marza=32.68, NettoNabavna =2.47 =>
Marza% =32.68/(2.47*10)*100% = 1.323 * 100% = 132.31%

Predporez = ulazni podatak, citas sa racuna, izrazen u valuti

PC = maloprodajna cena, izrazena u valuti

PDV = ulazni podatak, citas sa racuna, iznos poreza na dodatnu vrednost, izrazen u valuti, ili PDV = (PC*Kolicina) * 18/100 (priblizno 18%?)

BezPDV = (PC * Kolicina) - PDV

IznosZaPlatiti = NettoNC + Predporez

Ako je ovo sve tacno sto sam napisao, onda u tabeli PrijemnicaDetalji treba imati polja za sve podatke koji stizu sa racuna i onda cela ova kalkulacija postaje jako jednostavna u najobicnijem kveriju.

Ako su neki od ulaznih poadataka atributi robe a ne ulaznog racuna, onda treba da se nalaze u tabeli Roba. na priomer, ako je rabat uvek isti za datu robu (zavisi dakle od Robe) onda rabat treba cuvati u tabeli Roba. Ako rabat za robu 'COLA'oze da bude na jednom racunu 0% a na drugom 3%, onda to treba cuvati sa racunom, ili prepisivati iz tabele Roba.

Pomozi mi jos jednom da shvatim PC (= maloprodajna cena?) Ispada da tebi dobavljac odredjuje po kojoj ces ceni da prodajes robu?



:-)

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

Nije mi jasno zašto vam to ne obezbedi kolega odavde koji je započeo celu diskusiju? On svakako radi na tom programu, pretpostavljam i da ima sve podatke; pošto hoćete da pomognete pretpostavljam da bi to bilo u redu. Ako se ne varam, to je ona mešaona hrane. Ako da, onda se izvinjavam. :)

[Quote]Predporez = ulazni podatak, citas sa racuna, izrazen u valuti[/Quote]

Bojim se da ovoga nema u Srbiji. Čini mi se i da prodavac ne izražava svoju maržu na računu.

Jos nismo stigli do mesavina, to je za posle. Za sada samo hocemo da napravimo ulaz izlaz i famoznu kalkulaciju za recimo bakalnicu. Pa cemo da se vratimo na kafic, a tamo se bavimo spricerima i koktelima (pivo vise necu da spominjem, ja ga ni ne pijem inace).

Ako u Srbiji nema predporez, tri put ura za Dinkica :-)

Poenta je da u bazu strpamo ono sto se nalazi na ulaznom dokumentu, samo sirove podatke, a racunanje mozemo da obavimo i sami. Ko ima predporez, neka upise, ko nema, neka uziva.

:-)

Osecam se prozvanim :) , krenule su slave pa se malo zabatalio posao, posto "tata" Zidar kaze da prvo resimo ovaj ulaz i izlaz, kalkulacija bla bla bla ajd da se to resi pa cemo da predjemo na mesavinu hranu :)
Poz

Da nije u pitanju različita terminologija?
I u Srbiji prilikom nabavke robe plaća se porez na vrednost nabavvke. Kad se roba proda plaća se porez na razliku u ceni. Međutim prilikom obračuna porez se prikazuje na celokupan iznos pa se umanjuje za iznos predhodno plaćen.

naprimer:

ulazna cena bez poreza=100
porez =18
Plaćeno dobavljaču =118
prodajna cena bez poreza= 150
obračunati porez = 27

porez za uplatu 27-18=9

Znači postoji predhodno plaćeni porez i iskazuje se u poreskoj prijavi. Da li je to isto što i predporez?

ulazni racun je ujedno i kalkulacija.
obveznik pdv unosi u nabavnu vrednost robe vrednost sa racuna bez poreza, a ko nije obveznik pdv-a unosi za nabavnu vrednost vrednost sa racuna bruto.
isto je i sa zavisnim troskovima nabavke.
u vezi rabata vidim da ga je neko spomenuo, na izlaznom racunu, ako dajes rabat na neku kolicinu robe onda moras npr.
ulaznom kalkulacijom si postavio marzu 10% na 100 kg hleba, sada pri prodaji 10 kg hleba uvodis rabat odnosno smanjujes marzu te bi trbalo napraviti novu kalkulaciju napr. sa sifrom SK (storno kalkulacije) kojom pravis kalkulaciju na -10 kg psa marzom od 10%, i NK (novu kalkulaciju) sa 10 kg hleba sa marzom 8% (ako si rabat postavio na 2%)
ja sam jos proletos krenuo da pravim aplikaciju na ovu temu medjutim zbog drugih obaveza stao, nadam se da cu nastaviti kad budem imao vremena

Upravo je to tako kako je BiloKoje opisao! I takav porez za uplatu se uplaćuje mjesečno državi.

Mislim da je nama upravo ta terminologija često problem zbog toga jer nas ima od svakud. :)

Evo prilažem primjer računa i kalkulacije u Excelu gdje je sve objašnjeno i gdje se može vidjeti po tome što se s čime množi, djeli, oduzima i sl.

I tako bi otprilike trebao izgledati naš query. Jel sam u pravu?

Evo moje baze koju sam napravio za maloprodaju koristeci par knjiga i informacije sa ovog sajta funkcionise iako bih hteo da je napravim ispocetka jer je sve neuredno sklepano posto se ja accessom bavim zadnih godinu dana iz hobija a inace sam trgovac.

evo drugog dela

Sto se tice kalkulacije, malo je ozbiljnije nego sto izgleda. Naime, prvo je bitno da li je dobavljac koji je ispostavio fakturu u sistemu PDV-a, a zatim da li je korisnik za koga se radi takodje u sistemu PDV-a (kasnije cu se pozabaviti detaljima).Zatim, nabavna cena sa racuna moze biti sa ili bez poreza (sto znaci - ako je bez poreza primenjuje se procenat poreza koliki jeste, a ako je sa porezom - primenjuje se preracunata stopa). Po meni, ovo su osnovni parametri koje treba definisati na samom pocetku (postoji i slucaj kada je dobavljac poljoprivredni proizvodjac, ali ne bih sada o tome).
Kalkulacija bi trebala da se sastoji iz osnovne forme na kojoj ce se unosti osnovni podaci (sifra dobavljaca,datum, valuta, broj racuna, pdv u ceni, rabat - u dinarima ili procentima). Za nju da bude veza podforma koja bi trebala da sadrzi sledeca polja (naravno oboje je samo predlog):
Artikal - sifra artikla (unosi se)
Stopa - (vuce iz tabele roba) - poreska stopa (u slucaju da se promeni poreska stopa u tabeli roba u kalkulaciji mora da ostane prava)
Kolicina - nabavljena kolicina (unosi se)
Cena - nabavna cena sa racuna (takodje se unosi jer je u maloprodajnim objektima sa velikim brojem artikala nemoguce (u nasoj zemlji bez upotrebe barkoda) odrediti kom artiklu pripada koja cena, plus razliciti dobavljaci za iste artikle daju razlicite cene)
Nabavna vrednost - (racuna se, moze da se menja rucno) iznos koji se dobija kada se pomnoze kolicina i nabavna cena. treba ga upisivati isto zbog zaokruziavnja koje je veoma cesto razlicito a krajnji zbir mora biti isti kao na racunu.
Rabat - (Unosi se) - Rabat odobren od strane dobavljaca, moze biti u dinarima ili procentima
Iznos rabata - (Racuna se) - kada se unese prethodno polje da se iznos upise u ovo. Neophodno je jer na racunu dobavljaca moze da se pojavi zaokruzenje koje nije matematicki tacno (cak sta vise cesto se desava), pa mora rucno da se unese iznos)
Prethodni PDV - (izracunava se) - porez koji je placen dobavljacu i obaracunava se na nabavnu cenu (treba da se obracunava za svaku stavku, a ne da se unosi rucno, jer nema na svakom racunu iznos poreza pojedinacno).
Marza - procenat marze - moze i da se unese i da se izracuna (desava se da klijent kaze stavi mi 20% marze pa koja se dobije prodajna cena. Takodje, kada se unese prodajna cena da izracuna procenat marze).
Prodajna - (unosi se ili se racuna nakon unosa procenta marze) - prodajna cena koju odredjuje onaj za koga se radi kalkulacija

Prodajna vrednost i iznos marze u dinarima ne moraju da se upisuju jer uvek mogu da se izracunaju i ne menjaju se ni u kom slucaju (mada je daleko lakse upisati i ova dva podatka).

Ovo je samo osnovna konstrukcija koja zadovoljava minimalnu funkcionalnost. Sledi obracun.

Nabavna vrednost
Ako je onaj za koga se radi kalkulacija u sistemu pdv-a onda:
- ako je PDV sadrzan u nabavnoj ceni treba ga prvo oduzeti pa izracunati nabavnu vrednost (kolicina * (cena - porez))
- ako PDV nije u ceni onda je nabavna vrednost = kolicina * cena
Ako korisnik kome se radi kalkulacija nije u sistemu PDV-a:
- ako je pdv u ceni nabavna se racuna kao kolicina * cena
- ako pdv nije u ceni nabavna vrednost se dobija tako sto se na vrednost kolicina * cena doda i iznos prethodnog pdv-a

Rabat
Rabat se obracunava tako sto se na nabavnu vrednost primeni procenat rabata, ako je rabat u procentima. Ako je rabat u dinarima iznos se ne menja.

Obracun prethodnog poreza (pdv koji je placen dobavljacu i ulazi u odbitak)
- Ako su i dobavljac i kupac u sistemu PDV-a porez se racuna tako sto se na nabavnu vrednost od koje je oduzet rabat primeni stopa poreza. U slucaju kada je nabavna cena bez poreza primenjuje se stopa kolika jeste (npr. 18%), a ako je cena sa porezom primenjuje se procenat koji se dobija preracunatom stopom (preracunata stopa se dobija kao (100 * Stopa) / (100 + Stopa) - gde bi za 18% poreza se dobilo 15,254237%).
- Ako je dobavljac u pdv-u a kupac nije prethodni pdv je nula (sabira se u nabavnu vrednost)
- Ako dobavljac nije u sistemu pdv-a a kupac jeste - prethodni pdv je takodje 0 jer ga obveznici koji nisu u sistemu pdv-a ne iskazuju
- Ako obojica nisu u pdv-u prethodni porez je takodje nula.

Marza
- ako je nabavna cena sa porezom procenat marze se dobija kao ((Prodajna - Cena) * 100) / Cena
- ako nabavna nije sa porezom procenat marze se dobija kao ((Prodajna - Cena - (Ukukupan_PDV / Kolicina)) * 100) / (Cena + (Ukukupan_PDV / Kolicina))
(prodajna je prodajna cena, cena je nabavna cena, Ukupan_PDV je iznos prethodnog poreza, (Ukukupan_PDV / Kolicina) je iznos prethodnog poreza za uentu cenu po jedinici mere i, naravno, moze i drugacije da se izracuna)

Prodajna vrednost
Uvek je kolicina * prodajna cena


Par napomena:
Obracuanti porez je porez koji se racuna na prodajnu cenu i razlika izmedju obracunatog i prethodnog je za uplatu. Medjutim, kako se za obracunati porez kod nas uzima podatak sa fiskalne kase (iz maloprodaje naravno) nema nekog posebnog smisla da se obracunava kod izrade kalkulacije.
Programeri koji su radili programe za fakturisanje veoma cesto prave gresku kod ukupnog iznosa poreza. Naime, ne sabiraju pojedinacne stavke sa fakture nego na kraju primene procenat poreza na osnovicu za obracun. Na taj nacin se ne retko desava da se ukupan zbir poreza na pojedinacnim stavkama razlikuje i po desetak para u odnosu na izracunati (pogotovu kada se koristi preracunata stopa koja je po prilicno nezahvalana ako se koristi sa manje od 6 decimala). Tada se mora rucno menjati iznos poreza u kalkulaciji jer mora biti u paru isti kao na racunu.

Nadam se da nisam previse zakomplikovao i da ce vam ovo koristiti.

Sad kolektivno mongo vise znamo od racunima i Kalkulaciji :-)

Nieam imao vremena da pogledam attachmente u poslednjim postovima, ali sam zakljucio jedno:
- sta god se nalazi na racunu, ima da se unese u tabelu tblUlazDetalj
- sta god je vec izracunato na racunu, ima da se prepise sa racune, umesto da se racuna, zbog zaokruzivanja i zbog sinhronizacije sa racunom.

Cim stignem, pogledacu attachmente i vreovatno prepisati strukture u novi fajl i dacemo kao neki program i potrebne kverije.

Imam puno posla na poslu ovih dana a i bio sam nesto bolestan, pa se oteglo. Godine, sta ces ...

:-)

Evo da nesto i uradimo. Hvala kolergi VMaotic na prilozenoj kalkulaciji i racunu. ostale attachemnet nisam jos stigao da pogledam, ali verujem da pomazu ba r nekome da se razjasni problem.

Napravio sam deo baze, tek toliko da pokrije ulaz i kalkulaciju. Jasno je da se kalkulacija arzlikuje od slucaja do slucaja, od zemlje do zemlje, ali niej bas toliko razlicito. Pokusao sam da napravim model koji moze da sluzi kao osnova za razlicite kalkulacije. U zakacenom fajlu je primer racuna i kalkulacije koje je dao Vmaotic, jedan Word dokument gde sam dao neka objasnjenja i MDB back end sa dva kverija.
U MDB fajlu, procitajte komentare o poljima u dizajnu tabela. ima nekoliko stvari koje mogu da se ubace u model ali i ne moraju, zavisi od situacije.

Proanalizirajte tabele i vidite da li to ima smisla. Ko ima drugacuju kalkulaciju, pokusajte da je napravite u kveriju, na osnovu modela koji sam predlozio, da bismo testirali model.

Ako sam zabrazdio u nesto sto ipak nema veze sa realnoscu, molim da to neko kaze, da ne gubimo dalje vreme. :-)

evo kako izgleda kalkulacija

Slažem se sa ovim dosadašnjim dizajnom kojeg je Zidar razradio. Također sam mišljenja da CijenaUkupno u tblRacuniStavke NE TREBA.

Samo mi nije jasno zašto u tblRacuni imamo stavke Iznos, Rabat, Ukupno, Porez, Sveukupno kad ćemo te iznose dobiti na osnovu kalkulacije?

Ili si to tako zamislio da će se kasnije ti podaci sami popunjavati i upisivati u tablicu tblRacuni na temelju kalkulacije, tj. nekog query-a ili forme?

Uglavnom, palac gore za sad, pa čekam da dođemo do dijela kopiranja cjene. (taj dio ne znam). :)

Za savkov!

Svaka cast za program. Tesko se meni odmah usaltati da vidim na koji nacin si ti to zamislio no prvi dojam je odlican. Istina je da je dosta "neuredno" no ima hrpa dobrih ideja kod tebe. El mi mozes reci koju knjigu si koristio kod ucenja?

Za Tacka: hvala na skeniranoj kalkulaciji, pogledacu danas

Za Vmaotic:
Drago mi je da predlozeni model ima smisla.
Q:
A: Svrha prepisivanja svaga sa racuna u tabelu je da se imaju ORIGINALNI podaci, znaci da mozemo da odstampamo report koji lici na stvarni racun maksimalno, ako nam zatreba. Znaci, kontrola unosa u bazu.
Kalkulacija je na neki nacin provera ulaznog racuna i neke stvari moraju da se sloze. Ako se kalkulacija i racun slazu, znamo zasigurno da vazi sledece:
a) Dobavljac nije pogresio u racunanju kad je pravio svoj racun
b) mi smo dobro preneli sve podatke sa racuna u bazu
Ako se ne slazu kalkulacija i ulazni racun, onda ili a) ili b) nisu tacni. Ako a) nije tacno, osporicemo racun. Ako b) nije tacno, onda nam je kalkulacija beskorisna, ne mozemo je upotrebiti ni za sta.

Ako verujemo ulaznom racunu, onda kalkulacija ne mora ni da se radi (barem jedna deo), jer ZaPlatiti ionako pise na racunu, zar ne?

Probacu danas da uradim malo front enda, pa ce biti jasnije.

:-)

OK. Ima smisla. :)

Evo primer kalkulacije po modelu vmaotica. Malo sam pojednostavio dizajn u back endu. Sada su racun i kalkulacija zaista u jednoj tabeli, posto svi kazu da je Racun i kalkulacija jedno te isto.

U primeru se moze videti kako se prepisuje vrednost MPC iz tabele roba (after update za kontrolu RobaID na subformi)

:-)

Evo i mene.
Nadam se da cu pomoci.
Odmah da napomenem da nisam sve procitao od pocetka samo letimicno pogledao.
Naravno skinuo sam ovu zadnju bazu i nju sam pogledao.
U tabeli racuni koja bi kako sam razumio ujedno bila i ulaz robe sa kalkulacijom ima nekih polja koje smatram viskom.
Npr. polja sveukupno, rabat, porez ukupno itd, ti svi podaci se mogu dobiti iz druge tabele stavke racuna.
E sad ako se radi i ulaz sa kalkulacijom onda bi trebalo napraviti jos jednu tabelu koja bi bila 1-1 na tabelu stavke racuna i u nju smjestiti polja koja se ticu ulaza a nema ih u izlazu.
Jos nesto da napomenem pri kalkulaciji se odredjuje i izlazna cijena artikla, znaci tu moraju postojati svi ama bas svi troskovi za taj artikal kao i porezi i nakon toga kad se doda dobit formira se cijena.
Na ekranu to treba da izgleda ovako po meni.
Ulazna cijena
Rabat
trosak 1
trosak 2
trosak 3
Marza
Porez
izlazna cijena

Naravno sve stavke treba da imaju polje za kol 1 i za ukupan broj komada ulaza.
Sve stavke isto trebaju da imaju mogucnost upisa u % i u valuti
Pored ovoga treba da postoji mogucnost rucnog unosa izlazne cijene a da sad se sve ostalo preracuna po toj cijeni.
Eto to je moje misljenje.
Pozdrav svima

Za Zidar:

Ovu shemu znam. To smo vec u jednoj temi rjesavali. Ja sam mislio da ce se dogoditi drukcije prepisivanje cijena.

Ovako kako je sad je dobro, samo opet ona cijena koja se upise u glavnu formu kod unosa racuna da se prepise u tbl_Roba. Tako da u tbl_roba uvijek cuva samo zadnju cijenu. Kuzis?

Za Izonic:

Slazem se svim sto si napisao, no ovo je samo jedna pojednostavljena verzija da se nauce neke stvari.

Za Vmaotic: kalkulaciju sam doslovno uradio po Excel dokumentu koji si prilozio. tamo je MPC ulazni podatak za izracunavanje marze, a ne obrnuto. Na ovoj temi postoji i kalkulacija koju je prilozio Tacka, tamo se jasno vidi da se kalkulacijom izracunava nova cena. Tvojom kalkulacijom se nova cena ne izracunava, nego se koristi kao ulazni podatak. Mogu da napravim da sta god upises u polje MPC na racunu, to ode u tabelu roba. U tom slucaju bih izbacio prepisivanje iz tblRoba koje sada radimo, jer se vrtimo u krug?

Z Izonic: hvala ti na korisnim komentarima. Slazem se da vecinu kalkulisanih polja treba izbaciti zi tabele, ja sam ih ubacio samo zbog moguce kontrole. Sto se men tice, ni polje Za Platiti ne mora da se prepise sa racnua, jers r ga racunamo u kalkulaciji, a mozda ne mora ni da se racuna, jer vec postoji na racunu? Jedini problem koji vidim u modelu koji si predlozio su polja za troskove
("trosak 1", "trosak 2", "trosak 3"). Ona treba da idu u posebnu tabelu, zbog pravila normalizacije. Pitanje 'koliko ima troskova' se tesko moze odgovoriti korektno. U momentu dizajniranja baze moze biti 3 troska, dve godine kasnije moze biti 5 ili 2. U jednoj drzavi je 3 troska, u drugoj 1 ili 5 mozda. Zbog toga bih to stavio u posebnu tabelu. Ovo ce malo zakomplikovati izracunavanja, ali ti daje fleksibilnost, model moze da se primeni bilo gde u bilo koje vreme i da se menja sa vremenom. Ako se promene pravila za kalkulisanje, bice mnogo lakse prepraviti kverije ako su podaci normalizovani.

Ajde sad da probam da uradim prepisivanje cene iz kalkulacije nazad u tabelu Roba za Vmaotic :-)

Evo isti primer od ranije, dodate dve stvari:
1) prepisivanje MPC sa racuna u tabelu Roba (Prepisivanje iz Roba u Racun postoji i dalje)
2) dodato OLE polje u tabelu Racuni, gde se moze cuvati skenirana kopija racuna

Sta cemo dalje?
A) Da dodamo evidenciju placanja? Ako da, onda imam pitanja:
1) koja se placanja evidentiraju: dobavljacima (Racun.ZaPlatiti ) i/ili drzavi za porez?
2) da li da kombinujemo sva placanj u jednu tablicu ili je bolje odvojeno?
3) da li nekada neko (osim kupaca u maloprodaji) uplacuje robu nasoj radnji? Recimo, preplatili smo nekada, pa nam dobavljac ili drzava vrate pare?

B) Ili da probamo da ubacimo ostale trskove, za izracunavanje MPC, u normalizovanom obliku (trosak1, trosak2, trosak3,.. trosakN nisu polja u tabeli StavkeRobe, nego se cuvaju u posebnoj tabeli sa poljima (OpisTroske,IZnos_ili_Procenat)

C) Ili da dodamo modul Prodaje robe, koji smo negde na pocetku vec imali?

D) ili da molo ovo odstoji, pa da se vratimo na mesavine ?

To je to! :-)

Hvala majstore!

Sto se nastavka tice ja sam da se proba napraviti kartica dobavljaca, znaci evidencija placanja, pa da probamo preci malo na mesavine.

I jednostavnosti radi moze da samo pokazemo placanje dobavljacima (Racun.ZaPlatiti ), jer ako idemo na poreze opet ce tu biti razlika od drzave do drzave.

Moze?

A ovo da imamo preplatu - pa moguce je - no, ja se u svojem radu s time nisam bas susretao, a kad bi se i susreo onda tom dobavljacu po iducem racunu platimo manje i gotovo. Tako da sto se mene tice ovo ne treba uzimati u obzir.

:-)

Evo kartica dobavljaca. Treba otici na formu Dobavljaci i tamo kliknuti na dugme Kartica Dobavljaca. Napravio sam dve verzije reporta, valjda ce bar jedna da bude dobra.

Uplate se unose direktno u subformu na formi Uplate Po Racunima.

Uplate sam vezao za racune, 1:1. Znaci u tabeli Uplate svaki racun moze da bude tacno jednom, ne vise. Tako mi je trazeno ("uplate se vrse po racunima"). Ne bi valjalo da u tablicu Racuni stavimo polja koja se bave uplatom, ako neko ima takve ideje. Razlog - naka pravila normalizacije, pa neka bude ovako.

Licno mislim da bi trebalo dozvoliti da se jednom uplatnicom plati vise racuna, pa se spisak posalje dobavljacu sa kopijom uplatnice, da ustedite sebi malo posla. Zamislite hleb koji stize svaki dan. Ne mogu da verujem da za hleb treba da napravite 30 uplatnica svaki mesec, jer ste dobili 30 racuna.


:-)

Dana Wed, 9 Nov 2005 20:59:20 CET, Zidar napisa:



Normalno je da se tako i radi. Ne mora se uvek platiti po svakom racunu

pojedinacno. Nekada se plati i za vise racuna a nekada i za pola racuna

danas, a sutra ostatak kada legnu pare na racun.


Pristigli racuni nas zaduzuju kod dobavljaca a nase uplate nas razduzuju.

Normalno je da je to u nekoj ravnotezi ali ne mora da bude uvek tako. Neki

od dobavljaca nam moze dati robu i na odlozeno placanje.

Hvala Mkaras :-) Postavicu sutra novu verziju.

Nesto smo se krivo razumjeli Zidar. :-) Isto sam za da se moze unositi vise uplata po racunu i obrnuto. Stavio sam samo u tbl_PlacenoDobavljacu Duplicates Yes na broj racuna, pa se onda moze unositi.

No, nego sto tice reporta, vise mi se svida Verzija2, no ako se moze sortirati na ovaj nacin koji je u prilogu?

Sorry ako gnjavim.

Nema problema, normalno je da se ne razumemo ponekad. :-)
Problem je sto ti materiju poznajes veoma dobro a ja veoma malo, pa verovatno ponekad pretpostavis da nesto razumem sto ja u stvari nisak skuzio korektno. To je sve normalno i zato je analiza koja prethodi razvoju aplikacije teska i ne moze svako da je odradi korektno.

Evo nova verzije, sa karticom dobavljaca, onako kako si trazio. To je zahtevalo malu izmenu u dizjnu baze. Doadta je nova tabela, tblUplatnice i neka polja uklonjena iz postojece tblPlacenoDobavljacima. Pogledaj Relationships i razumeces.

:-)

To je to!!! Svaka cast!

Sad cu ja prema tvojem modelu zapoceti svoj pa da vidim dal sam usvojio znanje i ako ce biti kakvih pitanja javit cu se.

Takoder cu vidjeti gdje bi se trebalo sto ubaciti, pa se cujemo (moguce da ce meni za ovo trebati dosta :)).

Hvala!

Evo ja zapoceo bazu prema Zidarovom modelu ispocetka kako bi pohvatao sve, pa imam neka pitanja:

1. Kod prepisivanja MPC nazad u tabelu roba mi radi dobro, no tek kada sam maknuo ove 3 linije:
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strSQL As String

Cemu su one sluzile ako radi bez njih, a sa njima mi nije htjelo?

2. Izbacio sam jednu tablicu, jer sam prilagodio model svojim potrebama i dodao sam 2 tablice vezane za prodaju u najjednostavnijem mogucem obliku (necemo jos sa mesavinama), pa me samo zanima el to OK (vidi se sve u prilogu)?
3. Ako je ok onda imam jedan problem koji nisam siguran kako rijesiti – treba mi report dnevnog izvjestaja ulaza i izlaza robe sa kolonama kao u primjeru koji prilazem.

Nisam nastavio sa izradom izvjestaja i ostalih query i formi dok to ne uspijem rijesiti.

Taman kada sam mislio da sam vecinu pohvatao opet zastoj. :(

Cestitam :-)

Dobro si dodao tabele Prodaja i StavkeProdaje u model. medjutim, ima nekoliko stvari koje treba malkice doterati.

1) Tabela StavkeProdaje nije konstruisana ispravno. U tabeli tblProdajaStavke stavio si da ti je PK=StavkaProdajeID,Autonumber. To je nepotrebno i stetno. Nepotrebno, jer tvoj PK treba da bude kombinacija polja (ProdajaID, ArtiklID). Ako ti je PK (ProdajaID, ArtiklID), onda ne mozes da ponovis isti artikl dva puta u jednoj prodaji. Zasto je stetno uzimati Autonumber za PK tek tako? U tabeli tblProdajaStavke imas takvu situaciju - za ProdajaID=1 imas dve stavke, obe su Coca Cola, jednom 10 drugi put 100 komada, po istoj ceni 7.00. To bi trebalo da se uvede kao jedan rekord (Coca Cola, kolicina=107, cena=7.00).

2)
Ove tri linije sluze da se deklarisu varijable. Kod tebe to radi sasvim slucajno iz dva razloga:
a) nemas referencu na JET engine (Microsoft DAO 3.5 ili 3.6) Ti imas samo referencu na Active Data Objects (ADO 2.6). Posto ADO ne prepoznaje DAO objekte, nije htelo da ti radi. Kad obrises deklaraciju, ono radi. U ranijim vezijama ADO to ne bi uopste radilo, i posle brisanja deklaracija

b) ne modulima nemas deklaraciju Option Expliict, iako tvoje Access Options General kazu "Require variable declaration". I pored toga, tvoj Access te je putio da radis bez deklarisanja varijabli. tu nesto nije u redu i mogu da se kasnije pojave neobjasnjivi problemi.

Sta treba da uradis:
a) skines refrencu na ADO
b) dodas referencu na DAO 3.5 ili 3.6, koji ti se vec pojavi (otvoris VBA modul, bilo koji, i ides u Tools/References, otkacis ADO i skrolujes na dole dok ne vidis Microsoft Data Access Objects 3.5 ili 3.6)

c) u svaki modul (i na formamma) stavis na pocetku Option explicit (sada imas samo Option Compare Database)
d) vratis deklaraciju varijabli svuda gde si je uklonio
e) prekompajliras projekat ponovo

Probacu da zakacim kveri za izvestaj u ovoj ili sledecoj poruci.

Pitanje za DnevniIzvestaj:

Polje Cijena, na kraju, odakle da ga uzmem? Imas sad cenu svuda, u Kalkulaciji, u Prodaji i u tabeli Roba. Vrednosti u tabelama tblKalkulacijaStavke i tblProdajaStavke se ne menjaju kroz vreme, vrednost u tabeli tblRoba se menja kroz vreme. Koju od ove tri da stavim u dnevni izvestaj?

Pokusavam da napravim dnevni izvestaj kao kveri. PC iz tabele tblRoba ne bi bilo dobro, jer se menja s vremenom, pa ako odstampas dnevni izvestaj za isti datum, danas i za sest meseci, dobices razlicite izvestaje. A ne bi bilo dobro da se cuvaju dnevni izvestaji u tabelama, zato sto su sva polja izracunata, nema nista sto pripada iskljucivo toj tabeli. (Osim mozda cene?)

Odgovori po rednim brojevima:

1.Znam da sam to krivo – to si me vec jednom upozorio!
El mi uopce treba tu polje PK, tj. stavkeID?
Ako ne treba onda netreba ni u tbl_StavkeKalkulacije!?

A kod tbl_StavkeKalkulacije sam namjerno izostavio kombinaciju StavkeID i KalkulacijaID kao PK, jer hocu imati mogucnost unosa vise istih artikala po jednoj kalkulaciji.

Zasto? Jer imam na ovom dnevnom izvjestaju npr. stavku "Pivo razno 0,5", tako kad dobijem pivo Tuborg 0,5 po cijeni 3,50 kn i Becks 0,5 po cijeni 3,70 kn ja to unosim kao "Pivo razno 0,5" dva puta, a prodajna cijena im je ista. Malo je mozda bez veze, no to mi daje prostora za manevar u samom poslovanju.

Ili bi se to dalo rijesiti kasnije sa onom pricom o normativima – ja imam ulaz Tuborg 0,5 i Becks 0,5 na kalkulaciji (sto bi i bilo pravilno), a bilo koji od tih ili slicnih artikala se prodaje samo kao pivo razno. No, o tome kad rijesimo ovo. Korak po korak, moze?

2. Uradio sam (bar mislim :-)) ovako kako si rekao – mozes vidjeti u prilozenoj bazi. Sada od referenci imam ukljuceno sljedece:
Visual Basic For Applications,
Microsoft Access 10.0 Object Library,
OLE Automation,
Microsoft Activex Dana Objects 2.1. Library
Microsoft DAO 3.6 Object Library

El mi treba jos nesto?

3. Vezano uz zadnju poruku:
Polje cijena trebalo bi se uzimati iz Prodaje prema onom datumu za koji se izvjestaj radi.

_{[Ovu poruku je menjao vmatoic dana 16.11.2005. u 12:42 GMT+1]}

Hvala na brzom odgovoru :-)

Sto se tice PK u tabelama ProdajaStavke i kalkulacijaStavke, teorijski prica je ista. ne bi trebalo da se koristi Autonumber za PK, nego kombinacija polaj. Ali, i ako se koristi Autonumber, ne smeta ukuliko imas UNIQUE INDEX po poljima (prodajaID,ArtiklID), odnosno (KalkulacijaID,ArtiklID). To bi bilo kao da imas dva kljuca, jedan po Autonumber polju, a drugi po dva polja.

Razumem da bi hteo to da zadrzis u kalkulaciji, zato sto zelis da se na ulazu piva razvrstavaju po proizvodjacu (Jelen nije isto sto i Tuborg), a na izlazu da idu kao jedno te isto, pod imenom "Pivo Razno". Tu vec imamo malcice problem. Nisi ga uocio jer u primeru koji si poslao imas samo artikle Cola, Juice i Kava. I u kalkulaciji i u prodaji mozes da iams samo ono sto pise u tabeli Roba za svaki pojedinacni ArtiklID. Ako imas razlicite ArtiklID za svaku vrstu piva u tabeli Roba, to ces dobiti i u kalkulaciji i u prodaji. Ne moze na ulazu odvojeno a na izlazu svi zajedno. Ako hoces da ipak se sve prodaje pod imanom "Pivo razno", "Skovi razni","Cola razna", onda ti treba u tabei Roba dva polja, ImeNaKalkulaciji i ImeZaProdaji. Onda bi ImeNaUlazu bilo razlicito za svako pivo/kolu/sok, a sva piva, svi sokovi (ili bar neki) imali bi isto ImeNaIzlazu. Onda ti se naravno menjaju kveriji za brojanje, i sve se komplikuje. Da li si siguran da je to ono sto zelis?

Molim te da nove verzije attachmenta oznacis brojevima. U prvoj poruci bio je Caffe.ZIP. U drugoj treba da bude Caffe_02.ZIP. na taj nacin kad ih downloadujem nece jedan drugoga prebrisati i imamo uvid u to kako je dizajn evoluirao kroz vreme.

Sad nesto konkretno:

Ovo moze da se resi na dva nacina:
1) da se cena prikaze samo za one artuikle koji su imali prodaju u datom danu, a ostali artikli imaju ili 0 (nula, nistica) ili NULL (prazno). Meni ovo izgleda razumno
2) da se cena cuva iz dana u dan za SVE artikle pa da se prikaze za SVE artikle, imali prodaju ili ne. I ovo mi izgleda razumno, ali je mnogo vise posla i komplikovanije nego 1)
Molim te za komentar.

Evo da sve pojednostavimo! :-)

Neka za sad bude ulaz pivo razno i izlaz pivo razno, tj. istovrsni ulaz za istovrsni izlaz!

Vazi za attachmente u buduce.

Moze ovo jednostavnije pod 1!

Eto, ne moze jednostavnije! :-)

Dobro, probaj ovo.

Evo na prvi pogled to je to, no budem ja sad to proucavao preko vikenda, pa se javim drugi tjedan.

Imaces vise od nedelju dana za testiranje. :-)
Ja iduce nedelje nisam tu, pa necu moci da odgovaram na poruke.

Vidim da se Zidar vratio pa da podnesem "izvjestaj". :-)

Prilazem bazu, pa ce ti sve biti jasno.

Uradio sam ipak report za dnevni izvjestaj bez oni tablica i bez koda. Prvo mi je bacalo poruku da ne moze subquery, no onda sam napravio kombinaciju tablice i query-a.

El to uredu?

Dodao sam par sitnica - porez na potrošnju (PP) u izračunu kalkulacije i to su sad svi mogući porezi koji meni trebaju, zatim da nudi iznos kod uplata prema broju racuna, kojeg mozemo prihvatiti ili ne i jos neke sitnice oko informacija na samoj formi potrebnih za korisnika.

Kako ti se za sad cini? Mogu dalje, dok ne zapnem :-)?

Evo me nazad, ali sad moram duplo da radim da nadoknadim sto sam bio otsurtan. Nezgodan ovaj kapitalizam mnogo, mora da se odradi sto se propusti. Nisam zaboravio na temu, ali nemam vremena da detaljno pogledam sta si napravio. U svakom slucaju, ako radi ono sto ti treba, dobro je, barem radi. valjda cu do kraja nedelje imati vis e vremena pa cu pogledati, pa onda mozemo na spricere.

:-)

Da, mnogo je nezgodan ovaj kapitalizam. :)

Nema veze, i ja sam bio dosta zaposlen ovih dana pa nisam nista dalje radio, bacim samo povremeno pogled na forum.

Nastavljamo onda za kojih tjedan dana ili kad se uzmogne vremena!

Evo opet problema.

U formu frmProdajaStavkeAdd, koja je subforma frmProdajaAdd pokušavam ubaciti kolonu stanje robe kako bi imao uvid kod prodaje, no to mi baš i ne uspijeva poći za rukom. :(

Dobio sam samo neka polovična rješenja. :(

Pa kad bude vremena, ako nije problem da se to vidi.

Pogledao sam malo bazu. Ako hoćeš da vidiš stanje prilikom unosa prodaje, mislim da je dobro sledeće rešenje. U upitu qryPrimljenoProdano treba dodati kolonu stanje:[primljeno]-[prodano]. Zatim iymeniti record source za frmProdajaStavkeAdd tako što će record source biti upit sastavljen od tabele tblprodajastavke i upita qryPrimljenoProdano povezanih preko artiklID. Onda jednostavno dodaš polje Stanje na formu.

Nadam se da sam jasan.

Bas to ne moze tako kako si ti zamislio ili ja ne znam odraditi.

Evo prilazem bazu u kojoj imam to svoje polovicno rjesenje.

Sve ce ti biti jasno kad otvoris frmProdajaAdd.

I to tako sad radi, vidi se zadnje stanje, no trebalo bi popraviti 2 stvari:

1. Da se ubaci neki filter koji bi prikazivao samo stanje od onog datuma na kojem se nalazimo u frmProdajaAdd.

2. Ja bi radije ako moze da frmProdajaStavke bude datasheet i da vidim sto unosim redak po redak, a u koloni stanje da bude stvarno stanje robe na taj datum? Jer kada prebacim iz singlform u datasheet javlja error. Pretpostavljam da isto treba neki filter koji ce tocno reci Access koji podatak da uzme?

Ako imas sretnije sveukupno rjesenje rado cu ga poslusati.

Evo, dodao sam upite QueryStanje, QueryPrimljeno i QueryProdato kao i FormProdaja i SubformProdajaStavke. To je jedan mogući način kako može da funkcioniše praćenje stanja robe. Naravno može i drugačije u zavisnosti od zahteva korisnika.

Ma, mi se cijelo vrijeme ne razumijemo. :)

Jasno je meni kako dobiti pregled stanja. To već i imamo u queryu i izvjestaju.

No kako na formi za unos podataka imati stanje?

Forma za unos prodaje moze ovako izgledati kako si napravio, no na njoj nemas mogucnost unosa stavaka, samo pregled.

No, dao si mi jednu ideju sa svojim rjesenjem.

Tako da sad prilazem bazu.

U odnosu na verziju caffe04 promijenio sam slijedece:

U qryPrimljenoProdanoUkupno u polje datum sam dodao kriterij [Forms]![frmProdajaAdd]![Datum]

Tako da sad kad se pokrene forma za prodaju ili frmProdajaAdd to radi OK, no ja bi samo ako je ikako moguce da subforma frmProdajaStavkeAdd bude datasheet?

Probaj promijeniti frmProdajaStavkeAdd u datasheet i vidjet ces u cemu je problem.

<sub>[Ovu poruku je menjao vmatoic dana 02.12.2005. u 08:06 GMT+1]

[Ovu poruku je menjao vmatoic dana 02.12.2005. u 08:07 GMT+1]</sub>

Da je ova tema gotova ili je ponestalo ideja, posto ja cekam izlazni racun u maloprodaji.

Nije gotova, no malo se oduzilo jer nije bilo vremena ovih dana.

Ja cu probati raditi na daljnjem dodavanju pojednih opcija na bazu, dok Zidar malo ne baci oko da vidi u cemu je greska sa ovim stanjem koje smo spominjali u par prijasnjih postova.

A izlazni racun u maloprodaji ti je zapravo nedoradena do kraja forma Prodaja. Tu se moze dodati jos samo veza na formu Konobari ili Blagajne i iz toga se radi izvjestaj i to je to.

E, tu cemo dodati jos samo onu pricu sa normativima, tako da u prodaji mozemo imati gemist (0,10 vino + 0,10 voda) ili neki koktel i sl.

Priznajem da nisam ni pogledao sta je novo. Ucinilo mi se da se uz zahvaljujuci BiloKoje sasvim lepo snalazite. Pogledacu pa cu se javiti, sad se lakse dise. Imao sam vremena samo za kratke odgovore tu i tamo. Sva sreca da nisam ni jedini ni najpametniji na forumu, pa su ljudi dobijali odgovore od drugih majstora.

Pogledao sam Cafef_03 i dopada mi se.

Lepo si resio otvaranje reporta, bez forme i pomocne tabele. Ja licno ne volim u kveri da stavljam kriterij "Form!ImeForm!Polje" ali u ovom slucaju to ispada najbolje resenje, svakako bolje nego akrobacije sa temp tabelom. Svaka cast.

Lepo si resio i prenosenje cene iz tabele tblRoba u tabely ProdajaStavke. u ranijim postovima doa sma negde funkciju koja kopira cenu, a ovde smo to pokupili iz combo boxa. (ili je ovo bilo i pre?)

Dopada mi se i unos, uz neke male dodatke. Zasto ti treba uvid u stanje pri unosu?
Ako zelis da sprecis da se unese vise nego sto imas, sam uvid nije dovoljan. Uvid u stanje moze da kaze imas 3 piva na lageru, a ti ipak mozes da uneses 6 za prodaju.
To moze na drugi nacin (i treba), da program odbije unos ako hoces da prodas vise nego sto imas.

Zakacio sam modifikovanu tvoju verziju 03.

Izmena 1: Stavio sam u formi frmProdajaStavkeAdd na BeforeUpdate kod da spreci unos nedozvoljenih vrednosti (prodato vise nego sto ima). Ako je sve u redu, nema poruka, samo unesi i sibaj. Ako pokusas da prodas vise nego sto imas, dobices poruku (probaj) koja ti kaze i stanje i kolicinu koju pokusavas da uneses.
Stavio sam i uvid u stanje, ali na veom los nacin pa preporucujem da izbacis DLookup iz kverije za frmProdajaStavkeAdd. Vrlo ruzan nacin, quick and dirty. Quick samo za programiranje, a ne i za izvrsavanje. Zapazi da postoji novi kveri qryStanje, baziran na dva isto tako nova kverija. Sve slicno onome sto si imao i ranije, ali malcice razlicito.

Izmena 2: Uklonio sam tabelu Datum iz relacije sa Prodajom. U tblProdaja ionako dozvoljavas vise prodaja po danu (sto je OK). Mozes da vratis tblDatumi ako hoces, vidi sta ti odgovara. Ako je imas u reklaciji, imas punu kontrolu, ali moras da dodajes datume u tabelu ako ih zelis upotrebiti.


Moze li ovim da okoncamo prodaju i kalkulacije, generalno, pa da se posvetimo spricerima?

Dobar dan !
Sve pohvale od strane mene za ovoj rad za maloprodaja

Skino sam ovaj zadnji fajl " BAZA " ali ne radi , kad otovrim i idem na start ono javi neku gresku i nece da mi radi kako treba .
Da li moze neko od vas da popravi to pa da okaci ispravnu bazu ovde na forum

Unapred HVALA !

Izmjene mi se sviđaju!

I ovime možemo za sad okončati ovu priču, mada bi ja nastavio kasnije sa razvojem aplikacije ako ste za. Ja bi sam razrađivao bazu, a u slučaju problema zatražio bih pomoć? Dodao bih kao prvo više izvještaja, zatim u relaciju ubacio troškove i konta i sl.

No, to ćemo kasnije ako ste za i ako bude vremena?

A sad se možemo prebaciti na špricere i predlažem da to nastavimo u temi Caffe.

El možemo uzeti ovu zadnju priloženu bazu i nastaviti na njoj promjene vezane uz "špricere"?

Za kolega Mandic: ja sam skinuo zadnju prilozenu bazu Caffe03_Z.zip i nema nikakvih problema.

P.S. Ako izbacimo tbl_datumi iz relacije tada kad unesem nevezani datum u prodaju report dnevni izvjestaj nece da izlista, tako da je bolje da ostane.

_{[Ovu poruku je menjao vmatoic dana 12.12.2005. u 17:04 GMT+1]}

Poslednji ispravan fajl na ovoj temi je Cafe_03_Z.MDB i izgleda da radi, barem kod mene. Ako neko ima problem, molim javite koju to gresku javlja, 'neku gresku' ne umemo da popravimo, osim d aupotrebimo 'neki nacin' a vi cik pogodite koji je nacin.

Evo mene brzo natrag. :(

Znam da sam rekao da cemo se prebaciti na spricere, no ako je moguce da probamo prvo rijesiti problem na koji sam naisao. Vec se 2 dana patim s tim.

Izmjene koje sam napravi su:

1. Dodao sam u dnevni izvjestaj neke sumarne iznose koji po zakonu moraju biti i to je OK.

2. Dodao sam tblTemeljnicaTroskovi koja je isto ulazni racun kao i kalkulacija samo ne ide u prodaju vec u trosak. Od te tablice i tblKalkulacija sam napravio qryKnjigaUlaza. (tako je Zidar predlagao jednom prije kada sam ja iz te dvije tabele radio jednu novu tabelu-da se ne cuvaju isti podaci jos jednom) i to je OK.

3. Tu tblTemeljnicaTroskovi sam takoder dodao kao ulaz u dobavljace, pa ona ulazi u report KarticaDobavljaca koji vec imamo i to je OK.

4. E, sad problem - Neznam kako tu novu tabelu povezati na tblUplatnice. Pokusao sam istim sistemom kao i sa tblKalkulacija, no onda prije nego mogu upisati BrojRacuna u tblUplatnice me trazi da imam BrojRacuna i u tblKalkulacija i tblTemeljnicaTroskovi. A ako maknem relaciju onda mogu bilo koji broj racuna upisati. Nadam se da se razumijemo.

Zakacit cu i bazu, pa ce nadam se biti jasno sto sam htio.

Ako ipak Zidar misli da treba ovo pricekati i da krenemo sa spricerima, onda cemo se na ovo vratiti.

Skinuo sam caffe_04_Z.ZIP i pogledacu.

Predlazem da ovim polsednjim ispravkama okoncamo temu o Mloprodaji.

Manje vise, svi principi su tu, konkretna kalkulacija razlikovace se od drzave do drzave, kao i zakonom trazeni izvestaji. verujem da imamo nesto sto moze da sluzi za dalju razradu. Pokazali smo nekoliko vaznih stvari, barem u principu:
- prepisivanje cene u i iz tblArtikli,
- zaduzenje/razduzenje dobavljaca,
- pracenje zaliha kverijima bez cuvanja trenutnog stanja,
- pokazali smo kako se sprecava izdavanje vece kolicine robe nego sto ima na lageru

Kako rekoh, da razrsimo polsednja pitanaj u vezi temeljnica i da zatvorimo temu.
Spriceri su cisto problem kafica, pa cemo se vratiti tamo. Pocetna aplikacija bice ono sto pollednje zkacimo na ovu temu.

Moze li ovako? Ao moze, molim ne odgovarajte, ako ne moze, molim da obrazlozite, pa cemo videti sta moe da se uradi.

:-)

ne razumem ovo sa temeljnicom ama bas nista. To si sve objasnjavao na pocetku, ali ni onda nisam razumeo :-(

- Mozes li ponovo da objasnis sta je temeljnica i cemu sluzi?
- Sta to temeljnica ima a kalkulacija nema i obrnuto, a sta im je zajednicko?
- Da li se desava da imas nekad temeljnicu a nemas kalkulaciju i obrnuto? Ako da, kada i zasto?

I u kalkulaciji i na temeljnici vidim da se pojavljiuje Dobavljac i vidim BrRacuna. Nigde u bazi ne cuvamo racune koje dobijemo od dobavljaca, kalkulacija na neki nacin obuhvata i zamenjuje racun od dobavljaca, za sada. Sta sad tu radi temeljnica?

Ako pricate o maloprodaji, tj STR, poredak je sledeci:
Od dobavljaca se dobije faktura tj racun o kupljenoj robi, na osnovu racuna se pravi kalkulacija, a na osnovu kalkulacije popunjava se trgovacka knjiga (TK), i poslovna knjiga (ako se radi o prostom knjigovodstvu).Kada se proda roba, pazar se pise u TK i skida se se sa stanja roba koja se prodala.
To je sve sto je potrebno po zakonu za STR (ne racunam obracun plata, i evidencije PDV), za komisionu prodaju je malo drugacije, ali je vrlo slicno, pa ako vam nestane ideja mozete pokrenuti temu za komisionu prodaju robe, posto je to najzastupljeniji vid prodaje kod nas sto se tice malih radnji i butika.
Pozdrav

Evo ovako:

Dobijem racun od dobavljaca i sa tim racunom radim slijedece:

1. Ako je na racunu roba koja ide u prodaju onda radim kalkulaciju i taj dio smo odradili.
2. Ako je na racunu roba koje sluzi kao potrosnja, tada za taj racun nije potrebno raditi kalkulaciju vec ga samo uvedemo u evideciju i vodi se kao trosak. Evo, to je najjednostavnije objasnjenje.

U trenutnoj bazi je povezana evidencija sa karticom dobavljaca sto se tice ulaza robe (preko kalkulacije ili temeljnice), no nije kod izlaza.

Znaci, u "Uplate" treba dodati pracenje placanja za temeljicu kao i za kalkulacije.

Znam da je tesko u potpunosti objasniti nesto ovako :(, pa cu zato probati jos jednom rezimirati:

Imamo dvije vrste ulaza u poduzece - kalkulacija ili temeljnica
A imamo jednu formu ili tablicu za pracenje placanja tih ulaza.

Ako treba jos nekako pojasniti drage volje cu to uciniti.

Sve je OK :-)
Tacno ono sto sam zeleo da cujem: kad dobijes racun, on moze biti ili kalkulacija, ili temeljnica. temelnjica nema veze sa robom, to moze da bude racun za struju, vodu, zakup prostora. To mi je izmicalo sa pameti, jer to generalno ne ide u model 'kupovina i preprodaja robe'. Medjutim, jets neodvojiv deo poslovanja i mora se ukljuciti u igru, inace model ostade nekompletan. Hvala ti za strpljenje i upornost.

Lako cemo da ukljucimo troskove u model, ali ce to nazalost da izazove promene u nekoliko tabela i kverija. To ti je kad developer ne raume odmah ceo bisnis model, pa napravimo zgradu od sest spratova i na kraju moramo da dodamo jos jedan, ali ne odozgo, nego u sredini, izmedju treceg i cetvrtog :-)

Ovako cemo: zakacicu poslednji primer koji je radio, sa izmenjenom strukturom tabela. Necu da diram kverije pa naravno nista vise nece da radi, ili u najboljem slucaju radice pogresno. Pokusacu da ti ukazem gde sve vidim promene pa da probas da promene uradis ti. Ako zapne, pomoci cemo. Vazi li tako?

Evo nova verzija. Preuredio sam kverije tako da ne moras da se mucis. Medjutim, prouci relationship diagram - uporedi sa onim u prethodnoj verziji.

Uveli smo tabelu tblRacuniOdDobavljaca. Tu cuvamo RacunBR i Datumracuna i jos jednu vaznu stvar - TIP racuna. Tip racuna moze biti "K" i "T", za kalkulaciju i temeljnicu. Posto je svaki racun ili T ili K, ne mozes pogresiti. Isto, nije moguce uneti racun tipa T u tabelu kalkulacije, i obrnute. To je reseno na nivou tabela i kreiranjem vise Candidate keys u tabeli tblRacuniOdDobavljaca.
Posto je polej Datumracuna sada u tebeliracuniOdDobavljaca, ono je nestalo iz tabela Kalkulacija i Temeljnica. Rezultat ovoga je poteba za promenom svih kverija koji imaju vezu Dobavljac<-->Kalkulacija i Dobavljac<-->Temeljnica. Svida je ubacena jos jedna tabela, pa imamo sada ovo:

Dobavljac<-->RacuniOdDobavljaca<-->Kalkulacija i
Dobavljac<-->RacuniOdDobavljaca<-->Temeljnica

Takodje sam ispravio neke greske koje su se potkrale u gradnji kverija za reporte, pa sada sve radi malkice pouzdanije.

Jedini spori kveri jeste qryPrimljenoProdanoUkupno, koji se koristi za Dnevni izvestaj. Razlog su subkveriji za izracunavanje sume do tekuceg datuma. Tu nazalost nema pomoci bez dodatnog komplikovanja, pa predlazem da istrpis otvaranje reporta od 10-15 sekundi (kod mene je 5 sekundi). Ko nema potrebu za ovakvimmdnevnim izvestajem, nece imati ni ovaj problem. Ako bi prikazali samo trenutno stanje, bez kolona 'Prenos od juce' sve bi bilo mnogo brze.

Mozemo li ovim da smatramo temu 'Maloprodaja robe' zavrsenom?

:-)

To je to! :)

Hvala na pomoci!

I mislio sam da bi takva relacija mogla upaliti, no bolje pitati majstora. :)

Tako nesto slicno si objasnjavao jednom prije kad smo gledali koji sve modeli ulaza i izlaza postoje.

Uglavnom, bitno je da je to to!

Sad cu si ja malo promijeniti neke forme i dodati reporte, pa kad to bude kako spada ostavit cu to tu na forumu.

Sto se mene tice nebi vise duljio s ovom temom (ovaj put za ozbiljno). :)

Ako ima zelje i volje mozemo se prebaciti na caffe, pa nadograditi ovu bazu.

Jos jednom zahvaljujem na pomoci!

Zahvaljujem svima na pomoci i sugestijama i naravno na strpljenju. Sacekacemo da Vmotic jos malo preuredi aplikaciju i zakljucati ovu temu.

Primetite kako smo krenuli od magacina, koji ima verovatno najjednostavniji model podataka, pa smo to nadogradili da radi za maloprodaju. Primer maloprodaje je bio kafic a ne trgovacka radnja, no to ne menja stvari u principu. Evo kratak opis evolucije modela:

Model magacina:
- pokazana veza izmeddju robe, ulaznih i izlaznih dokumenta
- pravilo biznisa: ne moze se izdati vise nego sto ima na lageru
- dokumenti i pregledi: cuvanje podataka o ulaznim i izlaznim dokumentima, kartice robe, pregled stanja u svakom momentu

Model maloprodaje:
- sve isto kao magacin, plus:
- cena artikla se pamti na ulazu i na izlazu
- vrsi se kalkulacija na ulazu
- cuvaju se podaci o troskovima koji nisu kupovina robe
- dokumenti i pregledi: kao magacin, plus kartica dobavljaca, plus isplate dobavljacima
Napomena: dnevni izvestaj (koji se sporo otvara) cini mi se da je specifican za kafic/restoran, ne izfgleda mi da se mnogo koristi u maloprodaji

Model kafica (u pripremi):
- sve isto kao maloprodaja plus upravljanje mesavinama (ima vise komponenti koje treba prikazati na izvestajima o ulazu/izlazu) i nehomogena roba (roba koja se pojavljuje iskljucivo na ulazu ili iskljucivo na izlazu (spricer se ne moze pojaviti na ulazu, secer i brasno se ne pojavljuju na izlazu, ali se placinke pojave na izlazu a ne mogu na ulazu)

Ovo moze da zadovolji i Object Oriented ekipu, kao klasa 'magacin' je evoluirala u klasu 'maloprodaja' a ova ce evoluirati u klasu 'restoran'. Barem na logickom nivou.

Ako dakle uspemo da napravimo nesto upotrebljivo za kafic/restoran, onda smo pokrili celu jednu veliku oblast sa mnogo mogucih konkretnih primena.

:-)

Posto se mene ceka ja cu priloziti trenutnu bazu koju imam.

No, ta baza jos ne izgleda onako kako bi ja zelio.

A kako bi to moje razvijanje moglo potrajati predlazem da se krene na restoran sa ovom verzijom pa cu ja u nju dodavati promjene koje cete predlagati na forumu.

Tako da me ne cekate, jer imam ja tu sto jos raditi.

Pa ako ste za nastavimo ovo u temi cafic, moze?


P.S. dodao sam jos samo jednu tabelu koja mi je trebala za jedan izvjestaj i isprobao sam bazu simulirajuci 10 dana poslovanja iz svojih poslovnih knjiga i za sad mi daje identicne podatke koje i imam u svojem knjigovodstvu (zato je baza malo veca sada).

_{[Ovu poruku je menjao vmatoic dana 20.12.2005. u 14:57 GMT+1]}

Ok, ovo bi trebalo da bude zavrsna poruka.

Pregledao sam fajl Cafe06_Z koji je zakacio Vmaotic. Ispravio sam neke sitnice koje bi malo smetale u radu:

- frmProdajaAdd - nije mogla da se unese nova prodaja, ako se priohvati default datum. Razlog: na glavnoj formi se ne menjanista, pa se niakda ne dodeli Autonumber, pa ne mozemo da ga prenesemo u subformu, itd itd. Resenje: premestio sam dodeljivanje dafault vrednosti polju datum u kod, na OnCurrent event.

- forme GlavnaProdaja i GlavnaUplata, posle unosa novih nisu se osvezavale, pa sam stavio Recalc u OnActivate. Sada, kad unesete nesto nov i vratite se nazad na glavnu formu, novi unos se vidi na dnu datasheeta.

- dodo dugme na formi Dobavljaci, za otvaranje reporta Kartica Dobavljaca za tekuceg dobavljaca. postojece dugme otvara report za SVE dobavljace odjednom

- promenio neka polja u tabelama na Required='yes'

Sad mi se cini da sve radi. Neka ovo dakle bude zavrsni primer za maloprodaju i ujedno i pocetni primer za temu Kafic kojoj se sada vracamo.