Search Results update_items_and_sourcing

Overview

CTO_UPDATE_ITEMS_PK is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Configure-to-Order (CTO) manufacturing model. Its central purpose is to maintain consistency between configured item definitions, sourcing rules, and the cost and cross-reference data that Oracle Manufacturing relies upon when a model or option configuration changes. The package declares AUTHID CURRENT_USER, meaning its SQL executes with the privileges of the invoking session rather than the package owner. The package header carries a revision marker of 120.1 dated 11 November 2010 and a creation history dating to October 2003, indicating it has been a long-standing component of the CTO utility layer. Its dominant entry point, Update_Items_And_Sourcing, is the procedure most commonly associated with the search term "update_items_and_sourcing". The package is referenced by one other package, confirming it is an internal utility rather than a top-level user interface. Its responsibilities span four related areas: propagating sourcing changes to configured items, propagating Bill of Material and configuration changes to ATO lines, synchronizing accounting item attributes, and updating item and cost data tied to a passed category identifier.

Key Procedures and Functions

• Update_Items_And_Sourcing — The principal driver procedure. It accepts a changed-source indicator, a category identifier, an upgrade-mode flag, and (following Bugfix 10240482) a maximum sequence parameter, returning status, message count, and message data. It is responsible for refreshing item and sourcing information across the CTO organization model.
• Update_Bcso — Updates Base Configuration and Sourcing Object data for a given ATO line, returning the standard status, message count, and message data triple.
• Update_Acc_Items — Updates account-related item attributes, returning status, message count, and message data.
• Update_Item_Data — Updates item-level data for the supplied category identifier, returning status, message count, and message data.
• Update_Pc_Items — Updates processed-cost item records, returning status, message count, and message data.
• get_attribute_control — A function that returns a numeric control value for a named attribute, used to determine whether a given attribute is eligible for update.
• get_cost_group — A function that returns an integer cost group for a given organization identifier and line identifier.
• WriteToLog — A diagnostic utility that writes a message at a specified debug level. Package initialization reads the ONT_DEBUG_LEVEL profile option into the global gDebugLevel.

Tables Accessed

The package reads and writes CTO model metadata through BOM_CTO_MODEL_ORGS, BOM_CTO_ORDER_LINES_UPG, and BOM_CTO_SRC_ORGS_B, which describe model organizations, order lines eligible for upgrade, and sourcing organizations respectively. Cost data is drawn from CST_COST_TYPES, CST_ITEM_COSTS, CST_ITEM_COST_DETAILS, and CST_QUANTITY_LAYERS, supporting the cost-group and processed-cost procedures. Item and category definition data is accessed through MTL_CATEGORY_SETS_B, MTL_DEFAULT_CATEGORY_SETS, and the MTL_CROSS_REFERENCES family (MTL_CROSS_REFERENCES, MTL_CROSS_REFERENCES_B, MTL_CROSS_REFERENCES_B_S, and MTL_CROSS_REFERENCES_TL). Supporting lookups use FND_ATTACHED_DOCUMENTS and FND_LANGUAGES. All access is through APPS synonyms.

Usage Notes

CTO_UPDATE_ITEMS_PK is invoked as a back-end utility rather than directly from a user form. Typical invocations occur during upgrade processing—particularly when converting or resynchronizing configured items, as the _UPG table and the upgrade-mode parameter suggest—and during sourcing-rule maintenance. Because the procedures return standard FND-style status, message count, and message data values, callers are expected to interrogate xReturnStatus and, on failure, retrieve messages through the message stack. Debug output is governed by the ONT_DEBUG_LEVEL profile option, so enabling that profile at an appropriate level is the supported method for tracing execution. Custom code should call the package only with the documented signatures and should not bypass it to update the underlying BOM_CTO and CST tables directly, since the procedures maintain cross-table consistency that a direct DML statement would not preserve.