In de financiële administratie zijn er twee parameters die een grens impliceren waarbinnen gejournaliseerd mag worden; deze 'onder- en bovengrens' worden bepaald door parameters 'Boeken toegestaan vanaf - t/m', die ingesteld kunnen worden bij het Rekeningschema (Hoofdmenu, 7 Financieel, 8 Overige Basisgegevens, 2 Rekeningschema's, 1 Raadplegen-/Onderhoud, F5 Wijzigen).
Veel financiële mutaties worden aan het grootboek beschikbaar gesteld vanuit een subadministratie. Deze subadministratie behoort daarmee ook netjes te kontroleren of de mutatiedatum binnen deze ingestelde grens ligt; gebeurt dat niet, dan kan in de subadministratie een wijziging worden verwerkt die financieel niet per die datum mag worden gemuteerd.
V.w.b. het 'verleden' (de ondergrens) is deze kontrole zo goed als overal opgenomen, echter, vandaag is gebleken dat er een aantal funkties waren die niet op de bovengrens kontroleerde.
Zo was het mogelijk om een Voorraadmutatie toe te kunnen voegen in 2017, welke ook per 2017 moest worden gejournaliseerd, maar wat in niet toegestaan was omdat rubriek 'Boeken toegestaan t/m' met 31-12-2016 was gevuld.
Merk op dat veel mutaties in het Logistieke pakket 'realtime' worden verwerkt. Als we nu voorraad verplaatsen naar een Externe Lokatie, dan betreft dit een registratie van iets wat daadwerkelijk gebeurd is. De vraag is dan ook of we zoiets wel
moeten blokkeren op basis van de 'Boeken toegestaan t/m datum' instelling; we zouden immers niets kunnen zolang de parameter niet is aangepast.
Kombineer dit met de wetenschap dat talloze klanten in de eerste week opbellen en met de melding 'Boekdatum na datum formeel toegestaan' worden gekonfronteerd en niet meer weten hoe ze dit ook al weer een jaar moesten opschuiven, en realiseer je dat als we deze kontrole te strikt inbouwen, medewerkers die 's morgens om 05:00 beginnen te werken al meteen niets meer kunnen doen (en zowel de Systeembeheerder alsmede Heart pas om 08:15 beginnen) de impact zal zijn dat er 3 uur niet gewerkt kan worden.
De oplossing wordt derhalve tweeledig:
Ten eerste gaan we inbouwen dat bij het opstarten van Profit wordt gekontroleerd of de parameter "Boeken toegestaan t/m datum" binnenkort komt te vervallen, en zo ja, de gebruiker hierop te attenderen. Zo'n melding is niet zinvol voor 'normale' gebruikers, en dus zal de kontrole alleen worden uitgevoerd bij 'Managers'.
Omdat ook een Systeembeheerder met vakantie moet kunnen gaan, zal de melding ruimschoots van te voren worden aangegeven. We bouwen (hard) een periode in van 3 weken (21 dagen) hetgeen voldoende lang wordt geacht om deze datum te kunnen verlengen.
Ten tweede zullen we de kontrole nog niet meteen 'overal' inbouwen, maar allereerst op een aantal strategische plekken. Heeft u nog een funktie gevonden waarin het ook toegestaan is iedere datum in te vullen, meldt het, dan kunnen we ook die funktie valideren op de juistheid van de mutatiedatum.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| ADABAFBD | Verwerken Afschrift Diskette | 26-10-2005 | 04-01-2017 |
| ADBKDBBO | Dagboek Journalisering | 20-12-2013 | 04-01-2017 |
| ADBOTVV | Omschrijving (nog) niet bekend | 19-08-2014 | 04-01-2017 |
| ADBOVSBK | Korrigeren verschillen | 07-01-2015 | 04-01-2017 |
| ADCBBD | Boekdatum Afletteren | 26-10-2005 | 04-01-2017 |
| ADFITV | Boeken Ingekomen Fakturen | 04-08-2016 | 03-01-2017 |
| LOELOGDL | Gedeeltelijke Ontvangst Emballage | 28-10-2015 | 04-01-2017 |
| LOELOGGL | Gehele Ontvangst Emballage | 09-02-2016 | 04-01-2017 |
| LOIELVDL | Gedeeltelijke Levering Emballage | 12-08-2014 | 04-01-2017 |
| LOIEOGDL | Gedeeltelijke Ontvangst Emballage | 05-01-2011 | 04-01-2017 |
| LOILOGT1 | Omschrijving (nog) niet bekend | 05-02-2015 | 04-01-2017 |
| LOLRBK | Invullen Raaplijst-Regel. | 04-01-2017 | 04-01-2017 |
| LOLRRG | Rapen en Goedkeuren Raaplijst. | 02-01-2017 | 04-01-2017 |
| LOUFGN | Genereren Uitg. Fakturen | 12-05-2016 | 03-01-2017 |
| LOVMTV | Opnemen Voorraadmutaties | 30-01-2015 | 03-01-2017 |
| LOVMTVVA | Omschrijving (nog) niet bekend | 10-10-2014 | 04-01-2017 |
