Nemam reci, VRH !

Prvo pitanje:
Sta ce se desiti sa upitom qryStanje nakon recimo 200 dana i izdatih 2580 otpremnica i 4520 prijemnica za 2100 razlizitih artikala? Upit treba da pokupi ulaze sabere ih, da pokupi izlaze saberi ih , i oduzme medjusobno, da nece to da radi malo sporo (nemojte reci da Pentium 4 moze da izvrsi 3.000.000.000 instrukcija u sekundi ... pitam cisto jer moramo znati sta ce se desiti kada se baza enormno uveca)? Sta ce se desiti posle 2-3 godine, sta ako to bude sve radilo kroz mrezu ? Da li ce nesto od ovoga da smeta ?


_{[Ovu poruku je menjao Cyberghost dana 02.09.2005. u 22:16 GMT+1]}

Zar je moguce da nema komentara?

Vikemd ap se ne radi, a u kandi se ne radi ni ponedeljak, pa se opet ne radi :-)

Ne brini za brzinu, sve ce da radi kao satic barem dve tri godine. A onda ce da naprave jos brze pentiume pa ce opet da radi dovoljno brzo. Nista ne radi brze nego kveri. Ako baza zaista poraste toliko da se sistem uspori, moguce su dve stvari 1) preci na neku pravu bazu (SQL, Oracle, MySQL), pa izvrsavati upite na database serveru i samo rezultate slati preko mreze nazad 2) deo podataka arhivirati, na primer sve stoje starije od 2 godine se izbaci u neku arhivsku tabelu, a ceo taj set rekorda ze zameni jednim rekordom po artikllu. Taj rekord je sumarni rekord i tretirace se kao novi ulaz, ili izlaz, ako je vrednost negativna (sto ne bi trebalo da se desi, ne mozete u magacinu imati minus 15 kilograma necega)

Ako si mislio na zracunavanje stanja posle svake transakcije i cuvanaj tog rezultata u nekoj tabeli, pa update svaki put, zaboravi na to, iz dva razloga. 1) Tako se neradi u relacionim bazama 2) Razlog zasto se tako ne radi je sto pre ili kasnij dodje do greske koju je prakticno nemoguce ispraviti. Kako ovo?
Pa moguce je da tvoj program koji izracunava Sanje pukne u momentu kad se stanje izracunava, a transakcije je vec unesena. Nestane struje u momentu unosa na primer. Ili neko napisao jos jednu aplikaciju, koja radi slican posao, a zaboravio da uradi update polja Stanje.
Ako i uvedes polje Stanje, bez obzira na tvoje update polja Stanje u tabeli Roba, kveriji bi trebalo da ti daju isti rezultat, pa makar radili i sporo. Neka jednom nedeljno vrtis kveri da proveris stanje i neka to traje deset minuta. Sta ako kveri izracuna drugaciji rezultat od onoga koji imas u svom polju Stanje? negde je greska, ali gde? neki uopdate nije prosao. Koji? Ko to zna. Tacno, mozes jednostavno da upises novu vrednost u polje Stanje. To samo znaci da svom polju Stanje ne mozes verovati jer ne znas da li je tacno. Mozda jeste a mozda i nije, nikada se ne zna dok ne provrtis kveri. pa zasto onda raditi dve stavri kad je jedna od njih sigurno tacna a druga tek 'mozda' tacna?

Sad, moguce je da i kveriji daju pogresan rezultat. Na primer, kveri kaze imas 10 gajbi piva u magacinu, a kad odes da izbrojis licno, ono samo sedam gajbi. Znaci da neka transakcija nije unesena, pivo je izaslo iz magacina a magacioner to nije upisao u kompjuter. Ili je pivo uslo u magacin a magacioner nije upisao u kompjuter.

Sta raditi u tom slucaju? Mozes da otpustis magacionera, ali je stanje i dalje
pogresno, znaci otpustanje nije resenje. Mozes da prihvatis da se takve greske desavaju i da upises korekciju - novu transakciju, da dodas ili oduzmes neku kolicinu da bi se stavri zbalansirale. A onda se potrudis da negde u procesu sprecis mogucnost prometa robe bez evidentiranja.

Nego, ima li ideja kako bi se baza mozda prosirila. Kako evidentirati narudzbe robe (neko mora da naruci robu povremeno )? Kako uvesti prodaju putem narudzbi - kupac naruci robu a magacin je isporuci? Moze li ova baza to da izdrzi? Sta treba uraditi (dodati, oduzeti) pa da se to omoguci?

Svaka baza mora da ima mogucnost rasta u buducnosti. Nigde nismo rekli da ce ovo biti Access baza. Ako bude MS SQL, onda aplikacije mogu da se pisu tako da rade preko interneta (opet ne koristimo Access). i sve to u isto vreme dok u magacinu lepo sljaka Access aplikacija koja omogucuje magacioneru da evidentira prijem i izdavanje robe. Moze li to nasa pretpostavljen abaza i sta bi trebalo uraditi da sve to moze?

Ok, razjasnili smo baratanje upita sa velikim brojem podataka.



Hm, ono na cemu ja trenutno radim je da se evidentiraju Prijemnice i izdaju Otpremnice i da se prati stanje na lageru, sto sa ovim modelom koji si izlozio radi odlicno, ja nastavljam da radim aplikaciju (nadam se da cu uspeti sa C# koji trenutno pokusavam da savladam) .

Ne razumem sta znaci ovo: Kako uvesti prodaju putem narudzbi - kupac naruci robu a magacin je isporuci? Jel si mislio dodje kupac i radnik napravi narudzbenicu prosledi je magacinu koji na osnovu nje izdzdaje otpremnicu ?


P.S. I dalje ne znam kako da napravim (u Access-u) da mi izracuna stanje kada se u Subformi unese IDArtikla, da ne moze da ode stanje na lageru u minus (ili makar zabraniti da vrednost polja ne moze da ide u minus i da javi da na lageru nema dovoljno robe), eksperimentisao sam svasta ali mi ne polazi za rukom.

Sto se tice narucivanja robe, moguca su dva slucaja
1) tvoja firma (vlasnik magacina) narucuje robu od dobavljaca, to ima u diagramu procesa, ali nema u modelu baze koji smo zadnji napravili. Znaci ti narucujes robu.

2) Kupci narucuju robu od tvoje firme, putem interneta, ili ti posalju narudzbenicu postom. Onda se ta narudzba od kupca prosledi nekako magacinu i magacin poslaje robu pouzecem. Znaci, od tebe narucuju robu.

Kako 'dodati' ova dva slucaja ako se u buducnosti pojavi potreba za tim?

Drugo pitanje:
Za proveru stanja prilikom unosa, bice detaljno obradjeno kasd budemo radili aplikaciju, a to je uskoro. Ako ti je bas hitno, onda pre nego sto se sacuva rekord, uradis proveru 'da li mogu od trenutnog stanja da oduzmem uneti Qty i da pri tome ne dobijem negativan broj?' Ovako nekako treba da ide proces:

1) uneses artikl (RobaID)
2) unsese kolicinu Qty
3) pokusas da se pomeris na sledeci rekord, za novi artikl
4) Access proveri da li BeforeUpdate event za formu ima nekih zahteva i ako je sve OK sacuva rekord, pa te pusti na sledeci, novi rekord. Ovo se sve desava u kratkom trentku kad pokusas da izadjes sa tekuceg rekrda i odes negde drugo.



predpostavljam da se unos RobeID,Kolicina radi na nekoj subformi. Na subformin BeforeUpdate event stavis nesto otprilike ovako (sve je pseudokod):



qryStanje je stari dobri kveri qryStanje koji racuna SUM(Ulaz)-SUM(Izlaz) AS Stanje, cak i posle 50,000 rekorda i vise

Nista novo, samo sam malo proemnio PDF dokument zakacen na prvi post ove teme. Slike su numerisane, neke gramaticke i greske u kucanju ispravljene (ne sve, naravno) i dodato/promenjeno nesto teksta na pri kraju.

Evo vracamo se osle duge pauze. Puno vremena oduzela je tema Kafic :-)

Elem, stali smo kod logickog modela. Usvojicemo negenralizovani model, onaj sa puno tabela. Za dalje cemo da pretpostavimo najjednostavniji moguci slucaj. Roba ulazi u magacin, i izlazi. I na ulazu i na izlazu brojanje je u istim jedinicama. Kompleksniji slucaj, kad je ulaz u gajbicama (piva) a izlaz u flasama (tog istog piva) resicemo u temi 'Kafic'.

Evo dakle fizickog modela baze - konkretne Access tabele i malo price o tome kako ce i zasto da izgleda aplikacija. Molim obratite paznju na neke vazne korake u dizajnu samih tabela (required fields, indeksi, deafult values i validation rules). Otvorite svaku tabelu u dizajnu i pogledajte sta je tamo. Ako sam nesto zaboravio, ili nisam pratio sopstvena pravila dosledno na svakom mestu, molim prijavite pa da ispravimo. Tako pocinje testiranje, dok radimo, a ne na kraju kad je kasno jer se vise ne moze popraviti. Ako ste u timu, nije lose da u ovoj fazi, kad ste napravili fizicku bazu, to pokazete kolegi ili testeru da pogleda. Ne bi trebalo da se sporite oko logickog dizajna, nego oko stvari tipa:
- da li su sve tabele opisane, pa kad pogledate u DB prozoru, ono pise sta koja tabela radi
- da li su sva polja dokumentovana - opisana
- da li su polja koja su required navedena kao required
- da li sva polja imaju default
- da li sva polaj imaju validation rule. Ako neka nemaju, to odgovorite tetster i kazete 'jeste, ovde je slobodan unos, i nem avalidacije; I to se onda negde zapise, da se zna za buducnost.
- da li sve tabele ucestvuju u relacijama, ne sme ni jedna da visi u vqaduhu, bez razloga
- da li su FK polja istog tipa i imena kao opdgovarajuca PK polja
- da li psotoje indeksi na svim FK poljima
- da li imate nepotrebne indekse, dva puta po istom polju

Znaci, ovo nabrojano treba tester da potrazi u vasoj bazi i da se to sve ispravi pre nego sto se nastavi.

Zkaceni fajl sadrzi back end naseg informacionog sistema 'Magacin' i PDF fajl sa pratecim tekstom, kao neki nastavak od onoga sto iamamo u prvom postu.

Evo napokon prica o dizajnu aplikacije, korak po korak, skoro gotovo.

Imam par jednostavnih pitanja: Definitivno smo usvojiki ovaj model baze (koristimo odvojeno Prijemnice i Otpremnice, a ne pomocu tabele VrstaTransakcije)? Ako je tako qryStanje sabira sve Prijemnice-Otpremnice ?
U tabelama tblPrijemnicaDetalji i tblOtpremnicaDetalji polje RobaID da li moze da se pojavi vise od jednom (pise da je Duplicate YES ako se ne varam-trebalo bi da moze) ?
I jos jednom svaka ti cast za dizajn aplikacije od sad sve sto budem radio radicu po uzoru na tvoje primere - svaka cast MAJSTORE !

Danas cu kompletno da izradim sve i dacu svoje predloge.



_{[Ovu poruku je menjao Cyberghost dana 16.09.2005. u 08:06 GMT+1]}

Pitanje 1:

Odgovor: Da, ali ne znaci da je taj model bolji. Posto je ovo samo primer, usvojio sam model koji je laksi za razumevanje. medjutim, principi dizajna aplikacije ostaju isti. Ovo je prica o dizajnu aplikacije, dozajn baze nam je samo trebao da bismi imali s cim da radimo. Poent je da kao vam neko drugi napravi model baze, vi mozete da napravite pristojnu aplikaciju i be z da znate sve detalje, ako prtite prinicpe koje pstavljamo.

Pianje 2:
Odgovor: qryStanje jos nismo napravili, znamo samo da ce nam trebati. Svakako da ce se stanje dobiti kao rzlika zbirova SVIH otpremnica i prijemnica. Bez obzir sto cemo za dve godine imati 25,000 otpremnica sa 120,000 detaljnih rekorda i otprilike isto toliko prijemnica. Za dve godine ce i kompjuteri da budu jaci, zar ne :-)

Pitanje 3:
Odgovor; Tacno tako. svaka roba se moze nalaziti n bilo kojoj priejmnici/otpremnici. Pivo moze da se primi u magacin svakog dana i da se otpremi nedge svakog dana takodje. Indeks je tu zbog brzine pretrazivanaj i brzine kverija. Da nije tog indeksa, ne bih imao bas toliko poverenja u qryStanje :-)

Preporuka: ne zurite sa izradom aplikacije, jos nismo zavrsili dizajn. Ima tu jos problema koje treba resiti, a koje mozda ne vidite u ovom momentu, pa cete se zapetljati nepotrebno. Budite strpljivi jos samo malcice...

:-)

Evo ja sam nesto kao gledao i uradio ono kako meni treba da izgleda.
Zidar ako mozes u otpremnicu koja se otvori kada se startuje baza da mi podesis da se prikazuje trenutna kolicina u magacinu ono sto me muci vec duze vreme, ja sam napravio qryStanje a ovo mi je neophodno da bih mogao da predam coveku posao vec mnogo kasnim a izradu ostatka aplikacije cemo polako.

Pozdrav, HITNO mi je !!!

