Gevonden waarde uit Query gebruiken in andere Query

• KostenSoort zou misschien KostenSoortID moeten zijn. Je zou een tabel kunnen maken met alle mogelijke kostensoorten.
  Dat was ik al van plan, maar voor het voorbeeld was dit prima mijns inziens.
• Wat je in die tabel met "orderregel" bedoelt snap ik niet.
  Dat is simpelweg om de volgorde van de orderregels te bepalen. De één noemt het "regel x" de andere "positie x". Veel bestellingen bestaan uit meerdere artikelen. Veel klanten zetten een orderregel vooraan zodat het makkelijk is daarnaar te refereren.
• Als de verschillende artikelen van een order op verschillende momenten afgeleverd kunnen worden staat de afleverdatum op de juiste plek. Als je alles in 1 keer aflevert hoort die bij de order.
  We hebben inderdaad, bij een aantal klanten, verschillende aflevermomenten per order.

• In Tabel OrderRegels hoort volgens mij het aantal en de prijs (van het artikel) thuis.
• In Tabel OrderRegelsDetails horen aantal en prijs juist niet thuis.
• Naast de kostensoort moet je daar volgens mij ook een bedrag opnemen. Ik neem aan dat je per kostensoort 1 bedrag opneemt en dat een aantal niet nodig is.

Ik heb die keuze van prijs en aantal juist uitgelegd in mijn vorige bericht.

xps351 zei:

Met onderstaande ben je mijns inziens op de goede weg.

Dan verwacht ik direct commentaar/disccusie op de plek waar ik het aantal en prijs invul.
Mij lijkt dit de logische indeling. Wij hebben namelijk wel eens een order waarbij we een deel gewoon kunnen bewerken. Maar voor een aantal "extra werk" hebben.
Dat zetten we dan ook op zo op de factuur. Hoewel dat een apart systeem is (Twinfield) zou ik dat toch ook graag zo in ons ordersysteem vast leggen.

Dan wordt het als volgt:

[TABLE="class: grid, width: 500"]
[TR]
[TD]OrderRegelID[/TD]
[TD]OrderID[/TD]
[TD]OrderRegel[/TD]
[TD]ArtikelID[/TD]
[TD]Leverdatum[/TD]
[/TR]
[TR]
[TD]123[/TD]
[TD]987[/TD]
[TD]1[/TD]
[TD]18[/TD]
[TD]1-4-2023[/TD]
[/TR]
[/TABLE]

[TABLE="class: grid, width: 500"]
[TR]
[TD]OrderRegelsDetailsID[/TD]
[TD]OrderRegelID[/TD]
[TD]Aantal[/TD]
[TD]Prijs[/TD]
[TD]KostenSoort[/TD]
[/TR]
[TR]
[TD]25[/TD]
[TD]123[/TD]
[TD]20[/TD]
[TD]10[/TD]
[TD]Productie[/TD]
[/TR]
[TR]
[TD]26[/TD]
[TD]123[/TD]
[TD]5[/TD]
[TD]5[/TD]
[TD]Extra[/TD]
[/TR]
[TR]
[TD]27[/TD]
[TD]123[/TD]
[TD]1[/TD]
[TD]50[/TD]
[TD]Instel[/TD]
[/TR]
[/TABLE]

Klik om te vergroten...

Ik laat me graag adviseren, maar mijn oplossing lijkt me logisch in mijn situatie.
Anders krijg je ook in beide tabellen een prijs veld. Moeilijker rekenen om een som te maken. Daarnaast misschien ook nog in beide tabellen een aantal veld omdat ik bepaalde kosten liever niet als totaalsom wil plaatsen, maar per product.

Aangezien een plaatje meer zegt dan 20 lijnen en mijn uitleg blijkbaar toch nog wat verwarrend overkwam:

RaoelS zei:

Ik heb die keuze van prijs en aantal juist uitgelegd in mijn vorige bericht

Klik om te vergroten...

Helaas begreep ik die uitleg niet helemaal. Ik snap niet hoe ik kan zien hoeveel er nou van artikel 18 besteld is. Het enige dat ik zou kunnen bedenken is dat het er 20 zijn. Dat zou dan weer betekenen dat je dus altijd een regel met productiekosten moet hebben.

Ik ben benieuwd of en waar je dan de productiekosten van een artikel vastlegt. En die andere kosten, kennen die een prijs per eenheid?

Het wordt nu ook steeds duidelijker waarom dit verhaal zo moeizaam loopt. Je zegt dat je wilt werken volgens een apart systeem. Je kunt ons niet kwalijk nemen dat we dat systeem niet kennen. Zeker niet als je dat pas in post #13 een keer noemt.

Overigens blijft het zo dat, zoals ik eerder al schreef, de wijze waarop je de gegevens wil presenteren niet leidend hoeft te zijn voor de manier waarop je ze opslaat.

RaoelS zei:

Anders krijg je ook in beide tabellen een prijs veld. Moeilijker rekenen om een som te maken. Daarnaast misschien ook nog in beide tabellen een aantal veld

Klik om te vergroten...

Nee hoor, niet moeilijker. Waarom denk je dat? In je totalenquery zitten beide tabellen gekoppeld, dus je kunt gewoon per order regel optellen.

Beste is om alle kosten in één tabel te houden, zo kan je de totalen eenvoudig berekenen. Zeker geen extra tabel toevoegen. Er is een reden waarom klassieke designs klassiekers zijn . In de orderlijnen tabel kan je nog een extra veld steken "sorteervolgorde" om de afdrukvolgorde te regelen.

NoellaG zei:

Beste is om alle kosten in één tabel te houden, zo kan je de totalen eenvoudig berekenen. Zeker geen extra tabel toevoegen.

Klik om te vergroten...

Heerlijk, die stellige opmerkingen. Maar er is geen enkele reden om er niet een extra tabel voor te maken; al was het maar omdat dat dat toch echt afhankelijk is van de situatie ter plekke. Kunnen wij vanaf de buitenkant nooit goed beoordelen. Zelf zou ik, als dat mogelijk is, extra velden toevoegen voor de verschillende kostensoorten. Mits het aantal beperkt is. Dat is namelijk het makkelijkst in te voeren, en het makkelijkst voor de berekening. Maar je kunt er best een aparte tabel voor gebruiken.

Maar er schijnt nu weer verwarring te zijn over het begrip 'Orderregel'.

RaoelS zei:

Wat je in die tabel met "orderregel" bedoelt snap ik niet.

• Dat is simpelweg om de volgorde van de orderregels te bepalen. De één noemt het "regel x" de andere "positie x". Veel bestellingen bestaan uit meerdere artikelen. Veel klanten zetten een orderregel vooraan zodat het makkelijk is daarnaar te refereren.

Klik om te vergroten...

Veel klanten? Ik dacht dat klanten bij jou wat bestellen, en dat jij levert en dus een bestelbon meestuurt met de bestelde artikelen? Hoe dan ook: in een query op basis van de tabel Orderregels kun je prima een extra veld maken dat een regelnummer genereert. En op een rapport (wat doorgaans naar de klanten gaat) heb je zelfs de mogelijkheid om een tekstvak te maken dat een lopend nummer genereert, zodat je niks hoeft te doen voor je regelnummers. Zit dus allemaal al standaard in Access. Wat je nooit hoeft te doen, is het opslaan in een tabel. Dataredundantie, weet je nog?

Extra velden toevoegen voor de verschillende kostensoorten, kost1, kost2, kost3 is nooit een goed idee, zelfs niet als ze beperkt zijn tot één of twee velden. Voor je het weet heb je een derde en vierde soort kost nodig. Niet doen dus. Het toevoegen van een handmatig ingevuld veld voor de sorteervolgorde doe je omdat dit onafhankelijk is van elke berekening. Het biedt je de mogelijkheid om een afdrukvolgorde vast te leggen, onafhankelijk van een sortering of berekening.

NoellaG zei:

Extra velden toevoegen voor de verschillende kostensoorten, kost1, kost2, kost3 is nooit een goed idee, zelfs niet als ze beperkt zijn tot één of twee velden. Voor je het weet heb je een derde en vierde soort kost nodig. Niet doen dus.

Klik om te vergroten...

Je hebt gelijk, een extra gekoppelde tabel is veel handiger . Of: je zou eens op kunnen houden met in de schoenen van TS te gaan staan, en hem laten beslissen wat hij nodig heeft. Wij weten tenslotte de situatie niet. Of probeer je stiekem een betaalde klus binnen te halen?

OctaFish zei:

Of probeer je stiekem een betaalde klus binnen te halen?

Klik om te vergroten...

Dit is een ongevraagde, beledigende insinuatie. Graag excuses.

Nee joh, doe niet zo gek. Lees eerst eens na wat een belediging is. Of een insinuatie. Dit was gewoon een kwinkslag.