Hi There,
I have given it some thought and here is an example of something you can do that will not affect posting. This is more work to develop, but you have full control of it and what information you want to check.
- A "Master Data Compare" table that records the balance of each master record.
- A Codeunit that runs on a job queue at intervals, checking the balance and compares it to the "Master Data Compare".
- If different, modify the master record ONCE (updating the SystemModifiedAt field), and update the Master Data Compare with the current value so the next time the job runs runs and the value has not changed, then don't modify the record.
By using events on triggers as suggested:
- this cannot be switched off, you have to make code changes to remove it, becomes critical if it is any emergency in production.
- updates master records many times if triggers are on subledger entries.
- if master record is locked, posting fails.
- posting runs longer - every time.
- introduce issues if failed postings does not roll back correctly.
By using the Job Queue and running a codeunit at intervals:
- gives total control of when it runs and you can stop it from running ANY TIME.
- does not lock master data continuously as it only update ONCE, and only if value is different after last run.
- commits each change immediately, meaning table locks are very short, and rollback is up to the last committed record if another user locks the current master record the job queue attempts to check.
- does NOT affect posting for any user as it runs in the background.
- efficient, using partial records (only specific fields of a record is loaded) so should process records quickly.
Note: It is important to use partial records like I have in my attached example. You may used it and change it to your needs.
Hope this helps.