Ja lepo rekoh da se ne trci sa aplikacijom, a Cyberghost ne slusa. Pa jos i ne cita sta pise na forumu, nego uporno podnosi svoj stari dizajn. Pa jos nazove forme imenima "tblPrijemnice". Jako je nezgodno kad u istom fajlu imas tabelu koja se zove tblPrijemnice, a istovremeno imas i formu koja se zove tblPrijemnice. Pa ti se fajl zove Magacin_BE a unutra i tabele i forme. Ono _BE znaci "Back end".

Evo ti resenja koje si trazio, ali preporucujem da se uzdrzis za malo od predavanja aplikacije korisniku, ima tu jos mnogo rupa kojih nisi mozda ni svestan.

Ma samo da coveku pokazem primer kako ce da radi, cekam konacan dizajn Aplikacije. Covek me pita jel radim ja uopste nesto na njegovoj bazi ?

Izmontirao sam mu nesto samo da vidi da ce biti nesto od posla.

Cekam strpljivo dalji razvoj

Evo najzad nesto konkretno. Sve dosad je bila kao neka 'teorija', sad nastupa praksa. Nemam vremena da bas svaki detalj objasnim, verujem da cete kopajuci po kodu da shvatite o cemu se radi.

Zakaceni fajl sadrzi konacnu verziju modela baze, aplikaciju i kolekciju planova aplikacije. Moduli Roba, Prijemnice i Otpremnice su uglavnom zavrseni. Nisam napravio reporte za Prijemnice i Otpremnice, to mozete sami. Cuveni kveri stanje robe je tu, kao i kartice robe. Prilozen je plan aplikacije za module Dobavljaci i Kupci, pa pokusajte sami.

Ako budem imao vremena, probacu da dodam Quer/report manager i Table Linker.

Prilozenu aplikaciju moracete rucno da linkujete na back end.

:-)

Ja sam pokusao da linkujem ali mi ne ide ne mogu da koristim nista ???

Iz zakacenog fajla extractuj dva NDB fajla. FE je front end, BE je back end. Kopiraj ih gde zelis na budu. Startuj FE. Pritisni F11 da dobijes Database window, pa idi u Tools/Datbase Utilities/Linked Table manager.....

Eto sta se desi kad se isoruci nekompletna aplikacija - fali table linker.

Evo nova verzija, table linker preuzet negde sa foruma, Banem je dao formu i kod koja to rade, ja sam samo malo prilagodio nasem primeru.

:-)

Drago mi je da vam je to od koristi. Zapravo sam ja to negde pokupio i malo prilagodio. Sjajna je procedura, jer kad instalirate Access, često se ne instalira Linked Table Manager Wizard.

Ok, proradilo i dopada mi se ali ne mogu da ispunjavam otpremnicu, glavni deo za klijenta unesem ali kada treba uneti robu ne dozvoljava !!! Ostalo sto je meni potrebno radi.

Sve pohvale Zidaru za aplikaciju!

I odgovor Cyberghostu - kod mene sve radi kako treba! I otpremnice i prijemnice.

Odradio sam sve ponovo i sve je proradilo.

P.S. Zidar, cime se bavis u Canadi i koliko dugo radis sa bazama ?

Pozdrav

Joooooooj opet problem , ponovo sam raspakovao .Zip uradio sve sto treba sa linkovanjem ... unos artikala radi, pregled radi, ali kada otvorim bilo Novu prijemnicu bilo novu otpremnicu ne mogu da unosimu Detaljima artikle evo kako izgleda slika u prilogu.

Jesi li siguran da nisi nista brljao po aplikaciji? slika koju si dao ukazuje da ti ili fali subforma, ili je preimenovana ili nesto trece ne valja. Downloadovao sam ZIP kuji je uploadovan i startovao aplikaciju - ne dobijam taj problem. probej da downloadujes ponovo.

:-)

Cackao sam samo kod dodavanja Formi za unos Klijenata i Dobavljaca, mozda sam cacnuo negde gde ne treba. Skinuo sam ponovo i radi (bez cackanja :) ).
Pitanje: Kada sad hocu da napravim Report za Otpremnicu pravim upit u Magacin_BE pa report na osnovu upita i sve to linkujem ili uvezem u Magacin_FE. Potrebno je jos samo prilikom izrade Otpremnice imati mogucnost da se odmah po izradi odstampa, jel se to radi kao sto sam rekao ili ... ?

Pogledao sam rad Zidara - i stvarno je prilično sveobuhvatan. Ipak imam par pitanja za njega (biću kratak):

Pre nego sam pogledao tvoj rad, po uzoru na Access-ov template (Inventory control) izradio sam magacin - i radi sasvim OK. Medjutim, pošto sam to radio za prijatelja (inače se slabo bavim Accessom), naknadno mi se javio sa problemom:

- Radi se o mešaoni stočne hrane. Ulaz je sirovina (prijemnice) a izlaz (otpremnice) gotovi proizvodi. E a sada zez: postoje i poluproizvodi. Sve ove tri 'kategorije' robe idu i na otpremnicu, sirovina služi za pravljenje poluproizvoda i proizvoda, a poluproizvodi za proizvode. Izmedju njih postoji razmera (koja se ponekad menja), tipa: 1 kg Proizvoda (hrana za piliće) se sastoji od x sirovina i poluproizvoda: 55% sirovine 1(kukuruz), 35% sirovine2 (sačme), 5% sirovine3 (so) i 5% poluproizvod1(smeša).
I slično je i za poluproizvode (samo sirovine).

I tu sam stao jer mi treba kontrola praktično tri povezana magacina (sirovina, poluproizvoda i proizvoda) koji svi idu na jednu otpremnicu. U prvoj varijanti ja sam odradio klasičan magacin (ulaz izlaz robe, stanje).

Osnovni problem je što sirovina treba da se skine sa stanja kada se napravi poluproizvod i proizvod, ili kad se proda preko otpremnice.

Pokusao sam da na tvoj primer primenim neke svoje zamisli, ali nije išlo. Verovatno zato što nisam baš vičan VB, jer sam do sada "probleme" rešavao Macroima.
Zato molim za pomoć...

Unapred zahvalan

Prijateljski savet je da ne radiš dalje na tome. I to iz nekoliko razloga:

- magacinsko "poslovanje" zahteva ozbiljan program - ako se na baviš Accessom aktivno, imaćeš velikih problema (već si naveo neke)
- uvek će se javiti "još nešto" što treba da uradiš
- ako "prijatelj" ima firmu, a misli ozbiljno da angažuje informatičke resurse, red bi bio da plati nekom ko će profesionalno da mu uradi program
- da li ti je prijatelj pomenuo još nešto što program mora da ima, tipa: interne otpremnice, prenos iz magacina u magacin, magacin poluproizvoda, stanje svakog od njih, ulaz, izlaz, itd? Ima još dosta stvari tu
- osim toga moraš znati zakone i pravilnike kojima se uređuje poslovanje jedne takve firme; praktično moraš znati materijalno knjigovođstvo
- kada radiš program _moraš_ znati sve parametre poslovanja i sve zahteve poslodavca. Ako on to ne da odmah, postoji opasnost da uradiš program i zatim moraš da ga radiš ispočetka (prvo bude ulaz/izlaz, a onda se pojavi međustavka poluproizvod, itd)

Jednostavno, iz iskustva, nemoj raditi program za prijatelja na kome će on da zarađuje, a ti si mu pomogao. Postoji opasnost da kasnije više ne budete prijatelji.

I na kraju, kada to ipak uradiš moraš biti 101% siguran da program radi kako treba, proveri program, ako treba, deset puta. Moraš biti apsolutno siguran! Zamisli da negde nešto zaboraviš i program daje netačne podatke, a prijatelj ti na tome bazira plan nabavke, prodaje i proizvodnje? QQ&LL

Dakle, NHF, pitanje je takvo da sumnjam da će ti neko pomoći jer je odgovor preobiman.

OK. Hvala na prijateljskim savetima.

Nisam ni mislio da mi neko nacrta rešenje problema, već samo da dobijem ideju za rešenje ( a sam cu dalje otkopati).
Ono što mogu da kažem je da sam hteo robi da dodam tri kategorije (S, PP, GP) i da otvorim tabelu gde ce biti upisivane vrednosti za normativ (razmera). Sta da primenim kako bi posle unosa naloga za izradu gotovog proizvoda dobio umanjenje na stanju sirovina (mislio sam generisanje upisa skidanja sirovine sa stanja).

Ako mogu da dobijem makar neke smernice. Na kraju moja je stvar da li cu raditi do kraja ili ne.

Hvala još jednom.

Slažem se sa banemom da je velika odgovornost iza jednog takvog poslovnog programa, no ako čovjek želi probati.

U temi Caffe - praćenje robe (u top temama je) smo također stigli do problema normativa i kako najbolje povezati da se kod prodaje sa jednom stavkom razdužuje više stavaka.

Ja baš i nemam neko rješenje problema, pa čekam da Zidar nešto "iskemija". :-)

Tako da za sada, savjetujem funkymedia da pričeka malo i prati ovu i već spomenutu temu.

Banem - imaš ti možda kakav prijedlog za takvu relaciju među tabelama?

Rešenje se pravi kada se znaju svi zahtevi do detalja. Da bi to uradili moramo znati na koji način radi mešaona:

- ulaz je roba kao sirovina (ili proizvod) i stoji u jednom magacinu ili više magacina
- ona se prerađuje i pri tome se dobijaju poluproizvodi i gotovi proizvodi koji (oba) stoje u nekom magacinu
- u procesu proizvodnji menja se JEDINICA MERE, odnosno upotrebljava se po nešto od svake sirovine i dobija se novi proizvod
- u izlaz idu poluproizvodi ili gotovi proizvodi
- da li postoje interne otpremnice

itd. možda sam nešto zaboravio. Pomogli bi u organizovanju tablica kada bi znali ove detalje.

Čini mi se, otpremnica nije potvrda o kupovini već opravdanje za prevoz tj. potvrda o izdatku robe iz magacina. Dakle osim otpremnice potrebno je izdati fakturu kada se roba proda. To već ide u finansijsko, ali da bi pomogli trebaju na gornji detalji + ekstra zahtevi kojih uvek ima a zavise od poslodavca.

Obrisao sam onaj ostri post. Sve sto sam napisao zaista i mislim, bez namere da vredjam, ali sam ocigleno zvucao preostro i stoga se coveku izvinjavam, za ton pre svega, ostalo shvati vise kao preporuku. Sve sto je Banem rekao stoji.
Izvinjavam se ostalima koje smo odvukli s teme. Na ovom forumu se ne svadjamao, nego se trudimo da radimo konstruktivno. Covek je postavio dobro pitanje, ovih dana potrudicemo se da dobije i odgovor.

Pitanje je veoma dobro, kako resiti problem mesavina. Problem je resiv, ali se zahteva mnogo veci nivo znanja, pre svega iz modeliranja podataka, a verovatno i programiranja, pa ne zurim sa pricom. U isti kos pada i jos jedno pitanje, kako na ulazu robu primiti u gjabicama ili dzakovima, a prodavati na flase ili kilograme? Nisam 100% siguran ali mi se cini da je to jedan te isti problem, moram jos malo da proverim neke stvarcice i onda ce doci i predlog resenja.

Ako vas zanimaju konkretna resenja, mnogo bliza stvarnosti, moete da posetite sajt
http://www.icentar.com/f.35;sess=bf721d6e3732c3fcca47c8ebc8144393

Koga zanima magacinsko poslovanje i maloprodaja, tamo moze da nadje jako korisne savete, iz prve ruke, od profesionalca koji to zaista radi u praksi. Sajt nije moj niti coveka poznajem licno, osim cini mi se sa foruma, iako tamo koristi drugi nick.

Pozdrav Zidaru, Banemu i ostalima.
Problem sam resio jos pre neki dan sa dva kverija, gde od unetih podataka za izradu nekog proizvoda i tabele normativa dobijam sumirane rezultate za ulazne komponente, koje definisem kao izlaz2.
Ako nekog zanima mogu detaljnije da obrazlozim...

P.S. Nisam ljut. Shvatam vas sve i ja radim za novac, ali se pretezno bavim web-om. Iza sebe imam nekoliko prostih access programa, ali mi to nije primarno.
A prijateljima cu uvek raditi for free, jer ce i oni meni "popraviti auto" for free.
Hvala jos jednom i ne zaboravite: Covek je bogat onoliko koliko ima prijatelja.

Evo na sponovo na temi Magacin, posle mnogo vremena.

Verujem da je mnogo sto sta do sada jasnije, pa predlazem da se pomerimo za jos jedan korak - sa magacina da predjemo na poslovanje trgovacke radnje. Radnja kao i svaka radnja, kupuje od dobavljaca jeftino i na veliko a prodaje na malo po vecoj ceni.

Evo zakacen word dokument gde se objasnjavaju razlike.

Molim da svi koji se u praksi zaista bave ovim problemima ukazu na vreme na sve pogresne pretpostavke koje napravim, da ne gubimo vreme objasnjavajuci pogresne stvari. Ja ne radim profesionalno softver za magacine i maloprodajne radnje, ali razumem poneke principe i mogu da pokazem kako bih je to resio u Accessu. Resenja ni u kom slucaju nisu ni najbolja ni jedina, ali je duga ne znam, a sudeci po pitanjima na forumu, bar poneko ce od ovoga imati koristi.

Kad malo ovo proradimo, bicemo spremni da nsatavimo sa kaficem, i kako sam tamo obecao, negde do Nove godine cemo mozda zavrsiti nesto.

Da li da ovo odvojimo mozda u posebnu temu a Magacin uklonomo sa Top pozicije?

U principu Magacinsko poslovanje smo razradili dosta dobro, uz manje ispravke u zavisnosti od potreba korisnika dolazi se do krajnjeg cilja.
Mislim da je dobra ideja da izdvoji maloprodaja u novu temu a da se magacin izmesti sa TOP-a.
Ja sam dobio trenutno zadatak da resim ulaz/izlaz: Dzakovi secera(50kg)/kilogrami pa sam jako zainteresovan kako cemo da resimo ovaj problem?

Cyberghost, kada radiš magacinsko poslovanje, a firma nije registrovana za proizvodnju, onda NE MOŽE da uđe džak u magacin, a izađe KG. To se zove proizvodnja (promena jedinice mere).

Ako uđe džak, ima da izađe džak, mada za tu jedinicu mere nikada nisam čuo.

Hm, pa covek ima Magacin Veleprodaje u koju mu ulazi sva roba, 10 kutija cokolade, 20 dzakova secera. On u svoja 3 maloprodajna objekta izdaje robu, ali ne mora da izda celu kutiju cokolade vec moze samo 30kom iz kutije (bar koliko sam ja upoznat), tako mi je on rekao, pa zato sada on unosi cokolade kao komadi i izdaje u svoj maloprodajni objekat na komad a ne na kutiju. Ovo je sve legalno jer ima registrovan Magacin veleprodaje i tako sam mu isporucio Bazu.

Druga stvar, sada je otvorio i Proizvodnju cokolade e tu je sad morao da oformi poseban magacin repromaterijala iz koga ce da uzima sirovine 100g emulgatora, 300g mlecne masti .... a sirovine u magacin repromaterijala dolaze iz Magacina Veleprodaje. Tu nastaje problem jer roba uzlazi kao sirovina a izlazi kao gotov proizvod i smesta se u magacin veleprodaje. Jos uvek mi je malo zamrseno, tek treba da razradim ideju za realizaciju E-R modela.

Da, stalno se ponavlja jedan te isti problem. Ulaz u jednom obliku, a izlaz u drugom.

Što se mene tiče ja sam za to da se proba odraditi ovaj dio koji je Zidar priložio u zadnjem svojem postu, a zatim da se pređe na ovaj stalno ponavljani problem.

I za to sam da se otvori nova tema "Od veleprodaje do maloprodaje".

Ova shema kako je Zidar opisao u svojem dokumentu je razumljiva i prema tome bi veliku većinu sam znao odraditi, pa me sad zanima kako si (Zidar) ti to zamislio. Ti si dao teoretski, pa da netko od nas to proba odraditi u Accessu i zakačiti, pa će se raditi po tome ispravke ili će ostati to za sad na teorijskom obliku?

Za�to praviti ra�unarskim problemom ne�to �to je zakon ve� regulisao.


Roba u magacinu se vodi samo u zakonom predvi�enim jedinicama mere. U

slu�aju �e�era ta mera je kilogram.


Proizvodnja je tako�e regulisana zakonom. Iz magacina repromaterijala

sirovina ide u magacin pripreme za proizvodnju, a iz proizvodnje ide u

magacin gotovih proizvoda.


Sve to je pra�eno dokumentima (trebovanje, otpremnica, prijemnica, itd).

Tako da se radi na isti na�in kao da se roba nabavlja od dobavlja�a. Jedan

magacin se razdu�uje a drugi zadu�uje. Mo�e da se radi jednim dokumentom

(interna dostavnica) ili sa dva dokumenta jedan je otpremnica za magacin iz

koga ide roba, a drugi je prijemnica za magacin u koji ide roba.

Ma, sve je to jasno. Isto tako se prenosi po kontima u knjigovodstvu kako si opisao. :-)

Ajde, probaj mi odgovoriti na ovaj primjer, npr. mešaona stočne hrane:

Iz magacina repromaterijal izdamo npr. srot i aditiv (ove komponente su izmisljene, jer pojma nemam o tome, no samo za primjer) i odgovarajucim dokumentom to prede u magacin pripreme za proizvodnju.

Tamo se iz te dvije komponente radi gotovi proizvod koji se zove smjesa. I npr. za jednu kg smjese treba pola kg srota i aditiva.

Iz tog magacina se opet prebaciva u magacin gotovih proizvoda i od tamo u maloprodajni objekt gdje se prodaje.

El smo na ostoj valnoj duljini za sad?

E, recimo da se firma bavi i prodajom direktno raznih komponenti (srota i aditiva u nasem slucaju) i dal tada u maloprodajni objekt ide roba direktno iz magacina repromaterijala?

Evo mene opet. :-)

Sada kad sam pisao ovaj zadnji post shvatio sam zapravo da je meni stalno u glavni poslovanje kafića i da se to ipak razlikuje od magacinskog poslovanja.

Tamo roba ne prelazi sva ova skladista i dolazi direktno u maloprodajni gdje ju je moguce prodavati u obliku u kojem je dosla ili kao mjesavinu vise vrsta, pa je mi u tome dijelu problem pojmiti kako se tada smanjuje stanje na zalihi.

No, za ovo cu pricekati kad zavrsite ovu temi i prebacite se na caffe.

Sorry na zabuni.

Dana Thu, 20 Oct 2005 07:49:54 CEST, vmatoic napisa:




U pravu si to je put robe a i dokumenata


Sto se tice kafica i tu se sva pica zaduzuju i razduzuju na litar pa se

tako na litar formira i cena. Ne moze drugacije. Jedan centilitar pica uvek

ima istu cenu bez obzira da li je u koktelu ili je 0.3 ili 0.5 . Mesavine

pica imaju recepturu koja se postuje i na osnovu nje se skida stanje za

svaki koktel. Fakticki je isto kao i proizvodnja, osim sto roba ide iz

magacina direktno potrosacu bez medjumagacina. Ali bitna je receptura.

Da, jasno je to meni no ne znam postaviti pravu relaciju između tabela.

Ako uzmemo za primjer ovu relaciju koju je Zidar postavio nekoliko postova gore mene zanima kako bi trebala izgledati ta tabela sa recepturama.

I sad prema toj relaciji imamo ulaz npr. 1 l juice i 1 l vodke. I to nema problema ako se to prodaje na deci ili manje, no ako netko naruči juice-vodku koja se sastoji od 0,10 juice i 0,03 vodke.

E sad dali prema tome znaš kako bi trebala izgledati tabela sa receptima koja bi se i kako bi se dodala u taj model prema kojoj bi se za određeni koktel/recept smanjila i zaliha za određnu vrstu proizvoda?

Razumiješ što mislim?

Znači ja ne znam postaviti pravilno relaciju! :(

Za admine!

Od usera mkaras dobijam po 20-tak poruka za svaki njegov post mailom (pratim \Access mailom). Molim vas proverite šta se dešava i obrišite ovu poruku kad pročitate.

Moždač bi trebao da postaviš međutabelu u račun. Prva tabela neka ima nazive pića. Druga tabela u relaciji jedan (nazivi pića) prema više (sadržaj) neka ima upisano koliko kog ulaznog pića ide u izlazno. Npr.

1. Pivo
2. Bambus
3. Vino belo
...
1. Pivo 0,5 l
2. Coca Cola 0,25 l
2. Vino crno 0,25 l
3. Vino belo 0,5 l

itd.

Kada računaš stanje upotrebi međutabelu. Za bambus u ovom primeru oduzimaćeš (po relaciji) Coca Cole 0,25 i Vino crno 0,25 sa stanja.

U krajnjem slučaju ne moraš ovako da radiš, već može konobar umesto da ukuca "Bambus" ukuca "Coca Cola 0,25" i "Vino crno 0,25" pa da to ide na fiskalni isečak. Tako se odmah skida sa stanja.

_{[Ovu poruku je menjao banem dana 20.10.2005. u 20:28 GMT+1]}

Probao sam tako, sa još jednom međutabelom, no to nije rješilo problem.

Da, za sad mi ne preostaje drugo nego prodati tako na komade.

A i meni se događa ovo isto sa mailom što i banemu!?

Evo da se malo vratimo na Zidarov model.

Citat iz njegova dokumenta koji je zakačen na ovoj temi:

5) Dobavljacima treba da platimo za robu koju su nam isporucili, pa nam treba tabela za to. Pretpostavicemo da ne placamo svaku isporuku robe zasebno, nego placamo kad i koliko mozemo, pa se povremeno sravne racuni, da visimo koliko im dugujemo, ili smo mozda preplatili.

Čak ako pretpostavimo da ne plaćamo robu zasebno, već skupno, ona bi opet po zakonu trebala biti zatvorena pojedinačno.

Da pojasnim - roba preko tbl_Prijemnice uđe u firmu i glasi na nekog određenog dobavljača i na neki određeni njegov broj dokumenta (to sve imamo u našoj tablici).

Kada platimo robu trebalo bi biti vidljivo točno kojem dobavljaču smo platili i točno koji račun. Znači nedostaje polje BrojDokumenta u tblIsplateDobavljacima.

Tako da bi kartica dobavljača u nekom nasem kasnijem query - u trebala imati ova polja:

DobavljacID, BrojDokumenta, Zaduzenje, DatumZaduzenja, Razduzenje, DatumRazduzenja

Se slažete?

U ovoj fazi, bitno je postaviti tabele i relacije među njima. Koja polja tabele treba da sadrže, ipak zavisi od konkretne firme, pa je to sada manje bitno.
Nego, ovo o koktelima i špricerima. Ja sam radio neki program gde je to potpuno funkcionisalo. Radilo se o prodaji pojedinačnih artikala, ali i mogućnosti prodaje kompleta koji sadrži 3-4 artikla. Na dokumentu je pisalo naziv kompleta i ostali podaci, a magacin sam razduživao preko pojedinačnih artikala. Bitno je da te mešavine, kompleti i sl budu unapred određeni.

Ovo polje i ovakav proces mora sadrzavati svaka firma prema zakonu.


Ako ti nije problem da tu relaciju malo obrazložiš. Bio bih zahvalan. I ako ćeš se odlučiti da obajsniš bilo bi dobro da to učiniš u temi Caffe - praćenje robe.

Imao sam tabelu Stavke (detalji otpremnice-računa) u relaciji jedan prema više sa tabelom Roba. Tabela Roba je u relaciji jedan prema više sa tabelom Artikli.

U tabeli Roba imam recimo:
Komplet1 koji sadrži Artikal1, Artikal2,Artikal3
Komplet2 koji sadrži Artikal4, Artikal5,Artikal3

ali i

Komplet3 koji sadrži samo Artikal1

Kad radim prodaju, izlaz robe unosim komplete.
U upitu IzlazRobe imam tri tabele: Stavke-Kompleti-Artikli.

To je radilo bez problema. Doduše posao je olakšavala činjenica da se sve izražavalo u komadima, nije bilo prebacivanja iz jedne jedinice mere u drugu. Kod kafića treba rešiti pitanje normativa, nisam to razrađivao, pa ne bih tamo da unosim zabunu.

Ako sam dobro razumio tako treba unaprijed odrediti određenu količinu za pojedini artikl?

I onda ja odredim liru vina i litru vode kao zasebne artikle i jos pola litre vina i pola litre vode za komplet, tj. za špricer.

I konobar proda tu litru vina, a nije dobio novu, pa bi prodao ono pola litre koje ima za špricer, no to ne može jer smo ih odredili za špricer.

Sam dobro shvatio kako funkcionira tvoj model?

Načelno - da.
S tim što sam naglasio da ono što sam ja radio je jednostavniji slučaj jer se sve izražavalo u komadima.

U kafiću bi kod ulaza robe imali, naprimer, 10 l vina i 10 l vode. I na lageru bi uvek bili vino i voda. Kad prodamo 10 špricera sa lagera se skida litar vina i litar vode. Znači nikada nema špricera na lageru. Pokušaću da napravim model pa da ga razmotrimo.

Izvinjavam se što kasnim sa odgovorom. Vikend.

edit:
Evo primera kako mislim da bi moglo da se radi "mešanje pića".

_{[Ovu poruku je menjao BiloKoje dana 24.10.2005. u 12:25 GMT+1]}

Svima nama je vikend. :)

Javim ti se sutra kad malo proučim.

Izvinjavam se sto nista ne cinim s ovom diskusijom, bio sam malo bolestan, pa malo odsutan i tako.

Mislim da oimamo dublji problem ovde. Cini mi se da su u diskusiju ukljucena dva -tri programera koji ponesto (ali nedovoljno) znaju o knjigovodstvu i poslovanju prodavnice, i imamo nekoliko knjigovodja koji znaju vise (ali nazalost ne dovoljno) o poslovanju prodavnice. I zakoni koje pominjete su za mene zbunjujuci.

Neko rece da se za svaku prijemnicu pravi posebna uplatnica. Znaci li to da za hleb, koji se isporucuje 30 puta mesecno mora da se pravi 30 uplatnica?

Zakon o mesavinama: bevanda = vino + voda, pa se onda vodi ulaz/izlaz vina ali i vode?

Zakon o mernim jedinicama: pice se uvek prodaje na litre i zakonom je propisana cena. Odkad to drzava odredjuje po kojoj se ceni prodaje pivo ili vinjak u privatnim kaficime ili prodavnicama? Ako je to zaista tacno, sto smo rusili staru Jugoslaviju, tamo je to zakon odredjivao, sada bi trebalo da je poslovanje slobodno. Zar se pivo ne prodaje i na flase i konzerve, koje sve mogu imati drugacije zapremine, i naravno drugacije cene. 341 ml piva u konzervi i 500 ml piva u flasi, kad se svedu na litar, ne daju istu cenu, zato sto se uracunava ambalaza, rad i tako dalje. Znaci, ne lici mi da je bas sve 'na litar'

Oko mene vidim razlicite poslovne modele prodaje pica po kafanama i robe po radnjama. Sve je moguce i sve je dozvoljeno. Pivo se kupuje u paketima od 6, 12 ili 24 (pq i 48) konzervi ili flasa, a moze i na burence od 4.5 litara, a moze i na komad. kupuje se po istoj ceni, od drzave, dakle drzava je jedini snabdevac za sve. U skupim kafanama pivo se placa i 12$ a u obicno 5$. Ima kafana gde se pepsi ili koka kola uopste ne placaju, one su neogranicene uz porucenu hranu. Dobijs casu pa sam ides i doivas koliko hoces. Ista pizza ima tri cene, najjeftinije kad narucis pa dodjes sam da je podignes, malo skuplje ako ti je oni donesu kuci, a najskupje je da tu istu pizzu jedes u pizzeriji. Ovo za picu znam iz licnog iskustva, razvozio sam je neko vreme ( ai vozaci imaju neograniceno besplatno pepsi/7up dok rade).

U maloprodajnim radnjama mozes da dobijes popust, ako napravis veliki racun. Kupimhokej opremu za klince, izadje 238$ za 3-4 stvari, i on mi onda zaokruzi na 225$, jer me zapamtio od prosle nedelje kad sam za drugo dete dao jos 200, pa da mi olaksa muku (i zadrzi me kao kupca za sledeci put)

Moze li neko da dovede na diskusiju nekog ko je vlasnik radnje ili kafica, da cujemo iz prve ruke sta je to sta ljudima treba. Ima razlike u potrebama koje ima knjigovodja koji radi za vlasnika radnje/kafica i potreba samog vlasnika. Ja sam napravio gresku i razmisljao da ovo radimo za potrebe vlasnika radnje, medjutim cini mi se da je vise interesovanja za uraditi nesto za knjigovodju koji radi za vlasnika radnje?

Dana Mon, 24 Oct 2005 14:43:51 CEST, Zidar napisa:




Ovo je velika greska. Kada se pice kupuje u flasama, balonima, buricima,

itd onda se prodajna cena formira na bazi jednog litra pica. Primera radi

ako nam je prodajna cena nekog pica 100 novcanih jedinica onda je jedan

deci uvek 10, a jedan centilitar uvek 1 novcana jedinica. Tako se i

formiraju cene za koktele. Na osnovu recepture saberu se cene pica koje

ulazi u koktel i tako se formira cena koktela.


Nikako se ne sme razlikovati cena jednog istog pica po jedinici mere u

zavisnosti od kolicine koja se prodaje. Na osnovu naseg primera ako 0,5 dl

nekog pica prodajete za 5 jedinica onda 0,3dl tog istog pica smete da

prodajete samo za 3 jedinice novcane. Ako u koktelu to isto pice ucestvuje

sa 0,1 dl onda je njegovo ucesce u ceni samo 1 novcana jedinica.


To je sustina zakona a ne tvoje tumacenje koje je pomalo nakaradno i

zajedljivo. Zakon nije propisao kolika je ta cena vec samo da se moraju

postovati neka pravila kada se jedinica prodajne kolicine robe razlikuje od

jedinice nabavne kolicine.


Pivo i sokovi u konzervama se nabavljaju i placaju komadno, ali se tako i

prodaju. Sigurno ne mozes nikome prodati pola konzerve piva a drugu

polovinu sacuvati za drugog kupca.


Zakon je, ponavljam veoma jasan, samo ga treba procitati i ne izmislkjati

rupu na saksiji.


Naravno da uvek moze da se odobri rabat dobrom kupcu. To niko ne

zabranjuje.

Hvala Mkaras na pojasnjenju. I nisam mislio da budem zajedljiv, samo me zbunjuje zakon ;-(

U Torontu koktel je skuplji nego komponente i prodajna cena svega je onolika koliko gazda to odredi, nema zakona, nema ni preporuka, nema nista. Na kraju obracunskog perioda popisu se troskovi i popisu se prihodi od prodaje. Od prihoda se odbiju troskovi, a na ostatak se placa porez. Kupujes jeftino, prodajes skupo sledi da je razlika velika, sledi da je i porez veliki. Ko voli nek izvoli.

Sta je da je, drzacemo se zakona. To je u delu izracunavanja prodajne cene, ako sam dobro razumeo.

Ova recenica je znacajna:

Iz ovoga proizilazi da ne postoji jednostvana roba nazvana 'Pivo'. Postoji vise razlicitih roba, u kategoriji 'pivo' koje imaju razlicite osobine, imena, pakovanja.
Znaci,

pivo, tuborg, konzeva, 0.341 lit
nije isto sto i
pivo, tuborg, flas, 0.33 lit

To su dva nezavisna artikla, sa nezavisnom cenom (koja moze biti formirana na osnovu zakona koji vodi racuna o odnosu kolicina). Kad tako formiramo tabelu Roba, bice laksi zivot.

A zasto stalno pominejmo kolicine na ulazu i izlazu i pakovanja na ulazu i izlazu? Kad se dovozi pivo iz pivare u kafanu, stize kamionom ili kombijem u GAJBICAMA. A prodace se na flase. Sad, ako sve izrazavamo u flasama, magacioner mora sam da izracuna koliko je flasa primio ako je primoo 23 gajbice po 12 flasa (ili bese 16?)
Ovde kod mene je slozenije, jer 'gajbice' nisu standardnme velicine pa bi racunica koju magacioner mora da izvede bila slozenija. A zasto bi coveku bilo teze da bi racunaru bilo lakse? Za pivo su gajbice koliko toliko standardne. A sta je sa keksom i cokoladom koji se dovoze u bakalnice? Svaki proizvodjac ima za svaku vrstu keksa razlicitu kutiju za transport. Kako ce siroti magacioner to sve da svede na broj kutija? ja bih mu malo pomogao softverom .

:-)



_{[Ovu poruku je menjao Zidar dana 24.10.2005. u 22:34 GMT+1]}

Dana Mon, 24 Oct 2005 22:33:41 CEST, Zidar napisa:


Upravo tako . To su dva razlicita artikla sa razlicitim siframa i svaki

ima svoju cenu.


To je vrlo prosto. Dokument koji prati dostavu i naplatu robe sadrzi

kolicinu u komadima, ako je rec o konzervama piva jer to je osnovna mera za

obracun. Tako da moze da bude 5 gajbica po 20 konzervi i 4 gajbe po 25

konzervi, a u dostavnici pise da smo primili 200 konzervi piva. Sve ostalo,

kolicina konzerve u gajbici, kolicina gajbica u paleti je informativni

podatak i sluzi korisniku samo kao obavestenje. Nema nikakav

knjigovodstveni uticaj.


Primer dugmadi:

U veleprodaji se kupuju na kilogram. Tako se i zaduzuje VP magacin.

U maloprodaji se prodaje na komad. Znaci u toku prelaza iz VP u MP magacin

jedinica mere se menja ali se to dokumentuje na dokumentu kojim se roba

prebacuje iz magacina VP u magacin MP. MP magacin zaduzuje se komadno.

Normalno, zna se odnos za preracunavanje. (Dugmici mogu biti razlicitih

velicina pa samim tim i razlicitih tezina).

OK, sad je vec nesto malo jasnije :-)

Da li mogu dakle da kazem ovako:

1) Robu je potrebno definisati sto preciznije, uvodjenjem nekih atributa, koji preciznije definisu robu. Na primer, ne postoji roba 'Pivo' ali postoje robe (mnozina):

Pivo, Jelen, Konzerva, 0.341 L
Pivo, Jelen, Flasa, 0.33 L
Pivo, Jelen, Flasa, 0.50 L
Pivo, Jelen, bure, 50 L

U ovom slucaju robu smo opisali atributima
{Kategorija (=pivo), Naziv (=Jelen), Pakovanje (Flas, Konzerva, bure), Velicine pakovanja (0.341 L, 0.5 L, 0.33 L, 50 L)}

Za druge vrste roba bili bi drugi atributi. Potrebno je da se sva roba u magacinu opise ako je ikako moguce istim atributima. Ovo moze da bude problem, ako na primer isti magacin (radnja) radi sa picima i auto delovima. Skup atributa za pivo i autodelove nije isti.

2) Svaka roba ima definisan unapred tacno jednu jedinicu mere koja se koristi za obracun (flas odredjene zapremine, konzerva, kutija, kilogram, litar)

3) Na ulaznom dokumetu (prijemnica=temeljnica=dostavnica) uvek treba da pise kolicina izrazena u zvanicnoj jedinici mere, tako da magacioner ne mora da prerecunava. Pored toga treba da pise i stvarna jedinica (gajbica) i kolicina. To mozda nije bitno knjigovodstveno, ali jeste u stvarnom zivotu. Svaki magacioner ima dva koraka da uradi kad prima robu a) da zavede papire u knjige (ili kompjuter) b) da prebroji sta je stvarno stiglo (pre nego sto zavedde u knjigu)

4) Da li gresim kad kazem prijemnica=temeljnica=dostavnica? Ako gresim, molim da neko objasni sta je sta i kako je sta u vezi sa ostalim dokumentima. Moze li neko da zakaci na odgovor PDF kopiju neke realne prijemnice/temeljnice/dostavnice?

:-)

[Quote]A zasto stalno pominejmo kolicine na ulazu i izlazu i pakovanja na ulazu i izlazu? Kad se dovozi pivo iz pivare u kafanu, stize kamionom ili kombijem u GAJBICAMA. A prodace se na flase.[/quote]

Ne, koliko ja znam, ne ide na gajbe. Radio sam u knjigovođstvu, ali smo imali u firmi imali i VP i MP piva. Kupac naruči npr. DVE gajbe, ali mu mi to fakturišemo kao 24 flaše. Gajba nije mera količine.

Tj. ako je "gajba" ulaz, onda moraš prodavati 1/24 gajbe za pojedinačnu flašu jer u određenim trgovinama ne smeš da menjaš jedinicu mere kako ne bi načinio "proizvodnju".

Za mkaras:

Prvo zahvaljujem na uloženom trudu i sorry što kasnim, no imao sam nekih drugih obaveza.

Aplikacija radi dobro prema relaciji koju si postavio. Sličnu sam i ja prije par dan postavio, no ona ipak ne zadovoljava 100%.

Evo gdje je još problem:

Ovo sad funkcionira sa artiklima koji "različiti" na ulazu i izlazu.

No, ja imam npr. ulaz 20 piva tuborg i sad pivo tuborg moram upisivati u dvije tablice artikala kako bi ga mogao prodavati.

Kad bi se iz tbl ProdajaStavke polje artikliZaProdajuID moglo uzimati u combo boxu osim trenutnog polja artikliZaProdajuID i polje ulazniArtikalID iz tbl UlazniArtikli.

No, i ovako će poslužiti. Hvala još jednom.

Evo sta mene muci a slicno je problemu kafica:
Iz magacina VP se roba izdaje u Magacin Repromaterijala, npt: 100kg secera, 20kg emulgatora, 8kg mlecne masti ... Kuvar (pravi cokoladu) treba da uzme odradjenu kolicinu svakog od ovih artikala. Magacin repromaterijala izda kuvaru trazenu kolicinu sirovina i za toliko se umanju stanje na lageru sirovina. E sad je potrebno da se automatski za izdatu kolicinu sirovina preko formule izracuna koliko kilograma cokolade mora da se dobije i da se ta ista cokolada smesti u magacin. Kada dodje kontrola vidi se koliko je sirovina izdato i koliko je cokolade uskladisteno u magacin i to mora da se poklopi !

Ovo je ipak za mene, a ne za mkarasa.

Kod unosa istog podatka u dve tabele (primer tuborg piva) koristio sam akcioni upit da podatke unesem i u drugu tabelu. Da bi bilo brže.

Ne vidim razlog da se u tbl ProdajaStavke unosi i podatak ulazniArtikalID. To se preko postavljenih veza dobija u upitu.

Pozdrav.

Da za BiloKoje je prethodna poruka!!! Sorry!

Znaci akcioni upit, OK, hvala na svemu jos jednom!

_{[Ovu poruku je menjao vmatoic dana 26.10.2005. u 09:48 GMT+1]}

Pronašao sam VAŠ problem odmah kada ste ga objavili.
Ja ga nisam mogao riješiti i zato se nisam ni javljao.Evo i ja imam jedan
problem, a vidim da niste čovjek koji živi samo od interesa, pa sam odlučio
pomoć od vas potražiti.O čemu se radi?

Imam skener za koji nemam drajver za operativni sistem XP. Model skenera je:
Umax Astra 610S.
Molim VAS ako ikako možete da mi pomognete VI lično ili preko VAŠIH
prijatelja. Ukoliko budete voljni za pomoć navedeni drajver možete poslati
na email
[email protected].

Slijedi bilo kakav revanš. PUUUUNO HVALA!
MASSMMI

>

Da, i meni je potrebno to sto je bilo potrebno i vama. Molim VAS da mi to
detaljnije objasnite. Pozdrav!
>