Search Results cst_lists_s




Overview
Explore in AI Chat

Overview

APPS.INVPCOII is a VALID PL/SQL package body residing in the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the Inventory cost management domain and is catalogued by Oracle's ETRM repository with an API classification of OTHER, indicating that it is an internal, non-public implementation package rather than a formally published extension API. The name follows Oracle's internal naming conventions for costing-related utilities, where the "INV" prefix denotes an Inventory-family object and the "PC" segment typically signals a process-costing or cost-interface role. The package serves as a supporting engine within the Cost Management module, orchestrating the movement of cost data between the interface layer (MTL_SYSTEM_ITEMS_INTERFACE), the standard cost tables, and the lists infrastructure that drives cost group and cost set definitions. It is consumed internally by other cost management packages rather than invoked directly by end users, and it is documented as referencing — and being referenced by — other APPS-owned cost processing units.

Key Procedures and Functions

The ETRM metadata documents four procedures or functions within APPS.INVPCOII. Their precise parameter signatures are not published in the metadata and should not be assumed; the descriptions below reflect the documented names and their evident functional grouping.

  • CSTFVSUB — Likely a cost "value submit" or cost sub-routine responsible for staging or submitting cost values into the appropriate cost structures. The "FV" pattern in Oracle costing code commonly denotes frozen or valued cost handling.
  • CSTPIICD — A cost process-costing interface/interim cost deletion or detail routine, associated with the interface cost table (CST_ITEM_COST_DETAILS) used during cost update and purge cycles.
  • CSTPPCOI — A process-costing insertion routine, presumably inserting cost rows from the interface into the item-cost tables during a cost update run.
  • CSTPIICP — A companion interface-cost procedure, likely processing interface cost records prior to final cost population.

Together these four entry points suggest a cohesive suite for reading interface cost rows, validating them against cost elements, and writing them to the item cost tables. Exact call sequencing and parameters must be obtained from the source in the database.

Tables Accessed

APPS.INVPCOII references the following documented objects, all accessed through APPS synonyms:

  • MTL_SYSTEM_ITEMS_INTERFACE — source of item and cost data to be processed.
  • CST_ITEM_COSTS and CST_ITEM_COST_DETAILS — the primary cost destinations written during processing.
  • CST_ELEMENTAL_COSTS and CST_STANDARD_COSTS — element- and standard-level cost references.
  • CST_LISTS and CST_LISTS_S — the cost list definition and its sequence/alternate-key table. The user's search term cst_lists_s corresponds to this dependent table, which holds the surrogate/sequence keying for cost list headers.
  • BOM_RESOURCES — resource definitions used when costing resource-driven elements.
  • MTL_PARAMETERS — organization-level cost and inventory control parameters.
  • DUAL — used for single-row utility queries.

The package also references the cost programs CSTPIICC, CSTPUMEC, INVPUOPI, and the STANDARD package. Pursuant to the metadata, APPS.INVPCOII is not referenced by any database object, confirming its role as a top-level internal driver.

Usage Notes

APPS.INVPCOII is typically invoked indirectly through Oracle Cost Management processing — most commonly the cost update, cost interface, and standard cost roll-up concurrent programs — and through form-driven transactions that trigger cost recalculation. Because it is classified OTHER rather than a public API, direct calls from custom code should be treated as unsupported; the documented, extension-safe surface should be reached through the officially published cost APIs (for example, CSTPIICC and CSTPUMEC, which this package itself references). In 12.1.1 and 12.2.2, the package remains VALID and unchanged in ownership, and any customization should avoid recompiling or wrapping it where ETRM marks it as non-referenced, as doing so risks invalidating dependent cost modules during patch application.