Dodatak temi:

Firma radi i veleprodaju i maloprodaju. Znači VP magacin bi vodila po nabavnim cijenama (odbije rabat ako ga ima i ulazni PDV i cijena koja ostane je "gola" nabavna cijena. Na tu cijenu bi kasnije trebalo dodati marzu, rabat ako ga ima i naravno PDV. Ovo je veleprodaja (firme - pravne osobe).

Sada kada dođe neka mušterija i hoće da kupi neki artikl za pare u maloprodaji trebao bi moći prebaciti taj artikl sa VP magacina na MP magacin i izdati racun gdje se naravno dodaje marza, rabat ako ga ima i PDV.

MP magacin bi uvijek bio nula (0) tj. Na njemu ne bi bilo robe i on bi služio kao tranzit robe iz VP magacina do kupca (fizičke osobe). U ovoj varijanti moramo imati registar blagajnu i istaknute VP i MP cijene na artiklima. To je zakon predvidio tako.

Posto ovo nije cista veleprodaja, nego kombinacija veleprodaje i maloprodaje, probacemo da vidimo na sta ce da izadje.

Kao i obicno, ne postavljamo i ne obecavamo rok niti kolko daleko cemo otici sa projektom. Zasigurno analiza procesa, logicki dizajn baze, i verovatno plan aplikacije (dijagram formi i reporta). I verovatno kalkulacija, koja ce se u nekim drugim slucajevima razlikovati. Ostalo, kako ispadne.

Možda će i ovo da pomogne. http://www.icentar.com/showthread.php?t=1361.

Nešto sam malo čitao o ovome i ne kužim baš najbolje. Zašto stalno trpaju kupce i dobavljače u jednu tabelu? U čemu je fora?

Zar nije bolje da imaju svako svoju zasebnu tabelu!?

Nekoliko pitanja za pocetak:
1) Sta firma prodaje? Sta firma radi, onako opisno, ne knjigovodstveno.
2) Da li ponekad firma kupuje komponente pa ih sklapa u neke proizvode koje zatim prodaje?

Bavi se prodajom kompjuterskih komponenti. Nabavljaju se pojedninacne komponente koje se prodaju solo i sklopljene kao konfiguracije.

To sa konfiguracijama malo komplikuje stvar. Kad prodas kompletan PC, kako se to knjizi? VP magacin ce se razduziti sa svim komponentama, a cime se zaduzuje MP magacin? Da li se racun izdaje sa jednom stavkom 'PC' ili se listaju sve komponente?

Listaju se sve komponente. Izlazni racun se formira po komponentama. Nabavljam komponente prodajem komponente.

Evo samo nekoliko slicica. Proces je na nekom kao poludetaljnom nivou, a daat modeli su razlicitog nivoa detaljnosti. nijedan nije takav da se samo uzme i pretvori u fizicke tabele. Fele polje svuda, ali glavna ideja se vidi. Naravno da je mnogo pozajmljeno iz tema Magacun, maloprodaja i kafic.

Upit je baziran na tome da li su ove tablice dostatne da se uradi konketna stvar (naravno polja bi dodao kasnije - informacije o dobavljačima, kupcima, detaljima, itd.) da stvar radi.

Da li su tablice dovoljne ili ne, to moras sam da zakljucis. Zasto? Ti najbolje znas sve o svom poslu. Svi prilozeni modeli mogu da odrade neki deo posla. Pogledaj tablice i razmisljaj. Nisam rekao razmisli, rekao sam razmisljaj, sto je trajna radnja i ne moze se obaviti iz jednog pokusaja. I samo ti mozes da je uradis, niko drugi.



_{[Ovu poruku je menjao Zidar dana 09.03.2006. u 21:45 GMT+1]}

Dragane, molim te da das komentar na dijagram procesa. da li dijagram odslikava ono sta se desava u tvojoj radni i oko ne. Ako ne, sta je suvisno? Sta nedostaje?

Pazi, treba nam slika stvarnog stanja, ne kako bi to trebalo da bude. Uoci da nigde na dijagramu procesa se ne spominju racunari nirti baza podataka. Nacrtane su samo aktivnosti i dokumanti koji se pojavljuju. Uradjeno je na osnovu tvoje price na pocetku i mog nekakvog iskustva sa prethodnih projekata. Ne evrujem da je dobro ispalo bas iz prvog pokusaja.

Treba nam jos jedna stvar. U cemu se razlikuje proces kad robu prodas na veliko i kad robu prodas na malo? Da li zaista postojie dva magacina, jedan za veleprodaju i ejdna za maloprodaju ili je zduzivanje MP magacina samo knjigovodstvena fraza? Da li se zaista pojavljuju Otpremnice i Projemnice izmedju ta dva magacina, ili se sve samo desava u nekom knjigovodstvenom svetu?

Nema dijagranma ili si ga zaboravio zakačiti ili sam ja nešto propustio

OOPs, izvinjavam se. Hvala Kiro :-)

Razlika u prodaji između veleprodaje i maloprodaje:


Vodim skladište veleprodaje po nabavnim cijenama i prilikom izdavanja računa moram uračunati maržu i onda porez (pdv) a u slučaju maloprodaje moram izdati otpremnicu da bi prebacio robu iz veleprodajnog skladišta u maloprodajno skladište (otpremnicu mogu izdavati za svaki artikl posebno ili zbirno na kraju mjeseca za sve artikle što je bolje rješenje). Imam mogućnost da dodam i maloprodajnu maržu ali ne smijem dva puta oporezivati. Za sada su iste cijene u veleprodaji i maloprodaji.

Zaboravio sam dopisati da su i Knjiga ulaznih faktura (KUF) i Knjiga izlaznih faktura (KIF) u procesu koje odrađujem. Odakle da uzimam podatke za njih?

Mislim da bi te podatke trebao uzeti iz dvije tabele koje se nalaze na dijagramima koje je Zidar spremio. To su tabela KalkulacijaDetalji u koje se unosi ulaz i racuni koji se izdaju kupcima.

Što misli Zidar o ovome?

ZIdar je malo zauzet na poslu ovih dana, p ce se redje javljati tokom sledece nedelje :-)

Zvonko je u pravu - Knjige ulaznih faktura slede iz tabela gde se cuvaju podaci o ulazu = DetaljiKalkulacije. Izlazne fakture su valjda racuni koje pravimo akd prodamo robu. I to imamo.

Sve mi ovo izgleda da ce biti u osnovi isto kao maloprodaja, samo ce se razlikovati racni za VP i MP?

OK, Zidar ima malo vise vremena nego u poslednjih nekoliko nedelja. :-)

Da li nastavljamo ili stajemo?

Ako nastavljamo, da vidimo koji model cemo usvojiti. Broj 4 mozda?

Pozdrav svima, novi sam na ovom forumu, malo sam Vas pratio pa bih se uključio ako nemate ništa protiv.

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.

_{[Ovu poruku je menjao Dragan Tomić dana 06.04.2006. u 14:29 GMT+1]}

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

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.


_{[Ovu poruku je menjao Kiro dana 10.04.2006. u 22:32 GMT+1]}

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.

_{[Ovu poruku je menjao mkaras dana 11.04.2006. u 09:25 GMT+1]}

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?



_{[Ovu poruku je menjao Dragan Tomić dana 29.04.2006. u 01:48 GMT+1]}

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

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.

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

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!

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

Moram da napomenem, mada nisam 100% siguran, da prema propisima vazi jedna otpremnica = jedna faktura. Tako da ne bi trebalo da se zakomplikuje resenje sa vise otpremnica u jednoj fakturi.