Difference In Validating UCM Survivorship Rules Between Root And Child Entities Using Custom Date Field For Scenario SDH Incoming Datetime = ATG.LAST_MOD_DT
Last updated on OCTOBER 17, 2016
Applies to:Siebel Data Quality - Version 15.5 [IP2015] and later
Siebel Universal Customer Master - Version 15.5 [IP2015] and later
Information in this document applies to any platform.
SIEBEL VERSION: Siebel 15.5 [IP2015]
Customer performed the steps outlined in this KM article to use a custom datetime column for Siebel UCM to compare against to determine which value would survive:
- 1591968.1 - How can Siebel UCM Child Survivorship feature use a custom date time column for comparison against the attribute modification timestamp?
The object being used was Account, with child Entity SE on Account Address.
The child SE rule uses Default Criteria = 'Recent', which means the more recent datetime value wins.
During testing, it was observed that when the incoming Datetime value is the same as the existing ATG LAST_MOD_TS, the operation applied to the record at the parent level is different than the child level.
At the parent (Account root level), when the incoming Datetime value is the same as the existing ATG LAST_MOD_TS, the incoming value fails since the existing base table value is already the same time stamp; resulting in no update allowed.
At the child (Address level), when the incoming Datetime value is the same as the existing ATG LAST_MOD_TS, UCM SE allows the incoming value to overwrite the existing base table field value; resulting in an update allowed.
The behaviour of "when the incoming Datetime value is the same as the existing ATG LAST_MOD_TS" is therefore not consistent between the parent and child level, which causes unpredicatable and inaccurate data values as a result.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms