Search Results update_mat_cost




Overview

APPS.CSTPOYUT is a cost management utility package in Oracle E-Business Suite that supports the cost roll-up and cost update processing for Work in Process (WIP) operations. Its principal business function is to write operation cost and quantity information into the WIP_OPERATION_YIELDS table on behalf of the Oracle Cost Management application. The package header is dated in the 11i timeframe (header revision 115.3, dated 2002) and the documented API classification is OTHER, meaning it is an internal utility rather than a formally published public API.

The package is invoked from two distinct cost processes: the material cost manager path, which records costs associated with material transactions issued to or returned from WIP, and the WIP cost manager path, which records operation-level cost and yield information for WIP entities. Because it writes directly to WIP_OPERATION_YIELDS, CSTPOYUT sits at the intersection of Cost Management and Work in Process, keeping the operation yield records synchronized with the cost figures computed by the cost managers.

Key Procedures and Functions

The ETRM metadata documents three program units within the package:

  • UPDATE_MAT_COST — Updates operation cost in WIP_OPERATION_YIELDS from the material cost manager. It accepts cost type, material transaction, organization, operation sequence, inventory item, transaction quantity, WIP entity, WIP entity type, user, login, and concurrent program context information, and returns a numeric result. It is the entry point used when material transactions drive cost updates against WIP operations.
  • UPDATE_WIP_COST — Updates operation cost in WIP_OPERATION_YIELDS from the WIP cost manager. The user search term "update_wip_cost" maps directly to this function. It takes a group identifier along with user context and returns a numeric status, where the documented convention is 1 for success and 0 for failure. It is the entry point used when the WIP cost manager processes a batch of operation cost records.
  • UPDATE_WOY_STATUS — Updates the status of WIP operation yield records. This companion routine maintains the state of the yield rows that the two cost update functions populate, ensuring records are flagged consistently as costing progresses.

No parameter lists beyond those present in the source excerpt are asserted here; consumers should treat the signatures as internal and subject to change.

Tables Accessed

The documented table references, resolved through APPS synonyms, are:

  • WIP_OPERATION_YIELDS — the primary target of the package; operation cost and quantity values computed by the cost managers are written here.
  • WIP_TRANSACTIONS and WIP_TRANSACTION_ACCOUNTS — source transaction and accounting data used to derive the costs being applied.
  • WIP_ENTITIES — identifies the WIP job or repetitive schedule whose operations are being costed.
  • CST_ITEM_COSTS — supplies item cost information at the applicable cost type.
  • MTL_PARAMETERS — provides organization-level inventory and costing setup context.

The package both reads from and writes to this set, with WIP_OPERATION_YIELDS being the dominant write target.

Usage Notes

CSTPOYUT is an internal utility, not a user-facing API. It is invoked by the Cost Management cost managers — the WIP cost manager and the material cost manager — during cost update processing rather than being called from Oracle Forms or standalone concurrent programs. The user identifier, login identifier, application identifier, program identifier, and request identifier parameters carried on these functions indicate that calls originate from a concurrent program context, which allows cost records to be stamped with the originating request and enables consistent error reporting through the standard request mechanism.

Because the ETRM metadata records zero downstream dependents, no other documented package relies on CSTPOYUT, reinforcing its role as a leaf-level writer rather than a reusable API. Customizations should avoid calling this package directly: it writes into WIP_OPERATION_YIELDS without the validation and locking safeguards of a published API, and its signatures are not guaranteed across releases. Where custom costing logic is required, the supported approach is to extend or wrap the standard cost manager processes rather than to invoke UPDATE_WIP_COST or UPDATE_MAT_COST directly.