Napravio sam malu bazu koja radi prodaju proizvoda, ali imam problem da kada mi se cene promene u tabeli Proizvod dešava mi se da se u svim već napravljenim računima promene najnovije cene.
Kako da mi račun pamti stare cene, a tekuće poslove radim sa novim cenama?
Unapred hvala svima koji imaju neki dobar predlog u vezi mog problema!
-----------

Ovo nije jednostavno napraviti jer kako kažeš da si početnik. Evo šta treba da uradiš:

Razdvoj tabelu sa proizvodima u dve tabele. U jednoj zadrži sve podatke osim cene, a u drugoj postavi šifru (ID) proizvoda, cenu i datum. Napravi relaciju jedan ka više, tako da za jedan proizvod možeš upisati više podataka o ceni. U drugoj tabeli upiši ID proizvoda, cenu i datum od kad važi cena. U daljim proračunima svuda moraš uvesti filter na kriterijum cene prema datumu transakcije.

Prodajna cijena je u tabeli artikli a cijena po kojoj je prodato ili kupljeno je u tabeli promjene, a dali je prodato ili kupljeno odreduje se poljem vrsta promjene
Sretan rad

Ne razumem kako da uradim ovo (uvodjenje filtera na kriterijum cene prema datumu transakcije), molim te daj mi primer!

Daj ljudi sto komplikujete.

Prvo treba da imas 2 tabele:

Prva tabela je tabela Artikli (ili Proizvodi), koja sadrzi bazu artikala sa sve njihovim trenutnim cenama, poreskim stopama, zalihama.

Druga je tabela racuna i sadrzi:
Broj racuna, Artikl (sa relacijom ka bazi Artikli), Prodatu kolicinu itd.

Problem je sto ova druga tabela mora da ima jos ona polja koja mogu da se promene u toku godine kao sto je npr. CENA. Kada prodajes artikl, pored prodate kolicine, upises i trenutnu cenu (a ne da je vuces iz baze artikala). Preporucio bih ti da dodas u ovu bazu i polje porez, koji isto pamtis (nadam se da ovo vise nece trebati, ali do sada je itekako trebalo posto se porez artikla menjao kako je kome dunulo).

Ovo ti je za pocetak najlaksi nacin. Baza ce biti malo veca, ali boze moj i diskovi su jeftini.

Pozdrav

Ova tema će ti možda pomoći

http://www.elitesecurity.org/tema/83644/0#533472

imaš primjer koji sam ja uradio uz ovu temu pa pogledaj

Problem je sto ova druga tabela mora da ima jos ona polja koja mogu da se promene u toku godine kao sto je npr. CENA. Kada prodajes artikl, pored prodate kolicine, upises i trenutnu cenu (a ne da je vuces iz baze artikala). Preporucio bih ti da dodas u ovu bazu i polje porez, koji isto pamtis (nadam se da ovo vise nece trebati, ali do sada je itekako trebalo posto se porez artikla menjao kako je kome dunulo).

Ovo ti je za pocetak najlaksi nacin. Baza ce biti malo veca, ali boze moj i diskovi su jeftini.
-------

Jeste, ali tako odstupa od pravila normalizacije i odmah u početku uči naopako - kako ne treba raditi. Osnovno pravilo je da jedan isti podatak ne sme da se ponavlja i unosi više puta. Nije stvar do veličine baze, one su odavno mnooogo manje nego što staje na disk.

Cekaj, cekaj. Naravno da nece unositi one podatke koji ostaju uvek isti. Na primer: Jedinica mere, Naziv artikla, sifra, Transportno pakovanje itd. da ne nabrajam, to sve ce na osnovu ID (artikla), i ako mu treba da uzme iz baze artikala.

E sad ono sto mi nije jasno: Reci mi samo jedan jedini dobar razlog sto ne bi tabela racuna imala ova 3 polja: ID atrikla, Prodatu kolicinu, Cenu. I zasto ne sme da ima cenu po kojoj je tada artikl prodat.

Evo, samo jedan dobar razlog i prihvaticu kritiku.

Mislim da je unosenje cene svaki put pri prodaji nekog proizvoda neprakticno!
I treba naci nacin kako da se izvede to da se povlace uvek najnovije cene preoizvoda!

