Zidareva teorema: The best code is no code at all.

Koliko puta da ponovimo: stanje se ne cuva u tabeli, nedgo se izracunava kverijima kada ti zatreba. Ako ovo poslusas, sav tvoj kod za UPDATE Sanje jednostavno nece postojati. Jos jednom, u relacionim bazama se stanje ne azurira prilikom svake transakcije. Moze i to da se uradi, ali je absolutno pogresna praksa. Dozvoljava se samo iskusnim programerima koji su logiku aplikacije preneli iz dana Clippera i Dbase jezika. Za nove aplikacije to bi trebalo zakonom zabraniti. Ako ti pokazemo kako da azuriras stanje znaci da ti podrzavamo jednu pogresnu logiku zbog koje bi pao na ispitu. Prema tome, necemo ti reci kako da odradis taj update. A o tome kako se stanje izracunava, pisali smo nadugacko i nasiroko na ovom forumu, a imas i forum Baze Podataka, pa potrazi.

:-)

Ajde malo da ublažimo ovo Zidarevo "nikad", a da ga ne rasrdimo previše. :-)

Elem najčešće se radi o poslovnim aplikacijama i bazama koje imaju životni vek od jedne godine nakon čega se počinje iz početka. Neka iskustva govore (ovo nije nikakvo egzaktno istraživanje) da za Access ne treba razmišljati o čuvanju stanja količine u magacinu sve do broja otprilike oko 10.000 dokumentata. Za SQL server bi bilo oko 20.000 dokumentata. Obratite pažnju da govorim o dokumentima, a ne o broju slogova kojih je mnogo, mnogo više. Za te gore navedene uslove sasvim se komforno može koristiti SQL jezik.

Šta ovo u suštini znači. Imate jednu tabelu u kojoj su sva dokumenta. Nad njom primenjujete upit sa tvrđim ili mekšim kriterijumima i upit će raditi dodvoljno brzo. Pre modeliranja tabela raspitajte se kod korisnika ili vlasnika sistema o mogućem broju dokumenata.

Čak ni ova iskustva ne treba uzeti previše kruto kad se na umu ima brzina razvoja hardvera.

Evo jednog svezeg primera, sa foruma Baze Podataka. Covek je hteo da radi UPDATE Stanje u run-tme, aplikacija "Kase u samousluzi", back end SQL Server. I vidite sta se desilo i kakva su misljenja i iskustva :-)

http://www.elitesecurity.org/t282119-Organizacija-baze-podataka

Da. Ovo je sjajan primer. Pratio sam ga od početka. Chachka je dobro stavio akcenat na organizaciji poslovnog procesa. Dovoljno je da se jednom dnevno odradi ažuriranje na serveru. Sve ostalo bi kočilo redovne aktivnosti. Ovo samo potvrđuje da se pre modeliranja baze podataka (informaciono modeliranje) mora uraditi funkcionalno modeliranje - modeliranje procesa i aktivnosti, a to opet zahteva snimanje poslovnog procesa, intervjue, analize dokumenata i da ne nabrajam. Ovde na forumu imamo otežavajuću okolnost pri pomaganju u modeliranju što nemamo često ni 2% nužnih informacija. Zato se na kraju sve svodi na krpljenje i vađenje iz (biću fin pa ću reći) čabra.

ovo je baza magacina...i u svakom trenutku mi treba stanje robe

magacinID magacinNO robaID stanje lokacija alternativniPartNo
autono c123 abc ok polica H4 xxx poslecemo o ovom xxx

treba pregled robe, i sva dokumenta prijemnice otpremnice i povratnice vezane su za stanje robe
gde se nalaze comboboxevi i u njima za otpremnice nalazi se roba cije je stanje ok, otpremnica neispravne robe tj.vracanje robe combo sa robom cije je stanje neispravan i gde ga menjam u vracen...

evo poslacu bazu ... najlakse je tako da vidite o cem pricam

Ako sam dobro pregledao, ti se ovde nigde ne baviš količinama. Stanje u magacinu "magacinTab" ti je opisna kategorija. Dokumenti "docsTab" ne nose informacije koje sam, možda neopravdano, očekivao da vidim (količina, cena, rabat.....). Slede pitanja : Čemu služi ovakav sistem? Koja mu je namena? Koji zadatak treba da obavi?

cemu sluzi...pa
samo da prati robu....
sta je u magacinu, koja je roba gde otisla, kad
treba i da ubacim narudbinu da ing. naruci neki deo iz baze da mu se donese
ali ovde novac nema ulogu..ovo je interno i samo je bitno stanje magacina, dal roba postoji u magacinu i dal je ispravna i gde se nalazi,ako je otisla onda gde kome kada ko je dao i sl
docTab- tabela otpremnica prijemnica sluzi da se zna gde i kad i kome je roba otisla
cena i te stvari cu kasnije kad naucim ovo da uradim i onda napraviti novu bazu koja posle mora da uporedi stanje s ovom bazom

