Results for “mrp_wip_schedule_type”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPS.PJM_LINE_SCHEDULES_V is a Project Manufacturing reporting view that consolidates production scheduling information from two distinct Work in Process (WIP) execution models: discrete jobs and flow schedules. In Oracle EBS 12.1.1 and 12.2.2, this view serves as a single reporting surface for project- and task-linked manufacturing activity, allowing users to retrieve scheduled, completed, and closed production records that carry a PROJECT_ID and TASK_ID association. Because it is defined as a UNION ALL of two SELECT statements, the view returns discrete job rows and flow schedule rows in one result set, normalizing their differing column names into a common projection.

The view is especially relevant to Oracle Projects, Project Manufacturing, and cost collection reporting, where manufacturing transactions must be attributed to a project and task for burdening and capitalization. It also provides a convenient join point for item, entity, and line-code descriptions, sparing report authors from repeated lookups.

Underlying Base Objects

The documented base objects are MFG_LOOKUPS (VIEW), MTL_SYSTEM_ITEMS_KFV (SYNONYM), WIP_DISCRETE_JOBS (SYNONYM), WIP_ENTITIES (SYNONYM), WIP_FLOW_SCHEDULES (SYNONYM), and WIP_LINES (SYNONYM). The first UNION ALL branch joins WIP_DISCRETE_JOBS to WIP_ENTITIES (to obtain WIP_ENTITY_NAME), MTL_SYSTEM_ITEMS_KFV (for concatenated item segments), and WIP_LINES (for LINE_CODE). The second branch performs an analogous join over WIP_FLOW_SCHEDULES, but uses SCHEDULE_NUMBER in place of a WIP entity name and PROJECT_ID filtering rather than a JOB.STATUS_TYPE lookup.

Both branches join MFG_LOOKUPS aliased as WST on the lookup type MRP_WIP_SCHEDULE_TYPE. The discrete branch restricts that lookup to LOOKUP_CODE = 1, while the flow branch uses LOOKUP_CODE = 2. The first branch additionally joins MFG_LOOKUPS aliased as WJS on lookup type WIP_JOB_STATUS to resolve the job status code into a status code and meaning. This is the origin of the user's search term mrp_wip_schedule_type: it is the lookup type that distinguishes the two schedule models surfaced by this view.

Key Columns

• PROJECT_ID / TASK_ID — The project and task to which the manufacturing record is charged; both branches require PROJECT_ID IS NOT NULL.
• LINE_ID / LINE_CODE — The production line and its descriptive code, sourced from WIP_LINES.
• LOOKUP_CODE / MEANING — Derived from MRP_WIP_SCHEDULE_TYPE (1 = discrete job, 2 = flow schedule), identifying which scheduling model the row represents.
• WIP_ENTITY_NAME — The discrete job name from WIP_ENTITIES (null for flow schedule rows).
• ORGANIZATION_ID / PRIMARY_ITEM_ID / CONCATENATED_SEGMENTS — Owning inventory organization, primary item identifier, and the flexfield-concatenated item number.
• END_ITEM_UNIT_NUMBER — Unit number of the end assembly.
• SCHEDULED_START_DATE / SCHEDULED_COMPLETION_DATE / DATE_CLOSED — Planning and completion dates.
• START_QUANTITY / PLANNED_QUANTITY / QUANTITY_COMPLETED — Quantities; the discrete branch exposes START_QUANTITY while the flow branch exposes PLANNED_QUANTITY, both projected into the same column position.

Common Use Cases and Queries

Typical uses include project manufacturing work-in-process reporting, reconciling scheduled versus completed quantities by project and task, and feeding project cost or capital reporting extracts. Because the view already resolves status meanings and item segments, it is a convenient source for ad hoc project inquiries.

A representative query filters the schedule type and joins item and entity details:

SELECT PROJECT_ID, TASK_ID, WIP_ENTITY_NAME, LINE_CODE, MEANING,
       CONCATENATED_SEGMENTS, SCHEDULED_START_DATE,
       SCHEDULED_COMPLETION_DATE, QUANTITY_COMPLETED
FROM   APPS.PJM_LINE_SCHEDULES_V
WHERE  LOOKUP_CODE = '1'
AND    ORGANIZATION_ID = :org_id
ORDER BY SCHEDULED_START_DATE;

Replacing the LOOKUP_CODE with '2' returns flow schedule rows using PLANNED_QUANTITY. Filtering on a specific PROJECT_ID and TASK_ID supports project-level reconciliation, while DATE_CLOSED may be used to separate open from closed production records.