[es] - Aplikacija u access-u, pitanja.

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

^{29.10.2007. u 20:10 - pre 200 meseci}

Citat:

1. Da li se ta forma pravi tako sto izaberem tabele racunZaglavlje i RacunStavke, pa se onda na combobox koji je naziv kupca postavi na dogadjaj afterupdate f-ja koja procita odgovarajuca polja iz tabele kupci na osnovu tog naziva (jedinstven je naravno) i analogno za artikle plus se na polje cena takodje na dogadjaj AfterUpdate postavi odgovarajuca f-ja (f-je mi nije problem da napisem tako da nemojte oko toga da se mucite)? Ili se pravi query na osnovu tih tabela pa ce on sam automatski da za izabrani naziv popuni odgovarajuca polja? (Ovo mi je uspelo kod subforme ali ne i u glavnoj formi). Ili se query pravi samo za izracunavanja, u ovom slucaju da se izracuna ukupna cena?
Mogu da napravim prvo resenje ali me ipak kopka da li je ovo preporuceno ovako da se radi u access-u?

U data setu koji je record source za formu frmRacunZaglavlje, imas polje KupacID. Postavi dva combo boxa na formu, cboKupacID i cboImeKupca. Oba neka imaju data source jednak KupacID.
U cboKupacID stavi record source samo "SELECT KupacID FROM KUpci".
U cboImeKupca, stavi row source "SELECT KupacID, ImeKupca FROM Kupci", Column Count=2, Column Widths: 0,3cm => nece ti se videti KupacID, nego nazivKupca, a kontrola ce u stvari da ima vrednost KupacID.
Kad promenis vrednost jednog kombo boxa, promenice ti se i drugi. Izaberes kupca po imenu => oba kombo boxa imace vrednost KupacID, cboKupacID ce prikazati KupacID, a cboImeKupca ce prikazati ime.

Kako da prikazes/kopiras relevantne vrednosti za kupca iz tabele tblKupci u tabelu tblZaglavljeRAcuna? Imas dve opcije, moze jedan ili druga, a mogu i obe odjednom (najbolje)

Prvi korak: treba ti after update za cboKupacID i cboImeKupca. Kod u oba eventa je isti - dodeljuje drugim kontrolama na formi vrednost iz tabele tblKupci. Ja najcesce koristim Dlookup, na primer
txtAdresa = Dlookup("Adresa","tblKupci","KUpacID=" & form!cboKupacID)
txtTelefon = Dlookup("Telefon","tblKupci","KUpacID=" & form!cboKupacID)
itd.

NA velikim tabelama Dlookup moze biti spor, pa ako ima desetak Dlookup-a, cela forma postaje spora. Onda mozes da otvoris rekordset koji ce ti vratiti sve trazene vrednosti u jednom cugu. Na primer

