Search Results get_status

Overview

UMX_PARTY_MERGE is a PL/SQL package body owned by APPS that participates in the TCA/HZ party merge process within Oracle E-Business Suite. Its role is to reconcile the Oracle User Management (UMX) registration request data whenever two trading community parties are merged. During a party merge operation, records that reference a "from" party (the party being merged away) must be repointed to the surviving "to" party. UMX_PARTY_MERGE acts as a client-side extension of the HZ party merge framework, providing the UMX-specific logic needed to keep UMX_REG_REQUESTS rows consistent with the outcome of the merge. A secondary and equally important function is to prevent the merge from proceeding when the source party has outstanding registration activity, thereby preserving the integrity of pending user-registration workflows. The package body carries an embedded revision marker of version 115.1, dated July 2004, reflecting its long-standing stability across the 12.1.1 and 12.2.2 releases. It is classified in the ETRM metadata as an OTHER API rather than a public or private API, indicating it is primarily an internal merge subscriber rather than a general-purpose callable interface.

Key Procedures and Functions

The package body exposes a single documented procedure, MERGE_PARTIES. This procedure is the merge event handler invoked for the UMX entity relationship. It performs three sequential responsibilities: first, it evaluates whether the merge is permissible; second, it performs the required data remediation; and third, it reports success or failure to the calling merge framework.

• MERGE_PARTIES — The procedure first opens the internal GET_STATUS cursor, which the user query referenced, selecting the STATUS_CODE from UMX_REG_REQUESTS for the source party filtered to status_code = 'PENDING'. If any pending registration request exists for the source party, the procedure sets the return status to FND_API.G_RET_STS_ERROR, attaches the message UMX_MERGE_NOT_ALLOWED, and returns without modifying data — blocking the merge. If no pending request is found, and the parent entity is HZ_PARTIES and the source and target party identifiers differ, the procedure updates UMX_REG_REQUESTS, repointing requested_for_party_id from the source party to the target party and stamping the standard audit columns (last_update_date, last_updated_by, last_update_login) from HZ_UTILITY_PUB. Any unexpected exception is trapped and reported through HZ_API_OTHERS_EXCEP with the SQL error text as a token, and the return status is set to FND_API.G_RET_STS_UNEXP_ERROR.

Tables Accessed

Only one base table is referenced, through an APPS synonym:

• UMX_REG_REQUESTS — Read by the GET_STATUS cursor to detect pending registration requests for the source party, and updated by the merge logic to transfer requested_for_party_id to the surviving party. This is the sole persisted object the package reads or writes.

The package also depends on shared TCA/HZ utility and framework constructs, notably FND_API for standardized return statuses, FND_MESSAGE and FND_MSG_PUB for message handling, and HZ_UTILITY_PUB for consistent audit column values.

Usage Notes

UMX_PARTY_MERGE is not intended to be called directly by end users. It is invoked by the HZ party merge framework as a registered entity handler when a party merge is executed, typically from the Trading Community Manager merge user interface or from a party merge concurrent program. Because it is a merge subscriber, the framework calls MERGE_PARTIES with the source and target party identifiers and interprets the returned status to decide whether the overall merge may continue. Administrators should understand the blocking behavior: a party with a registration request still in PENDING status cannot be merged, and the merge must be deferred until that request is resolved. In 12.1.1 and 12.2.2 the package behaves identically, as no release-specific overrides are documented. Customizations should avoid modifying this package body; any required logic changes should be implemented as additional merge handlers or by extending the framework rather than by altering the delivered code.