Search Results sched_comp_date

Overview

APPS.WIP_BIS_LATE_PROD_COMP_V is a Business Intelligence System (BIS) view in Oracle E-Business Suite, registered under the WIP (Work in Process) product with FND Design Data identifier WIP.WIP_BIS_LATE_PROD_COMP_V. Its status is VALID in both Oracle EBS 12.1.1 and 12.2.2. The view is classified as a web view, a design pattern intended to simplify access from Oracle Self-Service Web Applications by pre-joining and denormalizing data that would otherwise require multiple table lookups.

The view isolates manufacturing exceptions: it returns all discrete jobs and repetitive schedules that were completed after their scheduled completion date. For a discrete job, the actual completion date is compared against the scheduled completion date on the job. For a repetitive schedule, the closing date is compared against the scheduled last-unit completion date on the schedule. Because this view is a late-production exception report rather than a transactional entity, it is not referenced by any other database object; it serves strictly as a reporting and integration surface.

Underlying Base Objects

The view is defined over six referenced objects:

• WIP_DISCRETE_JOBS — supplies scheduled and actual completion dates for discrete jobs.
• WIP_REPETITIVE_SCHEDULES — supplies scheduled last-unit completion and closing dates for repetitive schedules.
• WIP_ENTITIES — provides the WIP entity name and organization context shared by both job types.
• WIP_REPETITIVE_ITEMS — links repetitive schedules to their assembled items.
• WIP_LINES — supplies the production line for repetitive schedules.
• MTL_ITEM_FLEXFIELDS — resolves item number and description, including flexfield segments, for the assembled item.

Most base objects are accessed through APPS synonyms (WIP_DISCRETE_JOBS, WIP_ENTITIES, WIP_LINES, WIP_REPETITIVE_ITEMS, WIP_REPETITIVE_SCHEDULES), while MTL_ITEM_FLEXFIELDS is referenced directly as a view. The join across these objects unifies discrete and repetitive manufacturing into a single late-completion result set.

Key Columns

• ORGANIZATION_ID (NUMBER) — organization identifier, the primary partitioning key for multi-org reporting.
• ITEM_NUMBER (VARCHAR2 40) — the assembled item number.
• ITEM_UOM (VARCHAR2) — unit of measure of the item.
• ITEM_DESCRIPTION (VARCHAR2 240) — item description.
• LINE (VARCHAR2 10) — production line, applicable to repetitive schedules.
• WIP_ENTITY_NAME (VARCHAR2 240) — identifier of the job or schedule.
• SCHED_COMP_DATE (DATE) — scheduled completion date; for repetitive schedules this is the scheduled last-unit completion date.
• ACTUAL_COMP_DATE (DATE) — actual completion date for a job or closing date for a schedule. This is the column most commonly targeted in searches, since it is the basis of the lateness calculation that defines the view's content.

Common Use Cases and Queries

The principal use case is manufacturing exception reporting: identifying jobs and schedules that missed their committed completion dates, measuring the magnitude of the delay, and feeding downstream metrics such as on-time delivery or schedule adherence. Because ACTUAL_COMP_DATE and SCHED_COMP_DATE are both exposed, delay duration can be computed directly in SQL.

A basic retrieval follows the documented query text:

• SELECT WIP_ENTITY_NAME, ITEM_NUMBER, SCHED_COMP_DATE, ACTUAL_COMP_DATE FROM APPS.WIP_BIS_LATE_PROD_COMP_V;
• To scope to a single organization and rank the worst offenders: SELECT WIP_ENTITY_NAME, ITEM_NUMBER, ACTUAL_COMP_DATE - SCHED_COMP_DATE AS DAYS_LATE FROM APPS.WIP_BIS_LATE_PROD_COMP_V WHERE ORGANIZATION_ID = :org_id ORDER BY DAYS_LATE DESC;
• To isolate a trailing period of late completions: SELECT * FROM APPS.WIP_BIS_LATE_PROD_COMP_V WHERE ACTUAL_COMP_DATE BETWEEN :from_date AND :to_date;
• To separate repetitive from discrete output, filter on LINE IS NOT NULL for repetitive schedules and LINE IS NULL for discrete jobs.

Typical consumers include custom reports, Oracle Discoverer or BI Publisher workbooks, and interface extracts where late-completion data must be moved to an external planning or quality system. Reporting should always filter by ORGANIZATION_ID, as the view spans organizations, and DBAs should note that the view performs no filtering of its own beyond the lateness predicate, so date-bounded queries benefit from indexing on the underlying WIP tables.