collapseMultipleActiveParties

Description
This transaction collapses multiple suspect parties, marking them inactive and creating a new party based on externalized rules of survivorship. This service is almost identical to collapseMultipleParties, except that it does not return an error if the source party provided in the input is an inactivated party and only one party is provided in the request (see usage 1).
Web Services
Operation name: collapseMultipleActiveParties

Service name: PartyService

Example
Usage 1
Given a specific party, find all A1 suspect matches on the database and collapse the parties according to survivorship rules. If the supplied party is not active with at least one linked record in the InactiveContLink table, then the collapseMultipleActiveParties service appends a warning message to the TCRMConsolidatedPartyBObj response, indicating that the requested party is already collapsed.
Usage 2
Given multiple parties, collapse them according to survivorship rules.
Usage 3
Given multiple parties to be collapsed, plus a new party definition, collapse the parties and create the new party according to the new supplied party definition.
Usage information
The collapseMultipleActiveParties service was specifically designed to be used by the Batch Activity Dashboard and other UI applications where multiple, consecutive collapse party service calls will be invoked to complete the task of collapsing parties during bulk load operations.
Preconditions
  • Given source party must exist.
  • Collapsing parties (if provided) must exist and be suspects of the given source party.
Mandatory input
  • source PartyId
Inquiry levels
Not applicable
Filter values
Not applicable
Transaction behavior
Usage 1
The request Party List contains a vector of one Party business object. The Party ID must be provided, and no other details are required.

If the supplied party is not active with at least one linked record in the InactiveContLink table, then this service appends a warning message to the TCRMConsolidatedPartyBObj response indicating that the requested party has already been collapsed. Otherwise, the service delegates to the regular collapseMultipleActiveParties service and performs the following steps:

  • Reads the suspect table and finds all A1 suspects of the provided party using an externalized rule (FindAllSuspectMatchRules.java).
  • Creates a new party using an externalized rule of data survivorship (CollapseMultiplePartiesRule.java).
  • Inactivates parties that were collapsed.
  • Creates suspects for the newly created party.
  • Creates party links between inactivated original source parties and the new target party.

The default implementation of the externalized rule for FindAllSuspectMatchRules.java will return A1 match records found, or return error if no A1 matches found. The maximum number of A1 matches returned from this rule is configurable in the Configuration and Management component. If the number of A1 matches found is higher than that set in the Configuration and Management component, it will sort the A1 matches by match score (highest first), then return only the set number of A1 match records.

The default implementation of the externalized rule of data survivorship will navigate through all data associated with the source party and A1 match parties, and copy all unique data (based on business key) to the new party. If common data is found on the source and suspect parties, then the business object with the latest last update date (LUD) is copied to the new party. If the LUD is the same for A1 match parties (this may occur if the data was directly loaded into the database), the data from the source party is copied to the new party.

Usage 2
The request Party List contains a vector of multiple Party business objects, and all party IDs must be provided. No other details are required. These parties are collapsed even if a better match exists on the database.
When provided with these two party IDs, this transaction performs the following steps:
  • Creates a new party using an externalized rule of data survivorship (CollapseMultiplePartiesRule.java).
  • Inactivates parties that were collapsed.
  • Creates suspects for the newly created party.
  • Creates party links between inactivated original source parties and the new target party.
Usage 3
The request Party List contains a vector of multiple Party business objects: source party, given multiple collapsed parties, and one target party. The source party IDs and given multiple collapsed party IDs must be provided and the target party must include all business objects that should be copied to the new party. These parties are collapsed even if a better match exists in the database.
When provided with the Party IDs and target party definition, this transaction performs the following steps:
  • Creates a new party as defined in the request.
  • Inactivates parties that were collapsed.
  • Creates suspects for the newly created party.
  • Creates party links between inactivated original source parties, given multiple collapsed parties and the new target party.
Request message
<TCRMTxType> collapseMultipleActiveParties

<TCRMTxObject> TCRMConsolidatedPartyBObj

<TCRMObject> TCRMConsolidatedPartyBObj

with mandatory business object:
Response objects
TCRMConsolidatedPartyBObj
Special note
Not applicable