Search Results process_organization_record




Overview
Explore in AI Chat

Overview

HZ_EXTENSIBILITY_PUB is a public PL/SQL package in the Oracle E-Business Suite Receivables/Human Resources shared schema (APPS) that exposes the extensibility framework for the Trading Community Architecture (TCA) party model. Its principal business purpose is to allow callers to persist and manage user-defined attribute values — the configurable "descriptive flexfield"-style columns that customers add to standard TCA entities — against organization profiles, person profiles, locations, and party sites. Rather than forcing each caller to work directly with the underlying private worker package, HZ_EXTENSIBILITY_PUB provides a stable, published interface isolated from the internal implementation.

The package body header identifies the source file as ARHEXTSB.pls and carries a $Header revision tag, confirming it is a shipped, Oracle-maintained artifact rather than a customer extension. Global constants G_FILE_NAME and G_PKG_NAME are declared, and session context is captured at package initialization through FND_GLOBAL.User_Id and FND_GLOBAL.Conc_Login_Id, ensuring that audit columns and concurrent-program logging throughout the package reflect the correct runtime user and request.

Key Procedures and Functions

  • PROCESS_ORGANIZATION_RECORD — Persists user-defined attribute rows and data for an organization profile, identified by an organization profile identifier and an owner table of HZ_ORGANIZATION_PROFILES. It accepts attribute row/data collections together with optional change-tracking information, delegating the actual work to HZ_EXTENSIBILITY_PVT.Process_User_Attrs_For_Item. The body shows the delegation pattern explicitly, with a placeholder comment noting that ID validation is intended before the private API is called.
  • PROCESS_PERSON_RECORD — The person-level counterpart to PROCESS_ORGANIZATION_RECORD, applying the same attribute-processing contract to person profiles. This is the procedure most frequently referenced by callers populating person DFF/extension attributes.
  • PROCESS_LOCATION_RECORD — Persists extensibility attributes for an address/location record, allowing location-level user attributes to be maintained independently of the party that occupies the location.
  • PROCESS_PARTYSITE_RECORD — Maintains user attributes at the party-site level, the intersection of a party and a location, which is the granularity at which many Receivables and order-management attributes are stored.
  • GET_USER_ATTRS_FOR_ITEM — A retrieval routine that returns the user attribute definitions (and associated values) applicable to a given item or entity, enabling callers to render or validate attribute values without querying the underlying attribute metadata tables directly.

Tables Accessed

The documented metadata identifies no direct table references via APPS synonyms. This is consistent with the delegation design: the public package hands attribute collections (typed as EGO_USER_ATTR_ROW_TABLE, EGO_USER_ATTR_DATA_TABLE, and EGO_USER_ATTR_CHANGE_TABLE) to HZ_EXTENSIBILITY_PVT, which performs the physical inserts, updates, and deletes. Logically, records are written against the HZ_ORGANIZATION_PROFILES owner table named in the delegation call, with attribute metadata and values managed through the EGO user-attribute framework. Because no tables are directly bound, the package is insulated from schema changes in the attribute storage model.

Usage Notes

HZ_EXTENSIBILITY_PUB is a low-level API typically invoked from TCA maintenance screens, concurrent programs that bulk-load party data, and custom PL/SQL integrations that need to set extension attributes during party creation or update. It is referenced by one other package, indicating it is not an entry point called directly by end users but rather a component within a larger API stack. Callers should invoke the process procedures after the base entity (organization profile, person profile, location, or party site) has been created, since attribute values are keyed to an existing owner record. The presence of parameters controlling debug level, error-handler initialization, concurrent-log writing, FND message list initialization, and commit behavior in the delegation signature means callers must decide explicitly whether the API commits or leaves transaction control to the caller; standard practice in EBS is to pass commit as false and commit in the calling program. All calls should be wrapped in standard FND_API error handling, checking x_return_status and the message stack on completion.