| Oracle® Retail Allocation Cloud Service Implementation Guide Release 22.1.401.0 F72669-01 |
|
 Previous |
 Next |
| Oracle® Retail Allocation Cloud Service Implementation Guide Release 22.1.401.0 F72669-01 |
|
Previous |
Next |
Allocation is a critical link in the supply chain process, which presents the final chance to distribute products efficiently. The challenges facing retailers for allocating product are the same, whether they sell fashion items, groceries or hard lines. Allocators want an efficient, accurate method of translating their merchandise plans into location level allocations. Effectively allocating products is a critical step in product life cycle management and is the last chance the retailer has to get the right product to the right location in the right quantity.
Allocation enables you to take advantage of the most current, up-to-date sales and inventory information. The solution also has the flexibility to allow allocations to be calculated months in advance for vendor commitment purposes. It 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 location in the incorrect quantity at the wrong time. The net result is higher markdowns and lower profits.
The logic of Allocation is based on establishing need at the item/location level. The allocator influences the determination of need by choosing a rule and rule modifiers and then setting optional quantity limits. Then, Allocation determines gross need values based on the demand sources selected and applies constraints to the data and determines the net need for each store or warehouse on the allocation. At this point, an algorithm determines how to spread the available inventory across all of locations, based on net need. Then, the allocation is created.
There are three different ways that Allocation can create allocations - standard, what-if, and scheduled.
Standard Allocations
This type of allocation is created manually by selecting the items to be allocated, the source of the inventory, and the locations where the items should be sent. The allocator will also select the rules to be applied in order to determine gross and net need for the item/locations and apply any constraints for efficient distribution.
What-if Allocations
What-if allocations allow allocators to create hypothetical allocation and provide the flexibility to create purchase orders based upon the allocation calculated quantities. The process is exactly the same as a standard allocation except that the user starts with an infinite available number of the selected product or a user-specified quantity and determines their actual demand at the destination locations. The results of the what-if allocation are sent in the form of a purchase order to Merchandising for approval.
What-if allocations utilize the primary supplier's primary origin country's inner, case, and pallet size only. If an allocator wants to adjust these for the purchase order, the recommended approach is to make this update once the order has been created in Merchandising for the resultant purchase order.
Scheduled Allocations
Scheduled allocations are created similar to standard allocations, but have a schedule assigned to it. The schedule allows you to define a template with the start and end dates for review, the frequency for reviewing, and, when need is determined to exist, the action that should be taken (e.g. Create and Approve). This template is referred to as the parent allocation. Any allocations created based on the scheduled batch runs are called child allocations.
Item sources represent the physical inventory that can be used for allocation. Allocation allows you to allocate based upon the following:
Advanced shipping notifications (ASN)
Transfers
Bills of lading (BOLs)
Purchase Orders
Warehouse-sourced inventory
Approved allocations to a warehouse
Allocators are 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.
Allocation allows multiple parameters to be selected when creating an allocation. These parameters are used to determine the store or warehouse level need based on metrics that fit the product, location characteristics, and product life cycle. This results in allocations based on individual location need, which is the key to maximizing sales and profits.
These parameters can also be pre-defined as policy templates to simplify the creation of allocations. Policy templates act only as a default template when applied to allocations, as the parameters that are covered by the template can be updated on each allocation, as needed. The major components of a policy template include the demand source details, inventory parameters, and calculation parameters.
Demand Sources
Gross Need is the need that is calculated for an item/location based on the demand source information applied to the allocation. This includes selecting a rule for determining demand, indicating the merchandise level for the demand, and then a date range. The rules supported include:
Sales History
History uses historical store sales and warehouses issues from Merchandising for a date range to determine the gross need for an item on an allocation. History can be used at an item level, or level of the merchandise hierarchy - department, class, or subclass. Hierarchy levels may be helpful for cases where the actual item doesn't have sufficient sales history. User Selection will be helpful where the actual hierarchy for the item being allocated doesn't have sufficient sales history and an alternate hierarchy can be selected. Refer to the History Roll Up Refresh Views section of the Merchandising Foundation Operations Guide, volume 1 while working with sales history for a hierarchy level higher than the item one.
Forecast
Uses forecasted demand for a date range to determine the gross need of an item on an allocation. Allocation gets forecast details from Merchandising, but Merchandising sources this data from an external source, like Oracle Retail Demand Forecasting Cloud Service. Forecasted sales can also be used at the department, class, subclass, or item level. Refer to the Forecast Roll Up Refresh Views section of the Merchandising Foundation Operations Guide, volume 1 while working with forecast data for a hierarchy level higher than the item one.
Plan
Uses plan data - usually sales plan data - for a date range to determine the gross need of an item on an allocation. Plan data is at a store/week level and can be for a department, class, subclass, style, style/color, or SKU. Allocation gets this data directly from a planning solution. This type of plan is usually used for in-season allocating. For more information on plan data, see the Allocation Dependencies - Planning section.
Receipt Plan
Uses receipt plan data for a date range to determine the gross need of an item on an allocation. Allocation gets this data directly from a planning solution. Receipt plan data is at a store/week level and can be for a department, class, subclass, style, style/color, or SKU. This type of plan is generally used for pre-season allocating. For more information on plan data, see the Allocation Dependencies - Planning section.
History and Plan
This method combines the Sales History and Plan methods to determine gross need for an item on a location based on the date range selected. This method is helpful for in season allocating. Refer to the History Roll Up Refresh Views section of the Merchandising Foundation Operations Guide, volume 1 while working with sales history for a hierarchy level higher than the item one.
Plan Re-project
Compares an item's actual sales to the plan and then re-forecasts the plan based on performance for the date range selected, This re-projected plan is then used to determine the gross need of the item on the allocation.
Corporate
This method allows you to use custom pre-defined rules for determining the need of an item on an allocation by housing any specific demand data at the department, class, subclass, style, style/color or SKU level that could not be determined using any of the other rule types. This data is non-time based, but could be used for certain allocations that are less time specific. For example, initial allocations to a new store based on ideal weeks of supply.
|
Note: This method is not supported in a cloud service implementation of Allocation, as there is not a way to load the data into the table for this method. |
Manual
If you want to create an allocation where you manually enter the quantities to allocation for each item/destination location, then this is the method that should be selected.
Although these rules are detailed, occasionally the allocator needs to base allocations upon like items. The User Merchandise Level Selection option allows allocators to select any combination of like data on which to base allocations. They 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 allocator are applied to each item on the allocation.
Inventory Parameters
Inventory parameters for an allocation help define how the gross need calculated by the demand source information will be reduced to net need. These parameters include the ability to calculate the inventory buckets to consider in the calculation, selection of inventory dates to look at future available inventory, and the ability to use rule level on hand. Rule level on hand (RLOH) is summed up inventory at the selected rule level. For example, if you are allocating an item based on class level sales history, the RLOH value will be the total stock for all items belonging to the class of the item being allocated.
Calculation Parameters
Lastly, the calculation parameters in this section allow you to configure the results of the net need calculation across locations on the allocation. For example, these parameters allow you to determine how to spread available inventory when there isn't enough to meet the demand of all location and to set size profiles.
For more details on creating and using Policy Templates, see the Allocation Foundation Data User Guide.
Inventory Parameters
Inventory parameters for an allocation help define how the gross need calculated by the demand source information will be reduced to net need. These parameters include the ability to calculate the inventory buckets to consider in the calculation, selection of inventory dates to look at future available inventory, and the ability to use rule level on hand. Rule level on hand (RLOH) is summed up inventory at the selected rule level. For example, if you are allocating an item based on class level sales history, the RLOH value will be the total stock for all items belonging to the class of the item being allocated.
Calculation Parameters
Lastly, the calculation parameters in this section allow you to configure the results of the net need calculation across locations on the allocation. For example, these parameters allow you to determine how to spread available inventory when there isn't enough to meet the demand of all location and to set size profiles.
For more details on creating and using Policy Templates, see the Allocation Foundation Data User Guide.
There are two different sets of statuses that are used for allocations - an overall status and a processing status. The overall status determines whether or not the allocation has reserved inventory or been sent onto Merchandising for execution; whereas the processing status indicates where the allocation is in the calculation process or approval. The table below explains the different statuses in more detail.
The processes of approving and calculating allocations are asynchronous. This allows the allocator to work on other allocations while one is being processed in the background. 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 Allocation 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.
Overall Status
| Status | Description | Code |
|---|---|---|
| Worksheet | Initial status for the allocation. | 0 |
| Submitted | Allocation is moved to this status when it is ready for approval by the allocation manager. | 1 |
| Approved | Indicates the allocation has been successfully approved and has been sent to Merchandising and other downstream systems for processing. | 2 |
| Processed | Once the warehouse starts working on the allocation, it moves to this status and can no longer be updated. | 3 |
| Closed | Indicates the allocation has been shipped by the warehouse. The allocation can no longer be updated in this status. | 4 |
| Cancelled | Indicates the allocation was cancelled by an external system, usually the warehouse management system when sufficient inventory is not available to fulfill the allocation. The allocation can no longer be updated in this status. | 5 |
| Reserved | Indicates that the allocation has been sent to Merchandising and inventory has been reserved against this allocation, but not yet sent to downstream systems like the warehouse or store for processing. | 6 |
| Deleted | Indicates a user has chosen to delete the allocation from the user interface. Allocations in this status are not visible via the user interface. | 7 |
| Approval in Process | This status isn't currently used. | 8 |
| Reservation in Process | This status isn't currently used. | 9 |
| PO Created | Used only for what-if PO type allocations, this indicates that a purchase order has been created based on the allocation. Allocations in this status cannot be edited. | 10 |
| Scheduled | Used for scheduled allocations only, this status indicates that the parent allocation has been successfully scheduled and a child allocation will be created based on the template definition. | 11 |
Processing Status
| Status | Description | Code |
|---|---|---|
| Not Calculated | The allocation has not been calculated. | 1 |
| Calculation Waiting | The allocation is waiting to be processed by the algorithm. Allocators cannot access allocations with this status. | 2 |
| Calculating | The system is in the process of calculating this allocation. Allocators cannot access allocations with this status. | 3 |
| Calculated | The allocation has been calculated successfully. | 4 |
| Calculation Error | An error was encountered during calculation. An overview of the error will be provided on hovering on this text in the Allocation Maintenance workflow. | 6 |
| Size Profile Missing | The size profile was not found for all parent/diff combinations on the allocation. | 7 |
| Ideal Weeks of Supply Calculation Error | Allocation weeks of supply data was not sufficient for the algorithm requirement for the Plan Re-project rule. | 8 |
| Quantity Limits Conflict | This status isn't currently used. | 9 |
| Status Error | An error was encountered when submitting, reserving, or approving the allocation. | 10 |
| Status Waiting | This status isn't currently used. | 11 |
| Status Processing | Allocation is in the process of submitting, reservation or approval. Users cannot access allocations with this status. | 12 |
| Status Processed | The allocation has been approved, reserved, or submitted successfully. | 13 |
| Available Inventory Error | Inventory quantities that the allocation was based on have increased or decreased since the time of calculation. The allocation must be recalculated and approved based on current inventory. | 14 |
| Scheduled | The scheduled allocation has been created successfully. | 18 |
| Schedule Error | One or more errors occurred when the schedule allocation was created. | 19 |
There are three different methods that are used for closing allocations. The closure of an allocation uses "all or nothing" processing logic - either the whole allocation is closed or it remains open.
Warehouse and Store Initiated Closure
This method of closure is based on standard business processes of shipping and receiving the allocation. Once all line items have been full shipped and received, the allocation will be marked for closure. This may also occur even if lines are not fully shipped but a stock order status update is sent from the warehouse to indicate full or partial cancellation of the allocation, usually due to insufficient inventory.
Automated Closure
After so many days, defined by Merchandising system options, purchase orders, transfers, and allocations can be automatically closed to free up inventory reservations and more correctly reflect on order. If a transaction that an allocation is tied to is cancelled then the allocations are also cancelled if not executed.
Manual Closure
Purchase orders and transfers can also be manually closed in Merchandising. If this occurs, then the associated allocations would also be cancelled. The exception to this is for purchase orders where users are given the option to leave allocations open even if the PO is cancelled.
In order to increase the efficiency of the allocation process, Allocation has the ability to split allocations. By splitting an allocation, the allocator has the option of selecting the product hierarchy and location combinations that they would like to remove from the original allocation.
Allocators are 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.
Allocation assumes that all the transaction items under a parent have the same store order multiple.
In some cases, orders are placed with a case size that differs from the standard case size held in Merchandising. When this occurs, rounding by inners for the allocation may have issues if the new case size is not evenly divisible by the standard definition of inner.
For more information on using Allocation, see the white papers found in the Merchandising Functional Library found on My Oracle Support at 1585843.1.
