Voorraadtelling in Access

[ppakker]

Hoi,
Ik ben bezig met een access-applicatie voorraadbeheer. Ik heb een tabel "artikelen" ontworpen, waarin o.a. de velden "artikelnummer" (sleutelveld) en "voorraad" voorkomen. Ook is er een tabel "mutaties", waarin naast het sleutelveld "Artikelnummer" ook de velden "voorraadplus" en "voorraadmin" staan. Ik heb een query gemaakt met beide tabellen van waaruit ik een formulier heb ontwikkeld, waarmee de mutaties kunnen worden bijgehouden.
Het lukt me niet om de VBA-code te vinden om, na invulling van plus of min en een druk op een "Bijwerk"-knop, de nieuwe voorraadgegevens te laten berekenen en in te vullen in de velden van de tabel "artikelen".
Ik gebruik Office 2003
Kijk uit naar een oplossing of hulp hierbij.

Pierre

 

[ExcelAmateur]

ppakker,

Had je hier ook al gekeken?

 

[ppakker]

Bedankt voor je meedenken. De v erzameling op het door jou opgegeven adres
heb ik bekeken, maar zie hier een minder genormaliseerde database, die alleen met query's werkt. Ik zoek de oplossing meer in VBA-code, waardoor ik directer kan kommuniceren met de gebruiker. (Vind ik)
Groet,
Pierre

 

[OctaFish]

Kun je een voorbeeldje maken? Zodra je met VBA gaat werken, is het wel zo makkelijk om gelijk de juiste objecten etc. te kunnen gebruiken. Bovendien is het wel handig als we kunnen zien hoe de structuur van de db in elkaar steekt.

 

[ppakker]

Demo

Michel,
Hier zet ik een uitgekleed voorbeeld van de database. Ik ben al een stuk verder in de vormgeving, maar die file werd te groot om via deze plaats te versturen. Zoals je kunt zien heb ik een code geschreven voor de tellingen van de voorraad in de tabel "artikelen", maar ik zou het fijn vinden als een (of meerdere) profs zich daar eens over bogen. Voor al de veiligheid bij het invullen van het formulier "mutaties" is erg belangrijk, daar worstel ik op dit moment mee.
Ben benieuwd naar reacties

Pierre

 

[OctaFish]

Zal er een blik op werpen!

 

[ppakker]

Kun je ook eens kijken naar de mogelijkheid om te voorkomen dat er twee keer dezelfde artikelmutatie wordt doorgevoerd. Ik denk zelf aan het toevoegen van een Boolean- veld "Bijgewerkt" in de mutatie-tabel. Maar dan?

Pierre

 

[OctaFish]

Je kunt (denk ik) niet helemaal uitsluiten dat een artikel twee keer wordt toegevoegd. Tenzij dat in de praktijk is uitgesloten. Maar ik zou me situaties kunnen voorstellen dat een artikel voor de helft geleverd wordt, bijvoorbeeld in de ochtend, en dat 's middags de andere helft komt. En dat wil je dan toch kunnen vastleggen, lijkt mij... Ik zou dan een check inbouwen die het aantal geleverde aftrekt van het aantal bestelde artikelen, en zodra die waarde 0 is, zijn alle artikelen geleverd. Dus: 12 besteld, 9 geleverd=3 te leveren. Zolang de waarde >0, kun je toevoegen. Met zo'n check kun je meteen een limiet stellen aan het max aantal dat je kunt inboeken, want dat mag uiteraard ook niet groter zijn dan Bestel-Geleverd.

 

[ppakker]

Beveiliging aangepast. Probleem met doorvoer gegevens

