Search Results delete_customer_alt_names

Overview

HZP_CUST_PKG is a PL/SQL package owned by the APPS schema that serves as a shared utility layer for the Oracle E-Business Suite Receivables and Trading Community (HZ) customer data model. It is declared with AUTHID CURRENT_USER, meaning its SQL executes under the privileges of the invoking user rather than the package owner, a design choice consistent with the Oracle EBS concurrency and security model. The package header source carries the CVS identifier ARHCUSTS.pls 120.5, dated 2005, indicating a long-lived component carried forward into the 12.1.1 and 12.2.2 code lines.

The package bundles validation routines, customer-site resolution lookups, dunning configuration helpers, and credit-limit derivation logic used by the Customer Standard and related Receivables forms. It is not itself a business API with event publishing; ETRM classifies it as API classification OTHER, and the metadata confirms that it is referenced by 6 other packages, indicating its role as a subordinate utility rather than an entry point.

Key Procedures and Functions

The package exposes eleven documented routines across three functional groupings.

• Uniqueness validation: CHECK_UNIQUE_CUSTOMER_NAME, CHECK_UNIQUE_CUSTOMER_NUMBER, CHECK_UNIQUE_PARTY_NUMBER, and CHECK_UNIQUE_ORIG_SYSTEM_REF. These accept a row identifier plus the candidate attribute value and signal a collision to the calling form. CHECK_UNIQUE_CUSTOMER_NAME additionally returns a warning flag through an OUT parameter, distinguishing a hard duplicate from a soft, user-overridable condition.
• Alternate name maintenance: DELETE_CUSTOMER_ALT_NAMES removes alternate name records associated with a customer. It receives the row identifier, a status value, and the customer identifier as its three inputs. In the Customer Standard form this is invoked when alternate names are cleared or superseded during a customer update.
• Site, dunning, and credit resolution: GET_STATEMENT_SITE, GET_PRIMARY_BILLTO_SITE, GET_DUNNING_SITE, and GET_CURRENT_DUNNING_TYPE return site or dunning identifiers and codes for a given customer account, with the dunning-type function accepting an optional bill-to site. ARXVAMAI_OVERALL_CR_LIMIT and ARXVAMAI_ORDER_CR_LIMIT compute overall and order-level credit limits for a customer, currency, and site-use combination.

The specification also declares a package-level collection type, id_tab, and a global g_site_use_id_tab variable used to cache site-use identifiers during a session.

Tables Accessed

Documented table references reach the HZ and AR base tables through APPS synonyms.

• HZ_CUST_ACCOUNTS — the customer account master, keyed by CUST_ACCOUNT_ID; central to the site, dunning, and credit-limit lookups.
• HZ_CUST_ACCT_SITES and HZ_CUST_SITE_USES — address and site-use rows from which statement, bill-to, and dunning sites are resolved; the site-use identifier collection draws from this table.
• HZ_PARTIES — the party record underlying the customer, used in party-number and original-system-reference uniqueness checks.
• HZ_CUSTOMER_PROFILES and HZ_CUST_PROFILE_AMTS — profile and amount records supporting dunning-type and credit-limit determination.
• AR_DUNNING_LETTER_SETS — dunning letter configuration referenced by the dunning helpers.
• DUAL and PLITBLM — used for scalar evaluation and PL/SQL index-by table handling respectively.

Usage Notes

HZP_CUST_PKG is invoked primarily from the Oracle Receivables Customer Standard form and from concurrent programs that maintain customer data, but the most significant dependency is indirect: six other packages call into it, so changes to these routines propagate widely. Custom code should treat the package as an internal EBS artifact rather than a supported public API. Where a supported interface exists, the Oracle Trading Community public APIs and the Receivables customer APIs should be preferred. Customizations that call these routines directly must account for the AUTHID CURRENT_USER behavior, ensuring the invoking schema holds the necessary HZ and AR object privileges. Because the header dates from 2005 and contains no 12.2-specific revision markers, behavior is effectively identical between 12.1.1 and 12.2.2; the primary 12.2 consideration is the Online Patching editioning model, under which this package is treated as a non-editioned object within the APPS schema.