Search Results ego_user_attr_change_table




Overview
Explore in AI Chat

Overview

HZ_EXTENSIBILITY_PUB is the public PL/SQL API package within the Oracle Trading Community Architecture (TCA) that manages extensible, custom attributes for the core TCA entities. The package is owned by APPS and was delivered as part of the Oracle E-Business Suite codebase common to releases 12.1.1 and 12.2.2. Its role is to provide a supported programmatic interface for creating and updating extension records that supplement the standard descriptive columns of TCA tables, thereby allowing implementers to store customer-specific data without modifying Oracle's base schema.

The package is declared AUTHID CURRENT_USER, meaning that it executes with the privileges of the calling schema rather than those of its owner. The source file is ARHEXTSS.pls, and the header comment identifies the API scope as public and the product as HZ. The @rep annotations list four business entities covered by the package: HZ_ORGANIZATION, HZ_PERSON, HZ_ADDRESS, and HZ_PARTY. The inclusion of HZ_ADDRESS is directly relevant to searches for "hz_address," since location and party-site extension records are maintained through this same API surface.

Key Procedures and Functions

The ETRM metadata documents five callable units within the package. Each addresses one of the extension areas supported by TCA.

  • PROCESS_ORGANIZATION_RECORD — Creates or updates extension information for organization profiles. According to the embedded documentation, the HZ_ORG_PROFILES_EXT_B and HZ_ORG_PROFILES_EXT_TL tables hold extended, custom attributes about organizations, and this procedure maintains records in those tables for a given organization. It accepts an organization profile identifier consistent with the TCA party model.
  • PROCESS_PERSON_RECORD — Performs the equivalent create-or-update operation for person profile extensions, writing to the person-level extension tables.
  • PROCESS_LOCATION_RECORD — Maintains extension records associated with locations, which in TCA terms relates to the address and location entities annotated as HZ_ADDRESS.
  • PROCESS_PARTYSITE_RECORD — Maintains extension records at the party-site level, covering the intersection of a party and a location (an address usage).
  • GET_USER_ATTRS_FOR_ITEM — A retrieval function that returns the user-defined attribute definitions applicable to a given extensibility item, supporting dynamic attribute discovery.

Each processing procedure follows the standard ETRM conventions reflected in the package constants: an API version parameter, IN/OUT identifiers, validation level and application context arguments, and the standard return-status values G_RET_STS_SUCCESS, G_RET_STS_ERROR, and G_RET_STS_UNEXP_ERROR drawn from FND_API. The package also uses the conventional missing-value constants G_MISS_NUM, G_MISS_CHAR, and G_MISS_DATE, and the standard boolean constants G_TRUE and G_FALSE.

Tables Accessed

The documented extension tables are HZ_ORG_PROFILES_EXT_B (the base table holding extended organization attributes) and HZ_ORG_PROFILES_EXT_TL (its translation table, storing language-dependent descriptive values). The package's DML against these tables is performed through APPS synonyms, consistent with the TCA schema layout. The remaining processing procedures follow the same architectural pattern against their corresponding extension tables for persons, locations, and party sites, and GET_USER_ATTRS_FOR_ITEM reads attribute registration metadata to resolve which user-defined columns are in scope for the requested item.

Usage Notes

HZ_EXTENSIBILITY_PUB is typically invoked from TCA-based forms, from concurrent programs that mass-maintain extension data, and from custom PL/SQL code that must preserve Oracle's supported upgrade path. Because the extension tables are structured as describer-flexfield implementations, direct INSERT and UPDATE statements are discouraged; callers should route maintenance through this package. The ETRM metadata records that the package is referenced by one other package, confirming its role as an internal building block of higher-level TCA APIs rather than an end-user entry point. Callers should check the return status after every invocation and honor API version and validation-level arguments.