Michel, en andere bezoekers van dit forum
Bedankt voor je reactie. Ik bedoelde eigenlijk dat ik wilde voorkomen dat, als iemand per ongeluk twee keer op “bijwerken” drukte, er ook twee of drie keer de mutatie werd doorgevoerd.
Ik heb dit opgelost, door de knop “bijwerken,enabled = false” in te stellen. Verder weer een aantal zekerheden ingebouwd.
Het volgende lukt me echter niet.
In het object “form_mutatieform”, de VBA-code van het mutatie-formulier, heb ik een probleem met het bijwerken van het veld “MutOudeVoorraad”in de tabel “mutaties”.
Ik heb in code de vier plekken waar e.e.a. moet gebeuren aangegeven met veel uitroeptekens of veel vraagtekens.
Hoe krijg het zo ver, dat als ik een hoeveelheid "min" of "plus" invul, het veld mutoudevoorraad in de tabel mutaties wordt bijgewerkt, zodat ik steeds weet wat er op elk moment aanwezig was en wat er daarna vanaf is gegaan of bijgekomen. In de tabel "artikelen" gaat dit wel, omdat ik op het moment van "bijwerken" de tabel "artikelen" open heb, Maar ik krijg hier natuurlijk alleen maar de laatste stand van zaken te zien.
Als iemand zijn of haar hulp liever via e-mail geeft, kan dat natuurlijk altijd.
Ben benieuwd of iemand de stoute schoenen aantrekt.

 

[OctaFish]

Om te beginnen: je relaties liggen niet goed; je hebt overal Outer Joins gelegd tussen de tabellen, met als gevolg dat er geen Referentiële integriteit is tussen de tabellen. En dat is wel essentieel. Outer joins gebruik je bij voorkeur in queries; in de relaties moet je eigenlijk altijd Inner joins gebruiken. Het resultaat in jouw tabellen is dat er in de tabel mutaties allerlei gegevens staan die niet uit de brontabellen komen. En de hele grap van relaties is nu juist dat je dàt wilt voorkomen. Door de data in de tabel Mutaties aan te passen kun je de relaties alsnog goed instellen, dus dat zou ik zeker doen.

Verder ben ik thuis al een beetje aan het rommelen geweest met je db, maar daarbij zou ik liever met één mutatieveld Aantal werken, en met een Plus en een Minknop vervolgens bepalen of er wordt toegevoegd, of afgeschreven. In je tabelmutaties kun je dan veel simpeler rekenen, omdat je maar naar één veld hoeft te kijken. De waarde daarin is dan positief, of negatief. Lijkt mij een stuk simpeler.

Het aan-en uitschakelen van een knop is op zich natuurlijk prima, maar daarmee los je het probleem van deel-leveringen niet op, lijkt mij. Tenzij je nog wat extra checks inbouwt. Ik zal kijken of ik er vandaag nog wat tijd in kan steken, anders wordt het vanavond...

 

[ppakker]

Is er niemand meer die raad weet?

 

[OctaFish]

Uhhh.... heb je dan al iets gedaan met mijn tips?

 

[ppakker]

Uiteraard! De relaties heb ik aangepast en op dit moment stoei ik met de plus-, min- en bestel-knoppen. Heb jij nog iets met de berekeningen gedaan?

 

[OctaFish]

Jazekers! Maar wel op basis van één mutatieveld. En de reden daarvoor lijkt mij vrij logisch. Als een getal negatief is, wordt de voorraad verlaagd, en bij een positief getal wordt de voorraad verhoogd. Door gebruik te maken van twee aparte velden, kun je in beide velden iets invullen, met een vreemd resultaat als gevolg. Het lijkt mij ook een situatie die in de praktijk niet voorkomt. Ik zou daarom voor alle mutatievelden maar één veld gebruiken.

 

[ppakker]

Voorraadmutatie versie 3

Het blijft tobben. Zit al dagen te zwoegen op die ene code, die maar niet wil lukken. Ik heb het probleem uitgesplitst in drie bestanden. 1 Demo van de app. zoals ze er nu ligt, een Word-doc met de structuur van de tabellen en een Word-doc waarin ik de code van de bijwerk-knop nog eens heb neergezet.
Ik hoop dat er in dit forum iemand is die me op de juiste weg kan zetten.
Ik ben benieuwd naar reacties zeker ook die van OctaFish

 

[OctaFish]

Dan moest ik maar niet teleurstellen

Ik zou het zo doen... 't Is nog niet compleet uiteraard, want je wilt nog checken op minimum voorraad etc, maar het idee is hoop ik wel duidelijk.

 

[ppakker]

5 Bier

Geweldig Octfisch, als je nu hier was, bestelde ik 5 bier voor jou. Op het idee om de telling via een query te laten lopen was ik nooit gekomen. Het verschil tussen pro en junior lijkt me nu wel duidelijk.

Toch nog een paar opmerkingen c.q. vragen:
- Je hebt een variabele iLaatsteMutatie gedeclareerd, maar in de invulling van strSQL alleen LaatsteMutatie gebruikt. Klein vergissinkje lijkt mij??
- Het vervelende (en dus niet goed) is dat de gedane mutaties niet te zien zijn in de query "Mutatiequery". Ook bij vernieuwing van de query geeft hij niets, ook al zijn de tabellen allemaal op de juiste manier gevuld. Wat kan er aan de hand zijn?
- Bij de functie "Confirm" wordt geen nieuw record geopend. Het lijkt wel of het object DoCmd.GoToRecord, ,acNewRec niet meer werkt, ook niet na de knop "Toevoegen"
- Waarom heb je de opdrachten "Bijwerken,enabled = true" buiten werking gesteld?
- De data "MinimumVoorraad" staan in een andere tabel. Is het moeilijk om die bij de invulling van de tabel Mutaties te betrekken?
- Ook vooruit en achteruit bladeren gaat niet meer in het formulier "Mutaties'"

Je ziet, je bent nog niet van me af. (Misschien voor nog eens 5 bier??)

Groet,
Pierre

 

[ppakker]

Nog even

Michel,
Het probleem van de "onzichtbare query" heb ik ondertussen opgelost. Blijft alleen de vraag hoe het kan dat de knoppen voorruit en terug bladeren op het mutatieformulier niet meer werken. Zelfs als ik ze helemaal verwijder en opnieuw instel gebeurt er niets?????? Ook Confirm() levert nog steeds geen nieuw record op.
Ik denk dat ik de vergelijking met de minimum voorraad heb opgelost.

Hoor ik nog wat?

Pierre

 

[OctaFish]

Ik kan je uiteraard wel antwoord geven op een paar van je vragen
Om te beginnen: de bladerknoppen doen het prima als je een formulier hebt dat is gebaseerd op een tabel. En dat had je ook, hoor ik je al zeggen! Klopt, maar nu niet meer!
Om het formulier wat beter beheersbaar te maken, heb ik het formulier onafhankelijk gemaakt. De reden daarvoor is simpel: alle velden die je wilt kunnen opslaan, haal je op uit tabellen d.m.v. de keuzelijsten. Het voordeel hiervan is dat je geen gedoe hebt met records inlezen, en per ongeluk overschrijven. Alle mutaties worden nu via VBA gedaan, en het enige wat dus gebeurt is dat er een nieuw record wordt toegevoegd aan de tabel Mutaties. Omdat er geen records meer zijn te bekijken, doen de bladerknoppen uiteraard ook niks meer... En hetzelfde geldt voor de knop Confirm (die ik nergens zie overigens...) zal hetzelfde 'probleem' hebben. Om een nieuw record te maken, hoef je eigenlijk alleen de velden leeg te maken.

In de keuzelijst Artikelen heb ik twee velden toegevoegd: Minimum voorraad, en Huidige voorraad. De huidige voorraad wordt met een DLast functie opgehaald op basis van het artikelnummer. De minimum voorraad staat uiteraard in de tabel Artikelen.
Hiermee moet je volgens mij zelf wel de juiste manier kunnen vinden om te checken of er überhaupt een mutatie mag worden gedaan (aantal blijft > dan minimum voorraad).

Wat betreft de 'zwevende' variabele: deze heb ik in eerste instantie wel gebruikt, maar hij bleek later niet nodig te zijn (de oude voorraad is immers de Nieuwe voorraad van het laatste record). Dus vandaar dat je 'm verder niet tegenkomt.
Wat je met 'onzichtbare' query bedoelt weet ik eigenlijk niet... Zoals uitgelegd, op het formulier wil ik geen recordset! Dus ook geen query...

Volgens mij heb ik wel weer een paar pinten verdiend

 

[ppakker]

Het begint langzaam een zuippartij te worden, want ieder 5 bier voor jou zijn er ook 5 voor mij.
De verdwenen query was gewoon een gevolg van een verkeerde join, vandaar.
Confirm is een eigen functie die een keer wordt aangeroepen.
Toch vind ik het vervelend dat ik niet door de records heen kan bladeren, maar alla.
Bestaat er trouwens een manier om met een knop alle velden leeg te maken?

Pierre