Search Results operation_seq_id




Overview
Explore in AI Chat

Overview

BOM_CALC_CYNP is an Oracle EBS Bills of Material (BOM) package body owned by the APPS schema. Its purpose is the calculation of cumulative yields and net planning percentages across manufacturing routing operations, including the handling of rework loops and cyclical operation networks. In a discrete manufacturing environment, the cumulative yield of a routing represents the compounded probability that a unit survives every operation it passes through. When rework paths, feeder networks, and cyclical dependencies exist between operations, this calculation can no longer be performed with a simple sequential product. BOM_CALC_CYNP provides the recursive traversal and iterative convergence logic required to derive correct cumulative yield (CYNP) values in those non-linear cases.

Key Procedures and Functions

The documented API surface exposes two entry points, both classified as OTHER:

  • CALC_CYNP — The primary driver that computes cumulative yield and net planning percentage values for a routing. It is the routine callers invoke when routing yield figures must be refreshed.
  • CALC_CYNP_RBO — A variant (read-only / rollback-oriented entry point) used where the calculation must be performed without persisting changes, or under a controlled commit strategy.

The package body additionally declares substantial internal machinery that supports these entry points. Functions such as on_primary_path, find_op, find_in_main_tbl, and isCyclical identify operations and detect cyclical network relations, while is_dummy flags placeholder operations. Procedures including collect_ops_between_rework, collect_total_rework_prob, calc_net_planning_pct_rework, calc_cum_yld, calc_rev_cum_yld, calc_net_plan_pct, calc_primary_network, and calc_feeder_network perform the traversal, accumulation, and reverse cumulative yield computations. An Op_Rec_Type record type carries operation_seq_id, operation_seq_num, and yield, which explains why a search for "operation_seq_id" resolves to this object — the identifier is the fundamental key by which operations are located, compared, and accumulated throughout the network walk.

Tables Accessed

The package reads and writes the following objects through APPS synonyms:

  • BOM_OPERATION_SEQUENCES — Source of individual operation definitions, including the operation sequence identifier and per-operation yield used as the base input.
  • BOM_OPERATIONAL_ROUTINGS — Routing headers that group operations and supply routing-level context for the calculation.
  • BOM_OPERATION_NETWORKS — The network edges describing predecessor/successor and rework relationships between operations; this drives the recursive and cyclical traversal.
  • DUAL — Used for scalar evaluations and default-value selection.
  • PLITBLM — The PL/SQL index-by table of lines mechanism used for accumulation within the calculation.
  • UTL_FILE — Used with the g_Debug_File declaration to emit diagnostic trace output when debugging is enabled.
  • V$PARAMETER — Read to detect instance parameters, typically to determine whether debug output is permitted.

Usage Notes

BOM_CALC_CYNP is an internal engine rather than an end-user API. It is referenced by five other packages and is typically invoked indirectly: from BOM inquiry and maintenance forms when routing yields must be displayed or recalculated, from concurrent programs that refresh cumulative yield and net planning percentages across routings, or from other BOM packages performing rollup and cost-related processing. The CALC_CYNP_RBO entry point supports recalculation scenarios where the caller requires the result without committing the standard updates. Because the package resolves operations through operation_seq_id and walks the operation network recursively, it should be invoked only after BOM operation sequences and network definitions are complete and stable for the routing; incomplete or mid-maintenance networks can produce inaccurate cumulative yields. The package is available in both 12.1.1 and 12.2.2, and its debug file handling relies on UTL_FILE directory configuration and V$PARAMETER visibility, so diagnostic tracing requires appropriate database privileges.