correctPartyAddress
- Description
- This transaction adds or corrects attributes in a party address for a given Party without creating an historical party address record in the database, even though a new Address may be created if there is no matching address existing in the database.
- Web Services
- Operation name: correctPartyAddress
- Service name: PartyService
- Example
- Add a 'Care Of' address for Mark Smith, effective July 1 to September 30.
- Usage information
- This transaction should be used to edit the attributes of the
PartyAddress business object where no change to the Address object
is contemplated, such as changing the address usage type and adding
an end date. If you need to modify the address, for example, to correct
an apartment number or change a ZIP code, use the updatePartyAddress transaction,
even if the change is necessitated by an error made in the original
input.
Use this transaction discriminately because, upon successful completion of this transaction if a new address is created, the association between the original address and the given Party is only available using the history table in the Transaction Audit Information Log (TAIL).
- Preconditions
- A Party address must exist.
- Mandatory input
- PartyAddressIdPK
- PartyId
- AddressId
- AddressLastUpdateDate
- AddressGroupLastUpdateDate
- LocationGroupLastUpdateDate
- AddressLineOne
- City
- Inquiry levels
- Not applicable
- Filter values
- Not applicable
- Transaction behavior
- This transaction behaves very similarly to the updatePartyAddress transaction.
The only difference is that, as opposed to the update transaction,
correctPartyAddress does not retain the record of the previous party
address association in the operational table. The original PartyAddress
record (pre-correction) is kept only in the history table.
If the corrected address does not already exist, a new address is added to InfoSphere® MDM with a new AddressId. This new address is associated with the Party using the same PartyAddressIdPK, replacing the old address. If the corrected address does exist, the existing address is returned.
A seasonal start dates must be prior to the seasonal end date, if applicable.
The start date must be prior to or equal to the end date.
To make a party address inactive, set the end date prior to or equal to the current system date.
To reactivate an expired party address, provide a blank end date or set the end date to be after the current system date.
- Request message
- <TCRMTxType> correctPartyAddress
<TCRMTxObject> TCRMPartyAddressBObj
<TCRMObject> TCRMPartyAddressBObj
with associated TCRMAddressBObj
- Response objects
- TCRMPartyAddressBObj
with associated TCRMAddressBObj
- Special note
- Use the updatePartyAddress transaction if you wish to keep track of the party address association in the operational table after modifying the given address.