Stock-programma

Ik ben voor ons schoolwinkeltje een stockdatabank aan het maken met onder anderen de volgende tabellen:
Artikels (artID, artOmschrijving,..)
Aankopen (aankID, artID, artAantal, artLeverancier)
Artikels per Leerling (artllID, artID,....)

In de tabel Artikels per Leerling komt er per artikel dat een leerling koopt een regel hierin tel ik het aantal keer dat een artikelnummer voorkomt.
In de tabel Aankopen beginnen we met het ingeven van een basisstock en daarna per levering het aantal stuks (hiervan maak ik de som per artikel).

Ik probeer de stock te berekenen. Wanneer ik dit met totalen probeer op te lossen in de querry telt hij wanneer het artikel 2x aan een leerling gekoppeld is, de basisstock en de aankopen ook dubbel (naargelang het aantal keer dat het artikel voorkomt in de tabel "Artikels per Leerling").
Hoe kan ik dit oplossen? (ik hoop dat mijn vraag duidelijk is)

Alvast bedankt!

Ik snap je opzet niet helemaal; de tabel [Aankoop] is denk ik meer een tabel [Inkoop] van artikelen die je bij een leverancier bestelt. Daarbij zou je een veld [MinArt] moeten hebben (vermijd spaties in veldnamen) waarin je de minimum voorraad vastlegt, en een veld [Voorraad] waarin je het stockvoorraad bijhoudt. [Artikelen per leerling] lijkt dan een tabel [Verkoop] waarin je de verkopen vastlegt, die blijkbaar aan de scholieren worden geleverd.
Verkopen splits ik zelf in twee tabellen: een tabel voor de transactie [Verkoop] waarin je de datum en leerling vastlegt, en een tabel [Verkoopregels] waarin je de gekochte artikelen vastlegt. Er daarbij vanuit gaande dat een verkoopactie meerdere artikelen mag bevatten. Als er per verkoop maar één artikel mag worden verkocht, hoeft dat niet. Maar dan heb je dus een behoorlijk beperkende factor in je systeem ingebouwd.

Op basis van de eerste inkoop, en vervolgacties (verkopen, inkopen en inventarisaties) leg je vast hoeveel er binnenkomt en hoeveel er uitgaat. De optelsom daarvan is altijd je actuele voorraad. Eens in de zoveel tijd doe je een inventarisatie, en als alles goed gaat, klopt de uitkomst daarvan met wat het systeem aangeeft. Heel simpel: je begint met 100 artikelen, verkoopt er vervolgens in de tijd 95, (+5), bestelt er 50 bij (+55) en verkoopt er 20 (+35). Bij inventarisatie blijken er maar 33 artikelen in het magazijn te liggen, dus je hebt een uitval van 2 stuks. Breuk bijvoorbeeld, of verkeerde levering. Die mutaties verwerk je uiteraard ook in het systeem.

De totalen zijn uiteraard prima in een query vast te leggen, door de juiste velden op te tellen met de juiste +/- toevoeging.
Ik zou zeggen: doe er een voorbeeld db bij, dat kijkt makkelijker.

Beste OctaFish,

bedankt voor je reactie. Het probleem is dat dit in een groter geheel zit. En een voorbeeld is moeilijk eruit te halen.
ik kan u wel laten zien hoe ik mijn query zou opbouwen:

Een artikel is 5x aan een leerling gegeven hij telt dit 5x
Ik geef voor het artikel een aankoop vb. 10 stuks
Hierbij telt hij 5x 10 omdat in de tabel artikels per leerling dit 5x voorkomt.
Wanneer ik het een tweede aankoop ingeef telt hij dit aantal ook 5x en wordt het aantal uitgedeelde artikels 10..

Kan je hier al iets meer mee?

Alvast bedankt!

