Search Results industrial_reference

Overview

HZ_ORG_INFO_VALIDATE is a validation package body in the Oracle E-Business Suite Trading Community / Receivables (AR) architecture. It resides in the APPS schema and is classified under the "OTHER" API category. Its central business function is to enforce data-integrity rules on the "organization information" child entities that hang off a party record in the TCA (Trading Community Architecture) model. These entities include stock market listings, security issuance details, financial reports, financial numbers, certifications, and industrial reference/classification data.

The package is a server-side helper companion to HZ_ORG_INFO_PUB. The public package exposes the create/update APIs, while this private validator performs the column-level and lookup-level checks before the data is persisted. Each procedure applies the ETRM standard error contract: it signals missing or invalid columns through the FND_MESSAGE / FND_MSG_PUB stack and returns a status through x_return_status, using FND_API.G_RET_STS_ERROR and the G_MISS_CHAR / G_MISS_NUM sentinel values that denote "attribute not supplied" in TCA APIs.

Key Procedures and Functions

Eight procedures are documented in the ETRM 12.2.2 metadata:

• VALIDATE_STOCK_MARKETS — Validates a stock markets record. As shown in the source excerpt, foreign-key validation is intentionally omitted, and the stock_exchange_code lookup check against AR_LOOKUPS (lookup_type 'STOCK_SYMBOL') is commented out because the lookup had not yet been created; the procedure currently reduces to a NULL placeholder.
• VALIDATE_SECURITY_ISSUED — Validates the security-issued record. It enforces required columns (for example stock_exchange_id on create) and non-updateable columns, returning an error when constraints are violated.
• VALIDATE_FINANCIAL_REPORTS — Validates financial report records belonging to an organization party.
• VALIDATE_FINANCIAL_NUMBERS — Validates financial number (financial metric) records, including currency and numeric range checks.
• VALIDATE_CERTIFICATIONS — Validates certification records such as certification type, issuing authority, and validity dates.
• VALIDATE_INDUSTRIAL_REFERENCE — Validates industrial reference records, verifying reference codes against the industrial reference/class hierarchy. This is the procedure most directly associated with a search for "industrial_reference".
• VALIDATE_INDUSTRIAL_CLASSES — Validates industrial classification definitions maintained in the classification table.
• VALIDATE_INDUSTRIAL_CLASS_APP — Validates the application (assignment) of industrial classes to a party or organization.

Tables Accessed

Based on the documented table list, the package reads and validates against the following APPS synonyms:

• HZ_STOCK_MARKETS, HZ_SECURITY_ISSUED — stock exchange and security issuance data for the party.
• HZ_FINANCIAL_REPORTS, HZ_FINANCIAL_NUMBERS — financial reporting and financial metric records.
• HZ_CERTIFICATIONS — certification records for the organization.
• HZ_INDUSTRIAL_REFERENCE, HZ_INDUSTRIAL_CLASSES, HZ_INDUSTRIAL_CLASS_APP — industrial reference codes, classification definitions, and class assignments.
• HZ_PARTIES — the parent party record to which all child entities belong.
• FND_CURRENCIES — currency validation for financial numbers and related records.

Lookups such as AR_LOOKUPS are referenced conceptually for stock symbol validation, but the check is disabled in the shipped source.

Usage Notes

HZ_ORG_INFO_VALIDATE is not intended for direct invocation by end users. It is called internally by the HZ_ORG_INFO_PUB public API layer whenever organization information is created or updated. In a standard Oracle EBS 12.1.1 / 12.2.2 deployment, that API layer is triggered from the Trading Community party/organization maintenance forms, from concurrent programs that import or update organization data, and from custom PL/SQL or interface programs that call HZ_ORG_INFO_PUB. Because the procedures accept a create/update flag and an in-out return status, callers should invoke them only within the context of a broader API transaction and should inspect x_return_status plus the FND message stack before committing. The metadata notes that this package is referenced by one other package, consistent with its role as a dependent validator. Behavior is identical across 12.1.1 and 12.2.2, as the underlying TCA schema is shared.