dal si primetio greske u programu
- da po brisanju nekog dokumenta obrise i njegove stavke
- esc dugme brise podatke iz baze bez pozivanja funkcija
- naci resenje za slucaj kad se roba vraca pod drugim part.no.
- multiply delete not working
- delte msgbox pa cancel kad izaberes nevraca na prethodno stanje
- on change combobox

1.
Što se tiče cene uredu. Onda je to Materjalno knjigovodstvo magacina. Ali gde su tu količine. Nemoj mi reći da neko naručuje robu i ne upiše koliko, da ovaj drugi izda robu iz magacina i na otpremnici ne napiše koliko. Kakva je svrha znati da u magacinu ima robe i da je ispravna ako se ne zna koliko. Čak i u magacinima tipa visokoregalnih skladišta, koja imaju lokacije (atribut koji si dodao u magacinTab) unutar magacinskog prostora, ništa se ne radi bez količina. Jedino možda premeštanje sa lokacije na lokaciju unutar magacina, mada sumnjam da je to posredi, jer čemu onda tabele dokumenti, klijenti, korisnici...
2. Greške u programu nisam ni gledao jer da bih nešto mogao da ispravim mora da mi bude jasno kako stvarno treba da radi, a ne kako si ti zamislio da treba da radi. Ako je ovo zadatak za vežbanje onda si odabrao jako tešku temu. Na ovom forumu ima nekoliko dobrih zadataka odrađenih od početka do kraja kao što je na primer ova http://www.elitesecurity.org/t133029-0-Caffe-pracenje-robe
Možda bi bilo dobro da je pročitaš i pokupiš neke ideje i znanje.

P.S. Korišćenje malo ADO malo DAO u VBA je jako loša praksa pri učenju. Probaj da se opredeliš za jedan model, a drugi isključi iz referenci. Kasnije možeš kako hoćeš.

_{[Ovu poruku je menjao Getsbi dana 02.10.2007. u 13:32 GMT+1]}

upravu si sto se tice kolicina...
nisam to najbolje izveo...ali ako pogledas otpremnicu
kad biras robu iz komboboxa on gleda robu sa stanjem ok i sortira po robaID i magacinID
i odatle izaberm prvo pojavljivanje robaID jer je i ta roba prva dosla u magacin...tu treba da bude i magacinNo gde je to sifra robe po kojoj je traze u magacinu
znaci za otpremnicu mi je bitno koja kutija odlazi to jest odredjeni magacinNo
magacinID magacinNo robaID lokacija stanje
autono C123 abc H4 OK
i sad znam da je C123 ok tj. u magacinu je i kad odes u magacin nadjes policu H pa sprat 4 i jurim C123
i nadjem kutiju C123 i pogledam partNo koji treba da je =robaID

kad mi se vraca roba...dolazi sa kutijom istom tom kutijom na kojoj pise C123 (ili onaj drugi slucaj kad dodje sa drugim part No ali to kasnije) i sad u zavisnosti od stanja ok ili neispravna imam tamo u prijemnici dugmice i unosim je nazad u magacin ali bas nju C123 sa odgovarajucim magacinID...

nisam znao kako da uradim to sa kolicinom...jer kad dodje roba fizicki prvo skines fakture proveris partNo i svakom stavis nalepnicu (C123 npr) i sad je svaki ponaosob definisan i kad ga unosim u magacin mislio sam u prijemnici bas tako da ga unesem .... video si ,partno i tamo ima magacinNo lokacija..odma da uneses...

ako bi stavio doslo 3 dela sa nekim partNo .posle moram neki novi form da ih prepravljam da im dodeljujem magacinNo i lokacije..
ovde je sve vezano za kutije....

Necu dalje da se mesam, ali ne mogu da ne primetim ovo
Niko ne spori potrebu za pozbavanjem stanja robe u svakom trenutku. Ono sto smo pokusali da ti kazemo ali ti ne zelis da cujes jeste: da bi znao stanje robe u svakom momentu NE TREBA ti izracunavanje stanja i upisivanje u nekakvu tabelu pri svakoj transakciji. vecina problema koje imas s aplikacijom potice iz uporne zelje da cuvas stanje posle svake transakcije i to zamagljuje druge probleme koji bi s emozda mogli i resiti. Dakle, imas mnogo nepotrebnog koda koji ti stvara mnogo nepotrebnih problema od kojih ne vidis one prave.

Nemam daljih komentara.

Evo šta sam uspeo da saznam iz modela :

Projektni zadatak : Evidencija u magacinu (sudeći po formama)
Metoda : FIFO (prva ušla prva izašla) sudeći po ovom iskazu: „ ...ali ako pogledas otpremnicu
kad biras robu iz komboboxa on gleda robu sa stanjem ok i sortira po robaID i
magacinID i odatle izaberm prvo pojavljivanje robaID jer je i ta roba prva dosla u
magacin...“
Zahtev korisnika : Bez vođenja količina po artiklu već šifriranjem tipa:
magacinID(magacinNo(robaID(lokacija(stanje)))) (sudeći po tabelama)

Stanje je opisna kategorija sa mogućnostima:
"OK", "VRACEN", "POZAJMLJEN" , "NEISPRAVAN" , "OTPISAN"
( bar tako piše u bazi)

Komentar :
1. Ako nema količina nema ni stanja na zalihama. Govorimo evidenciji statusa svake pojedinačne robe na nivou neke kutije ili pakovanja. (Ovde bi možda više odgovarala reč STATUS nego STANJE). S druge strane ne da mi mira onaj iskaz pod navodnicima. Ne znam šta da mislim.

2. Ako zbilja treba da napraviš kontrolu zaliha u magacinu po gore pomenutoj metodi. Uvedi jedinstvenu šifru za artikal, količinu, datum i vreme ulaza u magacin. Stanje ti neće trebati i uvek ćeš moći da ga izračunaš ili bar do granice koju sam spominjao. Nakon toga razmišljaš o preseljenu baze na SQL server i nekoj boljoj organizaciji podataka.

3. Ako je to evidencija o svakom pojedinačnom komadu neke robe onda tu bogami ne treba većina formi, a o kodu da i ne pričamo. VBA bi trebalo da atomatizuje nešto što ne može da se uradi na nivou objektnog programiranja.

Da li je zakačen fajl neko pogledao i možda razumeo bolje?

ma dobro si razumeo....nego ja sam se zapetljao..
artili su racunarske,serverske komponente...i bitan mi je magacinNo koji predstavlja sifru ili barcode ili bilo sta sto ce jednoznacno da predstavi tu komponentu, kutiju koja ima neki partNo(koji opisuje kategoriju robe) kao i neke druge..
Ako bi unosio u prijemnicu .. recimo partNo abc 3 komada...al to ne moze jer mi je svaki od njih definisan sa magacinNo...nemogu kolicinski nego moram kutiju po kutiju.

1. status , stanje sve jedno..al to je to

2. jednistvena sifra za artikals stanje datum...
inputOutputTab mi predstavlja stavke svih dokumenta
inoutID autonumber
magacinID da povezem sa tabelom magacinTab i da promenim stanje robe
docID da vezem za odredjeni sifru dokumenta
tipDoc za tip dokumenta 1 prijemnica 2 povratnica 3 otpremnica

znaci recimo prepravim tabelu inputoutputTab ,pored inoutID,magacinID,docID,tipDoc, da dodam i stanje i vreme
ali kako posle da je pratim...tu robu sa odredjenim partno i magacinid....trebalo bi posle da nadjem zadnje pojavljivanje magacinID u tabeli i procitam stanje iz inputoutputtab-ele....

3. sta bi trebalo da prepravim, koje su form visak
mislio sam da prepravim tab inputoutput i umesto oni docID i tipDoc bude neki dokumnetID koji ce biti vezan za tabeliu docTab i id kjluc....i one kverije kljijent i dobacljac to da izbacim..i.....

razumem sta hoce zidar da kaze...ali krenuo sam ovako i mislio da mi je tako lakse...nisam znao drugacije...
da sam pitao nekog cim sam krenuo da radim bazu bilo bi bolje ovako sad moram da sve menjam...
al sta je tu je..

eto molim za pomoc .. kako bi trebao da nadgledam stanje robe ....ili jos bolje od pocetka ...sad kad znate tematiku
da li sam dobro postavio tabele...relacije..
hvala

Dobro idemo iz početka. Zaboravi sve do sad. Prvo pitanje: Da li se u tvom magacinu nalazi roba sa istom šifrom koja se može ponoviti više puta količinski? Rcimo pošto su računarske komponente u pitanju. Da li u magacinu može u isto vreme biti dva ili više kulera za kućište istog: tipa,jačine, proizvođača......... ili je svaki obeležen jedinstveno i ima ga samo po jedan komad?

moze..

magacinno 36 ,partno 1420-0866, opsi battery...., stanje neispravan, lokacija j1, datum1
magacinno 83 ,partno 1420-0866, opsi battery...., stanje neispravan, lokacija h4,datum2
magacinno 308 ,partno 1420-0866, opsi battery...., stanje neispravan, lokacija f3,datum2
1420-0866 je baterija jednog proizvodjaca odredjenih k-ka
isto tako neki drugi partno moze biti baterija drugih k-ka ili drugog proizvodjaca

kad ih trazim , trazim ih po magacin partno pa koji je prvi usao a to je magacinNo 36, pa lokacija i eto ga...

Dakle svaki je obeležen jedinstveno i svaki komad 1420-0866 se unosi pojedinačno ručno u tabelu iz razloga lepljenja etketa (neke vrste šifriranja). Da li sam u pravu?

Predpostavljam da sam u pravu, a to potvrđuje i tvoj gornji tekst:

„ artili su racunarske,serverske komponente...i bitan mi je magacinNo koji predstavlja sifru ili barcode ili bilo sta sto ce jednoznacno da predstavi tu komponentu, kutiju koja ima neki partNo(koji opisuje kategoriju robe) kao i neke druge..
Ako bi unosio u prijemnicu .. recimo partNo abc 3 komada...al to ne moze jer mi je svaki od njih definisan sa magacinNo...nemogu kolicinski nego moram kutiju po kutiju.“

