waarde weergeven van een andere tabel

Status
Niet open voor verdere reacties.

frankie59

Gebruiker
Lid geworden
25 sep 2008
Berichten
154
Hallo,

Ik heb een bestandje voor prijslijsten.

Lijst 1: genaamd prijslijst met velden artikelnummer en prijs
Lijst 2: genaamd prijslijst oud met velden artikelnummer en prijs

Ik zou graag een manier weten om in een query te maken waarbij ik een nieuw veld krijg bv verkoopprijs.
Dit veld word gevuld met het veld prijs van de lijst prijslijstoud, als dit gevuld is anders wordt het veld prijs van lijst prijslijst genomen.

Ik hoor graag van jullie.

Met vriendelijke groet, Frank
 
Ik snap totaal niet waarom je daar twee tabellen voor gebruikt. Daar zou ik zelfs na een goede fles whiskey nooit op gekomen zijn :). En nuchter dus ook niet. Heb je daar een specifieke reden voor?
 
Ik kan er me wel een redenen bij bedenken: het gaat hier om een nieuwe, en een oude prijslijst.
Overigens lijkt het me dan wel geen goede opbouw van een database, om telkens er een prijswijziging is een nieuwe tabel te maken.

Maar goed, er zijn wel meer redenen waarom je de prijzen in aparte tabellen zou zetten.
Maak dus gewoon een query, waarbij je de unieke velden (het product wellicht) aan elkaar koppelt, en waar je vervolgens zowel de oude als de nieuwe prijs laat zien.

Mocht je op het idee komen om je eerste tabel uit te breiden met telkens een nieuw veld wanneer de prijs nog eens wijzigt... ook dat is geen goed idee hoor.

Nog even over nagedacht...
Stel dat je regelmatig een backup van je database maakt.
Na een tijdje wil je de prijslijst uit het verleden vergelijken met de huidige prijslijst.
Dan kan je de 2 tabellen (uit de huidige database, en uit de backup) importeren in een derde database, en op die manier kijken waar de prijsverschillen zitten.
Als dat regelmatig moet gebeuren, moet je natuurlijk een andere oplossing bedenken, maar als het dient om hier of daar fouten of zoiets op te sporen is het vergelijken van 2 tabellen wél handig.

Hier heb je een query die twee tabellen vergelijkt.
Ik neem alle velden van Lijst1, en enkel de velden van Lijst2 met een corresponderend artikelnummer.
Bovendien laat ik de 2 prijzen zien (van elke tabel bet veld prijs)

Code:
SELECT Lijst1.Artikelnummer, Lijst1.Prijs, Lijst2.Prijs
FROM Lijst1 LEFT JOIN Lijst2 ON Lijst1.Artikelnummer = Lijst2.Artikelnummer;

Of het veld 'Verkoopprijs' uit Lijst1 vullen met de waardes uit Lijst2 tenzij die waarde niet bestaat.

Code:
UPDATE Lijst1 LEFT JOIN Lijst2 ON Lijst1.Artikelnummer = Lijst2.Artikelnummer SET Lijst1.Verkoopprijs = IIf(Nz([Lijst2].[Prijs],0)=0,[Lijst1].[Prijs],[Lijst2].[Prijs]);
 
Laatst bewerkt:
Ik kan er me wel een redenen bij bedenken: het gaat hier om een nieuwe, en een oude prijslijst.
Vind ik geen goede reden; een prijslijst kan gewoon in één tabel worden onderhouden. Mét behoud van historie. En zónder al die rare poespas queries die je nu hebt gemaakt om de prijzen te vergelijken. Maar als iemand (TS?) dat wil, dan zal ik daar geen traan om laten natuurlijk.
 
Ik zou het zelf durven gebruiken. Maar altijd als iemand bij mij komt vragen wat er fout gegaan is.
En dat hoeft niet enkel met prijslijsten te zijn. Kan ook met klantenlijsten; planningslijsten; voorraad enz.

Je zou het bijvoorbeeld ook kunnen gebruiken als je de ganse applicatie hebt verbouwd, en op die manier oude gegevens wil importeren (Dat is dus een éénmalige handeling).

Hoe dan ook vergeet het als het een standaard procedure moet zijn.
 
Hoe interessant ook dit soort verhandelingen ook zijn, ik ben (op dit moment in dit topic) net zo min geïnteresseerd in jouw werkwijze als jij in de mijne. Ik stel voor dat we ons gewoon bezighouden met het beantwoorden van de vraag van TS. En ik wacht nog steeds op een reactie :).
 
Beste mensen, harstikke bedankt voor jullie reacties.
Ik lees wat irritatie, dat is omdat ik het niet goed uitgelegd heb. Excuus hiervoor, want dat kan niet de bedoeling zijn.

Ik krijg van onze groothandel een prijslijst in Excel.
Deze heeft veel kolommen oa.
artikelnummer, korte omschrijving, lange omschrijving, inkoopprijs, btw, voorraad, verkoopgroep etc.
Deze lijst omvat 3000 artikelen verdeeld in 100 verkoopgroepen.
Ik importeer deze gegevens in access en laat een tabel met alleen de verkoopgroepen en de door mij ingegeven opslag% een lijst maken met alle gegevens incl. de verkoopprijs die dan aangepast is met het door mij opgegeven opslagpercentage, dat werkt goed.

Dit laat ik in een formulier terugkomen.
Alles staat dan goed.
Het probleem is dat ik bv 20 % opslag heb voor de verkoopgroep notebooks. Er rolt hier een verkoopprijs uit die akkoord is voor notebooks van inkoop tussen de 400 en 500 euro, maar 20% op notebooks van inkoopprijs 900,- is weer veel te veel.
In de query laat ik een tabel bijmaken met de naam historie.
Deze zie ik terug in het formulier. Ik ga dan de prijzen corrigeren.
van dit alles ga ik een historie maken.
De dag erop krijg ik weer een nieuwe lijst.
Ik zie dan de nieuwe "foute"prijzen en de historieprijs (dus die ik gisteren aangepast heb).
Ik klik dan op het veldje prijslijst oud en maak dit als de nieuwe prijs.
En maak ik weer een nieuwe historie.
Omdat ik dagelijks dan op 200 veldjes moet klikken, zou ik dit anders willen.

Ik zat te denken om als laatste een query te laten lopen met alle informatie die dan als verkoopprijs gaat kijken of er een historieprijs is, is dit het geval dan neemt hij de historieprijs, anders de nieuwe prijs.

Dus in het kort: als ik van een artikelnummer een prijs aanpas, zou hij deze altijd moeten pakken als de prijzen geïmporteerd worden. Heb ik de prijs in het verleden van een artikel niet aangepast dan neemt hij de berekende prijs van het vaste opslag percentage.
------------------- Dit is de code van de query die ik gebruik op dit moment, mogelijk is dit voor jullie duidelijker dan mijn verhaal.-----------------------

SELECT OEM_LIJST.articleNumber, OEM_LIJST.price, 121 AS BTW, TBL_Groepen_Prijslijst.Toeslag, [price]*[btw]/100 AS inkoopincl, [inkoopincl]*[toeslag]/100 AS Verkoopprijs, ([verkoopprijs]-[inkoopincl])/1.21 AS Winstexcl, TBL_Prijslijst_Historie.Verkoopprijs AS Verkoop_oud, OEM_LIJST.title, "https://complies.nl/catalogsearch/result/?cat=&q=" & [title] AS link, OEM_LIJST.description, OEM_LIJST.stock, OEM_LIJST.categoryName1, OEM_LIJST.categoryName2, TBL_Prijslijst_Historie.categoryName3, TBL_Prijslijst_Historie.Configurator, TBL_Prijslijst_Historie.Tag1, TBL_Prijslijst_Historie.Tag2, TBL_Prijslijst_Historie.Tag3, OEM_LIJST.image1, OEM_LIJST.image2, OEM_LIJST.image3, OEM_LIJST.image4, OEM_LIJST.image5, OEM_LIJST.image6, OEM_LIJST.image7, OEM_LIJST.image8, OEM_LIJST.image9, OEM_LIJST.image10 INTO TBL_Prijslijst_OEM
FROM (OEM_LIJST LEFT JOIN TBL_Groepen_Prijslijst ON OEM_LIJST.categoryName2 = TBL_Groepen_Prijslijst.categoryName2) LEFT JOIN TBL_Prijslijst_Historie ON OEM_LIJST.articleNumber = TBL_Prijslijst_Historie.articleNumber
WHERE (((OEM_LIJST.stock)>0))
ORDER BY OEM_LIJST.price, OEM_LIJST.categoryName1, OEM_LIJST.categoryName2;

Alvast heel erg bedankt, dat jullie hier naar willen kijken.

Met vriendelijke groet, Frank
 
Het probleem is dat ik bv 20 % opslag heb voor de verkoopgroep notebooks. Er rolt hier een verkoopprijs uit die akkoord is voor notebooks van inkoop tussen de 400 en 500 euro, maar 20% op notebooks van inkoopprijs 900,- is weer veel te veel.
Ik zou met prijsgroepen werken, denk ik. Als ik je zo lees, doe je veel prijsaanpassingen 'op gevoel'. De ene groep pas je aan bij een prijs tussen 400-500, de volgende groep misschien weer bij 500-700. En zo verder. Dus een aparte tabel met verkoopgroep, prijsgroep en korting zou je al een hoop werk uit handen nemen. Daarnaast is het ook gelijk duidelijk waar de nieuwe prijzen vandaan komen, want de prijsgroepen liggen dan vast. Eventueel pas je een keer de percentages aan, of de prijsgroepen en je bent klaar.
Ik zou de Excel lijst gebruiken als basis om de basisprijzen in te lezen in je artikelen tabel, met dus één prijstabel met daarin de volledige prijshistorie van je artikelprijzen (uiteraard alleen als de prijs wijzigt). Je voegt dan dus een nieuw artikel toe aan je artikelentabel (geldt ook voor artikelgroep), met de ingangsdatum van de nieuwe prijs. Da's één toevoegquery. Vervolgens draai je een toevoegquery op basis van afwijkende bedragen. Als de prijs van een bestaand artikel afwijkt van de prijs die je nu gebruikt, dan de nieuwe prijs toevoegen + de ingangsdatum. Op die manier bouw je de prijshistorie op, en sla je geen overbodige gegevens op. Bij de verkoop kijk je dan in de tabel naar de actieve prijs, en die gebruik je in je transacties.

Daarnaast denk ik dat je systeem niet geheel jofel is genormaliseerd, als ik deze regel lees:
PHP:
OEM_LIJST.image1, OEM_LIJST.image2, OEM_LIJST.image3, OEM_LIJST.image4, OEM_LIJST.image5, OEM_LIJST.image6, OEM_LIJST.image7, OEM_LIJST.image8, OEM_LIJST.image9, OEM_LIJST.image10

Ik hoop dat de rést van je database wél genormaliseerd is :).
 
Bedankt Octafish en LUC voor je reactie.

Ja, klopt inderdaad.
Het toevoegen van een mutatiedatum is een goed idee.
Ik ga hem opbouwen, zoals je aangeeft.
Ik heb de code van LucHeyndrickx ingevoegd in mijn programma en het werkt precies zoals ik het graag wilde.
Ik ben er erg blij mee.

Jongens, heel erg bedankt en een fijne jaarwisseling voor straks.

Met vriendelijke groet,

Frank Schuurmans.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan