Search Results validate_cust_acct_relate




Overview
Explore in AI Chat

Overview

HZ_ACCOUNT_VALIDATE_V2PUB is a public PL/SQL package in the APPS schema that provides the centralized validation layer for the Oracle E-Business Suite Trading Community Architecture (TCA) customer model. Its business function is to verify that the data supplied to the various HZ_*_V2PUB public APIs is complete, internally consistent, and acceptable before those APIs commit records to the TCA registry. Rather than duplicating validation logic inside each API, TCA routes validation through this single package, which enforces the same business rules whether a customer account, account site, site use, account role, or customer profile is being created or updated. This design supports the user search for hz_cust_account_role_v2pub: the account role API depends on HZ_ACCOUNT_VALIDATE_V2PUB to validate the roles and responsibilities it is asked to assign, which is why the two objects appear together in dependency reports. The package is classified as a PUB API, meaning it is supported for direct invocation, although in normal business flows it is called indirectly.

Key Procedures and Functions

The package exposes eight documented procedures, each aligned to one TCA entity:

  • VALIDATE_CUST_ACCOUNT — validates the attributes of a customer account, including classification, currency, and account-level reference data.
  • VALIDATE_CUST_ACCT_RELATE — validates a proposed relationship between two customer accounts.
  • VALIDATE_CUSTOMER_PROFILE — validates customer profile information, including profile class and amount-related attributes.
  • VALIDATE_CUST_PROFILE_AMT — validates the profile amount records (credit limits, payment terms thresholds, and similar numeric profile data).
  • VALIDATE_CUST_ACCT_SITE — validates customer account site data, such as address and site-level defaults.
  • VALIDATE_CUST_SITE_USE — validates site use assignments, which determine the business purpose (bill-to, ship-to, etc.) of a site.
  • VALIDATE_CUST_ACCOUNT_ROLE — validates customer account role assignments, confirming that role types and associated responsibility references are valid before persistence. This is the procedure most directly relevant to searches on hz_cust_account_role_v2pub.
  • VALIDATE_ROLE_RESPONSIBILITY — validates the mapping between a role and its responsibility, the lowest-level check in the role validation chain.

No parameter lists are documented in the ETRM metadata; callers should obtain signatures from the package specification in the database rather than assuming them.

Tables Accessed

The package reads reference and transactional data through APPS synonyms. Key tables include HZ_CUST_ACCOUNTS and HZ_CUSTOMER_PROFILES for existing customer and profile records, and FND_LOOKUP_VALUES and FND_CURRENCIES for validating lookup-backed and currency values. Validation of receivables-related profile attributes draws on AR_SYSTEM_PARAMETERS, AR_COLLECTORS, AR_RECEIVABLES_TRX_ALL, AR_CHARGE_SCHEDULES, AR_DUNNING_LETTER_SETS, AR_STATEMENT_CYCLES, AR_STANDARD_TEXT, AR_AUTOCASH_HIERARCHIES, AR_CASH_AUTO_RULE_SETS, GL_DAILY_CONVERSION_TYPES, and FV_TP_TREASURY_SYMBOLS. These accesses are predominantly read-only lookups used to confirm that a caller-supplied value exists and is permitted for the operating unit or ledger in context.

Usage Notes

HZ_ACCOUNT_VALIDATE_V2PUB is referenced by the four principal TCA public packages — HZ_CUST_ACCOUNT_V2PUB, HZ_CUST_ACCOUNT_ROLE_V2PUB, HZ_CUST_ACCOUNT_SITE_V2PUB, and HZ_CUSTOMER_PROFILE_V2PUB — which invoke it as part of their own create and update processing. It is also referenced by itself and by HZ_CUSTOMER_PROFILE_V2PUB in the reverse direction, reflecting the shared validation chain across the TCA entity hierarchy. In practice, most invocations originate from these higher-level APIs, from the Oracle Customers and Contacts forms, and from concurrent programs and custom integrations that build customer data through TCA. Custom code should generally call the corresponding create or update API and let validation occur internally, invoking the VALIDATE procedures directly only when a pre-commit validation check is required. Because the procedures are exposed publicly, they are supported entry points, but callers must respect the published signatures and the TCA business rules enforced by the receiving entity APIs.