Validatie van gegevens door middel van VBA script

[PieterJan1]

Beste forumleden,

Hieronder een vraag met betrekking tot de validatie van gegevens invoer met eventueel gebruik van VBA.

Stel dat:
In tabel A wordt aangegeven dat er van artikel X, 200 stuks aanwezig zijn.
In tabel B worden deze 200 stuks in meerdere malen verbruikt (voorbeeld, 2 maal).




Met een normale validatie regel van Access, in de tabel of het formulier kan ik er voor zorgen dat de waarde niet boven bijvoorbeeld 200 of onder 0 mag zijn.
Bij het invoeren van een 2e verbruik wordt er echter ook een tweede regel aangemaakt en is niet bekend dat er al 75 zijn verbruikt en dat deze waarde niet boven 125 mag komen. Wel kan ik in een query of extra veld uitrekenen wat er resterend is van het artikel, echter hoe kan ik vervolgens met deze waarde verder rekenen?

Mijn vraag is als dit is op te lossen met een VBA code die automatisch de combinatie van X met 75 en X met 125 optelt en laat zien dat de waarde X is verbruikt en vervolgens bijvoorbeeld een Ja/Nee aanvinkt.
Of een andere gemakkelijke manier om dit op te lossen.

Ik ben benieuwd hoe jullie hier over denken.

Met vriendelijke groet,
Pieter

 

[OctaFish]

Ingewikkeld..... Een mutatietabel bestaat m.i. uit twee soorten (of 3) transacties: uitgifte of aanvullen. In het eerste geval maak je een record waarin je het aantal dat er uit gaat neerzet door een negatieve waarde in te geven, in het tweede geval boek je nieuwe artikelen in door een positieve waarde. De totaalsom van het geheel levert de actuele voorraad op. In de Artikelentabel geef je aan wat de minimum voorraad is, en als een bestelling daaronder duikt, bestel je nieuwe. Het aantal dat je kunt uitgeven kan natuurlijk nooit groter zijn dan wat er in voorraad is, maar dat is dus, zoals ik al aangaf, een simpele totaalsom. En dat kun je dus ook simpel checken.
Daarnaast heb je (derde variant) nog een periodieke voorraadcontrole nodig, waarbij je fysiek telt hoeveel er daadwerkelijk zijn. Dat zou hetzelfde moeten zijn als uit je transacties rolt, maar dat is natuurlijk niet altijd het geval (breuk bijvoorbeeld) dus dan voer je een correctief record toe dat de werkelijke voorraad weer op peil brengt in het systeem.

Maar daarvan vind ik in je vraag niet zoveel terug, moet ik zeggen.... Kun je niet een db erbij doen als voorbeeldje?

 

[PieterJan1]

Even heel snel wat in elkaar geprutst. Wist zo snel even niet hoe ik de relaties wou doen.

Het gaat er om dat elk artikel 1x volledig gebruikt kan worden, en daarna niet meer. Het artikel is uniek (daarom primaire key).
In het gefabriceerde formuliertje kan ik dan het artikel verbruiken, en krijg te zien (voorraad artikel) hoeveel er maximaal is. Met een validatie regel in het formulier kan ik er voor zorgen
dat ik niet meer verbruik dan die verschenen waarde. Bij aantalplus geef je dus door hoeveel er op voorraad is(door productie).
Echter als ik dus 2 maal aantalplus doe voor 1 en hetzelfde artikel, krijg ik een nieuwe regel in de tabel en telt ie vervolgens deze 2 waarden niet bij elkaar op om een voorraad van het artikel te krijgen.

Natuurlijk kan ik altijd voordat ik een verbruik in boek, handmatig controleren hoeveel ik nog mag verbruiken, maar dit kan eventueel resulteren in typefouten oid.

Daarnaast is de verkoop (die zal wel bij de mutatietabel in moeten komen) ook pas mogelijk als het is verbruikt voor productie. Hiervoor is dus de regel Aantalmin.

Misschien denk ik wel heel ingewikkeld, het gaat dacht ik iig om veel-op-veel relaties (?),
1 artikel kan meerdere keren worden gebruikt voor productie, en een productie kan bestaan uit meerdere artikelen;
1 productieregel(of artikel) kan meerdere keren worden gebruikt voor verkoop, en een verkoop kan meerdere artikelen bevatten.
(maar als het artikel uit 50 stuks bestaat, kan deze na 50 verkocht te hebben niet weer gebruikt worden).

 

[OctaFish]

Ik heb al aangegeven dat deze werkwijze niet geweldig is, dus dat ga ik niet herhalen . In bijgaand voorbeeld heb ik het dus een beetje aangepast, met één veld voor de mutatie en een extra veld voor het mutatietype. Om het de gebruiker makkelijk te maken heb ik er nog een tabelmacro bijgemaakt die op basis van de mutatiesoort het getal negatief maakt; de gebruiker kan dus een 'natuurlijk' getal intypen zonder zich zorgen te maken of het wel goed verwerkt wordt of niet.
In de query qMutaties kun je het effect het beste zien; het formulier werkt ook wel, maar is wat slomer qua bijwerken. Ik heb verder nog niet gekeken naar de minimum voorraad, maar dat is niet zo heel moeilijk.

 

[PieterJan1]

Hey Michel,

Bedankt voor je reactie en voorbeeld. Ik snap nu wel wat beter hoe je het bedoeld.
Echter is dit niet helemaal wat ik kan gebruiken.

Het lastige is dat het niet zo is als een artikel in de winkel, daarvoor is dit voorbeeld prima. Het geval is zo dat een artikel wordt ingeboekt (dit is ook gelijk de minimum voorraad), en vervolgens vindt alleen afboeking plaats tot de voorraad 0 is. Bij een voorraad van 0 zou het niet meer mogelijk moeten zijn om het te kiezen, en te verdwijnen uit de keuzelijst.

Is het ook mogelijk (misschien via een wisselknop of navigatiebutton?) om bij het aanklikken van “inboeken” een formulier te laten zien waarin het artikel kan worden ingevoerd, dus bijvoorbeeld Appels met een voorraad van 50. Peren met een voorraad van 86, en Pennen met een voorraad van 17.
Geeft het volgende:
Appels: 50 (25-1-17)
Peren: 86 (28-1-17)
Pennen: 17 (29-1-17)

Bij “Afboeken” verschijnen deze drie artikelen in de keuzelijst, en kan alleen afgeboekt worden.
Appels: 50 – 21 (27-1-17) = voorraad van 29 (voor productie)
Peren: 86-2 (29-1-17) = voorraad van 84 (voor productie)
Pennen: 17 – 17 (30-1-17) = voorraad van 0

Bij de volgende keer “afboeken” zijn alleen Appels en Peren beschikbaar. Pennen worden niet weer opnieuw gebruikt.

Daarna volgt pas de verkoop, waarbij een keuzelijst ontstaat zodra een artikel is gebruikt bij het “Afboeken”.
Op 27-1-2017 is dus zichtbaar (voor verkoop):
Appels: 21
Op 29-1-17 is zichtbaar:
Appels: 21
Peren: 2
Op 30-1-17 worden de pennen toegevoegd:
Appels: 21, Peren: 2, Pennen: 17

Verkoop zou dan op dezelfde manier kunnen werken, dus met een mutatie van afboeken waar hetzelfde principe geldt als bij productie. Alleen wordt hier de verkoopdatum ingevoerd met een klant uit de tabel “klanten”.
De wens is vervolgens om een foutmelding te genereren wanneer bij het afboeken een artikel de voorraad < 0 bereikt, een foutmelding te krijgen voordat het record kan worden opgeslagen (of direct na het opslaan om een correctie te boeken).

