Razduzivanje robe sa VP magacina na MP magacin

Pozdrav Zidaru i ostalima koji aktivno učestvuju u temi.

Gledao sam modele koje je Zidar spremio i nekako mi se model br. 4 čini najbolji u konkretnoj situaciji pa mi mogli krenuti s njim.

Potpis

Mate

OK, bice model 4.

Pretpostavke:
1) Postoji samo jedan fizicki magacin. = Ne postoji poseban magacin za veleprodaju i poseban za maloprodaju.
2) kada se roba proda kupcu u maloprodaji, onda:
- kupac odmah placa robu (kao u samousluzi)
- nije obavezno da cuvamo ime, prezime, adresu itd o kupcu (MP kupac je bezimen)
- zakon trazi da se maloprodaja zavede kao ulaz/izlaz iz magacina maloprodaje

3) Kad se roba proda kupcu kao veleprodaja
- kupac ne mora odmah da je plati, ali moze i unapred i odmah
- o veleprodajnom kupcu imamo unapred podatke naziv firme itd (= veleprodajni kupac je pravno lice, ne fizicko)

Molim te da mi kazes koja od ovih pretpostavki jeste tacna, koja nije tacna akoja nije kompletna. ako ima jos nesto sto sam propustio, molim te da dodas.

Jos uvek smo u fazi analiziranja procesa. Doduse, vec imamo model koji podataka koji izgleda da pokriva proces. Ova faza analize je vazna za razvoj UI (user interface = forme, reporti). Moramo da znamo vise detalja pre nego se bacimo na rad. tri puta meri, jednom seci. Ako jednom meris, dva put seces, bice uvek kratko, zar ne :-)

Ovako izgleda stvarno stanje:

1) Postoji samo jedan fizički magacin za sada. Znači nema razdvajanja na magacin veleprodaje i magacin maloprodaje. E sad ja moram nekako razduziti magacin veleprodaje i prebaciti ga na magacin maloprodaje (otpremnicom) u stvarnom svijetu. E sad ne znam kako ovo treba izvesti? Otpremnica za svaki artikal ili više njih ovisno koliko se prebacuje sa veleprodaje na maloprodaju.

2) Maloprodaja:

- Kupac odmah plaća robu
- Trebao bi sačuvati ime, prezime, adresu MP kupca pošto se izdaju porezni računi preko 100 KM vrijednosti, a iznosi do 100 KM se odrađuje preko blagajničkog računa na kojem nema podataka o MP kupcu jer se tada računi izdaju preko POS pišača na ovjerenoj traci.
- ulaz/izlaz iz magacina maloprodaje treba zavesti

3) Veleprodaja:

- Kupac može na osnovu predračuna (predračun ne skida robu sa skladišta nego ako kupac plati robu onda mu se izdaje račun koji skida robu sa skladišta - može li se izvesti da se automatski predračun pretvori u račun bez da se ponovo upisuje roba?) da plati robu i odmah.
- VP kupac (ime firme, adresa, ID broj, PDV broj, žiroračun, telefon, fax, mail, web)

4) Dodatak:

- Može li se negdje ubaciti ponuda kupcu (dal se može automatski prebaciti ponuda na predračun ili račun ako kupac odluči kupiti nešto?)
- Minimalne zalihe robe

Ako treba i pet puta da mjerimo samo da ispadne kako vallja :-)

Potpis

Mate

Dana Thu, 6 Apr 2006 17:21:45 CEST, Dragan Tomi� napisa:




Moras uvek imati odvojene poslovne jedinice (organizacione celine) ako

zelis razlicite magacine. Oni mogu biti na istoj adresi ali su to dve

potpuno nezavisne celine. To se resava dokumentom za interni prenos kojim

razduzujes jedan a zaduzujes drugi magacin.

Hvala Mkaras za pojasnjenje :-)

