prijzen uit een andere tabel automatisch invoeren

Status
Niet open voor verdere reacties.

Jesse2

Gebruiker
Lid geworden
3 mei 2011
Berichten
340
het gaat hier om 2 tabellen in de 1e staat week/dag 233t/m 257 €0,55
nu is het de bedoeling dat wanneer er via een formulier een bestelling in tabel 2 word ingevoerd met een datum tussen 233-257 deze prijs automatisch ingevuld word.

is dit mogelijk?

als dit niet mogelijk is hoor ik graag andere suggesties!
 
Dat is prima mogelijk, met een constructie die gebruik maakt van een Cartetisch product. Daarbij zoek je een waarde op die tussen twee andere waarden in liggen. In bijgaand bestand twee voorbeelden.
 

Bijlagen

  • Waarden in Reeks.zip
    29,3 KB · Weergaven: 26
het bijgevoegde document lijkt leeg te zijn:confused:
ik kan het wel openen maar alles wat ik te zien krijg is een leeg access document.
ik krijg wel een melding dat het alleen lezen is, maar als ik dat ophef maakt het geen verschil.
 
Laatst bewerkt:
ik heb het bekeken maar heb je een idee hoe de code van mij er dan uit zou zien?
ik had in gedachten het op basis van 1 veld te doen of kan dit niet?
in je voorbeeld staat een tabel die als de waarde: prijsgroep A ingevuld word hij 0,00 en 20,00 weergeeft.
is het ook mogelijk om daar een optie tussen bv. getal 275 en 285 zodat alle getallen daartussen dezelfde prijs krijgen?
en welke code moet ik hier voor gebruiken?
 
Het handigst werkt het systeem als je een tabel hebt met twee opzoekwaarden: een beginpunt en een eindpunt. In het voorbeeld gebruik ik prijzen om een categorie te vinden; met hetzelfde gemak maak je een tabel waarbij je prijzen opzoekt. In jouw geval moet die tabel dus een Artikelnr, beginweek+dag (dat zal dus 011 zijn voor het eerste record, vermoed ik), een eindweek+dag (als voorbeeld:131) en een prijs bevatten. En zo maak je meer records, voor de overige weken. In totaal heb je dus (bij een gebruik van 13 weken, oftwel een kwartaal) voor elk artikel 4 records. Bij het opzoeken van de juiste prijs is de zoekwaarde dan het weeknummer. Oftwel: exact dezelfde constructie als mijn voorbeeld!

Het kan overigens wel met een tabel met alleen een beginwaarde, maar dat maakt de constructie gelijk een heel stuk ingewikkelder, omdat je in de tabel twee records moet opzoeken (de lagere waarde, en de hogere waarde) waar de prijs voor geldt. En waarom zou je het moeilijk maken voor jezelf?
 
ik heb de query qPrijzen in je tabel nog eens bekeken.
Dus het enige code zit in het query ontwerp?: >[Vanaf] And <=[TotEnMet]
en als ik het goed begrijp gebruikt je de twee waarden in Vanaf , Totenmet om de waarde in het veld genaamd Waarde op te zoeken?
waar haalt hij de waarde uit het veld Waarde vandaan?
Hoe kan ik deze code het beste toepassen op mijn formulier?

Jesse
 