Mislim da ovo sto kaze Banem ne stoji. Cena u tabeli artikli se menja, a cena u atbeli ProdatiArtikli NE SME da se menja. Prema tome to su dva razlicita podatka po svojoj prirodi i moraju da se tretiraju razlicito. Ono sto zbunjuje ljude jeste nacin generisanja cene u tabeli ProdatiArtikli. Generalno, vrednost ProdataRoba.Cena se dobija kopiranjem vrednosti Artikli.Cena. To je jedini trenutak kad su ta dva podatka ista. Cena u tabeli Artikli moze se promeniti u bilo kom momentu, ali to nece i ne sme da utice na zapis u tabeli ProdataRoba.

Kako izbeci KUCANJE cene svaki put kad se proda roba? Upotrebite AfrerUpdate event za kontrolu ArtiklID. Verovatno imate formu u koju se unose prodati artikli. Cesto je ovo subforma na nekoj glavnoj formi. Verovatno imate combob box iz koga birate artikle. Taj kombo box ima ima dataSource=ProdataRoba.ArtiklID, a source za pop-down listu je nesto kao "SELECT ArtiklID,Opis,Cena FROM Artikli". Takodje imate polje na formi(subformi) gde se cuva ProdataRoba.Cena. Treba na AfterUpdate za combo box staviti otprilike ovakav kod:

sub cboArtklID_AfterUpdate()

me!Cena=me.cboArtiklID.Column(2)

end sub

I to je sve. Izaberete robu => cena se prepise iz tabele Artikli. Onda mozete da je promenite ako hocete. Uglavnom se ova promena nece desiti, osim ako ne odlucite da judima date popust iz nekog razloga, ili im povecate cenu iz nekog razloga.

Kod koji sam dao je samo ideja, kucao sam direktno u poruku, pa nemojte da Cut/Paste, probajte sami na vasem slucaju.

@draki
A kako mislis da obracunas porez naprimer za robu koju si pre nekog vremena (pre jednog meseca) prodao za 1din i treba da platis 20 para poreza na to.
Juce je doslo do poskupljenja i sada ta roba vredi 1000din po komadu, pa ti porez iznosi 200din za 1kom. ako ti se placa, ti placaj 200din za porez na robu koju si prodao za 1din (posto po tvojoj teoriji treba da stoji uvek najnovija cena).
Mozes da platis 200din za porez i 100.000+ za varanje drzave.

Ovo je primer pre uvodjenja PDV-a. Ja sam preuvelicao brojke da bi bilo malo jasnije.

@zidar (1.pasus)
Tako je

Da li moze neko da mi pokaze kako da odradim ovo isto sa ali sa stopama PDV-a da mi se u slucaju promene neke stope za neke artikle ne promene stope na artiklima koji su vec prodati!
HVALA!

Pa stavi i stopu PDV u tabelu ProdataRoba i kopiraj je iz tabele Artikli na isti nacin, u istoj proceduri. Treba ti samo jos jedna funkcija da odradi kopiranje.

Jel problem da mi napises postupak ovog procesa, nisam bas najbolje shvatio kako se radi to kopiranje!
NIJE MI JASNO STA U ACCESSU ZNAPOJAM KOPIRANJE!
Pogledajte gore sto sam zakacio primer, pa mi pomognite da ga resim!
Isto sto je uradjeno sa cenom zelim da uradim i sa stopom PDV-a!
HVALA!

Evo ti draki ono sa PDV-om i pogledaj malo kod iza sub forme

Evo
Sretan rad

Na njemu fali samo izdvojenost po stopama za osnovicu i vrednost pdv-a (na ovom primeru na slici nema proizvoda po stopi od 8%, ali su meni potrebne obe stope).
HVALA!

evo
Sretan rad

Evo sad valjda je ono sto trazis.
Prvi put sam uradio po tvojoj Skici.
Pozdrav

Tek sam poceo sa Access-om i pretpostavljam da mesam babe i zabe kad ovo pitam:

Ako radimo sa 2 tabele: Proizvodi (sadrzi podatke sa sve cenama) i Racuni (takodje sadrzi cenu), gde je relacija Proizvodi->Racuni, tipa One-To-Many, zasto ne bismo mogli da postavimo lookup relaciju u tabelu Racuni, koja bi vukla cenu iz tabele Proizvodi. Pri tome bi opcija "limit to list" bila "No", dok na "enforce referential entegrity" ne bi bila potvrdjena polja za Cascade. Da li bi se na taj nacin dozvolilo korisniku da unese cenu razlicitu od one koja se nalazi u tabeli Proizvodi, ako se ima u vidu da je "limit to list" u tabeli Racuni "No"? Da li bi se ovako izbeglo da se nove cene automatski ubacuju u stare racune, s obzirom da nema "Cascade"?

Da li se pored toga, moze u formi za unos u Racune, u polju cene, postaviti combo koji ce na OnNotInList izbaciti msg koja upozorava da smo uneli cenu koje nema u tabeli Proizvodi i da bi stoga trebalo da korigujemo cenu u tabeli Proizvodi? Tako bi cena u tabeli Proizvodi bila uvek ona najnovija.

Pretpostavljam da ovde nesto debelo ne stima, inace bi ste se vi ovoga pre setili.

Pozdrav!

Neznam resenje reporta Faktura!

Ovako:

1) izbaci parameters iz kverija queFakturaDetalji. Ovo nema veze sa dizajnom reporta ali olaksava rad kasnije.

2) tvoj report treba da se bazira na queFakturaDetalji i tu si OK

3) report treba da ima dva grupisanja: prvo po SifraFakture, a onda po PDVP. trenutno, imas samo PDVP. U oba grupisanja, treba da imas Section header i Section Footer

4) U Sifrafakture header stavis ono sto je u tvom trenutnom reportu u ReportHeader
ReportHeader se stampa tacno jedamput za ceo report, i u tvom slucaju ce da prikaze samo prvu fakturu

5) U SifraFakture footer stavis ForceNewpage="After Section". Ovo ce da ti svaku fakturu zapocne na novoj starnici.

6) U PDVP header stavi vrednost PDVP, da se zna da slede artikli koji imaju odredjeni PDVP. Nista ne smeta da u footer stavis PDVP ponovo. Tvoj trenutni footer za PDVP je OK.

7) Onaj deo sto si stavio u ReportFooter, gde listas Mleko, Jogurt i Probiotik ne valja nista. Sve je hard kodirano, i pojavice se i gde treba i gde ne treba. Drugo, sta ces kad se pojavi nova roba koja treba da se doda na tu listu? Ovo nije problem reporta nego nepotpunog dizajna baze, ali to je posebna tema. Informacija o ambalazi treba da se cuva negde u bazi, pa se onda ovde prikaze iz kverija. zavisno od uslova (koje ja ne znam, ti ih znas) ovde moze da dodje ili subreport ili jos jedan nivo grupisanja, a mozda i kombinacija. U svakom slucaju, prvo mora da se resi na nivou dizajna baze podataka, pa tek onda da se unese u report.

8) Prikazes fakture (otvoris report) samo za izabranog kupca, i to samo neke od njegovih faktura, u zadatom opsegu? Moras da napravis formu, koja ce da od korisnika uzme podatke: koji kupac, od fakture do fakture. Onda se to kroz DoCmd.OpenReport i WhereCondition posalje da se izvrsava. Vidi top temu "Primer jednostavne aplikacije Prihodi/Rashodi". Svrha te teme nije bila da se ponudi aplikacija za prihode i rashode, nego da se pokaze kakao se upravlja reportima, a to je ono sto tebi treba.

Imam sada problem!
Mislim da nije tezak, ali ja ne znam u cemu je stos!
Na fakturi u reportu zelim da mi idu redom redni brojevi stavki prodatih artikala?
Sada idu redom ti brojevi ali nastavljaju se na sledecem reportu!
HVALA!

U reportu imas text box Rb, source data =1. Stavio si Running sum = "Over All". treba "Over Group" i startovace sa 1 za svaku poresku grupu. Da li ti to odgovara?

To se dešava kada izabereš da ti prikazuje više fakturi u reportu npr. od 1 do 10 recimo, i zato što je u propertisu Rb „Running Sum“ postavljen na Over All i onda on sabira sve, kada izabereš samo jednu fakturu recimo od 2 do 2 Rb je sasvim u redu, Rb možeš staviti Running Sum na Over Group ali onda će ti u izvještaju redom brojati po jednoj stopi PDV pa onda ponovo po drugoj što znači prema grupi a kod tebe je grupirano po stopi PDV-a, što imaš slučaj u svojoj prvoj fakturi.
Ja to vidim ovako kada se faktura napravi ili se pozicionira na određenu fakturu u Formi, treba klikom na neko dugme da se ispisuje ta faktura i u tom slučaju Criteria, tj ono Between [PRVI RAČUN] And [ZADNJI RAČUN] u queFakturaDetalji ti ne valja – trebalo bi ovo staviti [Forms]![Fakturisanje]![SifraFakture] i napraviti jedno Command Button na formi Fakturisanje koje poziva taj Izvještaj. Pogledaj primjer
Nevidim razlog zašto bi ti trebalo da od jedanput ispisuješ VIŠE faktura. Ako ti treba mjesečni izvještaj prodaje ili za neki drugi vremenski period ili po kupcima onda valja napraviti drugi izvještaj na bazi nekog drugog Upita.

Evo brži je Zidar

Ako zelis da ti se redni broj nastavlja iamedju dve PDV grupe na istoj fakturi, onda kreiraj novu kontrolu txtRowCounter u sekciji Detalj (umesto Rb) i ubaci ovaj kod u report modul:

Neznam da odradim da mi izgleda ovako kartica za kupca! S jedne strane zaduzenje koje se automatski prenosi pri izradi racuna kada kupac kupuje robu i uplate po racunu kada se to proknjizi u tabeli tblUplate sa izvoda iz banke koji se dobija svakodnevno!
HVALA!

Na ovoj bazi bi trebalo to odraditi ako moze uopste ovako kako su tabele postavljenje!
HVALA!
POZDRAV!

Pretvori fajl u ZIP, nemogu da koristim RAR

Da li moze neko da mi pomogne, ne znam kako da resim iz ovih mojih tabela da izvucem karticu za kupce!
Gore sam zakacio fajl kartica.doc (kako bi trebalo da izgleda) i faktura02.05.05.zip!
HVALA!

DB schema ti je OK u principu. Tabela tblUplate mora da se doda. Ja sam je dodao tako da je povezana sa tabelom tblFaktura. Posledice ovakve veze su:
1) svaka uplata mora da se odnosi na tacno odredjenu fkturu.
2) Moguce je imati vise od jedne uplate po fakturi.
3) Nije moguce imati vise fakttura na jednoj uplati

Ostavi ovako ako ti odgovara. Ako je oguce da na jednoj uplati imas vise faktura, ond atreba malo drugacije. TblUplate, pa tblUplateDetalji, pa se tblUplate veze za tablKupci, a tblUplateDetalji sa jedne strane na tblUplate a sa druge na tblFaktura.

Dodao sam ti PK u tabelu tblFakturaDetalji, PK = (Sifrafakture,SifrArtikla). Ako je ovo OK, posledice su:
1) Svaki artikl se na jednoj fakturi moze pojaviti samo jednom

Ne znam kako racunas fakturisanu cenu, pa sam koristio tvoj kveri queFakturaDetalji i uradio qryKarticaKupca_Fakture. iz njega se dobija qryKarticaKupca_Fakture_SUM, a iz njega _Q_Fakture. Napravio sam i qryKarticaKupca_Uplate, razumeces ga bez problema, a od njega sam napravio _Q_Uplate. Kad se stave zajedno _Q_Uplate i _Q_Fakture, operacijom UNION, dobije se
_Q_UNION. Na _Q_UNION se doda tabela tblKupci i dobije se qryKarticaKupca, koji je osnova za report.

U Kartici kupca, pretpostavio sam da je "Broj racuna po kome se zaduzuje" isto sto i "Broj racuna po kome se uplacuje" a to je opet isto sto i "Sifra Fakture". Stoga sam izbacio jedno polje iz kartice.

Treba da promenis vrednosti Datum u tabeli Faktture, imas minute i sekunde sto nije dobro. traba da ostanu samo datumi. Verovatno si korstio funkciju Now() umesto Date() da uneses datum u to polje.

Sad razumes zasto mi je trebalo neko vreme da ssatavim odgovor.

Kako da uradim komandu UNION ako imam tri querija pa zelim da ih spojim, kako da napisem taj kod?
Neznam da napisem pravilno, gresim u sintaksi!
HVALA!

Pre svega, ako hoćeš da unijama spojiš rezultate dva query-ja, treba da vodiš računa da ta dva query-ja vraćaju isti broj kolona koje su istog tipa. NPR:





Dakle, radiš spajanje tabela i dobiješ rezultat koji ima toliko redova kao zbir redova koji daju pojedinačni query-ji.



As simple as that. Ain't it?

Ja hocu da spojim tri querija, ali ne znam kako u tom slucaju da koristim komandu UNION?

Zakaci tabele

UNION mora da se kuca u SQL prozoru. Sve kako je Mika rekao, moraju da se slazu polja broju, tipu i polozaju.

Primer:

SELECT RacunID, DatumRacuna, SumaRacuna FROM qryRacuni
UNION
SELECT FakturaID, DatmFakture, SumaFakture FROM qryFakture
UNION
SELECT PrijemnicaID, DatumPrijema, UkupnoPrimljeno FROM qryPrijemnice

Polja RacunID, fakturaID, PrijemnicaID moraju da budu istog tipa. Ako nisu, korsiti konverzione funkcije da ih napravis da budu istog tipa, barem u kveriju

isto vazi za Datum*, kao i za (Sumaracuna, SumaFakture, UkupnoPrimljeno)

Moras da otkucas SQL izkaz korektno. Probaj pa ce iz petog puta da uspe, a mozda i pre.

:-)

Evo postavio sam primer, ja ne znam kako da resim ovaj UNION, pa ako neko moze da mi resi!
Treba da se napravi UNION od
_Q_ZaduzenjePoKalkulacijamaZaKepu,
_Q_RazduzenjePoFakturamaZaKepu,
_Q_UplateZaKepu.

_Q_UplateZaKepu je samo iskopiran od qryUplate, mozda to i nije potrebno!
Ja sam se skroz upetljao u ovo i sada mi bas nije jasno kako da resim!
HVALA!

Formalno gledano, tri kverija koja si naveo ne mogu da se povezu u UNION. Razlog; _Q_UplateZaKepu nema isti broj kolona kao druga dva kverija. Sav tri moraju da imaju siti broj kolona, makar u nekim kverijima kolon bile lazne. Drugi uslov je da su kolone koje ce se unionizovati na istim pozicijama. Ako je kolona Zaduzenje, i ona je sedma s leva u kveriju _QRazduzenjePoFakturamaZaKepu, onda mora postojati kolona Zaduzenej u druga dva kverija, na poziciji 'sedma s leva'.

Nesto drugo me brine. Kad si prvi put postavio pitanje, resenje je zahtevalo samo dva kverija. Otkud sad tri? Da li jos uvek govorimo o istom reportu, 'Kartica Kupca' ili je nesto drugo u pitanju? Da ne pokusavas da primenis UNION n nesto drugo, gde mozda UNION uopste ne treba?

Objasni nam sta hoces, sa knjigovodstvene tacke gledista. Zaboravi na Access i kverije, kazi nam sta hoces da pokazes na reportu. opisi svoj 'business case'.

Pokusao sam da ti uradim union ali tamo nisam nasao srodnih polja sem datuma.
Da malo pojasnim kako se radi union.
CELECT PrvoPolje,DrugoPoljr,TrecePolje
From Imeebele
UNION SELECT Prvopolje,DrugoPolje,TecePolje
From ImeTabele
UNION SELECT PrvoPolje,DrugoPolje,TrecePolje
FROM ImeTabele

Unon nece raditi ako ne odaberes isti broj polja iz svake tabele.
Ako pak nema polja onda se moze upisati prazan strin ovako "" ili pak neki broj ako je polje brojcano.

Bez obzira da li ovo napravio, tesko da ce ti radit.
Union naime radi veoma sporo i treba ga izbjegavati a pored toga ti ga pravis iz nekih queria i za tabele koje ce imati po nekoliko desetina hiljada redova.