Predlazem da u bazi cuvamo samo raucn+detalji racuna. Ako je racun izdat u maloprodaji, onda generisemo jos dva reporta - izlazni dokument koji razduzuje fiktivni VP magacin i ulani dokument koji zaduzje MP magacin. Posto je roba prodata, znaci li da treba da generisemo i jos jedan fiktivni dokument, koji razduzuje MP magacin ili je taj dokument upravo racun koji izdajemo kupcu. Drugim recima, da li je racun za MP kupca dovoljan za razduzenje magacina VP?

U svakom slucaju, ova akrobatika sa fiktivnim dokumentima nece uticati na model baze podataka - necemo dodati nikakve nove tabele jer nam ne trebaju. Sve potrebne dokumente dobicemo iz zapisa o osnopvnoj transakciji koja se zove 'prodali smo nekom nesto u maloprodaji'. Treba mi skenirana kopija pomenutih ulazno-izlaznih dokumenta, ili nesto nacrtano u Excelu, da mogu da planiram report.

Novo pitanje: u cemu se razlikuje racun za VP kupca i racun za MP kupca? Da li nam trebaju dva razlicita reporta, ili moze jedan isti, sa naznakom 'Maloprodaja' ili 'Veleprodaja' negde na racunu?

Toliko od mene za danas. Moj mladji sin danas igra hokej turnir i bicu ceo dan u areni :-)

Q:

A: Ovo trazi izmenu dijagrama procesa. tamo nigde nismo spomenuli predracun cini mi se. Znaci, za VP kupca, moze sa predracunom, a moze i bez. Ako je sa predracunom, treba napraviti da se predracun pretvori u racun.

Jedan od nacina je da dodamo tabele Predracun/PredracunDetalj i tu zapisemo sta smo ponudili i po kojoj ceni. Onda, ako kupac prihvati, sve to prepisemo u tabele Racun/Detaljiracuna. Kao, stavimo dugem na formu racunDetalj, pa kad se klikne, pojavi se dialog box sa listom predracuna za tekuceg kupca, odatle se izabere jedan iz koga ce se prepisati vrednosti. da li onda treba nekako oznaciti da je taj predracun vec upotrebljen, to jest preveden u racun, da se ne bi pojavljivao sledeci put u listi?

Postoje i drugi nacini. Na primer, uvedemo u tabelu Racuni kolunu StatusRacuna. Vreadnosti u kolone StatusRacuna mogu biti {"Predracun","Racun","Placeno"}. Ovo je oprimamljivo, ali se gubi informacija da je psotojao predracun, kad ga prevedemo u racun. Ako to nije problem, OK. Takodje, ako kupac odluci da nesto doda ili iduzme od predracuna, da li zelimo da cuvamo i tu informaciju?

Sta je bolje? Ne znam, probajte pa vidite. Meni licno se vise svidja onaj prvi nacin, sa posebnim tabelama i prepisivanjem. Da li je bolji od drugog nacina? Verovatno da nije, bar u nekim situacijama, sve je stvar procene i ukusa.

Neko bi mogao da pita 'a zasto uopste razdvajamo racune od predracuna, moze li to da ide u isti set tabela?'. Naravno da moze, ali nije za pocetnika. Oni koji to umeju da rade ne trabaju pomoc od Zidara :-) od njih Zidar nauci ponesto kad god mu se ukaze prilika.

Predracun mozemo izdati i fizickom i pravnom licu (znaci i u maloprodaji i

u veleprodaji) i on ne skida robu sa stanja vec vrsi rezervaciju robe u

vremenu vazenja predracuna. Ovo je bitno jer ne smemo prodati robu koju

nemamo na lageru.

Ako kupac uplati po predracunu predracun se preprepise u tabelu racuna,

oslobodi se rezervisana roba i predracun se brise.

Ako kupac ne uplati robu u predvidjenom periodu predracun oslobadja

rezervisanu robu i brise se.

Ne postoji potreba za njegovim cuvanjem. Cuva se iskljucivo u periodu

njegovog vazenja odnosno do uplate ili isteka roka vazenja.




Nije neki veliki problem. Samo jedno polje se dodaje u tabelu koje oznacava

vrstu dokumenta (predracun ili racun) i kod prelaska predracuna u racun

menja se broj dokumenta (obicno se razlikuju brojevi racuna i predracuna)

Hvala Mkaras, sad se osecam mnogo bolje. Znaci, predracun rezervise robu. To mu dodje kao da je roba prodata, iako jos nije (bice, bice ;-). Ako je neko rezervisao 20 monitora, a u magacinu ima fizicki 25, na raspolaganju za prodaju je samo 5, 20 mora da se cuva. To znaci da se predracun i racun se u racunanju stanja robe mogu tretirati isto. Predracun uracunavamo u izlaz, makar i ne izasla roba.

Takodje sam shvatio da kupac ima opciju ili da plati sve po predracunu, cime se predracun automatski pretvara u racun, ili da odustane, nakon cega mozemo da kompletno ubijemo predracun - fizicko brisanje iz svih tabela?

Ovo omogucuje da radimo sa statusima (vrastama) dokumenat {'predrracun', 'racun'}. Kazes da se moze promeniti broj dokumenta prilikom prelaska iz predracuna u racun . Predracun 25 moze postati racun 37 (ali i ne mora). Ako se menja, trebace nam malo analize pre izbora PK za tabelu racuni. PK nece moci da bude niti BrojRacuna, niti BrojPredracuna. A opet, BrojRacuna i BrojPredracuna morace da budu unique u tabeli, ako nisu NULL. O tom potom. Licno, ne vidim razloga da menjamo broj dokumenta. Dokument 25 ce u nekom momentu biti ili placen, ili proglasen nevazecim. U prvom slucaju ce se roba isporuciti, u drugom se ponistava rezervacija.

Ako predracunu istekne rok trajanja, roba se oslobadja. Znaci, trebace nam nesto sto svakoga dana, kad se ukljuci aplikacija kaze "na danasnji dan istice predracun broj 25, molim vas da ili 1) produzite rok vazenja ili 2) oslobodite robu ili 3) pretvorite predracun u racun". Ako je kupac platio, on placa na osnovu predracuna, racun se izdaje POSLE. Znaci u evidenciji uplata koje vrse kupci, imacemo poziv na broj racuna ili predracuna. Zato mi se ne dopada promena broja dokumenta. Pri naplati em moram da pamtim broj dokumenta, em pamtim tip dokumenta. Ako je placeno na osnovu predracuna, pa ja posle promenim predracun uracun, ispada da se u evidenciji uplate pozivamo na dokument koji vise ne postoji (predracun koji se pretvorio u racun)

Da li se desava da se roba izda, a da kupac plati kasnije? Kako se to evidentira?

Roba Naplata
-------------------------------------
Rezervisana nije placeno
Rezervisana placeno
Izdata placeno
Izdata nije placeno

Ovo mi lici na dva statusa, StatsuRobe(Rezervisana,Izdata) i StatusNaplate (Placeno, Nije placeno). Ne znaci da cemo imati zasebna polja za ovo, samo primecujem da su to opcije. Naplatu cemo verovatno da citamo iz neke tabele gde evidentiramo sta su kupci uplatili. Ako dokumanta ima tamo, znaci placen je. Ako ga nema, nije placen.

Da li dobro govorim ili lupam gluposti?

Ja bi samo nešto rekao ovo sa brisanjem predračuna mi se nikako ne sviđa, ukoliko se radi tako, a firme koje prodaju informatičke komponente kod nas uglavnom i rade tako prvo plati pa ćeš dobiti robu, znači prvo predračun pa račun. E sad ako obrišemo predračun kako ćemo znati koji je slijedeći broj nekog novog predračuna????? Ovdje i račun i predračun imaju funkciju valjanog dokumenta. Predpostavljam de će se pojavljivati razne situacije kad se pravi račun bez predračuna ili da se neki predračuni jednostavno ne realiziraju ili sl. Da se radi o mojoj firmi ja bi htio imati evidenciju svih predračuna i svih računa.
Rezervacija robe, ovo je ok ako se predračun izdaje za već ugovorenu kupo-prodaju, znači za siguran posao, a ne onako svakom ko zatraži, pa onda imamo da smo rezervisali za badava a sa druge strane propustili posao.
Iz ovog slijedi da bi nam trebao još i dokument PONUDA, koji nema veze sa izlazom rezervacijom veće se izdaje gore pomenutom "svakom".
E sad bi i od predračuna i ponude valjalo napraviti neku automatizovanu radnju koja bi napravila račun. i sad se to komplicira, zatim praksa je i svi to vole da svaki dokument ima svoj kontinuirani broj i to po datumu, da nebude veći broj računa mlađi od nekog manjeg broja itd.
Ovo je samo moje razmišljanje koje ne nudi konkreto rješenje, a vi majstori rješavajte.

Potpis

Kiro

U Hrvatskoj sada svi većinom rade PONUDE jer po njima niste obavezni platiti PDV, znači kada nekome date PREDRAČUN imate obvezu platiti PDV po tome dokumentu iako niste dali robu, kupac može da si odbije pretporez na osnovu PREDRAČUNA a na osnovu PONUDE nemože, sve to malo izgleda komplicirano zar ne!
Za Zidara, kada netko uzme robu a ne plati odmah pišete mu tada normalni račun sa odgodom plaćanja.

Zidar :



Za PK uzimamam AutoNumber polje u tabeli a brojeve dokumenata, koji moraju
da budu u kontinuitetu, cuvam u posebnoj tabeli tblNoviBroj koja sadrzi
NaredniBrojDokumenta i TipDokumenta. Prilikom svakog upisa dokumenta na
disk pokupim iz tblNoviBroj NaredniBrojDokumenta za tu vrstu dokumenta. Ako
korisnik odustane od upisa dokumenta onda i ne dodje u situaciju da
potrazuje NaredniBrojDokumenta iz tblNoviBroj. Normalno, po nekom pravilu
unapred usvojenom, pripremim i broj za sledci dokument koji cuvam u
tblNoviBroj.

PK mogu da budu u diskontinuitetu, ali brojevi dokumenta moraju da budu u
kontinuitetu i ukoliko dodje do greske u izradi, dokument se stornira i
radi se novi dokument ispravke. Neispravan dokument mora i dalje da postoji
u bazi samo ne sme da utice na stanje robe i finansija. Nema preskakanja
brojeva dokumenata, a pogotovu nema popunjavanja rupa u brojevima.

Prilikom svakog upita u stanje robe na lageru treba proveriti da li ima
predracuna kojima je vaznost istekla i ako postoje treba obaviti
oslobadjanje rezervisane kolicine robe. To ne traje dugo, a uvek smo
sigurni da imamo pravo stanje robe na lageru.

Poštovanje svima uz dobre želje za 1 maj da se odmorite što bolje.

U prilogu sam spremio primjer otpremnice sa skladišta veleprodaje u skladište maloprodaje i račun koji se izdaje u vele i maloprodaji. Mislim da bi se negdje mogla staviti naznaka dal je veleprodaja ili maloprodaja a mislim da nije neophodna iz razloga što po kupcu vidimo o čemu se radi. Što misle drugi o ovome?

Potpis

Mate

Mislim da je ovo OK. Može ova opcija Zidar?

Potpis

Mate

Zdravo svima.
Interesuje me kako sada izgleda dijagram kada je resen problem.
Da li moze da se prikaze kao "relationships" da bih lakse razumeo koji su podaci vazni i kako su tabele povezane.

Hvala.

Potpis

I have not failed. I've just found 10,000 ways that won't work. (Thomas Edison)

Evo se lakse dise, bar za koji dan, pa mozemo da se vratimo na nasu temu. ;-)

Pogledao sam sta su kazali Mkaras i Izonic, Kiro i ostali i pokusao da shvatim kako sta ide. Deo sa prodajom, prdracunima, racunima, obradicemo detaljno a deo sa kupovinom od dobavljaca prepisacemo koliko moze iz teme Kafic.

Tesko mi je da kucam u ovom prozoru, pa sam pricu strpao u word dokument koji cu uz malo srece da zakacim uz poruku.

Idemo dakle ovako:

Evo deo programa, koliko da se moze nesto uneti u bazu. Za sada samo deo o prodaji, da se unese nekoliko rekorda pa da probamo da napravimo kverije za zaduzenej razduzenje MP magacina.

