Search Results hzp_cust_pkg




Overview
Explore in AI Chat

Overview

HZP_CUST_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It resides in the Oracle Receivables and Trading Community (HZ) product family and provides a collection of utility routines that support customer profile maintenance and customer data validation. The package is classified as OTHER within the documented API taxonomy, meaning it is an internal support package rather than a formally published public API, though its procedures are callable by other EBS modules and custom code that already have visibility into APPS schema objects.

The package is documented with ETRM metadata indicating a VALID status and lists eleven procedures or functions. Its principal responsibilities fall into two functional areas: enforcement of uniqueness constraints on customer-related identifiers, and resolution of customer sites for statement, dunning, and credit limit purposes. Dependencies show that the package builds on lower-level utility packages such as ARP_CUST_ALT_MATCH_PKG, ARP_STANDARD, APP_EXCEPTION, and FND_MESSAGE, and that it is referenced by six other database objects, confirming its role as a shared internal service layer.

Key Procedures and Functions

The documented procedures and functions of HZP_CUST_PKG address two broad concerns: uniqueness verification and site or credit limit determination.

  • CHECK_UNIQUE_CUSTOMER_NAME — Validates that a proposed customer name does not already exist, supporting duplicate prevention during customer creation or update.
  • CHECK_UNIQUE_CUSTOMER_NUMBER — Confirms that a customer number is unique within the applicable numbering context.
  • CHECK_UNIQUE_PARTY_NUMBER — Verifies uniqueness of the party number assigned in the TCA party model.
  • CHECK_UNIQUE_ORIG_SYSTEM_REF — Checks the originality system reference to prevent conflicting source-system identifiers.
  • DELETE_CUSTOMER_ALT_NAMES — Removes alternate customer name records associated with a customer account.
  • GET_STATEMENT_SITE — Returns the site used for statement generation for a given customer account or site use.
  • GET_DUNNING_SITE — Resolves the dunning site applicable to a customer for collections correspondence.
  • GET_CURRENT_DUNNING_TYPE — Determines the currently effective dunning type or letter set assigned to a customer.
  • ARXVAMAI_OVERALL_CR_LIMIT — Retrieves the overall credit limit value used in credit management evaluation.
  • ARXVAMAI_ORDER_CR_LIMIT — Retrieves the order-level credit limit used during order or transaction credit checking.
  • GET_PRIMARY_BILLTO_SITE — Identifies and returns the primary bill-to site for a customer account, a common requirement for invoicing and statement processing.

Tables Accessed

The package operates against several core Trading Community and Receivables tables through APPS synonyms.

  • HZ_CUST_ACCOUNTS — Primary customer account records; used for uniqueness checks and site resolution.
  • HZ_CUST_ACCT_SITES — Customer account site definitions used to determine statement, dunning, and bill-to sites.
  • HZ_CUST_SITE_USES — Site use assignments (bill-to, statement, dunning) that drive the GET_* site functions.
  • HZ_PARTIES — Party records underpinning party number uniqueness and customer identity.
  • HZ_CUSTOMER_PROFILES — Customer profile information, including dunning and statement preferences.
  • HZ_CUST_PROFILE_AMTS — Profile amount records, including credit limit values referenced by the ARXVAMAI credit limit functions.
  • AR_DUNNING_LETTER_SETS — Dunning letter set definitions used to resolve the current dunning type.
  • DUAL and PLITBLM — Utility references used for scalar evaluation and PL/SQL table operations.

Usage Notes

HZP_CUST_PKG is typically invoked from Oracle Forms-based customer maintenance screens, Receivables concurrent programs, and custom PL/SQL extensions that must enforce customer data integrity or derive default billing and collections sites. Because it is documented as an OTHER-classification package rather than a formally published API, Oracle does not guarantee signature stability across patches; implementers should wrap calls defensively and review dependencies during upgrades from 12.1.1 to 12.2.2. The dependency metadata confirms the package references no other database objects at the caller level, so consumers should confirm that the six documented referencing packages are the intended integration points.