Oracle® Retail Allocation

Allocation Whitepaper
Release 14.0

February 2014
Note: The following is intended to outline our general
product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not
a commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing
decisions. The development, release, and timing of any
features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.
 Contents
1 Oracle Retail Allocation ................................................................................................. 1 
Document Objective ............................................................................................................... 1 
Allocation vs. Replenishment......................................................................................... 2 
Item Types ........................................................................................................................ 2 
Allocation Types .............................................................................................................. 3 
User Key Decision Points ................................................................................................ 3 
Allocation Process Flow .................................................................................................. 4 
Basic Allocation Math and Concept .............................................................................. 4 
RMS Dependencies .......................................................................................................... 5 
RMS Inventory Options .................................................................................................. 6 
Target Stock Ratio ............................................................................................................6 
Quantity Limits ................................................................................................................ 7 
Spread Demand Mode .................................................................................................. 10 
Pack Distribution Mode ................................................................................................ 11 
What If: Create PO ......................................................................................................... 16 
Allocation Scheduler ..................................................................................................... 17 
Methodology Types ....................................................................................................... 19 
Basic Allocation Facts .................................................................................................... 20 
Implementation Considerations and Best Business Practice ................................... 20 
14.0 Integration Map...................................................................................................... 21 
Frequently Asked Questions ........................................................................................ 22 
Glossary........................................................................................................................... 25 
 1
Oracle Retail Allocation
A retailer's most important asset is its inventory. Get it right, and business will soar. Get
it wrong, and the result is unhappy customers, markdowns, and product that no one
wants. With the entire business riding on having “the right product in the right place at
the right time”, retailers need an easy-to-use and accurate method of allocating
merchandise. Oracle Retail Allocation helps retailers determine the inventory
requirements at the item and location level, resulting in an inventory allocation that
optimizes your supply across all locations. Using real-time inventory information, the
system calculates need based on parameters you set, whether it is the characteristics of
the product or the store. The result is an allocation tailored to each store's unique need.
Oracle Retail Allocation allows you to allocate either in advance of the order's arrival or
at the last minute to leverage real-time sales and inventory information.
Oracle Retail Allocation is an ad hoc manual “push” distribution tool used to send
sellable merchandise from warehouse locations to selling store locations. The objective of
each unique allocation is to create meaningful warehouse (WH) to store distributions.
Oracle Retail Allocation is used primarily to create just in time warehouse to store
distributions in order to take advantage of real-time inventory updates and store
demand. There are multiple methods and techniques within the Allocation product to
obtain and alter store demand; these are established based on a specific business case
which is driving the need to create an allocation. Per allocation, the user has full control
of the following:
 What to send
 How much to send
 Who to send to
 When to send
 How to send

Document Objective
The primary objective of this informal document is to highlight lesser well-known
capabilities within the Allocation product, provide more detail on commonly asked
questions, call out product facts, clarify specific capability/features, and provide
additional information on how to use the Allocation product more effectively.
This document is not intended to replace any of the current Release Notes, Operations
Guides, User Guides, Installation Guides, Data Models, Release Value Proposition, or
any related training documentation.

Oracle Retail Allocation 1

Allocation vs. Replenishment
Business cases to help determine the difference between using Allocation and
Replenishment:

Allocation Replenishment

Manual “push” process Automated “pull” process

No batch process required
Pre set up activities > No
React to sudden change in store demand
Short shelf life items; seasonal, less than16
weeks
Constrained inventory, only “x’ amount is
available and purchased
What the stores need now…point in time
Quickly distribute top selling items to top
selling locations using trend, forecast and plan based off historical performance/sales curve and
data
Distribute only what the store is expected to
sell or own
Batch process required
Pre set up activities > Yes
Pro active prepare for spikes and demand
Long shelf life items; year round, greater than 16
weeks
Unconstrained inventory, available to be
purchased based on store demand
What the stores need to support a horizon
Replenish to those locations with need based off
forecast
Maintain stock levels, presentation minimum

Items placed on Replenishment are also eligible to be allocated, often to support the
following:
 Quick reactions to sudden change in store demand due to inclement weather
 Preparing for an upcoming promotional event (last minute event)

Item Types
Oracle Retail Allocation supports the following item types:
 Staple Items:
– Items which are not associated with a Parent Item:
12” Hammer
Tennis Racquet
55” TV
Backpack
– Sellable or non sellable
 Fashion Items
– Aggregate store demand data is determined, store size profile data is required to
push down arrogate store demand down to size.
– What is a Fashion Item? Items which are associated with a Parent Item such as:
Parent Item = Red V Neck T Shirt
Child Item = Red V Neck T Shirt Small, Red V Neck T Shirt Medium, Red V
Neck T Shirt Large, Red V Neck T Shirt X Large
 Packs:
– Staple Simple Packs – multiple of the same item
– Staple Complex Packs – multiple of different staple items

2 Oracle Retail
 – Fashion Packs:
Single Style/Single Color/Single Size
Single Style/Single Color/Multiple Sizes
Single Style/Multiple Colors/Multiple Sizes
– Sellable and Non Sellable Packs
– Orderable and Non Orderable Packs

Allocation Types
Oracle Retail Allocation offers the capability to create different types of distributions:
 Just In Time Allocations: An allocation is created for items prior to arrival at the WH;
once the items arrive they are immediately processed and sent to the stores. Supports
cross dock business cases.
 Post Allocations: An allocation is created for items which are currently available and
stocked in a warehouse location, waiting for allocation instructions.
 Combo Allocations: Store demand is filled with both soon to arrive and warehouse
stocked available quantity.
 Schedule Allocations: Predefined instructions schedule to be executed on predefined
days in the future, allocations are created until available quantity meets the
minimum requirement.
 What If Allocations: Simulated scenarios using a top downs approach (user keys in
desired quantity to validate how much is consumed) or a bottom up approach
(system aggregates individual store demand to produce a total demand).
 Pre Season: Allocations created for items to support an upcoming selling period,
often Receipt Plan is used to drive this business case.
 In Season: Allocations created for items which are currently selling in the stores,
often historical sales data and forward looking sales plans are used to drive this
business case.
 End of Season: Final allocation of a specific item, the item will soon no longer be
available and is often marked down as new assortments are on the way.

User Key Decision Points

There are six primary key decision points before an allocation is created, using these key
decision points aides the user in creating meaningful store distributions:
1. What is the business case and objective of the allocation?
a. Pre or Post allocation
b. New or existing item
c. New store set up
d. Fill a fixture or fill in to historical sales
2. What items need to be distributed?
a. Staple items
b. Fashion items
c. Packs
d. Multiple items
e. Promotional items
f. Discontinued items

Oracle Retail Allocation 3

 Users are expected to have an understanding of items which require an allocation;
using the Search capability at the Dept. level is not considered an effective use of the
product. Sifting through hundreds of line items to only select a few items does not
support efficiency.
3. What is my source for available quantity?
a. Allocate from a stocked WH or soon to arrive Purchase Order (PO)
b. Do I have enough available quantity to achieve my business case
4. What stores am I allocating to?
a. All stores or a subset of stores
5. Where to obtain my store demand?
a. Receipt plan, historical sales or forward looking sales plan/forecast data
b. How much data (time coverage)
c. What level of data (dept/class/subclass/style-color/SKU or like item)
6. Which rules, parameters and constraints need to be applied?
a. Include store on hands
b. Constrain the store demand
c. Filter out low demand stores
d. Allocate total available quantity or only what is needed
Understanding each of these key points prevents the user from spending unnecessary
time validating the allocation results.
Creating tailored allocation with multiple items which have similar objectives and
characteristics produces meaningful allocations.

Allocation Process Flow

Task driven process; identify your task and execute

Basic Allocation Math and Concept

Oracle Retail Allocation applies the following mathematical concept to produce an
allocated quantity for each item/location record:

4 Oracle Retail
 The primary objective of Allocation is to fill each store’s demand (Gross Need) by 100%
or as close as possible. The final allocated quantity is based upon how much is available
to allocate, store calculation multiple, constraints, pack size, and so on.
In the example, the store needs 4 units to meet its demand of 12 (store owns 8). The item
allocated is a 6 piece pack configuration, therefore the store is eligible to receive 1 pack =
6 units.

RMS Dependencies
Much of the data required to create an allocation is dependent on Oracle Retail
Merchandising System (RMS). Allocation pulls the data “real time” directly from RMS
tables such as:
 Items:
– Product Hierarchy Level
– Supplier
– Item List
– UDA
 Locations (stores and WH):
– Store Open/Close Dates
– Store – WH Default Relationship
– Location Lists and Traits
– Sister Store
 Inventory:
– WH
– PO, ASN and BOL
– Transfers
 Historical Sales Data
 Stop Shipments
 Item/WH Relationship:
– Can the item be sent to the WH
– Can the WH stock the item
 WH/Store Relationship:
– Can the store receive the item from the WH
– Can the WH send the item to the Store
 Item/Store Relationship:
– Can the item be sold at the store

Oracle Retail Allocation 5

 – Can the store stock the item

RMS Inventory Options

Per allocation, the user has the option to select specific inventory criteria in order to
produce store Net Need. The options are:
 On Hands
 On Order
 In Transit
 Inbound Allocation
 Back Order
 Clearance Stock
When allocating at higher levels such as Subclass (demand and inventory), there may be
times when the user wants to exclude clearance stock. Do not want to penalize the stores
for owning an abundanct amount of clearance stock.
For pre season inventory build cases, the user may want to exclude current inventory
and only include Inbound Allocation inventory to produce the store’s Net Need.
For those cases in which the store has a back order quantity, the user has the option to
include or exclude the back order quantity to produce the store’s Net Need.

Target Stock Ratio

Whenever total store need is greater than total available quantity to allocate, the system
automatically performs a Target Stock Ratio calculation to proportionally adjust each
location’s Gross Need value down by the same percentage. See the following example:
Diagram 1: Total store need = 35, total available to allocate = 24

Total WH Availability 24

Gross
Store On Hands Net Need
Need
234 15 10 5
345 22 13 9
456 18 16 2
567 16 7 9
678 9 15 -6
789 26 16 10
Total 106 77 35
Diagram 2: How Target Stock Ratio is calculated
 Total WH On Hands of 24 + Total Store On Hands of 62 = Total Own of 86
 Total Own of 86 / Total Store Demand of 97 = Target Stock Ration of .89

Note: Any location with a negative Net Need value is

omitted from the logic as the location is already overstocked
(see Store 678).

6 Oracle Retail
 Total WH Availability 24

Gross
Store On Hands Net Need
Need
234 15 10 5
345 22 13 9
456 18 16 2
567 16 7 9
678
789 26 16 10
Total 97 62 35
Diagram 3: Final Results
Each store’s Gross Need is multiplied by the TSR of .89 and is adjusted down
accordingly.

Total WH Availability 24

Adjusted
Gross
Store Gross On Hands Net Need
Need
Need
234 15 13 10 3
345 22 20 13 7
456 18 16 16 0
567 16 14 7 7
678
789 26 23 16 7
Total 97 86 62 24

Quantity Limits
Q: What are Quantity Limits?
A: Quantity Limits are optional ad hoc capabilities used to fine tune the allocation;
applied at the individual item/location level.
 Quantity Limits should not be applied to control, mimic or create assortment
planning objectives. Or applied as the sole basis of the allocation to obtain desired
results.
 Quantity Limits are not shipping constraints; they constrain an individual
item/locations GN or NN values which are used to produce the Final Allocated
Quantity.
 The Trend, WOS and Min Gross Need Quantity Limits are used to constrain the
item/locations GN value (increase or decrease).
 The Threshold, Min Net Need and Max Net Need Quantity Limits values are used to
constrain an individual item/location Net Need value. The constrained Net Need
value is then used by the calculation engine to produce the final allocated quantity;
additional constraints such as, pack size, rounding logic, store size profile data, and
available quantity to allocate are also applied to produce the final allocated quantity.

Oracle Retail Allocation 7

 Quantity Limits are applied in the following order:
 Trend – The Trend value is treated as a percent (%) and applied to the Gross Need
value (increase/decrease); the result will be used as the store’s Gross Need (store
demand/need). This is used to alter the actual demand based on an expected change
in store demand.
 Weeks of Supply – The value entered will be multiplied by the item/location
Average Weekly Sales/Forecast/Plan (defined within the Rules); the results will be
used as the store’s Gross Need. This is often used for items which are about to end
their selling period.
 Minimum Gross Need – The value entered is compared to the stores Gross Need
value, the greater value will be used as the Gross Need for the allocation. This is
often used to ensure stores have enough demand to receive an allocated quantity.
 Threshold – Ensures the item/location is not allocated a quantity unless the Net
Need value is equal to or greater than the Threshold value. This is used to filter out
those stores with a small demand, sending a location a quantity of 1 or 2 is often seen
as not valuable in terms of the cost to process and ship.
 Minimum Net Need – The Min value is compared to the Net Need, the greater value
is used as the store’s demand/need. This is used to ensure that the Net Need is at
least the Min Net Need value.
 Maximum Net Need - The Max value is compared to the Net Need; the lesser value
is used as the store’s demand/need. This is often used to ensure the store is not
overstocked due to its small space on the sales floor or stockroom space.
The following is an example of applying a Min Gross Need and Max Net Need Quantity
Limit:
 The Min Gross Need Quantity Limit of 24 is compared to the Gross Need value of 18.
The greater value is used to calculate Net Need; 24 minus 10 equals 14.
 The Max Net Need Quantity limit of 8 is compared to the calculated Net Need value
of 14. The lesser value is used to determine final Net Need; 8 is the value used as the
stores Net Need.
 The item being allocated is a pack which contains 5 units, with a Net Need value of 8.
The store is eligible to receive 2 packs for a total of 10 units.

8 Oracle Retail
The following is an example of how Quantity Limits are applied and how they are used
to drive the Final Allocated Quantity. For this example, History last 3 weeks is used.

Note: The Pack Distribution Mode offers 2 unique Quantity

Limits; Min Pack and Max Pack. The Min Pack is used to
ensure at least “x” amount of the pack is allocated, and the
Max Pack ensures that no more than “x” amount of a pack is
allocated regardless of need. Both of these are set at the item
(pack)/location level.

Oracle Retail Allocation 9

Spread Demand Mode
The new Spread Demand Mode allows for users to allocate multiple items against a
single store demand.
Business Case: The Sunglass Tower holds 80 sunglasses and an additional 30 which can
be stored under the cabinet for a total of 110 units. The ideal result is to produce an
assortment like based allocation.

