Search Results create_party_site_use

Overview

The APPS.PV_PARTNER_ACCNT_MGMT_PVT package body is a private PL/SQL API belonging to the Oracle Partner Management (PV) module, part of the Oracle E-Business Suite 12.1.1 and 12.2.2 codebase. Its principal business function is to manage the lifecycle of customer accounts and associated site records that are created on behalf of channel partners within the Partner Management and Trade Management (now Oracle Channel Revenue Management) application flows. The package encapsulates the logic required to convert a partner party record into a fully formed Oracle Receivables customer account, including the creation of party sites, account sites, and site uses.

The package is classified as a private (PVT) API, meaning that it is not intended for direct invocation by external integrations. It provides internal service procedures consumed by public partner account management APIs and by the PV module's own transaction flows. The header revision date (2005) confirms the code is a long-standing component of the PV schema. The source file is pvxvpamb.pls.

Key Procedures and Functions

The documented package exposes four procedures and functions. Their names and purposes are as follows:

• CREATE_PARTY_SITE — Creates a party-site record for the partner organization, establishing the location context against which customer account sites can subsequently be associated. It is the procedure whose name matches the user's search term and is the entry point for building the HZ_PARTY_SITES and HZ_PARTY_SITE_USES data.
• GET_PARTNER_ACCNT_ID — Retrieves the identifier of the customer account associated with a given partner party, allowing downstream processes to resolve the Receivables account ID from a partner party ID.
• GET_ACCT_SITE_USES — Returns the account site use records for a customer account, exposing the HZ_CUST_SITE_USES information used by callers to determine which site uses (for example bill-to or ship-to) exist.
• GET_CUST_ACCT_ROLES — Returns the customer account role assignments (for example bill-to and ship-to roles) held by a given account, based on HZ_CUST_ACCOUNT_ROLES.

An additional internal procedure, Create_Customer_Account, is visible in the source excerpt. It uses the HZ_CUST_ACCOUNT_V2PUB, HZ_PARTY_V2PUB, and HZ_CUSTOMER_PROFILE_V2PUB record types to construct a customer account from an organization party, and returns the account ID to the caller.

Tables Accessed

The package reads and writes the following documented tables and views via APPS synonyms:

• HZ_PARTIES — source of the organization party name and party number used to derive the customer account.
• HZ_PARTY_SITES and HZ_PARTY_SITE_USES — target structures created by CREATE_PARTY_SITE.
• HZ_LOCATIONS — location master data referenced when building party sites.
• HZ_CUST_ACCOUNTS — the customer account master, populated by Create_Customer_Account.
• HZ_CUST_ACCT_SITES and HZ_CUST_SITE_USES — account site and site-use records queried by GET_ACCT_SITE_USES.
• HZ_CUST_ACCOUNT_ROLES — role assignments queried by GET_CUST_ACCT_ROLES.
• HZ_ROLE_RESPONSIBILITY — supporting role-to-responsibility configuration.
• AR_SYSTEM_PARAMETERS — Receivables system options consulted when deriving account numbers and profile defaults such as the generated customer number format.

Usage Notes

Because this is a PVT package, it is not exposed as a public interface. It is referenced by two other packages in the Partner Management schema, which act as public wrappers and are the appropriate integration points for custom development. Typical invocation occurs from Partner Management forms and OAF pages that register channel partners and create their associated customer accounts, as well as from concurrent programs that batch-create partner customer accounts. Developers extending partner account registration should call the corresponding public APIs rather than PV_PARTNER_ACCNT_MGMT_PVT directly. The procedures rely on standard EBS API conventions — FND_API message handling, savepoint usage, and x_return_status/x_msg_count error reporting — so callers must check the return status and retrieve messages from the FND message stack. All operations run within the caller's transaction and respect the p_commit commit flag.