Te gebruiken tabellen bij voorraadbeheer (Access 2003)

Hallo,

Met (op dit moment nog) geringe kennis van Access toch aan het proberen om een voorraadsysteem te bouwen.

Na veel adviezen om NoordenWind eens goed door te nemen loop ik toch tegen een tabellenprobleempje op, dat in hierin niet aan de orde komt.

Op dit moment het ik een tabel "artikelen" en een tabel "leveranciers" welke aan elkaar gekoppeld zijn door de sleutel "LeverID".
Aangezien in het systeem zowel verkoop als inkoop moet kunnen worden ingevoerd was ik van plan om onderstaande tabellen op te nemen:

• voorraadmutaties
• Inkoop
• Verkoop (Kas en Bank moet wel worden gescheiden)

Mijn plan was om de tabellen "Inkoop" en "Verkoop" te koppelen aan het tabel "voorraadmutaties"
Mijn vragen hierover zijn de volgende?

• Kan ik in het tabel "voorraadmutaties" zowel een referentiesleutel voor het tabel "Inkoop" alsook voor het tabel "Verkoop" plaatsen of is het beter om alle mutaties in enkel het tabel "voorraadmutaties" op te nemen?
• Is het mogelijk om in mijn voorgenomen oplossing ook nog het stukje Kas en Bank scheiding aan te brengen? (neem aan via een tabel "betaalmethode" welke ook gekoppeld wordt aan het tabel "Verkoop" of, indien enkel het tabel "voorraadmutaties" wordt geadviseerd, gekoppeld aan het tabel "voorraadmutaties")
• Kan ik het tabel "Leverancier" behalve aan het tabel "artikelen ook aan het tabel "Inkoop" koppelen? De inkoop zal later toch per leverancier opvraag baar moeten zijn.

Als iemand een betere oplossing heeft dan hoor ik dat heel graag. Wel dan heel graag voorzien van wat achtergrond info aangezien ik graag mag begrijpen waarop iets op een bepaalde manier gaat.

Alvast superbedankt voor je/jullie reacties

Groetjes

Inkoop en Verkoop is in beginsel dezelfde handeling, alleen met andere boekwaarden: bij inkoop wordt de voorraad verhoogd, en bij Verkoop gaat de voorraad uiteraard de andere kant op. Dus je kunt dat in beginsel wel in dezelfde tabel verwerken. Heb je in je artikelen tabel maar (en altijd) één leverancier per artikel? Zo niet (je hebt artikelen die door meerdere leveranciers geleverd kunnen worden) heb je eigenlijk een tussentabel nodig, bijvoorbeeld tLevert. Hierin leg je dan de artikelID en LeverancierID vast, met de artikelnummers en prijzen die de betreffende leveranciers rekenen.
Ik zou dus met één tabel Voorraadmutaties werken, waarbij je waarden optelt of aftrekt. Hou het simpel...

Super bedankt OctoFish,

Soms ga ik idd te moeilijk denken

Trouwens.. het is idd zo dat de materialen slechts 1 leverancier hebben dus kan ik dit op deze manier wel goed opvangen.
Wel is het zo dat ik nog niet weet of dit in de toekomst gaat veranderen. (wellicht moet ik op een dergelijk mogelijk veranderlijk feit toch al inspelen)

Wel nog een vraagje: Zoals ik al had aangegeven heb ik de tabel leveranciers gekoppeld aan het tabel artikelen, echter deze leveranciersgegevens moeten ook in relatie staan tot het bestelformulier. Kan ik deze leverancierstabel dan nog wel koppelen aan het tabel facturatie (welke op zijn beurt in relatie staat met de tabel voorraadmutaties) ?

Alvast bedankt voor het meedenken

Groetjes

Koppelen van tabellen doe je als je af wilt dwingen dat gegevens in tabel A moeten bestaan in tabel B. Bij een bestelling van een artikel zul je dat artikel bestellen bij een bestaande leverancier, dus is het logisch om Referentiële integriteit af te dwingen tussen tArtikel en tLeveranciers. Hetzelfde geldt bij Voorraad en Artikelen; je wilt geen voorraad bijhouden van artikelen die niet bestaan. Bij een factuur zul je ook alleen artikelen factureren die je kunt leveren/bestellen. Dus tussen die tabellen leg je dan een relatie. Omdat je een relatie hebt tussen Artikelen en Leveranciers, heb je automatisch ook een relatie tussen Leveranciers en facturen. Als je geen niet-bestaande artikelen kunt leveren of bestellen, kun je dat ook niet doen bij niet-bestaande leveranciers. Het is dan verder niet nodig om nog extra koppelingen te leggen tussen leveranciers en facturen.

