Klopt dit?

[headlight]

ik probeer een database te maken voor voorraadbeheer.

een locatie kan meerdere voorraad hebben, voorraad meerde locaties.
Een medewerker kan meerdere voorraad hebben, voorraad meerdere medewerkers.

ik heb het gevoel dat ik ergens iets verkeerd doe, maar weet niet wat.

 

[OctaFish]

Beschrijf het proces eens; aan het plaatje zie ik een hoop bijna lege tabellen, en ik vermoed dat het wel wat simpeler kan. Maar dan moet ik wel weten wat je precies wilt doen met de db. Sowieso vermoed ik dat je de verkeerde sleutelvelden gebruikt (eigenlijk niet namelijk). Ik neem althans aan dat het veld Lokatie een tekstveld is. Gebruik bij voorkeur numerieke velden (LokatieID, VooraadID etc) om unieke sleutels te maken, en gebruik de tekstvelden als (inderdaad...) tekstveld met de omschrijving van het tupel.

 

[headlight]

er is een totale voorraad welke verdeelt in 2 magazijnen ligt, en bij 4 medewerkers in de bedrijfswagens.

ik probeer een eenvoudige database te maken waarin te zien is wie waar hoeveel voorraad (voorraad is meerdere artikelen, welke apart geteld worden)

dus stel de voorraad is 100 stuks van v1 en 300 v2,

medewerker 1 heeft 50 stuks v1 en 100 stuks v2
medewerker 2 heeft 40 stuks v1 en geen v2
medewerker 3 heeft 10 stuks v1 en 200 stuks v2
medewerker 4 heeft geen voorraad.

voordat er besteld word moeten ze weten hoeveel er is, en hoeveel er bij moet komen. omdat een verschil in actuele en bestelde voorraad kan oplopen tot een boete 200 euro per stuk voorraad is dit van belang.

 

[OctaFish]

En is je bestelprocedure gekoppeld aan de voorraadtabel? Want die mis ik in het plaatje.

 

[headlight]

En is je bestelprocedure gekoppeld aan de voorraadtabel? Want die mis ik in het plaatje.

ik heb er voor gekozen die buitenwege te laten sinds dat voor de medewerkers niet van belang is.

het gaat erom dat ik kan zien waar welke voorraad zich bevind en of de aantallen kloppen met het bestelde.
hierop kan ik dan de benodigde voorraad bestellen en mensen attenderen dat ze een verschil hebben en dat ze dat na moeten gaan.

 

[OctaFish]

Normaal gesproken zou ik e.e.a. toch aan elkaar gekoppeld willen zien. Want bestellen en vooraad zijn m.i. onlosmakelijk verbonden. Maar zoals ik al eerder zei: ik vind je opzet nogal vreemd. Normaal gesproken heb je voor voorraadbeheer andere tabellen nodig:
1. een tabel tArtikelen met een ArtikelID, Omschrijving, Minimum voorraad etc
2. een tabel tMedewerkers/tVoertuigen.
3. een tabel tLocaties met een LocatieID, Naam, Postcode etc.
4. een tabel tVoorraadmutaties met een veld ArtikelID, MedewerkerID/VoertuigID, LocatieID, soort mutatie, mutatiedatum, aantal etc.

Ik maak even geen onderscheid tussen medewerkers en voertuigen, wat jij nog wel doet. Dat onderscheid wordt echter bepaald door de 'eigenaar' van de artikelen. Als een medewerker verantwoordelijk is voor een bepaalde voorraad, en die dus altijd op de man is te traceren, dan gebruik je MedewerkerID. Ligt de voorraad vast in bedrijfsauto 1, en rijdt op dag1 medewerker x in de auto, en dag 2 medewerker y, dan is de voorraad aan het voertuig gebonden. Medewerker x heeft dan immers op dag 1 andere voorraad in beheer dan op dag 2. Daarbij maakt het niet uit dat medewerker x zelden of nooit in een andere auto rijdt dan auto 1; zodra de persoon een dag vrij is of ziek, rijdt iemand anders vermoedelijk in auto 1 en die zal dan niet de complete inhoud vervangen door zijn eigen voorraad. Maar nogmaals: als dat bij jou wél het geval is, dan moet je dat dus zo inrichten.

Voorraad heeft dus een locatieID om te bepalen uit welke locatie een artikel wordt gehaald, en een voertuig om te bepalen waar de voorraad heen gaat. En elke mutatie daarin leg je vast in tVoorraadmutaties. In ieder geval heel wat minder tabellen dan jij nu hebt bedacht .

 

[headlight]

oke bedankt, ik zal het nog eens beter bekijken