Skip Headers

Oracle Cost Management User's Guide Release 12.1 Part Number E13635-05

Contents Previous Next

Iterative Periodic Average Costing

This chapter covers the following topics:

Iterative Periodic Average Costing (IPAC) Overview Comparing IPAC and Standard Periodic Average Costing Iteration Process Setting Up IPAC Running IPAC Viewing IPAC Process Status For a Period

Iterative Periodic Average Costing (IPAC) Overview

Iterative Periodic Average Costing (IPAC) is an alternative approach to standard periodic average costing and differs in the method of valuating the inter-organization transfers across cost groups. It is applicable in countries where the standards of cost absorption for inter-organization transfers across cost groups are more stringent and are not met by standard Periodic Average Costing (PAC). The inter-organization transfers that are impacted in this costing model are those transfers across cost groups within the same legal entity. Inter-organization transfers within the same cost group or across cost groups in different legal entities are not impacted in this costing model.
Glossary

Cost Group One or more premises of a company (e.g. manufacturing plants and/or warehouses) considered as a unit for costing purposes. All the premises belonging to the same cost group will carry the same unit cost.

Cost Owned Transactions Cost owned transactions are transactions that carry their own costs and are used to compute the periodic average unit cost, which is applied to cost derived transactions. Some examples of cost owned transactions include PO receipts, WIP job completions, miscellaneous transactions with cost, and inter-organization transfers across cost groups. Cost Derived Transactions Cost-derived transactions are transactions that are transacted at the newly computed periodic average unit cost of the period. Some examples include sales order issue, issues to WIP job, material issues, and returns to WIP. Periodic Moving Average Cost Periodic Moving Average Cost (PMAC) is the cost computed by moving the previous periods cost and inventory balance at each step of the PAC calculation process for the current period. PMAC is used during the iteration process for valuating inter-organization transfers across cost groups. The final PMAC computed after valuating all transactions is the PAC for the period. PMAC is calculated as follows: PMAC = ((Prior Cost * Prior Quantity) + (Inter-organization receipt quantity * PMAC cost of the corresponding shipment cost group)) / (Prior Quantity + inter-organization receipt qty) Where: Prior Quantity: Previous Period Quantity + SUM (Transaction Quantity). Prior Cost: ((Previous Period Quantity * Previous Period Cost) + SUM (Transaction Quantity * Transaction Cost)) / (Prior Quantity + SUM Transaction Quantity) Previous Period Cost The previous periods Item cost. Transaction Quantity

Receipt transaction quantities not including inter-organization receipts in the current period. Transaction Cost Receipt estimated prices or vendors invoice final prices within the costing period. Recursive Inter-organization Transfers Recursive inter-organization transfers refer to goods that move in both directions between two cost groups. One cost group ships to and also receives from the other cost group the same item.

Comparing IPAC and Standard Periodic Average Costing

IPAC model is different from standard PAC in the following areas:

IPAC model uses the current PMAC for valuating the inter-organization transfers across cost groups. Standard PAC uses the prior period PAC for these transfers. When recursive transfers across cost groups exist (when both shipments and receipts occur between two cost groups for the same item) an iteration process is used to derive the periodic cost to minimize the variance. Standard PAC does not treat these transactions in any special manner. Items are processed in a specific hierarchy during cost rollup to ensure that the iteration process for the child items is completed before they are rolled up into parent items cost.

The detailed differences between IPAC and standard PAC can be described by the differences in how the detailed PAC calculation steps are processed between these two costing models. In standard PAC, there are different phases of calculation and you must run three concurrent programs to complete the entire process. Details are as follows: 1. Acquisition Cost Processor: This program runs Phase 1 where acquisition cost is calculated. 2. Periodic Cost Processor: This program runs Phase 2 through Phase 5. Periodic cost is calculated during phase 5 and preceding phases process the transactions to facilitate the periodic cost calculation in Phase 5. 3. Periodic Cost Distributions Processor: This program runs Phase 6 where distributions are created.

Note: The first two programs are run separately for each cost group in standard PAC. In the IPAC method, a single program is used to run the acquisition cost processor and the periodic cost processor, and this program runs concurrently for all cost groups under a legal entity. The primary difference in the IPAC process is during Phase 5. In both standard PAC and IPAC, Phase 5 is further divided into several steps, one of such steps processes the cost owned transactions to compute the PAC that is used in subsequent steps. In standard PAC, inter-organization transfers across cost groups are processed with the other cost owned transactions such as PO receipt. In IPAC, these transfers are segregated and processed separately from the other cost owned transactions. The two significant processes used in the valuation of these inter-organization transfers across cost groups include: 1. Using an iteration process to reduce variance. 2. Using specific sequencing, referred to as absorption hierarchy, for processing items to ensure that the iteration process for child items is completed before their costs are rolled up into the parent items cost.

Iteration Process
The significance of the iteration process is illustrated in the following example. There are two cost groups, CGA and CGB, under the same legal entity. Each cost group is associated with the appropriate inventory organizations. Use an example of a recursive inter-organization transfer of Item A between these two cost groups. Period beginning quantity and prior period PAC in CGA are 10 each and $9 respectively. Similarly in CGB they are 20 each and $12 respectively. PMAC is the current period moving periodic cost calculated prior to valuating the interorganization transfers.

This transfer can be viewed as four transactions: 1. 2. 3. 4. TX1 TX2 TX3 TX4 is is is is inter-organization inter-organization inter-organization inter-organization shipment from CGA receipt into CGB shipment from CGB receipt into CGA

Standard PAC: In standard PAC, TX1 and TX2 are valuated at $9 (prior period PAC of sending cost group) and TX3 and TX4 are valuated at $12. IPAC: In IPAC, these transactions are valuated using an iteration process. At the end of each iteration, item PMAC cost (aggregate of all sub-elemental costs) is compared with the item PMAC cost derived in the previous iteration and it is verified that the difference is within the tolerance. Tolerance can be specified when running this process. PMAC is calculated using the following formula:

You should first consider CGA. TX4 is a receipt and must be valuated with PMAC of CGB: 15. Based on this, the revised PMAC for CGA is 10.833. Use this to valuate TX1 and TX2. Based on this, the revised PMAC in CGB is 14.6212. At the end of one iteration, the costs in both cost groups are:

Because the tolerance check is done between the item cost in nth iteration with the item cost in the previous n-1 iteration, no tolerance check is done after the first iteration. Tolerance check is done from 2nd iteration onwards. In this case, the second iteration is performed at the end and the costs will be as follows:

Differences after the second iteration are as follows: CGA: 10.8333 - 10.7702 = 0.063 CGB: 14.6212 - 14.6154 = 0.0058 Because the difference is within tolerance, the iteration for the item ends at this point and these costs are used as periodic costs for further processing. Diverging Scenarios In cases of negative inventory scenarios tolerance, the differences between successive iterations may diverge. This means that the difference increases rather than decreases between two iterations. In such cases, the iteration process is stopped for the item in those cost groups, but the process continues for the other entire cost group until completion. Absorption Hierarchy Absorption hierarchy determines the correct sequence for processing items. This absorption hierarchy is derived based on the BOM level of an item across cost groups. Use the following procedure to determine the absorption hierarchy:

Identify the corresponding level in all existing BOM across cost groups for each item. Identify the highest BOM level across cost groups. Items that are not involved in any BOM are treated as leaf nodes, or at the lowest BOM level.

Create a unique hierarchy with the levels identified in the previous step, further resolving any interdependencies of the item levels across cost groups. This hierarchy determines the priority sequence in which items should be processed. The process starts from the lowest level (leaf nodes) and moves to the highest parent level.

The following example illustrates the Absorption Hierarchy:

In this example, there are three cost groups CG1, CG2 and CG3. There are three BOM structures with different items in different levels. The lowest BOM level is considered as the leaf node and is represented by number 1000. The next higher levels are represented as 999, 998 and so on. The BOM level for each cost group from the above illustration will be: Item CG1 CG2 CG3 Highest F3 M1 T1 C1 1000 999 998 1000 1000 1000 999 998 1000 1000 1000

T4 M6 T3

998 999

1000 998 999 999 999

Further analysis is done to resolve the item level dependencies between cost groups. In the above example, items M1, M6, and T3 are at the same level of 999. However, T3 cannot be processed before T1 because T1 is a child item for T3 in cost group 2. Similarly, M6 cannot be processed before M1 and T3. Such interdependencies are resolved and a unique hierarchy of eligible items is derived for this example as follows: Item M1 T1 T3 T4 M6 New Level Codes 999.0000 998.0000 997.0000 996.0000 995.0000

F3, C1 1000.0000

Items F3 and C1 are first processed for deriving their periodic costs, and then the next level of items are processed. Deadlock Scenario There can be a deadlock scenario when there are BOM loops across cost groups. in a deadlock scenario, the same item is a parent and child of another item. For example, Item A is a parent of Item B in cost group 1, and Item B is a parent of Item A in cost group 2. In such cases, the IPAC process ends abruptly and you must resolve the deadlock scenario and run the process again.

Setting Up IPAC

IPAC is set up in the same way as standard PAC. The only additional step is to enable IPAC when defining the legal entity cost type associations. To enable or disable IPAC 1. Navigate to the Org Cost Group / Cost Type Associations window.

2. Select the Cost Type Associations tab. 3. Select the Enable Iterative Periodic Average Costing check box to use IPAC. 4. You can also select the Perform Multiple Iterations check box. This attribute determines whether multiple iterations should be performed until the tolerance is achieved when inter-organization transfers across cost groups are processed. If this is not checked, then only one iteration is performed. Note: You can leave this unchecked to improve the performance if you do not follow stringent standards to comply with the tolerance. 5. Save your work.

Running IPAC
IPAC is calculated by running the Compute Iterative Periodic Average Cost concurrent program. To run the Compute Iterative Periodic Average Cost concurrent program 1. Navigate to the Compute Iterative Periodic Average Cost concurrent window. The Parameters window displays. Note: Run this process for all cost groups under a legal entity and cost type.

2. Enter Run Options. Run Options include Start, Resume From Error, Resume for Non Tolerance, and Final Iteration. o Start - Start the processor from the beginning. The application will re-run the process for all items and transactions, regardless whether the tolerance is achieved for any of them in earlier runs. o Resume from Error - Resume from error can be used when the program ends abruptly due to some unexpected errors or due to deadlock scenario. o Resume for Non Tolerance - Resume from non-tolerance can be used when the program ends but the tolerance is not achieved. This option resumes the processor from the Rollup Iteration Process, only for those items that have not met the tolerance required, in earlier run. o Final Iteration - Finish the iteration process regardless of the tolerance achieved for the items. The option Final Iteration can be used when the earlier run ends in non-tolerance but you would like to finalize the periodic costs with whatever values are arrived at after one more final iteration. This option is applicable if you are not too particular of achieving the tolerance. 3. Enter Process Upto Date. This value defaults to the end date of the current period. You can specify the date for selecting the transactions that should be processed by the program. This date must be within the period specified above. 4. Enter Tolerance. Specify the tolerance that the variance should be within.

5. Enter Number Of Iterations. This is the maximum number of iterations that should be performed. The iteration process ends after the tolerance specified is achieved or the number of iterations is completed, whichever occurs first. 6. Specify the Number Of Workers. You can specify the number of workers that can be processed simultaneously to enable parallel processing and to improve performance. This number should be less than or equal to the number of cost groups. 7. Click OK. The report output of the process displays the detailed iteration calculation for all items and cost groups. You can review the report for details. Any errors or exception scenarios are included in the report. A typical report output would look like the following:

Viewing IPAC Process Status For a Period

There is not a separate phase for tracking the IPAC process. The cost processing phase is used for tracking and viewing the process status for a period. To view IPAC process status for a period 1. Navigate to the Process Status window.

Note: If the program ends in non-tolerance, then the status is shown as Resume for Non-tolerance. Viewing Periodic Cost calculated by IPAC The same item cost inquiry used for standard PAC is used to view the costs calculated by IPAC. Creating Distributions

There is no change in the way distributions are created when IPAC is enabled. Distributions are created in the same way when standard PAC is enabled. Enhancements in Release 12 Release 12 includes the following enhancements:

The iteration process is optional and you can choose not to use the iteration process while enabling IPAC at the legal entity and cost type level. EAM organizations are supported. Transfer cost specified on the organization parameters or shipping network is applied on the basis of PMAC. It was based on the perpetual cost prior to Release 12. Because Oracle Process Manufacturing (OPM) and discrete organizations are converged at the inventory organization level, inter-organization receipts from an OPM organization are processed like any other cost owned receipts. The price of the receipt is determined from the transfer price list specified in the shipping network between these two organizations, or you can use the client hook provided to pass the desired price. PAC supports transfer price for internal movements processed using internal orders. Therefore, IPAC does not process internal order shipments and receipts when transfer price is applicable. If the profile option CST: Transfer Pricing Option is set to Yes, Price as incoming cost, then such transactions are excluded from the iteration process. Contents | Previous | Top of Page | Next
Copyright 1996, 2010, Oracle and/or its affiliates. All rights reserved.