Search Results cst_wip_entity_v




Overview
Explore in AI Chat

Overview

In Oracle E-Business Suite releases 12.1.1 and 12.2.2, CST_WIP_ENTITY_V is a seeded, single-organization view owned by the APPS schema and registered under the Bills of Material (BOM) product family. Its documented purpose in the ETRM reference is to expose "job or schedule information." The view consolidates discrete job and repetitive schedule records from the WIP module into a single, denormalized projection that reporting tools, custom concurrent programs, and integration interfaces can query without joining the underlying Work in Process and inventory tables directly.

Because it is a view and not a table, CST_WIP_ENTITY_V carries no independent storage, no indexes, and no materialized data of its own. It is a filtering and join layer: at runtime it assembles rows from WIP_ENTITIES, WIP_DISCRETE_JOBS, WIP_REPETITIVE_SCHEDULES, WIP_REPETITIVE_ITEMS, WIP_LINES, MTL_SYSTEM_ITEMS_VL, and MFG_LOOKUPS. The "_V" suffix denotes the single-organization variant; it does not perform organization security filtering in the manner of an "ORG_ID"-based multi-org secured view. Callers must supply or constrain ORGANIZATION_ID explicitly.

Underlying Base Objects

The ETRM 12.2.2 metadata documents the following referenced base objects:

  • WIP_ENTITIES (synonym) — the master entity record; supplies WIP_ENTITY_ID, ORGANIZATION_ID, WIP_ENTITY_NAME, DESCRIPTION, and ENTITY_TYPE.
  • WIP_DISCRETE_JOBS (synonym) — discrete job detail; supplies primary item, class code, BOM revision, status, and closure date.
  • WIP_REPETITIVE_SCHEDULES and WIP_REPETITIVE_ITEMS (synonyms) — repetitive schedule header and line information, unioned into the same result shape.
  • WIP_LINES (synonym) — repetitive line identifiers.
  • MTL_SYSTEM_ITEMS_VL (view) — item description and primary unit of measure.
  • MFG_LOOKUPS (view) — decodes ENTITY_TYPE (lookup type 'WIP_ENTITY') and STATUS_TYPE (lookup type 'WIP_JOB_STATUS') into meaningful text.

The view text is composed of three UNION ALL branches: one for discrete jobs with a primary item, one for discrete jobs without a primary item, and one for repetitive schedules. Each branch aligns its output to a common column list so the union remains type-consistent.

Key Columns

  • WIP_ENTITY_ID / ORGANIZATION_ID — the composite key identifying the job or schedule within an organization.
  • WIP_ENTITY_NAME — the user-visible job or schedule name.
  • ENTITY_TYPE / its lookup meaning — distinguishes discrete jobs from repetitive schedules.
  • PRIMARY_ITEM_ID — the assembly being built; joined to MTL_SYSTEM_ITEMS_VL for description and primary UOM.
  • CLASS_CODE — the WIP class assigned to the job.
  • BOM_REVISION — the bill revision the job is built against.
  • STATUS_TYPE / status meaning — released, unreleased, complete, closed, and similar states decoded via MFG_LOOKUPS.
  • DATE_CLOSED — closure date of the job.
  • ROWID and the standard WHO/audit columns (LAST_UPDATE_DATE, CREATED_BY, REQUEST_ID, PROGRAM_ID, and so on) are carried through from WIP_DISCRETE_JOBS for traceability.
  • FIRM_PLANNED_FLAG is used only as a filter (1 or 2) rather than projected as a column.

Common Use Cases and Queries

Typical uses include open-job reporting, costing reconciliation, and integration extracts that need a flat view of jobs and schedules. A representative query follows:

  • SELECT wip_entity_name, entity_type, status_type, primary_item_id, date_closed FROM apps.cst_wip_entity_v WHERE organization_id = :org_id;
  • SELECT v.wip_entity_name, m.description, v.primary_uom_code FROM apps.cst_wip_entity_v v, apps.mtl_system_items_vl m WHERE v.primary_item_id = m.inventory_item_id AND v.organization_id = m.organization_id AND v.organization_id = :org_id;
  • Joining to WIP_MOVE_TRANSACTIONS or CST tables to reconcile job-level costs against reported completions.

Because the view references WIP_LINES and repetitive tables internally, and applies the FIRM_PLANNED_FLAG restriction, only firm or planned jobs (flags 1 and 2) appear. Queries expecting every created job, or those belonging to a specific ledger or cost group, should therefore restrict results accordingly and always constrain ORGANIZATION_ID.