Results for “bill_of_distribution”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The MRPBV_BILL_OF_DISTRIBUTIONS view is a read-only database object owned by the APPS schema within the Oracle E-Business Suite environment. It belongs to the MRP (Master Scheduling/MRP) product family and is classified in the ETRM documentation as Retrofitted. The view presents a denormalized, reporting-friendly representation of sourcing rules that function as bills of distribution. In Oracle planning and sourcing terminology, a bill of distribution defines the network of supply relationships through which an item is sourced across a multi-level distribution structure. This view surfaces that configuration data in a form that is straightforward to query, integrating the sourcing rule definition held in the base tables with descriptive lookup text.

Because the object is defined WITH READ ONLY, it is intended strictly for inquiry, reporting, and integration extraction rather than transactional maintenance. It plays a supporting role in downstream reports, data extracts, and interfaces that need to identify which sourcing rules have been designated as bills of distribution and whether they are currently planning-active. The view filters its results specifically to sourcing rules whose sourcing rule type equals 2, which corresponds to the bill of distribution designation.

Underlying Base Objects

Per the documented ETRM metadata for release 12.2.2, the view is defined over two referenced base objects within the APPS schema:

• MRP_SOURCING_RULES (SYNONYM) — the primary source object supplying the sourcing rule records, including the sourcing rule name, description, identifier, planning-active flag, type, and the standard audit columns (creation and last-update information).
• MFG_LOOKUPS (VIEW) — the lookup view used to resolve the planning-active code into a human-readable meaning. This join uses the lookup type SYS_YES_NO.

The view text joins these objects on the condition that the sourcing rule type equals 2 and that the planning-active value matches a lookup code where the lookup type is SYS_YES_NO. This restricts the row set to bills of distribution and translates their active/inactive status into descriptive text. The dependency on a synonym and a lookup view means the object is layered indirectly over the underlying base tables rather than referencing them directly.

Key Columns

The view exposes the following columns, which differ slightly in naming from the underlying source columns:

• BILL_OF_DISTRIBUTION — the sourcing rule name, exposed under this descriptive alias.
• DESCRIPTION — the free-text description of the sourcing rule.
• PLANNING_ACTIVE_FLAG — the meaning text from the SYS_YES_NO lookup, indicating whether the bill of distribution is active for planning.
• BILL_OF_DISTRIBUTION_ID — the sourcing rule identifier, exposed under this alias for use as a foreign key reference.
• LAST_UPDATE_DATE and LAST_UPDATED_BY — standard audit columns recording the most recent modification.
• CREATION_DATE and CREATED_BY — standard audit columns recording initial creation.

Common Use Cases and Queries

Typical scenarios include validating which sourcing rules are configured as bills of distribution, confirming their planning-active status, and joining the result back to assignment or sourcing tables using the bill of distribution identifier. The following query lists all planning-active bills of distribution:

SELECT bill_of_distribution,
       description,
       planning_active_flag,
       bill_of_distribution_id
FROM   apps.mrpbv_bill_of_distributions
WHERE  planning_active_flag = 'Yes';

Because the object is read-only, it is safe to query from custom reports, concurrent program extracts, and integration views without risk of mutating configuration data. When combining it with sourcing assignment or bill of distribution detail tables, the BILL_OF_DISTRIBUTION_ID provides the linkage key. Analysts should note that the row set is inherently filtered to sourcing rule type 2, so no additional type predicate is required in most queries.