updatePartyIdentification

All information that can be added as part of the addPartyIdentification transaction, including the identification type, and details such as the actual identification number, status (active, applied for, expired, and so on), expiry date, and effective date can be changed through this transaction.

• IdentificationIdPK
• PartyIdentificationLastUpdateDate

Specific party identification types, such as Social Security Number (SSN), Social Insurance Number (SIN), and Tax Identification Number (TIN) are defined as critical data by default.

If Critical Data Change processing is not enabled, changes to a Social Security Number, Social Insurance Number, or Tax Identification Number submitted through this transaction are immediately processed and reflected in the existing party record.

If Critical Data Change processing is enabled, when InfoSphere® MDM recognizes any data change to the specific party identification type in a transaction request, a record of the Critical Data Change is created and held, pending acceptance. A notification of the Critical Data Change request is generated upon creation of the Critical Data Change record.

All critical and noncritical data belonging to the same party identification type contained in an update request are grouped into and treated as a single Critical Data Change. This Critical Data Change must be accepted or rejected in its entirety as a single unit. In other words, noncritical data belonging to the same object of the same identification type as the critical data submitted for acceptance are handled in the same way as critical data. Updates of identification types other than SSN, SIN, and TIN are processed immediately without having to go through the acceptance process, unless it is defined in the configuration by the user as critical data.

Once the pending Critical Data Change request is created, an indicator is activated on the party record that prohibits the subject party from collapsing with other parties, splitting into new parties, or further updating other critical data or noncritical data for the same object as the existing pending Critical Data Change. Further, this party will be ignored by the "best match" rule in suspect processing until the indicator is off. This indicator is switched off when there is no associated unresolved Critical Data Change.

If standardization for PartyIdentification is configured 'on' and the IdentificationNumber being added is a Social Security Number (SSN), then the number is standardized in the format XXX-XX-XXXX, where X is a numeral. For standardization, the value provided must be in the correct format. IdentificationNumber values that contain alphabetic characters, or those with less or more than nine numerals, are not standardized.

<TCRMTxObject> TCRMPartyIdentificationBObj

<TCRMObject> TCRMPartyIdentificationBObj

• Only one pending Critical Data Change is allowed at any given time. This rule will not be overridden by any other direct update transaction such as updatePartyCriticalData.
• When the party does not have any pending Critical Data Change, a user with security access can update a party's identification directly through the updatePartyCriticalData transaction.
• As long as an update request does not contain any updates to any instances of business objects that currently have an active pending Critical Data Change, the update response will indicate success. When the update request contains an instance of a business object that currently has a pending Critical Data Change, the update response will indicate failure. No partial update or add will be performed for any critical or noncritical data that was included in a failed update request.