Business Case: The user is allocating 7 styles, and wants to ensure the 7 available styles of
sunglasses fill the store Subclass demand of 110. The store currently has 2 on hands,
therefore 108 are needed.
The Spread Demand Logic first calculates each Style’s percent to the total available, such
as:

10 Oracle Retail
 The store Subclass demand of 110 is multiplied by each Style’s percent to the total
available to determine each Styles unique Gross Need. Each Style appears as an
individual line item, such as:

The following are system rules and best business practices:

 Requires at least 2 items, all items types are supported.
 User must ensure the store demand is “rich” enough to produce optimal results;
demand must be greater than total available quantity.
 After the Spread Demand has occurred, each item/location record can be treated as
any other allocation. Quantity Limits, rounding, manual override, and so on.
 If allocating multiple items from different merchandise hierarchies, the User
Selection capability is required in order to spread one demand among multiple items.
 Ideal for final pushes or quick fixture fills.
Replaces former Cascade Logic
 Better intuitive results
 More user control

Pack Distribution Mode

The Pack Distribution Mode allows for retailers to allocate multiple non-sellable simple
staple and non-sellable complex staple packs using simple “round robin” logic against a
single store demand to ensure an assortment of packs are distributed to all eligible
locations with a priority given to the top demand locations.
The objective of this Mode does not attempt to fill store demand; its objective is to use the
store demand in order to prioritize the stores in order (highest to lowest).
Business Case: Identify stores which are in need of more merchandise at the Department,
Class, or Subclass level in order to determine which stores are in need of additional
product.
Example 1: You have multiple pack configurations of the same items and want to allocate
the biggest pack configuration to the stores with the highest demand.
 Pack A - 24 units > 50 available
 Pack B - 18 units > 450 available
 Pack C - 6 units > 200 available
Example 2: In this case the goal is with different items, you want merchandise
cohesiveness. The objective is to allocate an assortment.
 Boy’s Sports Lunch Boxes: Football >1000 packs of 12
 Boy’s Sports Lunch Boxes: Basketball > 750 packs of 6
 Boy’s Sports Lunch Boxes: Baseball > 700 of 6 packs

Oracle Retail Allocation 11

 Example 3:
 Opportunistic buy’s
 One time buys
 Initial distribution
 Retailer Selling Period: pre season and in season
System Rules:
 When multiple packs are allocated, begin with the pack with the largest
configuration (largest quantity):
– When applying this logic, all pack contents are considered equal, only the size of
the pack matters.
 The first pack allocated starts with the store with the highest demand.
 Per store; only allocate a pack if store demand is at least 50% of the pack
configuration. Stores whose demand < 50% of the pack configuration will be omitted.
If smaller pack configurations are available, the store may be eligible to receive a
smaller pack.
 No single store will be allocated a duplicate pack until all eligible stores have been
allocated at least one of the packs.
 Once a pack has been fully distributed, the round robin pack distribution logic
begins with the next largest pack configuration starting with the next store in line of
demand.
 After the store with lowest demand has been allocated a pack, the round robin logic
continues for unallocated packs. The store with the highest demand receives another
pack.
 The process continues until all packs have been distributed or until the store can no
longer consume another pack.
 Only supported in MLD 0 environment setting.
 When multiple packs exist with the same configuration quantity and same available
quantity, whichever record is processed first will be used as the priority pack.
 When multiple locations exist with the exact same demand and there are additional
packs to distribute, whichever record is processed first will be used as the priority
store.
 A single store demand will be used to rank the stores in priority for all item/loc
records (per store) on the allocation. The store demand value used to rank the stores
will display in the Net Need column of the Allocation Detail screen.
 All packs must belong to same product hierarchy, if not, User Selection is required.
 When the Allocation Mode is set to Pack Distribution, the following options are not
allowed (counter intuitive logic):
– Quantity Limits
– Need Is: Proportional
– Disable of Hierarchy level drop- down, and Style-Color and SKU hierarchy levels
Best Business Practice Guidelines and Assumptions:
 Optimal results are achieved best when store demand is much greater than available
quantity. When store demand data is less than available quantity, the objective of
distributing an assortment of packs starting with top demand locations cannot be
ideally achieved.

12 Oracle Retail
 If the first available pack has an abundant available quantity greater than store count,
it is expected that this pack may fill store demand by distributing duplicate packs to
the top locations which may prevent those locations from receiving other packs.
Large pack configurations are intended for top demand locations.
Example 1: Available to allocate

Logic
1. Begin with Pack A (5 packs available - largest pack configuration). Start with Store
112 and end with Store 114.
2. Pack B begins where Pack A left off (15 packs available – next largest pack
configuration). Start with Store 103, come to the last store on the list (Store 117), 3
packs available to distribute, loop back around and begin again with Store 112, and
end with Store 113 (no more packs, all depleted).
3. Pack C begins where Pack B left off (10 packs available, next largest pack
configuration). Start with Store 105 and end with Store 104.
4. The process continues until all packs have been distributed or until store demand has
been achieved.
5. The overall objective of distributing an assortment of packs starting with top demand
locations has been achieved.
6. The blue arrow indicates the logic of where a pack ends and the next pack begins
(next pack with largest configuration, next store in line of demand).

Oracle Retail Allocation 13

 Example 1: Results

Example 2: If the user wants to ensure a variety of packs are distributed, they should
apply a Hold Back against those packs with a large amount of available quantity or
modify the demand to increase using the Change Weights function (as Quantity Limits
are not available with this Mode).
The pack distribution logic will continue to distribute all packs until there are no more
packs or until store demand has been achieved. In scenario 1A, the top 5 stores all
received a duplicate 25 piece pack preventing them from receiving other packs. In
scenario 1B, the user held back 5 Pack as allowing the system to only distribute 10 packs
out of 15. The end results now allow for the top stores to receive a fuller distribution of
packs.
One of the assumptions: The allocation user is responsible to ensure that the objective of
allocating a full assortment of packs is achieved by controlling the number of packs
available to fill store demand.
The blue arrow indicates the logic of where a pack ends and the next pack begins (next
pack with largest configuration, next store in line of demand).
Remember the objective is to not fill the total demand of 775, but use this data as a guide
to determine and prioritize top demand locations.

14 Oracle Retail
Example 3: In this example, store demand is much smaller. Again, by controlling the
number of packs being allocated, the end results can differ. 3A penalizes the top demand
locations by distributing duplicate packs. 3B and 3C (next screens) are examples of
holding back packs which results in a better assortment of pack distribution. User choice!
Store 123
Scenario 3A results = 2 Pack As
Scenario 3B results = 1 Pack A and 1 Pack B
Scenario 3C (next screen) results = 1 Pack A, 1 Pack B and 1 Pack C
Depending on the components of the pack (what makes up the pack), which scenario is
better? If same item, multiple pack configurations 3A may be best; if multiple items 3C
may be best.
One of the assumptions: If the first available pack has an abundant available quantity
greater than store count, it is expected that this pack may fill store demand by
distributing duplicate packs to the top locations which may prevent those locations from
receiving other packs.
Scenario 3A - Store 567 has a demand of 30. After giving them a pack of 25 (Pack A), the
store need now becomes 5, with a new need of 5. Store 567 cannot use Pack B of 12 units
(does not meet 50% pack rounding rule), so Pack B is bypassed, however with a need of
5, the store qualifies for Pack C of units 6, total allocated quantity = 31.
Total Demand 275: In Scenario 3A, 311 units are allocated. In Scenario 3B 265 units are
allocated and in Scenario 3C, 283 units are allocated…..user choice, user has control to
manage final results.

Oracle Retail Allocation 15

What If: Create PO
What If is capability to create simulated allocations scenarios without creating formal
allocations records. The user can perform two types of What If scenarios:
 Tops Down: The user manually keys in a desired available quantity to allocate and
performs the necessary steps of creating an allocation to determine how much of the
keyed in allocated quantity is consumed.
 Bottoms Up: The user starts with an infinite concept as the available quantity to
allocate and performs the necessary steps of creating an allocation to determine how
much is needed.
As a time saving method to help increase operational efficiency, the results of a What If
allocation can be used to generate an RMS PO of one of the following four PO types:
1. Bulk: A purchase order is created to a single warehouse and no allocation is attached
to the PO. This type of PO is created during the initial planning phase when there is
no information about the different warehouses which receive the items.
2. Cross Dock: A purchase order is created with a line item for each warehouse. The
goods are directed from the supplier to a warehouse where it is immediately stocked.
3. Warehouse: One purchase order is created with multiple warehouses and quantities
and no allocation is attached to the PO.
4. Direct to Store: A purchase order is created with a line item for each store. It directs
the supplier to ship the goods on the purchase order directly to the final store
location.
   

16 Oracle Retail
 Ad hoc Example:

Business Case: What If: Create PO designed to support the following ad hoc in-season
business cases:
1. Buyer is at market and meets with Vendor.
2. Vendor offers the Buyer a 20% discount with the requirement that “x” amount must
be purchased.
3. Buyer contacts Allocator to determine if the stores can consume “x” amount.
4. Allocator performs What If and determines “x” is needed; uses the Create PO feature
to generate the PO.

Note: The What If: Create PO feature was designed to

support the business cases described above. It is not
designed to be the primary PO creation engine.

 Allocation results (based on store demand, rules, and parameters) are considered the
suggested order quantity; RMS is the system of record for POs generated from
Allocation and will produce the final PO quantity. When the PO is created in RMS
from Allocation, supplier, item and location attributes in RMS are used to default the
appropriate values onto the PO.
 All POs generated from Allocation are generated in RMS in Worksheet status. The
PO must be approved before an allocation can be created and approved using the PO
as the allocation source.
 This feature is designed for existing items which are currently selling in the stores
and which require an “at once” purchase order. This ad hoc feature is not designed
to support new items or new item process; initial purchase order creation.

Allocation Scheduler
The Auto Allocation Scheduler allows for users to predefine allocations in order to be
auto-created on specific day or days of the week using batch jobs (set up during
implementation). The user defines an allocation template (Parent Allocation) which
dictates when and how often an allocation (Child Allocation) will be created.

Oracle Retail Allocation 17

 This logic requires two additional allocation criteria to be entered; Minimum Available
Quantity and Threshold Percent:
 Minimum Available Quantity: represents the minimum available quantity needed in
order to auto-create and auto-approve the allocation. If the actual available quantity
is less than the minimum available quantity value, the allocation will not be auto-
created. Helps to ensure that the total available quantity will not be spread too thin
among all locations; user now has the opportunity to allocate the minimal available
inventory to a smaller group of locations or by applying other rules and parameters.
 Threshold Percent: represents the percentage difference between the total available
quantity and total store need. If the difference exceeds the threshold value, the
allocation will be auto-created in Submit Status; this requires the user to view the
allocation results to ensure ideal results are met. Helps to ensure that the total
available quantity was not spread too thin among all locations; gives the user the
opportunity to adjust the allocation for better optimal results.

Business Case:
For Fashion Retailers after the initial allocation occurs, often the items are stocked in the
warehouse to be later allocated to the top selling stores. The remaining units stocked at
the warehouse are not enough to be placed on a true replenishment system as these items
will soon be replaced with newer products.
The idea behind scheduling is to save time and data entry for users from having to
manually re-create allocations that have the same criteria. The Allocation Scheduler
feature is not intended to mimic or replace a full replenishment system or address
replenishment business requirements and objectives.
System Rules:
 Batch process required.
 This feature is only supported from a stocked valid warehouse location.
 The scheduler will allow the user to define an allocation and then place it on a
schedule to be automatically recreated on specific dates and time until the end date is
met, warehouse stock is depleted, or the minimum available quantity value is not
met.

Note: The Allocation Scheduler is not designed to mimic or

replace replenishment objectives and logic nor function as a
replenishment system.

18 Oracle Retail
Methodology Types
Allocation supports multiple methodologies. Following is a high-level overview (recap)
of the four types of methods:
Simple Mode (1:1 Methodology): When multiple items are allocated in a single
allocation, each item on the allocation is treated as single entity; each item will have its
own unique demand and calculated quantity. There are no grouping objectives or
relation between any items on the allocation. All items on the allocation will use the same
policies with the exception of Quantity Limits. When allocating a fashion item using the
Style-Color method, store size profile data is used to spread the aggregate Style-Color
demand down to size or best pack fit based on what is available to allocate.
Spread Demand Mode (Many to 1 Methodology): This Mode allows for multiple items
to be allocated against a single store demand. The single store demand is spread among
the each item based on each item’s % contribution to the total available quantity. After
the spread logic has occurred, each item will appear as a single entity (separate line item)
and will produce its own unique final allocated quantity; each item can then be further
managed with Quantity Limits and additional constraints. The intention of this method is
a many-to-one logic; distribute many items against one total demand. Ideally, the
allocated results of each item would add up to the total single demand or as close as
possible based on user constraints.
Pack Distribution Mode (Round Robin Methodology): The Pack Distribution Mode
allows for retailers to allocate multiple non-sellable simple staple and non-sellable
complex staple packs using simple “round robin” logic against a single store demand to
ensure an assortment of packs are distributed to all eligible locations with a priority
given to the top demand locations. The objective of this Mode does not attempt to fill
store demand; its objective is to use the store demand in order to prioritize the stores in
order (highest to lowest). The logic begins by distributing the largest pack configuration
to the highest demand store and works its way down until no more packs are available
or until a store cannot consume a pack. When allocating fashion packs, store size profile
data is bypassed as this method does not consider sku-store-demand. The size of the
pack is the objective, not the content of the pack.
Fashion Group (Grouping Methodology): This logic allows for multiple items types
within a single Style to be allocated as a group (single entity, 1 line item) against a single
store demand; sku-store-demand (store size profile data) is used to determine the spread
of sizes and/or best pack fit. The assortment-based results are dependent on available
quantity; this logic requires a combination of two or more of the following item types
which belong to the same Style:
 Single Style/Single Color/Single Size Pack (one or multiple configurations)
 Single Style/Single Color/Multiple Size Pack (one or multiple configurations)
 Single Style/Multiple Colors/Multiples Size Pack (one or multiple configurations)
 Any loose item (SKU) which is a child of a parent/diff belonging to the Style (parent)

Oracle Retail Allocation 19

Basic Allocation Facts
 Allocation only operates in measurements of whole units using full fiscal weekly
demand.
 All stores selected on the allocation are eligible to receive its demand by 100%; store
priority logic is not applied.
 Allocation is ideally used to determine “point in time” store need; does not offer
logic to project store inventory demand for a horizon.
 Allocation is designed as an execution-based product versus an analytical product.
 The version of Allocation must be implemented using the same RMS version as
nearly 85% of the data required to create an allocation is pulled directly from RMS
tables.
 Any item distributed using Allocation must be approved and active in RMS;
discontinued items, clearance items, items on replenishment and non sellable items
(such as, store supplies or gift with purchase) are also eligible to be allocated.
 Every allocation requires a Release Date; the Release Date is the date when the
warehouse can begin the “pick process”. The Release Date must be equal to the
current date or a date in the future. The Release Date is also used to validate store
eligibility.
 Each Allocation is considered unique and meaningful. When selecting multiple items
per allocation, all items should have a similar theme and common characteristics
which drive the need for creating an allocation.

Implementation Considerations and Best Business Practice

The following best business practice guidelines and implementation considerations are
based off previous implementation use cases and industry standards:
 From a user managerial perspective, an allocation containing more than 10 items
may be difficult to manage:
– Too many item/loc records to view
– A problem with 1 item on the allocation may hold up the entire allocation
 All items on a single allocation share the majority of the same rules and parameters,
most items do not perform the same; some items sell faster, some sell more, some sell
better in specific locations, and so on:
– Creating smaller meaningful allocations often results in better optimal results.
 As mentioned previously, Allocation is required to be implemented using the same
code branch as RMS. Most major implementations will roll out RMS before
Allocation is implemented; it is highly recommended that Allocation always be
considered during the RMS implementation to identify any risk in which RMS may
impact Allocation. Example:
– If RMS is implemented to only store historical sales data less than 52 weeks, then
the LY capability in Allocation cannot be used.
 Once allocations are set to “Closed” status, the client is responsible for creating a
purge process to remove them. Most often “Closed” allocations are often purged
after 30 days, storing closed allocation for long periods of time may impact system
performance.
 Having a solid understanding of the objective of creating an allocation will allow the
user to perform the steps of creating an allocation effectively, smoothly, and quickly.

20 Oracle Retail
 The description of an allocation is auto-populated with the description of the first
item selected on the allocation. A naming convention is recommended to help users
quickly identify previously created allocations such as:
– User initials followed by dept assignment, followed by open text
– FA D10 Back To School Backpacks
– Allocations can then be sorted using a alphanumeric approach
 Prior to training users on the Allocation product, the following training is highly
recommended:
– RMS Foundation Data
– RMS Orders
– RMS Replenishment
– RPAS applications SPO and AP
– RWMS (process)
 How do you know when you are heading in the wrong direction with the Allocation
product?
– Attempting to solve assortment planning objectives
– Attempting to implement Allocation in a dynamic fashion, that is, replenishment
– Attempting to solve business cases supported in other Oracle Retail products
– Performing analytical business cases instead of executing business cases
– Using the product as “workhorse” versus creating custom tailored allocations
– Using ad hoc capabilities to solve primary business objectives

14.0 Integration Map

Oracle Retail Allocation 21

Frequently Asked Questions

Question Answer

Can the Allocation product be implemented as This is not available, as previously mentioned,
a standalone product? the majority of the data required to create an
Allocation is obtained directly from the RMS
database. Allocation also takes advantage of real
time inventory updates and real-time updates
from Location Lists and Traits.
What’s the difference between Approving and Reserving an allocation decrements the allocated
Reserving the Allocation? quantity from the Source available and commits
the allocated quantity to the stores on hands.
However, the process of sending the allocation
details to RMS, which sends to RWMS, does not
take place.
Approving the allocation performs the same
process as Reserved status, however in this case,
the process of sending the allocation to RMS
which sends to RWMS, takes place.
How do I track an allocation once it’s been Once an allocation is approved, it is sent to
approved? RWMS as a "Stock Order" through RMS. There is
a type associated with the stock order that
indicates the source, "T" for transfer and "A" for
allocation, although it comes from a different
table structure in RMS. Both transfers and
allocations go to the same RWMS "Stock Order"
table.
RWMS sends constant updates to RMS about the
Stock Order status, so both could be used to track
the allocation; often a custom report is used.
Note: There is no visibility to approved
allocations in the online screens in RMS
Can I edit an allocation which is in “Progress” Once the system places the allocation in
status? “Progress” status, this is an indicator that the
warehouse pick process has begun; the allocation
is no longer editable.
How do I stop an allocation that has already This is a manual process defined by each client
been approved and is in “Progress” status? on how to stop the warehouse pick process.
Most often a call is made to the warehouse. There
are no options available in Allocation to stop an
allocation from being processed once the WH
pick process has begun.
How do I know if the stores received exactly Once the allocation is approved, the 20 units
what was allocated; such as, if I allocate 20 allocated are committed to the stores on hand.
units to Store 123, what happens if the When the allocation is closed, indicating that the
warehouse is unable to only send 15 units for pick process is complete, any quantity allocated
various reasons? How will this impact store on which was not shipped or processed, will be
hands? decremented.

