6 Allocation Calculations

This chapter describes the calculations that are done during the allocation process. This chapter consists of the following sections:

• Calculation Queue Processing

• Satisfying Need Across Multiple Locations

• Rounding Conditions

• Store Calculation Multiple

• Size Profile Logic

• Allocation of Packs

• Cascade Allocations

• Pack Distribution Allocations

• MLD Calculation Flows

• Store Warehouse Relationship

• Scheduled Allocation

• Prepack Algorithm

• What if Future Fulfillment

Calculation Queue Processing

The following diagram offers an overview of the calculation queue process. Explanations of the numbered steps follow the diagram. Note that the numbers do not necessarily reflect the system's order of operation but are provided to facilitate the discussion of the process.

Figure 6-1 Oracle Retail Allocation Calculation Queue Process

Calculation Queue Process Description

1. A continuously running thread pulls an allocation to be calculated into the calculation queue.

   
   

   Note: Steps 2, 3, and 4 are repeated and processed through each tier in the supply chain if multi-level distribution (MLD) functionality is enabled. Multi-level distribution is the term used to describe the automation of inventory flow through n layers of locations to ultimately arrive at a final destination. For more information regarding Multi-level distribution (MLD), see Functional Design.

   
   

2. Need is gathered based upon the applicable rule and the data from the database. For example, the need gathered could be based upon plan data, sales history data, forecast data, plan re-project (Bayesian-calculated) data, and so on. These calculations are internal to the Java in Oracle Retail Allocation. For more information about the data that the system uses to generate gross need, see Functional Design.

3. On-hand is gathered, as necessary, from the database depending upon whether gross need or net need is desired. These calculations are internal to the Java in Oracle Retail Allocation. For more information about the source of on-hand data and how on-hand is calculated, see Functional Design.

4. The algorithm, an external library written in C++, is called to make a statistical determination of the best allocation possible given the parameters and constraints of the problem. Inputs passed to the algorithm function include the following:

   • Available quantity by item

   • An exact/proportional flag

   • Item-store matrices of need, on-hand, minimum, maximum, and threshold

   Cascade mode uses additional vectors for cascade-level targets, minimum, maximum, and threshold. Pack mode uses a matrix representing the pack component quantities.

   
   

   Note: Cascade mode is not applicable for the following: Non-sellable Complex Pack (Fashion Skus) - Pack SKU Non-sellable Complex Pack (Fashion + Staple Skus) Sellable Complex Pack (Fashion + Staple Skus) Multi Color Fashion Style Non-sellable/Sellable Complex Pack (Fashion + Staple) in Simple Mode

   
   

   Depending upon the mode (for example, simple, cascade, or pack) and the constraints of a given problem, an algorithm is selected to calculate the allocation, including an 'objective' function representing a relative score for the evaluation of different options. In every mode, the return values represent the item (pack)-store amount to be allocated and shipped. In all modes (for example, simple mode, cascade mode, and so on), optimization is performed through a heuristic algorithm.

5. The results are retrieved and saved to the database.

Queue Scripts

Oracle Retail Allocation includes sample scripts for queue management. These scripts are examples provided for the retailer's convenience.The queue process includes calculation prepack optimization, fashion recalculation, and all approval processes.There is no maximum number of queues that can be run at any given time. Processor and memory limits (specific to a retailer's implementation) on a given Windows or UNIX box determine a maximum number.

Start (queue.sh)

This script is used for queue management. The script calls set.sh to set variables that are needed to run the queue. The command syntax is as follows:

queue.sh start x

The command starts an instance of the queue. 'x' represents an integer which serves as the ID for the queue being started. This integer should be unique among all instances of the queue being run.

When the queue is started, the script attempts to create a log for the queue in a subdirectory of the current directory.

Note: This subdirectory is referred to as 'logs' in the script template.

Retailers can specify any location they wish for these log files. The referenced directory should be created prior to running the script. Existing log files are overwritten when a queue is started.

Stop (queue.sh)

The command syntax that stops an instance of the queue specified by the integer 'x' is as follows:

queue.sh stop x

Status (queue.sh)

The command syntax that provides status information about an instance of the queue specified by the integer 'x'. is as follows:

queue.sh status x

Restart (queue.sh)

The command syntax that stops and restarts an instance of the queue specified by the integer 'x' is shown below. The newly started instance of the queue contains a new process identification number (PID) and creates a new log file that replaces the existing log file.

queue.sh restart x

where 'x' represents the unique integer specifying the ID of the queue.

The QueueProcess utilizes the parameters passed in at execution time to know which type(s) of queue it is. The operative command used to start a queue is:

§                    java com..alloc.queue.QueueProcess <name> -standard_calculation -prepack -recalculation -approval_stores -approval_next_destination

where <name> represents any name you would like to use to refer to the queue.

Note: Some JDK implementations on UNIX boxes do not have the classic option. The '-classic' argument can be removed from the script/command or substituted with '-server' (if the server option exists on your JDK implementation).

Batch Queue (queue_batch_mode.sh)

To process allocations that have been selected for batch calculation by the user selecting the "Calculate Later" option, a systems administrator must schedule the nightly process. The start, stop and restart commands are the same as noted above. An example command used to start a batch queue is:

 queue_batch_mode.sh restart x

Plan Re-project Algorithm

A Bayesian algorithm is one that is based on a mathematical theorem developed in the eighteenth century by the Reverend Thomas Bayes. This theorem is a basic starting point for inference problems that use probability theory as logic.

The variables used in the Bayesian Algorithm are given below:

Table 6-1 Variables used in Bayesian Algorithm

Variable	Represents...
N	Number of periods in the current season (and N = for staple products).
M	Current Period.
p(j)	Sales plan for periods j = 1, …, N.
x(j)	Achieved sales for periods j = 1, ... , M.
	Constant between 0.0 and 1.0 (This parameter influences the balance between model sensitivity and robustness, that is, how responsive the model is to new sales data).

The equations used in the Bayesain Algorithm are:

Table 6-2 Equations used in Bayesian Algorithm

Equation	Represents...
	Sum of the sales plan up to the current period.
	Sum of the sales plan over the entire season.
	Sum of the achieved sales up to the current period.

Table 6-3 Final Forecasts

Equation	Represents...
	Convex combination of a scaled version of the sales plan and the original sales plan itself.

The motivation for this forecast is relatively clear. The scaled version of the sales plan is scaled based upon the ratio of the achieved historical sales to the historical sales plan (for example, if the retailer sold twice what it had planned to sell in the past, then the scaled plan would be twice the original plan). Thus, if the retailer had no confidence in the magnitude of the original sales plan (but still believed in its time profile or shape), then the scaled plan would probably be a good forecast on its own. On the other hand, if the retailer really still believes in the plan and the retailer does not believe that the recent past performance is indicative of future performance, then it would make sense to stick with the original sales plan as the forecast.

In the forecasting algorithm, the weights assigned to the scaled and original plans represent the confidence in the respective portions. As (P/P') becomes larger (that is, the portion of the plan that can be compared to historical sales increases), the retailer tends to have more confidence in the scaled plan. For example, if (P'/P'')= 0.01, then the retailer really does not have much information upon which to base the scaled plan. On the other hand, for example, as the quantity approaches 0.5 (that is, the season is half way over), then the retailer really should start seriously considering why the plan was incorrect. The retailer may have greater belief in the scaled plan. Additionally, the constant (represented by alpha in the Table 6.1) parameter is used to tweak the sensitivity of the forecasting method. As the constant increases, the forecast will tend to stay closer to the original plan. For small values of the constant, the forecast will move rapidly towards the scaled plan as historical sales data becomes available. Retailers should use their own data and judgment to determine an appropriate for their particular business problem at hand. For more information, see the section Bayesian Sensitivity Factor in Backend System Administration and Configuration.

Guidelines

Bayesian forecasting is primarily designed for use with new product-location positions. The following guidelines should be followed:

1. No more than one plan should exist for a given product-location position.

2. Any time period with non-zero actuals for a given product-location position should have a corresponding plan component (otherwise the system will assume a plan exists and equals zero and will act accordingly).

3. Any non-zero actuals not within the time period of interest should be overridden to zero.

Satisfying Need Across Multiple Locations

One way to think of the application's methodology is by comparing its process to that of water filling a container.

The fill line of the container represents 100% of need for all the locations, and the quantity of water available represents the stock available. By pouring all of the water into the container, the water level naturally reaches the target stock.

Suppose that the bottom of the container is partitioned, and each partition represents a different store.

The water would naturally level itself to maintain consistent stock across all stores. Suppose two of the following three conditions, as depicted in the accompanying chart:

• Stock is already available at each store.

• The height of each partition in the container represents the amount of that location's existing stock.

• The partitions are sorted from left to right in ascending stock percentages.

Figure 6-2 Stores' Existing Stock and Need Before Allocation

When this staircase container fills with water, all locations to the left of the waterline would receive an allocation quantity that satisfies need. All locations to the right of the waterline would not receive an allocation because their existing stock satisfies need. The final allocation does not guarantee that all stores end with the same percentage of need, but instead guarantees that all locations which receive an allocation has the same percentage of need and that all others are at or above this percentage of need.

Figure 6-3 Stores' Stock After Allocation

Rounding Conditions

Some allocation algorithms use rounding rules to determine when to round fractional components up or down to whole number answers. However, simple rounding often causes problems if not handled appropriately, including the allocation of too many or too few items. By using sophisticated optimization techniques, Oracle Retail's allocation algorithm deals in whole numbers directly and avoids rounding.

Store Calculation Multiple

A store calculation multiple refers to the multiple that the application allocates in during the calculation process. Valid multiples are pallet, case, inner and each. By determining the store calculation multiple, Oracle Retail Allocation has the ability to move inventory with multiples other than the supplier case size. This ability prevents over allocation to stores that have need levels below the supplier case size.

In a supply chain, not all warehouses have the ability to break cases. Oracle Retail Allocation accounts for this limitation by enforcing the case multiple at warehouses that cannot break cases, but breaking the inventory as soon as it encounters a break case warehouse within the MLD path. This design ensures that warehouses receive valid stock order quantities. The ability to indicate the multiple for the allocation is available for product sourced allocations and 'what if' allocations.

Oracle Retail Allocation has the ability for the user to define a separate multiple at PO creation time in the front end screen relating to 'what if' summary data.

Size Profile Logic

The system uses historical sales data to create a size profile (a graph) that illustrates how many units should be allocated by size. The data that answers the question is useful because the size of people in different regions can differ. For example, a question that could arise during an allocation might be: how many size 8 red shirts did a retailer sell in Chicago as opposed to Los Angeles? Retail Allocation calculates that the Los Angeles area needs x percentage more of smaller sized shirts than Chicago.

In order to allocate the correct quantity for fashion items, size profiles must exist; otherwise need is always calculated as zero. If size profiles are not used, then the Minimum Quantity Limit can be used to generate a calculated need; however it will be a flat distribution (ratio of 1:1) among the skus of the color/style. Size profiles can be extracted from files by using external applications like Size Profile Optimization or RDF Curve. Another option is to manually enter size profile data through the "Size Profile" page in the application. The "Allocation Home" page and the "Select Rule" page of the application have a link to the "Size Profile" page.

Note: In cascade mode only, the size profile is bypassed and not used for calculating the allocation for fashion items. Using size profile restricts the size distribution of a hierarchy level across multiple locations.

Enforce Size Profile

The logic in the application related to using size profile ratio is that it is just used as a guiding value while allocating fashion items and is not really a constraint.

In order to handle this, an option has been added in the form of a checkbox titled 'Enforce Store Size Profile' in the Rules UI in order to fulfill the style/color demand at a store either using the store size profile data as a guide or enforce the Allocation system to only fill the store demand if the size profile data associated with the store can be fully achieved across all eligible sizes, using an "all or nothing" logic. This will prevent stores from being allocated sizes above and beyond its associated store size profile data in order to meet total store demand.

If the user selects this option (checkbox is in the 'checked' state), the application logic will fill the store's demand only if the need values for all the sizes can be fully achieved based on store size profile data. If a store cannot be fully allocated with 100% alignment to its associated size profile data, this store will not be allocated and the user will be alerted that all the sizes of the fashion item are not available to successfully fill the total style/color demand using store size profile data as a constraint.

Fashion packs will also be supported as part of this requirement. If the 'Enforce Store Size Profile' checkbox is in the checked state, then the store will be allocated a pack only if:

• The demand can consume the pack size (using current 13.2.x logic > round up at 0.50)

• The pack size is in full alignment with the stores associated size profile data

Points to Note

• Target Stock Ratio (TSR) – Target Stock Ratio will still be applied using current logic when the total demand is greater than the total quantity that is available to allocate. After TSR has been applied, this new feature/logic will be applied against the results of TSR.

• Spread to All Locations – The user cannot spread additional quantity on top of the values allocated (based on the enforcement of size profile data) as this would represent 'counter-intuitive' logic.

• Proportional Mode – The user cannot spread additional quantity on top of the enforcement of size profile data by setting the calculation mode as 'Proportional' as this would be 'counter-intuitive' logic.

• Quantity Limits can be used to drive the allocation but cannot be used to push out additional quantity on top of the enforcement of size profile data as this would represent 'counter-intuitive' logic.

• The user is expected to be able to derive the fact that optimal results are achieved by enforcing size profile data from the Allocation Details screen. Values displayed in the UI after enforcing the size profile data cannot be overridden by the user if the box is in the checked state.

Allocation of Packs

Oracle Retail Allocation optimally allocates packs of multiple items based on stores' need for the individual component items in the packs. The benefit of this approach is that the system does not follow arbitrary rules for allocating packs and items. Instead, a consistent holistic approach is used. The potential answers are evaluated by how well the resulting allocation of component items satisfies the stores' need for the individual items. See front-end documentation for a definition of the two types of packs, sellable and non-sellable.

Note the following conditions that apply to sellable packs:

• A sellable pack is connected to plan data and to forecast data via the pack_no rather than the component items.

• The ITEM_LOC_HIST table is used to determine the item-level history for a sellable pack.

• The on-hand value for a sellable pack is for the pack rather than for the components.

Note the following condition that applies to non-sellable packs:

• When the user selects a style-color to allocate, the system retrieves all non-sellable packs that contain only that style-color.

• Retrieved non-sellable packs are not displayed for the user, but the contents of the pack are included in the available quantity.

• The on-hand value for a non-sellable pack is at the component level. The on-hand value can be generated for the style-color.

• The need value for a non-sellable pack is determined at the component level. The need value can be generated for the style-color.

• Allocation transactions respect both open stock (items) and the associated pack level.

By considering the entire matrix of available packs against component-store need for optimization, Oracle Retail Allocation provides a sophisticated solution for the distribution of multi-product packs.

The following example illustrates a relatively simple fashion prepack allocation:

The user selects a style to allocate. The system determines the availability of the style, in the warehouse or from a PO, and understands the quantity available to allocate and the prepack matrix (the component makeup of the pack). The user sees the total number of items available for the style, 420 units in the example below.

Table 6-4 Example for Fashion Prepack Allocation

Prepack Matrix				Packs Available	Items Available
	S	M	L
Pack 1	3	3	6	20	240
Pack 2	3	6	3	15	180

The user picks a rule that defines the need for the styles being allocated. Note that this need is for the style, not for the component items or for the packs.

Table 6-5 Examples for Style

Need for style
Store 1	150
Store 2	150
Store 3	100

The allocation system looks up the appropriate size curve for each style-store, based on the style or subclass. Size curves are not calculated during the allocation process. Oracle Retail Curve or another similar system is used to calculate size profiles.

Table 6-6 Examples for Size Curve

Size curve
	S	M	L
Store 1	20%	50%	30%
Store 2	20%	30%	50%

Need for each individual item is calculated by multiplying style need by the size curve.

Table 6-7 Examples for Item Need

Item need
	S	M	L	Total
Store 1	30	75	45	150
Store 2	30	45	75	150
Store 3	20	30	50	100

Finally the allocation algorithm determines the optimal allocation of packs. Inputs to the process are the Prepack Matrix, Packs Available, and Item Need above. Other inputs not shown in this example may be included (for example, minimum, maximum, threshold, store on-hands, and so on).

Table 6-8 Example for Pack Allocation

Pack allocation
	Pack 1	Pack 2
Store 1	1	12
Store 2	11	2
Store 3	8	1

The user sees the result in terms of number of allocated per style, as shown in the following table:

Table 6-9 Example for Style Allocation

Style allocation
	Need	Allocation
Store 1	150	156
Store 2	150	156
Store 3	100	108

The user can also view the results by individual item to make sure the size distribution is correct. If the distribution is poor, action may need to be taken such as the ordering of more products or the breaking packs before allocation.

Table 6-10 Example for Item Allocation

Item allocation
	S	M	L
Store 1	39	75	42
Store 2	39	45	72
Store 3	27	30	51

The objective of the algorithm is to minimize the variance between the actual allocation and need across all item-store combinations.

Algorithm with Packs and Singles

The algorithm determines the optimum result based on the overall allocation of every individual product. Both packs and singles are allocated to stores as needed. Packs, however, are preferred to singles in order to minimize the total number of units distributed, thereby lowering handling costs.

Cascade Allocations

In many circumstances, merchandise issues that come up at the item level can be accommodated by adjusting allocations at higher levels in the merchandise hierarchy. The Oracle Retail Allocation's allocation optimization algorithm is applied to cascade allocations.

The following example illustrates a cascade allocation:

The retailer is running an ad for t-shirts, with a picture of the yellow one. All t-shirts are displayed on a store table all together. The yellow t-shirt has been allocated, and the next step is to make sure that every store has an adequate stock of all t-shirts to support other customer choices.

On a per item basis, the simple mode allocation distributes as much quantity as is available, up to the calculated need. However, the cascade mode allocation exceeds the item need if it is necessary to meet the category need. The chart, "Total item need vs. allocation", illustrates that more of all the t-shirts are distributed by cascade mode, and that two of the t-shirts are allocated above and beyond their need in order to satisfy the total category demand.

Figure 6-4 Total item need vs. allocation

Note: The overstocking of two items, which takes place in this example, is due to the fact that constraints (for example, minimum, maximum, threshold, and so on) are not being used to limit the results. The example is designed to highlight the effects of the two different modes of calculating.

The chart, "Total category-store need vs. allocation", illustrates that the category need is exactly met by cascade mode. This simplistic example illustrates the system's preference for stocking the store for category performance rather than for mere item performance.

Figure 6-5 Total Category-Store Need vs. Allocation

To obtain these results, the user selects the t-shirts to be allocated, using a plan rule, at subclass (or any appropriate) level, in cascade mode. Remember that selecting cascade means instructing the allocation to favor the need to fill the t-shirt table, over the need or lack of available quantity for any specific shirt. Constraints such as minimum and maximum can be used to ensure the resulting assortment is reasonable.

Behind the scenes, the system determines setup information, including the number of items available to allocate, the number of items on hand at the stores, and the need by category-store.

Table 6-11 Available Items for Allocation

Item Available Quantity To Allocate
Style	Solid	Striped	Solid	Striped	Logo	Logo
Color	Yellow	Yellow	White	Blue	White	Blue	Total
Available	0	0	80	85	16	20	201

Table 6-12 Available Items at stores

Item On Hand At Stores
Style	Solid	Striped	Solid	Striped	Logo	Logo
Color	Yellow	Yellow	White	Blue	White	Blue	Total
Store 1	50	50	20	20	15	15	170
Store 2	30	30	10	5	10	10	95
Store 3	30	30	10	5	10	5	90
Total	110	110	40	30	35	30

Table 6-13 Category Need

Category Need And On-Hand At Stores
	Need	On-hand
Store 1	250	170
Store 2	125	95
Store 3	125	90

The next steps involve the examination of the need by category-store in order to determine the need by item-store. The following results occur when allocating using the Oracle Retail Allocation algorithm in simple and cascade mode. Cascade mode uses exactly the same information as simple mode, with the addition of the category targets. Constraints such as minimum, maximum, and threshold could be added to both calculations. Cascade mode can consider optional constraints at the category level.

Table 6-14 Simple Mode Allocation

Simple Mode Allocation - Not Cascade
Style	Solid	Striped	Solid	Striped	Logo	Logo
Color	Yellow	Yellow	White	Blue	White	Blue	Total
Store 1	0	0	0	0	5	5	10
Store 2	0	0	0	3	0	0	3
Store 3	0	0	0	4	0	4	8
Total	0	0	0	7	5	9

Table 6-15 Cascade Mode Allocation

Cascade-Mode Allocation
Style	Solid	Striped	Solid	Striped	Logo	Logo
Color	Yellow	Yellow	White	Blue	White	Blue	Total
Store 1	0	0	35	35	5	5	80
Store 2	0	0	7	12	6	5	30
Store 3	0	0	8	12	5	10	35
Total	0	0	50	59	16	20

Staple Cascade

The following diagram illustrate the system's approach to a staple cascade calculation.

Staple Cascade

Explanations of Pass 1 and Pass 2 follow the diagram.

Figure 6-6 Staple Cascade

Pass 1

GN1 = Gross need at a location

SOH1 = Sum of SOH for all items in ItemList-D-C-SC at that location

NN1 = Net Net (after Pass 1)

NN1 = GN1 - SOH1

Pass 2

Divide NN1 among all items (X) at a location [NN1x=NN1/3]

NN11 = Cascaded need for item 1 at the location

NN12 = Cascaded need for item 2 at the location

NN13 = Cascaded need for item 3 at the location

Each item-location still has individual SOH.

SOH21 = SOH for item 1 at the location

SOH22 = SOH for item 2 at the location

SOH23 = SOH for item 3 at the location

Need applied to each individual item at the location

NN21 = NN11- SOH21

NN22 = NN12- SOH22

NN23 = NN13- SOH23

Staple Items - Cascade with RLOH

Staple Items in Cascade mode with Rule Level On-Hand (RLOH) has to be allocated as illustrated in the following example:

Table 6-16 Example of Rule Level On-Hand

Dept	1	Men's
Class	12	Tops
SubClass	123	S/S Logo T's

Table 6-17 Allocated Quantity

Total Available To Allocate
SKU	Description	Warehouse Quantity	Percentage of the total warehouse quantity (PCTT1)
SKU1	Flag Logo Tee	60	33.3333%
SKU2	Eagle Logo Tee	50	27.7778%
SKU3	Classic Car Logo Tee	40	22.2222%
SKU4	Beach Logo Tee	30	16.6667%
Total Warehouse Quantity On-Hand		180

Table 6-18 Historical Data

Based on Historical Sales; Subclass; Last 4 Weeks
Store	Last Week Sales	Last Two Weeks Sales	Last Three Weeks Sales	Last Four Weeks Sales	SUM1
101	88	72	64	59	283
102	69	54	44	56	223
103	56	50	52	58	216
104	32	53	44	29	158

Table 6-19 Calculated Quantity

Calculated Quantity				Alloc Qty	Alloc Qty	Alloc Qty	Alloc Qty	Alloc Qty
Store	SUM1	OH1	Need1	SKU1	SKU2	SKU3	SKU4	Total
101	283	202	81	27	23	18	13	81
102	223	188	35	12	10	8	6	35
103	216	200	16	5	4	4	3	16
104	158	125	33	11	9	7	5	33
Total	880	715	165	55	46	37	27	165

Need1 = SUM1 - OH1 (respective to Store/SKU)

Alloc Qty SKUx = Need1 * PCTT1 (respective to Store/SKU)

Staple Items - Cascade without RLOH

Staple items in Cascade mode without Rule Level On-Hand (RLOH) has to be allocated as illustrated in the example given below. The allocation is based on the onhands of the skus rather than the subclass (which was the rule level in this example).

Table 6-20 Allocated Quantity

Total Available To Allocate
SKU	Description	Warehouse Quantity	Percentage of the total warehouse quantity (PCTT1)
SKU1	Flag Logo Tee	360	26.08696%
SKU2	Eagle Logo Tee	350	25.3623%
SKU3	Classic Car Logo Tee	340	24.6377%
SKU4	Beach Logo Tee	330	23.9130%
Total Warehouse Quantity On-Hand		1380

Table 6-21 Historical Data

Based on Historical Sales; Subclass; Last 4 Weeks
Store	Last Week Sales	Last Two Weeks Sales	Last Three Weeks Sales	Last Four Weeks Sales	SUM1
101	88	72	64	59	283
102	69	54	44	56	223
103	56	50	52	58	216
104	32	53	44	29	158

Table 6-22 Calculated Quantity

Calculated Quantity				Alloc Qty	Alloc Qty	Alloc Qty	Alloc Qty	Alloc Qty
Store	SUM1	OH1	Need1	SKU1	SKU2	SKU3	SKU4	Total
101	283	40	243	63	62	60	58	243
102	223	55	168	44	43	41	40	168
103	216	30	186	49	47	46	44	186
104	158	68	90	23	23	22	22	90
Total	880	193	687	179	175	169	164	687

Need1 = SUM1 - OH1 (respective to Store/SKU)

Alloc Qty SKUx = Need1 * PCTT1 (respective to Store/SKU)

Fashion Cascade

The following diagram illustrate the system's approach to a fashion cascade calculation:

Figure 6-7 Fashion Cascade

Pass 1

GN=Gross Need at a location

Pass 2

Divide GN among all styles at given location to get GN, and subtract SOH, for each style-color to get NNx

NN1 = GN1- SOH1

NN2 = GN2- SOH2

NN3 = GN3- SOH3

Pass 3

Explode NNx out to sizes to get applied net need NNxy

Table 6-23 Example for Cascade mode

Style 1	Style 2	Style 3
NN11	NN21	NN31
NN12	NN22	NN32
NN13	NN23	NN33

Fashion Items - Cascade with RLOH

Cascade treats the items being allocated as a single unit, using a percentage contribution for each item against the total availability. Fashion items in cascade mode with Rule Level On-Hand (RLOH) should be allocated as illustrated in the following example:

Table 6-24 Example for Rule Level On-Hand

Dept	Class	SubClass
1	13	112
Women's	Sweaters	Knit

In the table given below, the percentage of total quantity is arrived at by dividing the Available Quantity by the Total available quantity to allocate.

Table 6-25 Available Quantity

Color	SKU	Available Quantity	Percentage of the total quantity
Black	564321	75	35.2113%
Yellow	564322	44	20.6573%
Blue	564325	38	17.8404%
Pink	574328	56	26.2911%
Total available quantity to allocate ----------------->213

Table 6-26 Historical Data

Rule	History		History		History
Level	Dept >1		Class > 13		Sub class > 112
Date Range	Last four weeks		Last four weeks		Last four weeks
Store	Sales	On hands	Sales	On hands	Sales	On hands
101	675	589	132	115	36	6
124	580	602	102	82	38	22

Since the rule level on hand is being used, each store uses its own unique on hands at the CLASS level. For example, store 101 would use the on hands of 115, and store 124 would use the on hands of 82.

Table 6-27 Calculations

Percentage of Total Quantity				35.2113%	20.6573%	17.8404%	26.2911%	100%
				Black	Yellow	Blue	Pink
Store	Gross Need	OH	Net Need	564321	564322	564325	574328	Total Alloc	Class OH	Total Ownership= Total Alloc + Class OH
101	132	115	17	6	4	3	4	17	115	132
124	102	82	20	7	4	4	5	20	82	102

Cascade mode calculations are based on the net need. For example, the cascade mode calculations for black-knit sweater yields 6 for store 101 (35% of 17), and 7 for store 124 (35% of 20 - the net need).

Fashion Items - Cascade without RLOH

The difference while calculating allocations in cascade mode for fashion items is the way in which net need is calculated. How the cascade mode calculations arrive at the net need for stores 101 and 124 without Rule Level On-Hand (RLOH) is illustrated in the example given below.

Table 6-28 Example for Fashion Items - Cascade without RLOH

Dept	Class	SubClass
1	13	112
Women's	Sweaters	Knit

In the table given below, the percentage of total quantity is arrived at by dividing the Available Quantity by the Total available quantity to allocate.

Table 6-29 Available Quantity

Color	SKU	Available Quantity	Percentage of the total quantity
Black	564321	75	35.2113%
Yellow	564322	44	20.6573%
Blue	564325	38	17.8404%
Pink	574328	56	26.2911%
Total available quantity to allocate ----------------->213

Since the cascade mode calculations are not considering the rule level on hand, each store uses its own unique on hands at the SKU level (sum of on hands for SKUs being allocated respective to store). For example, at the store 101 and 124, the individual on-hands at each of the SKU is considered:

Store 101 - 2+0+2+2

Store 124 - 8+5+6+3

Table 6-30 Historical Data

Rule	History		History		History		History		History		History		History
Level	Dept >1		Class > 13		Sub class > 112		SKU> 564321		SKU> 564322		SKU> 564325		SKU> 564328
Date Range	Last four weeks		Last four weeks		Last four weeks		Last four weeks		Last four weeks		Last four weeks		Last four weeks
Store	Sales	On hands	Sales	On hands	Sales	On hands	Sales	On hands	Sales	On hand	Sales	On hand	Sale	On hand
101	675	589	132	115	36	6	8	2	12	0	9	2	7	2
124	580	602	102	82	38	22	10	8	9	5	11	6	8	3

Cascade mode calculations are based on the net need. For example, the cascade mode calculations for black-knit sweater yields 44 for store 101 (35.2113% of 126), and 28 for store 124 (35.2113% of 80 - the net need).

Table 6-31 Calculations

Percentage of Total Quantity				35.2113%	20.6573%	17.8404%	26.2991%	100%
				Black	Yellow	Blue	Pink
Store	Gross Need	OH	Net Need	564321	564322	564325	574328	Total Alloc	Class OH	Total Ownership = Total Alloc + Class OH
101	132	6	126	44	26	22	33	126	115	241
124	102	22	80	28	17	14	21	80	82	162

Cascade with Fashion Items belonging to different levels

For cascade mode calculations with fashion items belonging to different levels, there are two types:

• Cascade with RLOH

• Cascade without RLOH

Cascade with RLOH for Items belonging to different levels

The example for cascade mode calculations with RLOH for items belonging to different levels is illustrated below:

Table 6-32 Example for items belonging to different levels

Rule	History		History
Level	Dept 1		Dept 2
Date Ranges	Last four weeks		Last four weeks
RLOH	n/a		n/a
Store	Dept Sales	On Hands (For Dept)	Dept Sales	On hands (For Dept)
999	4521	2500	2245	750

Percent contribution for each item against total availability is calculated as: 5000÷15000 = 33.3333% 10000÷15000 = 66.6667%Later, these percentages are used to apply the 'cascade' to Net Need as shown in the table given below.

Table 6-33 Items at Dept Level 1

Color	Dept	Available Qty	Percentage of the Total Quantity
Item 1	1	5000	33.3333%
Item 2	1	10000	66.6667%
Total Available to Allocate------------------------>		15,000	100%

Table 6-34 Items at Dept Level 2

Color	Dept	Available Qty	Percentage of the Total Quantity
Item 3	2	2000	40%
Item 4	2	3000	60%
Total Available to Allocate------------------------>		5,000	100%

Table 6-35 Cascade Mode Calculations

Store 999	Gross Need	On-Hand (total of the level)	Net Need	Alloc Qty
Item 1	4521	2500	4521-2500=2021	2021*33.3333%=673
Item 2	4521	2500	4521-2500=2021	2021*66.6667%=1347
Item 3	2245	750	2245-750=1495	1495*40%=598
Item 4	2245	750	2245-750=1495	1495*60%=897

Cascade without RLOH for Items belonging to different levels

The cascade mode calculations without RLOH for items belonging to different levels has been given in the tables below.

Table 6-36 Example for items belonging to different levels

Rule		History		History
Level		Dept 1		Dept 2
Date Ranges		Last four weeks		Last four weeks
RLOH
Store	Item	Dept Sales	On Hands (For Dept)	Dept Sales	On hands (By Item)
999	1	4521	100
	2	4521	150
	3			2245	25
	4			2245	50
	5	4521	2250
	6			2245	675
	Dept Totals	4521	2500	2245	750

Percent contribution for each item against total availability is calculated as: 5000÷15000 = 33.3333% 10000÷15000 = 66.6667%Later, these percentages are used to apply cascade calculations to 'Net Need' as shown in table given below.

Table 6-37 Items at Dept Level 1

Color	Dept	Available Qty	Percentage of the Total Quantity
Item 1	1	5000	33.3333%
Item 2	1	10000	66.6667%
Total Available to Allocate---------------------->		15,000	100%

Table 6-38 Items at Dept Level 2

Color	Dept	Available Qty	Percentage of the Total Quantity
Item 3	2	2000	40%
Item 4	2	3000	60%
Total Available to Allocate---------------------->		5,000	100%

Table 6-39 Cascade Mode Calculations

Store 999	Gross Need	On-Hand (total of the level)	Net Need	Alloc Qty
Item 1	4521	100+150=250	4521-250=4271	4271*33.3333%=1424
Item 2	4521	150+100=250	4521-25=4271	4271*66.6667%=2847
Item 3	2245	25+50=75	2245-75=2170	2170*40%=868
Item 4	2245	50+25=75	2245-75=2170	2170*60%=1302

Cascade Mode Calculations for Pack SKUs

The cascade mode calculations are applicable for packs. The cascade mode is enabled for the following types of packs:

• Sellable Staple Simple Pack

• Sellable Staple Complex Pack

• Sellable Fashion Simple Pack

• Sellable Fashion Complex Pack

• Non-sellable Staple Simple Pack

• Non-sellable Staple Complex Pack

Sellable Staple Simple Pack in Simple Mode

An example of the sellable staple simple pack in simple mode is given below:

Table 6-40 Example

Dept	1	Hardware
Class	12	Tools
Subclass	123	Hand Tools

Table 6-41 Different Packs

Pack	Description	Warehouse Quantity (Pack)	Warehouse Quantity (Units)
1	Hammer (5 units)	500	2500
2	Screwdriver (10 units)	350	3500
3	Handsaw (15 units)	250	3750
Total quantity on hand--------->		1100

For sellable packs, the transaction level is the sellable unit, hence sales history is recorded at the pack level as shown in the Dept Sales column of the table below. For sellable packs, the store owns the product at pack level. When a pack is sold, one pack is deducted from stock on hand. Sales are also recorded at the sellable unit which is pack.

Table 6-42 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

Table 6-43 The Final Calculations

Store No	Pack	Gross Need	OH (total of the level)	Net Need	Final Quantity
999	Pack 1	3967	125	3967-125=3842	3842
	Pack 2	3967	140	3967-140=3827	3827
	Pack 3	3967	130	3967-130=3837	3837

Sellable Staple Simple Pack in Cascade Mode

The following example illustrates the cascade calculations for the sellable staple simple pack:

Table 6-44 Example

Dept	1	Hardware
Class	12	Tools
Subclass	123	Hand Tools

The percentage contribution for each item is calculated as shown below:

Table 6-45 Different Packs

Pack	Description	Warehouse Quantity (Pack)	Percent of total
1	Hammer (5 units)	500	500/1100=45.4545%
2	Screwdriver (10 units)	350	350/1100=31.8182%
3	Handsaw (15 units)	250	250/110=22.7273%
Total quantity on hand--------->		1100

For sellable packs, the transaction level is the sellable unit, hence sales history is recorded at the pack level as shown in the Dept Sales column of the table below. For sellable packs, the store owns the product at component level. When a pack is sold, the components are deducted from the stock on hand.

Table 6-46 Dept Sales and On Hands for Sellable Packs

Rule		History
Level		Dept 1
Date Ranges		Last 4 Weeks
Available Quantity		1500
RLOH		n/a
Store	Pack	Dept Sales	On Hands
999	1	3967	125
	2	3967	140
	3	3967	130
	Dept Totals	3967

Onhands for Sellable Packs are not recorded at pack level through RMS, only the pack components have onhands. Thus, onhands for sellable packs = 0. Since the final quantity is pack quantity, the calculations do not go through any pack optimization process in the calc engine.

Table 6-47 The Final Calculations

Store No	Pack	Gross Need	OH (total of the level)	Net Need	Final Quantity
999	Pack 1	3967	0	3967	3967*45.4545%= 1803
	Pack 2	3967	0	3967	3967*31.8182%=1262
	Pack 3	3967	0	3967	3967*22.7273%=902

Note: The final calculations given above in the example above is applicable for sellable staple simple pack with zero on-hands at the rule level in cascade mode.

Sellable Simple Staple Pack at Gross Need with Cascade mode

Cascade mode is calculated based on net need. However, if the calculations are to be based on the gross need, the following example illustrates the method:

The example given in Table 7-36 is considered here again.

Table 6-48 Example

Dept	1	Hardware
Class	12	Tools
Subclass	123	Hand Tools

The percentage contribution for each item is calculated as shown below:

Table 6-49 Different Packs

Pack	Description	Warehouse Quantity (Pack)	Percent of total
1	Hammer (5 units)	500	500/1100=45.4545%
2	Screwdriver (10 units)	350	350/1100=31.8182%
3	Handsaw (15 units)	250	250/110=22.7273%
Total quantity on hand--------->		1100

Later, these percentages are used to apply the 'cascade' to Net Need.

As shown in the table below, for sellable packs, the transaction level is the sellable unit; therefore sales history is recorded at the pack level.

Table 6-50 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

When calculating at Gross Need, the on-hands are not considered. This is illustrated in the table below:

Table 6-51 The Final Calculations

Store No	Pack	Gross Need	OH (total of the level)	Net Need	Final Quantity
999	Pack 1	3967	0	3967	3967*45.4545%= 1803
	Pack 2	3967	0	3967	3967*31.8182%=1262
	Pack 3	3967	0	3967	3967*22.7273%=902

Since the final quantity is pack quantity, it does not go through any pack optimization process in the calc engine. Note that no changes are being made to the calc engine.

Sellable Staple Complex Pack in Cascade Mode

Note: If using rule level for complex pack, components must come from the same hierarchy (up to subclass level). If components are from different hierarchy levels, allocator must use "User Selection" to define where need is coming from.

The following illustrates the calculations for sellable staple complex pack in cascade mode:

Table 6-52 Example

Dept	1	Hardware
Class	12	Tools
Subclass	123	Hand Tools

The percent contribution for each pack against total availability is calculated as: 500÷950 = 52.6316% 450÷950 = 47.3684%Later, these percentages are used to apply 'cascade' to Net Need.

Table 6-53 Different Packs

Pack	Description	Warehouse Quantity (Pack)	Percent of Total
1	Complex Pack 1	500	52.6316%
	Hammer (5 units)
	Screwdriver (10 units)
2	Complex Pack 2	450	47.3684%
	Handsaw (15 units)
	Drill (4 units)
Total quantity on hand-------->		950

For sellable packs, the transaction level is the sellable unit, hence sales history is recorded at the pack level. For sellable packs, the store owns the product at component level. When a pack is sold, the components are deducted from stock on hand.

Table 6-54 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	180
	2	3967	240
	Dept Totals	3967

Onhands for Sellable Packs are not recorded at pack level through RMS, only the pack components have onhands. Thus, onhands for sellable packs = 0. Since the final quantity is pack quantity, it does not go through any pack optimization process in the calc engine. Note that no changes are being made to the calc engine.

Table 6-55 The Final Calculations

Store No	Pack	Gross Need	OH (total of the level)	Net Need	Final Quantity
999	Pack 1	3967	0	3967-0 = 3967	3967*52.6316%= 2088
	Pack 2	3967	0	3967-0=3967	3967*47.3684%=1879

Sellable Fashion Simple Pack in Cascade Mode

The following example illustrates calculations for a sellable fashion simple pack in cascade mode

Table 6-56 Example for Sellable Fashion Simple Pack

Dept	1	Women's
Class	12	Casual
Subclass	123	Tops

Table 6-57 Different Packs

Pack	Description	Warehouse Quantity (Pack)	Warehouse Quantity (Units)
1	Round Neck:White:Small (5 units)	500	45.4545%
2	V Neck:White:Medium (10 units)	350	31.8182%
3	Scoop Neck:White:Medium (15 units)	250	22.7273%
Total quantity on hand		1100

Table 6-58 Dept Sales and On Hands for Sellable Fashion Simple 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

Table 6-59 The Final Calculations

Store No	Pack	Gross Need	OH (total of the level)	Net Need	Final Quantity
999	Pack 1	3967	0	3967-0=3967	3967*45.4545%=1803
	Pack 2	3967	0	3967-0=3967	3967*31.8182%=1262
	Pack 3	3967	0	3967-0=3967	3967*22.7273%=902

Sellable Fashion Complex Pack in Cascade Mode

Note: If using rule level for complex pack, components must come from the same hierarchy (up to subclass level). If components are from different hierarchy levels, you must use "User Selection" to define where need is coming from.

The following example illustrates the cascade mode calculations for sellable fashion complex pack:

Table 6-60 Example for Sellable Fashion Complex Pack

Dept	1	Women's
Class	12	Business
Subclass	123	Casual

Percent contribution for each pack against total availability is calculated as: 500÷950 = 52.6316% 450÷950 = 47.3684%Later, these percentages are used to apply the 'cascade' to Net Need.

Table 6-61 Different Packs

Pack	Description	Warehouse Quantity (Pack)	Percent of Total
1	Complex Pack 1	500	52.6316%
	Jacket:Black:Med (5 units)
	Pants:Black:Med (100 units)
2	Complex Pack 2	450	47.3684%
2	Cardigan:Red:Large (3 units)
3	Skirt:Red:Large (4 units)
Total quantity on hand		950

For sellable packs, the transaction level is the sellable unit; therefore sales history is recorded at the pack level. For sellable packs, the store owns the product at component level. When a pack is sold, the components are deducted from stock on hand.

Table 6-62 Dept Sales and On Hands for Sellable Fashion Complex Packs

Rule		History
Level		Dept 1
Date Ranges		Last 4 Weeks
RLOH		n/a
Store	Pack	Dept Sales	On Hands
999	1	3967	180
	2	3967	240
	Dept Totals	3967

Onhands for sellable packs are not recorded at pack level through RMS, only the pack components have onhands,. Thus, onhands for sellable packs = 0 as shown in the table below. Since the final quantity is pack quantity, it does not go through any pack optimization process in the calc engine. Note that no changes are being made to the calc engine.

Table 6-63 The Final Calculations

Store No	Pack	Gross Need	OH (total of the level)	Net Need	Final Quantity
999	Pack 1	3967	0	3967-0=3967	3967*52.6316%=2088
	Pack 2	3967	0	3967-0=3967	3967*47.3684%=1879

Non-sellable Staple Simple Pack in Cascade Mode

The following example illustrates the cascade mode calculations for non-sellable staple complex pack:

Table 6-64 Example for Non-Sellable Fashion Complex Pack

Dept	1	Hardware
Class	12	Tools
Subclass	123	Handtools

Percent contribution for each pack against total availability is calculated as: 500÷1100 = 45.4545% 350÷1100 = 31.8182%Later, these percentages are used to apply the 'cascade' to Net Need.

Table 6-65 Different items

Pack	Description	Warehouse Quantity (Pack)	Ware house Quantity (units)	Percent of Total
1	Hammer (5 units)	500	2500	45.4545%
2	Screwdriver (10 units)	350	3500	31.8182%
3	Handsaw (15 units)	250	3750	22.7273%
Total quantity on hand		1100

For non-sellable packs, the transaction level is in units, therefore sales history is recorded at the unit level. For non-sellable packs, the store owns the product at component level. The store cannot sell the pack. It can only sell the components after breaking the pack.

Table 6-66 Dept Sales and On Hands for Non-Sellable Staple Simple Packs

Rule		History
Level		Dept 1
Date Ranges		Last 4 Weeks
RLOH		n/a
Store	Pack	Dept Sales	On Hands
999	1	3967	250
	2	3967	400
	3	3967	300
	Dept Totals	3967

As inventory is stored at pack level, the unit need has to be converted to pack size. Since the logic for pack optimization already exists in the Calculation Engine, it will be used to determine the optimal number of packs. No changes for pack optimization are being made to the Calculation Engine.

Table 6-67 The Final Calculations

Store 999	Gross Need	OH (total of the level)	Net Need	Final Quantity
Pack 1	3967	250+400+300=950	3967-950=3017	3017*45.4545%=1371
Pack 2	3967	250+400+300=950	3967-950=3017	3017*31.8182%=960
Pack 3	3967	250+400+300=950	3967-950=3017	3017*22.7273%=686

Non-sellable Staple Complex Pack in Cascade Mode

Note: If using rule level for complex pack, components must come from the same hierarchy (up to subclass level). If components are from different hierarchy levels, you must use "User Selection" to define where need is coming from.

The following example illustrates the cascade mode calculations for non-sellable staple complex pack:

Table 6-68 Example for Non-Sellable Staple Complex Pack

Dept	1	Hardware
Class	12	Tools
Subclass	123	Handtools

Percent contribution for each pack against total availability is calculated as: 500÷950 = 52.6316% 450÷950 = 47.3684%Later, these percentages are used to apply the 'cascade' to Net Need.

Table 6-69 Different Packs

Pack	Description	Warehouse Quantity (Pack)	Ware house Quantity (units)	Percent of Total
1	Complex Pack 1	500		52.6316%
	Hammer (5 units)		2500
	Screwdriver (10 units)		5000
2	Complex Pack 2	450		47.3684%
	Hand Saw (3 units)		1350
	Drill (4 units)		1800
Total quantity on hand		950

For non-sellable packs, the transaction level is in units, therefore sales history is recorded at the unit level. For non-sellable packs, the store owns the product at component level. The store cannot sell the pack. It can only sell the components after breaking the pack.

Table 6-70 Dept Sales and On Hands for Non Sellable Staple Complex Packs

Rule		History
Level		Dept 1
Date Ranges		Last 4 Weeks
RLOH		n/a
Store	Pack	Dept Sales	On Hands
999	1: Hammer	3967	100
	1:Screwdriver	3967	200
	2:Hand Saw	3967	300
	2: Drill	3967	400
	Dept Totals	3967

As inventory is stored at pack level, the unit need has to be converted to pack size. Since the logic for pack optimization already exists in the calculation engine, it is used to determine the optimal number of packs. No changes for pack optimization are made to the calculation engine. In the case of non-sellable staple complex packs, the current logic uses the max pack quantity to derive the allocation quantity. For example: Pack 1: Hammer (5 units) and Screwdriver (10 units) --> 10 = max packPack 2: Handsaw (3 units) and Drill (4 units) --> 4 = max pack

Table 6-71 The Final Calculations

Store 999	Gross Need	OH (total of the level)	Net Need	Final Quantity
Pack 1	3967	100+200+300+400=1000	3967-1000=2967	2967*52.6316%=1562
Pack 2	3967	100+200+300+400=1000	3967-1000=2967	2967*47.3684%=1405

Non-sellable Staple Pack Combinations for Cascade Mode Only

Non-Sellable Staple Packs, whether simple or complex, should be allocated only with other non-Sellable Staple Packs (simple or complex). The reasons are:

• To get the most optimal results for allocation, it is best practice to allocate the Non-Sellable Staple Packs first in order to commit the store on-hands. If the Non-Sellable Staple Packs didn't fulfill the need, then other allocations can be created for items/sellable packs to satisfy the need.

Sellable Pack Combinations for Cascade Mode Only

A Sellable pack, whether it contains Staple Items or Fashion Items as its constituents, is treated the same way as a Staple Item (aka Staple Unit). Inventory, need, and on-hand for a sellable pack are maintained at the pack level, thus there is little or no difference in the allocation of Staple Items or Sellable Packs.

Currently, a Fashion Item and a Staple Item cannot be allocated together within the same allocation. Technically, since a Sellable Fashion Pack is treated like a Staple Item, it is feasible to allocate both a Sellable Fashion Pack and Staple Items/Sellable Staple Packs within the same allocation. However, to maintain consistency that Fashion and Staple Items can't be allocated together at the same time, the following are stated as valid combinations:

• Sellable Staple Pack (simple or complex) can be allocated with another Sellable Staple Pack (simple or complex)

• Sellable Fashion Pack (simple or complex) can be allocated with another Sellable Fashion Pack (simple or complex)

• Sellable Staple Pack (simple or complex) can be allocated with Staple Items

Non-Sellable Complex Fashion Pack in Cascade Mode

Non-sellable Complex Fashion Packs cannot be selected as a pack. However if there is a Non-Sellable Complex Fashion Pack associated with a Style/Color (Skus of the Style/Color being the components of the Non-Sellable Complex Fashion Pack) and some inventory is maintained at the Pack level, then the user can search for the Style/Color and allocate it.

When the allocation is approved, the allocation details such as the number of packs and individual skus allocated, are populated in the DB tables ALC_XREF, ALC_ITEM_LOC etc. Although from the front end it is not possible to allocate Non-Sellable Fashion Packs, internally packs are allocated and the relevant information is stored in the database. Therefore, Cascade is valid for Non-sellable Complex Fashion Packs through style/color and not the pack.

Pack Distribution Allocations

At times there are business cases in which a user needs to distribute multiple packs to those stores which are in need of more product. The user's objective is to distribute a variety of packs instead of sending multiples of the same pack configuration to the same store. As each pack attempts to meet demand on its own, the final allocated results can be non-intuitive and confusing for the user. New logic was needed with a much simpler approach, also allowing for the end user to clearly understand the system logic and overall final distribution results.

Pack Distribution is a technique to ensure that a variety of packs are distributed to the stores using a round robin like methodology. The user has full control to decide the number of packs to be distributed. The logic begins with the largest pack configuration, and starts with the location with the highest demand. The distribution of packs continues in a top/down manner until a store can no longer consume another pack or until there are no more packs to distribute.

The objective of Pack Distribution is not to fill store demand, rather use the store's demand as a mechanism to rank the stores in priority order of need. In this mode, to ensure that total optimal results are achieved, it is expected that the total store demand be much greater than total available quantity. Non Sellable Staple Packs and Non Sellable Fashion Packs can be distributed using this mode.

In this mode, a single store demand/value is sent to the Calculation Engine that is used to rank the store in priority order (highest to lowest). If two or more stores have the same demand then priority is given to the store which is processed first. Packs are not distributed to stores with no demand. If all packs have the same size, then packs with the largest availability quantity are distributed first. If all packs have the same size and availability quantity, then priority is given to the pack that is processed first.

A store does not receive a pack if the store need is less than 50% of the pack size. For example, let the demand for Store 101 = 100, and size of pack A = 80. After receiving one of pack A, the need of the store = 20. Store 101 does not receive a second Pack A as the need is less than 50% of the pack size. In order to receive a second Pack A, the store must have a remaining need of 40 or higher. If there is a smaller pack available such as Pack B (size = 15), when the distribution occurs for pack B, store 101 is then eligible to receive pack B since it meets the 50% rule.

The type of components within the Non Sellable Staple Complex packs is not a factor in pack priority. Regardless of the items within the Non Sellable Staple Complex packs (whether components are completely different in each pack or if the components are repeated in other packs), the Calculation Engine only considers the pack size and pack availability.

Note: For Non Sellable Fashion packs, Store Size Profile is completely bypassed during calculation since Pack Distribution mode must ensure that all stores get at least a pack.

The following is an example to show that pack contents are not a factor in pack priority and when pack sizes are the same, priority is given according to the available quantity.

Table 6-72 Pack Configurations

Component	Pack A	Pack B	Pack C
White Tee XSmall	1
White Tee Small	1	2	1
White Tee Medium	1	2	1
White Tee Large	1	1	2
White Tee XLarge	1	1	2
White Tee XXLarge	1
Pack Size	6	6	6
Pack Availability	20	30	25

Here, the packs are distributed in the order of Pack B, Pack C and Pack A.

If Non Sellable Staple Complex packs contain components that belong to different merchandise hierarchies, then you must choose User Selection to generate demand. All subclasses, classes, or departments are not equal in performance (sales and on hands). For example, there may be times when you have a new subclass or a subclass that represents heavy clearance sales or a subclass which is overstocked. Using User Selection, you must decide the hierarchies to be used to obtain store demand for the pack distribution logic.

Variance Percent Calculation

The variance percent calculation for pack items is as follows:

Variance% = [((Final Quantity + On Hand) - Gross Need)/(Gross Need + 0.001)]*100

The variance percent calculation for sellable complex pack in simple mode is based on the same formula as given above except that the Final Quantity is a product of the number of final packs and the number of components in each pack. An example follows:

Table 6-73 Sellable Complex Pack in Simple Mode

Item	Gross Need	SOH	Future Fulfillment	Net Need	Calc	Final
Pack 'A'	42	0	0	42	3	3

Variance% = [[((3*4)+0)-42]/(42+0.001)]*100 = -71%

The variance percent calculation for cascade mode is as follows:

Variance% = [(Final Quantity - Net Need)/(Net Need + 0.001)] * 100

MLD Calculation Flows

In this section, the MLD Calculation Flow for staple and fashion items are discussed.

Staple MLD Calculation

The staple MLD allocation is calculated in three phases. The three phases are as follows:

1. The first phase is the 'need gathering phase'

2. The second phase is the 'source location phase'

3. The third phase is the 'allocation phase'

Each of the phases is described in this section for the following supply chain:

Figure 6-8 Example of a Supply Chain

Need Gathering Phase

The need gathering phase is used to determine the need and quantity limits for each tier one destination warehouse. For the supply chain illustrated above, the tier one destination warehouses are WH2 and WH3. The need is gathered starting at the deepest tier in the supply chain and proceeding up to tier 1. The following calculations are performed in the need gathering phase:

Figure 6-9 Need gathering phase - Calculation 1

Figure 6-10 Need gathering phase - Calculation 2

Figure 6-11 Need gathering phase - Calculation 3

Where:

NNxy is the net need for item x at location y.

SOHxy is the stock on hand for item x at location y.

Rx is the result of Calculation x.

Source Location Phase

The Source location phase is used to determine the amount to be allocated from the tier one source location. The source location phase always consists of a single calculation from the tier one source location to each of its destination locations. The following diagram illustrates the calculation performed in the source location phase:

Figure 6-12 Source Location Phase

Where:

NNxy is the net need for item x at location y.

SOHxy is the stock on hand for item x at location y.

Rx is the result of Calculation x.

Allocation Phase

The allocation phase is used to determine the amount to be allocated to each of the stores where the available at the source location is based on the amount allocated to the source location plus the stock on hand at that location. The following diagrams illustrate the calculations performed in the allocation phase:

Figure 6-13 Allocation Phase

Where:

NNxy is the net need for item x at location y.

SOHxy is the stock on hand for item x at location y.

RWHx is the amount allocated to warehouse x.

Fashion and Cascade MLD

