Inrichting afwijkende prijzen

Status
Niet open voor verdere reacties.
N

Nico84

Gebruiker
Lid geworden
21 jul 2011
Berichten
191
Kan iemand advies geven hoe je afgesproken prijzen vast legt in mijn database.
Heb de nu de volgende tabellen.

tblDebiteuren----DebiteurID, Debiteurnaam, adres, OrganisatieID enz.
tblOrganisatie---OrganisatieID, Organisatienaam, adres, enz.
tblArtikel-----ArtieklID, Artikelnaam, ArtikelgroepID
tblArtikelgroep-----ArtikelgroepID, ArtikelgroepOmschrijving, EANcode, BTWcode, RichtprijsVerkoop, Richtprijsconsument

Stukje uitleg hoe het werkt.
Iedere debiteur wordt vast gelegd in de tabel debiteuren. Sommige vallen onder een organisatie (1 hoofdkantoor meerdere vestigingen).

Wij hebben een 25 artikelen in ons bestand en een 7 tal artikelgroepen. Artikelen vallen onder een artikelgroep.
Facturatie gebeurt bij ons op Artikelgroepniveau, misschien is dit vreemd, maar zo werkt het eenmaal. De klant wil een beperkt aantal artikelen hebben.
Vandaar dat de richtprijs en EANcode vastgelegd is in de tabel Artikelgroep. (bijvoorbeeld: 4 artikelen hebben dezelfde EANcode en prijs.)

Voor ons is het wel van belang dat er op artikel niveau geregistreerd wordt. Voor ons zelf willen we kunnen zien welk artikel loopt wel of niet bij de klant.


Vragen:
Met een organisatie zijn er voor de artikelgroepen afwijkende verkoop- en consumentprijzen afgesproken.
Met wat debiteuren zijn er afwijkende verkoopprijzen afgesproken.

Hoe leg je deze afwijkende prijzen vast? (prijslijst maken?)
Is de inrichting van artikel/artikelgroep goed of zal je dit in 1 tabel onder brengen.

Hoor graag jullie advies hierover, zodat ik het in 1 keer goed vast kan leggen in mijn database.
 
Als je verschillende prijzen hebt per artikelgroep en klanten, dan ontkom je bijna niet aan een aparte tabel waarin je die prijzen vastlegt. Of, als je een constante factor hebt voor de klanten, dan kun je een veld Korting toevoegen aan je tabellen Debiteuren en Organisatie. Hierin leg je dan een kortingspercentage vast dat dan over alle prijzen wordt berekend.
 
Als ik een debiteur aanmaak waarbij ik aangeef dat hij bij een organisatie hoort.
Hoe krijg ik dan de prijzen bij die debiteur, als er op organisatie niveau prijsafspraken gemaakt zijn?
 
Je hebt neem ik aan de debiteurentabel aan de organisatietabel gekoppeld, dus middels een query kun je de korting/prijsafspraak makkelijk koppelen aan de debiteuren.
 
Volgens mij zie ik iets over het hoofd.

De debiteurentabel is gekoppeld aan de organisatietabel. Wij maken geen gebruik van een kortings percentage.
Bij ons zijn niet alle debiteuren gekoppeld aan een organisatie.
Maar ik wil wel als ik een debiteur aanmaak en deze bij een organisatie hoort dat dan de prijzen worden gehanteerd die afgesproken zijn met de organisatie.

Heb nu een tussentabel gemaakt met prijsafspraken met de volgende velden.
ID, DebiteurID, ArtikelID, Verkoopprijs

Moet hier dan ook het veld OrganisatieID aan toegevoegd worden?
Is het de bedoeling dat alleen de afwijkende prijzen in de prijsafspraken tabel gezet worden?
 
Als je prijsafspraken maakt op organisatieniveau dan heb je er weinig aan om een tussentabel te maken waarin je het DebiteurID en de Verkoopprijs vastlegt; die prijs moet je dan natuurlijk koppelen aan de OrganisatieID. Alles hangt ook een beetje af van de verdere inrichting van je db: heb je aparte tabellen voor Organisatie en Debiteur, dan is de situatie anders dan als je daar één tabel voor gebruikt. In het laatste geval kun je wèl met je huidige tussentabel uit de voeten.
 
Gebruik aparte tabellen voor organisatie en debiteur.
Prijsafspraken gebeuren op organisatieniveau en op debiteurniveau.

Voorbeeld:
Er komt een nieuwe AH filiaal in ons debiteurenbestand. Ik voer de gegevens in op debiteur niveau en geef
daarbij aan dat hij bij de organisatie van AH hoort.
Dus de prijzen/Artikelen die met het hoofdkantoor (organisatie) zijn afgesproken gelden dan ook voor dit filiaal evenals het factuuradres.
----
Als een zelfstandige ondernemer zich aanmeld wordt deze ook op debiteurniveau ingevoerd.
Deze hoort niet bij een organisatie, maar kan wel afwijkende prijzen en artikelen mee afgesproken hebben.
 
Je zou kunnen overwegen om de structuur te veranderen, en één tabel te gebruiken voor Organisatie en Debiteuren. In beginsel zit er (qua entiteit) namelijk weinig verschil tussen organisatie en Debiteur. Het enige verschil is dat een debiteur ofwel zelfstandig is, ofwel afhankelijk van een organisatie. Dat onderscheid kun je maken met een veld ParentID. In het geval van een zelfstandige debiteur of organisatie heb je dan geen ParentID, in de overige gevallen geef je in het veld ParentID het ID op van de organisatie waar de debiteur bijhoort. Eventueel geef je in een extra keuzelijst nog aan wat voor type record het is, zodat je met keuzelijsten snel overzichten kunt maken voor Organisaties, Zelfstandigen en Dochters etc.
Op die manier kun je in je tabel met prijsafspraken het ID nummer invullen, en als dat op organisatieniveau is, is dat gelijk dan ook bekend voor de afhankelijke debiteuren (middels het ParentID). Tevens kun je dan voor de afhankelijke debiteuren ook nog zelfstandige prijsafspraken maken, omdat je natuurlijk ook een prijsrecord kunt maken met de DebiteurID in het prijsrecord i.p.v. het ID van de organisatie.
Bovendien kun je aan een debiteur ook weer dochters hangen. Je hebt dan dus een hele flexibele organisatiestructuur tot je beschikking, waarbij een organisatie dochters kan hebben, en die dochters zelf ook weer dochters. En voor elke variant kun je aparte prijsafspraken vastleggen.

Nu, met twee verschillende bronnen, wordt het een stuk lastiger. Eigenlijk heb je dan een extra veld nodig: één veld voor de OrganisatieID, en één veld voor de DebiteurID. Als je dan een prijsafspraak maakt, vul je één van de twee velden in.
 
Laatst bewerkt:
Bedankt OctaFish.
Ben ermee aan de slag gegaan, heb deze constructie ook in 1 van de cursussen voorbij zien komen.
Maar toch nog een vraag:

Heb dan nu 1 tabel en heb een veld "FactuurHoofdkantoor" type:ja/nee toegevoegd.(Veld is alleen nodig bij organisatie)
Ja: dan gaat het factuur naar het factuuradres van de organisatie
nee: dan gaat het factuur naar het factuuradres van de debiteur.

Hoe krijg ik dan als ik facturen wil maken het juiste factuuradres bij de debiteur?
Doormiddel van Dlookup?
 
Om te weten welk hoofdkantoor bij welke debiteur hoort (als je van een ParentID gebruik maakt) maak je een query waarin je de tabel twee keer toevoegt. Voor het mooie hernoem je ze dan bijvoorbeeld naar tOrg en tDeb zodat je later nog weet welke tabel je waarvoor gebruikt. Met een Outer Join koppel je de tOrg aan de tDeb op basis van ID en ParentID. Nu kun je de query maken met de velden van tDeb, en voeg je uit tOrg het factuuradres toe.
 
Dat heb ik gedaan.

Alleen heb ik dan 2 velden met factuuradres, postcode, plaats.
1 uit de tabel Debiteur en 1 uit de tabel organisatie.

Maar als ik een overzicht wil maken wil ik het in 1 veld hebben.
Factuur adres vanuit de tabel debiteur, maar als het factuur naar het hoofkantoor gaat moet het factuur adres
van het hoofdkantoor in het veld komen.

Heb een voorbeeldje bijgevoegd.
Alvast bedankt OctaFish
 

Bijlagen

Je kunt met een DLookup het adres opzoeken op basis van het DebiteurenID, waarbij je als criterium dan kijkt of het veld ParentID leeg is of niet. In het eerste geval pak je het eigen adres, en in het tweede geval zoek je het adres op op basis van ParentID. Of je maakt er een functie voor. Dat laatse is denk ik sneller.
 
Op 250 records zal dat veel uitmaken in snelheid?

Bedankt voor je hulp.
 
Kwestie van uitproberen, en kijken of het te traag is of niet ;) Ik denk dat DLookup wel mee zal vallen; ik zal vanavond wel even kijken.
 
OctaFish kan je mij helpen met die functie maken?
Heb eingelijk geen idee waar ik dan moet beginnen, maar wil het wel graag leren hoe je zo functie in elkaar zet.
Met Dlookup in de query is het wel gelukt.
 
Laatst bewerkt:
OctaFish kan je mij verder op weg helpen?

Heb een voorbeeld erbij gedaan waarmee het factuuradres opgezocht wordt met dLookup in de query.
Deze staat in qryFactuur.

Maar nu vraag ik mij af hoe ik die afgesproken prijs bij het artikel krijg in qryFactuur?

Kan je mij ook laten zien hoe je die functie maakt?
 

Bijlagen

Met die functie ben ik al een beetje aan het stoeien; ik zal hem verder baseren op je nieuwe voorbeeldje, want die oude is volgens ook mij niet helemaal geschikt meer.
 
In het eerste bestandje is alleen de tabel debiteur aanwezig.

In de nieuwe versie heb ik de tabellen toegevoegd:
Order en orderregels
Artikel
Prijsafspraken

En toen liep ik vast, omdat ik niet wist hoe ik het afgesproken bedrag bij de juiste klant/artikel krijg.

En zet je alle artikelen in de tabel prijsafspraken of check je eerst of er een afwijkende prijs is in de prijsafspraken tabel.
Zo niet dan hanteer je de richtprijs uit de tabel Artikel
 
Laatst bewerkt:
Was je al iets verder gekomen OctaFish?

Het gaat om de volgende vragen:
-Functie voor factuuradres
-Hoe krijg je de afgesproken prijs bij de order (met relaltie leggen lukt dat niet)
-Welke prijzen leg je vast in de tabel prijsafspraken? Alleen waarvan de prijs anders is dan de afgesproken prijs of alle prijzen?
-Sla je de prijs op in de tabel van de order? of geef je met datums aan tot wanneer die prijs geldig is.

Misschien handig om te weten:
wij facturen 1 x per week. Dus op het factuur komen meerdere leveringen/orders.
 
Als ik het goed begrijp, wil je van het hoofdkantoor zowiezo het (factuur)adres gebruiken, en van de debiteuren het adres van het hoofdkantoor als het selectievakje [Factuurhoofdkantoor] is aangevinkt, en als dat uit staat, het eigen adres. In dat geval heb je eigenlijk helemaal geen ingewikkelde functie nodig, maar kan een Union query het prima oplossen:

Code: 
SELECT tbl_Debiteuren.DebiteurID, tbl_Debiteuren.TypeRecord, tbl_Debiteuren.ParentID, tbl_Debiteuren.Naam, Organisatie.Adres, Organisatie.Postcode, Organisatie.Plaats, Organisatie.FactuurAdres, Organisatie.FactuurPostcode, Organisatie.FactuurPlaats, tbl_Debiteuren.Factuurhoofdkantoor
FROM tbl_Debiteuren INNER JOIN tbl_Debiteuren AS Organisatie ON tbl_Debiteuren.ParentID = Organisatie.DebiteurID
WHERE (((tbl_Debiteuren.ParentID) Is Not Null) AND ((tbl_Debiteuren.Factuurhoofdkantoor)=True))
ORDER BY tbl_Debiteuren.DebiteurID

UNION
SELECT tbl_Debiteuren.DebiteurID, tbl_Debiteuren.TypeRecord, tbl_Debiteuren.ParentID, tbl_Debiteuren.Naam, tbl_Debiteuren.Adres, tbl_Debiteuren.Postcode, tbl_Debiteuren.Plaats, tbl_Debiteuren.FactuurAdres, tbl_Debiteuren.FactuurPostcode, tbl_Debiteuren.FactuurPlaats, tbl_Debiteuren.Factuurhoofdkantoor
FROM tbl_Debiteuren INNER JOIN tbl_Debiteuren AS Organisatie ON tbl_Debiteuren.ParentID = Organisatie.DebiteurID
WHERE (((tbl_Debiteuren.ParentID) Is Not Null) AND ((tbl_Debiteuren.Factuurhoofdkantoor)=False))
ORDER BY tbl_Debiteuren.DebiteurID

UNION 
SELECT tbl_Debiteuren.DebiteurID, tbl_Debiteuren.TypeRecord, tbl_Debiteuren.ParentID, tbl_Debiteuren.Naam, tbl_Debiteuren.Adres, tbl_Debiteuren.Postcode, tbl_Debiteuren.Plaats, tbl_Debiteuren.FactuurAdres, tbl_Debiteuren.FactuurPostcode, tbl_Debiteuren.FactuurPlaats, tbl_Debiteuren.Factuurhoofdkantoor
FROM tbl_Debiteuren
WHERE (((tbl_Debiteuren.ParentID) Is Null))
ORDER BY tbl_Debiteuren.DebiteurID;

De prijzen zijn nog onderwerp van studie ;)
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan