7 Oracle Retail Allocation

This chapter provides an overview of Oracle Retail Allocation.

Information Maintained by Allocation

The following information is maintained in the Allocation application:

Standard Allocations - Oracle Retail Allocation provides the customer a number of sources from which to allocate products. These sources include:

• Purchase Orders

• Advanced Shipment Notification (ASN)

• Transfers

• Bill of Lading (BOL)

• Warehouse inventory

• Approved warehouse-to-warehouse allocation

Customers have more access and control to existing transactions as a result of the different item sources, which results in increased supply chain efficiencies.

What if Allocations - These allocations are similar to regular allocations with the exception that they have an infinite amount of product available to allocate. This allows a customer to determine the true need for the locations being allocated to, if they choose to create a purchase based on the allocation to fulfill the need.

ScheduledAllocations - Manually re-creating allocations that have the same criteria requires time. Oracle Retail Allocation allows users to define an allocation and schedule it to be automatically re-created on specific dates and time until the end date is met, warehouse stock is depleted, or threshold is met.

Allocation Templates - Oracle Retail Allocation users can create standard templates to apply to allocations to save time. Two types of templates can be created: allocation location groups and policy.

Policies - Oracle Retail Allocation requires the selection of a policy for the calculation of an allocation. The policy defines the source of the data used in the calculation of the allocation and other parameters that are used in the calculation.

Advanced Need Determining Calculations - Allocations are calculated in real time by advanced internal algorithms that calculate store need based on the policy parameters established by the customer and the current perpetual inventory and sales for the items being allocated.

Split Allocations - Oracle Retail Allocation allows users to react to changes (such as short ships, delays, and cancelled product) by splitting an allocation. Using this functionality, users can split one or many items off from an existing allocation and onto their own allocation.

Implementation Considerations

As part of the implementation of Allocation, customers may need to make specific choices about RMS item set up and location ranging. Customers may also need to populate tables used by Allocation in order leverage certain functionality, such as size profiles or auto quantity limits. This section provides details on the expected values to leverage these capabilities.

Allocation Item Types

The way items are classified in Allocation is different from RMS and most of the enterprise. The ALC_ITEM_TYPE is best explained with examples. This is not the exhaustive list of possible combinations, but is instead an illustration of possibilities. When examples of the data in the item_master table are presented, please be aware that the example only shows a small subset of the columns on the table. Not all items in the ITEM_MASTER table will be considered by Allocation. Thus, not all items in ITEM_MASTER will have the ALC_ITEM_TYPE column populated.

ALC_ITEM_TYPES

• Staple Item (ST)

• Sellable Pack (SELLPACK)

• Style (STYLE)

• Fashion Item (FA)

• Fashion SKU (FASHIONSKU)

• Pack Component (PACKCOMP)

• Non-sellable Fashion Simple Pack (NSFSP)

• Non-sellable Staple Simple Pack (NSSSP)

• Non-sellable Staple Complex Pack (NSSCP)

• Non-sellable Fashion Multi-color Pack (NSFMCP)

• Non-sellable Fashion Single Color Pack (NSFSCP)

Staple Item

A one level item is not related to any other items.

Item(ID, not null)	Item_parent(nullable)	Item_grandparent(nullable)	Item_level(not null)	Tran_level(not null)	Diff_1	Diff_2	ITEM_AGGREGATE_IND	ALC_ITEM_TYPE
182920285	Null	Null	1	1	Null	Null	N	ST

Transaction level items of multiple level item families that have their aggregation indicator marked as N.

Item(ID, not null)	Item_parent(nullable)	Item_grandparent(nullable)	Item_level(not null)	Tran_level(not null)	Diff_1	Diff_2	ITEM_AGGREGATE_IND	ALC_ITEM_TYPE
100001393	Null	Null	1	2	COLOR	SIZE	N
100001828	100001393	Null	2	2	RED	SMALL	N	ST
100001561	100001393	Null	2	2	BLUE	SMALL	N	ST
100075018	Null	Null	1	3	null	null	N
100075026	100075018	Null	2	3	null	null	N
100075034	100075026	100075018	3	3	null	null	N	ST

Sellable Packs

All pack items that have ITEM_MASTER sellable_ind = Y are classified as Sellable Packs in Allocation.

Item(ID, not null)	Item_level(not null)	Tran_level(not null)	PACK_IND	SELLABLE_IND	ALC_ITEM_TYPE
110919650	1	1	Y	Y	SELLPACK
110919649	1	1	Y	Y	SELLPACK
111394648	1	1	Y	Y	SELLPACK

Fashion Item Families

These are item families where the transaction level is 2 and the aggregation indicator at level 1 is Y. Allocation introduces a new level between the level 1 item and the level 2 items. These intermediate level items (1.5) do not exist on the ITEM_MASTER table.

Level 1 items hold diff groups and level 2 items hold diffs in fashion item families

Item(ID, not null)	Item_parent(nullable)	Item_grandparent(nullable)	Item_level(not null)	Tran_level(not null)	Diff_1	Diff_2	ITEM_AGGREGATE_IND	DIFF_1_AGGREGATE_IND	DIFF_2_AGGREGATE_IND	ALC_ITEM_TYPE
100001393	Null	Null	1	2	COLOR	SIZE	Y	Y	N	STYLE
100001828	100001393	Null	2	2	RED	SMALL	N	N	N	FASHIONSKU
100001561	100001393	Null	2	2	RED	LARGE	N	N	N	FASHIONSKU
100001465	100001393	Null	2	2	BLUE	SMALL	N	N	N	FASHIONSKU
100001721	100001393	Null	2	2	BLUE	LARGE	N	N	N	FASHIONSKU

The Allocation constructed items (FA) between the STYLE items and the FASHIONSKU items are a combination of the STYLE and the unique aggregation diffs of the FASHIONSKU items. In our example the STYLE is 100001393. The unique aggregation diffs (where the DIFF_X_AGGREGATION_IND is Y at the STYLE level): RED, BLUE. They are concatenated in this format {STYLE agg position~aggregation diff}

ITEM	ALC_ITEM_TYPE
100001393 1~RED	FA
100001393 1~BLUE	FA

The same example if DIFF_2_AGGREGATE_IND is Y instead of DIFF_1_AGGREGATE_IND

Item(ID, not null)	Item_parent(nullable)	Item_grandparent(nullable)	Item_level(not null)	Tran_level(not null)	Diff_1	Diff_2	ITEM_AGGREGATE_IND	DIFF_1_AGGREGATE_IND	DIFF_2_AGGREGATE_IND	ALC_ITEM_TYPE
100001393	Null	Null	1	2	COLOR	SIZE	Y	N	Y	STYLE
100001828	100001393	Null	2	2	RED	SMALL	N	N	N	FASHIONSKU
100001561	100001393	Null	2	2	RED	LARGE	N	N	N	FASHIONSKU
100001465	100001393	Null	2	2	BLUE	SMALL	N	N	N	FASHIONSKU
100001721	100001393	Null	2	2	BLUE	LARGE	N	N	N	FASHIONSKU

ITEM	ALC_ITEM_TYPE
100001393 2~SMALL	FA
100001393 2~LARGE	FA

Non-sellable Staple Simple Pack

These are non-sellable simple packs that contain only 1 component item. The component item must be classified as a Staple item by Allocation.

In this example pack item 110919650 is a simple pack with 1 component item110919649 which is a ST item.

Item(ID, not null)	Item_level(not null)	Tran_level(not null)	PACK_IND	SELLABLE_IND	SIMPLE_PACK_IND	ALC_ITEM_TYPE
110919650	1	1	Y	N	N	NSSSP
110919649	1	1	N	Y	N	ST

Non-sellable Fashion Simple Pack

These are non-sellable simple packs that contain only 1 component item. The component item must be classified as a Fashion sku item by Allocation.

In this example pack item 110919650 is a simple pack with 1 component item (110919649) which is a FASHIONSKU item.

Item(ID, not null)	Item_level(not null)	Tran_level(not null)	PACK_IND	SELLABLE_IND	SIMPLE_PACK_IND	ALC_ITEM_TYPE
110919650	1	1	Y	N	N	NSSSP
110919649	1	1	N	Y	N	FASHIONSKU

Non-sellable Staple Complex Pack

These are non-sellable complex packs that only contain staple items as components.

In this example pack item 110919650 is a simple pack with 3 component items which are ST items.

Item(ID, not null)	Item_level(not null)	Tran_level(not null)	PACK_IND	SELLABLE_IND	SIMPLE_PACK_IND	ALC_ITEM_TYPE
110919650	1	1	Y	N	N	NSSSP
110919649	1	1	N	Y	N	ST
110919648	1	1	N	Y	N	ST
110919647	1	1	N	Y	N	ST

Non-sellable Fashion Single Color Pack

These are non-sellable complex packs that only contain FASHIONSKU components. The component items must all share the same item_parent. The component items must all share the same aggregate diff values.

In this example, let's say pack item 110919650 has two components: 100001828 and 100001561. The two components share a common parent item (100001393). The two components are classified as FASHIONSKU in ALC_ITEM_TYPE. The aggregation diff for the STYLE the components both belong to is position 1 and both components have the same value for DIFF_1.

Item(ID, not null)	Item_parent(nullable)	Item_grandparent(nullable)	Item_level(not null)	Tran_level(not null)	Diff_1	Diff_2	ITEM_AGGREGATE_IND	DIFF_1_AGGREGATE_IND	DIFF_2_AGGREGATE_IND	PACK_IND	SELLABLE_IND	SIMPLE_PACK_IND	ALC_ITEM_TYPE
100001393	Null	Null	1	2	COLOR	SIZE	Y	Y	N	N	Y	N	STYLE
100001828	100001393	Null	2	2	RED	SMALL	N	N	N	N	Y	N	FASHIONSKU
100001561	100001393	Null	2	2	RED	LARGE	N	N	N	N	Y	N	FASHIONSKU
100001465	100001393	Null	2	2	BLUE	SMALL	N	N	N	N	Y	N	FASHIONSKU
100001721	100001393	Null	2	2	BLUE	LARGE	N	N	N	N	Y	N	FASHIONSKU
110919650	Null	Null	1	1	Null	Null	N	N	N	Y	N	N	NSFSCP

Non-sellable Fashion Multi Color Pack