A fashion MLD allocation is handled in the same manner as a staple MLD allocation. However, when each calculation is performed, it is first performed at the style level and is then performed at the item level as described in the fashion cascade section above. Similarly, a cascade MLD allocation is handled in the same manner as a staple MLD allocation. However, when each calculation is performed, it is first performed as a level calculation and then performed as a cascade calculation as described in the staple cascade section above.

Note: The cascade mode is applicable for only MLD 0. It is not applicable for MLD 1 and 2.

Store Warehouse Relationship

Store warehouse relationship can be set in RMS to make supply chain more efficient. When stores are selected for allocation the default store warehouse relationship is considered. Oracle Retail Allocation provides the ability to bypass this default relationship if an inventory is available at a warehouse that is not in the supply chain path for the store or a set of stores.

For example, if a shipment of pace makers arrived at a DC and no stores selling pace makers are in the supply chain path for that DC, then manual selection of the stores that sell pace makers can be made by de-selecting the 'Enforce Store-Warehouse Relationship' check box.

When there are multiple warehouses to fulfill a store need and they are not in the supply chain path, then allocation happens from all the warehouses if 'Enforce Store-Warehouse Relationship' is unchecked. All the items belonging to the same level participate in filling the need irrespective of the warehouses they come from. If there are multiple warehouses, Allocation first tries to fulfill the need from a single warehouse to maintain cost efficiency.

Consider the example:

User selects items A and B for allocation to store 1. Both items A and B belong to Department 123. The items are inventoried at different warehouses. Each item is also individually inventoried at multiple warehouses. Consider Need = 1000 for store 1.

Assume the percentage contribution for cascade is 50% for Item A and 50% for Item B.

Table 6-74 Example

Item	Warehouse	Available Quantity
A	8889	1000
A	222	2000
B	1115	1000
B	777	3000

Scenario 1: 'Enforce Store-Warehouse Relationship' is unchecked and there is no Default Warehouse.

In such a scenario, items are allocated to store 1 in the following way:

Table 6-75 Final allocation for scenario 1

Item	Warehouse	Allocated Quantity
A	8889	0
A	222	500
B	1115	0
B	777	500

Scenario 2: 'Enforce Store-Warehouse Relationship' is checked and there is no Default Warehouse.

Items are allocated to Store 1 in the following way:

Table 6-76 Final allocation for scenario 2

Item	Warehouse	Allocated Quantity
A	8889	0
A	222	0
B	1115	0
B	777	0

Since 'Enforce Store-Warehouse Relationship' is checked and none of the warehouses are default warehouses, no warehouse participates in fulfilling this need.

Scenario 3: 'Enforce Store-Warehouse relationship' is checked and Default Warehouse = 8889.

Allocation is calculated in the following way:

Table 6-77 Final allocation for scenario 3

Item	Warehouse	Allocated Quantity
A	8889	1000
A	222	0
B	1115	0
B	777	0

Scenario 4: 'Enforce Store-Warehouse relationship' is unchecked and Default Warehouse = 8889.

Following is the allocation that is calculated:

Table 6-78 Final allocation for scenario 4

Item	Warehouse	Allocated Quantity
A	8889	500
A	222	0
B	1115	0
B	777	500

Scheduled Allocation

Scheduling allocations allows the user to define an allocation, and then place the allocation on schedule to be automatically re-created on specific date(s) and time until the end date is met or warehouse stock is depleted or threshold is not met. By scheduling allocations, the users will not have to manually re-create allocations that have the same criteria, thus saving time and data entry for the users.

Note: Scheduling allocations is not a replenishment system.

An example of where scheduling allocation would be useful is in fashion retailing. For fashion retailers after the initial allocation occurs, 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 true replenishment as these items are soon replaced with newer products.

To schedule allocations, the user must create a template called the 'PARENT' allocation. The template holds all the criteria to generate the scheduled allocation called the 'CHILD or CHILDREN' allocations.

Scheduling Validations

To schedule allocations, two new columns have been introduced on the "Review Item" page of the application. The new columns are "Min Avail Qty", and "Threshold%".

• Min Avail Qty: This is the minimum available quantity the item must meet for scheduled allocations. This is to ensure there is enough available qty to satisfy/fulfill total store demand/need (accounts for Hold Back values as well). Allocation will not auto create an allocation unless the Min Available qty is met. The initial value defaults to zero. The user may enter a value between 1 and 99,999,999 (both inclusive).

• Threshold%: Threshold percent is the percent difference between "total store need" and the "total available quantity". The store need can be either the net need (NN) or gross need (GN). This is the acceptable tolerance amount between total store need/demand and total available qty. When total store need is greater than total available qty, the Threshold% value will be used to prevent the system from spreading the total available qty to thin. The allocation will be auto created but not auto approved so the user must determine if the allocated qty is acceptable.

  For Gross Need, the threshold percent = ((GN - Available Quantity)/NN)*100

  For Net Need, the threshold percent = ((NN - Available Quantity)/NN)*100. The net need is calculated using the following formula:

  • Net Need = Gross Need - (Stock On Hand + Future Fulfillment)

  The initial value defaults to zero. The user may enter a value between 1 and 99 (both inclusive).

  An example for applying the threshold percent of 10% for item A (single item) multiple stores is given in the following table:

  Table 6-79 Example for Threshold Percent for Single Item/Multiple Stores

  Item A
  Store	Gross Need	On Hands	Net Need
  1	35	13	22
  2	32	16	16
  3	34	14	20
  4	36	12	24
  5	33	15	18
  6	31	17	14
  7	37	11	26
  8	36	12	24
  9	38	10	28
  10	28	20	8
  TOTAL	340	140	200

  
  

  In the above table, for item A, apply a threshold percent of 10 to the total net need of 200. So there must be at least 180 available quantity in order for Item A to pass threshold percent validation.

  An example for applying the threshold percent of 10% to item A and threshold percent of 15% to item B (multiple items) for multiple stores is given in the following tables:

  Table 6-80 Example for Threshold Percent for Item A

  Item A
  Store	Gross Need	On Hands	Net Need
  1	35	13	22
  2	32	16	16
  3	34	14	20
  4	36	12	24
  5	33	15	18
  6	No item/loc relationship for Item A/Store 6
  7	37	11	26
  8	36	12	24
  9	38	10	28
  10	28	20	8
  TOTAL	309	123	186

  
  

  Table 6-81 Example for Threshold Percent for Item B

  Item A
  Store	Gross Need	On Hands	Net Need
  1	35	13	22
  2	32	16	16
  3	No item/loc relationship for Item B/Store 3
  4	36	12	24
  5	33	15	18
  6	31	17	14
  7	37	11	26
  8	36	12	24
  9	38	10	28
  10	28	20	8
  TOTAL	306	126	180

  
  

  For item A, apply a threshold percent of 10 to the total net need of 186. Hence, there must be at least 167 (rounding applied to 167.4) available quantity in order for Item A to pass threshold percent validation.

  For Item B, apply a threshold percent of 15 is applied to the Total Net Need of 180. Hence, there must be at least 168 available quantity in order for Item B to pass threshold percent validation.

Some of the scenarios depicting how the threshold percent works are given in the following table:

Table 6-82 Threshold Percent

Total Need (could be GN or NN)	Available Qty	Calculated Value (%)	MAQ	Pass MAQ Validation	TH%	Pass TH Validation	Comments
-450	1000	322	500	Yes	10%	Yes	Whenever the available quantity is greater than need, the threshold calculation is not necessary because you have more than enough to fulfill need.
400	1000	-150%	800	Yes	75%	Yes	Whenever the available quantity is greater than need, the threshold calculation is not necessary because you have more than enough to fulfill need. So this is considered as meeting threshold percent validation. Also, note that a negative percent is less than a positive percent.
1400	1000	29%	1000	Yes	10%	No	If the calculated value is greater than the threshold percent, then validation fails.
1400	1000	29%	1000	Yes	35%	Yes	If the calculated value is less than or equal to the threshold percent, then validation passes.
2000	1000	50%	1000	Yes	50%	Yes	If the calculated value is less than or equal to the threshold percent, then validation passes.
100	90	10%	1000	Yes	5%	No	If the calculated value (rounded value) is greater than the threshold percent, then validation fails.

Prepack Algorithm

Retailers sometimes want to configure the number of prepacks and the configuration of prepacks that are to be used to provide merchandise to stores. The benefit of optimizing prepack definitions is reduced warehouse handling costs. More efficient packs result in better in-store levels using packs purchased, and less time and money spent breaking packs at season's end.

In these instances, a prepack algorithm provides suggested prepack configurations that will most closely fit store needs. The prepack configuration algorithm is a different algorithm than the one called out earlier in the diagram, "Oracle Retail Allocation calculation queue process". The prepack algorithm does not write any transactions inside the merchandising system.

The following example illustrates the prepack algorithm:

The table below shows item-store need, which was calculated as the product of style-store need and a size curve.

Table 6-83 Item Need

Item need
	S	M	L	Total
Store 1	30	75	45	150
Store 2	30	45	75	150
Store 3	20	30	50	100

The need represents the ideal allocation. Configuring two prepacks allows that need to be satisfied, assuming that the working environment is pre-season mode and that the supplier allows for the specification of prepack configurations.

For a given set of items, and a corresponding item-store allocation such as the need above, the user specifies some values:

• How many prepacks would you like to create?

• What is the minimum and maximum size for these, in total items?

For this example, the values selected are 2, 12, and 12.

Table 6-84 Prepack Configuration

Prepack configuration
	# Packs	Min	Max
Item Set	2	12	12

Using the same logic that the system utilizes when engaged in a prepack calculation, the system evaluates the possible prepack combinations to find which allows for the best allocation for the need defined.

Table 6-85 Prepack Matrix

Prepack matrix
	S	M	L
Pack 1	3	9	0
Pack 2	2	2	8

By running the allocation above with this prepack matrix, the following allocation can be achieved.

Table 6-86 Prepack Allocation

Pack allocation
	Pack 1	Pack 2
Store 1	7	6
Store 2	3	9
Store 3	2	6

At a style level, the following values more closely satisfy the stores' total need.

Table 6-87 Allocation at Style Level

Style allocation
	Need	Allocation
Store 1	150	156
Store 2	150	144
Store 3	100	96

At an item level, the results for medium and large items are very similar, but for the small item, the result is much better. Need by store is 30 30 20, and the result, 33 27 18, is better than 39 39 27.

Table 6-88 Allocation at Item Level

Item allocation
	S	M	L
Store 1	33	75	48
Store 2	27	45	72
Store 3	18	30	48

A retailer could now communicate the ideal configuration to the supplier. The configurations can be set up in the merchandising system and used when creating the purchase order.

What if Future Fulfillment

Overview

Future fulfillment is defined as the quantity of inventory that is to be fulfilled by expected inventory. The future fulfillment visible in the What If Summary screen is discussed in the following section. The second area that the Allocations application displays future fulfillment is within the Allocation Details screen. The Allocation Details column displays the future fulfillment at the store level only. There is no relation to the supply chain future inventory that this section outlines.

The 'What If' future fulfillment value is calculated based upon the following logic:

FutureX = FutureSOH - SOH
If the calculated value > 0
Future Fulfillment = FutureX
Else
Future Fulfillment = Minimum of (Mid Tier DC Need or FutureX)

Future fulfillment is the amount of inventory that the algorithm results are expecting to be fulfilled by future expected inventory. In other words, it is the amount per product/location/source that the allocator must fulfill with additional allocations for the entire quantity of inventory to be allocated to the stores. Giving users visibility to the future fulfillment quantity is critical to ensuring that they are aware of the quantities that PO creation and update logic is accounting for when the system determines the correct quantity to be ordered.

FutureSOH and SOH can be queried from the ALC_ITEM_LOC table for the warehouse and item. The FutureSOH value is held in the future_on_hand_quantity column. This column includes the future quantity and the current on hand quantity. The application displays the difference. The SOH value is held in the on_hand_quantity column.

Note: The creation of allocations for the future fulfillment quantities is not performed by the system. The creation of allocations is a manual process for the allocators.

Example Scenarios

The examples below demonstrate how the system determines the path for any given store. The examples are based upon the month of July, shown below.

Table 6-89 July Calendar

July
Sun	Mon	Tues	Wed	Thurs	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

Example 1 - Item Source Location Selected - T2 Regional

Figure 6-14 Location Selected

7/14/2005 release date from Virtual WH 251

Because there is two days of transportation time between 251 and 351, the date passed into the call to ITEM_LOC_QTY_SQL.GET_FUTURE_AVAIL for WH 351 is 7/16/2005. When 7/16/2005 is passed into the RMS function call, ASN 24 is included in the future expected inventory at WH 351.

The ALC_ITEM_LOC records are reflected in the data below:

Table 6-90 ALC_ITEM_LOC table

ALLOC_ID	1	1	1
ITEM_ID	TV	TV	TV
RELEASE_DATE	7/14/2005	7/16/2005	7/17/2005
LOCATION_ID	251	351	6789
LOCATION_DESC	Utah	Las Vegas	Las Vegas
ALLOCATED_QTY	0	0	20
CALCULATED_QTY	0	0	20
NEED_QTY	0	0	20
ON_HAND_QTY	0	0	0
FUTURE_ON_HAND_QTY	0	52	0

The allocator sees the following numbers through the front end screen related to 'what if' summary data.

Table 6-91 What-If Summary data

Item	Warehouse	Final Allocation	SOH	Future Fulfillment	PO Amount
TV	251	20	0	20	0

Example 2 - Item Source Location Selected - T1 Deconsolidation Center

Figure 6-15 T1 Deconsolidation Center

7/14/2005 release date from virtual WH 101

There are two days of transportation time between 101 and 201. There are three days of transportation time between 101 and 251. Thus, the date passed into the call to ITEM_LOC_QTY_SQL for WH 201 is 7/4/2005. The date for WH 251 is 7/5/2005. The resulting records are written to ALC_ITEM_LOC.

The ALC_ITEM_LOC records are reflected in the data below:

Table 6-92 ALC_ITEM_LOC records

ALLOC_ID	3	3	3	3	3	3	3
ITEM_ID	TV	TV	TV	TV	TV	TV	TV
RELEASE_DATE	7/2/2005	7/4/2005			7/5/2005	7/6/2005
LOCATION_ID	101	201	1234	4567	251	351	6789
LOCATION_DESC	Seattle	Denver	Colorado Springs	Denver	Utah	Las Vegas	Las Vegas
ALLOCATE_QTY	25	25	20	20	0	19	20
CALCULATED_QTY	25	25	20	20	0	19	20
NEED_QTY	25	25	20	20	0	19	20
ON_HAND_QTY	0	5	0	0	0	1	0
FUTURE_ON_HAND_QTY	0	15	0	0	20	1	0

The allocator sees the following number through the front end screen related to 'what if' summary data.

Table 6-93 What-If Summary data

Update Type = Warehouse, cross-dock or bulk quantities
Select PO Location = Blank (the default will always be the warehouse selected by the user as the item source location)
Item	Warehouse	Final Allocation	SOH	Future Fulfillment	PO Quantity
TV	101	60	6	29	25
				Note the future fulfillment value is 29 - not 30 (only 19 of the future SOH at WH 251 is necessary to fulfill the need at store 6789)
Update Type = Warehouse, cross-dock or bulk quantities
Select PO Location = Regional
Item	Warehouse	Final Allocation	SOH	Future Fulfillment	PO Quantity
TV	101	60	6	30	25
Update Type = Direct to Store
Select PO Location = Blank
Item	Warehouse	Final Allocation	SOH	Future Fulfillment	PO Quantity
TV	101	60	6	30	60

Note: Based on the example above, if the shipping schedule between WH 101 and WH 251 had been two days, ASN 24 would not have been included in the future available inventory quantity returned from ITEM_LOC_QTY_SQL because a date of 7/4/2005 would have been passed into the package and the date on ASN 24 is 7/5/2005. In this case, the future fulfillment value would have been 28 (10 future from WH 201 and 18 from WH 251).

Note: Current inventory quantities are used before future inventory quantities.

Example 3 - Item Source Location Selected - T1 Deconsolidation Center

Figure 6-16 T1 Deconsolidation Center

7/4/2005 Release Date from Virtual WH 201 and 251 - T2 Regional with Two Warehouses

There is one day of transportation time between 201 the stores. There are two days of transportation time between 251, through the HUB and to the stores.

The ALC_ITEM_LOC records are reflected in the data below:

Table 6-94 ALC_ITEM_LOC records

ALLOC_ID	3	3	3	3	3	3
ITEM_ID	TV	TV	TV	TV	TV	TV
RELEASE_DATE	7/4/2005			7/5/2005	7/6/2005
LOCATION_ID	201	1234	4567	251	351	6789
LOCATION_DESC	Denver	Colorado Springs	Denver	Utah	Las Vegas	Las Vegas
ALLOCATED_QTY	25	20	20	14	14	20
CALCULATED_QTY	25	20	20	14	14	20
NEED_QTY	25	20	20	14	14	20
ON_HAND_QTY	5	0	0	0	1	0
FUTURE_ON_HAND_QTY	15	0	0	0	6	0

The allocator sees the following number through the front end screen related to 'what if' summary data.

Table 6-95 What-If Summary data

Update Type = Warehouse, cross-dock, or bulk quantities
Select PO Location = Blank (the default is always the warehouse selected by the user as the item source location)
Item	Warehouse	Final Allocation	SOH	Future Fulfillment	PO Quantity
TV	201	60	5	10	25
TV	251	20	1	5	14

Note: If the user changes the select PO location to deconsolidation center, the PO quantity does not account for ASN32 because it is higher in the supply chain. Therefore, the front end screen related to 'what if' summary data would look exactly the same as for the regional selection. If a user had selected deconsolidation center 151 as his or her item source location, their 'what if' summary data totals for the deconsolidation center and the virtual warehouses would be updated according to the data below.

Table 6-96 What-If Summary data (continued)

Update Type = Warehouse, cross-dock or bulk quantities
Select PO Location = Blank (the default is always the warehouse selected by the user as the item source location)
Item	Warehouse	Final Allocation	SOH	Future Fulfillment	PO Quantity
TV	151	60	5	55	0

Table 6-97 What-If Summary data (continued)

Update Type = Warehouse, cross-dock or bulk quantities
Select PO Location = Regional
Item	Warehouse	Final Allocation	SOH	Future Fulfillment	PO Quantity
TV	151	60	5	55	39