Search Results backflush_flag

Overview

APPS.PJM_PROJECT_WIP_OP_V is a Project Manufacturing (PJM) reporting view that exposes Work in Process (WIP) job operation information for the Oracle E-Business Suite Web Inquiry interface. Registered in the APPS schema with a status of VALID, the view is a thin, opinionated projection over the standard WIP_OPERATIONS_V view, layered with formatting and decode logic supplied by the PJM_INQUIRY package. Its principal purpose is to present shop-floor operation status — scheduled quantities, in-queue, running, rejected, scrapped, and completed quantities, along with operation sequencing and department/location attributes — in a form consumable by the project manufacturing web inquiry pages.

Because the object is a view rather than a table, it holds no persistent data. It is therefore appropriate for read-only reporting, self-service inquiry, and integration extracts, but never for direct DML. In Oracle EBS 12.1.1 and 12.2.2 the view remains structurally consistent; the primary difference between releases lies in tablespace and editioning considerations for the APPS schema, not in the column set or view text.

Underlying Base Objects

The documented referenced base objects are:

• WIP_OPERATIONS_V (VIEW) — the source of all operational rows and quantity columns. This is the standard WIP operations view, which itself resolves against WIP operation and job tables in the WIP schema.
• PJM_INQUIRY (PACKAGE) — supplies the SYS_YES_NO function used to translate the stored Y/N flags into display-friendly values.

The view's SELECT list is a direct column projection from WIP_OPERATIONS_V, with three notable transformations: QUANTITY_IN_QUEUE, QUANTITY_RUNNING, QUANTITY_WAITING_TO_MOVE, QUANTITY_REJECTED, QUANTITY_SCRAPPED, and QUANTITY_COMPLETED are wrapped in TO_NUMBER to enforce numeric typing; and COUNT_POINT_FLAG, AUTOCHARGE_FLAG, and BACKFLUSH_FLAG are passed through PJM_INQUIRY.SYS_YES_NO. No joins, filters, or WHERE clauses are documented, so the view inherits the full row set of its parent view.

Key Columns

• WIP_ENTITY_ID / ORGANIZATION_ID — identifies the discrete job and the manufacturing organization.
• OPERATION_SEQ_NUM / OPERATION_SEQUENCE_ID — the routing step and its surrogate key; PREVIOUS_OPERATION_SEQ_NUM and NEXT_OPERATION_SEQ_NUM provide navigation across the routing.
• QUANTITY_SCRAPPED — the quantity of assemblies scrapped at the operation. Because the user searched for this term specifically, it is the principal analytical measure exposed for yield and loss analysis.
• QUANTITY_IN_QUEUE, QUANTITY_RUNNING, QUANTITY_WAITING_TO_MOVE, QUANTITY_REJECTED, QUANTITY_COMPLETED — the remaining shop-floor quantity buckets, all returned as numbers.
• SCHEDULED_QUANTITY — the planned quantity for the operation.
• DEPARTMENT_CODE / DEPARTMENT_ID, LOCATION_ID, OPERATION_CODE, DESCRIPTION — descriptive attributes for the operation and its performing department.
• COUNT_POINT_FLAG, AUTOCHARGE_FLAG, BACKFLUSH_FLAG — Yes/No indicators rendered via PJM_INQUIRY.SYS_YES_NO.
• FIRST_UNIT_ / LAST_UNIT_ START_DATE and COMPLETION_DATE, DATE_LAST_MOVED — timing attributes for cycle-time reporting.

Common Use Cases and Queries

Typical uses include scrap and yield reporting by operation, work-in-process status dashboards for project-manufactured jobs, and routing-level throughput analysis. The following query lists operations with scrapped quantities for a given job:

• SELECT wip_entity_id, operation_seq_num, operation_code, department_code, scheduled_quantity, quantity_scrapped, quantity_completed FROM apps.pjm_project_wip_op_v WHERE wip_entity_id = :job_id AND quantity_scrapped > 0 ORDER BY operation_seq_num;
• SELECT organization_id, SUM(quantity_scrapped) total_scrap FROM apps.pjm_project_wip_op_v GROUP BY organization_id;
• SELECT operation_seq_num, quantity_in_queue, quantity_running, quantity_waiting_to_move, quantity_rejected, quantity_completed FROM apps.pjm_project_wip_op_v WHERE wip_entity_id = :job_id ORDER BY operation_seq_num;

Because the view carries no filter predicates, callers should always constrain by ORGANIZATION_ID or WIP_ENTITY_ID to avoid full scans of the underlying WIP data set.