Ik heb zojuist al even gekeken als ik het veld aantal uit de mutatie tabel kan plaatsen in een formuliertje voor het aanmaken van een artikel, dit kon niet doordat join-sleutel niet overeen komt. Maar dat is denk ik makkelijk op te lossen.
Wel vraag ik mij nu even af hoe ik dit op een goede manier in de tabel relaties kan verwerken.

 

[OctaFish]

Je kunt sowieso een validatie maken die voorkomt dat je waarden invoert onder 0. Zou ik altijd al doen want dat is fysiek onmogelijk en moet je op tabelniveau dus uitsluiten.

 

[PieterJan1]

Er voor zorgen dat een waarde kleiner dan 0 wordt ingevoerd is uiteraard niet zo moeilijk. Waar het mij omgaat is dat er een foutmelding verschijnt zodra de voorraad wordt berekend in de mutatie query en dat er een foutmelding verschijnt zodra
de voorraad lager is dan 0.

Is het ook mogelijk om de sales tabel hier aan te koppelen zodat hier in de artikelen verschijnen met een voorraad?

 

[OctaFish]

Je query werkt op je tabel, dus normaal gesproken werkt de validatie van je tabel ook door in de query, en derhalve ook de melding die je in je validatietekst in je tabel hebt staan.

 

[PieterJan1]

Ik was even dom aan het denken.. ik kan natuurlijk het formulier ook gebruiken voor de verkoop, want de waarde die is ingeboekt is direct de waarde die beschikbaar is voor verkoop…

Is het mogelijk om bij het aangeven van Mutatiesoort: Inboeken
alleen zichtbaar te maken: artikelnaam, productiedatum, voorraad & aantal geproduceerd.

En bij het aangeven van mutatiesoort: Afboeken
Artikelnaam, verkoopdatum, klant, voorraad in kg (formule via de query), en het veld aantal

Het mooiste zou dan wel zijn om meerdere artikelen te selecteren voor 1 verkoop, is dat makkelijk te bereiken?

 

[PieterJan1]

Ik heb wat proberen toe te voegen aan de database.

Als ik nu een query aanmaak waarin ik de voorraad wil berekenen, verschijnen dubbele waarden door het inboeken. De query is dan waarschijnlijk op het verkeerde gebaseerd of heb ik het mis?
Voor een query met nog te produceren artikelen is hetzelfde verhaal van toepassing.
Hoe kan ik dit oplossen?

Graag zou ik nog feedback krijgen voor het boeken van verkopen waarbij ik meerdere artikelen kan gebruiken voor 1 verkoop.
Ik heb dit geprobeerd op te lossen met een subformulier als gegevensblad toe te voegen aan een formulier met mutatie ID, Datum en mutatiesoort.
Maar ik weet niet zeker als dit de manier is om dit te verwerken?
Bekijk bijlage Database.zip

 

[OctaFish]

Ik zal er vanavond even naar kijken.

 

[OctaFish]

Ik mis nog een essentiële tabel: de tabel [Verkopen]. Of hoe je die ook wilt noemen. Een Verkoopactie bevat vaak meerdere artikelen, dus de subtabel [Verkoopregels] (mag ook weer elke naam hebben natuurlijk) hangt met een veld VerkoopID aan de tabel [Verkoop] en de tabel [Artikel] hangt dan aan [Verkoopregels] want elke regel bevat één artikel, met de prijs en het aantal etc. Kijk eens of je hier wat aan hebt, een voorbeeldje dat ik ooit eens voor iemand anders heb gemaakt.

 

[PieterJan1]

Het voorbeeld had ik al eens voorbij zien komen, hier zie ik echter ook geen verkoop tabel? Ik snap het idee er achter wel. Dit is hetzelfde principe als mutatieregels voor productie.

Als ik dit toevoegen aan de database en maak een simpel formulier van de verkooptabel kan ik meerdere artikelen verkopen met 1 mutatie(komt overeen met mijn eerdere formulier)

Hoe kan ik er dan voor zorgen dat er alleen artikelen die in voorraad zijn, dus na productie, zichtbaar zijn voor verkoop?(en in kilo's)