Opgelost Voorraad op project boeken

[Jacobusje]

Goedemorgen,

Ik heb een "eenvoudige" database gedownload waarmee ik bezig ben om die naar mijn hand te zetten.
In het origineel kan je alleen artikelen in- en uit boeken.
Omdat wij in het hout zitten hebben we ook met verschillende lengtes en breedtes te maken
Hiervoor heb ik de artikelentabel aangepast.

Met de knop "Verstrekking" kom je in een ander scherm waarin de artikelen uitgegeven kunnen worden.
In dat scherm heb ik al een vakje "Ordenummer" gemaakt.
Hiermee probeerde ik het ordernummer in de voorraadmutaties te krijgen, ook code in de module en onder de knop inboeken aangepast, maar daar loopt het vast, die code heb ik weer terug gezet.

Achteraf gezien lijkt het me ook geen goed plan om artikelen voor een project in een voorraadmutatie te stoppen....
Maar nu zou ik met de knop "inboeken" een tabel willen vullen, daarvoor heb de tabel "ArtikelenPerOrder" aangemaakt.
Dus bij de voorraad de aantallen er af en bij "ArtikelenPerOrder" de aantallen er bij.

Hoe ik dit aan moet vliegen weet ik niet, kan iemand mij daarmee op gang helpen?
Vast bedankt.

 

[OctaFish]

Het grote nadeel van een bestaande database aanpassen naar jouw wensen, is dat het uitgangspunt verkeerd is, waardoor jij het hele traject al begint met grote oogkleppen op je hoofd. Je ziet dus alleen nog maar de dingen die al in de database zitten en die je dan gaat 'aanpassen'. Maar je hebt geen flauw idee waarom de database übehaupt is gemaakt en met welk doel, en of dat doel ook voor 100% aansluit bij jouw workflow en processen. Kortom: ik raad niemand aan om deze werkwijze te gebruiken. Maar goed, ik mag hopen dat deze database doet wat jij ervan wilt.

Dat gezegd hebbende: is er een reden waarom je hem als mdb database gebruikt? Werken jullie nog met een oude (2003-) versie? Zo nee: zet hem dan subiet om naar het nieuwe accdb format, dan geef je jezelf gelijk een veel betere set gereedschap mee.

Daarnaast zie ik vreemde benamingen voor de tabellen, en mis ik er een aantal. Zo heb je wél een tabel [ArtikelenPerOrder] maar géén tabel [Orders]? Wat is daar de logica achter?

Achteraf gezien lijkt het me ook geen goed plan om artikelen voor een project in een voorraadmutatie te stoppen....
Maar nu zou ik met de knop "inboeken" een tabel willen vullen, daarvoor heb de tabel "ArtikelenPerOrder" aangemaakt.

En hier snap ik dus ook niets van. Leg je proces eens uit, voordat we überhaupt zinvol kunnen praten over de betere werkwijze. En ik zag ook nog eens dat je in de tabellen keuzelijsten hebt gebruikt. Die heb ik uiteraard direct omgezet naar tekstvelden; in een tabel horen geen keuzelijsten thuis (tenzij op basis van Waarden).

Kortom: leg eens uit wat de bedoeling is .

 

[Jacobusje]

Oei oei
Ik zal proberen iet meer duidelijkheid te geven.
De database heb ik subiet omgezet naar .accdb

Zo heb je wél een tabel [ArtikelenPerOrder] maar géén tabel [Orders]? Wat is daar de logica achter?

De logica is dat we bij de zagerij een aantal artikelen op een order moeten boeken, naderhand kunnen we zien wat de kosten zijn voor het hout van die order. Ik zou een tabel "orders" toe kunnen voegen zodat ze een keuze kunnen maken. (Bijgaand aangepaste versie)

En ik zag ook nog eens dat je in de tabellen keuzelijsten hebt gebruikt.

Die had ik niet gezien.

De bedoeling is:
- Eerst de voorraad hout inboeken
- Bij binnenkomst van een pak hout van een leverancier die toevoegen in de voorraad
- Bij het zagen van een order de gebruikte balken uit de voorraad halen en op het project boeken.
- Nu is elke moment de totale voorraad in beeld
- 1 keer per maand of 1 keer per 2 maanden kunnen we kijken voor hoeveel geld er op voorraad ligt (balans)
- Als een order klaar is kunnen we er uit filteren wat de houtkosten daarvoor zijn (nacalculatie)

iig bedankt

 

