| Oracle® Retail Allocation Operations Guide Release 14.1 E57847-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 three possible methods of closing allocations.
This section covers what Allocation does, item sources, and the functional assumptions that are made during ASN-based allocations, item-location combination, store calculation multiple, what-if allocations, weight and date selection, and proportional allocations.
|
Note: Oracle Retail Allocation does not offer logic to support the following:
|
An Allocation application should enable 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 has been designed to address the following challenges (among others) related to the correct allocation of product:
How to put a variety of merchandise plans into action.
How to allocate products to support diverse marketing efforts and selling profiles.
How to effectively and accurately allocate products without increasing headcount while continuing to grow the business.
How to streamline the training process for allocators.
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 sales plan, receipt 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 the user would like to remove from the original allocation.
Oracle Retail Allocation can automatically respect the existence of an item location record in RMS.
The user is allowed to copy an existing allocation, resulting in the creation of a new one with the same item/location combinations and other parameters as the source.
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.
Approved allocations to a warehouse
The user is given more access to and control of existing transactions because of these item sources, which increases supply chain efficiencies. As a result, 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 and rule modifiers and then 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 net needs for each location, and the allocation is created.
When attempting to allocate with a store that has a zero need, the system uses the sister-store data instead of allocating no product. The Sister Store Setup system option setting file allows the retailer to determine whether 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 requires visibility to approved items and purchase orders and transfers. 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-hand, and store volume groups.
The application applies user-established rules, rule modifiers, and optional quantity limits.
The application utilizes complex algorithms that can determine gross need for large volumes of stores and products, using real time data.
Presentation Minimums at the item location level can be respected.
Due to the importance of balancing the need to maintain appropriate store presentation level and effectively allocate to stores' inventory needs, Oracle Retail Allocation can access item/location planogram data and dictate to the algorithm the smallest amount to allocate a given item/location.
Weight and Date User Selection
|
Note: In the Allocation application and in this document, the terms 'rules' and 'policies' are used interchangeably. |
The premise of Oracle Retail Allocation is to establish need at the item/location level via policies and policy modifiers. The following eight different rules are available:
Although these rules are detailed, occasionally 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.
The 'what if' source allows the user to create hypothetical allocations. 'What if' allocations provide users the flexibility to create 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 number of the selected product.
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 purchase orders (POs) from the front end screen dedicated to 'what if' summary data. Valid items added 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 window.
The purchase order addition functionality is achieved by calling an RMS stored procedure that 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 which is a system option in RMS.
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 spread demand mode:
Table 3-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 |
275 |
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, so 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 3-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 |
||
On hand for Sellable Packs are not recorded at the pack level through RMS, only the pack components have on hand. Thus, on hand for sellable packs = 0. Since the final quantity is pack quantity, the calculations do not go through any pack optimization process in the calculation engine.
The process of approving an allocation is asynchronous. 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 ensures that all inventory quantities are up to date at the time approval occurs, including the item source quantities. This validation prevents the system from creating an allocation against quantities that were available at the time of calculation but have since been claimed by another allocation, process or system.
This section covers assumptions made during ASN-based allocations, item-location combination, store calculation multiple, what-if allocations, weight and date selection, and proportional allocations.
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.
The ITEM_LOC table is where item location relationships are held and maintained from the Oracle Retail Merchandising System.
The system assumes that all of the items under a parent have the same SOM as the parent. In other words, the SOM cannot differ by item under a parent.
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.
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 screen 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.
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 quantity on future available on hand amounts assumes that the inventory that is expected within the warehouse arrives and that the business user creates a separate allocation to move the inventory to the stores.
'What if' allocations utilize the primary supplier's primary origin countries' inner, case and pallet size only. If a retailer wants to use the window 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.
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.
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.
For both Simple and Spread Demand, 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; 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 to have no more than 10 items in a scheduled allocation.
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 a 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 Schedule Allocation batch must be run after RMS updates the sales and on hand data.
The Daily Cleanup batch process deletes the data from the temporary tables on a daily basis. Run this batch immediately after you run the Schedule Allocation batch.
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 that 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 that the user deleted the earlier created child allocation, the batch process does not pick up the parent allocation, and creates the second child. The user has to either manually create an allocation or wait for the next scheduled batch run.
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 the ”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 on the System Properties tab of the system options screen.
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 status of the parent allocation will be set to '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 3-5 Visible Through the User Interface
| Status | Description | Status # |
|---|---|---|
|
Worksheet |
The allocation is in the initial stages of creation or it is being updated by the user. |
0 |
|
Submitted |
The allocation has been submitted successfully. |
1 |
|
Approved |
The allocation has been approved successfully. The allocation records have been sent to the merchandising system and the other downstream applications. |
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 |
The allocation has been cancelled by an external system. The allocation cannot be updated. |
5 |
|
Reserved |
The 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 for other items in the allocation for which no order has been created so far. |
10 |
|
Scheduled |
The 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 3-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 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 3-7 Process Status Column
| Status | Description | Status # |
|---|---|---|
|
Not Calculated |
The allocation has not been calculated. |
1 |
|
Calculation Waiting |
The allocation is waiting to be processed by the algorithm. The user cannot access an allocation with this status. |
2 |
|
Calculating |
The system is in the process of calculating this allocation. The user cannot access an allocation with this status. |
3 |
|
Calculated |
The allocation has been calculated successfully. |
4 |
|
Calculation Error |
An error was encountered during calculation. |
6 |
|
Size Profile Calculation Error |
The size profile was not found for all parent/diff 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 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 |
|
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 one or more errors occur 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, receipt 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 described 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. |
For this rule, data is gathered primarily from the following tables:
Table 3-8 Data Tables (History Sources)
| RMS 13.2.5 | Legacy System |
|---|---|
| DEPT_SALES_HIST | This table contains one row for each dept-location-week-sales type combination. Sales history information about each combination is held here. |
| CLASS_SALES_HIST | This table contains one row for each class-location-week-sales type combination. Sales history information about each combination is held here. |
| SUBCLASS_SALES_HIST | This table contains one row for each subclass-location-week-sales type combination. Sales history information about each combination is held here. |
| ITEM_LOC_HIST | This table contains one row for each item-location-week-sales type combination. Sales history information about each combination may be held here. |
For this rule, data is gathered from the following tables:
Table 3-9 Data Table (Forecast Data Sources)
| RMS 13.2.5 | 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, data is gathered from the following table:
ALC_RECEIPT_PLAN
For a more detailed description of this table, see the section, Receipt 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 3-10 Data Table (History and Plan Data Source)
| RMS 13.2.5 | Legacy System |
|---|---|
| DEPT_SALES_HIST | This table contains one row for each dept-location-week-sales type combination. Sales history information about each combination is held. |
| CLASS_SALES_HIST | This table contains one row for each class-location-week-sales type combination. Sales history information about each combination is held. |
| SUBCLASS_SALES_HIST | This table contains one row for each subclass-location-week-sales type combination. Sales history information about each combination is held. |
| ITEM_LOC_HIST | This table contains one row for each item-location-week-sales type combination. Sales history information about each combination may be held here. |
|
Note: For a description of the Bayesian algorithm that is used in this section, see . |
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 3-11 Data table (History Source)
| RMS 13.2.5 | Legacy System |
|---|---|
| DEPT_SALES_HIST | This table contains one row for each dept-location-week-sales type combination. Sales history information about each combination is held here. |
| CLASS_SALES_HIST | This table contains one row for each class-location-week-sales type combination. Sales history information about each combination is held here. |
| SUBCLASS_SALES_HIST | This table contains one row for each subclass-location-week-sales type combination. Sales history information about each combination is held here. |
| ITEM_LOC_HIST | This table contains one row for each item-location-week-sales type combination. Sales history 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 that 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 get allocated (if there is enough inventory to support it). Though the quantity limit gets accounted at the lowest level entity (that is, item/store combination), the retailer can also supply the quantity limits values at a higher level such as group of stores.
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 parent/diff. However, you may choose to de-aggregate the parent/diff 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 parent (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 affect net need, they are not addressed in the calculation illustrated by this section. |
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.
For a store location, Net Need = Gross Need - On Hand
On Hand = (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 + Outbound allocations) = (SOH +In Transit + On Order + TSF Expected + On Alloc) - (TSF Out + RTV + Unavailable + TSF Reserved)
For determining the on hand quantity, we need to consider all these different inventory buckets, some of which are present in Allocation while the rest are derived from RMS forms/tables/views.
Allocation side
SOH at the store
Stock in transit
Stock On Alloc
Back orders
RMS side
TSF Expected
TSF Reserved
TSF Out
RTV
Unavailable
Back orders
Alloc Out
See the Selecting Policies section in the Creating Standard Allocations chapter of the Oracle Retail Allocations User Guide for additional information.
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.
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. |
