Oracle Retail Allocation Operations Guide Addendum Release 10.0.16 November 2006
Oracle Retail Allocation Operations Guide Addendum, Release 10.0.16 Copyright 2006, Oracle. All rights reserved. Primary Author: Ramsankar Sundaram Contributors: Usha Raj The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited. The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose. If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agencyspecific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065 The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs. Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, thirdparty Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.
Contents Preface... v Audience...v Related Documents...v Customer Support...v 1 Approval/Calculation... 1 Overview...1 Detailed Discussion...1 Configurable Calculation Queues...1 New Calculation Statuses in Approval Process...1 Validation for Approval in Allocation 10.0.x...2 Specific Validation Types...2 Functional Changes in Calculation...3 Impact Analysis...5 Allocation Summary...5 Approval...5 Data Model Change...5 2 Algorithm... 7 Overview...7 Analysis...7 Testing Problem Differences...7 Algorithm Differences...7 Focusing the Four Stores in Question...8 Solution...8 iii
Preface Oracle Retail Operations Guides are designed so that you can view and understand the application s behind-the-scenes processing, including such information as the following: Key system administration configuration settings Technical architecture Functional integration dataflow across the enterprise Audience Anyone with an interest in developing a deeper understanding of the underlying processes and architecture supporting Oracle Retail Allocation functionality will find valuable information in this guide. There are three audiences in general for whom this guide is written: Business analysts looking for information about processes and interfaces to validate the support for business scenarios within Allocation and other systems across the enterprise. Related Documents Customer Support System analysts and system operations personnel: Who are looking for information about Allocation s processes internally or in relation to the systems across the enterprise. Who operate Allocation regularly. Integrators and implementation staff with overall responsibility for implementing Allocation. For more information, see the following documents in the Oracle Retail Allocation Release 10.0.16 documentation set: Oracle Retail Allocation Release Notes Oracle Retail Allocation Installation Guide https://metalink.oracle.com When contacting Customer Support, please provide: Product version and program/module name. Functional and technical description of the problem (include business impact). Detailed step-by-step instructions to recreate. Exact error message received. v
1 Approval/Calculation This chapter provides an overview of Approval & Calculation functionality of Oracle Retail Allocation. Overview The approval process in Allocation is now an offline process like Calculation. Instead of immediately approving/reserving an allocation when a user changes the status in the Alloc Summary page, now the approval/reserve request is submitted to the Calculation Queue after saving the allocation in the Alloc Summary page. The Calculation Queue then picks up the queue item and the status is then processed. Various functional changes in the Calculation process are also described in this document. Detailed Discussion Configurable Calculation Queues In order to take the approval process offline, the Calculation Queue was changed to support multiple administrator-defined queue types with a single queue. One queue can now perform standard calculations, pre-pack calculations, recalculation, and approval all while using the same queue processes. Conversely, approvals and standard calculations can now run on different queue processes. As per previous versions of the queue, batching and the ability to assign a name to a queue and have multiple queues running at the same time remains. The following parameters are now used when starting the Calculation Queue: approval, standard_calculation, prepack, and recalculation. For example, the following would start a Calculation Queue that processes all calculation types supported: queue_10.bat start <queue_name> -standard_calculation approval prepack recalculation New Calculation Statuses in Approval Process The new approval process runs in the background. The various statuses of the approval process are: 1. Status Waiting Calculation Status = Status Waiting, Allocation Status = Approved. This status indicates that the approval process is in the queue. The actual approval process has not started and no records can be found in the database. The user will not be allowed to enter the allocation summary. 2. Status Processing Calculation Status = Status Processing, Allocation Status = Approved. This status indicates that the queue has picked the allocation for approval and is still processing it. The user will not be allowed to enter the allocation summary. 1
Detailed Discussion 3. Status Processed Calculation Status = Status Processed, Allocation Status = Approved. This status indicates that the approval process has been completed successfully. The Allocation-Xref-RMS records will be available. The user is allowed to enter into the allocation summary for any updates. 4. Status Error Calculation Status = Status Error, Allocation Status = Worksheet. The status reports, that an error has occurred while processing the allocation for approval. The error could be due to any validation failure or any other system failure. The error can be determined in the log files present in the system. Validation for Approval in Allocation 10.0.x Specific Validation Types This document describes the validation that is performed during the approval process in Allocation 10.0.x. Validation is performed when an allocation is submitted to the calculation queue and once again during the actual approval process. If validation fails during submission in the Allocation summary page, the user will receive a popup message with a specific message. If validation fails during the actual approval process in the calculation queue, a detailed message is logged and the user will see the following generic approval failed message when that allocation is opened. An error occurred while approving your allocation. Contact your system administrator for details. Message bundle key: AllocSummary.approve_failed Find below the specific validation types that are performed: 1. Release Date Before the Current Date This validation type, validates the release dates of the item sources that are greater than the current date. If the release date of any one of the item source in the location falls before the current date (today s date), then processing is stopped and the following message is popped up or logged: Release date should be equal or after today s date. Message bundle key: ProdDetailsView.releaseDate_before_CurrentDate 2. Release Date Before the PO s Not Before Date Validates that release dates that are greater than the not before date of the PO. If the release date is before the not before date then the following message is logged/displayed: The PO Not Before Date, {0}, is after the Release Date, {1}. Message bundle key: ProdDetailsView.releaseDate_before_PONotBeforeDate 2 Oracle Retail Allocation
Detailed Discussion 3. PO Available Quantity Validation Validates against Orders for available quantity. If available quantity is 0 (if the PO has been exhausted by some other approved allocation) processing is stopped and the following message is logged/displayed: This Allocation contains a PO based Item Source. This item is with either zero available quantity or available quantity less than the allocated quantity or both. Remove the Item Source or recalculate and approve. Message bundle key: AllocSummary.invalidPO 4. Warehouse Available Quantity Validation This validation type validates against the Warehouse for available quantity. If available quantity is 0, then the processing is stopped and the following message is logged/displayed: This Allocation contains an item with either zero available quantity or available quantity less than allocated quantity or both. Remove the Item Source or recalculate and approve. Message bundle key: AllocSummary.invalidWH 5. Invalid Item Location Validation Validates locations that are in a valid status (not C, I or D), and that the store is open by verifying that the current and release dates are greater than the store close date. If any invalid item location is found, then the processing will be stopped and the following is logged/displayed: Status cannot be changed until all invalid item/locations are resolved. Click OK to view the invalid item/locations. Message bundle key: AllocSummary.invalid_item_locs Functional Changes in Calculation Quantity Limits effects when item sourced from multiple warehouse and store enforce flag = N with one or more stores. When creating an allocation the user has the ability to set the sum(min) value for an item in the Quantity Limits page be less than or equal to the total available quantity for the item. In multiple warehouse scenarios the total available qty = sum of the available quantity from all warehouses for the item. In that case, the total available quantity can be greater than the available quantity in the individual warehouses. Calculation is performed for an item per warehouse wise. Setting up total min > available quantity will lead to no store getting any allocated quantity. In such a scenario the system will now reduce the min value according to the available quantity at that particular warehouse. By doing this, the stores will get allocated. Approval/Calculation 3
Detailed Discussion Manual Rule will have a new default parameter setup. This is put in place so when the allocation is changed from non-manual Rule setup to a Manual Rule the old setup does not remain. This causes a problem for Fashion item sources where Recalculation needs to occur when final quantity is changed. The default parameter setup is: ruletype = Rule.TYPE_MANUAL; rulelevel= null; exactind = "Y"; cascadeind = "N"; netneedind = "Y"; userulelevelonhandind = "N"; includeclearancestockind = "N"; regularsalesind = "N"; promosalesind = "N"; clearancesalesind = "N"; includeinvinminind = "Y"; includeinvinmaxind = "Y"; fromdate = null; todate = null; fromdate2 = null; todate2 = null; onordercommitdate = null; wksfromtoday; templateid=null; corporateruleid; thisyear = -1; lastyear = -1; Manual rule will display the net need for an allocation 0 even if there is stock on hand available for an item. The following changes were made: The need for the store in the allocation will be replaced by the need of the sister store, if the store in the allocation has no need (ignoring when need=0 or negative) for the particular EOW_DATE. The net need value for an item in What-If and Cascade Mode will bear an * in allocation summary and view details. When doing a Cascade Allocation with RLOH = Y and Net Need = Y, the Gross Need will include the RLOH in the calculation. The gross need for individual item in the allocation in Cascade mode is calculated based on the formula: [[(Store Allocated Qty + CascadeStoreOnHand) * (Available quantity for item + skuonhandatallstore)] / (TotalOnHand + TotalAvailable) ] * storesum 4 Oracle Retail Allocation
Impact Analysis Impact Analysis Allocation Summary Store allocated Qty = Quantity allocated in first pass at hierarchy level CascadeStoreOnHand = SOH for all items in allocation in the store Available quantity for item = Actual available quantity for the item skuonhandatallstore = Total on Hand for the item in all the store in allocation. TotalOnHand = Total On Hand for all the items in allocation TotalAvailable = Total Available for all the items in allocation Storesum = 1 if calculated value > 0 else -1 Allocation Summary and Approval are impacted by these changes. Allocations will no longer be immediately approved when the status is set to Approved. When the allocation is saved on the Allocation Summary screen, the application will submit a status change request to the calculation queue. Approval After submitting an allocation for Approval, the user will be taken to the portal screen and the allocation will not be accessible until the status is processed by the calculation queue. Data Model Change None. Approval/Calculation 5
2 Algorithm Overview Analysis This chapter describes the difference between the documented rounding example in the previous operations guide and how the algorithm actually works till 10.0.15. Following are the two differences in the documented and production algorithm as well as in problem setup, which explain the different results. Testing Problem Differences Algorithm Differences The test problem (SKU 6404123 Constrained analysis) and the documented sample problem is not the same set up which triggers different run path within the allocation algorithm. SOM = 1 in the documented problem while SOM = 4 in the test problem. What that means is that we allocate SKU s in the sample problem and item pack of size 4 in the test problem. For the test problem, the first step of the allocation algorithm is to convert on hand and desired stock that is in SKU s to item packs. E.g., OH of 6 SKU s is converted to OH of 1.5 packs and desired stock of 11.48 SKU s is converted to desired stock of 2.97 packs. The algorithm described in previous operations guide is meant to illustrate the idea of the allocation algorithm, it is NOT the same with the allocation algorithm that are put in production (production algorithm). For numerical, stability and business reasons, the production allocation algorithm rounds the desired stock so that the difference between desired stock and on hand is an integer. E.g., with original OH of 1.5 packs and desired stock of 2.87 packs, we have a need-toship of 2.87 1.5 = 1.37 packs which is not integer. To make it integer, we round the desired from 2.87 to 2.5 which give us need-to-ship of 1 pack. An internal cutoff parameter (currently hard coded to 50%) is used to control when to round up and when to round down. When we have a residual that is more or equal to the cutoff percent of a SKU (pack), we round up. E.x., for a 50% cutoff percentage, the need-to-ship of 1.37 packs has a residual of 37% of a pack, so it is rounded down to 1 pack, and a need-to-ship of 1.51 packs is rounded up to 2 packs because of the 51% residual pack. This massage of the desired stock is insignificant when the numbers of OH and desired stock are big enough, but not in the test problem when OH and desired stock are small numbers like 0.75 and 1.38. Algorithm 7
Solution Focusing the Four Stores in Question The following table illustrates as to whythe store 761 and 586 got allocated rather than the store 580 and 784. In the first scenario where SOM = 1, store 580 and 784 has low DSR s. But in the second scenario where SOM = 4, the converting and rounding described in the previous two sections skewed the low DSR to store 761 and 586. Store # 580 784 761 586 OH ( on hand ) 6 6 3 4 Desired Stock 11.4814 11.4814 5.5461 7.0056 DSR (OH/Desired Stock) 0.522584 0.522584 0.540921 0.570972 DSR RANK 1 1 3 4 OH' (OH / SOM) 1.5 1.5 0.75 1 Desired Stock' (Desired Stock / SOM) 2.87035 2.87035 1.386525 1.7514 Need' (Desired Stock OH ) 1.37035 1.37035 0.636525 0.7514 Rounded Need' ( 50% cutoff ) 1 1 1 1 Rounded Desired Stock' (OH + Rounded Need ) 2.5 2.5 1.75 2 DSR' 0.6 0.6 0.428571 0.5 DSR RANK 3 3 1 2 Solution In the dealing phase, after we have already allocated the truncated SKUs (item packs), we use TSR [truncated stock target ratio = (on hand + truncated ship) / rounded desired stock] to guide the allocation of truncated SKU s (item packs) to stores. To honor the original stock target ratio, we could use original desired stock in the TSR calculation. This change will produce desired allocation to store 761 and 586 in the testing problem. This option has been implemented and put in production code as a bug fix. 8 Oracle Retail Allocation