22 Oracle Retail
Question
If my allocation was based off a PO quantity
and now I see an ASN with a different
quantity, how do I adjust the allocation to
match the ASN quantity?
Why can’t I allocate an ARB PO type?
If I allocate an item which is placed on RMS
Replenishment, am I going to overstock the
stores?
How is store on hands calculated in
Allocation?
Does applying a Min Quantity Limit of 6
guarantee all stores are shipped 6 units?
Answer
If the allocation is not in “Progress” status, a user
would need to delete the allocation and recreate
it using the ASN as the source. Allocation does
offer the capability to switch sources.
This PO type was created from the RMS
Replenishment system. The PO is expected to fill
the store demand based off the replenishment
attributes used to create the PO.
No, both RMS Replenishment and Allocation
pull store inventory from the same location. Store
expected quantity from either Allocation or
Replenishment are captured in the RMS Inbound
Allocations inventory bucket.
SOH +InTransit+OnOrder+TSF
Expected+OnAlloc) -
(TSFOut+RTV+Unavailable+TSF Reserved
Allocation allows for the user to select specific
inventory criteria to use as On Hands to calculate
store Net Need, such as:
On Hands
On Order
In Transit
Back Order
Inbnd Allocation
Clearance Stock
No, Quantity Limits are applied against the
store’s calculated Net Need value; a Quantity
Limit of 6 will only ensure the store has a
minimum Net Need of 6. Based on the store’s on
hand, available quantity to allocate, store
calculation multiple and pack size will determine
what the store is actually shipped.
Oracle Retail Allocation 23
 Question
Does Allocation offer store priority logic to
ensure tops stores are never short shipped?
What exactly is the Calc Engine?
24 Oracle Retail
Answer
All stores on the allocation are considered equal
to receive its fair share of the available quantity.
The user can take advantage of Quantity Limits
to ensure specific sets of stores receive more or
less products if available.
Allocation does offer short ship logic when
available quantity at the warehouse is less than
allocated. The warehouse will determine which
stores are short shipped.
However RWMS does offer priority logic:
There are "priority" columns on the stock order
(feed from allocations) and stock order details
tables in RWMS. When used, the system will
completely fulfill priority 1 orders before priority
2 orders, 2 before priority 3, and so on. Available
numbers are 1 to 9. But these are not fed by RMS
at the current time. If RMS gives them to RWMS,
they will be used.
Since RWMS does not get these from RMS (or
Allocation), the client can populate them within
the RWMS database y creating some logic and a
script. However, the base product does have the
option to set a default priority for every
destination (every Store and DC). So, since
RWMS does not get this data from the RIB
interface from RMS, it is currently always using
the default value set up for the destination. This
should work very well for a client because they
can set DCs to be a higher number priority
(higher number = lower actual priority for
apportionment) than they set for stores.
This priority will be applied for cross-docking
inbound POs being allocated to Stores and DCs.
The “Calc Engine” is a library (.jar file) of
algorithms the Allocation product calls using
APIs. The “Calc Engine” is not a product; its
source code, which is proprietary information, is
not available to customers.
 Question Answer

What’s the difference between the Allocation
ID and the Distribution ID in RMS?
Or why does one Allocation ID = multiple
Distribution IDs?
This has to do with the way Allocation stores
allocation data versus the way RMS stores
allocation data. In Allocation, each allocation is
one record, and in RMS, each item/source is one
record in ALLOC_HEADER.
If you look at ALLOC_HEADER, you will see
that the records are unique by ALLOC_NO,
ORDER_NO, WH, ITEM, and RELEASE_DATE.
If you then look at ALLOC_DETAIL, you will see
that this table has one record for each location for
the ALLOC_HEADER record. Note that both of
these tables are RMS tables. ALC_XREF is an
Allocation table, but it follows a structure similar
to the ALLOC_HEADER table and just refers to
the other ALC* tables for details.
In ALC_ALLOC (an Allocation table), there is
one record per allocation (the record you see on
the portal screen), ALC_ITEM_SOURCE (also an
Allocation table) lists the item/warehouse/
PO/ASN/transfer/BOL, and ALC_ITEM_LOC
lists the locations and allocated quantities for an
allocation. 

Glossary
RMS – Oracle Retail Merchandising System
RWMS – Oracle Retail Warehouse Management System
RPAS – Oracle Retail Predictive Application Server
AP – Oracle Retail Assortment Planning (RPAS application)
SPO – Oracle Retail Size Profile Optimization (RPAS application)
RDF – Oracle Retail Demand Forecast
RPM – Oracle Retail Price Management
RETL – Oracle Retail Extract Transform and Load
RIB – Oracle Retail Integration Bus
RSL – Oracle Retail Service Layer
PO – Purchase Order
ASN – Advance Ship Notice
BOL – Bill of Lading
WH – Warehouse
DC – Distribution Center
UI – User Interface
UDA – User Defined Attribute
TSR – Target Stock Ratio
GN – Gross Need
OH – On Hands
OO – On Order
NN – Net Need

Oracle Retail Allocation 25

 MIN – Minimum
MAX – Maximum
WOS – Weeks of Supply
SKU – Stock Keeping Unit
SOM – Store Order Multiple
SCM – Store Calculation Multiple
.jar – Java Archive Files

26 Oracle Retail
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.

This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle
Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.