Hallo,
in het verleden heb ik reeds meerdere stockbeheerprogramma's voor verschillende bedrijven in de Antwerpse haven geschreven en een constante is: je hebt steeds twee tabellen voor bewegingen in : de hoofdtabel PurchaseOrders (PO's) (dit kan je tabel aankoop zijn), deze is gelinkt aan je tabel leveranciers. In de hoofdtabel zet je de algemene velden zoals leverancier, datum aankoop, leverdatum, ... . Daaraan gekoppeld heb je een gedetailleerde tabel PurchaseOrderLines met de aankooplijnen met artikel en hoeveelheid. Aankopen worden meestal niet per student gedaan dus komen de studenten hier niet bij kijken. Langs de andere kant heb je de uitgaande bewegingen Delivery Orders met een gelijkaardige structuur: Delivery Orders (DO's) met datum bestelling, datum volledige uitlevering , klant (dit kan een leerling zijn), … . Hieraan gekoppeld heb je de tabel DeliveryOrderLines met de detailinformatie: artikel, hoeveelheid, eventueel deelleverdatum, … . Daarboven heb je nog een interne bewegingstabel + detaillijnen om zaken als breuk, stockcorrecties, eventuele herverpakkingen te registreren.
Bega niet de beginnersfout om de stock te berekenen als inkomende goederen - uitgaande leveringen. Voorzie steeds een aparte tabel waarin je de huidige stock registreert. je kan die aanpassen met actiequeries telkens je een beweging registreert (PO, DO, stockcorrectie, …). Dit werkt veel sneller, eenvoudiger en accurater. Meestal wordt zelfs elke week/maand een momentopname naar de stockhistoriektabel weggeschreven.
Alleen met een goede basisstructuur kan je tot een correct stockbeheersysteem komen.

NoellaG zei:

Bega niet de beginnersfout om de stock te berekenen als inkomende goederen - uitgaande leveringen. Alleen met een goede basisstructuur kan je tot een correct stockbeheersysteem komen.

Klik om te vergroten...

Beginnersfout? Lijkt mij niet.... We hebben het hier over een schoolwinkel, geen multinational. De opzet die je in essentie beschrijft is hetzelfde als ik voorstel, dus een beetje dubbel op, en (een stuk) ingewikkelder beschreven.

Het probleem van TS zit, als ik het zo kan bekijken (nogmaals: zonder db kunnen we er eigenlijk niks zinvols van zeggen) in het feit dat hij de verkeerde query maakt. Een Totalenquery werkt alleen goed als je op de juiste entiteiten groepeert. Hoe meer variabelen je toevoegt, hoe meer records je gaat krijgen. Als je wilt weten hoeveel je actuele voorraad is, heb je alleen de mutaties tabel nodig. Dat is dus een tabel waarin je bijhoudt welke bewegingen er zijn in de artikelvoorraad. In die tabel leg je bij verkopen het Bestelnummer vast (komt uit BestelRegels), het ArtikelID (idem) en het aantal. Uiteraard ook het mutatietype (Uit of In). Bij inkopen ook weer het ArtikelID, het aantal en een LeverancierID. En uiteraard de transactiedatum (beiden).

Daarna kun je naar hartelust totaalqueries maken. Om de voorraad te bereken heb je geen leerlinggegevens nodig; alleen de mutaties. Zet je de leerlinggegevens er wél bij, dan krijg je de mutaties per leerling. Ook leuk, maar levert geen informatie op over de voorraad. Gooi dus alle velden weg die niets met je vraag te maken hebben.

ik heb hier een mapje op mijn google drive:

link

in de databank zitten geen leerlinggegevens meer, het excel bestand is de lijst met artikels voor de leerlingen.

Ik heb een poging gewaagd het up te loaden op helpmij, maar kreeg voor de Access file altijd een foutmelding..

Kunnen jullie hiermee verder?

Bedankt nogmaals voor jullie tijd.
Ik werkte nog niet hier op het moment van creatie dus ken ook al het fijne niet wat erachter zit en waarom al dan niet..

Dag Evatar, een access bestand kan niet zomaar opgeladen worden omdat het vba code kan bevatten en dus ook virussen. Gewoon even zippen voor je het verstuurt, dan lukt het.

Maar je bestanden zijn zo prima op te halen, dus laat maar even zo. Waar zit nu het probleem? Er zitten nogal wat tabellen en queries in.

Ik wil dus een querry maken die de stock berekent/weergeeft.

ik heb om te testen bij tbl aankopen 2 aankopen ingegeven ik wil de basisstock hier ook in zetten en zo mee berekenen.
In tbl artikels per leerling staan de verkopen eigenlijk.

Ik probeer via qry Stock de actuele stock te berekenen. Maar daar kom ik op mijn voorgaande problemen terecht..

Bedankt voor de hulp!

Evatar zei:

ik heb om te testen bij tbl aankopen 2 aankopen ingegeven ik wil de basisstock hier ook in zetten en zo mee berekenen.

Klik om te vergroten...

Helemaal correct! [Artkels per leerling] is eigenlijk een onzinnige naam voor de tabel; het gaat namelijk niet om hoeveel artikelen een leerling heeft, het gaat om de transacties. Eén soort transactie is het verkopen/uitgeven van een artikel (aan een leerling), een andere is het inkopen ervan. Een derde is voorraadbeheer. Als je begint met zo'n database, en je hebt een bestaande 'winkel' die je erin zet, dan begin je niet met niks, maar met een basisvoorraad. Dus je beginvoorraad. Maar dat kan gewoon het eerste record (per artikel) zijn van je tabel, waarin je dat vastlegt. Vervolgens krijg je de verschillende transacties waarbij de voorraad muteert (inkoop, verkoop, magazijncontroles etc) waarin je de mutaties vastlegt, en die ene tabel is dus helemaal geschikt om je actuele voorraad uit te destilleren. Totaal onzinnig dus om een aparte tabel te maken voor je startwaarden.

Ik begrijp denk ik niet goed wat je hiermee wil zeggen, moet de databank aangepast worden of is het mogelijk in zijn huidige vorm?

Mod edit: quote verwijdert

Is er een reden waarom je een bericht post met een quote van 14 regels, terwijl je er zelf maar 1,5 terugschrijft? Waarom moet ik mijn eigen bericht nog een keer lezen?

Voorbeeld stock

Dag Evatar,

hierbij vind je een eenvoudig voorbeeld in Access 2016 hoe je met een stock kan werken. Ik neem aan dat je geen stock moet bijhouden voor bv. studiebezoeken, dat deze artikels alleen dienen om de prijs bij te houden.
Ik heb alleen de aankoop kant in het voorbeeld gezet, de verkoop kan gelijkaardig gebeuren. In de aankoop zie je ook de prijs terug komen. dit om te vermijden dat als de prijs van een artikel wijzigt, de aankopen in het verleden ook zouden veranderen. Zoals ik zei, het is maar een eenvoudig voorbeeld dat zeker niet al je topics oplost, maar misschien geeft het je een paar ideeën.

Succes

@Octafish: sorry ik begreep gewoon niet wat je hiermee wilde zeggen.
@NoellaG: Dank je voor de info en het werk, we gebruiken ieder jaar een nieuw bestand (de leerlingen veranderen ieder jaar dus aankopen van een vorig jaar hebben in het huidige jaar ook geen belang meer) het probleem is dat de verkopen op dit moment moeilijk geteld kunnen worden. Hier zou ik vooral graag een oplossing voor vinden. Of indien het mogelijk is, 2 aparte querries die samengevoegd kunnen worden voor een totaalberekening?

Bedankt voor jullie hulp!

Evatar zei:

we gebruiken ieder jaar een nieuw bestand (de leerlingen veranderen ieder jaar

Klik om te vergroten...

Nou en? Dat is toch geen reden om de historie van je database te vernietigen? Je zal maar de prijsontwikkeling van een artikel willen weten. Weg.... De grap van een database is dat je historie bewaart. Anders kun je net zo goed met Excel werken.
Zelfs als je de oudere data niet meer wilt zien, kun je nog steeds op een normale manier met de db werken zonder steeds een nieuwe database te maken. En wordt de db te groot (lees: te traag), dan kun je oudere data naar een historietabel verplaatsen zodat je de data nog steeds kunt raadplegen.

Ik wil best wat klooien aan je db, maar verwacht wel dat je bereid bent om de gekende database principes te omarmen. Ik sta niet te popelen om flutoplossingen te maken die niks met een goed database ontwerp te maken hebben. Dat vind ik dus zonde van mijn tijd. We zijn hier tenslotte om je te helpen met het maken van een goede database .

Dag Evatar,
ik heb een voorbeeld hoe je de verkopen kan registreren aangevuld in het voorbeeld bestand. Je hoeft inderdaad echt niet elk jaar een nieuw bestand aan te maken, maar als je dat wil kan dat natuurlijk.
Het eerste bestand is een overzicht van de relaties, het tweede bestand het voorbeeld met de uitbreiding verkopen.
As je vragen hebt, stel die gerust, maar het kan even duren want morgen vertrekken we naar Parijs voor een weekje