Opgelost Voorraad op project boeken

[xps351]

Voordat je begint om links en rechts vinkjes op te nemen, kan je beter eerst eens op papier zetten wat je nu eigenlijk allemaal met het systeem wilt kunnen doen. Ook de bedrijfsregels (bijvoorbeeld: hoeveel voorraad kan en mag ik uitgeven en aan wie) moet je helder hebben. Pas als dat duidelijk is kan je beginnen met ontwerpen en bouwen.

Als blijkt dat je gegevens over bestellingen (inclusief aantallen) nodig hebt bij het proces, dan is dat zo en moet je een manier vinden om die in je systeem te krijgen. Een conclusies van je analyse kan ook zijn dat het helemaal niet handig is om met verschillende systemen te werken. Praat dan eens met de verantwoordelijke voor de automatisering binnen je bedrijf.

Ga je op de ingeslagen weg verder, dan heb ik als je daar in geïnteresseerd bent nog wel wat mogelijke verbeterpunjes voor je huidige database.

 

[OctaFish]

Helemaal eens met Peter.

Het kan zijn dat ervaren access-gebruikers zeggen; Hoe heb je dat zo kunnen maken.... Dat komt dan door mijn gebrek aan ervaring.

Ik zou zeggen, als meerdere ervaren gebruikers hetzelfde zeggen: misschien moeten we toch nog maar eens naar het ontwerp kijken, want wellicht zitten we toch op de verkeerde weg.... Ik ga ook wel eens rechtdoor als de navigatie linksaf zegt, maar gek genoeg moet ik meestal na verloop van tijd tóch omkeren.

En een database maken zonder enige kennis is op zijn minst dapper en gedurfd. Maar vaker dom en tijdverspilling. Sifan Hassan wordt nu geprezen voor de durf met haar olympische programma, maar voor mijn gevoel heeft ze minstens één gouden medaille verloren i.p.v. één gouden gewonnen. Dus "maar" één goud i.p.v. twee. En als kijker zaten we twee keer met kromme tenen te kijken naar hoe ze zekere gouden medailles aan het weggooien was.

Laat op zijn minst een ervaren database bouwer naar je systeem kijken, en naar de workflow die je hebt. Zodat de procedures passen binnen het bedrijfsproces. En werk dus nooit andersom!

 

[NoellaG]

Het blijft wel moeilijk om te timmeren met nog niet geleverd hout, maar zoals Octafish altijd zegt: laat ons wachten op de reactie van Jacobus. Trouwens hebben we het nu over een database of een applicatie? Dat maakt wel een heel groot verschil. Meestal doet me eerst de analytische analyse betreffende hoe de applicatie moet werken. Daarna kan men beslissen over hoe men het gaat uitvoeren. Daarna kan men kijken hoe men aan de gegevens kan komen, en dan pas komt de database in zicht.

 

[OctaFish]

Trouwens hebben we het nu over een database of een applicatie?

Leg jíj dan eens uit wat volgens jou het verschil is, want voor simpele zielen is het heel simpel: Access is de applicatie en het database bestand (accdb, mdb) de database. Ik werk al járen tot volle tevredenheid met die wetenschap. Heeft me nog nooit in de steek gelaten .
En dat komt hier in het Access forum ook volledig tot zijn recht.

Heb je het over ándere applicaties met een database, dan heb je het vermoedelijk over iemand die met VB of een andere programmeertaal een (database)applicatie bouwt die data uitleest uit een (Access) database. Dat kan en mag uiteraard, maar dan heb je in het Access forum niets te zoeken. Access maakt géén applicaties. Al kun je wel ‘zelfstandig draaiende’ databases maken voor mensen die zelf geen Access hebben. Maar TS geeft nergens aan dat dat hier het geval is. Dus waarom dit erbij betrekken?

Het proces dat je beschrijft is overigens generiek, dus ook nuttig/noodzakelijk voor als je een database gaat maken.

 

[NoellaG]

applicatie: in Access de verzameling queries, formulieren, rapporten en modules.
Access is een Rapid Development Tool (omschrijving van Microsoft zelf) waarmee je heel snel gebuikersschermen kan ontwikkelen.

