Search Results check_if_primary_category

Overview

OTA_ACI_BUS is the business-layer PL/SQL package for the Activity Category Inclusion (ACI) entity within the Oracle E-Business Suite Training Administration (OTA) module. It is owned by the APPS schema and declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer. The package encapsulates the row-level business logic required to maintain relationships between activity versions and category usages, which together determine how training activities are grouped and classified within the enterprise catalog. Its responsibilities span validation of primary keys and uniqueness constraints, enforcement of date-range integrity, management of the primary category designation, and the derivation of security group and legislation context used by Oracle's multi-tenant (business group) and legislative architecture. The package is classified as OTHER in the ETRM schema and is designated for internal development use, indicating it is not intended as a public integration API but rather as the substrate upon which the ACI forms and higher-level APIs are built.

Key Procedures and Functions

Eleven documented entry points are exposed, each addressing a specific business rule for the ACI entity:

• SET_SECURITY_GROUP_ID — populates the security_group_id in CLIENT_INFO based on the activity version and category usage primary key, establishing the business group context for subsequent operations.
• RETURN_LEGISLATION_CODE — retrieves the legislation code associated with the business group for a given primary key, supporting legislative localization requirements.
• INSERT_VALIDATE — performs pre-insert business validation for new ACI rows.
• UPDATE_VALIDATE — validates changes to existing ACI rows prior to update.
• DELETE_VALIDATE — enforces deletion rules, preventing removal where referential or business constraints apply.
• CHECK_IF_PRIMARY_CATEGORY — determines whether a specified category usage is flagged as the primary category.
• CHECK_MULTIPLE_PRIMARY_CTGR — ensures that only one primary category is permitted per activity version, guarding against conflicting designations.
• CHECK_START_END_DATES — verifies that start and end dates are logically ordered and valid on insert.
• CHECK_UNIQUE_KEY — the procedure directly relevant to the user's search; it validates that the combination of activity version and category usage does not already exist, preventing duplicate ACI records.
• CHECK_DATES_UPDATE and CHECK_DATES_UPDATE_ACT — validate date integrity during updates, including checks propagated to the parent activity.

Tables Accessed

The package operates against three core tables via APPS synonyms. OTA_ACTIVITY_VERSIONS stores the versioned definition of each training activity and supplies the security group and legislation context. OTA_CATEGORY_USAGES holds the category-to-usage assignments that define catalog classification. OTA_ACT_CAT_INCLUSIONS is the intersection table that records which category usages are included for a given activity version; it is the principal table on which the validation procedures operate. CHECK_UNIQUE_KEY verifies that no duplicate pairing exists in this intersection table, while CHECK_IF_PRIMARY_CATEGORY and CHECK_MULTIPLE_PRIMARY_CTGR enforce the single-primary-category rule across the same structure.

Usage Notes

OTA_ACI_BUS is not intended for direct invocation by end users or external systems. It is called internally by the ACI maintenance forms (such as the Activity Category Inclusion form in the Training Administration responsibility) during insert, update, and delete processing, and by the higher-level OTA_ACI_API public API that wraps these validations. Four other documented packages reference it, reflecting its role as a shared business-layer component. Custom code should invoke the public API rather than calling OTA_ACI_BUS procedures directly, since the package is marked "Internal Development Use Only" and its specification may change between releases. Its date and uniqueness checks are especially relevant when bulk-loading ACI data via concurrent programs, where violations will surface as raised errors rather than silent rejections.