Search Results sourcing_rule_name




Overview
Explore in AI Chat

Overview

MRP_SR_VIEW_V is a lightweight database view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the MRP (Master Scheduling/MRP) product family and is documented as a "Sourcing rule view." Its purpose is narrow and deliberate: it exposes a minimal, denormalized projection of the sourcing rule definitions maintained within the planning and sourcing-rule infrastructure. Rather than surfacing the full set of attributes held in the underlying sourcing rule tables, the view returns only the sourcing rule identifier and its user-facing name.

This design makes MRP_SR_VIEW_V particularly suitable for integration and reference-lookup scenarios. When an external system, custom concurrent program, or a user-facing LOV (list of values) requires a simple mapping of sourcing rule identifiers to sourcing rule names, this view provides that mapping without exposing editing capability or the deeper configuration details of a sourcing rule. It functions as a read-only convenience object, shielding callers from the join complexity of the base sourcing schema while presenting a stable, human-readable "sourcing_rule_name" for the requested identifier.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, MRP_SR_VIEW_V is defined over a single referenced base object: MRP_SOURCING_RULES, accessed via a synonym in the APPS schema. The view text confirms a straight, non-transformed selection from that table:

  • MRP_SOURCING_RULES — the base sourcing rule table holding the authoritative sourcing rule definitions, including the identifier and name attributes exposed by the view.

Because the view performs no joins, aggregation, or filtering, it is a direct pass-through of two columns. This has two practical implications. First, the view inherits the row population of MRP_SOURCING_RULES exactly, so any sourcing rule visible in the base table is visible here. Second, the view is naturally dependent on the base table for validity and performance; it carries no independent storage and imposes negligible overhead. As with all APPS synonyms, the underlying object resolves to the MRP_SOURCING_RULES in the appropriate application schema, and the view remains VALID as documented.

Key Columns

The view exposes exactly two columns, summarized below:

  • SOURCING_RULE_ID — The unique numeric identifier of the sourcing rule. This is the primary key surrogate used throughout MRP and related modules to reference a specific sourcing rule in transactional and planning contexts.
  • SOURCING_RULE_NAME — The user-assigned name of the sourcing rule. This is the descriptive, human-readable label presented to planners and displayed in sourcing rule setup and maintenance forms. It is the attribute most often surfaced in list-of-values queries, reports, and lookup logic, matching the user search term "sourcing_rule_name."

Common Use Cases and Queries

Typical scenarios for MRP_SR_VIEW_V include populating a list of values for sourcing rule selection, resolving a stored sourcing rule ID into a printable name in a custom report, and reconciling sourcing data during data-migration or integration work. Because the view projects only two columns, it is an efficient source for name resolution where the full sourcing definition is not required.

Representative queries include:

  • Retrieve all sourcing rules with names: SELECT sourcing_rule_id, sourcing_rule_name FROM apps.mrp_sr_view_v ORDER BY sourcing_rule_name;
  • Resolve a specific rule by name: SELECT sourcing_rule_id FROM apps.mrp_sr_view_v WHERE sourcing_rule_name = :p_name;
  • Resolve a rule by ID: SELECT sourcing_rule_name FROM apps.mrp_sr_view_v WHERE sourcing_rule_id = :p_id;
  • Case-insensitive search: SELECT sourcing_rule_id, sourcing_rule_name FROM apps.mrp_sr_view_v WHERE UPPER(sourcing_rule_name) LIKE UPPER('%'||:p_fragment||'%');

Because the view is a pass-through over MRP_SOURCING_RULES, no additional filtering of inactive or obsolete rules should be assumed; any such qualification must be applied explicitly if required by the consumer.