Definitie van Access volgens Microsoft (https://www.microsoft.com/nl-be/microsoft-365/access) :

Access is een hulpmiddel dat eenvoudig te gebruiken is om zakelijke toepassingen te maken, vanuit sjablonen of helemaal vanaf het begin. Met de rijke, intuïtieve ontwerpmiddelen kan Access je helpen in korte tijd aantrekkelijke en goed functionerende toepassingen te maken.

Dat lijkt me toch wel sterk naar een applicatie te wijzen.

Hierbij kan je gebruik maken van een al of niet gratis externe database (MySQL, MariaDB, SQL server) of Excel databestanden of de ingebouwde Access tabellen.

Mijn post was alleen een antwoord op de posts van Peter en Octafish die het beiden over analyses hadden, en de volgende uitspraak duid volgens mij op de applicatie analyse:

Zodat de procedures passen binnen het bedrijfsproces.

Waarna er weer verwezen wordt naar een ervaren database bouwer.

Natuurlijk moet je ook een database analyse gaan doen, maar deze is dan weer een stuk technischer en kan pas gebeuren nadat de applicatie kant duidelijk heeft gemaakt wat je precies wil en wat men daarvoor nodig heeft.

Het lijkt me toch nuttig om, als je een duidelijke raad wil geven, de termen niet kris-kras door elkaar te gebruiken.

 

[Jacobusje]

Allen,

Volgende week ga ik het overleggen met degenen die er mee moeten werken.
Met name het deel tussen bestellen en leveren hout.
Wij zijn niet zo'n bedrijf wat alles vastlegt in processen, dus of het een database is of een applicatie zal ons een worst wezen
Wat er met de "appli-base" moet kunnen zit in mijn hoofd..... (soms maak ik er tussendoor een schetsje bij)
Dat het in de achtergrond beter moet/kan zal ongetwijfeld.....

Ik ga jullie aangeleverde informatie nog doorakkeren en laat nog van mij horen.

 

[OctaFish]

Je gaat gewoon veel te ver met dit soort haarkloveriij. Voor de gemiddelde gebruiker (en daar schaar ik jou ook onder, gezien je Access niveau) is Access de applicatie waarmee je databases bouwt. Klaar. En hoe uitgebreid en ingewikkeld moet je helemaal zelf weten.

 

[OctaFish]

Wij zijn niet zo'n bedrijf wat alles vastlegt in processen, dus of het een database is of een applicatie zal ons een worst wezen

Nee? Dus de ene klant komt hout halen en zegt dan: "ik kom wel een keer wat geld brengen" en dat vinden jullie dan goed, een tweede zegt: "ik heb nog wel een paar kratten bier in de auto liggen, lijkt mij een prima ruil" en de volgende klant moet gelijk met contant geld betalen? Jullie werken uiteraard met processen en procedures, ze zijn alleen niet (goed) beschreven en vastgelegd.

En dat is dus het probleem: als je een automatiserings systeem gaat maken, dan is nou uitgerekend dát aspect het belangrijkste. Zonder procesbeschrijving en procesanalyse kom je niet ver.

 

[Jacobusje]

Nee? Dus de ene klant komt hout halen en zegt dan: "ik kom wel een keer wat geld brengen" en dat vinden jullie dan goed, een tweede zegt: "ik heb nog wel een paar kratten bier in de auto liggen, lijkt mij een prima ruil" en de volgende klant moet gelijk met contant geld betalen? Jullie werken uiteraard met processen en procedures, ze zijn alleen niet (goed) beschreven en vastgelegd.

Ha ha, inderdaad, we zitten niet meer in de ruilhandel.
We zijn ook geen bedrijf waar Jan en Alleman hout komt halen, wij maken onderdelen van hout.
En ook werken we met ons projectsysteem wel volgens een bepaald stramien maar dat hebben we niet in een boekwerk vast gelegd.

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.

We gaan, na overleg, inderdaad pas inboeken als het wordt afgeleverd
En voorlopig gaan we de reserveringen nog niet gebruiken

Ga je op de ingeslagen weg verder, dan heb ik als je daar in geïnteresseerd bent nog wel wat mogelijke verbeterpunjes voor je huidige database.

Altijd mooi als het met weinig werk beter kan, tips zijn welkom.


We gaan eind van deze week en komende week testen met nepdata en dan kijken of dingen boven water komen waar we tegenaan lopen.

 

[OctaFish]

Hou ons op de hoogte en post vooral de meest recente versie met die dummydata, zodat we een reëel beeld hebben van je systeem .

 

[xps351]

Of het weinig werk is of niet, bepaalde onvolkomenheden helpen je systeem om zeep en zal je dus wel moeten repareren. Uitgaande van de laatst gepubliceerde versie en aannemende dat daar niet veel aan veranderd is een kleine bloemlezing aan tips.

Tip 1: valideer de invoer op het artikelformulier
Je legt uit hoe de gebruiker de lengte/breedte in moet vullen, afhankelijk van de groep van het artikel. Als het puntje bij paaltje komt, kan hij (m/v/x) invullen wat hij wil en help je de nacalculatie om zeep. Dus: controleer of de gegevens juist ingevuld zijn en weiger ze anders. Nog beter: pas tip 2 toe.

Tip 2: zet de nacalculatie anders op
De nacalculatie is mijns inziens onnodig ingewikkeld en (dus) lastig te verifiëren.
Als je bijvoorbeeld een of meer rollen dampremmende folie gebruikt hebt, staat er dat de prijs per meter €0,90 is (dat klopt trouwens niet, het blijkt per vierkante meter te zijn) dan moet je 50000 door 1000 delen, en 3000 ook en vervolgens 50 * 3 * 0,9 uitrekenen (= 135) en dat met het aantal verbruikte rollen vermenigvuldigen. Omdat je alleen hele rollen (platen, latten) kan nacalculeren, kan je net zo goed meteen € 135 als prijs per rol in het artikelrecord zetten. Geen gedoe, helder en eenduidig. Je hoeft dan ook niet kunstmatig een lengte van 1000 in te (laten) vullen (en niet te controleren) bij artikelen waarbij de lengte helemaal niet speelt.

Tip 3: valideer de voorraadmutaties
Zoals ik eerder meldde is (was) het mogelijk voorraad uit te geven die je niet hebt. Maar er klopt meer niet.
Een argeloze gebruiker zou een negatief getal in kunnen vullen bij een uitgifte voor een order. Geen probleem; de voorraad wordt “gewoon” verhoogd.
Als ik geen artikel invul bij een uitgifte, krijg ik de melding “Type komen niet overeen”. Bij een levering is de melding “Ongeldig gebruik van Null”. Niet echt duidelijke meldingen voor de gebruiker.
Bij een uitgifte voor order is het niet verplicht een ordernummer op te geven. Vergeten betekent dat een nacalculatie vernacheld wordt.
Als ik de nul bij een mutatie laat staan krijg ik de melding “er is geen aantal ingevuld” (wel waar: 0). Haal ik de nul weg, dan wordt de mutatie geaccepteerd terwijl er dan echt geen aantal is ingevuld.

Tip 4: laat bij het invoeren van een artikel niet #Fout zien bij huidige voorraad
Ziet er zo slordig uit.

Tip 5: maak een functie om correcties vast te leggen
Bij tellingen kan een verschil tussen de werkelijke voorraad en de administratieve voorraad geconstateerd worden. Je moet die laatste dan kunnen corrigeren.

Tip 6: Ga na of het voorkomt dat ongebruikte artikelen terug gebracht worden
Als dat zo is moet je het kunnen boeken.

Tip 7: Normaliseer de artikelentabel
Als je de prijs per leverancier echt wilt vastleggen, maak dan een (koppel)tabel artikelprijs-leverancier. Als er een leverancier bij komt, voeg je gewoon regels toe aan die tabel en hoef je niet het ontwerp van de artikeltabel aan te passen.

 

[xps351]

Tip 8: Laat de gebruiker niet onnodig ordernummers intikken
Als de gebruiker bij een uitgifte een order moet opgeven, kan hij gebruik maken van een combobox. Bij het opvragen van een nacalculatie of een uitdraai daarvan moet hij een ordernummer intikken. Biedt daar ook een combobox aan.
Bovendien is het nu zo dat als hij geen ordernummer invoert alle orders bij elkaar getoond worden. Met een combobox kan je controleren of er een order ingevuld is en weet je dat die bestaat.

 

[NoellaG]

tip 5 en 6: dit zijn gewoon PO's (bewegingen in) van een ander type, daar moet je zeker geen aparte functie voor voorzien.

 

[xps351]

Zucht, noem het wat je wilt (optie, mogelijkheid, functie). Feit is dat als iets voorkomt in de praktijk, je het netjes moet kunnen boeken in het systeem/de applicatie/de database.

 

[OctaFish]

En waarom kunnen jullie niet wachten tot TS zijn eerste bevindingen terugkoppelt? Is de pen te ongeduldig? .

 

[xps351]

Omdat alles wat je er vooraf uit kunt halen meegenomen is en minder ervaren testers wellicht iets over het hoofd zien of voor lief nemen

 

[OctaFish]

Je overdrijft je invloed. We zijn hier in eerste instantie om mensen te helpen met een probleem waar ze zelf mee komen, niet om ze nieuwe problemen aan te smeren .

 

[Jacobusje]

Goedmiddag,

Te eerste allemaal bedankt voor de input.

Tussen de bedrijven door (daarom duurde het even) ben ik aan het aanpassen geweest.

Ik zal puntsgewijs even reageren:

1. Opgelost middels punt 2
2. Bij de artikeleninvoer moet de keus gemaakt worden van M¹, M² of St, daarop is ook de nacalculatie afgestemd, balans volgt nog.
3. Moet ik nog naar kijken
4. Opgelost
5. Correctie had ik al opgelost door 2 leveranciers aan te maken, "Start balans" en "Correctie balans" hier kan dan positief en negatief op worden geboekt
6. Niet van toepassing
7. Misschien dat ik dat nog ga doen, maar dan wordt het artikeloverzicht weer veel ingewikkelder
8. Ik heb 2 comboboxen toegevoegd maar die krijg ik niet goed. Daarnaast is het zo dat we hier helemaal gewend zijn om ordernummers in te typen.

 

[xps351]

2. Bij de artikeleninvoer moet de keus gemaakt worden van M¹, M² of St, daarop is ook de nacalculatie afgestemd, balans volgt nog.

Mooi dat je de zichtbaarheid van de velden afhankelijk hebt gemaakt van de eenheid. Je zou alleen nog kunnen afdwingen dat een eenheid gekozen wordt. Je zou ook nog kunnen overwegen om de eenheid te koppelen aan de groep (plaat is altijd vierkante meter, hout is meter, overige is stuks). Dan kan je de eenheid automatisch tonen op basis van de groep.
Verder zou je af kunnen dwingen dat in voorkomende gevallen een lengte/breedte en prijs balans >0 wordt ingevuld.
Ook moet je nog even kijken naar het wijzigen van de eenheid. Als je bijvoorbeeld vierkante meters wijzigt in meters, blijft de eerder ingevulde waarde van breedte staan, met alle gevolgen van dien.

5. Correctie had ik al opgelost door 2 leveranciers aan te maken, "Start balans" en "Correctie balans" hier kan dan positief en negatief op worden geboekt

Voor de gebruiker is het misschien niet logisch dat hij "levering door leverancier" moet kiezen om een correctie vast te leggen. Bovendien moet je het valideren van de mutaties (punt 3) goed inregelen.

 

[Jacobusje]

Bedankt voor de aanvullingen

Je zou alleen nog kunnen afdwingen dat een eenheid gekozen wordt.

Geregeld

Je zou ook nog kunnen overwegen om de eenheid te koppelen aan de groep

Is niet van belang omdat de nacalculatie en balans rekent vanuit hetgeen als eenheid is aangevinkt.

Verder zou je af kunnen dwingen dat in voorkomende gevallen een lengte/breedte en prijs balans >0 wordt ingevuld.

Waar zou ik die code neer moeten zetten, ik heb geen knop "OK" op dat formulier

Ook moet je nog even kijken naar het wijzigen van de eenheid. Als je bijvoorbeeld vierkante meters wijzigt in meters, blijft de eerder ingevulde waarde van breedte staan, met alle gevolgen van dien.

Heeft geen gevolgen, rekent met hetgeen staat aangevinkt bij eenheid, dat vakje wat dan nog staat ingevuld wordt in de berekening nacalculatie en balans niet gebruikt.

Voor de gebruiker is het misschien niet logisch dat hij "levering door leverancier" moet kiezen om een correctie vast te leggen.

1 persoon doet de balans, dat is 1 keer uitleggen

Punt 3 is nog een dingetje, ik ben daar nog mee aan het stoeien, misschien komt het eerder in de buurt van vechten...



We komen nu bij het invoeren tegen dat bij het invoeren van 0,5 alleen de eerste keer de voorraad met 1 omhoog gaat en de volgende boekingen van 0,5 blijft de voorraad gelijk.
Ik heb geprobeerd alle vakjes die er mee te maken hebben op ander getalnotateis te zetten, maar geen resultaat.
Ook in de tabel mutaties "nieuwe voorraad" op standaard getalnotatie gezet met 1 decimaal, wordt niet zichtbaar.

Wat zou hier aan de hand zijn? zie ik wat over het hoofd?