Middels een Bedrijfsparameter "Leveren met terugwerkende kracht J/N" (een behoorlijk 'gevaarlijke' parameter die eigenlijk altijd
uit behoort te staan) is het mogelijk om Leveringen aan klanten te kunnen registeren per een andere datum dan de systeemdatum.
De funktionaliteit is ontwikkeld voor een administratief bedrijf, die achteraf, van de beheerder van een extern magazijn, doorkrijgt wat er vanuit dat magazijn aan wie geleverd is.
Het 'gevaarlijke' in deze methode is dat we met terugwerkende kracht in staat zijn dingen te registreren, waarvan we achteraf nooit meer zullen snappen waarom iets op een bepaalde manier werkte. Dit tevens in kombinatie met 'Ontvangsten' die met terugwerkende kracht geboekt kunnen worden.
Denk hierbij aan zaken dat we Charge A en Charge B op voorraad hebben liggen, maar eerst een klant X partij A leveren per de 16e, en daarna klant Y partij B leveren per de 12e. Kijken we nu naar de voorraadmutaties, dan komen we als eerste de mutatie van de 12e tegen, en met als uitgangspunt dat we FIFO werken, zouden we ons kunnen afvragen waarom die klant niet partij A heeft gekregen. Wel, simpel: e.e.a. is met terugwerkende kracht geboekt.
Nog raarder wordt het als gebruikers dit mechanisme gebruiken om er écht een puinhoop van te maken, door nl. de werkelijkheid niet na te doen. Ook in bovenstaand voorbeeld geldt nl. dat als we de werkelijkheid zouden nadoen, en we in werkelijkheid FIFO werken, de levering van de 12e inderdaad de oudste charge had moeten krijgen. We hadden dus partij A moeten leveren ipv B.
Maar, omdat het uitgangspunt bij deze rubriek is dat we natuurlijk wel de werkelijkheid nadoen, zijn er diverse kontroles niet opgenomen. Kontroles die ineens wél nodig zijn op het moment dat de Gebruikers niet in staat zijn deze funktionaliteit met beleid te gebruiken, waar ze tóch geaktiveerd is.
Denk hierbij maar eens aan de situatie dat de betreffende voorraad pas op de 15e ontvangen is, maar iemand nu op de 28e aangeeft dat ze per de 12e geleverd is... Dat kán in werkelijkheid helemaal niet, immers, per de 12e hadden we die voorraad nog niet.
Normaal gesproken zou je je nog kunnen afvragen of dit nou echt zo'n probleem is; hooguit kloppen je Voorraadmutaties niet gezien hun chronologische volgorde. Inderdaad. Maar, als je dié mutaties gebruikt om de voorraadhoogte op enig moment in de tijd terug te rekenen, dan is dit niet mogelijk.
Omdat de klant waar dit 'met terugwerkende kracht' mechanisme niet korrekt gebruikt wordt én aldaar wel de voorraadhoogte in het verleden wordt teruggerekend, zullen er een aantal aanvullende kontroles moeten worden uitgevoerd.
Voorraad moet aanwezig zijn per Raapdatum De eerste kontrole stelt dat als we gaan leveren, we niet alleen over een Voorraaditem moeten beschikken, maar, als we kijken naar alle Voorraadmutaties van deze Artikel-/Verschijning-/Charge(s)-/W-Inhoud dan zal de te leveren hoeveelheid ook aanwezig moeten zijn op de datum per wanneer we willen rapen. Deze kontrole is derhalve bedoeld opdat we niet kunnen zeggen dat een partij die we pas in januari hebben ontvangen, per een eerder moment (december) geleverd wordt aan een klant.
Terugboeking levering op Verkooporder altijd per oude Leverdatum Bij het terugboeken van een Levering, een toets die ontwikkeld is om 'dikke vinger fouten' te kunnen korrigeren (we hebben een verkeerde partij geleverd, en willen de levering ongedaan maken om even de partij te kunnen leveren). De funktionaliteit is
niet bedoeld om iets daadwerkelijk aan een klant te leveren, en, zodra de klant e.e.a. maanden later retour stuurt, dan nèt te doen alsof e.e.a. nooit geleverd was.
Zodra de parameter "terugwerkende kracht" aan staat, zal e.d. levering bij het terugboeken altijd worden gekorrigeerd per de datum waarop ze oorspronkelijk is geleverd. Indien die datum inmiddels in een afgesloten periode ligt, zal terugboeken niet meer toegestaan zijn.
Nb: Merk op dat dat laatste impliceert dat we in december iets geleverd hebben aan een klant (Pakbon de deur uit, levering vermeldt op ICL aangiftes etc) om vervolgens in maart te zeggen dat de levering nooit heeft plaatsgevonden. Dat mag gewoon niet. Als de goederen echt retour komen, zal er een credit moeten worden gemaakt.
Geen datum meer invulbaar bij "Direkt Leveren" Als we formeel regels naar een Raaplijst gestuurd hebben, dan weet het systeem welke Charges er gereserveerd zijn, en kunnen we valideren of deze Charges 'beschikbaar' waren per de opgegeven Raapdatum. Direkt Leveren (Hmenu,3,2,1,x Shift-F4) betreft echter funktionaliteit waarbij het systeem zelf wel een partij afboekt (FIFO). Zodra hier op het scherm een Raapdatum wordt overschreven, is nog niet bekend welke partijen er geraapt zullen gaan worden. Dat volgt pas na de
F1___. Deze procedure wordt
niet gebruikt door de klant voor wie 'Leveren met Terugwerkende kracht' ontwikkeld is; bewust, immers je kunt geen Charges opgeven.
Per heden is het kunnen overschrijven van de Raapdatum alhier gedisabled. In theorie zou het best mogelijk zijn hier iets voor te maken, maar, dit vereist (complex) aanvullend maatwerk die feitelijk uit de pool van Voorraaditems op zoek gaat naar die Voorraaditems die per de opgegeven Raapdatum aanwezig waren op voorraad.
Let op: Een aantal leverfunkties bieden de mogelijkheid om met terugwerkende kracht een datum op te geven per wanneer geleverd is. Dit betreft puur "een datum", maar, we hebben natuurlijk ook nog met "een tijd" te maken.
Als we onze handelingen nu maar allen direkt na elkaar uitvoeren, dan is er op zich niets aan de hand. Als we om 14:00 iets ontvangen per vorige week, dan komt dit per 14:00 op voorraad. Gaan we dit 5 minuten later leveren (per vorige week), dan gaat de voorraad om 14:05 de deur uit, en hebben we geen probleem.
Anders wordt het als we op donderdag om 14:00 aangeven dat we afgelopen maandag iets ontvangen hebben (of een order hebben teruggedraaid), en vervolgens vrijdag om 08:00 aangeven dat we dit op maandag geleverd hebben.
Omdat we alleen om "een datum" vragen, en niet om "een tijd" zal de huidige tijd (08:00) worden gebruikt voor de mutatie, terwijl de voorraad pas maandag om 14:00 op voorraad is gekomen. Resumer, als we de handeling op een andere datum verrichten, dient dit ná 14:00 te gebeuren (of per een andere dag) omdat de voorraad er anders nog niet was.
Dit kan af en toe best voor rariteiten zorgen (maar ja, het alternatief, om de gebruiker een tijd in te laten vullen) is ook niet echt wat.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOLLDR | Direkt Leveren | 08-01-2014 | 11-02-2014 |
| LOLLEETV | Boeken Levering Extra Emballage. | 26-07-2013 | 12-02-2014 |
| LOLLEMTV | Omschrijving (nog) niet bekend | 08-01-2014 | 12-02-2014 |
| LOLLTVZR | Levering zonder Raaplijst | 08-01-2014 | 12-02-2014 |
| LOLRBK | Invullen Raaplijst-Regel. | 08-01-2014 | 11-02-2014 |
| LOLRGK | Goedkeuren Raaplijst. | 23-01-2014 | 12-02-2014 |
| LOLRRG | Rapen en Goedkeuren Raaplijst. | 23-01-2014 | 12-02-2014 |
| LOLRTBZ2 | Omschrijving (nog) niet bekend | 25-09-2013 | 11-02-2014 |
| LOLRTBZC | Omschrijving (nog) niet bekend | 01-03-2012 | 11-02-2014 |
| LOLRTR | Omschrijving (nog) niet bekend | 11-11-2013 | 11-02-2014 |
| LOLRTRBK | Terugboeken Raaplijst | 16-09-2010 | 11-02-2014 |
| LOLRTREM | Omschrijving (nog) niet bekend | 08-01-2014 | 11-02-2014 |
| LOLRTREX | Omschrijving (nog) niet bekend | 11-11-2013 | 11-02-2014 |
| LOLRTRGC | Terugboeken Levering op Voorraad-Geleverde Charges | 11-11-2013 | 11-02-2014 |
| LOMD | Keuze voor Raadplegen Vrd.mut. | 07-02-2014 | 12-02-2014 |
| LOOVVWVO | Omschrijving (nog) niet bekend | 07-03-2005 | 11-02-2014 |
| LOVIDTBR | Omschrijving (nog) niet bekend | - - | 11-02-2014 |
