Voor veel van onze klanten is de informatie in Dynamics NAV en Dynamics 365 BC van onschatbare waarde. Met het wijzigingslog of changelog kunnen wijzigingen in alle tabellen van het systeem bijgehouden worden. Loggen van autorisaties en de inrichting van het log zijn niet uit te schakelen, standaard wordt verder niets gelogd. Instellen doe je onder Afdelingen/Beheer/IT-beheer/Algemeen/Wijzigingslogposten en vervolgens in het lint Acties > Tabellen. Let hier ook op dat logging geactiveerd is. Naast de volledige tabel kun je ook individuele velden loggen.
Audit-trail
Waarom zou je loggen? Je ziet wat er in het systeem staat en als dat niet klopt kun je even rondvragen bij collega's. Als auditors willen we graag zekerheid geven over de betrouwbaarheid van de gegevensverwerking met NAV. Dit doen we met een audit-trail: een geschiedenis van mutaties, je ziet wat door wie wanneer is veranderd, inclusief vorige waarden. Mits goed ingericht biedt het wijzigingslog in Dynamics NAV en 365 BC hier een perfect handvat voor.
Met een goede inrichting zie je of de functiescheiding goed is toegepast; of bijvoorbeeld deblokkeren van artikelen alleen is gedaan door mensen die dat mogen. Achterhalen van fraude is een andere belangrijke motivatie, met loggen van bankrekeningnummers van leveranciers en klanten als direct voorbeeld. Bij procesverstoringen door wijzigingen aan inrichting of stamdata wil je ook kunnen achterhalen wie wanneer iets heeft gewijzigd. Ons uitgangspunt is dat instellingen, stamgegevens en kritische procesgegevens (denk aan statuswijzigingen van een project) altijd gelogd moeten worden. Maar waarom zou je niet gewoon alles loggen?
Changelog Dynamics NAV
Het changelog van NAV en 365 BC maakt per wijziging een regel aan; aanmaken van een nieuwe klant waar 25 velden worden gevuld levert dus 25 regels in het log op als de hele tabel wordt gelogd. Het wijzigingslog wordt onbruikbaar traag door het grote aantal regels en je zoekt naar een speld in een hooiberg als je het nodig hebt. Logposten sla je op in de database waardoor die vele gigabytes groot wordt, die ook terugkomen in de back-up. Alles loggen is gelukkig ook niet nodig voor effectief gebruik. Veel van onze klanten zijn intensieve loggers maar hebben geen last van performance problemen of onhandelbare groei van de database.
Ze hebben goed nagedacht over wat ze loggen. Hier moeten control en de business zich afvragen: wat zijn écht kritische stamdata, instellingen en procesinformatie? Hoewel belangrijk, zijn grootboekposten en documentgoedkeuringsposten bijvoorbeeld een log op zichzelf. Transactie gerelateerde velden (bijv. in- en verkoopkop en regel) zijn beperkt interessant omdat er weinig definitiefs in staat. Voor instellingen en kritische stamdata daarentegen (nummerreeksen, namen, boekingsgroepen, etc. van stamdata, financiële instellingen) is loggen zeker aan te raden.
Ons advies: begin gewoon met de inrichting en evalueer dit regelmatig, zeker in het begin. Met iteratieve aanpassingen op basis van de resultaten bouw je een gedegen set wijzigingsloginstellingen. Gaandeweg wordt het als tool steeds waardevoller en krijg je het steeds beter onder de knie.
