splitParty
- Description
- This transaction replaces a single party with two new parties. The splitParty transaction addresses the situation where, due either to error or data conversion, two distinct parties are stored as one party in the database and need to be separated.
- Web Services
- Operation name: splitParty
- Service name: PartyService
- Example
- Mark Travis and Marc Travis are two distinct parties who both share the same birthday. These two parties were collapsed in error and must be reinstated as two distinct parties.
- Usage information
- Do not include a value for the PartyActiveIndicator in the request. This value is determined by the MDM operational server and will be included in the transaction return. This sets the PartyActiveIndicator apart from other indicators such as AlertIndicator, SolicitationIndicator, and ConfidentialIndicator.
- Preconditions
- Party must exist.
- Mandatory input
- PartyId
- PartyType
- Inquiry levels
- Not applicable
- Filter values
- Not applicable
- Transaction behavior
- In the Split Party transaction, the following steps occur:
- The original party is inactivated.
- Two new parties are created.
- A suspect record is created for each of the two new parties, with a suspect status indicating that the parties are not duplicates.
- Suspects to the newly created parties are identified if suspect processing (a configurable option) is turned on.
- Party links are created between the inactivated original party that was split and the two new parties to provide traceability between the new parties and the original party. No link is created between the two new parties themselves.
- The party details, party name, party contact method, party address, identification, party relationship, party bank account, party charge card, and income source information is copied from the original party to the two new parties created through the split party transaction.
- Request message
- <TCRMTxType> splitParty
<TCRMTxObject> TCRMPartyBObj
<TCRMObject> TCRMPartyBObj
- Response objects
- TCRMPartyListBObjNote: The first party in the list is the original party, and the two following parties are the new parties created through the split party transaction.
- Special note
- By default, when a party is split in InfoSphere® MDM, the corresponding product-party roles do not survive in the newly created parties.