Naar vandaag is gebleken, is de bedoelde werkwijze van Inventariseren in augustus 2004 om zeep geholpen. We hebben hier dan over de formele registratie van een Inventarisatie (en dus niet bij met Bij-/Af registreren van Voorraadmutaties).
Inventariseren is oorspronkelijk zodanig opgezet dat met een Inventarisatie altijd een nieuw 0 punt wordt gekreëerd. Wat er vóór het Inventarisatie tijdstip gebeurde is niet meer van belang, we kijken alleen naar hetgeen gebeurd is vanaf de laatste Inventarisatie. Ofwel, als we op 1 januari tellen dat er 100 op voorraad liggen, liggen er voortaan vanaf 1 januari 100 op voorraad, en maakt het niet uit wat er daarvoor gebeurd is.
Doel van deze opzet was om niet afhankelijk te zijn van eventuele fouten die in het verleden ontstaan zijn. Per het nieuwe Inventarisatie tijdstip vangen we met een schone lei aan, en hoeft niet verder naar het verleden gekeken te worden.
Sinds (de niet verder beschreven) Releasenote
http://ha1.heartprofit.nl/profit/index.php?topic=12693.0 heeft iemand bedacht dat als er 100 blikken van 25 liter op voorraad staan, en we tellen er maar 80, de Voorraadmutatie "80 blikken x 25 liter" bevat, en dat dit beter gevuld kon worden met "-20 blikken", immers er zijn 20 blikken minder geteld dan wat er op voorraad lag.
Tsja... aan de ene kant logisch... maar... zo was Inventarisatie juíst niet opgezet !
Waar het de bedoeling was dat de Voorraadmutatie de getelde +80 bevatte, en deze op een print meteen zou leiden tot een nieuwe cumulatieve hoeveelheid van +80 (uitgaande van een nieuwe basis van 0), staat er sinds augustus 2004 ineens -20 in. Op zich is dat niet zo erg, maar die -20 is relatief t.o.v. de 100 die er op dat moment zou moeten liggen...
Ten eerste is het dan minder handig dat dat bepaalt dat we altijd eerst alle Voorraadmutaties (vanaf het begin dat we met Profit begonnen) moeten doorlopen om op deze 100 uit te komen, maar de echte ellende wordt veroorzaakt door het feit dat om dat te kunnen doen, er ook geen enkele fout in de Voorraadmutatie tabel mag staan. Tsja... en dat kunnen we niet garanderen... Overal in het systeem zal bij het muteren van de Voorraad er ook een Voorraadmutatie worden geregistreerd. Maar... hoewel de tijd die tussen deze 2 akties zit minimaal kort is, kán er toch altijd iets foutlopen tussen het bijwerken van het Voorraaditem en het aanmaken van de Voorraadmutatie (geblokkeerde funktie, netwerk error, stroomuitval, programma fout etc).
En, als we het al niet willen zoeken in de hoek van een fout, denk dan maar aan formele funkties waarmee Voorraadmutaties kunnen worden opgeschoond. Opschonen Voorraadmutaties is oorspronkelijk dat ook zodanig opgezet dat het laatste Inventarisatie Tijdstip bepaald wordt (bijv. 1 januari 2010) en staat enkel toe dat alles van vóór dat nieuwe 0 punt eruit wordt gegooid. Dit zou nl. straffeloos toegestaan zijn, immers per 1 januari is er tóch een nieuw 0 punt gekreëerd.
Nb: Merk overigens ook op dat het nooit (en nog steeds niet) is toegestaan om bij een handmatige Voorraadmutatie "Inventarisatie" in te vullen in de omschrijving. Dit, omdat deze omschrijving voor het systeem gereserveerd was ter herkenning van het nieuwe 0 punt.
Stel dat we 250 hebben ingekocht, en dat we 150 hebben verkocht. De voorraad is dan 100, en nu tellen we er 80.
Stel ook dat de 250 is ingekocht als 2 partijen van 125, en dat van 1 van beide de voorraadmutatie ontbreekt.
In de voor ogen liggende situatie zou de Inventarisatie van 80 stuks een Voorraadmutatie opleveren van 80 stuks. In de omschrijving staat dan "Inventarisatie" wat we zouden moeten lezen als "vanaf dit moment geldt er een nieuw 0 punt, nl. deze getelde 80".
In de situatie die sinds augustus 2004 is ontstaan, wordt zoals gezegd -20 opgenomen in de Voorraadmutaties, immers, er lagen er 100 en er worden er 80 geteld.
Het gaat nu fout als we een tijdje verder zijn, en we de huidige voorraad willen verklaren m.b.v. een print van de Voorraadmutaties. Deze zou per 1 januari als uitgangspunt de 80 moeten hebben die op dat moment geteld zijn. In de oude situatie was dat ook zo, immers, de Voorraadmutatie bevatte 80 en kreëerde een nieuw beginpunt van 80 stuks. In de situatie ontstaan sinds augustus 2004 moeten we het beginsaldo bepalen o.b.v. de voorraadmutaties. Daar troffen we maar 1x125 in aan, vervolgens de verkoop van -150 en dan de Inventarisatie van -20. Ofwel, dit resulteert in een saldo van -45. Precies de 125 minder van de ontbrekende voorraadmutatie.
En natuurlijk... als het goed is behoort die 125 niet te ontbreken... Feit is alleen dat als ze dat wél doet (en let wel, als er iets in de voorraad niet klopt, dan konstateert iemand dat wel (omdat ze voorraad wil pakken die er administratief niet is, of administratief is het er juist wel maar in werkelijkheid is het er niet), maar niemand zal door de voorraadmutaties lopen om te kijken of daar iets aan ontbreekt, c.q. om het daarna met een voorraadmutatie weer aan te gaan vullen (die dan weer niet daadwerkelijk in de voorraad terecht zou mogen komen)). Maar, nogmaals... desnoods is gewoon de Voorraadmutatie tabel opgeschoond, dán werkt het al niet meer...
Feit is dat deze methode zich baseert op de hoeveelheid die er al lag, en dát is fout, en is ook nooit de opzet geweest.
De aanpassing van augustus 2004 is vervolgens nog weer verder een eigen weg gaan leven o.a. met Releasenote
http://ha1.heartprofit.nl/profit/index.php?topic=14714.0. Hier werd door een klant gemeld dat de Beginvoorraad in een print met Voorraadmutaties niet klopte. Logisch, de print ging op zoek naar de laatste formele Inventarisatie, en bepaalde t.o.v. dat punt de getelde voorraad, ervanuitgaande dat de 1e voorraadmutatie het geïnventariseerde saldo bevatte. Echter, in plaats van 80 toonde deze ineens -20.
Dat e.e.a. nú pas aan het licht komt heeft ermee te maken dat als de Voorraadmutatietabel wel juist is (en dat behoort ze natuurlijk ook te zijn) en er niets wordt opgeschoond (hebben we op zich ook geen reden voor, hooguit misschien als de tabel boven de grens van 2 GB dreigt uit te komen) en het de klant niet opvalt dat de print steeds langer gaat duren (tsja, zoveel testdata hebben wij hier niet
) dan is er eigenlijk niets aan de hand...
Ja... totdat een van de genoemde zaken wél aan de orde is, en dan krijg je dat ook niet meer goed !
De werkwijze van Inventariseren wordt derhalve nu weer teruggezet naar de werkwijze vóór augustus 2004. Als er dán ooit op enige manier een foutsituatie ontstaat, kan een Inventarisatie worden gebruikt om een nieuw 0 punt te kreëren. En... merk op dat relatief aan de huidige voorraad werken altijd mogelijk is (en was), immers U kunt ook altijd nog de -20 als Handmatige Voorraadmutatie boeken, in welk geval er wél -20 geboekt wordt.
We zullen nog even precies moeten uitzoeken welke funktionaliteit er nog meer in deze hoek is aangepast, immers, door de aanpassing van augustus 2004 kunnen er daarna ook andere zaken verkeerd beoordeeld zijn (zoals het geval bij het berekenen van het beginsaldo). Tevens moeten we ons realiseren dat als e.e.a. nú klakkeloos wordt teruggezet, we er zeker van kunnen zijn dat dergelijke prints niet meer werken, immers, als we nu weer formeel op zoek zouden gaan naar de 1e Voorraadmutatie ná het Inventarisatietijdstip, dan staat daar nog steeds de -20 in, en niet de 80 die erin hoorde te staan. Nu kunnen we wel stellen "dat komt wel goed met de eerst volgende Inventarisatie", maar als dat ook maar even niet nodig is omdat we dat kunnen ondervangen, zullen we dat niet moeten nalaten.
Hoewel "krom" dan ook (immers, zo behoorde het altijd te werken) ontkomen we er misschien niet aan om nú formeel bij een Inventarisatie (intern) een indikator op te nemen dat deze een nieuw 0 punt kreëert. Dit, opdat we het vanaf de aanpassing waarmee e.e.a. wordt teruggezet naar de oorspronkelijke wijze weer kunnen laten werken zoals bedoeld, zonder dat dit van invloed is op de huidige (foute) werkwijze. E.d. interne indikator ter herkenning van een Voorraadmutatie v/d Inventarisatie is ongetwijfeld ook degelijker dan zoals het was opgezet "te kontroleren op het voorkomen van 'Inventarisatie' in de Omschrijving v/d Voorraadmutatie" (en het daarmee de gebruiker te verbieden die term te gebruiken).
De print "Printen Voorraadmutaties v/e Artikel-/Verschijning" lijkt te zijn opgezet om het Voorraadsaldo op enig moment in de tijd te kunnen verklaren. Als de print wordt opgestart wordt het beginsaldo berekend op het Begintijdstip van het gevraagde overzicht, en worden vervolgens alle Voorraadmutaties afgedrukt uit de opgevraagde Periode. Per mutatie wordt vervolgens de mutatiehoeveelheid getoond en tevens de nieuwe cumulatieve voorraadhoogte. Van deze laatste is het de bedoeling dat deze de eindvoorraad bevat per de einddatum van het overzicht.
Ook bij die funktionaliteit wil ik een paar kanttekeningen plaatsen:
1. Zodra een overzicht wordt opgevraagd van 1 januari t/m 31 december, en halverwege (juli) zou het produkt geïnventariseerd zijn, dan zou de kolom met de cumulatieve hoeveelheid gekorrigeerd moeten worden v.w.b. dit nieuwe nulpunt. Nu wordt er doorgeteld, telt ook de Voorraadmutatie v/d Inventarisatie mee, en wordt hier (gezien de oorspronkelijke werkwijze) juist 80 meegeteld i.p.v. het totaal te resetten naar 80.
Uitgangspunt van de print kon wel eens zijn dat er op de begindatum v/h gevraagde overzicht er
altijd een gehele Inventarisatie is uitgevoerd (dus alle Voorraaditems, op alle Lokaties en van alle Artikelen zijn geïnventariseerd), en dat er tussendoor niet meer geteld is. Zou er immers wel tussendoor nog geteld zijn, dan anticipeert de print er niet op.
2. Zou de print wél anticiperen op tussentijdse Inventarisaties, dan nog heeft de print m.i. een onjuiste indeling om ooit op een duidelijke wijze een eindsaldo te kunnen herleiden op de print.
Stel, we hebben 100 x charge A op voorraad, en 50 x charge B. Het beginsaldo van de print toont derhalve cumulatief 150. Vervolgens zijn er 25A geleverd, en die regel toont cumulatief 125. Daarna is er 50A geleverd, en cumulatief wordt 75. Veel complexer hoeven we het niet te maken, maar op dat moment gaan we tussentijds Inventariseren... Steekproefsgewijs wordt charge B van dit artikel geteld (cyclisch tellen), en laten we deze voorraad voor het gemak eens op 0 inventariseren.
De print kan nu echter niet zomaar de cumulatieve voorraad op 0 stellen omdat dit de nieuw getelde waarde is; nee, met deze Inventarisatie is enkel partij B geteld (op lokatie X, Intern Charge Y, Inhoud Z etc). en alleen van dát Voorraaditem zal het totaal gereset moeten worden naar 0.
Resumer, de print zal bij een weergave op datum-/tijd het volgende tonen:
Beginvoorraad 150, totaal 150
Levering 25, totaal 125
Levering 50, totaal 75
Inventarisatie 0, totaal 25
etc.
Niemand zal hier de overstap van een mutatie van 0 naar een cumulatief saldo van 25 begrijpen, en na mate er meer mutaties zijn, wordt dit alleen nog maar moeilijker te doorgronden.
Een betere indeling voor de print (als deze gebruikt moet kunnen worden voor de aansluiting van de voorraad) is deze op te zetten zodat deze per Charge-/Interne Charge-/Lokatie-/Inhoud (de gegevens op welk niveau een partij geïnventariseerd wordt) de gegevens af te drukken, en dan per datum tijd. In dat geval zou de print eerst van charge A tonen dat er 100 ligt, 25 geleverd is, 50 geleverd is, en dat er nog 25A behoort te liggen, en daarna zal B worden afgedrukt met een beginvoorraad van 50, en zal de inventarisatie van 0 een cumulatief van 0 afdrukken v.w.b. die specifieke partij. Aan het einde van de print zou er dan een totaal kunnen worden afgedrukt wat van welke partij de eindvoorraad zou moeten zijn, en dát kan dan weer getotaliseerd worden voor de bepaling van de totale voorraad.
Door deze indeling zal de print alleen totaal niet leesbaar worden; indien een partij wordt overgeboekt naar een andere lokatie zal dit niet resulteren in een af mutatie direkt gevolgd door een bij mutatie, nee, er kunnen honderden mutaties tussendoor staan. Sterker nog, als de lokatie waarnaar geboekt wordt kwa Identifikatie kleiner is dan de lokatie waarvan afgeboekt wordt, dan zal de "bij" mutatie zelfs nog eerder vermeld kunnen worden dan de "af" mutatie.
Mogelijk werkt de print om die reden zoals ze werkt, en anticipeert ze erop dat er in de opgevraagde periode geen tussentijdse Inventarisaties hebben plaatsgevonden. Wellicht is het dan ook beter om dáár een kontrole voor in te bouwen (is er tussentijds geïnventariseerd, dan geen eindsaldo meer tonen) en desgewenst een nieuwe print ontwikkelen voor zij die daar behoefte aan hebben (als die behoefte er überhaupt is, immers, waar ik bedenk dat dit een probleem oplevert bij een tussentijdse Inventarisatie, kon dat wel eens enkel "theorie" zijn, omdat we hier in al die jaren nooit iemand over hebben gehoord).
