Tezak Problem za mene

Imam Dvije tabele: u tabeli PrijemnicaDetalji su mi kolone PrijemnicaID, RobaID, Kolicina, Cijena
u tabeli OtpremnicaDetalji su kolone OtpremnicaID, RobaID, Kolicina. Treba mi forma za otpremnice na kojoj cu isto imati cijenu ali ako je u pitanju Materijal onda je cijena izlaza ista kao cijena ulaza tj. kao cijena iz tabele PrijemnicaDetalji. Ako je u pitanju Inventar onda je cijena izlaza duplo manja nego cijena ulaza. Materijal i inventar mi se nalaze u tabeli Roba u kojoj imam kolone RobaID, Naziv, Inventar (yes, no), JedinicaMjere. Imam jos tabela ali mislim da su za ovaj problem nebitne

Posto nemam cijenu u otpremnicama hocu da je imam na formi za otpremnice.

Ako ste me shvatili sta mi treba molim vas da mi pomognete.

Nasla sam resenje tako da mi ovaj put nije potrebna pomoc.

Mozda jeste rijeseno ali ja vidim da ovdje nedostaje bar jedno polje a mozda i jos jedna tabela.
To cu pokusati objasniti na primjeru.
Ulaz:
datumUl robaId Kolicina Cijena
01.01.2005 1 20 100
03.03.2005 1 60 102
07.03.2005 1 12 101



evo sad ako su ovo cijene i kolicine ulaza sad da vidimo kako ce izgledati cijena izlaza.
Ako pravimo izlaz izmedju datuma 01.01.2005 i 03.03.2005 kolicine 10 cijena je naravno 100 ali ako pravimo izla 04.03.2005 koju cijenu cemo sad uzeti.
Mozda ce neki reci uzet cu zadnju cijeniu bez nivelacije i rijeseno.
I to moze ali kako je vaditi i ulaza pogotovo ako cijene idu gore dole jeli to najvisa cijena ili zadnja to je sve pitanje.

Ako neko bude zainteresovan moze i cvise pojasnjenja.

Potpis

zxz

Hvala Izonoc na ponudi ;-)

Mene interesuje, cela prica o izracunavanju izlazne cene kada se ulazna menja stalno. Ja sam uvek pretpostavljao da se prodajna cena (to je izlaz?) uvek nekako 'zna'. Onda su mi objasnili da se prodajna cena menja kada se roba primi, te se uradi kalkulacija. Onda smo negde uradili primer sa verujem najjednostavnijim nacinom kalkulacije i promene prodajne cene.

Kako se to zaista u praksi radi? Ako ima vise nacina, kako se odabira koji nacin primeniti? Je li nacin izracunavanja zakonom propisan ili je stvar izbora? I naravno, kako se racuna koji nacin, mada verujem da je to jednostavno u odnosu na problem izbora nacina.

Cim Izonic pocne da pise odgovor, tema ide u TOP.

:-)

Poslovna jedinica se zaduzuje na sledece nacine:

1.- Po nabavnoj ceni

2.- Po maloprodajnoj ceni

3.- Po veleprodajnoj ceni


Ukoliko se menja nabavna cena robe onda imamo sledecu situaciju kada se

magacun razduzuje sa robom:

1.- Radi se po FIFO metodi (prvi unutra - prvi napolje). Znaci roba se

prodaje po jednoj ceni sve dok je ima, a kada se potrosi prva tura prodaje

se po ceni druge ture i tako redom

2.- Radi se po LIFO metodi (zadnji unutra - prvi napolje)

3.- Radi se po prosecnoj nabavnoj vrednosti

4.- a moze i po planskoj nabavnoj vrednosti


Znaci zavisi samo od nas kako se odlucimo da vodimo pojedini magacin. Samo

moramo biti dosledni u radu.

Prodajna cena se formira onako kako zelimo. Niko nam ne brani da svaki put

kada se poveca nabavna vrednost robe mi povecamo prodajnu vrednost robe, na

nama je kako cemo to uraditi. Bitno je samo uraditi nivelaciju. Moze i

pozitivna ali i negativna ( smanjujemo cenu).


Magacini vezani za trgovinu vode se razlicito od magacina vezanih za

proizvodnju.


Bitno je samo da mi kao firma donesemo odluku o nacinu vodjenja cena u

pojedinom magacinu (poslovnoj jedinici) i da se toga pridrzavamo.

Evo ja cu to pokusati da objasnim u stvari da opisem kako ja to radim.
Ako se radi o nekoj robi bila to kasa magacin ili nesto trece i ako imamo ulaz i izlaz robe trebaju nam tri tabele i u sve tri tabele cijena robe.

Prva tabela je tabela artikala koja pored naziva artikla treba da ima izlaznu cijenu a ponekad i ulaznu kao i broj zadnje kalkulacije i naravno ostalo da ne nabrajam.
Cemu nam sluzi ova cijena?
Ova cijena nam sluzi kao cjenovnik artikala i ona je trenutna i promjenjljiva.
Ove cijene cemo jos korisiti i pri ulazu i izlazu robe ali o tome cemo kasnije.

Tabela ulaza robe?
Tabela ulaza robe pored sifre artikla mora imati i cijenu kao i kolicinu ulaza, ostala polja opet necu nabrajati.
Zasto nam treba cijena ulaza?
Cijena ulaza za jedan te isti artikal nije svaki puta ista i nju treba pribiljeziti i na osnovu ulazne cijene troskova i poreza pravi se kalkulacija i dobija se izlazna cijena.
Da bi imali stanje ulaza znaci moramo imati ovu cijenu bez obzira na onu u tabeli artikala.
Obicno se napravi da se pri ulazu robe (ako imamo ulaznu cijenu u artiklima) ona i upise u cijenu artikla (ponudjena) odnosno da onaj koji radi i vidi predhodnu ulaznu cijenu tog artikla. Naravno da trebamo napraviti da se ta cijena ponovo zapise u tabelu artikala ako se promijeni.
Ako je na ulazu robe uradjena kalkulacija sto bi trebalo ovdje dobijamo i izlaznu cijenu ali je upisujemo u tabelu arikala. Ovdje nije potrebna jer je mozemo uvijek dobiti racunskim putem.
Ovdje se postavlja i nivelacija cijena ali bi sad otisli daleko.
Sada kada pogledamo cijene ulaza za jedan artikal one su razlicite kao i kolicine.


Idemo sad na tabelu izlaza:
Tabela izlaza treba da sadrzi naj manje sifru artikla izlaznu cijenu i kolicinu.
E sad izlaznu cijenu prepisujemo iz artikala i ovdje onaj koji radi na kasi ili ne znam gde izdaje robu ne moze upisivati cijene robe nego samo kolicine.
Druga stvar ako je to kasa to daleko uproscava pravljenje racuna nego da sami ukucavamo cijene, taman kad bi ih i znali.

To je u kratkim crtama tako.

Ima ovdje jos jedna stvar a to je da je da se tabela ulaza i izlaza satave u jednu sa opcijskim poljem koje doznacava dali se radi o ulazu ili izlazu.
Dodatna polja koja sadrzi ulaz robe a nema ih izlaz robe prenesu se u novu tabelu napr. UlazDetalji i vezuje se 1-1 na ovu tabelu.
Ovo je dosta prakticnije i lakse dobiti stanje nego kada se radi o jednoj tabeli.
Nisam to smio a pocetku tako bojeci se da ne bude nejasno.

Ja sam jos jedanput pokusao da se umijesam samo iz razloga da pomognem ali eto objasnili ste mi da vi radite prost programcic.

Prost program ne moze biti prost za programera nego treba da bude prost za korisnika.
Nema prostog programa za programera a da radi.
Toliko za sad

Potpis

zxz

izonic:




U tabeli artikala ne bi trebalo da bude cena robe. Vise poslovnih jedinica

nabavljaju robu i formiraju cenu svaka za sebe. Znaci svaka poslovna

jedinica ima svoj cenovnik robe. Primer je prodavnica koja je nova u kraju

i zelimo da razradimo posao tako sto cemo musterije privuci cenom koja ce

