Search Results cto_transfer_price_pk




Overview

CTO_TRANSFER_PRICE_PK is an Oracle E-Business Suite package owned by the APPS schema and classified under Manufacturing as an "OTHER" API object. It addresses a specific requirement in Configure-to-Order (CTO) environments: the determination and retrieval of the optional components belonging to a configuration item, and the calculation of the transfer price associated with that configured item. The package header carries the RCS identifier CTOTPRCS.pls 120.1, dated 2005/10/28, and is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer.

The package originated in Oracle Manufacturing and was created to satisfy two distinct business needs documented in its header comment: first, Get the optional components of a configuration item from either the sales order or the BOM; second, Calculate Transfer Price for a configuration item. The latter is significant because transfer pricing between internal organizations or legal entities must reflect the configured bill of material rather than the generic model item price. Headers in the format "TRANSFER NOW" correspond to CTO transfer price list lines; the rupee value shown in such a search string reflects an organization-specific transfer price derived from data this package prepares.

Key Procedures and Functions

The package exposes four documented procedures or functions. Exact parameter lists are not reproduced here; the descriptions below reflect documented purpose.

  • GET_CONFIG_DETAILS — Returns the optional components of a configuration item and of its child configuration items, selecting the source data from either a sales order or the configuration BOM according to the caller-supplied mode. The optional components are written into BOM_EXPLOSION_TEMP under a unique group_id, which is returned to the calling application so the caller can read back the exploded set.
  • GET_CONFIG_DETAILS_BCOL — A sales-order-driven variant. It returns the optional components of a configuration item and its children based on a sales order, populating BOM_EXPLOSION_TEMP against a caller-provided group_id. The "_BCOL" suffix indicates the BOM_CTO_ORDER_LINES basis for the explosion.
  • GET_CONFIG_DETAILS_BOM — The BOM-driven counterpart, deriving the optional component set from the configuration bill of material rather than from order lines, and depositing results into the same temporary explosion table.
  • CTO_TRANSFER_PRICE — The pricing procedure. It calculates the transfer price for a configuration item, operating over the exploded optional-component set to arrive at a configured transfer value.

Tables Accessed

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

  • BOM_EXPLOSION_TEMP and BOM_EXPLOSION_TEMP_S — the primary output sink. The temporary and its sequence are used to stage exploded optional components keyed by group_id, decoupling the explosion from the subsequent read by the caller.
  • BOM_CTO_ORDER_LINES — supplies the sales-order-side configuration line data used by the "_BCOL" path.
  • OE_ORDER_LINES_ALL — provides order line context, including the line identified by the caller for order-based explosions.
  • MTL_SYSTEM_ITEMS — the item master, used to resolve item attributes and organization-level item identity during explosion and pricing.
  • DUAL — used for scalar expression evaluation and single-row utility selects.

Usage Notes

CTO_TRANSFER_PRICE_PK is not an end-user-facing API. It is invoked programmatically by three other packages within the application, which call it to obtain a staged optional-component set before pricing or order processing proceeds. Typical invocation patterns include configuration validation and pricing logic triggered from the Configure-to-Order order entry flow, and transfer price derivation routines that need a configuration-aware price rather than the model price. Because the explosion output is written to a temporary table keyed by group_id, callers must consume and, where appropriate, purge that staged data after reading. Customizations should call the procedures through the APPS synonym rather than referencing the underlying package directly, and should expect the OUT status, message count, and message data parameters to be populated on the standard EBS error-handling convention.