Noordenwind ontwerp

Status
Niet open voor verdere reacties.
H

Hannie2

Gebruiker
Lid geworden
30 dec 2007
Berichten
47
De voorbeelddatabase Nwind wordt veel gebruikt als basis voor boeken over Access. Er zijn in het ontwerp 2 dingen die volgens mij indruisen tegen de normalisatieregels:
1. Het veld Prijs per Eenheid komt voor in twee tabellen, Producten en Orderinformatie. Vraag: waarom is dit veld ook opgenomen in de tabel Orderinformatie?
2. VerzendNAW is opgenomen in de tabel Orders. Dit mag volgens mij niet omdat deze gegevens vele malen voorkomen in Orders en dus in een aparte tabel zouden moeten staan. Bovendien zijn de gegevens exact hetzelfde als KlantNAW. Het kan zijn dat het verzendadres anders is dan klantadres, maar dan nog hoort verzendNAW niet thuis in de tabel Orders.
Vraag: waarom staan verzendNAW-gegevens in de tabel Orders?
 
Vraag 1: Lijkt mij omdat er soms ook korting wordt gegeven bij het plaatsen van een (grote) order.
Vraag 2: Je zegt het zelf eigenlijk al: Het afleveradres kan per order verschillend zijn (bijv. als je een klant hebt met meerdere vestigingen).

Normalisatie heeft hier niets mee te maken, meer de inrichting van 1. prijspolitiek en 2. logistiek.

Hopelijk heb je hier iets aan.

Tijs.
 
Hoi,

1) Eens met wat dnties zegt. Ik heb zelf in mijn tabel artikel twee prijzen, voorraadprijs en adviesprijs. Adviesprijs verschijnt in het orderscherm als een artikel geselecteerd wordt. Vervolgens dient de verkoopprijs ingevoerd te worden in een ander element. Adviesprijs komt naar voren om niet elke keer deze op te hoeven zoeken in het scherm artikel.
2) Niet eens met wat dnties zegt: Als er meerdere vestigingen zijn, dan horen die onder de tabel klant te hangen. In tabel klant komen dan de gegevens van de hoofdvestiging (of default vestiging of iets dergelijks) en in de tabel vestigingen alle mogelijke vestigingen voor die ene klant, of eventueel bij andere bedrijven (aflevering bij een ander bedrijf dan het bestellende bedrijf). Tijdens het invoeren van de order dien je dan te selecteren waar de boel afgeleverd moet worden.

M.i. heeft 2 wel degelijk met normaliseren te maken, echter het is erg afhankelijk hoe 'gecompliceerd' je je db wil maken.

Groet,

Zqwiqly
 
Reactie op vraag 1: Prijs per eenheid:
Het veld Prijs per eenheid komt voor in tblOrderinformatie en tblProducten.
Wanneer je producten toevoegt aan een bestelling in het formulier Orders verschijnt niet automatisch de prijs. Dit zou wel moeten, maar dan moet er een AutoLookup-query worden gemaakt.
Het gemeenschappelijke veld is Productnummer. In de query komt het van de véél-kant. In de expressie Factuurprijs moet specifiek worden opgegeven dat de Prijs per eenheid uit de tabel Producten moet worden gehaald.
Bij het invullen van een nieuwe order wordt nu de prijs automatisch ingevuld wanneer je een product opneemt in een order.
Nu weet ik alleen niet hoe ik om moet gaan met de Prijs per eenheid uit tblOrderinformatie. Vraag: Als jouw suggestie, een speciale prijs bij een grote order, klopt, hoe moet ik dat dan invullen als ik een nieuwe bestelling maak op het formulier Orders?
 
Quote: Ik heb zelf in mijn tabel artikel twee prijzen, voorraadprijs en adviesprijs. Adviesprijs verschijnt in het orderscherm als een artikel geselecteerd wordt. Vervolgens dient de verkoopprijs ingevoerd te worden in een ander element. Adviesprijs komt naar voren om niet elke keer deze op te hoeven zoeken in het scherm artikel.

Reactie op antwoord van Zqwiqly op vraag 1 (Prijs per eenheid):
Jouw oplossing m.b.t. Adviesprijs komt in de buurt van de mijne (zie mijn 2e reactie). Maar wat bedoel je met "Verkoopprijs invoeren in een ander element?" Als het om een berekening gaat bedoel je waarschijnlijk een expressie in de query waarop het subformulier is gebaseerd. Als dat zo is begrijp ik nogsteeds niet wat ik aan moet met het veld Prijs per eenheid in tblOrderinformatie. Als dit een speciale prijs is voor grote orders, moet ik die dan telkens handmatig invoeren in de tabel Orderinformatie? Dat zou dan betekenen dat ik niet kan werken met de AutoLookup-query die de prijs automatisch invult op het subformulier van formulier Orders.

p.s. Ik kom ook nog terug op mijn vraag 2, daar moet ik nog even over nadenken.
 
Hoi,

In mijn tabel 'part' staan dus twee elementen: adviesprijs en voorraadprijs. In mijn tabel 'orderlines' staat een element prijs. Dat is dus op dat moment de verkoopprijs. Op mijn subform 'orderlines' staat de adviesprijs naast de verkoopprijs. Dat veld is disabled. Na het kiezen van een partnummer uit een drop down box verschijnt de adviesprijs in het veld.

Het veld verkoopprijs is enabled, daar moet je handmatig de prijs invoeren. Dat heb ik gedaan om het mogelijk te maken om andere prijzen te hanteren (zo heb ik voor een aantal parts een prijsafspraak voor volledige onderdelen. Echter het komt voor dat we ze niet volledig leveren, laten we zeggen 80%. Dan is het makkelijk om een andere prijs in te voeren en niet de adviesprijs te hanteren).

Factuurprijzen komen bij mij dus ook uit de tabel 'orderlines' en niet uit de tabel 'part'. Het is uiteindelijk wel handig om te factureren wat je op je orderbevestiging zet (komt voort uit je tabel 'orders' en 'orderlines'), en niet wat in je tabel 'part' staat.

Heb je altijd dezelfde prijs voor een artikel, dan kan je het systeem hanteren dat je eens per jaar een artikelprijs invoert (zou ik toch nog steeds in tabel 'part' doen), en die automatisch op je order plaatsen als je een order invoert (zelfde werkwijze als dat ik 'adviesprijs' laat zien, echter dan wordt 'adviesprijs' direct 'verkoopprijs').

Groet,

Zqwiqly

Ps. Ik heb die db 'Noordenwind' nog nooit geopend.... wat ik je vertel is de manier zoals ik het in mijn db opgelost heb.
 
de verzendNAW betreft aflever adres.

Als dozenschuiver/reseller kun je de producten rechtstreeks bij de klant van de dozenschuiver laten afleveren. is dus niet het adres van de schuiver zelf, en waarschijnlijk alleen voor deze Order geldig
 
Laatst bewerkt:
Hoi,

Nav de reactie van Ellasar:
Toch zitten hier ook wat haken en ogen aan. Prima dat je direct bij een klant van de dozenschuiver kan afleveren, maar als je dat nog een keer wil doen moet je weer het gehele adres intikken..... Dan toch eerder een constructie dozenschuiver heeft als adres X en heeft als mogelijke afleveradressen klant Y en klant Z. Dat in tabelvorm met de juiste knoopjes ertussen en de volgende keer selecteer je direct uit een dropdown box.

Groet,

Zqwiqly.
 
Hoewel ik nog nooit met Noordenwind gewerkt heb is er nog een belangrijk argument om de prijs op order niveau op te slaan. Artikelen zijn aan prijsmutaties onderhevig, koppel je de prijs niet los dan heb je de kans dat de prijs op orderniveau wordt aangepast als prijsmutaties plaats vinden. In het geval van facturen is dit natuurlijk niet wenselijk maar er zijn veel meer situaties waarin dit ongewenst is. Ook, en dat is afhankelijk hoe je de voorraad gaat waarderen en bij exacte marge berekening, is het verstandig om de prijs per order (inkoop en verkoop) op te slaan.

Het geval van de afleveradressen is redelijk simpel op te lossen door een extra tabel aan te maken waarin je de afleveradressen per klant op slaat waarbij je 1 als default kan kiezen, ook kan je een cmdbutton aanmaken waarin je de optie aanmaakt : Factuuradres is afleveradres waarbij je de inhoud van de velden kopieert.
 
Zqwiqly zei:
de volgende keer selecteer je direct uit een dropdown box.
Klik om te vergroten...
Niet handig want de volgende keer besteld dozenschuiver iets voor iemand met adres W, en iets voor adres V (hij heeft hopenlijk voor hem wel iets meer adressen dan 2)
 
Niet handig want de volgende keer besteld dozenschuiver iets voor iemand met adres W, en iets voor adres V (hij heeft hopenlijk voor hem wel iets meer adressen dan 2)
Klik om te vergroten...

Heh,

Da's inderdaad ook weer zo... Inderdaad, twee of meer afleveradressen op 1 order wordt een probleempje, maar oplosbaar. Heb ik zelf nooit me te maken gehad en zal er ook niet mee te maken hebben. Maar goed, is nog steeds op te lossen door per orderregel een afleveradres uit de dropdown box te kiezen. Hoofdformulier de bestellende firma (dozenschuiver in dit geval) en per orderregel (=subformulier) afleveradres. Paklijsten vervolgens uitsorteren op afleveradres (dat je niet per regel een paklijst krijgt). Ben zelf nogal lui van aard ;) en voer liever dit soort gegevens eenmaal in en daarna klikkerdeklik en klaar. Tevens verhoogt extra invoeren de kans op fouten.

Nav de post van Floor E:
Helemaal mee eens.

Groet,

Zqwiqly
 
Laatst bewerkt:
Hallo Zqwiqly, Ellasar en Floor E,
Heel fijn dat jullie met me meedenken. Ik vind de suggesties allemaal interessant en geeft mij stof tot nadenken.
Antwoord aan Floor E:
Quote: Artikelen zijn aan prijsmutaties onderhevig, koppel je de prijs niet los dan heb je de kans dat de prijs op orderniveau wordt aangepast als prijsmutaties plaats vinden.
Het geval van de afleveradressen is redelijk simpel op te lossen door een extra tabel aan te maken.....
Ik vind je uitleg over prijs in tblOrderinformatie heel helder. Pluim ;)
Voor adressen (klant- en aflever) had ik ook 2 tabellen gemaakt. Dat vind ik een elegantere oplossing dan NAW in de tabel Orders op te nemen.
Bedankt!
Antwoord aan Zqwiqly (makkelijkere naam zou fijn zijn) en Ellasar:
Ik vind jullie reacties ook heel interessant om over na te denken en ze vormen een positieve bijdrage aan deze discussie die ik heb aangezwengeld. Bedankt. :thumb:
Groet, Hannie2
 
[Off topic]

Zqwiqly (makkelijkere naam zou fijn zijn)
Klik om te vergroten...

Maaaaar.... die is toch hardstikke makkelijk?

Nah, ok, 't is wat lastig tikken, maar als ik je uitleg dat het een
Engelse nick is van 'Is quickly', en dat snel uitgesproken... dan
wordt het wel duidelijker.... :)

[/Off topic]

Graag gedaan, ik moet zeggen dat ik een dergelijke discussie
en zeker deze onderwerpen ook wel kan waarderen, is weer eens
wat anders dan 'wat is de code voor' of 'hoe maak ik deze querie'. ;)

Groet,

Zqwiqly.
 
Hallo mensen
Misschien kan iemand me helpen met het volgende :
In access 2007 heb je het formulier order van nieuwe klant.
Onderaan het subformulier krijg je dan het totaal van de rekening te zien.
Hoe maak je dat?
Ik ben al een tijd aan het zoeken maar kan het niet vinden.


voorb.jpg
Iemand?
 
Ordertotaal Nwind 2007

Beste Paul,
Volgens mij dient de query Orderoverzicht als recordbron voor het subformulier Orders voor Klanten. De berekeningen Subtotaal en Ordertot vind je in deze query. Je kunt deze velden plaatsen als afhankelijk tekstvak in de voettekst of de sectie detail van het subformulier.
Ik hoop dat dit is wat je bedoelde. Overigens was je voorb.jpg te klein om te kunnen lezen.
Groet,
Hannie2
 
Hallo hannie2

Eerst heel erg bedankt voor de reactie!

Je verhaal klopt denk ik wel maar….
Het probleem is dat ik het tekstvak niet kan vinden ( is er niet).

Groeten
Paul
Naamloos.jpg
 
Tekstvak Factuurtot

paul.jacobs zei:
Hallo hannie2

Eerst heel erg bedankt voor de reactie!

Je verhaal klopt denk ik wel maar….
Het probleem is dat ik het tekstvak niet kan vinden ( is er niet).

Groeten
Paul
Bekijk bijlage 59665
Klik om te vergroten...

Open het formulier Klantgegevens in ontwerpweergave. Klik op het tabblad Orders. Daar vind je het subformulier gebaseerd op de query Orderoverzicht dat de berekeningen bevat. Hier vind je het afhankelijke tekstvak Factuurtot (bron: Ordertot).
Groet,
Hannie2
 
hallo hannie

nogmaal bedankt!!

we snappen elkaar niet goed geloof ik...

ik bedoel het formulier Detailgegevens orders.

daar kom je een totaal tegen en die wil ik graag namaken ......:thumb:
 
Ordertotalen

Hallo Paul,
Ik begrijp dat je zoekt naar de som van Bedrag. Even iets over de structuur: de recordbron van Ordersubformulier voor ordergegevens is de query Ordergegevens-Uitgebreid. In die query wordt het totaal per order uitgerekend (CCur enz.). De query is gebaseerd op de tabel Detailgegevens orders. Als je naar de gegevensbladweergave van het subformulier kijkt zie je onderin de optelsom van de totalen. Hier is de functie Som gebruikt. En dit is dus ons probleem: in de ontwerpweergave is deze totaalsom niet terug te vinden. Ik kan je wel uitleggen hoe je zelf het veld Totalen kunt toevoegen, maar het is misschien interessanter uit te dokteren waar ze deze laatste Totalenregel hebben verstopt. Ik wil het graag uitzoeken, maar daar heb ik even tijd voor nodig. Als je snel een oplossing wil kan ik je wel uitleggen hoe het handmatig moet.
Groeten,
Hannie
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan