We recently found we lost all changelogs when we migrated from E9 to E10(don’t know you lost it until you need it). It looks like a data directive using widgets is the standard way to implement changelogs in E10, and in our testing it’s really simple to implement. That has lead us to the question of what fields do we want to log. We have a discussion started, but before we spend to much time I’m wondering if there is a default Changelog list anywhere or something similar that doesn’t result in us having to start from scratch in regards to what fields we want a changelog on.
My fear being, we won’t know we didn’t log an important field until after we need the change history and don’t have it. I understand each company is unique, but I can see the value in having some default set of tables/fields that most companies would want to log.
Assuming no such default changelog fields exist, below are the screens our end users have asked us to review and add Changelogs on(still need to map out the actual table.field names). If we’re missing anything really important, we would love to hear your suggestions
Part
Part Class
Product Group
Customer
Order
Quote
Job
purchase order entry
subcontract shipment entry
User Account Maintenance
Company Maintenance
Menu Maintenance
Site Maintenance
Data Directives Maintenance
Method Directives Maintenance
We started off change logging a ton, which grew the size of the DB a lot (and folks wanted to report on unstructured text too, ugh!).
Since then, we’ve really pared back what is change logged, and also purge the change logs monthly with a 2 year cut-off. We use it to figure out how unintended changes happened, then train users to not make them (or lock down the fields if needed).
I believe logging should happen outside the database. There are MANY logging systems available today like SeriLog (Thanks @John_Mitchell) . It reduces your database size and reduces the ability to tamper with the logs. Also, data logging is one thing but application logging (who ran what, when, where; are there errors I’m missing?), DMT, changes to settings or the application…
From a technical perspective I really like the idea of moving the changelogs out of the Epicor DB, and leveraging syslogd or other open source solutions… Although from an end user’s perspective, I know they like to be able to see who changed what when from the screen in Epicor when things seem wrong…
Absolutely. Not that that isn’t doable with modern logging systems, it’s just not built into Epicor. One would need an endpoint to call to return changes that the user has security to see.
