Search Results validate_lookup

Overview

HZ_REGISTRY_VALIDATE_V2PUB is a public PL/SQL package body in the Oracle E-Business Suite TCA (Trading Community Architecture) registry layer, owned by APPS. It supplies the centralized validation engine used by the party, location, and contact-point public APIs (notably HZ_PARTY_V2PUB, and related registry V2 APIs) before records are committed to the HZ schema. Rather than embedding validation logic in each caller, the TCA design consolidates it here so that every creation or update path enforces the same business rules.

The package header carries the RCS identifier ARH2RGVB.pls 120.131 2011/10/03, consistent with the 12.1.1 and 12.2.2 code lines. Internally it declares private global state — a special-character constant, a cached validation table (VAL_TAB) sized at 2048 entries, and helper functions get_index, put, and search — along with private validators such as validate_rel_code, validate_hr_security, validate_global_loc_num, and validate_created_by_module. The cached lookup table is directly relevant to the user's search term validate_lookup: this package is one of the TCA entry points where lookup-coded attributes are validated against FND_LOOKUP_VALUES before a row is persisted.

Key Procedures and Functions

The documented public interface exposes 29 procedures, each validating one registry entity or attribute group:

• Party validators — VALIDATE_PARTY, VALIDATE_PERSON, VALIDATE_GROUP, and VALIDATE_ORGANIZATION validate the party record and its party-type-specific sub-records (person, group, organization) supplied through the V2 public API record structures.
• Site and location validators — VALIDATE_PARTY_SITE, VALIDATE_PARTY_SITE_USE, and VALIDATE_LOCATION validate party-site and location data, including business rules around site usage and location references.
• Contact and relationship validators — VALIDATE_ORG_CONTACT, VALIDATE_ORG_CONTACT_ROLE, VALIDATE_RELATIONSHIP, and VALIDATE_RELATIONSHIP_TYPE validate organizational contacts, their roles, and party-to-party relationships, including forward/backward relationship codes and roles through validate_rel_code.
• Contact point validators — VALIDATE_CONTACT_POINT, VALIDATE_EDI_CONTACT_POINT, VALIDATE_EFT_CONTACT_POINT, VALIDATE_WEB_CONTACT_POINT, VALIDATE_PHONE_CONTACT_POINT, VALIDATE_TELEX_CONTACT_POINT, and VALIDATE_EMAIL_CONTACT_POINT apply medium-specific rules (format, uniqueness, and required attributes) for each contact-point type.
• Supplementary validators — VALIDATE_PERSON_LANGUAGE and VALIDATE_ORG_NONSUPPORT_COLUMN cover person language assignments and non-supported organization columns.

All public validators return a standard x_return_status outcome (success, expected error, or unexpected error), allowing callers to abort the transaction before partial data is written.

Tables Accessed

The package validates primarily through read access to reference and registry tables via APPS synonyms:

• FND_LOOKUP_VALUES — the definitive source for lookup-code validation; this is the table evaluated when callers invoke the lookup-validation path (the validate_lookup concern).
• FND_CURRENCIES, FND_LANGUAGES, FND_TERRITORIES — validate currency codes, language codes, and territory/address references.
• FND_OBJECTS, FND_OBJECT_INSTANCE_SETS — support object-level and instance-set security checks, referenced by validate_hr_security and validate_created_by_module.
• HZ_CONTACT_POINTS — contact-point validation and uniqueness checking.
• HZ_CITIZENSHIP, HZ_EDUCATION, HZ_EMPLOYMENT_HISTORY, HZ_FINANCIAL_NUMBERS, HZ_FINANCIAL_REPORTS, HZ_CREDIT_RATINGS — validate person and organization profile data used during party updates.
• HZ_LOCATIONS, HZ_CODE_ASSIGNMENTS — location validation and code-assignment checks, including global location numbers.

Usage Notes

HZ_REGISTRY_VALIDATE_V2PUB is not typically called directly by end users. It is invoked internally by the TCA V2 public APIs — HZ_PARTY_V2PUB, HZ_LOCATION_V2PUB, HZ_CONTACT_POINT_V2PUB, and their siblings — and is referenced by 12 other packages in the registry layer. Standard behavior is that a caller populates a record type and calls the corresponding create/update API, which in turn calls the matching VALIDATE_* procedure here before performing DML.

Because the package is classified as PUB, custom code may call it for pre-validation, but doing so is generally unnecessary: the supported pattern is to call the parent V2 API and inspect x_return_status and the message list. In Oracle Forms, the Customer and Supplier entry forms reach this logic indirectly through the underlying APIs. Concurrent programs and interfaces that load parties or locations (for example supplier or customer import) rely on the same validators, so changes to lookup values in FND_LOOKUP_VALUES or reference data in FND_CURRENCIES, FND_LANGUAGES, and FND_TERRITORIES can alter validation outcomes without any code change. This behavior is a common cause of failures during data migration and should be accounted for when diagnosing rejected records.