Pogledaj sliku u prilogu.
Napravio sam početni model koji ćemo još da utanačimo. Uveo sam tabelu “VrstaDokumentaTab” .
1. Jedna vrsta dokumenta se u tabeli 'DokumetTab' može naći više puta.
2. Jedan Dokument ima više stavki.
3. Jedna roba se može naći više puta u stavkama. Ovde postoji mogućnost da uvedemo količinu u StavkeDokumenta, ako mi pojasniš kako izgleda prijemni odnosno otpremni dokument.
4. Jedan radnik može da izvrši više radnji u magacinu ili duži više pojedinačnih primeraka robe.
5. Veza između stavki magacina je za sad slaba bez referencijalnog inegriteta. Naknadno ćemo da je utvrdimo.
6. Roba u magacinu je jednoznačno određena ako joj ispred šifre dodelimo nasumice odabran broj (AutoNumber). Tako dobijamo jedinstvenu šifru robe u magacijnu.
7. Lokacija nam pomaže da saznamo u koji ćošak magacina smo robu odložili.
8. Status nam govori o onome što treba da znamo o toj robi. ("OK", "VRACEN", "POZAJMLJEN" , "NEISPRAVAN" , "OTPISAN")

Tabele : KroisniciTab i KlijetiTab nisam još povezao jer mi nedostaju neke informacije.

Ko su korisnici , a ko su klijenti? Kakva je čija uloga u procesu evidencije u magacinu?
Da li su pravna ili fizička lica?

Odgovori mi na pitanja, pitaj i komentariši.

P.S. Izvadio sam RobaID iz primarnog ključa magacina. Mislim da će dovoljno biti indeksiranje.






_{[Ovu poruku je menjao Getsbi dana 04.10.2007. u 13:40 GMT+1]}

da to je to...samo sto se tice sifre u magacinu ....ostavio bih magacinID kao autono i morao ih dodati magacinNo
realno gledano magacinNo bi trebao da bude magacinID ali roba vec ima neke stare sifre koje necemo menjati te iz tog razloga morao bih ostaviti magacinNo..eto samo to..

a sto nebi radniciTab povezali sa DokumentTab umesto magacinTab,tj. da se u dokumentu vidi koji je radnik odgovoran.

dokumentID nije autonumber, tipa text i moze da se desi sledece
tsg05/5 da je naziv dokumenta za otpremnicu i za prijemnicu, gde to nesto znaci kao 5 mesec 2005,ali u principu nek korisnik unosi naziv dokumenta
u designview da se stavi yes(allow duplicates) ili kao ono sto sam ja komplikovao....yes (allow duplicates)

dokumenta ..nista posebno neizgledaju
otpremnica xxxxx
primalac xxxxx
krajnji korisnik xxxx
-------------------
# roba opis kol.
------------------
datum xxxxx napomena xxxx

primio izdao
xxxxx xxxxx

i to je to.
sto se tice kolicina...nek bude da moze da se unese odjenom vise artikala pod istim partNo(robaID) ali da se to posle nekako moze prepraviti u magacinu i dodati mu magacinNo za svaki artikal razlicit magacinNo
mada uglavnom roba dolazi po 1 kom od svake...hocu reci razlicite kutije.

dokumentiTab -- kljucevi za povezivanje sa klijentiTab i korisnicitab
i dobro sad i stavkedokumenatatab onda doda se kolicin

Što se tiče starih naziva iz prošlog modela ostaviću sve što je razumljivo širem krugu posetilaca ovog foruma. Nazive tabela ti nisam sve promenio, samo one koje mi nisu izgledale smisleno i dovoljno razumljivo. Ovo nije komunikacija samo između mene i tebe već svih zainteresovanih. Ovde si ti recimo u trećem razredu, ja u petom a gledaju nas i oni iz prvog i oni iz osmog. Niko nije nepogrešiv, a ja pogotovo. Trudićemo se da nam oni iz osmog pomognu ako negde omanemo.

Model je još uvek na logičkom nivou tako da ćemo o tipovima polja odlučivati kad ga dovedemo bar na 80 % izvršivosti.
Nisi mi decidno odgovorio na pitanja. Trudi se da bude razumljivo, a ne kao ovo na kraju tvog zadnjeg posta.
Trenutno nemam vremena od nekih obaveza ali već večeras ću da izbacim sledeću verziju sa uključenim sugetijama.

_{[Ovu poruku je menjao Getsbi dana 04.10.2007. u 12:24 GMT+1]}

Evo ugradio sam neke tvoje sugestije:

Dodao sam u magacinu atribut StaraSifra umesto magacinNo. Tako je razumljivije, a ti imaš zadovoljen zahtev korisnika da se vide i stare šifre.
Dodao sam RadnikID u tabelu DokumentiTab kao nekog ko je Nosioc dokumenta - neko ko potpisuje otpremnicu i izdaje robu ili prijemnicu i zaprima robu.

