Recentelijk is (voor een klant in Italië) een Voorraadmutatieoverzicht ontwikkeld in Excel. Dit overzicht moet de goederenstromen inzichtelijk brengen die gedurende een periode (een jaar) hebben plaatsgevonden. Per Magazijn wordt per Periode (maand) gepresenteerd wat de beginvoorraad was, hoeveel items er in de periode erbij zijn gekomen, hoeveel items eruit zijn gegaan, en wat vervolgens het eindsaldo was.
Het overzicht is (ten tijde van dit schrijven) te bereiken via Hoofdmenu,1,4,2,6,6.
Bij het opvragen van het overzicht kan worden aangegeven over welke Magazijnen gerapporteerd moet worden, en over welke periode. Tevens kan worden aangegeven of de gegevens in Liters gepresenteerd moeten worden, in de Voorraadeenheid v/h Artikel getoond moeten worden, danwel in aantal Verschijningen.
Het Exceloverzicht wat hieruit gegenereerd wordt ziet er uit als:
Hierin zien per dat iedere kombinatie van Artikel-/Verschijning-/Werkelijke Inhoud wordt opgenomen als één regel, en per regel de Beginvoorraad, de in de periode gemuteerde hoeveelheid (verdeeld in + en -), en de eindvoorraad getoond wordt. Onderaan het overzicht een grande totaal, van alle gerapporteerde regels.
Per Magazijn staat alle data op een separaat tabblad.
Let op:Dit overzicht is ontwikkeld voor een handelsbedrijf. Artikel-/Verschijningen worden ingekocht, en verkocht. Er wordt niet omgepakt, er is geen sprake van bulk, en worden geen eenheden uit verpakkingen 'getapt', danwel gebruik gemaakt van funktionaliteit zoals 'appels per stuk kunnen verkopen, doch af laten boeken uit een kist van 18 Kg'. De wijze waarop data gepresenteerd wordt, maar tevens de wijze waarop data berekend wordt, zal in dat laatste geval extra aandacht vereisen c.q. anders moeten worden opgezet (= aanvullend maatwerk). Denk hierbij aan een situatie dat als we 20 liter uit een vat van 200 liter zouden tappen, we een partij van 20 liter hebben ingekocht, er 20 liter van die charge uit een vat van 200 liter weggeboekt wordt, en dit wel eens als 2 separate (niet aansluitende) regels gepresenteerd zou kunnen worden.
Indien er mutaties zijn in de opgegeven periode, staat er vóór iedere regel een + je. Als we op dit + je clicken, klapt de regel open, en zien we meer detailinformatie over dat produkt. Als we e.e.a. op Artikel-/Verschijningsvorm niveau openklappen, zien we de perioden waarin deze kombinatie gemuteerd is.
Er ontstaan vervolgens weer nieuwe + jes die open geklapt kunnen worden. Het eerst volgende niveau toont een totaal per dag, en er verschijnt wéér een extra niveau.
Het volgende (en tevens laatste) niveau toont de mutaties die op die datum hebben plaatsgevonden. In dit voorbeeld 2 mutaties. Twee Goederen Ontvangsten van respektievelijk 440 en 660 liter, die tezamen de 1100 liter van die dag, en tevens van die maand vormen.
Berekenen Beginsaldo
Per regel (Artikel-/Verschijning-/Winhoud) geldt dat het systeem begint met het bepalen van een Beginsaldo op de begindatum v/h overzicht. Alle data die daarna in het overzicht terecht komt, wordt 'berekend' op basis van de opgenomen mutaties.
De berekening van dit beginsaldo vereist wat extra uitleg, omdat dat in deze print anders werkt dan in sommige andere overzichten.
Allereerst geldt dat de Voorraadtabel een momentopname betreft. Als we nu na de voorraad kijken kan deze al anders zijn dan één uur geleden (of zelfs 1 seconde geleden); dit, omdat er continue mensen in Profit aktief zijn die de voorraad kunnen muteren. Als we een Voorraadlijst willen hebben van 31 december, is geldt ook altijd het uitgangspunt dat we die op dát moment gewoon moeten uitprinten (en bewaren). Ook geldt een advies om op 31 december, als laatste op de dag, Produktie- naar Test te kopieren, opdat daarmee de stand van 31-12 wordt 'bevroren' in de Testbestanden, en we wat langer de tijd hebben om naar 'de momentopname' van 31-12 te kijken (zolang niemand muteert in de testbestanden, blijft de stand van 31-12 daar beschikbaar). Talloze overzichten betreffen nl. 'momentopnames', zo ook bijv. een print met de stand van 'Nog te ontvangen fakturen' van ontvangen goederen.
Binnen Profit is binnen de print LOPRVI (Printen Voorraaditems; Hoofdmenu,1,4,9,1) een optie ontwikkeld om de stand per een op te geven datum in het verleden te kunnen printen. Een dergelijke optie betreft dan altijd 'een berekening', en valt en staat met de juistheid van alle Voorraadmutaties, de juiste chronologische volgorde en zelfs nog de mate waarin allerlei soorten mutaties bij dit terugrekenen onderkent worden (zie hierbij voor je dat we soms rare trucen toestaan, zoals appels per stuk verkopen, maar afboeken uit kisten van 18 Kg, welke funktionaliteit nimmer in dit soort berekeningen is opgenomen, omdat dat voor de klant voor wie e.e.a. ontwikkeld werd niet nodig was). De methode is vrij simpel: als er nú 100 op voorraad liggen, en vanmorgen hebben we er nog 20 geleverd aan een klant, dan zullen er gistermiddag wel 120 op voorraad moeten hebben gelegen.
Bij deze methode geldt uiteraard dat hoe langer we moeten terugrekenen, hoe groter de kans is dat er niet meer teruggerekend kán worden omdat er ergens een fout is gekonstateerd.
Nb: Fouten kunnen op allerlei manieren ontstaan zijn. We weten van situaties waarin klanten zélf iemand vinden om een Voorraadtabel in het systeem te krijgen, maar hierbij dan niet de voor dit soort toepassingen vereiste formele mutaties aanmaken. Geblokkeerde funkties, waardoor zaken 'half af' zijn. Ordertjes die door de helpdesk op verzoek er even uitgegooid moeten worden omdat ze fout zijn, maar waarbij niemand aan de mutaties zelf denkt. Uiteraard kan zoiets ook worden veroorzaakt door een fout in de coding, en ook door fouten in bepaald gebruik (zo hebben we ooit iets ontwikkeld waarbij je leveringen met terugwerkende kracht kon registreren, bedoeld om in februari een melding van een extern magazijn te kunnen verwerken dat ze per 20 januari een partij ontvangen hebben, die ze vervolgens op 25 januari aan een klant geleverd hebben. E.e.a. is ontwikkeld met de regel 'je moet wel de werkelijkheid nadoen'. Wordt die regel gebroken, dan kan e.e.a. misbruikt worden door per februari een partij in te kopen, en deze vervolgens per januari aan een klant te leveren. De mutaties staan dan niet in de juiste chronologische volgorde, en ermee rekenen wordt onmogelijk voor het systeem.)
De genoemde LOPRVI print rekent dus vanuit de huidige voorraad terug naar de status per de opgegeven datum.
Dit overzicht doet dat precies andersom. Dit, omdat de tellijsten met bijv. de stand per 31-12 bewaard worden, en altijd 'de basis' behoren te zijn voor het nieuwe jaar. Zou 'terugrekenen' in LOPRVI niet werken, dan zou er een andere beginvoorraad worden berekend t.o.v. wat er op de tellijst staat. Dat is slecht uit te leggen aan een accountant. Dit overzicht begint derhalve met die tellijst, en rekent daarna verder naar nu.
De beginvoorraad per 01-01-2014 wordt hier derhalve bepaald door op zoek te gaan naar de laatste Inventarisatie vóór die opgegeven datum (bijv. 31-12-2013, om 23:00:00.00) en vanaf dat moment door te tellen tot 01-01-2014. Ervanuitgaande dat er na de Inventarisatie van 31-12 niets meer geleverd is, zal de beginvoorraad van 01-01-2014 daarmee altijd aansluiten met de tellijst van 31-12.
Tip: Door een einddatum van 31-12-9999 op te geven volgt er nog een extra kolom met de aktuele voorraadstand uit de Voorraadtabel, en wordt er een verschil berekend t.o.v. de berekende eindvoorraad. Als het goed is zit daar dan nooit een verschil tussen, maar zo toch, dan zijn items die niet aansluiten eenvoudig te herleiden.
Een Inventarisatie wordt op dit moment alleen gebruikt in de bepaling voor het beginsaldo. Als er een overzicht over een Inventarisatietijdstip heen wordt opgevraagd doet dat op dit moment niets. Wel hebben we al bedacht dat we in zo'n geval een idee kan zijn om 'automatische korrektieregels' toe te voegen aan het overzicht, opdat het overzicht 'sluitend' gemaakt wordt. Ofwel, stel dat we met een beginsaldo van 100 beginnen, er -40 gemuteerd is, we dus een eindsaldo van 60 zouden vinden, maar dan een inventarisatie tegenkomen die stelt dat er 90 hadden moeten liggen, dan zouden we kunnen besluiten er automatisch 30 bij te boeken.
Voor nu 'slechts een idee'.
Mutaties Analyseren-/korrigeren
Wat nu indien de mutaties
niet aansluiten ? Hoe vinden we nu wat er precies waar fout is gegaan ? En als er mutaties niet in evenwicht zijn, hoe korrigeren we zoiets dan zónder dat we ook de huidige voorraad daarbij korrigeren (die wél juist kan zijn).
Speciaal voor de werkwijze van dit overzicht, zijn er een aantal analyse- en korrektietools ontwikkeld.
E.e.a. begint bij het opvragen van de Voorraadmutaties van een Artikel-/Verschijning. Hoofdmenu-1-4-2-4.
Indien hier een overzicht wordt opgevraagd middels Charge-/Datum én rubriek "Analyseren Verschillen J/N" werd aangevinkt, zal er een overzicht worden opgebouwd met alle voorkomende kombinaties van Charge-/Interne Charge-/Kenmerken-/Inhoud en Lokatie. Per regel wordt daarin de Beginvoorraad getoond per de datum zoals hierboven werd opgegeven, het mutatiesaldo vanaf dat moment (tot nu), en de huidige voorraadhoogte. In principe zouden deze cijfers altijd moeten aansluiten.
In dit overzicht kunnen we een kombinatie selekteren, waarna we met Shift+F4 de Voorraadmutaties van die kombinatie kunnen opvragen.
In een situatie waarin dit niet aansluit konstateert Profit dat het beginsaldo + de mutaties niet aansluiten bij de huidige voorraad. In dat geval wordt er een * opgenomen in de kolom V (verschil).
Het overzicht maakt ook duidelijk van - t/m wanneer iedere kombinatie gemuteerd is. Ons 'probleem' zal in bovenstaand voorbeeld vóór 2014 hebben gelegen, omdat het item voor het laatst in 2013 is gemuteerd. We zouden dan het overzicht vanaf een eerdere begindatum kunnen opvragen, om te analyseren waar e.e.a. fout gegaan is.
Vanuit Raadplegen Mutaties van een kombinatie Artikel-/Verschijning-/Charge(s)-/Kenmerken-/Inhoud-/Lokatie zijn er een aantal korrektiemogelijkheden opgenomen om de voorraadmutaties te korrigeren.
Middels F4 kunnen we een nieuwe Voorraadmutatie toevoegen. Hierbij 2 keuzes:
De 1e keuze staat ons toe een normale (consistente) mutatie te maken. Hierbij wordt én een Voorraadmutatie gemaakt én er wordt iets op-/af Voorraad geboekt.
De 2e keuze is bedoeld om een inconsistente mutatie te maken. Hierbij maken we alléén een Voorraadmutatie aan, zónder dat er iets aan de voorraad gekorrigeerd wordt. Ook zal er niets worden gejournaliseerd. Een optie die enkel bedoeld is om een inconsistente situatie te kunnen korrigeren.
Deze funktionaliteit vereist expliciete autorisatie.
Middels Shift+F5 kan de Datum-/tijd van een Voorraadmutatie worden gewijzigd.
Met deze tool kan een mutatie die in januari geboekt is, maar per december had moeten worden uitgevoerd kunnen worden gewijzigd kwa datum; bedoeld om mutaties in de juiste chronologische volgorde te kunnen zetten.
Deze funktionaliteit vereist expliciete autorisatie.
Shift+F6 staat u toe een Voorraadmutatie te verwijderen. Ook deze verwijdering wijzigt niets aan de voorraadhoogte, en zal financieel niets boeken. Ook hier, puur bedoeld om een inconsistente situatie te verhelpen.
Deze funktionaliteit vereist expliciete autorisatie.
Nb: Nèt als het overzicht in Excel geldt ook voor deze funktionaliteit dat ze is ontwikkeld vanuit de 'handels' hoek.
Voor situaties als bulk, tappen, delen van verschijningen leveren zal e.e.a. niet voldoende ondersteund worden.
Het is derhalve niet gezegd dat iedereen deze funktionaliteit klakkeloos kan gebruiken; mogelijk is voor uw situatie aanvullend maatwerk benodigd.
