Recently we received few comments about the inventory values generated using the below hack not matching the transaction historical summary report values (R12). We had gone through a series of exercises to evaluate such claims and confirmed that all those comments were valid. Below are the few possible explanations.
Though both the above said reports call the same API to populate inventory details, parameters passed into the API are slightly different.
For the report “Inventory Value By Subinventory” the API is called like following
CST_Inventory_PUB.Calculate_InventoryValue( p_api_version => 1.0, p_init_msg_list => CST_Utility_PUB.get_true, p_organization_id => :P_ORG_ID, p_onhand_value => 1, p_intransit_value => 1, p_receiving_value => 0, p_valuation_date => to_date(:P_AS_OF_DATE,'YYYY/MM/DD HH24:MI:SS'), p_cost_type_id => :P_COST_TYPE_ID, p_item_from => :P_ITEM_FROM, p_item_to => :P_ITEM_TO, p_category_set_id => :P_CATEGORY_SET, p_category_from => :P_CAT_FROM, p_category_to => :P_CAT_TO, p_cost_group_from => NULL, p_cost_group_to => NULL, p_subinventory_from => :P_SUBINV_FROM, p_subinventory_to => :P_SUBINV_TO, p_qty_by_revision => :P_ITEM_REVISION, p_zero_cost_only => :P_ZERO_COST, p_zero_qty => :P_ZERO_QTY, p_expense_item => :P_EXP_ITEM, p_expense_sub => l_exp_sub, p_unvalued_txns => :P_UNCOSTED_TXN, p_receipt => 1, p_shipment => 1, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data );
Parameter “p_intransit_value => 1” makes the entire scenario different from “Transaction Historical Summary” as the inventory values are calculated against the quantities including the quantities in transit also. Further, for Average cost organizations, the report calculates the values against the current date item costs (We are trying to get an explanation for the same from multiple oracle communities, including communities.oracle.com)
Further, the rollback date column, unless entered as cutoff date 23:59:59 (eg: 31-dec-2012 23:59:59) always rolls back to 31-dec-2012 00:00:00, thus not picking up lines whichever were processed later for the entered date.
On the other hand, Transaction Historical Summary report calls the API like following
CST_Inventory_PUB.Calculate_InventoryValue( p_api_version => 1.0, p_init_msg_list => CST_Utility_PUB.get_true, p_organization_id => :P_org_id , p_onhand_value => 1, p_intransit_value => NULL, p_receiving_value => 0, p_valuation_date => l_hist_date, p_cost_type_id => NULL, p_item_from => :p_item_lo , p_item_to => :p_item_hi , p_category_set_id => :p_cat_set_id , p_category_from => :p_cat_lo, p_category_to => :p_cat_hi, p_cost_group_from => :p_cg_lo, p_cost_group_to => :p_cg_hi, p_subinventory_from => :p_subinv_lo, p_subinventory_to => :p_subinv_hi , p_qty_by_revision => NULL, p_zero_cost_only => NULL, p_zero_qty => NULL, p_expense_item => NULL, p_expense_sub => NULL, p_unvalued_txns => 0, p_receipt => NULL, p_shipment => NULL, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data );
Here the parameter “p_intransit_value => NULL” is set as NULL, thus the quantities in transit are not calculated. Further, the historical average costs are picked up for the transactions (material costs)
Further the rollback date is always expected to be entered like “31-dec-2012 23:59:59” in order to include the all the material transactions happened on the date.
So the in-transit quantity differences, item costs and the material transactions happened within the cutoff date time frame creates the variances what the user see with both the reports.
We had done the exercises more than few dozen times to reach to these unconfirmed conclusions. If as an experienced Oracle application user, dealing with Oracle inventory has any other explanations, Please, come ahead and we will amend the post with your valued inputs.
Requirement details: Oracle provides multiple standard reports to generate Inventories values on specified dates and depending upon the volume of transactions all these reports generate thousands of lines details to reach to such cut off date inventory values. Our requirement was to provide the auditors a quick view to inventory values as on end of each month, thus the entire development of below provided solution started.
How it works
Folder view supported form module developed by us calls a stored procedure, generates the rows into GLOBAL TEMPORARY tables and a stored function sum ups the material value and inserts into a local table (Base table with the form module)
For all the closed inventory periods, an insert statement picks up the values for the cut off dates from the view“cst_period_summary_v” and the months which are not already in the “cst_period_summary_v” view are populated by calling PVT APIs what we have heavily customized.
We achieved our goal by disabling the gather table statistics which are called from the PUBLIC API, then exclusively calling a COMMIT from the primary loop initiated by “populate history values” button press, thus indirectly flushing out the GLOBAL TEMPORARY TABLES for next run.
We hope this solution will be useful for organizations around the world who are running Oracle ERP 12.x.xx suites.
Oracle clearly states the API CST_Inventory_PUB is private and shouldn’t be called by the users exclusively from any other procedures or packages. Please refer to :“Using Oracle API CST_Inventory_PUB Package ID 847101.1]”
Hence you are going to use the solution provided by us at your own risk (Ironically, this PVT API is nothing more than few select statements based on different parameters passed in)
Here we are providing a solution to populate inventory values until “last month” by a mere mouse click
The entire solution could be downloaded from here