Broj dokumenta bi trebalo da dodeljuje tvoja evidencija, a da se u OpisDokumenta pozivaš na tuđi broj baš iz razloga što se može desiti da ti stignu dva dokumenta iz vana sa istom nomenklaturom.
Zanima me razlika Korisnika i Klijenta koje kako vidim iz opisa dokumenta koristiš za atribute dokumenta: primalac i krajnji korisnik. Da li je moguće da neki klijent bude u drugom momentu krajnji korisnik i obratno. Ako jeste uveo bih jednu tabelu PoslovniPartneriTab, a nju podelio na entitete kategorija: FizičkaLicaTab i PravnaLicaTab pod uslovom da firma radi i sa jednima i sa drugima. Poboljšanje bi bilo poprilično.. S tim što fizičko lice može da bude deo pravnog lica (OsobaZaKontakt).

Veza partnera i dokumenta može da ostane ovakva, mada je bolje da u dokumente stavimo (PartnerID i UlogaPartnera) umesto (Primalac i KrajnjiKorisnik), što sam i uradio.

Na ovaj način smo donekle učvrstili model i ako sam dobro shvatio poentu projektnog zadatka dosegli smo nekih ¾ logičkog modela. Možda se kasnije ukaže potreba za još nekom tabelom.

Ovo je sve podložno kritici i pošto smo krenuli putem bez količina u magacinu, a samim tim i bez izračunavanja stanja robe, voleo bih da se i drugi uključe u temu, a pogotovo Zidar čije će nam iskustvo pomoći da model dovedemo bliže završetku. Na ovaj način bi ti imao dobru startnu poziciju a ostali koji pomažu ne bi morali da vade trnje.

opet si upravu...
klijenti - to su firme sa kojima radimo bilo da su dobavljaci ili korisnici
korisnik je fizicko lice iz neke firme
"Da li je moguće da neki klijent bude u drugom momentu krajnji korisnik i obratno. " moguce je
sto se tice kolicina, kolicine mozemo ukljuciti u dokumenta ali onda moramo nekako naknadno obezbediti obelezavanje robe, lepljenje etiketa ili barcoda

izmene u tabeli...
robaID- tipa text, roba id predstavlja part NO koji je na kutiji a on je u formatu a1234-5678

dolkumenttab...
ja sam se izgubio s onim tabelama partner,fizicko,pravno lice...mozemo li to pojednostaviti
partnerID je neko lice, pa ulogaPartnera dal je korisnik ili krajnji primalac....ali mislio sam da bude odvojeno,da recimo
ima primalac robe to je neko lice ,petar petrovic iz dhl-a, i posebno krajnji korisnik a to je neka firma (nije bitno lice u firmi jer njemu nisam dao robu dao sam je petru iz dhl-a)
znam mene je tesko razumeti....

ako se slazes, onda da odradim izmene i postujem je...

To oko bar koda, optičkih čitača i upisa u bazu se ne razumem i nisam nikad radio, tako da ti tu ne mogu pomoći. Mada mislim da nije neka preterana nauka. Količinu možeš da uključiš u DokumentiTbl. Kasnije se može pri prenosu iz dokumenta u magacin obezbediti dodela šifre i upis u magacin slog po slog umesto zbirna količina. (Sve ovo iz razloga načina vođenja artikala u magacinu po pojedinom komadu).

Ti kažeš: “klijenti - to su firme sa kojima radimo bilo da su dobavljaci ili korisnici
korisnik je fizicko lice iz neke firme“
Ako prodajete usluge onda su korisnici takođe i kupci usluga, a možemo ih zvati i korisnicima svejedno. Korisnici, Kupci, Klijenti, Dobavljači...... svi su oni poslovni partneri. Razlikuješ ih od radnika svoje firme jer za ove druge ćeš možda morati da radiš plate ili nešto drugo dok se oni prvi razlikuju po tome kako ih tretira tvoja firma. Možda ćeš u početku imati mali otpor prema ovakvom viđenju pertnera, ali takav pristup obezbeđuje da isto lice nemaš u dve tabele. Ako u tabeli DokumentTbl ostaviš KrajnjiKorisnik i Klijent, možeš da vežeš dvostruko iz PartneriTbl. I model i aplikacija će da izdrži ali to već narušava eleganciju. Ako se ukaže potreba pa povećavaš broj veza od partnera prema dokumentu na tri ili više to će govoriti o potrebi da se izvrši prekomponovanje tabela. Zato mi se više dopada varijanta sa ulogom partnera, a na izveštajima i štampanim dokumentima se po potrebi ispred podataka piše njegova uloga: Klijent, korisnik, ovlašćeno lice..... Malo razmišljaj o mogućim pojavama u pojedinim poljima.

Ali na kraju krajeva poslovni proces je tvoj, ti ga najbolje vidiš tako da nije uputno da ti ograničim da prepraviš model.

Promeni RobaID u tekstualno polje ako format nove šifre to zahteva. To verovatno važi i za staru šifru. Odradi ovo i okači možda će neko hteti da prokomentariše.

samo sam izmenio robaid da bude tipa text.....

"Veza partnera i dokumenta može da ostane ovakva, mada je bolje da u dokumente stavimo (PartnerID i UlogaPartnera) umesto (Primalac i KrajnjiKorisnik), što sam i uradio."
mislio sam da ubacim kao ranije sto sam ja uradio ali nisam...samo mozes li da mi pojasnis kako bi to izgledalo u formi
partnerid bi birao iz comboboxa a u uloga partnera bi kucao sta...