DIM db as DAO.Database
DIM rs AS DAO.recordset
SET db = currentdb
Set rs = db.openrecordset("SELECT Adresa, telefon, FROM tblKupci WHERE KupacID = " & me!cboKupacID
rs.movefirst
txtAdresa = rs!Adresa
txtTeleforn = rs!Telefon
itd...

Znaci, kad god izaberes kupca, sva relevantna polja na formi se odmah popune. Pozeljno je da ta polja budy read-only (Locked = Yes)

Drugi Korak: Treba ti i kod na Form Before_Update, da proveri da li se sve ovo desilo, pa ako nije, da pokusa da ponovi operaciju ili bar da spreci cuvanje rekorda.
Ako koristis bound formu subformu, ne treba ti nikakvo dugme za snimanje rekorda na glavnoj formi. Kad sa glavne forme predjes na subformu, rekord na glavnoj formi ce se automatski sacuvati. Novajlije to vole, jedna stvar manje da brinu. neki profesionalci vole da imaju vise kontrole nad snimanjem rekorda, pa zato bar na frominom Before Update izvrse sve potrebne konrole.

Drugi nacin je da nemas nista na After Update za kombo boxove, vec da sve uradis na forminom BeforeUpdate, sto se ne preporucuje. ako vec radis za nekog kupca, lepo je da vidis sta si izabrao.

Sto se tice dodavanja nepostojeceg kupca/dobavljaca u letu i to je veoma popularno, ali se meni ne svidja. Unos kupca u bazu podataka je suvise ozbiljna stvar da bi se tek tako na brzinu odradio dok ti stoji otvoren combo box na tamo nekoj formi. Ako kupac/dobavljac ne postoji u bazi, ostavi racun na stranu, ili zatvori formu. Unesi kupca kako treba (ima li neka interna kontrola, da li je kupac dobro unesen, da li se taj kupac/dobavljac mozda nalazi vec u tabeli pod pogresnim imenom i slicno) pa se vrati i razresi doticni racun.

Access je amlo fleksibilniji i aljkaviji nego VB kad se radi o unosu podataka (autmatsko snimanje bez pitanja i slicne stvari) Zato se puno paznje treba pokloniti back endu, jer Access aplikacija ne moze da ti cuva integritet podataka na nacin an koji to mozda moze VB. Zato je brzina nevidjena. Da dobijes aplikaciju koja izgleda kao da radi, to je ocas posla. D.da je utegnes (citaj: sprecis kojekakve Accessove automatizme i aljkavost) treba pet puta vise vremena. Otprilike, 20% vremena da napravis aplikaciju kojaje 80% kompletna i pouzdana. 80% vremena da je doteras do 100% kompletnosti i pouzdanosti.

Odgovor na temu

Neznanac_

Član broj: 149203
Poruke: 32
*.vdial.verat.net.

Profil

Re: Aplikacija u access-u, pitanja.

^{14.11.2007. u 23:58 - pre 200 meseci}

Probao sam da primenim savete ali mi neke stvari ne idu bas najbolje. Sad sam na brzinu napravio neku bazu koja moze da prikaze sta zelim da radim sa racunom. Nadam se da u brzini nisam napravio neku znacajnu gresku (vec vidim da mi se na racunu pojavljuje umesto naziva PIB klijenta ali to u realnom modelu nije tako pa zanemarite).
Dakle, zelim da izborom klijenta popunim odgovarajuca polja na racunu (to radim kodom na event before update). Sva ta polja (osim PDVBroj) se upisuju u tabelu racuna zbog eventualnih kasnijih izmena. PDVBroj nema potrebe da se pamti jer ne moze da bude menjan, ali zelim da se uvek vidi na racunu.
Valuta je nesto sto moze i na racunu da se menja i u zavisnosti od nje menja se drugi datum i to je (valjda) korektno odradjeno. Rabat takodje moze da se menja i u zavisnoti od njega treba da se menja vrednost u polju text22, sa predznakom “-“ i tu prijavljuje gresku, kao i na iznosima i izracunavanjima. Kod rabata bih zeleo da stoji i procenat, medjutim kad stavim da je text box tipa percent on rabat iz tabele pomnozi sa 100. Polje NekoIzracunavanje je neka vrednost koja se racuna po formuli koja u buducnosti moze da se izmeni i zato treba da se cuva na nivou racuna a ne stavke i u subformi ne treba da bude vidljivo (sluzi samo za izracunavanje).
Takodje mi treba Getsbi-jevo resenje da stavke racuna na svakom racunu pocinju od 1 pa na dalje na ovom konkretnom primeru.
I na kraju, trebalo bi iz ovog racuna generisati izvestaj koji ce se stampati.
Unapred (a i unazad za sve prethodno) zahvalan.

Prikačeni fajlovi

Primer.zip - 103.79k

Odgovor na temu

savkov
Igor Savkov
Vrsac

Član broj: 21550
Poruke: 94
77.46.217.*

+2 Profil

Re: Aplikacija u access-u, pitanja.

^{16.11.2007. u 22:39 - pre 200 meseci}

Mislim da fali jos jedna tabela gde bih odvojio adresu jer jedan kupac moze imati vise maloprodajnih objekata i isti pib i tekuce racune samo je mesto isporuke drugo.

Igor

Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2831

+45 Profil

Re: Aplikacija u access-u, pitanja.

^{17.11.2007. u 07:41 - pre 200 meseci}

@ Neznanac
Pošto si me prozvao za rešenje da se stavke povećavaju za jedan u okviru broja računa moram da opravdam tvrdnju. U tvom slučaju rešenje bi izgledalo ovako:

Polje BrStavke zaključaj stavivši osobinu Locked na Yes. U događaj podforme Before Update

Postavi kod:
Me![BrStavke] = Nz(DMax("[BrStavke]", "StavkeRacuna", "[BrojRacuna]=FORM.[BrojRacuna]"), 0)+ 1

Sve drugo u na brzinu napravljenom primeru ne mogu da ispravljam, a razloge ću izneti u daljem tekstu. Dakle da krenem redom od tabela. Savkov je u pravu što se tiče kupaca. Oni mogu imati više objekata i roba ide na adresu objekta. Da li račun ide na adresu objekta ili na adresu sedišta firme je diskutabilno. Pre bih rekao da robu prati otpremnica i da kupac na osnovu nje radi kalkulaciju za svaki objekat, a da račun može stići i naknadno ali na adresu sedišta kupca. Međutim i da usvojimo do kraja tvrdnju Savkova ne preporučujem ti da komplikuješ model u ovom trenutku dodatnom tabelom bar dok ga ne dovedeš u red. Moguće je da imaš i širi model, a nama si ovde prezentovao neki na brzinu urađeni sa toliko grešaka u formama i sa očekivanjem da to ispravimo posle onako iscrpnih odgovora još od letos na tvoja pitanja.

Zato ću se ovog puta zadržati samo na modelu podataka.

1. Rabat je deo svake stavke i tu kolonu treba premestiti iz zaglavlja u stavke jer se može davati različiti rabat za različitu robu i naručenu količinu.
2. Kolone Adresa i NazivKlijenta treba izbaciti iz tabele zaglavlja jer je u pitanju redudanca podataka. Imaš ih već u tabeli Klijent. Dovoljan je prenešeni ključ PIB, a na formi se mogu videti podaci koji ne moraju biti upisivani u tabelu. Ovi podaci su ti potrebni tek kod štampanja dokumenta.
3. Polje NekoIzračunavanje ne bih da komentarišem.

4. Održavanje rabata u tabeli Klijent je takođe diskutabilno iz tvrdnji koje sam napisao u tački 1.
5. Valuta u tabeli Klijent je takođe nepotrebna po momo mišljenju jer te ona obavezuje da ti kupac ili uvek ima istu valutu (20 dana od isporuke) ili ćeš morati da praviš tabelu istorijata. Nevidim kako ćeš da naknadno odštampaš ispravno račun br. 3 sa valutom od 20 dana ako si je u međuvremenu promenio valutu na 15 dana pri izradi računa br. 8. To je promenljiva kategorija po meni i treba da ostane samo u zaglavlju dokumenta jer je njegov deo i daje se za svaki račun.
6. U tabeli StavkeRacuna nema potrebe držati NazivProizvoda jer ga već ima u roditeljskoj tabeli Proizvod. Dovoljan je preneseni ključ ProizvodID. Ovo je takođe redundabca (suvišnost) podataka.

Savetujem ti da kreneš od ovih primedbi, prepraviš model i da probleme pri izradi formi izlažeš jedan po jedan, kako nailaziš na njih, a ne nagomilano. Uzgred polja koja si postavio na glavnoj formi, a za Control Source imaju vrednosti sa podforme ne mogu da se prikazjuju kontinualno ili sam ja loše shvatio ideju. U svakom slučaju polja u Futeru podforme su nepotrebna. Treba upotrebljavati referenciranje i funkciju Sum() da bi se video ukupan izos svih stavki sa podforme na glavnoj formi.

_{[Ovu poruku je menjao Getsbi dana 17.11.2007. u 09:19 GMT+1]}

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Odgovor na temu

Neznanac_

Član broj: 149203
Poruke: 32
*.vdial.verat.net.

Profil

Re: Aplikacija u access-u, pitanja.

^{19.11.2007. u 21:00 - pre 200 meseci}

Getsbi, nisam te prozvao, samo nisam umeo da implementiram resenje koje si mi ponudio jer sam negde gresio. Sad kad si video konkretan primer i napisao kod on radi! Hvala.
Sto se tice modela, on je pravljen po zahtevu ma kako neuobicajen bio pa evo i objasnjenja po stavkama:

1. Na racunu i na otpremnici treba da stoji adresa sedista kupca, bez obzira na koji maloprodajni objekat se upucuje pa zato nema potrebe za posebnom tabelom.
2. Rabat moze da postoji iskljucivo na nivou racuna a ne moze se desiti da na jednom racunu bude vise razlicitih rabata za razlicite proizvode.
3. O redudansi i istoriji smo pricali na pocetku, pa posto adresa i naziv klijenta mogu da se promene a potrebno je da na racunu uvek bude adresa i naziv koji je bio kad je izdavan ne moze da se veze za tabelu kupca.
4. NekoIzracunavanje je navedeno kao primer jer ce biti izracunavanja koja ce zavisiti od cene i koje kao takvo treba da se pojavi na racunu.
5. Valuta u tabeli kupac treba da postoji jer kupac ima fiksnu valutu, koju dobije kad se unosi u bazu (da se ne bi pamtila, jer je to stvar dogovora prodavca i kupca). Ta valuta se prenosi na racun i samo u pojedinacnim slucajevima se menja (kad kupac kupuje vise/manje robe) i zato treba da se cuva i u tabeli racun i kad stampam racun br.3 procitacu valutu koja je upisana u tabeli racun a ne kupac a isto vazi i za racun br.8.
6. Isto sto vazi za valutu, vazi i za rabat (kupac ima fiskni rabat koji se u pojedinacnom slucaju menja).

Kad je u pitanju suma sa podforme na formi na forumu sam naisao na primer da je prvo sumirano u footer-u subforme pa preneseno na glavnu formu, meni je to cak jednom proradilo ali posle toga javlja gresku.

Ovde sam probleme postavljao pojedinacno i dobijao detaljna uputstva ali nekada nisu resavala problem jer verovatno nisam dobro postavljao pitanje. Zato sam i poslao primer, da lakse uocite kakve probleme imam sa formom racun posto deluje da fale neki detalji koje mogu samo iskusni access programeri da primete.

Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2831

+45 Profil

Re: Aplikacija u access-u, pitanja.

^{20.11.2007. u 12:36 - pre 200 meseci}

Evo zakačio sam ispravljen primer. Morao sam da ga preradim jer mi nešto sa fajlom nije bilo u redu. Importovao sam tabele u prazan .mdb i ispoštovao sva tvoja poslovna pravila. Ono za adresu sedišta kupca sam i ja tvrdio opovrgavajući potrebu za dodatnom tabelom. Sa načinom vođenja rabata se ne slažem, ali bože moj. Da bi sračunao rabat za račun, ceo račun mora da bude gotov. Moglo bi na neko dugme na formi, nakon završetka unosa podataka, ali je najbolje da se taj podatak sračuna na iveštaju uz iznos za uplatu. Znači svega manje rabat jednako svega za uplatu. Naravno ostaje da se i porez ukalkuliše ukoliko je potrebno.

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

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Prikačeni fajlovi

Primer_G.zip - 48.75k

Odgovor na temu

Neznanac_

Član broj: 149203
Poruke: 32
*.vdial.verat.net.

Profil

Re: Aplikacija u access-u, pitanja.

^{20.11.2007. u 20:49 - pre 200 meseci}

Getsbi, hvala sto si se potrudio oko primera, da shvatis pre svega model pa sad mogu da postavljam, nadam se jasnije pitanja.
Koliko vidim, ti si u ovom primeru uradio sledece:
1. Postavio si kod tako da se redni broj stavke generise automatski i ide od 1 pa na vise kako sam i trazio i kako si mi vec objasnjavao.
2. Postavio si da je i PIB polje combobox, pa se moze i po njemu birati kupac sto je odlicno. Da li si to uradio nakon wizarda, promenivsi textbox u combobox?
3. Izracunao si uspesno ukupno sumu svih proizvoda.
Medjutim, sad se u podformi ne pojavljuje suma na nivou proizvoda i na izbor ProizvodID se ne popunjavaju ostala polja kao u prvobitnom primeru. Posto sam ovo vec radio, nije mi problem da dodam.

Takodje, ne dozvoljava mi da kreiram 2 racuna sa istim kupcem a razlicitim brojem racuna koji je primarni kljuc racuna??
Moja ideja za rabat je bila da posto on zavisi od ukupne sume, da kako se ona menja izborom svakog sledeceg proizvoda i kolicine tako se i rabat menja jer zavisi od nje.
Ono sto nije reseno je:
1. Kad kreiram racun i izaberem kupca on korektno popuni PDVBroj. Ali kad predjem na sledeci racun on u tom polju drzi PDVBroj prethodnog, na izbor kupca postavi odgovarajuci, ali povratkom na prethodni racun on cuva PDVBroj poslednje izabranog kupca
2. Kako da popunim polje NekoIzracunavanje, koje moze biti neki dodatni porez npr. i izracunava se po odredjenoj formuli u zavisnosti od cene i koje mi je potrebno da se vidi na nivou racuna a predstavlja sumu na nivou proizvoda (ali ne smije da bude vidljivo na nivou podforme)? Sta ako se ta formula vremenom menja, da li mora da se ulazi opet u kod?
3. Kako se iz ovog racuna pravi izvestaj, da li se pravi query?

Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2831

+45 Profil

Re: Aplikacija u access-u, pitanja.

^{20.11.2007. u 21:37 - pre 200 meseci}

Combo Box za PIB sam napravio ručno, mada nisam siguran da je pametno jer iovako koristim tvoj kod ispod događaja “NazivKlijenta_BeforeUpdate“, što si verovatno primetio. Nisam stigao sve da dodam kako je bilo. Probaj sam. Vodi računa kod pisanja jer neispravna imena kontrola i referenci su najčešći uzročnik greške tipa: # Error kao rezultata u polju.

Što se tiče ključa. Pokidaj vezu u RelationSheeps, obriši podatke u tabelama zaglavlja i staveki, promeni BrojRacuna u LongInteger u obe tabele kao i Broj Stavke takođe u LongInteger u tabeli stavki. Tad ponovo uspostavi vezi. Nisam imao vremena da unosim podatke pa otuda i ne valja.
Loša varijanta je da kombinacija ključa bude razlišitih tipova. Ako ti baš treba neki broj računa tekstualnog tipa bolje je da dodaš posebno polje i nazoveš ga recimo InterniBroj ili tako nekako, a da ne bude deo ključa.

Ostatak ću da pogledam sutra.

Nije ni ovo pomoglo sa promenom tipa podatka u ključu. Sutra ću pogledati.
Proradilo je. Pošto sam iskopirao tvoje tabele, preneo sam i redosled indeksa koji je pogrešno postavljen, tako da je to smetalo. U svakom slučaju bolje je da PK budu Numerici, a da ti dodaš neki interni broj ako je to potrebno.

Evo zakačio sam. Odgovori mi u vezi Primarnog ključa i tipa podatka za Broj računa.

_{[Ovu poruku je menjao Getsbi dana 20.11.2007. u 23:02 GMT+1]}

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Prikačeni fajlovi

Primer_G2.zip - 50.97k

Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2831

+45 Profil

Re: Aplikacija u access-u, pitanja.

^{21.11.2007. u 15:49 - pre 199 meseci}

Otkud ovo: $#.##0,00;($#.##0,00) u Format polja u tabelama i formama, kad postoji limitirana lista : General, Currency, Fixed, Standard,.........
Prepravio sam malo tipove podataka i formate.
Dao sam ti primere za nekoliko sumiranja i prenošenja sa podforme na formu.
Pogledaj šta se piše u Control Source kontrole koje sumiraju u podformi i one koje prezentuju sumirano na glavnoj formi.
Pitanje : “ Sta ako se ta formula vremenom menja, da li mora da se ulazi opet u kod?”
Ako je formula u kodu mora se ispraviti kod. Ako je formula na kontroli mora se ispraviti Control Source kontrole.
Ne vidim razlog da se petljaš sa PDVbroj na frmi. Kad budeš štampao izveštaj automatski ćeš povući i PDVbroj iz tabele Klijent. Ovo nema raloga da se vidi na formi za unos i ažuriranje. Ako baš mora napravićemo i to.
Pitanje “ Kako se iz ovog racuna pravi izvestaj, da li se pravi query?”
Da. Prvo napravi query sa svim potrebnim tabelama, a onda query uzmi za Record Source izveštaja.

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Prikačeni fajlovi

Primer_G4.zip - 66.8k

Odgovor na temu