Search Results x_exception_msg

Overview

APPS.POS_ENTERPRISE_UTIL_PKG is a utility package in the Oracle E-Business Suite iProcurement / Oracle Sourcing (POS) schema that centralizes the identification and creation of the "Enterprise" party record used for buyer-side, internal purchasing activity. In EBS, the enterprise party represents the buying organization itself, and many sourcing, negotiation, and procurement functions need a reliable single reference to that party. This package encapsulates the query logic against the trading community model tables so that callers do not have to duplicate it.

The package exposes a small, focused API surface: it defines the enterprise as the HZ_PARTIES row that carries an active HZ_CODE_ASSIGNMENTS classification of POS_PARTICIPANT_TYPE / ENTERPRISE. The header indicates a source version of 120.2 (2005), and the package is classified in ETRM as OTHER rather than as a formal public API, but it is referenced by twelve other packages, making it a shared internal dependency.

Key Procedures and Functions

• GET_ENTERPRISE_INFORMATION — The core routine. It returns the enterprise party identifier and party name, together with a status code and, when applicable, an exception message via the x_exception_msg OUT parameter. Internally it opens a cursor over HZ_PARTIES joined to HZ_CODE_ASSIGNMENTS, filters for the active ENTERPRISE participant type with a null or future end date, and expects exactly one row. If no row is found it sets x_exception_msg to 'enterprise party not found' and status to 'E'; if more than one row is found it sets x_exception_msg to 'found more than 1 enterprise party' and status to 'E'. On success it returns status 'S' and a null exception message.
• GET_ENTERPRISE_PARTY_NAME — A convenience wrapper that returns only the enterprise party name, delegating to GET_ENTERPRISE_INFORMATION and discarding the party identifier.
• GET_ENTERPRISE_PARTYID — A convenience wrapper that returns only the enterprise party identifier, delegating to GET_ENTERPRISE_INFORMATION and discarding the party name.
• CREATE_ENTERPRISE_PARTY — Creates the enterprise party record when none exists, so that downstream sourcing and procurement flows have a valid enterprise reference.
• POS_CREATE_ENTERPRISE_USER — Creates the corresponding FND_USER representation associated with the enterprise party, tying the party model to the EBS application user model.

Tables Accessed

• HZ_PARTIES — The registry of parties. Read by the getter routines to resolve the enterprise party identifier and name, and written by CREATE_ENTERPRISE_PARTY when the enterprise party must be created.
• HZ_CODE_ASSIGNMENTS — Holds classifications applied to parties. It carries the POS_PARTICIPANT_TYPE / ENTERPRISE code assignment that identifies which HZ_PARTIES row is the enterprise; the getter query filters on this table (status 'A', category, class code, and active date range).
• FND_USER — The EBS application user repository, written or referenced by POS_CREATE_ENTERPRISE_USER to establish the enterprise user account.

All three objects are accessed through APPS synonyms, as is standard in the EBS schema model.

Usage Notes

The package is normally invoked as a server-side utility rather than from a user-facing form directly. Sourcing and iProcurement internal flows, and custom extensions that need to know who the buying enterprise is, call these routines to obtain the enterprise party id or name before performing negotiations, document defaults, or setup operations. Because every getter funnels through GET_ENTERPRISE_INFORMATION, callers should always inspect x_status and x_exception_msg: status 'E' with the message 'enterprise party not found' indicates that setup is incomplete, while 'found more than 1 enterprise party' indicates a data integrity problem requiring correction. Callers should also be aware that the package treats the enterprise as a singleton; the duplicate-row branch exists specifically to protect against misconfiguration. Custom code should not replicate the party query but call this package so that a future change to the enterprise identification rule is honored consistently across the twelve dependent packages.