这些字段为：CHANGED_AT, HEAD_CHANGED_AT和CRM_CHANGED_AT
Have a look at Order header table CRMD_ORDERADM_H and you can find there are three different times. When, where and how is each populated?
CHANGED_AT
There is a scenario that the field CHANGED_AT is changed, but HEAD_CHANGED_AT remains untouched. The common scenario is that you make some changes on order line item only, for example change the description of line item.
When the change is to be persisted, a new timestamp is populated and filled to both CHANGED_AT and CRM_CHANGED_AT field.
The usage of CRM_CHANGED_AT is clearly explained in the source code.
Kindly notice the difference between changed_at from database buffer and latest value.
In line 163, the field value filled based on database buffer is overwritten with the latest data:
The purpose is, after this assignment, in line 166 we can use simple “=” to compare whether there are some other changes on ORDERADM_H besides these three fields ( since in line 163~165 we forcefully ensure the equality of them ).
Since we actually only make changes on item, so line 239 will not be executed – head_changed_at remains unchanged.
Now in line 335 the header object buffer is now changed with latest value of changed_at:
So in function module CRM_ORDER_UPDATE_TABLES_DETERM, an entry will be determined for update, which is simply because the changed_at value now in object buffer and database buffer are different. See comparison screenshot in debugger:
After the update function module is executed, the CHANGED_AT and CRM_CHANGED_AT is now persisted to header table successfully.
HEAD_CHANGED_AT
The scenario with this field involved is quite straight-forward, for example just make changes on header description. In this case HEAD_CHANGED_AT will be overwritten with CHANGED_AT, since now header object buffer and database buffer has different value for field DESCRIPTION:
