This topic came up today here at Epicor. Someone (who is rather skilled) noticed that a customer had a very large change log… as they examined it they saw that there were LOTS of change log entries for jobs that were beyond normal. I dialoged with him how to resolve the issue… but it made me look… turns out that I have been teaching this for years, but I never wrote it down.
SO… I will document here my rules on Change logs.
- Only log what you NEED logged… do NOT log all fields. Example: Do not log “last change date” because you will be entering a log entry that says you changed the last change date from 1/2/22 to 1/3/22 on 1/3/22… it is simply redundant.
- The most important rule: ADD FILTERS to your Change Log BPMs… FILTER OUT changes that you don’t need or want to log. To do this, simply add a CONDITION widget to the BPM before the log widget.
- Here is the MOST IMPORTANT EXAMPLE: Do NOT log changes on UNFIRM JOBs. Why? Because MRP is the only “user” that creates, schedules and changes unfirm jobs. This is done EVERY NIGHT. MRP will do these mass changes. And this will slow down MRP and cause HUGE Change logs to be create. If you have change logs on the JobMtl and JobOper tables, then every time MRP creates a job, it will create new log entries for the all the materials and operations. This clutter will continue to build on that temporary unfirm job, and is actually meaningless information.
- Also consider whether you actually need to log ADDITIONS to the change log… maybe only create a change log entry when the record actually Changes. These filters will reduce the workload for the system, and reduce the log file size.
Other ideas? Please “Log” them below (pun intended).