These are non-sellable complex packs that only contain FASHIONSKU components. The component items must all share the same item_parent. The component items can have varying aggregate diff values.

In this example, let's say pack item 110919655 has two components: 100001828 and 100001721. The two components share a common parent item (100001393). The two components are classified as FASHIONSKU in ALC_ITEM_TYPE. The aggregation diff for the STYLE the components both belong to is position 1 and both components have different values for DIFF_1.

Item(ID, not null)	Item_parent(nullable)	Item_grandparent(nullable)	Item_level(not null)	Tran_level(not null)	Diff_1	Diff_2	ITEM_AGGREGATE_IND	DIFF_1_AGGREGATE_IND	DIFF_2_AGGREGATE_IND	PACK_IND	SELLABLE_IND	SIMPLE_PACK_IND	ALC_ITEM_TYPE
100001393	Null	Null	1	2	COLOR	SIZE	Y	Y	N	N	Y	N	STYLE
100001828	100001393	Null	2	2	RED	SMALL	N	N	N	N	Y	N	FASHIONSKU
100001561	100001393	Null	2	2	RED	LARGE	N	N	N	N	Y	N	FASHIONSKU
100001465	100001393	Null	2	2	BLUE	SMALL	N	N	N	N	Y	N	FASHIONSKU
100001721	100001393	Null	2	2	BLUE	LARGE	N	N	N	N	Y	N	FASHIONSKU
110919655	Null	Null	1	1	Null	Null	N	N	N	Y	N	N	NSFMCP

Items Not Supported By Allocations

Item below transaction level items

Allocation does not support Items where the item_level is greater than the tran_level.

Fashion Item Families with aggregation diffs in position 3 or 4

• Allocation can only support fashion item families DIFF_1_AGGREGATE_IND or DIFF_2_AGGREGATE_IND is Y.

• Allocation cannot support fashion item families where DIFF_3_AGGREGATE_IND or DIFF_4_AGGREGATE_IND is Y.

• Allocation cannot support fashion item families where more than one diff aggregation position is marked as Y.

Fashion Item Families with more than one diff marked for aggregation

• Allocation can only support fashion item families DIFF_1_AGGREGATE_IND or DIFF_2_AGGREGATE_IND is Y.

• Allocation cannot support fashion item families where DIFF_3_AGGREGATE_IND or DIFF_4_AGGREGATE_IND is Y.

• Allocation cannot support fashion item families where more than one diff aggregation position is marked as Y.

Non-sellable complex packs that contain a mix of FASHIONSKU and ST components

Allocations does not support packs with both ALC_ITEM_TYPE = FASHIONSKU and _ITEM_TYPE = ST components.

Non-sellable complex packs that contain FASHIONSKU items with different parent items

Allocations does not support packs with component items that belong to more than one fashion item family.

Size Profile

Overview

All fashion and fashion pack group allocation need to have size profile information. Certain types of staple application need to have size profile information. Size profile information is used to spread the quantity being allocated from Style/Color down to the SKU level. If an item / destination location does not have size profile information, it is excluded.

In order to properly use Allocation for fashion items, customers need to populate the size profile table. Each record should have hierarchy, location, and quantity information and should only contain information relevant to the target hierarchy level. For further information about size profile please see the Allocation and SPO section.

Table 7-1 Size Profile Table details

Column	Required	Description
SIZE_PROFILE_ID	Y	This column is auto-generated
LOC	Y	This column stores the location to apply the size profile to. This column should always be populated
DEPT	N	This column stores the dept to apply the size profile to. This column should be populated only for dept, class, and subclass level size profiles.
CLASS	N	This column stores the class to apply the size profile to. This column should be populated only for class, and subclass level size profiles.
SUBCLASS	N	This column stores the subclass to apply the size profile to. This column should be populated only for subclass level size profiles.
STYLE	N	This column stores the Style Id to apply the size profile to. This column should be populated only for Style, or Style Diff level size profiles.
SIZE1	N	This column stores the aggregated or non-aggregated Diff_1 information to apply the size profile to. In the case of Style_Diff level, This column contains the aggregated or non-aggregated diff. In the case of Dept, Class, Subclass or Style Level; This column contains the non-aggregated diff.
SIZE2	N	This column stores the aggregated or non-aggregated Diff_2 information to apply the size profile to. In the case of Style_Diff level, This column contains the aggregated or non-aggregated diff. In the case of Dept, Class, Subclass or Style Level; This column contains the non-aggregated diff.
SIZE3	N	This column stores the aggregated or non-aggregated Diff_3 information to apply the size profile to. In the case of Style_Diff level, This column contains the aggregated or non-aggregated diff. In the case of Dept, Class, Subclass or Style Level; This column contains the non-aggregated diff.
SIZE4	N	This column stores the aggregated or non-aggregated Diff_4 information to apply the size profile to. In the case of Style_Diff level, This column contains the aggregated or non-aggregated diff. In the case of Dept, Class, Subclass or Style Level; This column contains the non-aggregated diff.
SIZE_GROUP1	Y	This column stores the value 'X'
SIZE_GROUP2	N	This column stores the value 'null'.
QTY	Y	This column stores the individual size profile quantity.
CREATED_BY	Y	This column stores the created by user name
CREATION_DATE	Y	This column stores the creation date
LAST_UPDATED_BY	Y	This column stores the last updated by user name
LAST_UPDATE_DATE	Y	This column stores the last updated date
LAST_UPDATE_LOGIN	Y	This column stores the last updated login
OBJECT_VERSION_NUMBER	Y	This column store the object version number
GID_PROFILE_ID	N	This column stores the GID_PROFILE_ID. This column is populated when the size profile is part of a Seasonal or Generation set. This column is null if it is a standard size profile. This column is a Foreign Key on the table ALC_GID_PROFILE
SIZE_PROFILE_LEVEL	Y	This column stores a numerical size profile level. Dept = 1, Class = 2, Subclass = 3, Style = 4, Style_Diff = 5

Auto Quantity Limits

Overview

Auto quantity limits provides users a way to store pre-defined quantity limits for multiple merchandise hierarchy levels, including item, style diff, style, department, class, and subclass levels. Auto quantity limits will automatically use the lowest available hierarchy level to apply to each item location. The quantity limits information retrieved from the auto quantity limits table will display in the existing quantity limits section of the UI. These values will then be saved to the Allocation as normal quantity limits, so once auto quantity limits are applied to an allocation, changes to the values in the auto quantity limits table will not be reflected. Allocations can use auto quantity limits through a checkbox in the quantity limits tab. Auto quantity limits can be used by default for every allocation through a new system option.

Implementation

In order to use the auto quantity limits, customers need to populate the auto quantity limits table manually. Each record should have hierarchy and location information and should only contain information relevant to the target hierarchy level. Every record uses a start and end date to determine the effective dates of that record. Start dates must be populated, However, end dates are optional.

Not Supported

Overlapping dates for a particular hierarchy level location are not supported. If there is a record with no end date specified, then only records with start and end dates can be populated in the time period before the start of the original record which has no end date.

Table 7-2 Auto Quantity Limits

Column	Required	Description
AUTO_QUANTITY_LIMITS_ID	Y	This column is auto-generated
LOCATION_ID	Y	This column stores the location to apply the quantity limits to. This column should always be populated
DEPT	N	This column stores the dept to apply the quantity limits to. This column should be populated only for dept, class, and subclass level quantity limits.
CLASS	N	This column stores the class to apply the quantity limits to. This column should be populated only for class, and subclass level quantity limits.
SUBCLASS	N	This column stores the subclass to apply the quantity limits to. This column should be populated only for subclass level quantity limits.
ITEM_ID	N	This column stores the Item id or Style Id to apply the quantity limits to. This column should be populated only for Item, Style, or Style Diff level quantity limits.
DIFF_1	N	This column stores the Diff_1 information to apply the quantity limits to. This column should be populated only for Style Diff level quantity limits where Diff_1 is the aggregate Diff.
DIFF_2	N	This column stores the Diff_2 information to apply the quantity limits to. This column should be populated only for Style Diff level quantity limits where Diff_2 is the aggregate Diff.
DIFF_3	N	This column stores the Diff_3 information to apply the quantity limits to. This column should be populated only for Style Diff level quantity limits where Diff_3 is the aggregate Diff.
DIFF_4	N	This column stores the Diff_4 information to apply the quantity limits to. This column should be populated only for Style Diff level quantity limits where Diff_4 is the aggregate Diff.
START_DATE	Y	This column stores the date when this record can start to be applied. This column should always be populated. (This Column may be depreciated in version 15.0)
END_DATE	N	This column stores the date that this record can no longer be applied. This column does not need to be populated, in which case, anything date after the start date is valid. (This Column may be depreciated in version 15.0)

Integration with Other Applications

A retailer that acquires Oracle Retail Allocation gains the ability to achieve more accurate allocations on a stable product. Having the right product in the right stores allows for service levels to be raised, sales to be increased, and inventory costs to be lowered. By accurately determining which stores should get which product, retailers can meet their turnover goals and increase profitability.

The Oracle Retail Allocation retailer benefits from the following capabilities:

• Built on ADF Technology stack, it allows the ability to quickly add UI based on ready to use design patterns, metadata driven tools and visual tools. Debugging can be performed more rapidly; maintenance and alteration costs are kept low using the Meta data driven Application Development.

• The application's interface takes advantage of the Java Database Connectivitiy (JDBC), ADF's built-in transaction management, along with connections to datasources handled in Weblogic server hence minimizing the interface points needed to be maintained.

• The application's robust algorithm executes rapidly and the call to the calculation engine has been ported over from C++ library to a Java Library thus minimizing the overhead/issues related to maintaining codebase consisting of two languages.

  • For retailers with other Oracle Retail products, integration with the Oracle Retail product suite means that item, purchase order, supplier, sales, and other data are accessed directly from the RMS tables, with no need for batch modules. The allocation information containing the item, location, and allocated quantity details is passed from RMS to a warehouse management system, such as the Oracle Retail Warehouse Management System (RWMS).

• Access Control to the System is better managed by using Fusion Security Architecture.

• The application allows for retailers to adjust to changing trends in the market by facilitating real time allocations.

The following diagram illustrates the Allocation n-tier architecture:

Figure 7-1 Allocation n-tier Architecture

Allocation n-tier Architecture

