Search Results owning_org_id




Overview

APPS.MRP_BIS_PLAN_PROFIT_V is a reporting view in the Oracle E-Business Suite applications schema. Its purpose is to aggregate planned cost and planned revenue figures at the level of the plan designator and the owning organization. It belongs to the Oracle Advanced Supply Chain Planning business intelligence (BIS) layer, which supplies pre-summarized data to planning dashboards, Discoverer workbooks, and other analytical reporting tools. Because the view returns one summarized row per combination of plan and owning organization, it is suited to plan profitability comparisons rather than transactional drill-down.

The view is defined with a straightforward aggregation query over a single base table, which makes it inexpensive to query and predictable in behavior. In both EBS 12.1.1 and 12.2.2 the definition is unchanged: the view selects COMPILE_DESIGNATOR and OWNING_ORG_ID, and applies SUM to the PLAN_COST and PLAN_REVENUE measures, grouping by the two dimension columns. The user search term "owning_org_id" corresponds directly to the ORGANIZATION_ID of the inventory organization that owns the planned items, which is the primary organizational filter applied by reporting consumers.

Underlying Base Objects

The view is defined over MRP_BIS_PLAN_PROFIT, which is documented in ETRM as a SYNONYM. The synonym resolves to the underlying planning profitability table that stores plan cost and plan revenue amounts per compile designator and owning organization. No joins, unions, or secondary tables are present in the view definition, so the view functions purely as a grouping and summation layer over that base object.

  • MRP_BIS_PLAN_PROFIT (SYNONYM) — the single referenced base object, providing COMPILE_DESIGNATOR, OWNING_ORG_ID, PLAN_COST, and PLAN_REVENUE.
  • COMPILE_DESIGNATOR — identifies the plan compilation (the plan and its compiled version) that produced the rows.
  • OWNING_ORG_ID — the inventory organization identifier under which the plan figures are held.

Because the base object is exposed only as a synonym, the physical table name and its owning schema should be confirmed on site using ALL_SYNONYMS or DBMS_METADATA before any direct dependency analysis is performed.

Key Columns

  • COMPILE_DESIGNATOR — the plan compile identifier. It ties each summarized row back to a specific plan and compilation, and is required in every GROUP BY.
  • OWNING_ORG_ID — the owning inventory organization. This is the key used to segment plan profitability by organization and to join to organization-related master data such as HR_ALL_ORGANIZATION_UNITS or ORG_ORGANIZATION_DEFINITIONS.
  • SUM(PLAN_COST) — total planned cost aggregated across all rows of the base object for the given compile designator and owning organization.
  • SUM(PLAN_REVENUE) — total planned revenue for the same grain.

The view does not expose a margin or variance column; profitability must be derived by subtracting aggregated cost from aggregated revenue in the consuming query.

Common Use Cases and Queries

Typical usage includes plan-versus-plan profitability comparison, organization-level margin reporting, and feeding summary figures into BI Publisher or Discoverer reports. Because the grain is plan and organization, the view is often joined to organization and plan name views for presentation.

  • Retrieve all summarized plan profit rows: SELECT compile_designator, owning_org_id, SUM(PLAN_COST), SUM(PLAN_REVENUE) FROM apps.mrp_bis_plan_profit_v;
  • Filter to a specific owning organization: SELECT compile_designator, owning_org_id, SUM(PLAN_COST), SUM(PLAN_REVENUE) FROM apps.mrp_bis_plan_profit_v WHERE owning_org_id = :p_org_id;
  • Derive margin: SELECT compile_designator, owning_org_id, SUM(PLAN_REVENUE) - SUM(PLAN_COST) margin FROM apps.mrp_bis_plan_profit_v GROUP BY compile_designator, owning_org_id;
  • Joining to organization definitions to display organization names alongside the aggregated plan figures.

When querying, note that the column names in the view are the aliases SUM(PLAN_COST) and SUM(PLAN_REVENUE); these should be referenced with their exact aliases or wrapped in an outer query for clarity.