posto u dokumetima pise primalac i krajnji korisnik mislio sad da i tako formu odradim...a i posle ako bude pretraga po krajnjem korisniku bilo bi lakse...

Dobro. Evo to sam sad i ja promenio u vezi tipa RobaID. Uzgred sam dodao tabelu UlogaPartneraTab koja će imati par slogova: Klijent, Korisnik, Dobavljac, Kupac... To specificiranje će biti od koristi. Tako da sad možeš na formi za unos dokumenta da odabereš ulogu partnera iz Combo Boxa zasnovanog na UlogaPartneraTab. Ja bih to sve odradio na sledeći način. Sve što sam obeležio kao šifarnike: RadniciTab, RobaTab, VrstaDokumentaTab i UlogaPartneraTab radio bih kao Dtasheet forme, pošto i stvarni papirni šifarnici izgledaju kao neke pregledne tabele. Dokument i Stavke dokumenta bh uradio kao formu i podformu sa onim Combo box-ovima koji su nužni za odabir podataka iz nekog od šifarnika. Kad to odradiš i zakačiš objasniću ti kako da ukljušiš partnere kao jedinstveni izbornik u formu za Dokumente.

promenio dokumenttab.
opisdokumenta,datum ---required

stavkedokumenta
dodao kolicina

skicirao form prijemnica kako mislim da treba da izgleda ali nesnalazim se sa partneriTab te to ne znam kako da ubacim
i videces stavke prijemnice e i tu mi nije jasno kako si isplanirao da se ubacuje roba i da on prati kolicinu i stanje robe

Napravio sam dve nove forme i tri nova query-ja. Forme su Datasheet View i zasnivaju se na query-jima koji su spoj po dve tabele. Posebno obrati pažnju na query “qryPartnerFizickoLice” i kolonu Partner: FizickoLiceTab.Prezime & " " & [ime] u polju Field. Ona obezbeđuje da se sa lakoćom načini treći query “qryPartnerUnija“ koji je po tipu Union i koji se mora napisati za razliku od ovih Select koji se mogu i dizajnirati. Taj treći query sam iskoristio za izvor podataka Combo box-a na formi “frmPrijemnica”. Ako ga pokreneš kao query videćeš koja su polja uparena. Prezime + Ime sa NazivPravnogLica, JMBG sa PIB-om i tako dalje. Isti query, a raznorodni podaci. Ovo mi se učinilo vrlo praktičnim rešenjem za tvoj primer gde partneri mogu biti i jedni i drugi.

Što se tiče unosa dokumenta moraćeš da napraviš dugme i ispod njega VBA kod koji će da ažurira slogove u magacinu dodajući ih ili brišući u zavisnosti od tipa dokumenta (Prijemnica ili Otpremnica). Pošto nema polje količina u magacinu jer se svaki primerak robe dodaje i oduzima pojedinačno, a roba prati kvalitativno a ne kvantitativno, tvom kodu za ažuriranje trebaće For Next petlja i brojač iniciran količinom u tabeli “StavkeDokumentaTbl”.
Kada bih se ja pitao “frmPrijemnica” bi se zvala “frmDokumenti“ i ta bi forma služila za unos svih vrsta dokumentata, a VBA kod ispod gore predloženog dugmeta bi grananjem radio ono što je neophodno u zavisnosti o vrsti dokumenta.

oket.. unija kombinuje rezultate vise queryy-ja..
al sto se tice frmDokumenti...kako bi to izgledalo, sta..imao bi dugme da ili combo da biras koji je tip dokumenta
i onda na osnovu izabranog namestio bi izgled forme...kako?

Izborom vrste dokumenta iz Combo box-a i popunjavanjem istoimenog polja slog je definisan kao jedan od dokumenata. Forma bi bila jedinstvena za sve dokumente. Nebi imalo potrebe da se razlikuju Prijemnica, Otpremnica, Povratnica.... po izgledu. Forma bi imala sva potrebna polja. Popunjavaš samo neophodna za tu vrstu dokumenta koji unosiš. Znači, od vrste dokumenta ne bi zavisio izgled forme već način ažuriranja tabele MagacinTab. Šta je dobitak? Manje je formi, a kod je na jednom mestu umesto u tri modula forme. Pogotovo što bi kod bio u visokoj meri identičan kod sve tri forme, odnosno ponavljale bi se nepotrebno mnoge instrukcije. Dole imaš sliku, kako izgleda unos svih dokumentata.

Inače, može se podesiti i da neka polja budu vidljiva ili nevidljiva u zavisnosti od odabrane vrste dokumenta, ali o tome samo ako bude bilo potrebe.

da,da....ok thx
cekaj...aa da..isto tako bi mogao iz stavkedokumenta da sakrijem neke kolonece,ili comboboxove koji postoje
ali nisam to uspeo probao sam ja to nesto

prepravio sam formu...
e sad, onaj option btn koje vidis mogli bi samo da menjamo label (otpremnica,prijemnica,povratnica) i da radi razlicite funkcije u slucaju od izabranog dokumenta (gore ce biti kombo da bira vrstu dokumenta) ...

neradi mi combo sa partnerID

jos ne znam one stavke dokumenta kako da odradim, da bude zajednicko za sve dokumente

Ovo u vezi Combo box-a je moja greška. Stavi 4 umesto 1 u osobinu Bound Column. Ostavio sam keca po defaultu. Option button bi ti radilo istu funkciju koju možeš postići i testiranjem polja VrstaDokumenta. Nema potrebe da dva puta specificiraš vrstu dokumenta.

"jos ne znam one stavke dokumenta kako da odradim, da bude zajednicko za sve dokumente"

Prvo popiši sva polja koja vidiš na svim papirnim dokumentima i slobodno ih dodaj u tabele i u formu. Kasnije testiranjem polja Vrsta dokumenta na događaj OnExit ili Before Update sakrivaš nepotrebna polja.






_{[Ovu poruku je menjao Getsbi dana 09.10.2007. u 12:28 GMT+1]}

Evo kako dokumenta izgledaju...

Koliko ja vidim svi su skoro jednoobrazni. Dodaj u tabelu StavkeDokumentTab: ProdctNumber, SerialNumber i Note.

E sad ne znam koju šifru robe ti daješ, a koju zadržavaš. Šta je tu stara šifra ? Predpostavljam da je ovo ProductNumber u magacinu stara šifra.

productnumber = robaid
serialno nije od znacaja , primetio sam da ga slabo pisu,ali mozemo ga ostaviti kao opciju
note = opisrobe

sto ce reci mozda dodamo samo serialno, no to me nebrine nego ono ako si video dokumenta
primalac robe i krajnji korisnik....kako si to osmilio preko partnerId...
jer koliko sam svatio partnerId je primalac robe, a nemamo krajnji korisnik...
imamo ulogapartnera...ali nju si rekoa da je kao textbox gde pises kome ide roba
a ja sam mislio da umesto uloga partner bude nesto kao krajnjipartnerid gde je to firma koja preuzima robu...
da bi sve to izgledalo kao na dokumentima koje sam ti poslao....a i bila kasnije laksa pretraga po firmama
...
nebitno, samo ti meni nacrtaj to sto si mislio (ja sam ti umetnicka dusa,volim da crtam,a i preko crteza-izgleda forme,lakse cu shvatiti sta si planirao)

sto se tice sifara....tj.oznaka u magacinu(nalepnica) zaboravi to ...

Ako si skinuo fajl mdb_G2.zip od pre dva dana, a jesi video si da sam dodao tabelu UlogaPartneraTab. Pri unosu dokumenta napravi i za ovo polje Combo box, obzirom da će u toj tabeli biti par slogova: Klijent, Krajnji korisnik, Dobavljac, Kupac.... Tako će ti svaki slog u dokumentu imati i podatak šta je uloga tog partnera. Možeš i da promeniš tip kolone UlogaPartneraID da bude u obe kolone text tipa, a OpisUloge da izbaciš iz tabele UlogaPartneraTab. Ako ostane po starom u Query za izvor podataka nekog od izveštaja trebaće uvući i tabelu UlogaPartneraTab. U suprotnom dovoljno će biti i bez nje.
Kad je na izveštaju naziv vaše firme, onda to ne biraš iz podataka već je fiksno napisano kao Label. Kad je vaš ovek iz firme onda je RadnikId. Za izveštaj opet kao i gornjem slučaju koristiš query sa uvučenom tabelom DokumetTab i tabelom RadniciTab. Ne vidim ni u jednom dokumentu koje si zakačio za primer, potrebu za dva strana partnera. Svoju firmu ne računaj kao stranog partnera. Koristi direktan upis na izveštaj.
Nažalost nemam dobar alat za crtanje, a i jako malo vrmena da bih ti ovo opisano primenio u tvom primeru, pa se trudim da objsanim koliko god mogu jednostavnije. No ne polazi mi očigledno to baš najbolje za rukom.

evo bazice
nacrtao sam sta sam hteo reci... :)
kad izaberm mirkovic mirko iz parnterid i stavim primalac robe...

znam da je covek uzeo robu...ali za koga je uzeo...on je lik recimo iz dhl...ili nas covek koji ide da isporuci robu(serviser)...

Imaš dve mogućnosti:
1. Da ove iz DHL-a smatraš svoji radnicima i upišeš ih u tabelu radnici.
2. Da otvoriš novu kolonu u tabeli DokumentTbl i tabelu ServiseriTab koju ćeš da vežeš slično kao i RadniciTab.

mozemo li recimo ovako da umesto
partnerID stavimo liceID
i dodamo firmaID
koje ce i dalje biti povezane sa tabelama poslovnipartneritab,fizickolice,pravnolice i dalje preko union queryia

Može. Ali to je upravo ono što sam hteo da izbegnem. Dvostruka veza od PoslovniPartneriTab prema DokumentTab. Ovako kako sam ti predložio su bolje normalizovane tabele. U slučaju da hoćeš posebo, bolje da držiš samo PravnaLicaTab i FizickaLicaTab bez zajedničke tabele PoslovniPartneriTab.

