Search Results update_cust_reg_item

Overview

AK_CUSTOM_GRP is a PL/SQL package body owned by the APPS schema that forms part of the Oracle E-Business Suite Application Framework (AK) component, commonly referred to as the Oracle Application Object Library customization infrastructure. Its primary business function is to provide the group-level API for managing custom regions and their associated customization definitions within Oracle EBS 12.1.1 and 12.2.2. The package encapsulates the logic required to create, maintain, and deploy custom region definitions that extend or override standard application functionality without modifying seeded Oracle code. The single documented entry point surfaced by the search term "create_custom" is the CREATE_CUSTOM procedure, which the header comments describe as a "Group API for creating a region." The documented API classification is GRP, indicating this is a group-level (business-entity) API that wraps one or more underlying private APIs rather than exposing base-table data manipulation directly.

Key Procedures and Functions

The ETRM metadata documents nine procedures within the AK_CUSTOM_GRP package body, organized into create and update operations:

• CREATE_CUSTOM — The principal group API for creating a custom region. It invokes a private API to persist the region using the supplied information and returns the standard p_return_status indicating Success, Error, or Unexpected error, along with the standard message count and message data out parameters.
• CREATE_CUST_REGION — Creates the custom region record that scopes a customization to a particular region.
• CREATE_CUST_REG_ITEM — Creates individual region items belonging to a custom region.
• CREATE_CRITERIA — Creates the criteria that determine when and where a given customization applies.
• DOWNLOAD_CUSTOM — Retrieves or exports an existing customization definition, supporting the transfer of customizations between environments.
• UPDATE_CUSTOM — Modifies an existing custom definition.
• UPDATE_CUST_REGION — Modifies an existing custom region record.
• UPDATE_CUST_REG_ITEM — Modifies an existing custom region item.
• UPDATE_CRITERIA — Modifies existing customization criteria.

Each create and update routine follows the Oracle EBS API conventions: a validation level defaulting to FND_API.G_VALID_LEVEL_FULL, an API version number, an initialization flag for the message table, and the standard output parameters for message count, message data, and return status.

Tables Accessed

The documented table references for this package are limited and indirect. The package references DUAL, the standard Oracle single-row utility table typically used to evaluate expressions or supply constants within PL/SQL, and PLITBLM, an internal Application Object Library table used to store messages associated with the FND_MSG_PUB message stack. Because AK_CUSTOM_GRP is a group API, it does not manipulate the underlying AK customization base tables directly; instead it delegates physical persistence to private APIs that own the insert, update, and delete operations. Consequently, the documented table list reflects only the direct references visible in the package body, not the full set of tables written on its behalf through the private API layer.

Usage Notes

AK_CUSTOM_GRP is typically invoked indirectly rather than through direct end-user action. It is called by the Oracle EBS customization user interface — most notably the Forms-based "Customize" and personalization administration screens — and by concurrent programs or internal Application Framework logic that create, update, or download custom region definitions. The metadata indicates the package is referenced by one other package, consistent with a layered design in which a higher-level orchestration unit calls this group API. Custom code integrating with the AK customization framework can call CREATE_CUSTOM directly, provided it honors the standard FND_API contract: initialize the message table when p_init_msg_tbl is TRUE, inspect p_msg_count and p_msg_data to retrieve errors, and always evaluate p_return_status before proceeding. Because calls transpire within the APPS schema, callers should execute with the appropriate application context and, where relevant, supply the correct p_org_id and responsibility context so that region-level criteria resolve correctly.