What is Allocation?

When a retailer buys 10,000 units of a new winter jacket and receives them into the central warehouse, the next question is: how many of those 10,000 units should go to each of the 500 stores?

This is the allocation problem. Sending too many to a small rural store wastes capital and shelf space. Sending too few to a high-volume urban store means lost sales. The goal is to maximize sell-through rate — getting as close to 100% of allocated units sold as possible.

Oracle Retail Allocation is the module that solves this. It takes a pool of inventory at a warehouse and distributes it across stores based on configurable logic — historical sales, store size, store grade, merchandise plan targets, or manual overrides.

Allocation vs. Replenishment

These two concepts are frequently confused. The key difference:

Allocation is about distributing new inventory. Replenishment is about maintaining ongoing inventory levels for established items. In practice, many items transition from allocation (initial distribution) to replenishment (ongoing automated ordering) after the first few weeks of sales data.

Allocation Methods

Oracle Retail Allocation supports several distribution methods:

1. Proportional Allocation (Based on History)

Distribute inventory proportionally based on historical sales performance. If Store A sold 30% of the total sales for a similar item last season, it receives 30% of the new allocation.

Store A historical sales = 3,000 (30% of total)
Store B historical sales = 5,000 (50% of total)
Store C historical sales = 2,000 (20% of total)

Total to allocate: 10,000 units

Store A allocation = 10,000 × 0.30 = 3,000
Store B allocation = 10,000 × 0.50 = 5,000
Store C allocation = 10,000 × 0.20 = 2,000

2. Store Grade Allocation

Instead of using individual store history, stores are grouped into grades (A, B, C, D) based on overall volume. Each grade receives a predetermined percentage:

3. Plan-Based Allocation

Distribute based on the Merchandise Financial Plan (MFP) targets built in RPAS. If the plan says Store A should do $50,000 in winter jacket revenue, allocation works backward from that target to determine the unit quantity.

4. Push Allocation

At end of season, remaining warehouse inventory must be distributed to stores regardless of demand. The goal is to empty the warehouse. Push allocation divides remaining stock evenly or by store capacity, with the intent that stores will clear the merchandise through markdowns.

5. Manual Override

For special items (exclusive launches, limited editions, flagship store allocations), allocators can manually specify exact quantities per store, overriding any calculated method.

Initial Allocation Workflow

┌─────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   BUYER     │───▶│  ALLOCATOR   │───▶│  ALLOCATION  │───▶│    RMS       │
│  Creates PO │    │  Creates     │    │  APPROVED    │    │  Creates     │
│  in RMS     │    │  Allocation  │    │              │    │  Transfers   │
│             │    │  Plan        │    │  Qty per     │    │  WH → Store  │
│  10,000 units│   │  Method +    │    │  Store       │    │              │
│  to WH      │    │  Store List  │    │  Finalized   │    │  Shipments   │
└─────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

1. Buyer creates a PO in RMS for 10,000 units of a new item, to be delivered to Warehouse 1.
2. Goods are received at Warehouse 1. RMS updates ITEM_LOC_SOH.STOCK_ON_HAND for the warehouse.
3. Allocator creates an allocation in the Allocation module, selecting:
   • Source warehouse
   • Items to allocate
   • Destination stores (from the item's ranged locations)
   • Allocation method (proportional, grade-based, plan-based)
4. System calculates quantities per store based on the selected method
5. Allocator reviews and adjusts quantities (rounding, minimum display quantities, store capacity constraints)
6. Allocation is approved — the system generates Transfer documents in RMS, one per store
7. Warehouse picks and ships the transfers
8. Stores receive using SIOCS

Quantity Calculation Logic

Beyond the basic allocation method, several constraints affect the final quantity:

Minimum Presentation Stock

Every store needs at least a minimum presentation stock — the minimum number of units to create a visible display. A single unit hanging on a rack looks like a mistake; 3–5 units create a proper display.

Pack Rounding

If items ship in packs of 6, allocations must round to multiples of 6. A calculated allocation of 14 units becomes either 12 or 18.

Store Capacity

Some stores have limited shelf space or backroom capacity. Allocation respects maximum stock levels to avoid over-shipping to space-constrained locations.

Size Curve Distribution

For fashion items with sizes (XS, S, M, L, XL), the total store allocation is further distributed across sizes using a size curve:

Size curves are determined by historical sales mix and vary by item category and store demographics.

Database Schema

SELECT 
    ah.item,
    im.item_desc,
    ah.wh            AS source_warehouse,
    COUNT(DISTINCT ad.to_loc)  AS stores_allocated,
    SUM(ad.qty_allocated)      AS total_allocated,
    SUM(ad.qty_transferred)    AS total_shipped,
    SUM(ad.qty_received)       AS total_received,
    SUM(ad.qty_allocated) 
      - SUM(ad.qty_transferred) AS pending_shipment,
    ah.status
FROM 
    alloc_header ah
JOIN 
    alloc_detail ad ON ah.alloc_no = ad.alloc_no
JOIN 
    item_master im ON ah.item = im.item
WHERE 
    ah.status IN ('APPROVED', 'CLOSED')
    AND ah.close_date >= TRUNC(SYSDATE) - 90
GROUP BY 
    ah.item, im.item_desc, ah.wh, ah.status
ORDER BY 
    total_allocated DESC;

Integration with RMS & POs

Allocation integrates tightly with RMS:

• Item Master: Allocation reads item data (department, class, subclass, item type) to determine applicable allocation rules
• Item-Location Ranging: Only stores where the item is actively ranged receive allocation
• PO Linkage: Allocations can be linked to specific POs, reserving incoming inventory before it physically arrives at the warehouse
• Transfer Creation: Approved allocations automatically create transfer documents in RMS, triggering the warehouse picking process
• Inventory Updates: As transfers ship and are received, RMS updates stock positions and the stock ledger

The Allocation Data Flow

Merchandise Plan (RPAS)  ──▶  Target Sales by Store
                                      │
                                      ▼
Historical Sales Data    ──▶  Allocation Calculation  ◀──  Store Grades
                                      │
                                      ▼
                              Allocation Document
                              (ALLOC_HEADER + DETAIL)
                                      │
                                      ▼
                              Transfer Creation (RMS)
                                      │
                         ┌────────────┼────────────┐
                         ▼            ▼            ▼
                     Store 101    Store 205    Store 340
                     80 units     50 units     30 units

Allocation Best Practices