[xps351]

Zoals @OctaFish al schreef is het gevaarlijk een database over te nemen zonder je te realiseren wat je eigen eisen zijn en wat het idee achter de overgenomen database is.

De database was bedoeld voor het vastleggen van ingaande en uitgaande goederenstromen, alsmede de interne verplaatsingen. Dat alles vast te leggen in de tabel Voorraadmutatie. Door er nu een tabel ArtikelenPerOrder tussen te knutselen komt dat principe in de knoei. De artikelen die je voor een order nodig hebt zijn - zodra je ze daadwerkelijk uit het magazijn neemt - immers ook een voorraadmutatie. Daarmee help je de boel dus om zeep en laat de qryVoorraad ook niet meer de juiste voorraad zien.
Merk ook op dat de voorraad niet vastgelegd wordt, maar op elk moment afgeleid kan worden uit de voorraadmutaties (met qryVoorraad).

Op de ArtikelenPerOrder is trouwens wel meer aan te merken; artikelnaam, lengte en breedte horen er in ieder geval niet in, want die staan al in de artikeltabel. PrijsPerMeter (inkoop, toe te rekenen prijs?) is een verhaal apart.

 

[OctaFish]

Ik zie volgens mij nog steeds maar een deel van het proces. Zo heb je het over Projecten, die ik nog niet in de db heb teruggevonden, leveranciers en dus orders (klantentabel? Worden de orders op een andere afdeling ingeboekt? In een eigen database? Gedeelde database? Worden de ordernummers op geeltjes per postduif doorgestuurd (mag hopen van niet ).

Er zitten zoveel meer aspecten aan je verhaal die niet terugkomen in (het ontwerp) van je database…. Ik had echt eerst begonnen met het maken van een ontwerp, voordat ik überhaupt Access op had gestart. En dus gewoon met een schone lei beginnen, want ik vermoed dat je veel meer tijd kwijt bent met het aanpassen van deze db dan als je netjes met een lege en was begonnen.

 

[Jacobusje]

De artikelen die je voor een order nodig hebt zijn - zodra je ze daadwerkelijk uit het magazijn neemt - immers ook een voorraadmutatie. Daarmee help je de boel dus om zeep en laat de qryVoorraad ook niet meer de juiste voorraad zien.

Is het niet mogelijk om een voorraad met bijv. 50 af te boeken, net als nu en tegelijk de tabel "Artikelen PerOrder" te vullen met 50. Daarbij de prijs met artikel meenemen zodat bij een prijswijziging de prijs van dat moment intact blijft?

Op de ArtikelenPerOrder is trouwens wel meer aan te merken; artikelnaam, lengte en breedte horen er in ieder geval niet in, want die staan al in de artikeltabel. PrijsPerMeter (inkoop, toe te rekenen prijs?) is een verhaal apart.

Daar heb je een punt mee, met uitzondering van de PrijsPerMeter

Ik zie volgens mij nog steeds maar een deel van het proces. Zo heb je het over Projecten, die ik nog niet in de db heb teruggevonden, leveranciers en dus orders (klantentabel?

We hebben een projectbeheersysteem waarin van alles van orders word bijgehouden. Maar daar zit niets in van voorraadbeheer, dus alleen een ordernummer is voldoende.

Zoals de database in basis was vond ik al heel mooi, ik heb hem een beetje uitbreid om het hout in te kunnen voeren.
Dat zou ik voor de voorraad al kunnen gebruiken.
Maar ik hoop dat het hout op een ordernummer zetten er zo zijdelings bij gemaakt kan worden zonder de andere tabellen e.d. aan te tasten.

 

[NoellaG]

Omdat ik al meer dan 20 jaar magazijn databases beheer voor verschillende klanten, heb ik een blik geworden op de data structuur. Wat ik daar vooral mis voor stockbeheer is een Stocktabel. Het lijkt logisch, maar in de Excel en Access wereld leeft hardnekkig het idee dat men aan voorraadbeheer kan doen door de ingaande mutaties op te tellen en de uitgaande af te trekken. In de realiteit geeft dit altijd problemen na een tijd.
De stocktabel dient de volgende velden te bevatten:

• ArtikelID
• aantal
• locatie-ID
• prijs op het moment dat het artikel werd aangeschaft (deze blijft zeker niet constant en soms worden er artikelen met tijdelijke of hoeveelheidskortingen gekocht)
• status: (beschikbaar, gereserveerd: als een artikel aan een order word toegevoegd maar nog niet uit de voorraad is afgeboekt, geblokkeerd: mag momenteel niet gebruikt worden (nat hout, vervuild, ...)

Als je werkt met een stocktabel moet je wel bij elke aanvulling of pickorder de stock via VBA of actiequeries bijwerken, maar je hebt het voordeel dat je heel snel de actuele stock per locatie aan de prijs op de moment van aankoop kunt opvragen. Bovendien kan je de mutaties ouder dan een jaar gemakkelijk archiveren zonder dat je stockberekening verkeerd gaat lopen.

Wat is trouwens het verschil en gebruik van de tabellen Voorraadmutatie en VorraadmutatieHistorie?

 

[xps351]

Is het niet mogelijk om een voorraad met bijv. 50 af te boeken, net als nu en tegelijk de tabel "Artikelen PerOrder" te vullen met 50.

Er wordt geen voorraad bijgehouden in de (oorspronkelijke) database (dus is er niets af te boeken) er worden alleen voorraadmutaties vastgelegd. Ik heb al proberen uit te leggen dat ArtikelenPerOrder ook een soort voordmutatie is (dus zou dat vastleggen kunnen volstaan) . We kennen jullie werkwijze niet. Voorstelbaar is dat je ArtikelenPerOrder al vult voordat de goederen uitgegeven worden; je werkelijke voorraad blijft gelijk, de "vrije voorraad" neemt af. Als dat zo is kan je dat bijvoorbeeld oplossen met een status (gereserveerd, uitgegeven).

Daarbij de prijs met artikel meenemen zodat bij een prijswijziging de prijs van dat moment intact blijft?

Ja dat kan. Op de site waar je de voorbeelddatabase vandaan hebt staat daar ook iets over.

We hebben een projectbeheersysteem waarin van alles van orders word bijgehouden. Maar daar zit niets in van voorraadbeheer, dus alleen een ordernummer is voldoende

Wel vreemd dat je de nacalculatie wel in het voorraadsysteem wilt doen. Misschien toch maar een geïntegreerde oplossing nastreven?

Het is eerder gezegd: bezint eer ge begint. Breng eerst in beeld wat je allemaal wilt (zijn er bijvoorbeeld nog meer goederenstromen) en hoe het proces loopt en begin dan pas aan een oplossing te werken.

 

[xps351]

in de Excel en Access wereld leeft hardnekkig het idee dat men aan voorraadbeheer kan doen door de ingaande mutaties op te tellen en de uitgaande af te trekken. In de realiteit geeft dit altijd problemen na een tijd.

En wat zouden die problemen dan zijn?

Als je werkt met een stocktabel moet je wel bij elke aanvulling of pickorder de stock via VBA of actiequeries bijwerken, maar je hebt het voordeel dat je heel snel de actuele stock per locatie aan de prijs op de moment van aankoop kunt opvragen.

Het redundant vastleggen van gegevens lijkt me juist bij uitstek een bron van problemen.

Bovendien kan je de mutaties ouder dan een jaar gemakkelijk archiveren zonder dat je stockberekening verkeerd gaat lopen.

Wat is trouwens het verschil en gebruik van de tabellen Voorraadmutatie en VorraadmutatieHistorie?

Die optie zit in de voorbeelddatabase ook. Er is een functie waarmee je voorraadmutaties naar de voorraadmutatiehistorie schrijft. De actuele voorraad per artikel/locatie wordt als startvoorraadmutatie vastgelegd.

 

[NoellaG]

En wat zouden die problemen dan zijn?

In de praktijk: vooral traagheid en vastlopen van systemen met een lokale FE en een BE op een server. Dan moeten in een Access systeem alle mutatie gegevens over het netwerk gesleurd worden telkens men de stock opvraagt. Zolang men maar een paar honderd lijnen heeft lukt dit nog wel, maar met een paar duizend kan dit al problemen geven.

Dit zijn trouwens geen redundante gegevens, je gebruikt de ID-waarden van artikel en locatie zoals men in andere koppeltabellen doet, het veld prijs is de prijs op het moment van de transactie en niet de prijs genoteerd in het artikelbestand en het statusveld is de status in de stock en dus een unieke eigenschap van de tabel.

 

[OctaFish]

We hebben het over een Access database, niet over een groot systeem op een server. Gek toch dat dat er altijd weer bij wordt gehaald . Voordat je op korte termijn (zeker met deze database) tegen snelheidsproblemen aan gaat lopen is niet zo heel groot.

Zelf zou ik ook altijd met een Voorraad tabel werken en een tabel Voorraad mutaties. Al was het maar omdat in de praktijk er altijd wel afwijkingen in het beheer voorkomen, al dan niet door menselijke fouten. Niet voor niets doe je altijd aan het begin van het jaar een inventarisatie om de voorraad in de tabellen weer in overeenstemming te brengen met de werkelijkheid.

Van dataredundantie is, zoals Noella al aangaf, nauwelijks sprake.

 

[Jacobusje]

Ik zit al vanaf 7 uur met deze topic op mijn scherm....
Ondertussen ben ik wat anders aan het uitvogelen uit een ander lusje op dit forum.
Daarbij komt dat de vakantie aanstaande is, wellicht dat ik in de vakantie nog wat ga proberen.

Voor nu allemaal bedankt, ik kom er t.z.t. op terug, of met vragen of met een perfecte oplossing

 

[Jacobusje]

Tadada...
Het lusje waar ik over sprak heb ik aangepast en uitbreid naar mijn/onze wensen.
We moeten het volgende week nog gaan testen als de vakantie voorbij is, wellicht komen er nog wat kleine aanpassingen, maar het gros zit er nu wel in.

Het kan zijn dat ervaren access-gebruikers zeggen; Hoe heb je dat zo kunnen maken....
Dat komt dan door mijn gebrek aan ervaring.
Desalniettemin vindt ik goed gelukt voor het doel wat we voor ogen hebben.

Als bijlage de database waar ik relevante informatie uitgehaald heb.

 

[NoellaG]

als het voor jou werkt is het een goede oplossing. Good job

 

[xps351]

Zoals ik gisteren bij een ander draadje ook al schreef, als jij er tevreden mee bent, wie zijn wij om het er niet mee eens te zijn

Ondertussen vind ik het stilletjes vreemd dat je bijvoorbeeld voorraad uit kunt geven die je niet hebt en dat ik in de aantal-velden geen verschil zie tussen uitgifte met en zonder reservering. Reservering betekent volgens mij dat je het nog niet uitgeeft maar wel vasthoudt, en het dus niet uit zou mogen geven voor een andere order. Maar wie ben ik?

 

[Jacobusje]

Bedankt, daar heb je inderdaad een punt.
Maar dit kan voorkomen als het hout is besteld, nog niet binnen is, maar wel gereserveerd moet worden.
Ik heb al zitten broeden om het hout wel in te boeken als het is besteld en nog niet binnen is....
Daar eventueel een vinkje bijmaken dat het in bestelling is.
Dit wil ik nog overleggen na de vakantie.

 

[OctaFish]

Je hebt, neem ik aan, toch ook een tabel voor je bestellingen? Daarmee heb je dan een fysieke voorraad (wat er daadwerkelijk ligt) en een ‘virtuele’ voorraad: fysiek + in bestelling. Die aantallen kun je gewoon bij elkaar optellen (uiteraard wel op basis van wat besteld, maar nog niet geleverd is).

 

[Jacobusje]

Bestellen doen we met het eerder genoemde projectbeheersysteem.
Daarom dacht ik wel vast te boeken in de voorraad, later het vinkje "Is besteld" uitzetten

 

[NoellaG]

Leveringen kunnen uitgesteld worden, deels uitgeleverd, geannuleerd. Het lijkt me praktisch om alleen de goederen die daadwerkelijk in stock zijn bij de voorraad te tellen. want alleen die kan je nu gebruiken.

 

[OctaFish]

Volgens mij gaat het nu niet om voorraad, maar om wat je kan toezeggen in bestellingen. Daarbij mag je best reeds bestelde artikelen betrekken, want daarvan is de levering bekend. Dat je ze niet gelijk kan uitleveren lijkt mij evident. Vergelijk het met een artikel dat je zelf bestelt bij een online winkel, en dat tijdelijk niet leverbaar is. Dat zou je, normaal gesproken, nog steeds moeten kunnen bestellen met dus een onbekende levertijd.

Ik zou ook zeker geen artikelen in de voorraad tabel opnemen die je niet hebt. Behoorlijk verwarrend, want als je met een telraam langs de schappen gaat, klopt er geen hout meer van je voorraad. Ofwel iets is fysiek aanwezig (en kan geleverd) ofwel iets is in bestelling (niet gelijk leveren). Nooit doen dus wat jij nu bedenkt.