Search Results mtl_project_v




Overview

MTL_PROJECT_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, delivered under the Inventory (INV) product module. Its ETRM classification identifies it as VALID within the documented 12.2.2 environment, with a description of "Retrofitted," indicating that the object was re-pointed or re-engineered during an upgrade cycle rather than authored as a new custom artifact. In practice, MTL_PROJECT_V exposes a normalized, security-filtered projection of Oracle Projects data — specifically project identifiers, numbering, descriptive attributes, and planning attributes — for consumption by Inventory and manufacturing-adjacent processes that must reference project context without directly querying Oracle Projects (PA/PJM) internals.

The view is deliberately narrow. It is not a general-purpose project repository; it surfaces just enough project metadata to support lookups, value-list populations, and joins from inventory-side transactions and reports to the project dimension.

Underlying Base Objects

The documented view text is a straightforward projection over a single base object:

  • PJM_ORG_PROJECTS_V — the sole FROM-clause object in the view definition, aliased POPV. All seven exposed columns are selected directly from this Projects view with no filtering, aggregation, or expression logic.

The documented 12.2.2 metadata additionally registers package dependencies: FND_PROFILE, MRP_GET_PROJECT, PA_CROSS_BUSINESS_GRP, PA_PROJECT_UTILS, and PA_SECURITY. These are not base tables of MTL_PROJECT_V itself but are called indirectly through PJM_ORG_PROJECTS_V. Their presence is significant: PA_SECURITY and PA_SECURITY-dependent logic enforce project security (organization and cross-business-group access) so that rows returned reflect the querying responsibility's authorized project set, while FND_PROFILE supplies profile-option-driven behavior within that chain. MRP_GET_PROJECT provides planning-side project resolution. The practical consequence is that MTL_PROJECT_V inherits Projects security semantics even though the view body itself contains no WHERE clause.

Key Columns

  • PROJECT_ID — the primary surrogate key for the project; the canonical join column to PA_PROJECTS and to inventory or transaction tables carrying a project reference.
  • PROJECT_NUMBER — the user-facing project number, typically the value displayed on forms and entered on transactions.
  • PROJECT_NAME — the descriptive project name, used in reports and list-of-values presentations where a number alone is insufficient.
  • START_DATE — the project start date, useful for date-bounded reporting and validation of transaction timing.
  • COMPLETION_DATE — the project completion date; frequently used to determine whether a project is open or closed for new inventory activity.
  • PROJECT_NUMBER_SORT_ORDER — a pre-computed, zero-padded or otherwise normalized sort key enabling correct alphanumeric ordering of project numbers, which are character-based and would otherwise sort unintuitively.
  • PLANNING_GROUP — the planning grouping associated with the project, supporting aggregation and MRP-related segmentation.

Common Use Cases and Queries

The principal uses are lookups and joins: resolving PROJECT_ID to PROJECT_NUMBER or PROJECT_NAME in inventory reports, driving project list-of-values behavior, and validating that a project referenced on a material transaction is active and within its date range.

Basic project listing:

  • SELECT project_id, project_number, project_name, start_date, completion_date, planning_group FROM apps.mtl_project_v;

Ordered lookup by number for value lists:

  • SELECT project_number, project_name FROM apps.mtl_project_v ORDER BY project_number_sort_order;

Resolving a single project from a transaction reference:

  • SELECT project_number, project_name, completion_date FROM apps.mtl_project_v WHERE project_id = :project_id;

Identifying open projects for current activity:

  • SELECT project_number, project_name, planning_group FROM apps.mtl_project_v WHERE start_date <= SYSDATE AND (completion_date IS NULL OR completion_date >= SYSDATE);

Because security filtering is inherited from the underlying Projects view, query results are constrained by the responsibility's project access rather than by the view's own text — a critical consideration when diagnosing seemingly "missing" projects in reports.