Maloprodaja Robe

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.