RMS owns virtually all of the information that Oracle Retail Allocation needs to operate and the information that Oracle Retail Allocation provides is of primary interest/use for RMS. As a result Oracle Retail Allocation has limited interaction with other Oracle Retail Merchandising Operations Management applications. For Oracle Retail Merchandising Operations Management applications that Oracle Retail Allocation does interact with, it is managed through direct reads from Oracle Retail Merchandising Operations Management application tables, direct calls to Oracle Retail Merchandising Operations Management packages, and Oracle Retail Allocation packages based on Oracle Retail Merchandising Operations Management application tables.

For more information on the Merchandising Architecture, see Retail Reference Architecture artifacts on My Oracle Support.

Allocation and RMS

RMS provides the following to Allocation:

• Foundation Data-This information is essential to all areas of Oracle Retail Allocation including valid locations to allocate to and from, location groupings, valid merchandise hierarchies to allocate within, and so forth.

• Item-Allocations are generated at the item location level so it is necessary that the Allocation application understands what items and item/locations are eligible in the system.

• Purchase Order-One of the sources from which a user allocates is an approved Purchase Order. Oracle Retail Allocation relies on RMS to provide Purchase Order information.

• Transfer-One of the sources from which a user allocates is an approved Transfer. Oracle Retail Allocation relies on RMS to provide Transfer information.

• BOL-One of the sources from which a user allocates is a bill of lading. Oracle Retail Allocation relies on RMS to provide BOL information.

• ASN -One of the sources from which a user allocates is an ASN. Oracle Retail Allocation relies on RMS to provide ASN information.

• Inventory -In order to determine the correct need at an item-location level before performing an allocation, the application needs visibility to the current on-hand inventory at each location being allocated to. Oracle Retail Allocation relies on RMS to provide inventory information at the item/location level.

• Shipping Information - Once an allocation is shipped by the Warehouse Management System, this information is passed on to the RMS. This shipment information implies that the allocation has been processed and is not available for any further user edits from the UI. Oracle Retail Allocation relies on the RMS to provide shipment information.

• Sales Information - Oracle Retail Allocation uses historical sales, forecast sales, and plan in order to determine the need at an item/location level for an allocation. Oracle Retail Allocation relies on RMS to provide sales information, RDF to provide forecast information, and Assortment Planning (or external planning system) to provide plan information.

• Item/Location Ranging - Oracle Retail Allocation uses the item/location ranging data set up in RMS. The following logic is applied during the determination of valid item/location combinations:

  1. A location gets staple items allocated if and only if the SKU has a valid item/location status.

  2. A location gets fashion items (style/color or parent/diff) allocated if and only if the parent as well as all its child items being allocated have a valid item/location status.

  3. A location gets sellable packs (fashion/staple/simple/complex) allocated if and only if the pack has a valid item/location status.

  4. A location gets non-sellable packs (fashion/staple/simple/complex) allocated if and only if the pack as well as all its components have a valid item/location status.

  Valid item/location status are the ones not defined in the system options - 'LOCATION EXCEPTION REASONS - PRODUCT SOURCED ALLOCATION' and 'LOCATION EXCEPTION REASON - "WHAT IF" ALLOCATION'.

• Allocation - One of the sources from which a user allocates is an approved warehouse-to-warehouse allocation. Oracle Retail Allocation relies on RMS to provide this information.

  
  

  Note: The source identifier that is used is the one in Allocation tables and not the ones in RMS owned tables.

  
  

Allocation provides the following to RMS:

• Allocations - Once an allocation has been moved to Approved or Reserved status, the allocation is written to RMS tables to give visibility to the allocation results.

• Purchase Orders created by What-If process in Allocation - If the user selects the What-if option when creating an allocation, the allocation is created based on current need and then have RMS build a Purchase Order from the allocation to fulfill the need. Oracle Retail Allocation uses an RMS API to build the purchase order in RMS.

Allocation and RPM

RPM provides the following to Allocation:

• Future retail - Oracle Retail Allocation has the ability to get a real time price from RPM with which it is directly integrated. Allocation uses this data to provide the future retail price values of the set of items present in the entire allocation (based on their quantities). In addition, you can access future retail price values by item and by location.

• Promotions - You can associate active or future promotions present in RPM while creating an allocation.

Allocation provides no information to RPM.

Allocation and RTM

No information is exchanged.

Allocation and ReSA

No information is exchanged.

Allocation and ReIM

No information is exchanged.

Allocation and ARI

ARI is a monitoring system that interacts with any applications database (including Oracle Retail Allocation). As such, it does not use any information from Oracle Retail Allocation; rather, it monitors the Oracle Retail Allocation database for events defined by a customer and notifies the customer when said events occur.

Allocation and AP

Allocation is now integrated with RPAS Assortment Planning via RETL using the new Receipt Plan feature. Assortment Plan data ideally represents what the store is expected to receive at the item level.

Allocation and SPO

Prior to Oracle Retail Allocation Release 13.3, the option to select and apply a specific set of store size profile data was not available to be used during the allocation process. Logic was set to always apply the lowest level defined in the ALC_SIZE_PROFILE table. Oracle Retail Size Profile Optimization enables you to create various seasonal sets of store size profile data in terms of generation IDs (GIDs). GIDs are commonly created in advance of a selling period and based off current trend. Oracle Retail Allocation will allow you to select a specific GID to be applied during the allocation process. This is illustrated in the following three business case examples:

• Business Case 1: When creating a pre-allocation for the upcoming fall season. You may want to use a forward out Subclass Fall 2014 set of size profile data. This helps to better align the planning and execution process.

• Business Case 2: When creating an in-season allocation, where the allocation is expected to be processed the next day, you may want to take advantage of a current trend GID and select the Style level GID set of size profile data. Results will be based off actual trend data.

• Business Case 3: For key items, you may want to apply key item level specific GIDs instead of store size profile data created at higher levels, such as Class or Subclass.

Allocation System Options

In order to increase operational efficiencies, Allocation has introduced the system properties settings into the UI. The Tasks menu > Allocation Foundation > Manage System Options allows you to view various system settings. Manage System Options displays two tabs System Properties and User Group Properties. System Properties will display global system settings which were configured and defined during install and implementation; the System Properties is controlled and maintained by the System Administrator user role. The User Group Properties displays settings in which the Allocation user group can manage as business trend, and business needs change due to a shift in season or a change in their business model. The User Group Properties is controlled and maintained by the Allocation Manager user role. Allowing allocation users to have view access of these settings allows for them to better understand the Allocation product, process and results.

System Properties

• CALCULATION QUEUE POLLING INTERVAL

  Indicates the calculation queue polling interval in milliseconds. This system option has been deprecated and does not impact the calculation queue due to the implementation of WLS JMS queue. This property requires a reboot/restart of Oracle Retail Allocation to take effect.

• ITEM LOCATION WARNING

  Indicates whether a warning message needs to be displayed to the user in case of, selection of an invalid item/location combination. This system option is important for customers to understand that invalid item/locations combinations have been added in an allocation. Once these are identified, the user can take necessary steps to rectify them before proceeding with the workflow.

• END OF WEEK DAY

  Indicates the day treated as the end of the week. This system option is vital for all customers implementing Oracle Retail Allocation. Any weekly rollups performed by the application during need calculations are based on this setting. For accurate results, this needs to be in sync with the setup within the merchandising system.

• BULK WAREHOUSE SETTING

  Indicates the non-finisher virtual bulk warehouse ID for PO creation for What If allocations. This is a non-finisher virtual warehouse where the customer would require the delivery of bulk purchase orders created out of What If allocations. It needs to be noted here that this warehouse would be considered only in cases where the destination stores do not have a designated default delivery warehouse in the merchandising system.

  Business example: Bulk Warehouse Setting = VWH1. For store S1, default delivery warehouse in the merchandising system = VWH2. For store S2, there is no default delivery warehouse in the merchandising system. In the above setting, a bulk PO raised for S1 would be sent to VWH2 and for S2 would be sent to VWH1.

• AUTOMATIC GROUP UPDATE

  Indicates whether the location groups need to be updated for worksheet allocations. This system option is important for customers who extensively use location groups. In cases where a location group undergoes modifications within the merchandising system, where there are stores that were added to or deleted from the group, the Allocation user would be alerted of such changes on accessing an allocation making use of the modified location group.

• ALL ORDERS

  Indicates whether the On Order quantities against open purchase orders are considered while calculating item stock on hand.

  On Order quantities against open purchase orders are considered while calculating stock on hand (SOH) for the items in the order only if this option is set to Yes. This setting needs to be taken into consideration while analyzing the net need quantity generated for a store by the calculation algorithm.

• SUPPLY CHAIN PATH SETTING

  Retailers intending to use date-based paths might consider using the distribution level of 2 whereas those using static time-based paths would want to use the distribution level of 1. Change in this value would invalidate all the allocations created in the previous distribution level setup and not allow the user to access them.

  
  

  Note: The distribution path set up by the retailer is unidirectional and cannot be used to move goods back to the deconsolidation center from the store. Currently, this field is defaulted to zero and disabled till Multi Level Distribution (MLD) functionality is introduced.

  
  

• WHAT IF ITEM SOURCE QUERY LEVEL

  For this property, the retailer would need to set the merchandise hierarchy at which the maximum number of item queries are likely to be carried out while creating a What If allocation. This would largely need to be a corporate decision during the implementation phase.

• LOCATION EXCEPTION REASONS - PRODUCT SOURCED ALLOCATION

  Indicates the item-location relationship status that needs to be excluded from product sourced allocations. Separate multiple statuses with a space. Example: Location Exception Reason Product Sourced = C D I. If you want to exclude a non-existing item location relationship, add NULL to the list.

  Within the merchandising system, there are multiple item-location relationships that may exist. During the implementation phase, it is very important that the retailer takes a decision around which of these relationships would be considered valid during the creation process for a regular allocation. Defining the set of invalid relationship status through this system option removes an additional overhead of having to individually examine each allocation and manually remove invalid item location combinations.

• LOCATION EXCEPTION REASON - "WHAT IF" ALLOCATION

  Indicates the item-location relationship status that needs to be excluded from What If allocations. Separate multiple statuses with a space. Example: Location Exception Reasons What If = C D I. If you want to exclude a non-existing item location relationship, add NULL to the list.

  Within the merchandising system, there are multiple item-location relationships that may exist. During the implementation phase, it is very important that the retailer takes a decision around which of these relationships would be considered valid during the creation process for a 'what if' allocation. Defining the set of invalid relationship status through this system option removes an additional overhead of having to individually examine each allocation and manually remove invalid item location combinations.