Bovendien kun je ook beperkingen vastleggen op je formulieren, waar je met keuzelijsten kunt afdwingen wat er gekozen mag worden. Bedenk ook of een relatie het werken van het systeem niet onmogelijk maakt; stel dat je een bestelling krijgt voor een artikel dat je nog niet in het systeem hebt, maar wat je wel kunt leveren. Als de relatie te dwingend is, kan je die bestelling dan niet verwerken zonder eerst het artikel op te voeren. Hetzelfde voor een nig niet ingevoerde klant. Je wilt in zo'n situatie de order wel kunnen opslaan, waarna je dan later de ontbrekende gegevens toevoegt.

He Michel,

Kijk... met deze informatie kan ik echt verder. Je legt precies uit hoe en waarom.. helemaal super.

Nog 1 laatste vraag voor ik dit topic sluit:

Je hebt me ervan overtuigd dat ik met een tabel VoorraadMutaties moet gaan werken. Nu wil ik uiteraard zoveel mogelijk dubbele invoer voorkomen en vroeg me af of mijn denkwijze goed is.

Ik ben van plan om aan het tabel VoorraadMutaties de volgende velden toe te kennen:

• VoorraadMutatieID (primairy key)
• Mutatiedatum
• ArtikelID (referentie key voor tabel artikelen)
• MutatieSoortID (referentie key voor tabel MutatieSoort)
• InkoopOrderID (referentie key voor tabel InkoopOrder)
• Aantal

In het tabel MutatieSoort zullen dan alle verschillende soorten voorraadmutaties in een veld genaamd "mutatiesoorten" komen te staan (bv zoals Verkoop Kas, Verkoop Bank, Stuks besteld, Stuks ontvangen, maar ook bijvoorbeeld Financiele afboekingen zoals tekorten enz)

Nu zit ik er een beetje mee in mijn maag of dit wel goed gaat komen. In principe is het zo dat ik wil dat de gegevens uit tabel "MutatieSoort" wil laten bestaan in de tabel "VoorraadMutaties" dus die voorwaarde zit goed. Ook is het zo dat iedere Voorraadmutatie slechts 1 Mutatiesoort kent, maar dat een Mutatiesoort wel vaker dan eens in voorraadmutaties voor kan komen. een ��n-op-veel relatie dus.

Hetgeen waarmee ik in mijn maag zit is dus eigenlijk het InkoopOrderID. Ik wil deze eigenlijk koppelen aan voorraadmutaties zodat ik bij iedere InkoopOrder makkelijk kan acherhalen welke producten er ingekocht zijn in die desbetreffende order. Dit zorgt voor nogal wat gaten in het tabel voorraadmutaties omdat niet iedere mutatie een Inkooporder is en deze tabel dus niet altijd gevuld hoeft te worden.

Als 2de optie heb ik in mijn hoofd om de gehele tabel MutatieSoort te laten vervallen en alle velden die ik daarin bedacht had in het tabel "Voorraadmutaties" te plaatsen. Wel krijgt de tabel "voorraadmutaties" dan een veld genaamd "MutatieOmschrijving".
In dit geval vroeg ik me af of dit tabel dan wel goed genormaliseerd (zo noemen ze dat toch) is, aangezien er dan nogal wat herhalende waarden in het veld "MutatieOmschrijving" gaan komen.
Daarnaast leek optie 1 (inclusief tabel MutatieSoort) mij beter omdat de database daarmee ook kleiner wordt gehouden. Je hebt maar 1 veld voor aantallen nodig, terwijl als ik het tabel "MutatieSoort" weg laat er in het tabel "VoorraadMutaties best veel velden voor de verschillende aantallen nodig zijn.

Ben benieuwd hoe jij hier tegenaan kijkt. Wellicht denkt ik weer iets te veel haha

Groetjes
Ren�

renew000 zei:

In het tabel MutatieSoort zullen dan alle verschillende soorten voorraadmutaties in een veld genaamd "mutatiesoorten" komen te staan (bv zoals Verkoop Kas, Verkoop Bank, Stuks besteld, Stuks ontvangen, maar ook bijvoorbeeld Financiele afboekingen zoals tekorten enz)

Klik om te vergroten...

In een tabel Voorraad mutaties moet je alleen daadwerkelijke mutaties willen vastleggen. Dus of er voorraad bijkomt, of afgaat. Een keuze als "Stuks besteld" vind ik dus niet in mutaties thuishoren. Pas als je de goederen gaat inboeken, wordt de voorraad verhoogd, anders niet. Op basis van de transacties verandert de voorraad; je zou er nog voor kunnen kiezen een apart veld te gebruiken voor de eigenlijke Voorraad. Dit veld laat je dan berekenen op basis van de keuzelijst. Bij verkoop (een aantal opties bij jou) verlaagt de voorraad, bij inboeken verhoogt hij. En bij inventariscontrole kun je op die manier ook simpel de voorraad actualiseren.
Ik vraag me af of je voor de voorraadmutatie types een aparte tabel moet maken; je kunt ook volstaan met een Lijst met waarden. Al is een tabel makkelijker te onderhouden, als je veel variaties verwacht (denk 't trouwens niet).

Wederom bedankt voor je adviezen.

Het leuke aan dit project is dat het voor mij een manier is om mezelf Access enigzins aan te leren, maar dit is niet een project dat voor mijzelf is.
Dit laatste maakt het juist interessant omdat ik keuzes moet maken waardoor de gebruiker(s) hiervan op een makkelijke manier het programma kunnen gebruiken, maar ook onderhouden.
Dit is dan ook de reden dat ik wel tabellen wil gebruiken voor zaken zoals voorraadmutatie types.

Wellicht zal ik nog meer vragen stellen mbt dit project, al zijn deze vragen nooit zonder eerst goed te hebben nagedacht en zoek ik vaak meer bevestiging voor mijn (juist of onjuiste) keuzes.
Na veel op het forum te hebben gelezen ben ik ook erg blij dat juist jij op mijn vragen hebt gereageerd omdat in jouw feedback op vragen van andere gebruikers jij de uitleg van je keuzes superduidelijk toelicht, waarvoor dank.

Groetjes
René

Dank voor het compliment! Ik ben van mening dat een antwoord an sich iemand vaak wel verder helpt, maar dat je op de lange termijn meer bereikt als je iemand het inzicht meegeeft waarom iets wordt gedaan. Daar leer je namelijk meer van. Nadeel is wel dat ik per antwoord meer strekkende meters moet typen

Hoop nog veel van je te leren,

Dit onderwerp zal ik voor nu sluiten

greetz

Toch nog even geopend, want ben nu bezig geweest om een MutatieTabel, Mutatiesoorttabel en MutatieDetailTabel te maken. Maar nu loop ik te klooien met een InkoopOrderTabel. In principe wilde ik deze koppelen aan het MutatieTabel, maar nu ik een MutatieDetailTabel hebt lijkt het me handiger om deze aan dit tabel te koppel. Het is toch niet zo dat er bij elke MutatieDetailRecord verplicht een ID van het InkoopOrderTabel moet staan.

Is het trouwens zinvol/mogelijk om het MutatieSoortTabel zowel aan het MutatieTabel alsook aan het MutatieDetailTabel te koppelen. Het leek mij namelijk dat als ik het MutatieSoortTabel aan het MutatieDetailTabel koppel en vervolgens het MutatieDetailTabel weer aan het MutatieTabel koppel dit genoeg moet zijn voor het MutatieTabel om de gegevens uit MutatieSoortTabel uit te lezen.

Oja, ik zag nog iets. Ik heb in mijn tabel Artikelen ook een veld "voorradig" staan, maar volgens mij staat deze hierin ook niet goed aangezien dit een veranderlijk feit is en eigenlijk helemaal niets over een artikel zegt. Ik kan volgens mij dus volstaan met een veld "voorradig" (of zoals jij dat noemde "eigenlijke voorraad") in het tabel VoorraadMutaties? toch

Eigenlijk zoek ik bevestiging, maar de ervaring leert mij inmiddels dat er wellicht weer een denkfout bij mij optreedt haha

greetz

Op basis van tabelnamen is het een beetje lastig om nu exact te zien wat je aan het doen bent; daarvoor zou je een voorbeeldje moeten meesturen. De manier waarop je de tabel InkoopOrder koppelt aan MutatieDetail kan misschien anders, maar nogmaals, daar zou ik de tabellen voor moeten zien. Kijk anders eens naar de eerste hoofdstukken over Normaliseren van de Access cursus, of google eens op dat woord.
Een Inkoop record zal in beginsel de Ordergegevens bevatten zoals LeverancierID en Besteldatum. Een tabel InkoorOrderDetails bevat dan de gespecificeerde artikelen en aantallen, met een koppeling naar InkoopOrder.
Op basis van de records uit de InkoopOrderDetails moet de tabel MutatieDetail (die snap ik dus niet helemaal, want heb je aan de tabel Mutaties niet genoeg?) worden bijgwerkt; wat de inkoopgegevens daarbij doen weet ik eerlijk gezegd niet, tenzij je wilt bijhouden op basis van welke inkooporder een mutatie is gedaan. Tenzij je verwacht dat bestellingen niet vaak in één keer geleverd worden, en dat je dus meerdere keren een mutatie moet doen bij inboeken.
En een voorbeeldje dat vorig jaar op het forum aan bod is geweest ter inspiratie

Thanks voor dit bestandje... heeft idd veel functies die ik ook nodig heb.

Heb mijn tabellen nu wel zo n beetje rond, maar zit met 1 veld.. Het veld "PrijsPerStuk". Heb hier nog 2 vraagjes over.

• Prijs hoeft toch slecht 1 x als veld te worden gebruikt in het tabel "Artikelen" en niet als 3 als ik verschil wil maken in soorten prijs. (bruto, netto, netto+winstmarge)? Ik neem aan dat ik velden in rapporten kan berekenen met dat ene veld. De prijzen zijn immers altijd vaste percentages.
• Kan ik met het veld "PrijsPerStuk" wel een queri draaien waarbij ik de voorraad kan bekijken, maar ook dus de prijs hierbij gebruiken(staat immers in

Ook zat ik nog na te denken dat er bij het aanvinken van de optie "gerelateerde velden trapsgewijs bijwerken" alle gerelateerde velden zullen worden bijgewerkt. Dit bekend voor mij dat ik bijvoorbeeld niet een artikelnummer dat is vervallen moet gaan overschijven met een ander artikel omdat dan dus alles in de database veranderd. Ook alle mutaties uit het verleden zullen dan deze naam dragen. Of is er een mogelijk dat bij het trapsgewijs bijwerken de geschiedenis met rust wordt gelaten en dat een wijziging enkel voor toekomstige mutaties geldt?

Ik zal ook een printscreentje van mij tabellenstructuur laten zien. Alle aanwijzigingen zijn top Eerst wilde ik naast een mutatietabel ook een soort finacieel tabel, maar begrijp dat ik dat allemaal kan afleiden uit.

Greetz and thanks
Rene

Je geeft zelf al de antwoorden op je vragen, dus dat scheelt ons! Al is een deel van je tweede bullet weggevallen, dus daar moet ik ook een slag naar slaan.
Een artikelnummer dat is vervallen moet je natuurlijk nooit hergebruiken, relaties bijwerken of niet. Je bestellingen en orders op basis van dat nummer hebben dan inderdaad ineens een heel ander artikel. Altijd nieuwe nummers gebruiken dus, en vervallen artikelen aanduiden middels een Ja/Nee veld [Vervallen].

Fijn om te horen dat ik enkel naar bevestiging vraag , maar dacht kan toch beter de fundering van mijn proggie bij een beter onderlegd gebruiker laten checken..

Wat ik me wel afvroeg... is er een bepaalde werkvolgorde die ik het beste aan kan houden of is access zo meedenkend geweest dat ze de werkvolgorde eigenlijk al in de navigatie hebben verwerkt? Hiermee bedoel ik dat tabellen bovenaan staat in het objectenscherm.

Iig bedankt tot hier

greetz

Access denkt niet mee in de volgorde van objecten, al begrijp ik niet helemaal wat je daarmee bedoelt. Sortering gebeurt doorgaans alfanumeriek. Overigens zie ik in je afbeelding dat je de tabellen Categorie en Subcategorie zonder referentiële integriteit gebruikt. In dat geval kun je de relaties net zo goed verwijderen, want die zijn in deze vorm volkomen overbodig en nutteloos.

Beste Michel,

Ben vanmiddag nogal tegen een tegenvaller opgelopen. Naast het voorraadproggie dat ik wil maken is er ook een kassa. Nu wilde ik al op toekomstige veranderingen inspelen door de artikelnummer niet 3 tekens (zoals ze nu zijn), maar 4 tekens te laten bevatten. Dit zou in mijn artikeltabel ook de primairy key worden.
Nu ben ik er dus achter gekomen dat de kassa slecht maximaal 700 verschillende artikelnummers kan bevatten. De nummers die in de kassa staan gebruik ik dus ook als zijnde de artikelnummers in de database.

In een vorige post heb ik al van je gehoord dat het eigenlijk een vereiste is voor een nieuw artikel ook een nieuw artikelnummer aan te maken (ivm het aantasten van eerder opgeslagen data).

Nu vroeg ik me af of het toch mogelijk is op 1 of andere manier om artikelnummers die vervallen te hergebruiken zonder dat dit effect heeft op reeds bestaande data. Het gaat uiteraard om dezelfde artikelen maar dan van andere merken en prijzen.

Greetz
Rene

Dat is een ingewikkelde zaak, want je wilt uiteraard voorkomen dat artikel 081 (Harde schijf van 1 TB bijvoorbeeld) die je 80 keer verkocht hebt ineens een draadloze muis wordt, omdat je het artikel verandert. In je tabel met Artikelen heb je dan een ander artikel staan als de artikelen die in de tabel Verkoop zijn opgeslagen. Of Mutaties....
Er zijn wel workarounds te bedenken, maar echt geweldig zijn die allemaal niet. Je kunt er voor kiezen (je zult wel moeten) om in de tabel Artikelen een ander veld als sleutelveld te definiëren, want ArtikelNr zal dus meerdere keren worden ingevoerd. Bijvoorbeeld een veld ArtikelID met gegevenstype Autonummer. Om onderscheid te maken tussen de verschillende artikelen in je transactie tabellen zul je het artikelnummer ook nog moeten uitbreiden met een veld Actief, en eventueel een datumveld voor de inactief datum. Je kassa baseer je op de tabel met actieve artikelnummers (die dus kunnen wisselen), maar het veld dat je opslaat in de tabellen is dan het ArtikelID veld.

Thanks voor t meedenken... het enige probleem in de oplossing die ik zie is dat ik artikelen in een formulier wil kunnen opvragen aan de hand van het 3 cijferige artikelnummer (dat ook in de kassa staat).
Dit omdat deze nummers ook op de kassarol staat die als fysieke input voor afboeken van voorraad gaat dienen.

Is het anders mogelijk om een primairykey te maken van de velden "ArtikelNummer" (het 3 cijferige nummer met als gegevenstype tekst) en "UitVoorraad" (met ja/nee gegevenstype)?

Immers, het gaat om vervanging van een artikel en dan is ook iedere waarde uniek. Er bestaan namelijk nooit 2 dezelfde artikelnummers die voorradig zijn. Al kom ik er tijdens mijn typen wel achter dat er misschien (en dat is goed genoeg) 2 dezelfde artikelnummers zijn die beide niet voorradig zijn. Of kan ik dat oplossen door een 3de veld aan mijn primairykey toe te voegen (of is dat weer te veel).

Wellicht is mijn hele suggestie overbodig omdat jou oplossing wellicht wel mijn probleem (het opvragen van een artikel op artikelnummer) ondervangt...

Elke keer log ik weer met plezier aan op helpmij simpel omdat ik iedere keer weer iets meer komt te weten van access.. thanks daarvoor

greetz
rene

Je geeft zelf al aan dat jouw idee niet gaat werken. De verklaring is heel simpel: een Ja/Nee veld heeft maar twee waarden (als je NULL niet meerekent): 0 of -1. In combinatie met een Artikelnummer heb je dus maar twee unieke combinaties: [Art087]+[0] en [Art087]+[-1]. En deze sleutelcombinatie houdt dus in dat je elke combinatie maar één keer mag gebruiken.
Zelf zou ik dus op mijn voorstel verder zoeken. Wel dus een statusveld Actief (of UitVoorraad, wat je wilt) om te bepalen welk artikelnummer je wilt zien op je formulier. Dat is dus het actieve artikelnummer; zodra een artikel wordt vervangen en er een nieuw artikel is toegevoegd met hetzelfde artikelnummer, wil je dat nieuwe artikel zien, en niet meer het oude.
Dat filter je dus op basis van ofwel het statusveld, ofwel op een datumveld. Als je een datumveld gebruikt, bereik je namelijk hetzelfde: als een artikel uit voorraad gaat, vul je de datum waarop dat ingaat in. Een artikel dat actief is, heeft geen datum. En is dus per definitie actief.

Hallo Michel,

Thanks voor de hulp, ik zal jouw advies eens proberen uit te werken. Voor nu weet ik even genoeg en sluit ik dit topic.

Ongetwijfeld tot later

greetz