biti nesto niza nego u ostalim nasim prodavnicama. Mozemo da je nazovemo

diskont ili kako kod vec hoces ali cene u njoj se razlikuju od cena u

ostalim prodavnicama. Kako taj cenovnik smestiti u tabelu artikala? Svaka

poslovna jedinica ima svoj cenovnik formiran na osnovu kalkulacije prodajne

cene za taj objekat. U tabeli artikala treba da budu samo nepromenljive

osobine artikla.


Ovo se nadovezuje da ne trebamo da cuvamo poslednji broj kalkulacije u

artiklima iz dva razloga. Jedan je da ne mozemo da odredimo koji objekat

ima prvenstvo prilikom upisa broja kalkulacije i drugi je taj da je broj

poslednje kalkulacije lako naci upitom u tabelu gde smestamo podatke o

kalkulacijama. Da dopunim nesto o broju kalkulacije. Taj broj moze biti

jedinstven na nivou cele firme ali i ne mora. Ako imamo vise odvojenih

objekata svaki od njih moze da numerise kalkulacije za sebe samo doda neki

prefiks ili sufiks koji ga jednoznacno odredjuje.


Primer:

imamo MPKL/123456 ali i VPKL/123456

i koji broj ima prioritet kod upisa u tvoju tabelu artikala?




Ni tabele ulaza ni tabele izlaza nemaju svrhu svog postojanja. Samo

dupliraju podatke koji se cuvaju. Ulaz i izlaz se rade preko dokumenata

koji su predvidjeni za to. Postim upitom u bazu dobija se stanje ulaza i

stanje izlaza robe. I to uvek tacno stanje jer se pri svakom upitu nanovo

racuna.


A sto se tice programa dobar program je uvek jednostavan i za korisnika i

za programera koji ga pise i odrzava. Bitno je samo dobro odraditi postavku

baze podataka i logiku aplikacije. Nikada ne treba cuvati i obradjivati

nepotrebne stvari, samo dokumenta, koja su u osnovi jednostavna. Sve ostalo

se dobija raznoraznim upitima u bazu podataka

Samo da napomenem da svaka poslovna jedinica moze imati svoju kodnu tabeleu.
Inace kad se radi neki veci program kodne tabele se mogu svakako odvojiti u drugu bazu.
Zadnja kalkulacija nam treba jer ona mora da bude na krtici artikala naravno ako program ima tu mogucnost da stampa kartice artikala.
To sam radio tako.
Ja bi samo da pitam odakle da povucem cijenu ako je ne stavim u tabelu artukala pri izlazu robe i koja bi to cijena bila ako imamo jednu od maja a drugu od aprila napr.
Ja sam opisao moj nacin rada pa bi volio da znam i ovaj drugi nacin.
Mislim da bi bilo dobro da se to detaljno opise.

Potpis

zxz

izonic :



Sifarnici moraju da budu istovetni u jednoj firmi jer ipak se u nekom

momentu sva ta dokumenta objedinjuju u direkciji. Velike bi zabune bilo da

svako odredjuje pojedine sifre kako mu odgovara. Ovo vazi samo ako sam ja

dobro shvatio da su kodne tabele isto sto i sifarnici.

Samo nivelacija i kalkulacija prodajne cene menjaju prodajnu cenu artikla.

Uvek uzimas podatak o ceni koja se nalazi u dokumentu koji je najsveziji po

datumu. To je lako naci u upitu.

Mozes cak i da napravis tblLager koji ce ti za svaku poslovnu jedinicu

cuvati kolicinu, rezervisanu kolicinu i prodajnu cenu pojedinog artikla.

Da bih uvek imao pravo stanje, umesto tblLager, ja pravim pogled qryLager u

kome se to automatski odrzava.

Cudna je stvar, trazio sam od tebe da opises tvoj nacin rada ali nisi to uradio, umjesto toga negiras nacin koji sam ja uradio ne upustajuci se u problematiku.
Nebih ovo ni postavio da zidar nije trezio, druga stvar opisao sam nesto sto radi i ovo nije nikakva teorija.
Siffarnici su naravno isti firme koje rade sa velikim brojem artikala nikako i ne rade sa autonumber poljem nego sa bar kodom i sa sifama koje imaju tasno odredjen broj cifri kao i sa grupama i podgrupama artikala, koe nam kazu dosta toga da ne opisujem.

Necu da negiram tvoj nacin, koji si opisao ali kazes da uzimas cijenu koja je najvazniji o datumu, a ne kazes dali tu iskalkulisanu cijenu uopste zapisujes i gdje ili je dobijas racunskim putem.

Ima tu jos puno stvari ali kad b ti opisao tvoj ompletan postupak onda bi se moglo razgovarati o tome.
Izlaz dali to bila kasa ili nesto drugo treba sto vise rasteretiti.
Ako budemo trazili na izlazu (ili kako ti kazes posaljes upit) zadnju kalklaciju te novoformiranu cijenu te stanje tog artikla itd.. sto nam treba da vidimo u izlazu onda je upitno koliko ce to brzo raditi a tu nam je najpotrebnija brzina i efikasnost i na kraju krajeva tu imamo i najvise upisa u bazu.

Potpis

zxz

Ako nekoga zanima samo da kazem kako sam rijesila problem. Za recimo jednu istu robu (npr. Ventil) ako se nabavlja od razlicitih dobavljaca i ako su cijene razlicite otvaraju se razlicite KARTICE ROBE, pa sam kolonu Cijena vratila u tabelu Roba a u tabeli PrijemnicaDetalji i OtpremnicaDetalji nemam vise kolnu CIJENA.
Cijenu na formi Prijemnica i Otpremnica sam dobila zahvaljujuci upitu:

SELECT RobaID, Cijena
FROM Roba
WHERE Inventar = no
UNION
SELECT RobaID, Cijena/2 AS Cijena
FROM Roba
WHERE Inventar = yes

To vec spada u domen izrade projekta aplikacije. Ovo o cemu sam pisao je

samo princip rada kod odredjivanja sta se gde cuva od podataka. I to nije

samo teorija vec je praksa uveliko. Moram te podsetiti da je osnovno

pravilo kod izrade baza podataka da se nigde ali bas nigde ne cuva ono sto

moze biti izracunato u realnom vremenu.



Podseticu te da sam napisao da su kalkulacija i nivelacija dokumenti koji

odredjuju cenu proizvoda, pa je logicno da tamo i treba da budu sacuvanai a

da se upitom uzima cena koja je najsvezija po datumu za formiranje lagera.



Tu se potpuno slazemo da je potrebna brzina pri radu sa kasom. Ali ako imas

kasu koja jedna i povezana direktno na bazu onda se da pretpostaviti da je

i promet na toj kasi relativno mali. Racunari su dovoljno brzi da mogu da

sazvacu kompletnu obradu, sve se svodi na upit koji vraca samo jedan

podatak i to je uvek dovoljno brzo. Cim je broj kasa veci ili se

postavljaju i drugi zahtevi onda se kasa i ne povezuje sinhrono na glavnu

bazu pa ni na glavni racunar. Sve podatci, a to su uglavnom cenovnik i

izdati racuni , cuvaju se u samoj kasi i tek na zahtev salju se serveru

baze podataka.

Program pisan na ovaj nacin radi u praksi. Do sada nisam imao nekih

primedbi. Najveca firma koja radi na ovaj nacin ima nekih 40 000 artikala

sedam veoma posecenih i dislociranih poslovnih celina veleprodaje i svaki

od tih centara opsluzuje dosta maloprodajnih objekata sto svojih , sto

komotenata. Aplikacija je pisana u Accessu ali je server baze SQL Server

2000. Svi VP objekti su sinhrono povezani na glavnu bazu preko ADSL i

jedino sto je morao da se napravi kompromis kod formiranja lagera. U toku

noci, pre pocetka rada napravi se tabela tblLager koja sluzi kao polaz i

onda se upitima dodaju i pridruzuju dokumenti koji su u toku dana izazvali

promenu kolicine i cene robe. To je sve sto se tice principa rada.


@Izonic:

Nadam se da ti je malo vise pomoglo u razumevanju prethodnih postova.

Pozdrav

Zidar samo pokusava da nauci nesto o knjigovodstvu. Zato sam zahvalan svima, Izonic, Mkaras, Kiro, Vmaotic, Dragan Tomic, DrakiMpek. Izvinjavam sa ako sam nekoga ispustio iz liste. Da bi se napravio dobar knjigovodstveni program, moraju se znati tri stvari 1) knjigovodstvo 2) dizajn baza podataka 3) programiranje. Ovde dodju ljusdi na forum sa pitanjima, i mi pretpostavimo da je problem i resenje u domenu programiranja. Medjutim, mnogo cesce problem je u nepoznavanju knjigovodstva, zatiim u nepoznavanju modeliranja podataka, i tek na kraju, jedan zaista mali procenat otpada na samo programiranje.

Sta ja pokusavam jeste da sam shvatim proces, nastajanje i zivot kljucnih dokumanata i kako se to vezuje za osnovnu delatnost forme - prodaju ili proizvodnju necega. Tu se naravno umesaju zakoni i praksa od vremena pre kompjutera, pa se sve dodatno zamagli. Traze se nepotrebne nebuloze. na primer, suma na dnu stranice i prenos na sledecu stranicu ima puno smisla ako se radi rucni upis i obracun kalkulatorom. Ako se radi racunarom, kroz bazu podataka, to je sasvim nepotrebno. Ili, fiktivno zaduzivanje i razduzivanje magacina maloprodaje koji ne postoji, pa se ulaz odmah pretvara u izlaz i stanje je stalno nula. Postoji verovatno jednostavniji nacin da se prikaze koliko je robe prodato po VP ceni a koliko po MP ceni. Ako se roba seli sa jednog mesta na drugo pre prodaje, to je druga stvar.

Bi bih licno jako zadovoljan ako iz cele ove price proizidju neki stavovi koji ce pomoci svima da razumeju sta se desava. Na primer:

Ulazni dokument => Kalkulacija => (nova prodajna cena, suma za platiti poreza na ulazu)
Stanje= (SUM(Ulaz) - SUM(Izlaz) ) <=> racuna se u svakom momentu, nema potrebe da se pamti u nekoj tabeli
Trenutna prodajna cena = pamti se u tabeli tblArtikli.
Ulazne cene - pamte se sve, a koriste se za izracunavanje nove prodajne cene, ne neki usvojeni nacin

Ako imamo sistem koji prati vise radnji, tacno je da svaka moze da ima svoj cenovnik. Nekako mi je samo malo verovatno da ce se takav sistem raditi u Accessu. Ako svaka radnja ima svoj lokalni program i lokalnu bazu podataka, onda je to opet jedna radnja za sebe. Kako se sad to sve salje u direkciju i tamo odrzava jedna centralna baza, to je potpuno drugo, mnogo slozenije pitanje koje absolutno ne mozemo na forumu Access da resavamo.

Kako je dobro ocenio Zonic, mi ovde pravimo programcice, sa ciljem da se objasne neki principi a ne aplikacije koje bi nesto zaista i uradile za korisnika. Ja sam veoma ponosan ako to sto pravimo na forumu uopste stigne da se poredi sa stvarima koje vi profesionalno radite.

Ako razumemo knjigovodstvene principe, lako cemo razumeti i dizajn baze koji to treba da prati. A iz dobrog dizajna programska resenja slede veoma jasno i logicno. Medjutim, nerazumevanje knjigovodstvenih principa uzrokuje los dizajn baze , a to vodi losem programiranju. Onda pokusamo da los dizajn resimo sa vise programiranja, na neki slozeniji nacin....

Mislim da smo otisli na predugo i na presiroko da bi bilo konstruktivno i razumljivo.
Na preporuku sam postvio post sa minimalnim objasnjenjem rada ulaza i izlaza robe, racunajuci da ce drugi postavljati pitanja ako je nesto ispusteno.

Umjesto toga desilo se suprotno drugi su poceli objasnjavati moj postupak rada umjesto da iznesu svoj.
Naravno to nikad ne donese dobre rezultate jer nemozemo pobjeci od subjektivnosti.
Mislim da bi se rasprava otegla u beskonacnost.

po meni trebalo je da ide ako treba ekoliko ideja ili postupaka jedan za drugim sa pitanjima i odgovorima i da bi to donijelo daleko vece rezultate i pomoglo ljudima.

Potpis

zxz

izonic:



Ali samo ako su u skladu sa onim sto si ti pisao. Sto ne mozes da prihvatis

da ima i drugacijih nacina za izradu aplikacije od onoga sto si ti

zamislio?

Da si malo pazljivije citao prethodne postove shvatio bi da je izneta

kritika tvog vidjenja posla i istovremeno izneto drugo vidjenje. Normalno

je da je svako mosljenje subjektivno. Zato se valjda i zove misljenje a ne

nametnuto misljenje. Ili ti idalje mislis da nema o cemu da se diskutuje

ako si ti vec postavio i izneo svoje ideje?

Neznam na osnovu cega si ti to zakljucio.

Problem je u tome sto ja ne vidim tvoj nacin rada nego samo opovrgavnje moga nacina ili kako ja razumijem da je neispravan.

Ja sam opisao moje tabele i kad je u pitanju cijena robe gdje se koja nalazi i cemu sluzi jer upocetku ovog posta je i bilo takvo pitanje.

[quite]Ni tabele ulaza ni tabele izlaza nemaju svrhu svog postojanja. Samo
dupliraju podatke koji se cuvaju[/quite]

Htio sam ti odgovoriti na ovo ali ne znam gdje ti smijestas svoje podatke ako ova niti jedna tabela netreba i koja se polja nalaze u toj tabeli.

Isto tako se desilo i sa cijenom u kodnoj tabeli koju opovrgavas i kazes da pravis upit ali gdje su podaci i gdje je iskalkulisana cijena to ja ne znam.

Zbog toga sam rekao da se rasprava moze voditi u nedogled a nemam namjeru ucstvovati u njoj.

Potpis

zxz

Zidar:



Niko ne obavezuje da se moraju imati oba magacina. Sva roba moze direktno

ulaziti i u MP magacin bez posrednih magacina, a cak moze i direktno u

prodajni objekat. VP magacin se uvodi zbog prodaje robe pravnim licima po

ceni koja se razlikuje od cene robe za fizicka lica, pa se na taj nacin

razdvaja roba. Inace ako je cena ista onda se i pravnim licima moze

prodavati iz MP magacina ili cak i iz radnje direktno. PDV se placa uvek

tako da je sasvim svejedno odakle roba izlazi. Jedino se fizickom licu roba

ne moze prodati iz VP magacina vec samo iz MP objekata.

izonic:



Sa tobom je veoma tesko diskutovati o necemu sto se razlikuje od tvog

misljenja. Jednostavno ne zelis da se upoznas sa tudjim misljenjem da bi

mogao da diskutujes. Ili ti to bas i ne ide od ruke?



Koliko znam pravila ovog foruma su da se ne daje celovito resenje vec samo

princip resavanja. Normalno to je samo moje vidjenje problema o kome je

trebalo diskutovati konstruktivno



Moras pazljivije procitati prethodne postove, u njima sve lepo pise.



Moras pazljivije procitati prethodne postove, u njima sve lepo pise.



Potpuno se slazem sa tobom da takvu diskusiju nema svrhe voditi. Do sada

nisi ni diskutovao o problemu osim sto si se zalio da nista ne razumes.

OK, nisam mislio da se diskusija pretvori u raspravu blizu svadje. Svrha je bila da se meni objasni kako ovo funkcionise. Iz postova Mkarasa i Izonica sam naucio mnogo stvari, od obojice. Nema razloga da se dize pritisak.

Zahvaljujem obojici, sada mi treba malo vremena da svarim sve sto je napisano. Hajde da niko ne odgovara dan dva, dalje ionako ne muga da pratim ovom brzinom. kad budem u stanju d aidem dalje postavicu pitanje.

Je'l vazi?