Pogledajte dizajn tabela, validation rules za polja a i za tabele (tblrRcuni, tblUcesniciUPrometu)
Validation rules za tabele se dobiju u design modu, kad otvorite properties. Potrebna su kad se definise odnos izmedju dva polja. na primer:

tblKupci:
(Ako je kupac pravno lice, onda nema prezime AND Ako je kupac fizicko lice, onda MORA prezime)
ili
tblRacuni:
(RokPlacanja (datumski tip) ne moze biti pre nego DatumRacuna)

Pogledajte kako su ove rcenice prevedene u Validation rules.

Deluje naivno, ali ako se ns postave pravila, mnogo garbage podataka moze da se unese. A bolje je postaviti rulas na tabelama nego loviti moguce logicke greske unosa na formama


:-)

izgleda su svi zadovoljni

Potpis

AOtto

Pošto su završili godišnji odmori i nadam se da su se svi uspješno oporavili od prethodnih obveza zamolio bih resprektabilne osobe našeg foruma da nastave sa radom na našoj temi razduživanja robe sa VP magacina na MP magacin.

Hvala svima!

Potpis

Mate

tek sam sad vidio ovu temu pa bih htijeo da dodam kako se mora imati dva skladišta iz više razloga a jedan od njih je i da firme znaju imati različite cijene na vp i mp pa da im čak i veleprodajne cijene budu veče od maloprodajnih pa na to daju razne popuste i rabate a ako je jedno skladište fiktivno onda to treba riješiti međuskladišnicom to jest da se iz jednog skladišta prenosi samo onoliko robe koliko se proda i bilo bi dobro da se od računa može napraviti međuskladišnica i da dodam na vp mora postojati i otpremnica
pozdrav

Ja sam tek sad primetio da se Dragan javio, kao i Panonac. Izvinjavam se za zakasnjenje.

Slazem se sa svime sto je Panonac rekao. Poenta je u tome da se na svim dokumentima koje on pominje vrte jedni te siti podaci - roba koja je usla i izasla iz skladista.

Ako oznacimo fakturu/recun kao 'maloprodaja', sva roba koja je vezana za taj racun/fakturu jeste istovremeno i ulaz i izlaz iz zamisljenog magacina maloprodaje. Napravite report koji ima naslov 'Promet magacina veleprodaje' i eto vam magacina maloprodaje u knjigama. u tom magacinu stanje je uvek nula za svaku robu, sto udje to i izadje. Bitno je da podaci sede na jednom mestu - setu tabela (Fakture, StavkeFakture)

To je lako. Sta bi sadrzala otpremnica? Pa iste one stavke koje sdrzi i faktura. Znaci, napravite report 'Otpremnica', veom slican reporu 'Faktura'. Razlika je sto se valjda na otpremnici ne prikazuju cene i rabati i porezi, nego se prikazuje samo roba i kolicina. Znaci, opet oni siti podaci koje smo sacuvali jednom u paru tabela (Fakture, Stavke fakture). Naravno, pod pretpostavkom da se sva roba isporucuje odjednom. Ako se roba isporucuje iz nekoliko puta, onda naravno treba imati vise otpremnica, pa tu informaciju treba negde i sacuvati u bazi. Tu se stvari diodatno komplikuju. Morate paziti da ukupna isporucena kolicina neke fakturisane robe (zbir po svim otpremnicama za datu fakturu) ne predje placenu kolicinu. To zahteva da na front endu u Accesu proveravate kolicine koje unosite na otpremnici, da ne predju zadatu kolicinu. U 'pravim' RDBMS (Oracle, MS SQL, Firebird) to se moze psotici i na nivou tabela, ali u Accesu ne moze drugacije nego programiranjem na front endu. Kako? Na isti nacin kao sto proveravamo kolicinu na lageru pre prodaje. Ako na lageru imamo 100 necega, ne mozemo prodati 150. U temi Kafic ili cak i ovoj to smo pokazali, pa mozete videti princip.

Toliko za sada :-)