| Oracle® Retail Allocation Operations Guide Release 14.1 E57847-01 |
|
 Previous |
 Next |
This chapter discusses the integration among Oracle Retail Allocation and other systems and it provides the following:
An integration interface allocation-related dataflow across the enterprise.
The tables and triggers that are in external systems or related to external systems that Oracle Retail Allocation uses (for example, RMS).
A functional description of RMS dependencies and assumptions that affect Oracle Retail Allocation.
Information necessary to integrate Oracle Retail Allocation and Oracle Retail Workspace.
This section provides an overview as to how Oracle Retail Allocation is functionally integrated with other systems (including other Oracle Retail systems). The discussion primarily concerns the flow of allocation-related business data across the enterprise.
|
Note: Symbol denotes tables held on the Merchandising table. Oracle Retail allocation pulls the data from these Merchandising tables through the use of the JDBC connection. |
|
Note: Oracle Retail allocation pulls the data from the Merchandising tables in RMS using the JDBC connection. |
The diagram above shows the overall direction of the dataflow among the products. The accompanying explanations are written from a system-to-system perspective, illustrating the movement of data.
The history data is subjected to processing that yields data that is sent back to the merchandising system. From there, Oracle Retail Allocation pulls the following data:
Forecasting data: Oracle Retail Allocation accesses forecasting data that originates in the Oracle Retail Demand Forecasting (RDF) system. RDF is Oracle Retail's statistical and causal forecasting solution. It uses state-of-the-art modeling techniques to produce high quality forecasts with minimal human intervention. RDF is an application that resides on the Oracle Retail Predictive Application Server (RPAS). Oracle Retail Allocation uses forecasting data as a basis for calculating gross need and can access the following five levels of forecasting data: department, class, subclass, style-color and item.
Store grade group data: Oracle Retail Allocation accesses store grade group data that originates in Grade. Grade is Oracle Retail's application that groups store locations together intelligently, based on similarities in performance, customer type, geography, or some other factor that allows the stores within each group to be treated as one unit. Grade is an application that is part of the Oracle Retail Predictive Application Server (RPAS). Internally, Oracle Retail Allocation also updates its store grade groups data groups based on the most current definitions. This update plays an important role when many months pass between initial and final allocations.
Plan data
Oracle Retail Allocation accesses plan data that originates in the planning application (including Oracle Retail's planning applications that reside on the RPAS server). The RPAS products are applications that provide functionality for developing, reconciling, and approving plans. When interfacing with Oracle Retail planning applications, Oracle Retail Allocation accesses department, class, subclass, parent/diff, or SKU plan data at the store-week level. Oracle Retail Allocation can be used as a tool to verify the final product-store plans and to initiate a PO to execute the plan. In other words, Oracle Retail Allocation can take the retailer's plan or forecast and execute it. Both the Oracle Retail and the legacy planning applications populate a planning table, ALC_PLAN, which resides within Oracle Retail Allocation. See the section, Planning Table in Oracle Retail Allocation, later in this chapter.
|
Note:
|
Size Profile data
Oracle Retail Allocation uses size profile data from Oracle Retail Size Profile Optimization (SPO) system. SPO creates optimal profiles of size distribution by both merchandise category and by store. The size profile data is extracted at the following levels: department level, class level, sub-class level and item level. The data for all the levels are extracted in a single file. For more information, see the section, in and see RETL Batch Processing.
Size Profile data
Curve data becomes size profile data once it's integrated into Retail Allocation. If allocations are made at the style level, Retail Allocation utilizes the Curve data to get to the SKU level. For more information, see the section, in and see RETL Batch Processing.
Appointment data
Appointment data is one source that identifies item(s) to be allocated.
Warehouse inventory position data
ASN, BOL, and Transfer information
RPM provides the following to Allocation:
Future Retail Price Data - Oracle Retail Allocation has the ability to get a real time price from RPM as it is integrated directly with RPM. Allocation uses this data to provide you with the future retail price value of the entire allocation (based on its quantities). In addition, you can access future retail price values by location and by item.
|
Note for RMS users only: Item, purchase order, supplier, sales and other data are accessed directly from the RMS tables, with no need to interface data via batch modules. |
Item data Oracle Retail Allocation can allocate at the item, style-color, pack, or item list level. Styles, items, and packs can be mixed on a single allocation.
PO data
Hierarchy data
Sales history data (for items, user-defined attributes (UDA), warehouses, stores, and so on)
Foundation data (supplier data, shipping tables, and so on)
Oracle Retail Allocation calculates the allocation based on the information it has received from the merchandising system. Once the retailer reviews and approves the allocation, Oracle Retail Allocation sends the following information back to the merchandising system:
Approved or reserved allocation data
Worksheet status POs that contain product, supplier and quantity information (the only remaining actions to be taken in the merchandising system are to approve the PO and, if desired, to truck scale the PO.) These worksheet status purchase orders may be created or updated from within the Oracle Retail Allocation front end.
|
Note for RMS users only: Oracle Retail Allocation utilizes the existing integration between RMS and RWMS. This interface currently passes purchase order, item, location, and allocation information from RMS to RWMS. |
Based upon the approved allocation information from Oracle Retail Allocation, the merchandising system sends the following information to the distribution management system:
Approved allocation data represents the store quantity instructions for allocating a specific quantity of stock at the store level.
Oracle Retail Active Retail Intelligence (ARI) is an exception management and resolution system driven by custom business rules. Depending upon ARI's configuration, an ARI user could receive an alert that includes a link to Oracle Retail Allocation in the form of a URL address. The user could then log on to Oracle Retail Allocation in order to address the contents of the ARI alert.
This section addresses Oracle Retail Allocation's persistence layer method of integration:
Tables Populated by External Systems
The following tables are owned by Oracle Retail Allocation. The data within them is populated by external systems. For descriptions of each table and its columns, see the Oracle Retail Allocation Data Model.
ALC_CORPORATE_RULE_DETAIL
ALC_CORPORATE_RULE_HEAD
ALC_IDEAL_WEEKS_OF_SUPPLY
ALC_PLAN
ALC_RECEIPT_PLAN
ALC_SIZE_PROFILE
Can also be populated through size profile setup via the front end of the application.
Planning Table in Oracle Retail Allocation
Planning applications populate a planning table, ALC_PLAN, that resides within Oracle Retail Allocation. This table includes the following columns:
Plan ID
Loc
EOW.date
Department
Class
Subclass
Item
Diff1_id, Diff2_id, Diff3_id, Diff4_id
Quantity
A record can thus exist at any of the following levels by week-store-quantity:
Department
Department-class
Department-class-subclass
Item-color
Item
The ALC_RECEIPT_PLAN table includes the following columns:
Plan ID
Loc
EOW.date
Department
Class
Subclass
Item
Diff1_id, Diff2_id, Diff3_id, Diff4_id
Quantity
A record can thus exist at any of the following levels by week-store-quantity:
Department
Department-class
Department-class-subclass
Item-color
Item
Pack
Merchandising Interface Tables
Oracle Retail Allocation and RMS share certain database tables and processing logic. This integration provides the following two important benefits:
The number of interface points that need to be maintained is minimized.
The amount of redundant data (required if the rest of the Oracle Retail product suite is installed) is limited.
Oracle Retail Allocation exchanges data and processing with RMS in four ways:
By reading directly from RMS tables.
By directly calling RMS packages.
By reading Oracle Retail Allocation views based on RMS tables.
Oracle Retail Allocation triggers reside in RMS tables. These triggers cause actions (create, delete, update) on RMS tables based on Oracle Retail Allocation business rules.
RMS Tables (for Retailers with RMS only) used by Oracle Retail Allocation
The following table illustrates the tables from which Oracle Retail Allocation gets its data from RMS.
Table 5-1 RMS Tables Used by Allocation
| RMS Tables | |
|---|---|
|
Functional Area |
Associated Tables |
|
Item data |
SUB_ITEMS_HEAD |
|
SUB_ITEMS_DETAIL |
|
|
ITEM_MASTER |
|
|
ITEM_SUPP_COUNTRY |
|
|
ITEM_SUPPLIER |
|
|
ITEM_LOC |
|
|
ITEM_LOC_HIST |
|
|
ITEM_LOC_SOH |
|
|
ITEM_PARENT_LOC_HIST |
|
|
Skulist data |
SKULIST_HEAD |
|
SKULIST_DETAIL |
|
|
Pack data |
PACKITEM |
|
ITEM_MASTER |
|
|
ITEM_LOC |
|
|
Order data |
ORDHEAD |
|
ORDLOC_WKSHT |
|
|
ORDLOC |
|
|
ORDSKU |
|
|
ALLOC_HEADER |
|
|
ALLOC_DETAIL |
|
|
SHIPMENT |
|
|
Supplier data |
SUPS |
|
ITEM_SUPPLIER |
|
|
Location list data |
LOC_LIST_HEAD |
|
LOC_LIST_DETAIL |
|
|
LOC_LIST_CRITERIA |
|
|
Merchandise hierarchy data |
DEPS |
|
CLASS |
|
|
SUBCLASS |
|
|
Organizational hierarchy data |
STORE |
|
WH |
|
|
WH_STORE_ASSIGN |
|
|
Shipment data |
SHIPMENT |
|
SHIPSKU |
|
|
Store grade data |
STORE_GRADE_GROUP |
|
STORE_GRADE |
|
|
STORE |
|
|
BUYER |
|
|
STORE_GRADE_STORE |
|
|
Location traits data |
LOC_TRAITS |
|
LOC_TRAITS_MATRIX |
|
|
LOC_AREA_TRAITS |
|
|
LOC_REGION_TRAITS |
|
|
LOC_DISTRICT_TRAITS |
|
|
Transfer data |
TSFHEAD |
|
TSFDETAIL |
|
|
User defined attribute (UDA) data |
UDA |
|
UDA_VALUES |
|
|
UDA_ITEM_LOV |
|
|
Forecast data |
DEPT_SALES_FORECAST |
|
CLASS_SALES_FORECAST |
|
|
SUBCLASS_SALES_FORECAST |
|
|
ITEM_FORECAST |
|
|
Sales data |
DEPT_SALES_HIST |
|
CLASS_SALES_HIST |
|
|
SUBCLASS_SALES_HIST |
|
|
ITEM_LOC_HIST |
|
|
ITEM_PARENT_LOC_HIST |
|
|
Appointment data |
APPT_HEAD |
|
APPT_DETAIL |
|
Oracle Retail Allocation-Owned Triggers Residing on RMS Tables
Table 5-2 Triggers
| Triggers | Details |
|---|---|
|
ALC_TABLE_ALD_AUR - 1 - 4 |
This trigger is involved in the following processing: Whenever a portion of an allocation order is worked on by the distribution center by selecting, distributing, transferring or receiving inventory, the allocation within Oracle Retail Allocation is placed into a 'Processed' status. The user can no longer change that allocation in Oracle Retail Allocation. |
|
ALLOC_STATUS_TRIGGER |
This trigger is on the RMS table ALLOC_HEADER. The trigger updates the status in Oracle Retail Allocation table ALC_ALLOC to 4 (closed). This trigger is fired only if the status on RMS table ALLOC_HEADER is updated to 'C' (closed). |
|
ALLOC_STATUS_TRIGGER_AU |
The closure logic within the Oracle Retail Allocation application accounts for the multiplicity between ALLOC_HEADER records and the Oracle Retail Allocation (ALC_XXX) tables. The table triggers only set a Oracle Retail Allocation allocation number to closed if all ALLOC_HEADER records have been closed. |
This section describes the functional dependencies of Oracle Retail Allocation on RMS.
The RMS item structure allows multiple item levels and multiple differentiators. To structure item setup for use with Oracle Retail Allocation, the retailer must understand the implications of the Item Aggregate Indicator and the Aggregate Indicators that exist at the differentiator level.
The following section describes how an item family must be structured to enable the Oracle Retail Allocation product to differentiate the items among fashion, staple and pack items.
Fashion Item
|
Note: In the Allocation application and this document, the terms 'style/color' and 'parent/diff' are used interchangeably. |
RMS allows for the potential of three item levels. For a customer who allocates based on the concept of parent/diff, the style can be translated to RMS item setup as being the level one item in the item family. The SKU can be translated to RMS item setup as being the transaction level item (this could be level one, two or three). There is no requirement within RMS that forces a 'fashion' item to be multi-level.
An item is viewed as a fashion item only if the Item Aggregate Indicator in the Attributes section of the Item Master Window is selected for the style (level one item) in the item family.
Once the item aggregate indicator has been selected, the user needs to indicate which differentiator should be curved by allocations. Each item may contain up to four differentiators.
The Aggregate check box is enabled when more than one differentiator is being created for an item where the Item Aggregate Indicator has been selected. The differentiator that the customer wants to be curved by Oracle Retail Allocation must be the only differentiator that is not indicated on the Item Master Window.
Below is an example of a fashion item, its indicators within RMS, and what is visible.
Item 100011006 has three differentiators associated.
Color/pattern/width
The retailer wants to have Oracle Retail Allocation apply the curve to Color. Therefore, it sees information within the Oracle Retail Allocation screens based upon the pattern and width differentiators.
All of the transaction level children have their item and differentiator aggregate indicators set to 'N'. These values are only maintained for the level one item. All other items in the system (including packs) have those indicators defaulted to 'N'.
In this scenario, if the retailer is creating an allocation for the parent item (100011006), it has visibility to four different levels of the 'style'.
100011006 - 100% Cotton Sheets Plaid:N
100011006 - 100% Cotton Sheets Plaid:S
100011006 - 100% Cotton Sheets Leopard:N
100011006 - 100% Cotton Sheets Leopard:S
A staple item is every item in the system where the level one item in the item family does not have the Item Aggregate Indicator selected. In this scenario, the Oracle Retail Allocation retailer has visibility to the transaction level item only. There is no roll up of item information. The retailer also has visibility to the non-sellable packs that contain the component staple item and is able to include or exclude those packs from the allocation.
There are multiple types of packs that may be set up within RMS. The key criteria for Oracle Retail Allocation is whether the pack is sellable or non-sellable, whether the pack contains multiple component items and whether or not those multiple components items are of one type (for example, fashion as opposed to staple).
When creating your packs, consider the following pack assumptions made by Oracle Retail Allocation:
Oracle Retail Allocation does not have the ability to allocate packs that contain fashion and staple items.
Oracle Retail Allocation does not have the ability to allocate fashion packs that contain multiple item level one/differentiator (style/color) combinations.
These items are individually allocated and can be selected from item LOV search criteria.
These items are allocated as part of their style/color. They may also be individually selected from the worksheet to distribute only those sizes/components that are available to allocate. Single fashion items may also optionally be included in a Fashion Group Allocation
|
Note: Fashion packs cannot be de-aggregated. |
The transaction level (item) is allocated as visible in the View Assortment window. However, the allocation is created at the item level one/differentiator (style/color) level. The item level one/differentiator (style/color) level is where retailers work with the allocation.
Simple sellable staple pack and complex sellable staple pack:
These types of packs are included in an allocation when they are individually allocated.
Simple non-sellable staple pack and complex non-sellable staple pack:
These types of packs are included in an allocation when the component of the pack item is allocated or when the non-sellable pack itself is allocated.
Simple sellable fashion packs and complex sellable fashion packs:
These types of packs are included in an allocation when they are individually allocated. They are not being automatically included in any fashion items allocation.
Simple non-sellable fashion packs and single color complex non-sellable fashion packs:
These packs can be allocated as part of a style/color or they may also be allocated individually (components must stay within the pack). They could also be allocated as part of a Fashion Group allocation.
Multi-color complex non-sellable fashion packs:
These packs can be allocated individually or they can be allocated as part of a Fashion Group Allocation.
When fashion items are individually selected for an allocation (rather the selecting a style/color), the items are allocated as staple items.
A single allocation cannot have both fashion item(s) and staple item(s).
Non-sellable fashion packs are visible on the trans level view of the Assortment View screen.
The list of values on the search screen displays staple items, sellable/non-sellable staple packs, and sellable simple/complex fashion packs.
The stop shipment record for a non-sellable staple pack must be at the component item level for the stop shipment to be recognized by Oracle Retail Allocation. A record for the non-sellable staple pack itself has no effect.
