Database meerdere EHBO tassen

Ik ben redelijk nieuw in MS Access maar wil graag een database maken met een speciaal doel:

De database beheerd meerdere EHBO tassen van een non profit vereniging met wat de inhoud van deze tassen is.

Dit is niet zo moeilijk maar elke tas heeft een eigen unieke RFID tag zodat ik precies weet welke data er bij welke tas hoort.

En ik wil in de database een optie welke bijhoud of er geen steriele producten zoals snelverband over de houdbaarheids datum gaan.

Wie kan / wil mij helpen heb nog geen idee hoe dit het beste op te zetten

Heb nu twee tabellen gemaakt

1. Assortiment = hier staan de producten in : Product naam
: Steriel (ja/nee)
: Info
: Aantal
: EXPDt
: Leverancier
: Prijs per stuk

2. Leverancier = overzicht van leveranciers met contact gegevens

De leveranciers lijst is gekoppeld met de assortiment lijst dus dat werkt.

Maar weet nu effe niet meer hoe ik het beste verder kan hopelijk wil iemand mij helpen ?? Helaas is er geen budget om een database te laten ontwerpen

Dank je wel voor het aanpassen helemaal niet aan gedacht dat "Wie kan mij helpen" niets zegt over mijn probleem

Ik zou een onderscheid maken tussen de producten (assortiment) en de productexemplaren.
In producten: algemene info (ID (meestal autonumber)naam, omschrijving, leverancier), exemplaren: fysieke exemplaren: examplaarID (autonumber) , productID (long integer -> link naar tabel producten), prijs (deze kan in de tijd evolueren, dus hoort bij het specifieke exemplaar), aanschafdatum, steriel ja/nee, geldigheidsdatum, aantal exemplaren
Dan nog een tabel met je kits: ID, code, omschrijving
koppeltabel tussen kits en exemplaren: kit ID, exemplaar ID, aantal exemplaren in deze kit.

Voor de rest hangt het grotendeels af van wat je ermee wil doen.
Als je de samenstelling van een kit wil beheren kan je misschien eens naar een BOM (Bill Of Materials) voorbeeld kijken, die zijn op het internet overal te vinden. bvb http://www.databaseanswers.org/data_models/bom/index.htm


Vriendelijke groeten
Noëlla

Ik zou de productprijs zeker ook in de producten tabel opnemen, en niet alleen in de tabel Inventaris (zo zou ik de tabel met fysieke objecten noemen) zetten. Bij elke nieuwe tas inrichting heb je de prijs namelijk nodig, en die haal je doorgaans uit je producten tabel. Ik zou denk ik kiezen voor een handmatig ID veld, omdat je product codes wellicht betekenis hebben, en je dan makkelijker kan filteren op bepaalde producten. Al kan je dat met een categorie veld ook oplossen. Daarnaast zou ik ook zeker het artikelnummer van de leverancier erbij zetten, wat handig is bij verdere bestellingen.

Als je de prijs bij het product zet, hoe los je dan de volgende cases op: de ene keer krijg je bv. een kwantiteitskorting, de andere keer niet, of de prijs stijgt maar voor de oude artikelen moet je nog de oude prijs gebruiken?

Prijzen die je gebruikt zijn per definitie prijzen dagprijzen; in je productentabel leg je altijd de actuele dagprijs vast. Op het moment dat je een nieuwe prijs doorkrijgt van de leverancier, verander je die bij het product. Zodra je gaat bestellen, gebruik je een andere tabel om de bestelgegevens op te slaan. Hier zit uiteraard óók een veld Prijs in, gebaseerd op het product. Deze prijs haal je op middels de keuzelijst waarin je het productID kiest; de actie <Bij klikken> op deze keuzelijst vult ook de actuele prijs in het veld Artikelprijs. Dit is een bewerkbaar veld, dus je kunt de prijs altijd overschrijven, mocht dat nodig zijn. Bij de bestellingen heb je dus de daadwerkelijk te betalen/ontvangen prijs.

(Kwantum)kortingen kun je wellicht al vastleggen in de product tabel, zodat je op basis van het aantal bestelde artikelen al gelijk weet oeveel korting je krijgt. Ook hiervoor geldt: je kunt de korting altijd overschrijven in afwijkende gevallen. Als je meerdere kortingspercentages hebt bij verschillende aantallen, dan is een gekoppelde tabel nog een optie.

Lijkt me wat ingewikkeld voor een simpele database die verzorgingskits wil bijhouden. De simpelste manier lijkt me om op het moment dat je de artikelexemplaren geleverd krijgt die in te vullen met de prijs van dat moment. Als je bij nieuwe bestellingen wil kijken hoeveel dat ongeveer zal kosten kan je gewoon nagaan hoeveel je de vorige keer betaalde. Het hangt ervan af hoe uitgebreid de database moet zijn.

Ik ben al in overleg met TS aangaande de db. Jouw optiek lijkt mij sowieso niet de simpelste oplossing, al was het maar omdat je eerst de oude prijs moet gaan opzoeken . Ik heb zat databases gemaakt met de door mij voorgestelde structuur, en veel makkelijk in het gebruik dan dat krijg je ze echt niet .

Succes, laat ons ook hier iets weten want ik denk dat er wel meerdere geïnteresseerd zijn in je oplossing. Je aanpak is zeker correct.

Alhoewel ik het een tegenspraak sine qua non vind om een professionele aanpak in Access te maken. Wat zeker niet bedoeld is als een aanval .

https://medium.com/young-coder/microsoft-access-the-zombie-database-software-that-wont-die-5b09e389c166

Ik heb nog niemand hier zien spreken over een ‘professionele aanpak’ . Laat staan een tegenspraak . Neemt niet weg dat je in Access best toepassingen kan maken voor professioneel gebruik. Zoals met (bijna)alles in het leven, heb je voor verschillende gradaties van problemen verschillende gradaties oplossingen. Zo vind ik een vrachtwagen heel geschikt voor verhuizingen, maar doe ik mijn boodschappen toch liever in mijn personenwagen. Terwijl er toch echt veel meer in die vrachtwagen past .