ti znas bolje...uradicemo kako ti kazes..ali moraces da mi nacrtas inace...nece da valja.
mada..stvarno mi nekako lepse ovo odvojene tabele nepovezane s partnertab..lakse ga kapiram..

Ma uradi onda lakši način. Mnogo je važnije da ti bude jasno i da ga lakše održavaš nego da bude elegantno. Ja sam samo hteo da ti pokažem šta može. Sačuvaj jednu kopiju ovakve baze, pa kad malo sazri aplikacija možda ćeš prilikom sledeće revizije poželeti nešto takvo.

nemogu da nastavim dalje, jer ne znam kako si osmislio prijem i otprem robe,tj. kako to iz forme da se odradi
evo trenutne baze.

To sam ti napisao pre tri-četiri dana:

> Što se tiče unosa dokumenta moraćeš da napraviš dugme i ispod njega VBA kod koji će da ažurira slogove u magacinu dodajući ih ili brišući u zavisnosti od tipa dokumenta (Prijemnica ili Otpremnica). Pošto nema polje količina u magacinu jer se svaki primerak robe dodaje i oduzima pojedinačno, a roba prati kvalitativno a ne kvantitativno, tvom kodu za ažuriranje trebaće For Next petlja i brojač iniciran količinom u tabeli StavkeDokumentaTbl. " <

Dakle nakon unete jedne prijemnice (jedan slog zaglavlja i jedan ili više slogova stavki) pokrećeš Command Button (dugme) koje napraviš i VBA kod na događaj On Click tog dugmeta. VBA kod bi trebalo da radi punjenje magacina.

Ja inače mogu da ti pomognem savetima ali nemam vremena da pišem kod. Probaj da pokupiš sa foruma sav VBA kod gde se spominje ažuriranje tabela. To prouči i primeni na tvom primeru. Ako zapneš tokom pisanja u vezi neke sintakse ili neočekovane greške u izvršavanju, okači primer sa uputstvima gde i šta loše radi i nešto malo unetih podataka, tek da se može iztestirati, pa ću ja ili već neko da pomogne. Ovo "knjiženje" bi moglo da se uradi i pomoću query-ja. Pitanje je samo šta ti više leži SQL ili VBA.

ja sam to sve odradio u prvoj verziji ove baze koju sam poslao...
tabele i veze izmedju njih su iste i na ovoj i onoj staroj bazi...meni je pravilo problem brisanje podataka iz tabele..combo on change jer mi menja vrednost koju sam izabrao a promenjenoj ne vraca staru...multiply delete jer nevraca stanje u prethodno svim rekordima vec samo posljednjem...
sql over vba, vba over sql sve je jedno sta cemo koristiti, samo moras mi objasniti na primeru kako si mislio da
u otpremnicu ubacuje stavke...

ja sam imao combo (podatke je vukao iz queryja ok roba) i iz komba izaberem neki partno
onda preko afterupdate odradim updajte qerija a pre toga promenim stanje robe u pozajmljena
greska se javlja kad isti taj kombo promenim opet...jer ostavi stanje ove prve robe na pozajmljen i normalno novoj promeni na pozajmljen..pa sad u magacinu imam stanje robe pozajlmjen ali nigde nije otisla..
delete je isto problem ako si video sta sam pisao...

master problem je ustvari nacin upisa podatak i tu mi treba pomoc

Evo jedne teme gde je obrađeno ažuriranje tabela i prenos podataka iz jedne tabelu drugu po nekim kriterijumima.
http://www.elitesecurity.org/t267896-0#1625333

> samo moras mi objasniti na primeru kako si mislio da
u otpremnicu ubacuje stavke... <

Stavke otpremnice se ukucavaju kao i stavke drugih dokumenta. Onog momenta kad ih knjižiš petlja koja vrti stavke iz otpremnice briše pojedine stavke iz magacina ili im u još boljem slučaju dodeljuje oznaku za stanje "PRODATO", a kod pregleda se u tom slučaju vodi računa o stanju, to jest pozivaju se samo slogovi sa stanjem koje je potrebno u pregledu.
Na tebi je da odlučiš da li ćeš stavke u magacinu da brišeš ili da ažuriraž njihovo stanje. Ova druga varijanta je dobra i zbog tog što ostaje istorijat svega što je ikad ušlo u magacin.

nije to to...no nema veze cu se patim pa kolko uradim..

daklen patio sam se neko vreme ,...uradio neke izmene ali .... opet isto problem sa brisanjem rekorda i updatetom
nesto jet engine pravi problem ...ustvari verovatno ja pravim njemu probleme...ali on meni zadaje glavobolju,,,
ako moze ko da pogleda bazu i uputi na greske (po mogucstvu i njihova resenja) i objasni sto ovde neradi delete
tj. u subfrmDokumenit onDelete event zove updateStatus koji treba da promeni status robe i ako je roba nova(nema je ni u jednom dokumentu) da je obrise iz magacinTab...