• DEFAULT "WHAT IF" IMPORT WAREHOUSE

  Indicates the default warehouse for import based purchase orders from What If allocations. This is a non-finisher virtual warehouse where the customer would require the delivery of purchase orders created out of What If allocations. It needs to be noted here that this warehouse would be considered only in cases where the destination stores do not have a designated default delivery warehouse in the merchandising system.

  Business example: Default What If Import Warehouse = VWH1. For store S1, default delivery warehouse in the merchandising system = VWH2. For store S2, there is no default delivery warehouse in the merchandising system. In the above setting, a What If PO raised for S1 would be sent to VWH2 and for S2 would be sent to VWH1.

• "WHAT IF" SUMMARY DEFAULT ACTION

  Indicates the What If Summary Default Action: Create or Update PO.

• FUTURE AVAILABLE FOR WHAT IF ALLOCATIONS

  Indicates whether or not to consider Future Available inventory for What If Allocations. True - Use the future SOH; False - Use the current SOH only.

  While raising purchase orders out of What If allocations, this system option gives the retailer the extra edge of being able to see inventory likely to be delivered within the time horizon of the allocation at the locations being covered by the allocation. The order quantity gets optimized as a result of this and it also safeguards the retailer against over-allocation and markdown scenarios.

• ENABLE SIZE PROFILE VALIDATION

  Indicates if the size profile validation should be done when the user hits the Calculate button.

• SIZE PROFILE VALIDATION LEVELS

  Indicates the levels at which the validation should be done. The valid values are STYLE, STYLE/COLOR, SUBCLASS, CLASS, and DEPT. If you want to specify more than one value, then use the comma as a delimiter.

  This needs to be set to the merchandise hierarchy levels at which the retailer is likely to store the size profile data.

• SISTER STORE SETUP

  Indicates whether the need of a similar store can be used during allocation calculation. If this is set to True, the system uses the sister store's need when the records don't exist for a store. If this is set to False, the system uses the sister store's need when the records don't exist for a store or when there are existing records but with zero need.

  This gives the retailer the option to use item sales data from a like store in case of no existing records from the store in the allocation or there is a new store receiving goods for the first time and which is unlikely to have any past history data.

• LOCATION LIST THRESHOLD

  Indicates threshold value to be used in SQL IN while fetching a location list.

• UNLOCK MINUTES

  Indicates the locking timeout in minutes.

• PROMOTION ASSOCIATION

  Indicates whether the system should allow you to link promotions with an allocation during the creation process.

• BATCH PROVIDER URL

  Indicates the WebLogic context Uniform Resource Locator (URL) that the Async process uses. This property requires a reboot/restart of Oracle Retail Allocation to take effect.

• ITEM SEARCH MAXIMUM

  Indicates the limitation on the number of rows that are returned by the item search.

• ALLOCATION RETENTION DAYS

  Indicates the number of days you can retain allocations that are not linked to RMS allocations in the system without them being picked up by the purge batch. This is calculated based on the last modified date of the allocation.

• WORKSHEET RETENTION DAYS

  Indicates the number of days to keep worksheets not linked to any RMS allocations in the system. Purging occurs once this time frame is over.

• NOTIFICATION POLLING INTERVAL

  Indicates the notification polling interval in milliseconds.

• NOTIFICATION POLLING TIMEOUT

  Indicates the notification polling timeout in milliseconds.

• ENABLE FUTURE RETAIL

  Indicates whether or not the retail values of the items being allocated are displayed to the user.

• ENABLE PROMOTIONS

  Indicates whether or not the system must allow the user to link promotions with an allocation during the creation process.

• CALCULATION LOG PATH

  Directory path to hold calculation dat files. This property requires a reboot/restart of Oracle Retail Allocation to take effect.

User Group Properties

The User Group properties are assigned to the Allocation Manager standard user role.

• NUMBER OF DAYS BEFORE RELEASE DATE

  Indicates the number of days before the release date, that is used during the creation of a purchase order for a What If allocation. This field is set to three days by default.

• DEFAULT RELEASE DATE

  Indicates whether or not to use Default Release Date. 'Yes' indicates Allocations will have a default release date and 'NO' indicates Allocation will not have a default release date.

• DEFAULT AUTO QUANTITY LIMITS

  Indicates whether or not to use Default Auto Quantity Limits. 'Yes indicates Allocation will have Default Auto Quantity Limits and 'No' indicates Allocation will not have Default Auto Quantity Limits

• BAYESIAN SENSITIVITY FACTOR

  Indicates the plan sensitivity value used while using the Plan Reproject policy. The sensitivity factor is set to 0.3 by default. This value can be changed to any value between zero to one based on the requirements.

• SECONDARY

  Indicates whether to display secondary description of store or supplier in store field and supplier field respectively.

• BREAK PACK ENFORCEMENT

  Indicates whether the break pack functionality is enabled or not.

• PRESENTATION MINIMUMS

  Indicates if presentation minimums are initially defaulted into the quantity limits UI. This field impacts the default setting of the Auto Quantity Limits check box in the Quantity Limits tab on the Policy Maintenance window.

• DEFAULT STORE CALCULATION/PO MULTIPLE

  Indicates the default store calculation multiple. Possible Values are:

  • EA - Each

  • IN - Inner

  • CA - Case

  • PA - Pallet

• ITEM SOURCE DEFAULT FOR ITEM SEARCH PAGE

  Indicates the Item Source that will be checked by default when entering the Item Search page.

  • P - Purchase order

  • S - Advanced shipping notification

  • T - Transfer

  • B - Bill of lading

  • W - Warehouse

  • A - Allocation

• DESCRIPTION LENGTH

  Indicates the maximum length to be used for display of Item descriptions in the user interface.

• RULE VISIBILITY

  Indicates the rule type for which the need value is displayed on the Allocation Maintenance window.

• PACK VARIABLE ACCEPTANCE THRESHOLD

  Indicates the Pack Variance Acceptance Threshold value.

• QL SPLIT METHOD FOR LOCATION GROUPS

  Indicates the method of splitting quantity limits across individual stores in a location group.

• MAXIMUM ITEMS IN ALTERNATE HIERARCHY SELECTION

  Indicates the maximum number of items per alternate hierarchy selection.

Database Statistics

In order to ensure optimal performance of Oracle Retail Allocation, ensure that an appropriate database statistics strategy is in place for the Allocation database tables. Of particular importance is a strategy for managing the temporary tables used within the calculation processing and user online sessions.

The calculations tables can be identified by the naming standard, ALC_CALC_***_TEMP, and they represent the volatile tables that are subject to high concurrent users and application logic inserting data (and later deleting). Gathering stats against these temp tables has always been a challenge because the number of rows changes at a very high frequency. Cardinality is the estimated number of rows that will be returned by a query operation and is the key to getting representative statistics (and not necessarily the latest statistics). With this architecture, we have no way of knowing during the session if the upper boundary of a temp table is 100 rows,10000 rows or 1000000 rows and so our cardinality is unpredictable and the Oracle Optimizer Engine gives you a false estimate and produce bad query response times.

The following is the list of the volatile tables which must be set up for using dynamic sampling or a locked statistics approach:

• ALC_CALC_DESTINATION_TEMP

• ALC_CALC_NEED_DATES_TEMP

• ALC_CALC_NEED_TEMP

• ALC_CALC_QTY_LIMITS_TEMP

• ALC_CALC_RLOH_ITEM_TEMP

• ALC_CALC_RLOH_TEMP

• ALC_CALC_SOURCE_TEMP

• ALC_HEAD_TEMP

• ALC_MERCH_HIER_RLOH_TEMP

• ALC_SESSION_ITEM_LOC

• ALC_SESSION_ITEM_LOC_EXCL

• ALC_SESSION_QUANTITY_LIMITS

• ALC_WORK_SESSION_ITEM

• ALC_WORK_SESSION_ITEM_ALL

• ALC_WORK_SESSION_ITEM_LOC

So generically, we need to choose one of two options: using DYNAMIC_SAMPLING, or locking the statistics at an approximate average level.

Dynamic Sampling

Using DYNAMIC_SAMPLING (an Oracle system parameter), Oracle gathers just enough stats on the referenced table to give it a best guess. So if you select dynamic sampling, you must drop the current stats on the reference temp table(s) and then lock them. This prevents the auto stats from collecting them or a dba mistakenly creating them and also tells the Optimization Engine that these referenced tables are candidates for dynamic sampling collection. Then, it is recommended setting the DYNAMIC_SAMPLING to 6. It can be set either at the system or session level. See the following article for more details on dynamic sampling: Optimizer Dynamic Sampling (OPTIMIZER_DYNAMIC_SAMPLING) (ID: 336267.1).

Locking Statistics

Oracle recommends that if you are not using dynamic sampling, their size be monitored and the statistics gathered at, or close to, their peak size. The statistics should then be locked using dbms_stats.lock_table_stats().

Note: The volatile tables need to be maintained by running the AlcDailyCleanUp batch process nightly. For more details on the batch, see the Oracle Retail Allocation Operations Guide

The following are additional recommendations on statistics relevant to Allocation:

• If statistics are currently being gathered manually, Oracle assumes that automatic statistics gathering has been disabled. If not, set DBMS_STATS.SET_GLOBAL_PREFS ('AUTOSTATS_TARGET', 'ORACLE'). This will still gather dictionary table statistics.

• The remaining ALC% tables should follow best practices for statistics gathering using DBMS_STATS.GATHER_*_STATS procedures, namely allowing ESTIMATE_PERCENT to default to AUTO_SAMPLE_SIZE. Running these statistics on a weekly basis should suffice unless a major change occurs in the characteristics of the data (e.g. size, density, etc).

• Finally, if not carried out previously, we recommend that fixed object statistics be gathered (DBMS_STATS.GATHER_FIXED_OBJECTS_STATS) while there is a representative load on the system. If that is not feasible, then these should be at least gathered after the database is warmed-up and v$session, v$access, v$sql, v$sql_plan, etc are populated.

Internationalization

For details on the language supported information see, Oracle Retail Merchandising System documentation for the current release.