Search Results update_job_pre




Overview
Explore in AI Chat

Overview

APPS.AHL_PRD_WORKORDER_CUHK is a PL/SQL package belonging to the Oracle E-Business Suite Product Development (AHL) application module, specifically the production/work order subsystem. The suffix "CUHK" denotes a Customer Hook package. In the Oracle EBS architecture, Customer Hook packages exist to provide a supported extension point within the standard product lifecycle, allowing customers and implementers to inject custom business logic at defined points during the execution of a base API. Such packages are not called directly by the user; instead, they are invoked from within the owning Private API (PVT) package through standard hook mechanisms. In this case, AHL_PRD_WORKORDER_CUHK acts as the customization hook for AHL_PRD_WORKORDER_PVT, which is the private API that manages production work orders (jobs) in the Oracle Enterprise Asset Management and discrete manufacturing contexts associated with the AHL schema. The hook package carries a VALID status and is classified as an OTHER API, indicating that it is an extension utility rather than a standalone public interface.

Key Procedures and Functions

The package exposes four documented hook procedures, corresponding to pre- and post-processing points across the create and update operations of the underlying work order API:

  • CREATE_JOB_PRE — Executed before the base logic of the work order creation process, allowing defaulting, validation, or derivation of attributes prior to insertion of a new work order or job record.
  • CREATE_JOB_POST — Executed after the work order creation logic completes, intended for post-insert actions such as populating dependent data, cross-referencing related entities, or triggering follow-on business logic.
  • UPDATE_JOB_PRE — Invoked before the base work order update operation, permitting validation of changes or normalization of incoming attributes before the record is modified.
  • UPDATE_JOB_POST — Invoked after an update completes, used for post-modification actions such as cascading changes, logging, or synchronization with related records.

The naming convention (PRE/POST paired with CREATE/UPDATE) confirms that this is a hook package designed to be overridden with customer-specific code, with the standard Oracle implementation containing empty or placeholder bodies.

Tables Accessed

The ETRM metadata does not enumerate specific base tables referenced through APPS synonyms. Based on the dependency graph, the package operates within the AHL production work order schema. The referenced procedures derive their context from AHL_PRD_WORKORDER_PVT and related private APIs including AHL_PRD_OPERATIONS_PVT, AHL_PP_MATERIALS_PVT, and AHL_PP_RESRC_REQUIRE_PVT. Because the hook procedures execute within the transactional scope of the calling PVT package, any table access is typically inherited from that parent process rather than direct manipulation of work order, operation, material, or resource requirement tables. This indirect access model preserves data integrity by ensuring that all DML remains governed by the owning PVT APIs.

Usage Notes

AHL_PRD_WORKORDER_CUHK is not invoked directly by forms, concurrent programs, or custom client code. It is called exclusively by AHL_PRD_WORKORDER_PVT, as confirmed by the documented dependency listing, which shows the PVT package referencing this hook. The package itself references the PVT package and standard PL/SQL packages, and is referenced back by the hook and the PVT, forming a controlled callback relationship.

Implementers customize the customer hook by replacing the empty procedure bodies with their own PL/SQL logic. Typical use cases include enforcing site-specific validation on work order creation or update, defaulting attributes not covered by standard configuration, and synchronizing external systems at defined transactional milestones. Because changes are invoked inline within the base transaction, custom logic must respect the calling transaction's commit boundaries and avoid issuing independent commits that could compromise transactional integrity. This extension pattern remains consistent across Oracle EBS 12.1.1 and 12.2.2.