Audit functionality is implemented by database triggers, so *any* updates to the database tables for an audited attribute will cause new entries in the audit table (CMN_AUDITS).
There are various things I would investigate ; as others have mentioned look at *ANY* (bespoke) jobs that are running on your system - but also look at *ANY* interfaces, *ANY* custom triggers, *ANY* adhoc updates.
The reason I emphasise *ANY* is that the date/time stamp (and the "last updated by") on the audit table can be "misleading" where the data has been updated by a non-stock (i.e. bespoke) method, because if such a thing only updates the single column on the audited table, then the when and who information on the audit log will be wrong as this is copied from the base table itself rather than being generated by the trigger - what I am saying is that if the update does not also set the last_updated_by and last_updated_date on the base table then the last_updated_by and last_updated_date values in the audit log will actually be the "previous" update to the table, not the actual update.
The other thing I'd look at is the raw data on the CMN_AUDIT table, the "Finish" field is a date/time field and since the screen only shows you the date element you are missing some possibly interesting information (if a field has not changed, then the trigger should not be auditing it at all, so perhaps looking at the raw data on the table might help you understand what is actually going on?
Original Message:
Sent: 11-01-2019 11:48 AM
From: Jia En Chua
Subject: Project security and finish auto changes but old value equal to new value