Search Results time_existing_fs




Overview

MRP_LINE_SCHEDULE_ALGORITHM is an internal Oracle Applications package that implements the production line scheduling engine used by Oracle Master Scheduling/MRP and Oracle Work in Process. Its role is to take unfirm and firm demand — sales orders, planned orders, and purchase order demand — and translate it into timed, capacity-feasible flow schedules, repetitive schedules, and discrete jobs on a production line. The package embodies the line scheduling algorithm that determines how demand is sequenced, leveled, rounded, and placed against the line calendar, honoring build sequence rules, order modifier restrictions, and capacity constraints for each date.

The package is declared AUTHID CURRENT_USER, so it executes with the privileges of the calling schema. The header shown above was last modified in 2003 (MRPLSCHS.pls 115.48), and the same body is shipped in both 12.1.1 and 12.2.2, meaning its behavior is consistent across those releases and it is not one of the objects materially reworked by the Online Patching or multi-org changes introduced in 12.2.2.

The package defines several PL/SQL collection types — CapTabTyp, TimeTabTyp, BuildSeqTabTyp, OrderModTabTyp — that hold net capacity by date, the latest schedule completion time within a day, the highest build sequence per schedule group, and per-item order modifier minimums and maximums. These reflect the in-memory working structures of the scheduling algorithm.

Key Procedures and Functions

Nineteen documented procedures and functions make up the package's public surface:

Tables Accessed

The package reads and writes through APPS synonyms. Principal transactional and setup tables include:

Usage Notes

MRP_LINE_SCHEDULE_ALGORITHM is not an end-user API; it is invoked indirectly. It is called from the scheduling forms in Oracle Master Scheduling/MRP and from concurrent programs that perform line scheduling and flow schedule generation. It is referenced by six other packages, confirming it functions as a shared engine consumed by higher-level scheduling and planning logic. Custom code should avoid calling it directly, since its interface is internal and unversioned; any integration should go through a supported API or concurrent program instead. When debugging scheduling behavior, DBMS_OUTPUT and a call to CREATE_CURSOR can be used in a development instance to inspect the demand set being scheduled.