| Oracle® Retail Merchandising Implementation Guide Release 16.0 E80776-04 |
|
 Previous |
 Next |
This chapter provides an overview of Oracle Retail 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 Notifications (ASN)
Transfers
Bill of Lading (BOL)
Warehouse inventory
Approved warehouse-to-warehouse allocations
Customers have more access and control to existing transactions as a result of the different item sources, which results in increased supply chain efficiency.
What if Allocations - These allocations are similar to the standard ones with the exception that it is assumed that these have an infinite amount of product available to allocate. This allows a customer to determine the true need for the locations being allocated to, and they can choose to create a purchase order based on the allocation to fulfill the need. The user can also enter a finite available quantity during the creation of a 'what if' allocation, in which case this value gets treated as an upper cutoff.
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 or warehouse 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 a new allocation of their own.
As part of the implementation of Allocation, customers may need to make specific choices about RMS item setup 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.
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 item 110919649 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 |
Item below transaction level items
Allocation does not support Items where the item_level is greater than the tran_level.
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.
Overview
All fashion, fashion pack, and fashion group allocations need to have size profile information. Size profile information is determined based on the selling ratio of the fashion items and 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 while performing the calculations.
In order to properly use Allocation for fashion items, customers need to populate the size profile data either through the UI or the database table. Each record should have hierarchy, location, and quantity information and should only contain details relevant to the target hierarchy level. For further information about size profile please see the Allocation and SPO section.
A combination of a merchandise hierarchy and location group can have multiple size profiles set up, which are termed as Generation IDs (GIDs). Size Profile Optimization application in RPAS provides size profile information for different seasons. These seasonal profiles are stored using three different tables in Allocation.
Table 8-1 ALC_GID_HEADER
| Column | Required | Description |
|---|---|---|
|
ID |
Y |
This is the primary unique ID generated from the sequence |
|
GID |
Y |
This is the GID season code, populated from SPO |
|
GID_DESC |
Y |
The description for the GID |
|
CREATED_BY |
Y |
Indicates the user who created the record |
|
CREATION_DATE |
Y |
The timestamp of the record creation date |
|
LAST_UPDATED_BY |
Y |
Indicates the user who last updated the record |
|
LAST_UPDATE_DATE |
Y |
The timestamp of the last updated date for the record |
|
LAST_UPDATE_LOGIN |
Y |
Indicates the session login associated to the user who last updated the row. |
Table 8-2 ALC_GID_PROFILE
| Column | Required | Description |
|---|---|---|
|
GID_ID |
Y |
This is the foreign key to the primary key of ALC_GID_HEADER |
|
GID_PROFILE_ID |
Y |
This is the primary unique ID generated from the sequence |
|
CREATED_BY |
Y |
Indicates the user who created the record |
|
CREATION_DATE |
Y |
The timestamp of the record creation date |
|
LAST_UPDATE_DATE |
Y |
The timestamp of the last updated date for the record |
|
LAST_UPDATE_LOGIN |
Y |
Indicates the session login associated to the user who last updated the row |
Table 8-3 Size Profile Table details
| Column | Required | Description |
|---|---|---|
|
SIZE_PROFILE_ID |
Y |
This column is auto-generated |
|
LOC |
Y |
This column stores the location to which the size profile will apply. This column should always be populated |
|
DEPT |
N |
This column stores the dept to which the size profile will apply. This column should be populated only for dept, class, and subclass level size profiles. |
|
CLASS |
N |
This column stores the class to which the size profile will apply. This column should be populated only for class, and subclass level size profiles. |
|
SUBCLASS |
N |
This column stores the subclass to which the size profile will apply. This column should be populated only for subclass level size profiles. |
|
STYLE |
N |
This column stores the Style Id to which the size profile will apply. 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 which the size profile will apply. 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 which the size profile will apply. 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 which the size profile will apply. 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 which the size profile will apply. 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 |
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 system option. A new UI is now available to define the Auto Quantity Limits.
Implementation
In order to use the auto quantity limits, customers need to populate the auto quantity limits table manually or through the UI. 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 8-4 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) |
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 or warehouses allows for service levels to be raised, sales to be increased, and inventory costs to be lowered. By accurately determining which stores or warehouses 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:
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.
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:
For Staple, Fashion and Sellable Pack items, the transaction item will be used to determine valid Item/Location ranging.
For Non Sellable Packs, Pack or Component item will be used to determine the valid Item/Location ranging, by considering FP_PACK_RANGING value P or C in System Options.
Allocation uses RMS ITEM_LOC, Store and WH table to identify the valid Location, logic is as follows:
If the 'Use Default Sourcing Location Only' checkbox is checked, then the SOURCE_WH in ITEM_LOC table is considered first to identify the warehouse that is valid to allocate to a destination location. If this is not found, then the DEFAULT_WH specified in the Store or WH table for the destination location will be used.
If the 'Use Default Sourcing Location Only' checkbox is not checked, then the SOURCE_WH in ITEM_LOC table is considered first to identify the warehouse that is valid to allocate to a destination location. If this is not found, then the DEFAULT_WH in Store or WH table for the destination location will be used. If neither of these options is able to meet the destination need, then a sequencing logic will be used based on the ORG_UNIT, CHANNEL, PROTECTED indicator (of the source warehouse), and PRIMARY indicator (of the source warehouse) in the Store or WH table will be used to identify the valid Source based on the legal entity which will be either the transfer entity or set of books, depending on the Intercompany Basis defined in RMS. For more details, see the Oracle Retail Allocation User Guide.
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 is integrated with RPAS Assortment Planning via RETL using the Receipt Plan feature. Assortment Plan data ideally represents what the store or warehouse is expected to receive at the item level.
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 2017 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 the store size profile data created at higher levels, such as Class or Subclass.
|
Note: The GID option applies only to stores. For a fashion allocation involving destination warehouses, there are other options to determine the size profile. For more details, see the Oracle Retail Allocation User Guide. |
In order to increase operational efficiencies, Allocation has introduced the system properties settings into the UI. The Allocation Foundation > Manage System Options under the updated Task List allows you to view various system settings. Manage System Options displays two tabs System Properties and User Group Properties based on user privileges. 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.
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.
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 Re-project 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.
ENABLE LOCATION PRIORITY
Allows the user to upload and maintain a spreadsheet containing details on the priority value associated with the set of stores and warehouses being used in the system.
PACK RANGING
Indicates the option of performing pack ranging at either of the following levels:
Pack Level: Allows the retail to plan and execute at the same level.
Component Level: Allows each unique component within the pack to be ranged to the store. If a single component of the pack is not ranged, the pack cannot be allocated to the store.
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.
Oracle Retail Operational Insights dashboards and reports provide pervasive Business Intelligence. To provide a seamless user experience, they are designed to be embedded within Allocation application.
Operational Insights Dashboards and report does not require SSO for seamless integration of dashboards and reports except when there is a contextual launch from the report into a task flow of an external application. Such as in Allocations, there is a link from the PO Arrivals report to open the order maintenance task flow in RMS.
For more information on security configuration and implementation, see the Oracle Retail Merchandising Operations Management Security Guide.
The ALC_SYSTEM_OPTIONS_OI table drives the configuration parameters for the Allocation Operational Insights dashboards reports and is present in the Allocation application database schema. This following table describes the configuration parameters for OI reports for Allocation:
| System Option | Definition | Column Name |
|---|---|---|
| Need Calculation Type | The PO Arrival/Shipment Arrival report, WH Inventory report and the Allocated to Plan/Forecast have the ability to support using either Forecast or Plan data.Retailers should configure this parameter based on the data that they have available for their items and wish to see in these reports.
Values - P (plan); F (forecast) |
NEED_CALC_TYPE |
| PO Allocation Time threshold | Number of days before the not after date of the purchase order that the retailer expects a quantity greater than the 'Percentage Allocated PO Threshold' to be allocated. | PO_ALC_TIME_ THRESHOLD |
| Percentage Allocated PO Threshold | The percentage of the warehouse order quantity against the given PO that is expected to be allocated within the 'PO Allocation Time Threshold' defined. | ALLOCATED_PO_ THRESHOLD |
