SOH Incorrectly Updated During Stock Count if Original SOH Quantity Has 4 Decimal Places
Last updated on JULY 18, 2017
Applies to:Oracle Retail Store Inventory Management - Version 15.0 and later
Information in this document applies to any platform.
When a stock count is done using an item whose current stock on hand has 4 decimal places. The SOH is incorrectly updated because it uses the difference between snapshot and counted quantity with 3 decimal places only. This issue happens on both types of stock counts (Unit and Unit&Amount) but is more problematic on Unit&Amount because it creates SOH discrepancies between RMS and SIM of 0.0001~0.0009.
Steps To Recreate:
- Create a stock count using items with current SOH containing 4 decimal places.
- Take the snapshot.
- Notice that the ‘count_snapshot’ value inserted on ‘stock_count_line_item’ has 4 decimal places
- Insert the ‘counted quantity’ and save it. Notice that, aside from inserting the ‘counted_quantity’ on
- ‘stock_count_line_item’, the ‘count_snapshot’ value previously inserted with 4 decimal places is now updated to 3 decimal places.
- Complete the stock count.
- Insert and confirm authorization values.
- Notice the ‘approved_quantity’ only has 3 decimal places but the actual value on ‘store_item_stock’ has 4 decimal points , because a calculated difference of 3 decimal points was applied to an original value with 4 decimal points .
- The expected result would be either one of the following:
- Apply the ‘approved_quantity’ with 3 decimal points to store_item_stock without leaving a 4 decimal points on SIM SOH values.
- During stock count always work with 4 decimal points and not round it to 3 decimal points .
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms