| Oracle® Retail Allocation Operations Guide Release 13.2.9 E72187-01 |
|
 Previous |
 Next |
This chapter discusses the various functional aspects of Oracle Retail Allocation. The chapter provides the following:
A functional overview of the system, along with its features and corresponding functional assumptions.
The sources of data used by rules to determine gross need.
A description of the four possible methods of closing allocations.
The functional features and assumptions discusses what Allocation does, item sources, and the assumptions that are made.
|
Note: Oracle Retail Allocation does not offer logic to support the following:
|
A good Allocation application enables retailers to make important decisions as close as possible to the time the product must be sent to the stores. A critical link in the supply chain process, the allocation process presents the final chance to distribute products successfully. The challenges facing retailers for allocating product is the same, whether they sell fashion items, groceries or hard lines. Merchants want an efficient, accurate method of translating their merchandise plans into store level allocations. Effectively allocating products is a critical step in product life cycle management and the last chance the retailer has to get the right product to the right location.
Oracle Retail Allocation enables retailers to take advantage of the most current, up-to-date sales and inventory information. The application also has the flexibility to allow allocations to be calculated months in advance for vendor commitment purposes.
Oracle Retail Allocation was designed to address the following challenges (among others) related to the correct allocation of product:
How to put many a variety of merchandise plans into action.
How to allocate product to support diverse marketing efforts and selling profiles.
How to effectively and accurately allocate product without increasing headcount while continuing to grow the business.
How to streamline the training process for allocators, due to position's high level of turnover.
If these challenges are not met, the wrong product can be sent to the wrong store in the incorrect quantity at the wrong time. The net result is higher markdowns and lower profits.
Oracle Retail Allocation allows multiple parameters to be selected when creating an allocation. The system determines store need based on metrics that fit the product, store characteristics and product life cycle. The result is allocations based on individual store need, the key to maximizing sales and profits.
In Oracle Retail Allocation, the retailer has the option of executing a plan, history or forecast at any level of the hierarchy. The retailer can allocate a collection of products using a class plan or allocate one item using its history. Oracle Retail Allocation has the functionality to create and reuse 'templates' to save time and produce consistent results.
Oracle Retail Allocation can react to current trends. The system has sophisticated rules that can compare current selling to a plan and create a forecast on which to base an allocation. Oracle Retail Allocation provides the ability to both allocate in advance to give vendor commitments and allocate at the last minute, utilizing up to date sales and inventory information to determine individual store need. Some key features of the application include:
Any PO that a user creates can be previewed through the front end.
In order to increase the efficiency of the allocations process, Oracle Retail Allocation has the ability to split allocations. By splitting an allocation, the user has the option of selecting the product hierarchy and location combinations that they would like to remove from the original allocation.
Oracle Retail Allocation can automatically respect the existence of an item location record in RMS. See the section, Location Exception Reason-product Sourced, in Backend System Administration and Configuration.
Item sources represent the physical inventory that Oracle Retail Allocation can allocate. The system allows the retailer to allocate based upon the following:
Advanced shipping notices (ASN) or Advanced Shipment Notifications (ASN) are batch communications that inform a retailer when to expect a certain quantity of order inventory. ASN quantities are received closer to the time of arrival at the distribution center. Allocations based upon ASN quantities allow retailers to account for purchase order shortages or overages as a part of their Oracle Retail Allocation process.
Because of these item sources, the user is given more access and control to existing transactions, which increases supply chain efficiencies. The benefit is found in that the next inventory movement can be communicated to the distribution center before the inventory arrives and is put on the shelf as warehouse stock.
The logic of Oracle Retail Allocation is based on establishing need at the item/location level. The user determines need by choosing a rule, rule modifiers and setting optional quantity limits. The system accesses gross need values provided. The application applies constraints to the data, such as on-hands and on-order, and determines the net need. At this point, the algorithm determines how to spread the available inventory across all of the locations' net need, and the allocation is created.
When attempting to allocate with a store which has a zero need, the system uses the sister-store data instead of allocating no product.
The sister_store_null setting in allocation.properties file allows the retailer to determine whether they want to use the sister store need whenever the need is calculated as zero or only when no need records exist for each location.
Oracle Retail Allocation retrieves most data in real-time from the Oracle Retail Merchandising System (RMS). Oracle Retail Allocation only has the need for visibility to approved items and purchase orders. See Functional and Technical Integration for integration information.
In sum, Oracle Retail Allocation determines the needs of each individual store at the item-location level through the following capabilities:
The application sorts through large quantities of data, such as sales history, current on-hands, and store volume groups.
The application applies user-established rules, rule modifiers, and optional quantity limits.
The application performs complex algorithms that can determine gross need for large volumes of stores and products, using real time data.
Presentation Minimums.
Due to the importance in balancing the need to maintain appropriate store presentation level and effectively allocate to stores' inventory needs, Oracle Retail Allocation can access item/location Plan O' Gram data and dictate to the algorithm the smallest amount to allocate a given item/location. If the user does not enter any quantity limits manually and selects the Default Auto Presentation Minimum and Quantity Limits check box in the GUI, the values from the repository are populated into the algorithm parameters behind the scenes. This functionality exists for all the valid quantity limits in allocation including minimum, maximum, threshold, trend, weeks of supply and minimum need. The defaults may be held at an item hierarchy level or the item level.
Net need is based upon the rule selected by the retailer less the stores future on hand. Gross need is based upon the rule selected by the retailer without any store stock on hand consideration. The addition of multi-level distribution allocations functionality, which extends the item lead time from its initial location to its destination location, leaves a calculation adjustment for the expected sales during the shipping time. This adjustment capability, 'lead time need,' is an option for the user. The addition of sales that occur during the shipping lead time for an item prevents the possibility of shorting high volume stores based on the sales that occur between the time the order was received and allocated and the time the order arrives at the stores.
Weight and Date User Selection
The premise of Oracle Retail Allocation is establishing need at the item/location level via rules and rule modifiers. There are seven different rule possibilities, and they are as follows:
Although these rules are detailed, the occasion arises where the user needs to base allocations upon like items. The User Merchandise Level Selection screen allows retailers to select any combination of like data on which to base allocations. The user may choose a merchandise hierarchy level, a combination of merchandise hierarchy levels, individual items or merchandise hierarchy levels combined with individual items. Each combination of data may be weighted. For example, an allocation may require the input of Subclass Z's sales history to be weighted at 50% and item A's sales history to be weighted at 75%. The values selected by the user are applied to each item on the allocation.
'What if' Supply Chain on Hand
A 'what if' source allows the user to create hypothetical allocations. 'What if' allocations provide users the flexibility of performing additional activities including defining optimal pre-pack configurations, and creating purchase orders based upon the allocation calculated quantities. The process is exactly the same as a regular allocation except that the user starts with an infinite available quantity of the selected product. To avoid the risk of warehouse imbalances or overstocking, 'what if' allocations have the ability to account for stock on hand in mid-tier warehouses that are in the supply chain for a given item/location. By providing visibility to warehouse inventory and including it in the 'what if need' calculation, locations in the MLD path are stocked more accurately.
In Oracle Retail Allocation, the user has the ability to allocate many items on a single allocation. This ability is dependent on what rules are utilized when gathering an item, or set of items' need values. The user has the ability to add quantities to existing POs from the front end screen dedicated to 'what if' summary data. Valid items to add to the PO must not previously exist on the PO. If the item already exists on the PO, the allocator should modify the quantities within the ordering dialogue.
The purchase order addition functionality is achieved by calling RMS Store Procedure which handles the PO Creation Request. The Oracle Retail Merchandising System owns this code and the standards it enforces regarding PO creation. The current API validation includes: location exists, item exists, supplier exists, item/supplier exists, item/supp/country exists, item is orderable and checks for dept_level_orders.
|
Note: The Oracle Retail Allocation, RMS, and RWMS interface is not capable of facilitating warehouse-to-warehouse inventory movements. |
Multi-level distribution is the ability to create an allocation that flows from one warehouse to another warehouse that is based on the store need. The aggregated store allocation may be viewed and edited at its associated warehouse. By enabling this functionality, the application allows inventory to flow through warehouse tiers until it arrives at its final store destination.
Many retailers import a portion of their inventory. Importing goods typically involves the arrival of an inbound purchase order at an import distribution center. Inventory then travels to a regional warehouse and finally to a store. This inventory flow is referred to as the 'MLD path'. Importing goods leads to a greater need for warehouse-to-warehouse allocations. Oracle Retail Allocation allows users to send allocation orders to RMS at two levels.
Next destination: The first level would be from the first level on the MLD path to the second level on the MLD path.
Stores: The second level would be from first level on the MLD path through all mid tier warehouses to the stores.
Users have the ability to edit values for the two approval levels. The approval options are limited when final quantities are edited by the user.
|
Note: Oracle Retail Allocation multi-level distribution allocations allow a single path to a store. This statement means that for a given merchandise hierarchy, each store may be sourced from a single warehouse. The product supports a 'V' at the top of the supply chain from one warehouse to another. The top level is defined based on the table records for an entire MLD path. It does not account for the path on an individual allocation item source level. The 'V' path functionality is intended to support multiple import warehouses that fulfill the same regional warehouses. The system does not support multiple supply chains at any other level. This statement means that within a hierarchy level, the retailer cannot have two paths to the same store. |
'What if' allocations are utilized by retailers to run a number of different allocation scenarios without being concerned about constrained inventory limitations. This allows retailers to have a preview of different allocation amounts based on a variety of calculations using history, plan, forecast, plan-reproject, history and plan, manual or corporate rule based allocations. Retailers may also use 'what if' allocations to determine optimal pre-packs for retailer brand goods. After the retailer has determined the best allocation scenarios, they can execute upon the 'what if' allocation results by creating an Oracle Retail Merchandising System purchase order from the What If Summary Screen.
The system's purchase order creation abilities include MLD PO creation, the inclusion or exclusion of supply chain stock on hand, as well as updating of existing purchase orders.
Expected Inventory for MLD 'what if' Allocations
Where an item source location is selected, the system can account for future fulfillment inventory as part of the MLD PO creation process. This functionality prevents retailers from ordering quantities that are greater than their required quantities by recognizing inventory amounts that are inbound to the distribution centers. Expected inventory amounts that are inbound to stores are accounted for by allocating to net need.
Oracle Retail Allocation includes possible data sources for the multi-level distribution (MLD) path.
MLD using the TRANSIT_TIMES table.
Retailers leverage the TRANSIT_TIMES table data that is maintained within RMS. This data exists at the department, class, or subclass level.
MLD using the ALC_SHIPPING_SCHEDULE table.
|
Note: The Oracle Retail enterprise does not support the population of the ALC_SHIPPING_SCHEDULE. This effort must be a part of the retailer's implementation of the application. |
The Oracle Retail Allocation-owned table, ALC_SHIPPING_SCHEDULE, allows the retailer to have a single view of a shipping schedule that is more detailed than the RMS-owned TRANSIT_TIMES table. This data exists at the department, class, subclass, or item level.
The Oracle Retail Allocation product houses a ALC_ITEM_SOURCE_SHIP_SCHEDULE table whereby MLD paths are stored for each item source of an allocation. The paths stored in this table are refreshed at calculation and approval time. If there is a path discrepancy between the path at calculation time and the path at approval time, the allocation is set to a status of 'Supply Chain Error'.
For more information about these data sources, see the section, Supply Chain Path Setting (distribution_level), in Backend System Administration and Configuration. Also see the Oracle Retail Allocation Data Model and the RMS Data Model.
When allocations are created, it is usually under the assumption that they follow their standard logistics path because this is the most cost effective way to ship product. However, there are instances where the established item/Store/WH relationship cannot fill allocated need.
For item-sourced allocations, the system takes the number of days that occurs between the release date to the arrival date and compares those days to the in-store date. The system marks the allocation as a rush allocation whether the items can arrive in time.
Oracle Retail Allocation provides visibility to an estimated cost based upon different freight date options (in store date - release date day = number of freight days, also known as lead time). The user has visibility to an estimated cost to meet the in-store-date. This is calculated based upon the weight of the goods. It allows the user to split the allocation based on the product source and location. This assists users in making an intelligent decision about an in-store date requirement based solely on the cost of freight.
The holdback quantity is the quantity that the user does not want to allocate. The holdback quantity is subtracted from the available quantity of each item to calculate the available percent to total quantity. The available percent of the total quantity is applied to the gross need to calculate the net need. The following example illustrates applying the holdback quantity to a sellable staple simple pack in cascade mode:
Table 4-2 Different Packs
| Pack | Description | Warehouse Quantity (Pack) | Holdback Qty | Net Available Warehouse Qty | Percent of total |
|---|---|---|---|---|---|
|
1 |
Hammer (5 units) |
500 |
75 |
425 |
425/900=47.2222% |
|
2 |
Screwdriver (10 units) |
350 |
75 |
225 |
225/900=25% |
|
3 |
Handsaw (15 units) |
250 |
0 |
250 |
250/900=27.7778% |
|
Total quantity on hand---------> |
1100 |
900 |
|||
For sellable packs, the transaction level is the sellable unit, hence sales history is recorded at the pack level as shown in the Dept Sales column of the table below. For sellable packs, the store owns the product at component level. When a pack is sold, the components are deducted from the stock on hand.
Table 4-3 Dept Sales and On Hands for Sellable Packs
|
Rule |
History |
||
|
Level |
Dept 1 |
||
|
Date Ranges |
Last 4 Weeks |
||
|
Available Quantity |
1500 |
||
|
RLOH |
n/a |
||
|
Store |
Pack |
Dept Sales |
On Hands |
|
999 |
1 |
3967 |
125 |
|
2 |
3967 |
140 | |
|
3 |
3967 |
130 | |
|
Dept Totals |
3967 |
||
Onhands for Sellable Packs are not recorded at pack level through RMS, only the pack components have onhands. Thus, onhands for sellable packs = 0. Since the final quantity is pack quantity, the calculations do not go through any pack optimization process in the calc engine.
The process of approving an allocation has been moved to an off line, queue based procedure. The functionality is consistent with the calculation process and allows the user to work on other allocations while one is being submitted, reserved or approved. In addition, the validation has been enhanced to ensure that all inventory quantities are up to date at the time approval occurs, including supply chain on hand and the item source quantities. This validation prevents the system from creating an allocation order against quantities that were available at the time of calculation but have since been claimed by another allocation or system.
This section covers assumptions made during MLD calculations, ASN-based allocations, item-location combination, presentation minimum repository, store calculation multiple, what-if allocations, lead time need, weight and date selection, rush flag and freight cost calculations, and proportional allocations.
Oracle Retail Allocation accounts for allocations where the same item is coming from two different item sources. Oracle Retail Allocation prioritizes the use of item sources based upon on the release date first and foremost. The system uses the earlier release date item sources first. It then uses inventory from a PO, ASN, TSF, BOL and WH stocked inventory.
An approval of an allocation results in data's being written to multiple RMS table records (ALLOC_HEADER and ALLOC_DETAIL tables) for a single allocation within Oracle Retail Allocation. The relationship is based on the item sources used on the allocation, mid tier inventory, and the MLD path for the level of the approval selected by the user.
MLD functionality allows any combination of location-to-location allocations, excluding store-to-store and store-to-warehouse allocations, as long as the supply chain path information exists. Need is always derived based upon the stores in the MLD path for the destination location.
MLD path information does not utilize data entered from a supplier to a store or warehouse. Any inventory originating with a supplier continues to be based upon the purchase order date.
Retailers are not able to edit allocations within the Oracle Retail Allocation application once any portion of the MLD allocation record is being processed by any of the distribution centers. Any edits at that time would need to be completed by stock order status messages from the distribution center.
Users may experience slow response from the application when using ALC_SHIPPING_SCHEDULE to maintain their supply chain and the system is generating release dates based upon 'in store' dates entered at the location level. Oracle Retail recommends that the retailer enter release dates to eliminate the system generation of release dates when using the shipping schedule.
International orders are created six to nine months ahead of the expected delivery date. If retailers want to utilize allocations to create international POs through the 'what if' capabilities, they must maintain the ALC_SHIPPING_SCHEDULE table path six to nine months in the future. Volume considerations may prohibit meeting performance standards based on the large volume of shipping schedule information and processing required to contain paths, six to nine months in advance.
Shipping schedules require that a store has a single path from the item source location. However, to account for the importing process the top tier in an MLD path may have two or more origin and destination records where the destination warehouses are the same. This multiplicity is only allowed at the top tier in an MLD path.
Valid shipping schedule information is required during the time period on the allocation for a retailer to load a previously created allocation successfully. If the retailer removes shipping schedule data for the date range of the allocation, the user is not be able to access the allocation. If a store is closed that was open when the allocation was originally created, the system allows the user to access the allocation, but it is set to a 'Not Calculated' status.
Oracle Retail Allocation item sources are not individually selectable. A previously generated allocation may be selected indirectly by being included in a BOL portion of inventory.
ASN, BOL and TSF sourced allocations are available for MLD and non MLD retailers. If a non MLD retailer is using the system, the alloc_header.alloc_parent value is never populated.
The ITEM_LOC table is where item location relationships are held and maintained from the Oracle Retail Merchandising System.
The ITEM_LOC table is where item location relationships are held and maintained from the Oracle Retail Merchandising System.
No user interface exists for the maintenance of the Presentation Minimums repository.
The system assumes that all of the items under a style have the same SOM as the style. In other words, the SOM cannot differ by item under a style.
The ability to calculate an allocation based upon one multiple and create a PO based upon another multiple may create a discrepancy between the total amount the allocation calculated initially, and the amount of inventory included in the purchase order.
The approach to respecting the break pack warehouse indicators assumes that users accept a warehouse level determination of the break pack level within the supply chain that spans merchandise hierarchy nodes.
This functionality enables the possibility of overage at the mid-tier warehouses. It does not validate against the stock holding indicator. Therefore, an allocation could be created where a non-stockholding DC would have an allocation order that is not 100% flow through.
Promotional buy rounding issue: The use of the order case size as the case multiple for PO sourced allocations creates a scenario where rounding at the inner causes packaging discrepancies. Note that when a purchase order is the source of an allocation, the suppliers case pack size may be different than the pack size defined in the RMS Item data model. Because the RMS Purchase Order front end does not hold a defined value for an inner size, the inner defined for the item may not evenly round into the case on the purchase order.
Respecting the break pack warehouse indicator for 'what if' allocation is not possible because there is no source destination until the moment of PO creation. The Store Calculation Multiple is the only enforceable number.
Front-end PO location selection only has an effect on the PO to location when the user is creating a PO with a PO type of warehouse or cross dock, or updating a PO with a PO type of warehouse. For all other types of PO actions, the value has no relevance.
The major assumption associated with this functional area is that basing the allocation amounts on future available supply chain on hand amounts assumes that the inventory that is expected within the supply chain warehouses arrives and that the business user creates a separate allocation to move the inventory to the stores. The records that Oracle Retail Allocation writes to ALLOC_HEADER and ALLOC_DETAIL does not include the future available inventory at the mid tier locations. Oracle Retail Allocation only writes records for inventory that is currently available in the mid tier warehouses. There is no way to determine the source of the expected inventory and write a cross-dock record for the mid tier expected inventory.
'What if' allocations utilize the primary supplier's primary origin countries' inner, case and pallet size only. If a retailer wants to use the dialogue to create a PO to a supplier that does not have the same multiple as the primary supplier, the functional recommendation is to calculate the allocation and create the order using an 'Each' multiple. The multiple can then be adjusted within the merchandising system.
Utilizing Oracle Retail Allocation is generally applicable to reactionary situations and is not intended to replace replenishment or advanced inventory replenishment functionality.
The shipping days used to determine lead time need are based upon the MLD path. It accounts for inbound processing days at mid tier warehouses.
Lead time need is not available for corporate or manual allocations. The lead time need related fields are removed from the Select Rules Screen when the user selects an allocation Rule of Corporate or Manual from the Rule list box.
The application is capable of accounting for lead time need in 'what if' allocations if they are utilizing in-store date functionality. If an in store date is not entered into the system, there is no logical time period to leverage.
The lead time need functionality uses regular and promotional sales as the history query criteria if the selections on the rules screen have led to the disabling of the check boxes.
The many-to-one functionality is available to users when using automatic rule types, except for corporate rules and manual.
The system allows the user to add the same item or merchandise hierarchy level twice. This is intentional because various weights may be applied. Users are responsible for adjusting the weight appropriately.
When a user changes the in store date, or adds/removes a date, the allocation should be re-calculated.
Release dates for PO sourced allocations are used within the PO creation logic. The in store date and release date do not take into account partial days. Same day delivery is a possibility.
No freight cost is calculated if the In Store Date is not specified.
No freight cost is calculated if the item on the allocation does not have a weight and weight unit of measure value in the ITEM_SUPP_COUNTRY_DIM table within RMS.
No rush flag is calculated if the 'in store date' is not specified.
Cost is always expressed in the system's primary currency.
The system assumes that a proportional allocation does not contain more than 10,000 units going to one store. The 10,000-unit value is a hard limit, and if exceeded, an infeasible solution arises in the system's algorithm. This pertains to MLD allocations and non-MLD allocations.
For both Simple and Cascade mode, the application should consider the threshold value as the first validation for allocating quantity to the store. This is irrespective of whether the MIN or MAX values are mentioned.
|
Note: If the "Need is" set to proportional, and the threshold value has been mentioned, allocation happens only if the store's net need is greater than the threshold value. If the store's net need is less than the threshold value the store is not allocated any quantity. After these validations occur, the allocation passes through the calc engine and the allocated quantity may be greater than the threshold value. |
Some of the constraints the user must follow while scheduling allocations are:
The parent/children relationship is one parent to many children of the same parent. The parent allocation cannot be a child allocation for another parent; or a parent allocation cannot be a parent to another parent allocation.
A parent allocation can only be deleted if all of the following is satisfied:
The current date is at least one day after the scheduled end date.
All child allocations of the parent must be closed or deleted.
If there is at least one child allocation that is not closed or deleted or if the end date is not met, the user cannot delete the parent allocation. The following error message is displayed "Allocation cannot be deleted until after the scheduled End Date and all its Child Allocation(s) are 'Deleted' and/or 'Closed'." In order to delete this parent, the user must go into the parent allocation to change the end date and also change the status of the child or children allocation(s) to 'deleted.'
It is recommended not to have more than 10 items in a scheduled allocation.
The child/children allocation(s) must be at the same MLD level as the parent allocation was created in. If the MLD level has changed by the scheduled run, an error message is displayed, and no child/children allocation(s) are created.
|
Note: If the retailer has scheduled allocations and decides to change the MLD environment midstream, the system does not generate the children allocations as the MLD level is now different than when it was scheduled. |
The user has to consider the following points while running the batch for scheduled allocations:
Batches can be run by external scheduling system such as APPWORX or simple UNIX CRON job.
If the server is down and restarted outside the client designated window, scheduled allocations for that day are not created.
The scheduling batch must be run after RMS updates the sales and onhand data.
There should be a two hour window in which the child allocations can be generated. The user has to define this two hour window and this is against the system (server) date and timestamp which would apply to all users regardless of time zone.
Whatever may be the status of the parent allocation, the batch process runs if the parent allocation has to generate a child allocation on that day. Despite having a status of 'Schedule Error' the parent allocation runs because the error may have occurred in the past (when the previous batch was run), and that situation may not be applicable for subsequent batches. The error may have occurred because of insufficient inventory but by the next batch run, the warehouse may have received additional goods to meet inventory criteria so the previous error is no longer valid.
If the user tries to run the batch process a second time on the same day since the user had deleted the earlier created child allocation, the batch process does not pick up the parent allocation, and create the second child. The user has to either manually create an allocation or wait for the next scheduled batch run.
To run the scheduler, ALC_BATCH_CONTROL table should have User Name and password of the default user ('default_user' property value) mentioned in the allocation.properties file, as USER_ID and PASSWORD. If not, the following insert query need to be run after deleting the existing record(s) if any:
delete from ALC_BATCH_CONTROL;insert into ALC_BATCH_CONTROL (batch_identifier, user_id, password, max_thread_limit) select 'com..alloc.business.scheduler.AllocationAutoScheduleBatch', a.user_name, a.user_password,1 from alc_users a where a.user_id=<< 'default_user' value from properties file >>.
|
Note: It is mandatory that the USER_ID is maintained in UPPERCASE in the ALC_BATCH_CONTROL table. |
Children allocations are not created if the parent allocation has errors. The child allocation is not created for the parent allocation, if the following validations fail:
At least one Item has a valid item/store association. For example: If two items and two stores are selected in the Parent Allocation, then at least one item should have association with at least one store.
At least one store is not closed and has a valid Warehouse-Store relationship when "Enforce WH-Store relationship or Enforce Supply Chain" check box is selected.
If the Parent Allocation contains fashion items, then all the fashion items should have Size Profile information available for all the stores if the 'Enable Size Profile' = True in the Properties File.
If at least one item has the warehouse available quantity greater than the minimum available quantity specified on the "Item Review" screen of the application, the child allocation is created with the status as 'Submitted'. This status overrides the status specified by the user. If all items do not have the warehouse available quantity greater than the minimum available quantity, then no child allocation is created for that parent on that day. The Allocation Home page displays the status of the parent allocation as 'Schedule Error'.
Significant functionality is attached to the status numbers in the system. The tables below reflect the status column on the ALC_ALLOC table.
Table 4-5 Visible through the User Interface
| Status | Description | Status # |
|---|---|---|
| Worksheet | This allocation is in the initial stages of creation or it is being updated by the user. | 0 |
| Submitted | This allocation has been submitted successfully. | 1 |
| Approved | This allocation has been approved successfully. The allocation records have been sent to the merchandising system. | 2 |
| Processed | The warehouse system has started executing this allocation. The allocation cannot be updated. | 3 |
| Closed | The allocation has been executed by the warehouse. The inventory movement is complete. | 4 |
| Cancelled | This allocation has been cancelled by an external system. The allocation cannot be updated. | 5 |
| Reserved | This allocation has been reserved successfully. The allocation records have been sent to the merchandising system. | 6 |
| PO Created | This status exists for 'what if' allocations only. A purchase order has been created within this 'what if' allocation. The user cannot edit anything within the allocation except creating or updating additional purchase orders within the front end screen that holds 'what if' summary data. | 10 |
|
Scheduled |
This allocation is scheduled. This status is not dependant on whether the parent allocation is successfully validated or not. It is a static field and does not get updated. Child allocations display the status selected in the Auto Schedule screen of the parent allocation. |
11 |
Table 4-6 Not Visible through the GUI
| Status | Description | Status # |
|---|---|---|
| Deleted | Allocations have been set to be deleted from the allocation application tables by the user selecting the 'Delete' button in the within the front end screen that holds 'what if' summary data. The next time the allocation deletion logic is run, the record is removed from the tables. | 7 |
| Approval In Process | This status is used when the system is writing an approval request to the queue. | 8 |
| Reservation In Process | This status is used when the system is writing a reservation request to the queue. | 9 |
Significant functionality is attached to the status numbers in the system. The tables below reflect the process_status column on the ALC_ALLOC table.
Table 4-7 Process Status Column
| Status | Description | Status # |
|---|---|---|
| Not Calculated | This allocation has not been calculated. | 1 |
| Calculation Waiting | The allocation is waiting to be processed by the algorithm. The user cannot enter an allocation with this status. | 2 |
| Calculating | The system is in the process of calculating this allocation. The user cannot enter an allocation with this status. | 3 |
| Calculated | This allocation has been calculated successfully. | 4 |
| Calculate Later | This allocation is calculated during a scheduled batch run based on each retailer's timeline requirements. The value is accessible to users and they may change the allocation to calculate real time. | 5 |
| Calculation Error | An error was encountered during calculation. | 6 |
| Size Profile Calculation Error | The size profile was not found for all style/color combinations on the allocation. Users must adjust their size profiles and recalculate the allocation. | 7 |
| Ideal Weeks of Supply (IWOS) Calculation Error | This error occurs if the cascade allocation weeks of supply data are not sufficient for the algorithm requirements for calculation. | 8 |
| Quantity Limits Conflict | This error occurs if quantity limits are defined for a pack and non sellable pack containing the same item. The system requires the user to resolve the conflict manually. | 9 |
| Status Error | The system encountered an error when submitting, reserving or approving this allocation. | 10 |
| Status Waiting | The system is in the process of submitting, reserving or approving this allocation. The user cannot enter an allocation with this status | 11 |
| Status Processing | The system is in the process of submitting, reserving or approving the allocation. The user cannot enter an allocation with this status | 12 |
| Status Processed | The allocation has been approved, reserved or submitted successfully. | 13 |
| Available Inventory Error | This error occurs if the inventory quantities that the allocation was based upon has increased or decreased by another part of the system since the time of calculation. The user must recalculate and approve based on the current inventory. | 14 |
| Next Destination Error | This error occurs when the user has edited allocations amounts at the store level and selected 'Approved to Next Destination' as the status selection. The error is received if the quantity of inventory being sent to the stores is entirely fulfilled by the mid tier warehouses. This means there is no quantity to approve to the next destination level, and the error is received. Users should select 'Approved to Stores' as their approval level or adjust the allocation quantities. | 15 |
| Supply Chain Error | This error occurs if the original path built at calculation time is no longer valid at approval time. The validity of the path is determined by whether or not the locations of the path are still valid, not whether the dates of the path have changed. An error occurs if a path to the warehouses or stores that existed during the original calculation is no longer found. The user must recalculate and approve based on the new path. Locations without paths are noted as item location exceptions. | 16 |
|
Item Source Conflict |
This error occurs if an allocation is created using a purchase order in one allocation, and then a user attempts to create another allocation using an associated advance shipping notice (ASN). Once the purchase order allocation is approved, entering the ASN allocation prompts a question to the user stating that he or she must delete any associated purchase order allocations to continue using the ASN allocation. If the user selects ’Cancel', the ASN allocation is set to this new status, ’Item Source Conflict.' The allocation is then ’locked down' until either the user deletes the purchase order allocation or deletes the ASN allocation. |
17 |
|
Scheduled |
This scheduled allocation has been created successfully. |
18 |
|
Schedule Error |
This error occurs if there are one or more errors that when scheduled allocation was created. |
19 |
Gross Need is the need of the rule level selected. To accurately determine individual store gross need, retailers want the flexibility to choose forecast data, plan data, sales history data, or combinations of this data.
Through the front end, retailers select a rule based on a portion of this data that accurately gathers gross need. The source of the data used by each rule is illuminated in this section.
To determine the net need at the store level, the system takes the gross need and subtracts from it the stock-on-hand at the store level. The equation that Oracle Retail Allocation uses to determine the stock-on-hand at the store is described later in this chapter.
|
Note: For a description of how the following rules use the data to determine gross need, see the Oracle Retail Allocation User Guide. |
Through the front end, retailers can view the lowest merchandise hierarchy data available for the plan or forecast.
|
Note: If the lowest merch hierarchy data available is at SKU level, but the Rule parameters are Plan/Subclass, the Gross Need reflects the plan data at subclass level while the new metrics displays plan data at SKU level. |
For this rule, data is gathered primarily from the following tables:
Table 4-8 Data Tables (History Sources)
| RMS 13.0.1 | Legacy System |
|---|---|
| DEPT_SALES_HIST | This table contains one row for each dept-location-week-sales type combination. Sales history, forecast and plan information about each combination is held. |
| CLASS_SALES_HIST | This table contains one row for each class-location-week-sales type combination. Sales history, forecast and plan information about each combination is held. |
| SUBCLASS_SALES_HIST | This table contains one row for each subclass-location-week-sales type combination. Sales history, forecast and plan information about each combination is held. |
| ITEM_LOC_HIST | This table contains one row for each item-location-week-sales type combination. Sales history, forecast and plan information about each combination may be held here. |
For this rule, data is gathered from the following tables:
Table 4-9 Data Table (Forecast Data Sources)
| RMS 13.0.1 | Legacy System |
|---|---|
| DEPT_SALES_FORECAST | This table holds the forecast information summed to the department-location-eow_date. |
| CLASS_SALES_FORECAST | This table holds the forecast information summed to the class-location-eow_date and should be partitioned by domain_id, as well. Thus, if only a portion of the domains is forecasted, then the rebuild is done by domain_id. |
| SUBCLASS_SALES_FORECAST | This table holds the forecast information summed to the subclass-location-eow_date and should be partitioned by domain, as well. Thus, if only a portion of the domains is forecasted, then the rebuild is done by domain_id. |
| ITEM_FORECAST | This table holds the item level forecasted information from the RDF extractions. This table holds all item types. This table should be partitioned according to the domain level. |
For this rule, data is gathered from the following table:
ALC_PLAN
For a more detailed description of this table, see the section, Planning Table in Oracle Retail Allocation, in Functional and Technical Integration.
For this rule, the plan portion of data is gathered from the following plan table in Oracle Retail Allocation:
ALC_PLAN
The history portion of data is gathered from the following tables:
Table 4-10 Data Table (History and Plan Data Source)
| RMS 13.0.1 | Legacy System |
|---|---|
| DEPT_SALES_HIST | This table contains one row for each dept-location-week-sales type combination. Sales history, forecast, and plan information about each combination is held. |
| CLASS_SALES_HIST | This table contains one row for each class-location-week-sales type combination. Sales history, forecast, and plan information about each combination is held. |
| SUBCLASS_SALES_HIST | This table contains one row for each subclass-location-week-sales type combination. Sales history, forecast, and plan information about each combination is held. |
| ITEM_LOC_HIST | This table contains one row for each item-location-week-sales type combination. Sales history, forecast, and plan information about each combination may be held here. |
|
Note: For a description of the Bayesian algorithm that is used in this section, see Allocation Calculations. |
For this rule, the historical and future plan data is gathered from the following table in Oracle Retail Allocation:
ALC_PLAN
The history portion of data is gathered from the following tables:
Table 4-11 Data table (History Source)
| RMS 13.0.1 | Legacy System |
|---|---|
| DEPT_SALES_HIST | This table contains one row for each dept-location-week-sales type combination. Sales history, forecast, and plan information about each combination is held. |
| CLASS_SALES_HIST | This table contains one row for each class-location-week-sales type combination. Sales history, forecast, and plan information about each combination is held. |
| SUBCLASS_SALES_HIST | This table contains one row for each subclass-location-week-sales type combination. Sales history, forecast, and plan information about each combination is held. |
| ITEM_LOC_HIST | This table contains one row for each item-location-week-sales type combination. Sales history, forecast, and plan information about each combination may be held here. |
For this rule, data is gathered from the selected column of the following tables in Oracle Retail Allocation:
ALC_CORPORATE_RULE_HEAD
ALC_CORPORATE_RULE_DETAIL
The column selection is based on which corporate rule is picked by the user.
|
Note: If the retailer plans ideal weeks of supply (IWOS) by product-location, the corporate table can be accessed to create different ideal weeks of supply by store. If the retailer does not plan IWOS, a field can be created that contains the same IWOS for every store. |
Quantity Limits allows the user to limit the allocation. This feature allows the user to set parameters which affect different stages of the allocation for the product-stores where they are entered. The values for each applicable quantity limits selection are held on the applicable column of the ALC_QUANTITY_LIMITS table.
Using Quantity Limits, the value that gets allocated can be altered according to the user's preference. There are six constraints for quantity limits: Min, Max, Threshold, Week Of Supply (WOS), Trend, and Min Need.
For example, if the user wants to allocate at least 100 units of merchandise irrespective of the need, a minimum constraint of 100 can be applied. In this case, 100 units gets allocated (if there is enough inventory to support it). Though the quantity limit gets accounted at the lowest level entity i.e. item/store combination, the retailer can also supply the quantity limits values at a higher level such as Group of stores.
In addition to grouping at the location level, there is another aggregator for item level in cascade mode which is the (merchandise) level at which the calculation is sought. Thus the user can enter quantity limits in four different places (screens) in cascade mode:
Item/Store
Item/Group
Level/Store
Level/Group
Quantity Limits should work in the same manner for staple items, sellable and non-sellable staple packs since all these types of items/packs inventory are maintained at the same unit (item or pack) that gets allocated. For fashion items, though the inventory is maintained at the SKU level, allocation occurs for the Style/Color. However, you may choose to de-aggregate the Style/Color within allocation and distribute only those sizes/components which are available to allocate.
A 'stop ship' is a product/location combination that prevents an item from shipping to that location. The system looks at the release dates entered on the product window and compares them with stop ship records entered via the merchandising system. If the release date is on or between the stop ship dates, the system inserts '0' into the min and max columns of quantity limits for this store-item. Stop shipment records appear as item location exceptions.
The release date is on the ALC_ITEM_LOC table and is represented by the column, release_date. The STOP_SHIP table contains the stop ship date range: start_date and end_date. In order for a stop ship record to stop shipment of an allocation, the store, department, class, and subclass of the allocated item must match the store, department, class, and subclass on the stop_ship record, or the store and style (for fashion) or item (for staple) of the item being allocated must match the store and item_id on the STOP_SHIP table. See the Oracle Retail Allocation User Guide for more information.
On a fundamental level, net need is gross need minus the on-hand at the store.
|
Note: Although quantity limits also effect net need, they are not addressed in the calculation illustrated by this passage. |
To determine the gross need, Oracle Retail Allocation gathers the information based upon one of the rules selected by the retailer through the front end. Oracle Retail Allocation uses the following equation to determine the on-hand at the store that is subtracted from the gross need result.
Stock-on-hand at the store+ Stock in transit+ Stock on order [stock that is expected by the on order commit date]+ Transfers of stock expected+ Stock on allocation
Outgoing transfers + Return to vendor stock+ Unavailable stock+ Transfers on reserve
An abbreviated version of this equation would be the following:
(SOH +InTransit+OnOrder+TSF Expected+OnAlloc) -
(TSFOut+RTV+Unavailable+TSF Reserved)
This section addresses the three possible methods of closing allocations. Note that the closure of the allocation in Oracle Retail Allocation entails 'all or nothing' processing logic.
Oracle Retail Allocation and RMS in the context of the three methods of allocation closures:
Warehouse and Store initiated Closures: The majority of RMS allocation records should be closed as part of the retailer's Warehouse Management system and the retailer's Store Inventory Management system integration with RMS.
For purchase orders closed via batch functionality: RMS allocation records attached to these closed purchase orders are closed, if the allocation meets RMS validations. RMS cancels the associated quantities on the RMS allocation records and closes the RMS allocation records. All the quantities remaining for related RMS allocation records are cancelled, and the RMS allocation records are closed if no quantities are in transit. If the RMS allocation records cannot be closed, there is no further action.
For purchase orders closed manually online: If RMS allocation records exist when the user attempts to either cancel an item or cancel all items, a message offers the user an option to cancel the associated RMS allocation records or not. If the user selects to close the allocations, all the quantities remaining for related RMS allocation records are cancelled, and the RMS allocation records are closed if no quantities are in transit. If the user selects to not close the allocations, there is no further action.
|
Note: The Oracle Retail Allocation application is updated through the table triggers when actions occur on RMS allocation records. |
