Search Results ahl_schedule_materials_s

Overview

The APPS.AHL_SCHEDULE_MATERIALS_PKG package body is a foundational data-maintenance component within the Oracle Enterprise Asset Management (eAM) and Maintenance Workbench product family of Oracle E-Business Suite. It encapsulates the transactional logic required to persist material scheduling records associated with maintenance work orders, activities, and resource requirements stored in the AHL schema. The package operates as a lower-level persistence layer rather than a business-facing API, and its classification in the ETRM repository is therefore recorded as OTHER. In Oracle EBS 12.1.1 and 12.2.2 the object resides in the APPS schema, reports a status of VALID, and exposes a narrow public surface consisting of three DML-oriented procedures. Its principal role is to provide a controlled, centralized entry point for inserting, updating, and deleting rows in the material scheduling table, ensuring that base-table maintenance is performed consistently and that dependent validation and message-generation logic is applied uniformly.

Key Procedures and Functions

The documented package metadata identifies three public procedures, each responsible for one class of row-level change against the underlying material scheduling entity:

• INSERT_ROW — Creates a new material scheduling record in the underlying table, allocating the surrogate primary key and populating the attributes supplied by the calling context. It establishes the association between a scheduled maintenance requirement and its corresponding material line.
• UPDATE_ROW — Modifies the mutable attributes of an existing material scheduling record identified by its primary key. This procedure is used to revise quantities, dates, status, or other descriptive fields without altering the record's identity.
• DELETE_ROW — Removes an existing material scheduling record from the underlying table, typically invoked during cleanup, cancellation, or re-planning of a maintenance activity.

All three procedures follow the standard EBS row-API convention of operating on a single row per invocation and relying on the caller to supply a fully populated record structure. No parameter lists are documented in the ETRM metadata, and none should be assumed.

Tables Accessed

The package performs its work against two documented database objects, resolved through APPS synonyms:

• AHL_SCHEDULE_MATERIALS — The primary transactional table holding material scheduling rows. This is the table directly targeted by INSERT_ROW, UPDATE_ROW, and DELETE_ROW.
• AHL_SCHEDULE_MATERIALS_S — The companion sequence (the "_S" suffix) used to generate unique primary-key values for new rows created by INSERT_ROW. The user search term "ahl_schedule_materials_s" corresponds precisely to this sequence, which is frequently queried to confirm the current high-water mark when diagnosing key collisions or sequence synchronization issues.

In addition to these tables, the package declares dependencies on FND_MESSAGE and FND_MSG_PUB, indicating that it raises user-facing errors through the standard Oracle Application Object Library message stack rather than returning raw SQLCODE values. It also depends on the SYS.STANDARD package, which is a normal PL/SQL compilation artifact.

Usage Notes

AHL_SCHEDULE_MATERIALS_PKG is not referenced by any other database object according to the ETRM dependency report, although the package itself is documented as being referenced by two other packages in the broader product configuration. This suggests it is invoked as a leaf-level helper by higher-level scheduling or maintenance APIs rather than being called directly from forms or concurrent programs. Practitioners encountering the object typically do so in one of three scenarios: while tracing the insert, update, or delete of a material scheduling row during a work-order transaction; while investigating sequence-related errors surfaced against AHL_SCHEDULE_MATERIALS_S; or while reviewing custom extensions that need to maintain AHL_SCHEDULE_MATERIALS records in a manner consistent with the standard application logic. Because the package relies on FND_MSG_PUB for error reporting, any calling code should be prepared to handle the standard EBS message-stack idiom, invoking FND_MSG_PUB.ADD and FND_MSG_PUB.GET_MSG patterns or checking whether an unhandled application error has been raised. Direct invocation from custom code is possible but should be treated cautiously, since the procedures perform row-level DML without a surrounding transactional boundary of their own.