Laatst bewerkt:
Als je de query goed wilt begrijpen, zou je het criterium eens moeten verwijderen (knippen, want je wilt 'm ook weer terug zetten...), en de query uitvoeren. Je zult dan zien, dat je ineens veel meer records te zien krijgt: 32 namelijk i.p.v. de 8 die er met criterium in zitten. De reden daarvoor is eigenlijk heel simpel: omdat de twee tabellen (BronTabel en BereikTabel) niet aan elkaar gekoppeld zijn, kan Access het resultaat niet baseren op overeenkomende waarden in de twee tabellen. Normaal gesproken heb je in TabelA (Klanten) bijvoorbeeld een sleutelveld KlantID, en in TabelB (Orders) een referentieveld KlantID. Door de twee KlantID's aan elkaar te koppelen, krijg je in het resultaat alle orders per klant te zien. Ontbreekt deze koppeling, dan weet Access niet welk records uit Orders horen bij welke KlantID's uit Klanten. Het resultaat: alle records uit de ene tabel worden gekoppeld aan alle records uit de andere tabel.
En dat is precies wat er gebeurt in de query qPrijzen, als je het criterium weghaalt. In de BronTabel zie je 8 records met artikelen en prijzen, en in de BereikTabel vind je 4 records met categorieën. Omdat er geen directe koppeling is tussen de velden, zal Access alle records uit de BronTabel koppelen aan alle records uit de BereikTabel. Oftewel: 8 records uit de BronTabel * 4 records uit de BereikTabel = 32 records. En dat is dus een Cartesisch product. Op zich is het een redelijk zinloze manier van gegevens koppelen, maar het laat dus alle mogelijke combinaties zien die er mogelijk zijn.

In het voorbeeld (en dat geldt dus ook voor jouw situatie) heb je geen velden die exact overeenkomen met elkaar. In de BronTabel heb je een veld Waarden. Dit veld bevat allerlei verschillende bedragen. In de BereikTabel heb je twee velden: [Vanaf] en [TotEnMet]. Je kunt dus geen koppeling maken tussen het veld [Waarde] en het veld [Vanaf], of het veld [Waarde] en het veld [TotEnMet]. Wèl kun je kijken of het getal in het veld [Waarde] tussen de waarden uit [Vanaf] en [TotEnMet] ligt. En dat doe je met het criterium. Daarmee filter je a.h.w. drie records uit het cartesisch product weg uit het resultaat: namelijk die records waarvan de waarde t.o.v. de velden [Vanaf] en [TotEnMet] niet voldoen aan het criterium. Ik zal dat nog even verduidelijken met een voorbeeldje.

ID Produkt Waarde Klasse Vanaf TotEnMet
7 Hagelslag € 44,00 Prijsgroep A € 0,00 € 20,00
7 Hagelslag € 44,00 Prijsgroep B € 20,00 € 40,00
7 Hagelslag € 44,00 Prijsgroep C € 40,00 € 60,00
7 Hagelslag € 44,00 Prijsgroep D € 60,00 € 9.999,00

In de tabel zie je de 4 records die worden gemaakt als er geen criterium is toegepast. Je ziet het artikel 4 keer verschijnen, omdat er 4 records zijn in de BereikTabel (zie hierboven). Elk artikel is gecombineerd met een Prijsgroep. Je ziet dat de correcte categorie Prijsgroep C is: de prijs van € 44,00 valt in de range € 40,00 - € 60,00. En dat is Prijsgroep C. Prijsgroepen A en B zijn te laag, en Prijsgroep D is te hoog. Het criterium [Waarde]>[Vanaf] And [Waarde]<=[TotEnMet] pakt dus precies de juiste categorie: 44 is groter dan 40, en 44 is kleiner dan 60.

En zo werkt dus een criterium op een cartesisch product...
 
nog even een vraagje hierover hoe zou ik dit het beste kunnen toepassen met in mijn huidige tabel.

Velden tabel met bestellingen:

naam van de klant, de datum, KC(hier word K of C ingevoerd), het wk/dag veld(dat zal wel niet gebruikt kunnen worden), Prijs veld

Velden tabel met prijzen:

naam van de klant, Prijs voor K, prijs voor C, van wk/dag(241), tot wk/dag(247),
 
Op basis van je voorbeeldje (al klopte je tabel Bestellingen niet...) een databasje
 
eigenlijk is k of c het artikel in mijn geval.
dus volgens deze manier zou ik er 2 velden bij moeten doen een aparte k prijs en c prijs? en een apart artikel veld er bij voegen of kan ik gewoon k en c gebruiken?

is het niet mogelijk om als er in het veld K/C , K word ingevoerd de prijs van K op basis van de datum en naam klant in te voeren in het veld prijs?

het is misschien ook belangrijk te melden dat in mijn database elke klant een eigen records met zijn eigen prijzen krijgt.

en in het voorbeeld wat is nou het definitieve veld de query?
 
Laatst bewerkt:
Als jij het al niet snap, wat moeten wij dan ??? Ik dacht eigenlijk dat K en C twee prijsgroepen o.i.d. waren, dus dat een klant een prijs betaalt op basis van de letter. Blijken dat nu je 'artikelen' te zijn?
 
ja dat zijn artikelen ik had het eerder moeten vermelden.
ik zal een voorbeeld maken.
 
In beginsel blijft mijn voorbeeldje nog steeds werken, alleen moet je de naam van de artikelen dus veranderen. Een artikel heeft een prijs, gebaseerd op een tijdsblok. Dus het opzoeken blijft gelijk.
 
Ik heb het voorbeeld aangepast, zodat hij nu voldoet aan jouw omschrijving (hoop ik :) )
 

Bijlagen

  • Prijs opzoeken.zip
    14,7 KB · Weergaven: 20
als ik dit dan in mijn formulier wil zetten moet ik dus met onafhankelijke velden gaan werken?
ik zie ook dat bij de tabel bestellingen K C twee keer voorkomt één keer in KC en één keer in artikel.
natuurlijk kan ik dit ook doen en er dan maar 1 laten terugkomen in mijn formulier.
 
Laatst bewerkt:
in de query staat bijvoorbeeld de klant febo met twee records met K op dezelfde start en eind week met verschillende prijs.
 
Kijk niet teveel naar de voorbeeld records; ik heb de kolom vrij willekeurig gevuld; eerst stonden daar andere artikelnamen. De kolom KC kan nu weg in bestellingen, want dat is inderdaad Artikel geworden.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan