Pomoć! Kako da mi u odrađenim računima u Access-u ne postavlja uvek najnovije cene_

POMOĆ!
Nov sam na ovom forumu i ne znam baš kako sve funkcioniše, ali naučiću.
Imam problem!
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!

Potpis

Bez muke nema nauke!!!

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.

Potpis

Pozdrav,
Branislav

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

Potpis

zxz

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

Potpis

Bez muke nema nauke!!!

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

https://www.elitesecurity.org/t83644#533472

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

Potpis

Kiro

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.

Potpis

Pozdrav,
Branislav

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!

Potpis

Bez muke nema nauke!!!

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!

Potpis

Bez muke nema nauke!!!

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!

Potpis

Bez muke nema nauke!!!

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

Potpis

Kiro

Evo
Sretan rad

Potpis

zxz

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!

Potpis

Bez muke nema nauke!!!

evo
Sretan rad

Potpis

zxz

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

Potpis

zxz

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!

Potpis

Kevo brate, chu te napucam familije mi!