Mislim da neces uspjeti ovo izgurati na ovaj nacin.
Ja sam negdje bio postavio tabele za fakture ulaz izlaz na forum.
Ovo tvoje tabele nisu dobre nitisu dobro relaciono vezane.
Dobavljace si vezao za artikle umjesto za fakture kao sto si to uradio za kupce.
Jos nesto tu je dovoljna jedna tabela a stavis polje opcija pa primjera radi dobavljaci su ti br1 kupci br2.
Isto vazi za ulazne racune i fakture.
Da si tako odradio sad ti nebi trebao union. a imao bi i manje tabela.
Jos nesto sam primijetio da imena polja pises iz dvije rijeci.
To nije dobro u ostalom si sam primijetio kada si pravio union a u kodu se moze jos vise osvetiti.
Ako se odlucis za promjenu spreman sam pomoci.
Pozdrav

Sto se tice onoga sa dva querija to smo otprilike zavrsili – mozda jos neke finese, ali otom potom, ali mi sada treba report koji se zove KEPU knjiga a izgleda ovako!

Evo jos jednom sam postavio malo izmenjenu aplikaciju sa zavrsenom qryKalkulacija.
HVALA SVIMA KOJI MI POMAZU DA RESIM OVU APLIKACIJU!

Nije mi opet sve najjasnije, sta je sta, ali generalni problem je da se sastavi OpisKnjizenja, posto nije ista struktura u rekordima 1,2,3 koje si dao u Word dokumentu.

probaj ovako nesto:

Ovo ti daje tacno 5 kolona. verovatno nisam dobro iskomponovao OpisKnjizenja, ali to ces sam bolje znati.
Napravi ovakva TRI kverija, svaki da imapolja koja se zovu (DatumKnjizenja, OpisKnjizenja, Zaduzenje, Razduzenje, Uplate) i snimi ih pod raznim imenima, na primer
qryKEPU_Kalkulacija,
qryKEPU_Fakture,
qryKEPU_Uplate.
Onda napravis novi kveri, qryKEPU_UNION ovako:


Ono 1,2,3 na reportu postigens tako sto u detail sekciji stavis unbound text box i kazes da mu je RecordSource =1 pa u Property RunningSum stavis "Over All". Onda se da ti se pojave 1,2,3 na pocetku redova.

I nesto mi je sumnjivo da tabela tblUlazniRacuni nije dete tablea od tabele tblDobavljaci. Dalje, jesi li siguran da je relacija izmedu tblUlazniRacuni i tblUlazniRacuniDetalji 1:1 Obicno ovo ide 1:vise, pa ti treba neki GROUP BY kveri da sabere sve u kalkulaciji. A mozda je i sve OK, u tom slucaju - OK, everybody's happy.

:-)

Evo

Ova aplikacija faktura 190505 nesto ne radi!
kada hocu da udjem, npr. UNOS PODATAKA - NABAVKA ROBE izbacuje mi poruku "run-time error '13' ".

Ides u reference pa pozovi taj dll.
Sretno

Objasni mi molim te kako da nadjem reference, trazio sam po accessu ali ne vidim, ako se to uopste tu i nalazi?
HVALA ZA SVAKI TRUD NA APLIKACIJI!

udjes u modul pa Tools pa refererence pa brovs i ucitas taj dll sto si dobio

upravo radim program ulazno-izlaznih racuna, pa sam pogledao vase teme, nije mi samo jasno ubacujete li vi tu sifre dokumenata (up, uf, st - storno dokumenta, knjizno odobrenje), veze izmedju predracuna - racuna - stronodokumenta - knj. odobrenja.

Nece da mi radi ova aplikacija! Opet mi izbacuje run time error!

Naravno da nece ja sam napravio samo formu artikli a umeniju sam dao primjer kako unijeti sledece forme za upis misleci da ces sam da ih naprvis po uzoru na moju formu artikli.
Probaj malo prouciti meni i pozivsnje formi kroz meni.
Pozdrav

jos sam na pocetku, evo mog primera.

Nist novo, tema mi se dopala pa je ovako ponovo stavljam 'na videlo'

:-)

Ima li nekog ko je zainteresovan za nastavak ove teme?
Pozdrav!

Ja, samo ne znam kako?

Otvri novu temu, nazovi je
Kako da mi u odrađenim računima u Access-u ne postavlja uvek najnovije cene_2_deo
Ono 2 na kraju je bitno :-)
U poruku ubaci link na ovaj prvi deo i nastavi sa diskusijom.

:-)