| Oracle® Retail Allocation Operations Guide Release 13.2.9 E72187-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.
A description of how Oracle Retail Allocation uses the Oracle Retail Service Layer (RSL), including the classes that are involved.
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 intergrate 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, style-color, 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, Size Profile Logic in Allocation Calculations 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, Size Profile Logic in Allocation Calculations and see RETL Batch Processing.
Future retail price data
Oracle Retail Allocation uses this data to provide the user with the future retail price value of the entire allocation (based on its quantities). In addition, users can access future retail price values by location and by item. For information about configuration related to this setting, see the section, Display Future Unit Retail Price Values in Backend System Administration and Configuration.
Appointment data
Appointment data is one source that identifies item(s) to be allocated.
Warehouse inventory position data
ASN, BOL, and Transfer information
Shipping schedule data
The external supply chain management system populates the Oracle Retail Allocation-owned table, ALC_SHIPPING_SCHEDULE. This data allows the retailer to have a single view of a shipping schedule that is more detailed than the RMS-owned TRANSIT_TIMES table. This data exists at the department, class, subclass, or item level.
|
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.
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 is divided into the following two sections that address Oracle Retail Allocation's methods of integration:
RSL is a framework that allows Oracle Retail applications to expose APIs to other Oracle Retail applications. As shown in the diagram below, in RSL terms, there is a 'client application layer' and a 'service provider layer'. Oracle Retail Allocation provides the client application layer.
RSL exposes a synchronous method to communicate with other applications. All RSL services are contained within an interface offered by a Stateless Session Bean (SSB).
For RPM integration purposes, these RSL SSBs invoke business logic within the RPM application.
To the client application, each service appears to be merely a method call.
For information about RSL-related configuration within the Oracle Retail Allocation application, see the section JNDI Configuration File Related to RSL in Backend System Administration and Configuration. Also, see the latest RSL documentation which addresses client application layer configuration.
Description of Class Using RSL
The table below briefly describes the functional role that Oracle Retail Allocation's RSL class has within the application.
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_SIZE_PROFILE
Can also be populated through size profile setup via the front-end of the application.
ALC_USERS
The retailer can populate this table through a SQL script. Following script can be used to insert into ALC_USERS table:
Example 5-1 Sample Script
INSERT INTO ALC_USERS ( USER_ID, USER_NAME, USER_PASSWORD, FIRST_NAME, LAST_NAME, MIDDLE_INITIAL,USER_TYPE, LANGUAGE, COUNTRY ) VALUES (ALC_USERS_SEQ.nextval, UPPER(<USER_NAME>), alc_hash(UPPER(<USER_NAME>),<USER_PASSWORD>), <FIRST_NAME>, <LAST_NAME>, <MIDDLE_NAME>, <USER_TYPE>, <LANGUAGE>, <COUNTRY>);
ALC_USER_DEPTS
The retailer can populate this table through an SQL script, but Oracle Retail does not provide this script. Note that when a new user is added to this table, he or she has access to the associated department-level information.
Planning Table in Oracle Retail Allocation
Planning applications populate a planning table, ALC_PLAN, which resides within Oracle Retail Allocation. This table includes the following columns:
Plan ID
Store
EOW.date
Department
Class
Subclass
Item
Diff1_id, Diff2_id, Diff3_id, Dif4_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
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-2 RMS Tables used by Allocation
| RMS Tables | |
|---|---|
|
Functional Area |
Associated Tables |
|
Item data |
SUB_ITEMS_HEAD |
|
SUB_ITEMS_DETAIL |
|
|
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 |
|
|
Security data |
SEC_USER_LOC_MATRIX |
|
SEC_USER_PROD_MATRIX |
|
|
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 |
|
|
Multi-level distribution |
TRANSIT_TIMES |
Oracle Retail Allocation-owned Triggers Residing on RMS Tables
Table 5-3 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
RMS allows for the potential of three item levels. For a customer who allocates based on the concept of style/color, 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 de-aggregated within allocation to distribute only those sizes/components which are available to allocate.
|
Note: Fashion packs cannot be de-aggregated. |
The transaction level (item) are 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 complex non-sellable fashion pack:
An allocation for this pack is performed behind the scenes. The user does not have visibility to the non-sellable pack allocation.
The only way to allocate fashion items is at the style/color level or users can de-aggregate the style/color and allocate the components as individual staple items.
A single allocation cannot have both fashion item(s) and staple item(s).
Non-sellable fashion packs are never returned as part of any search criterion that is visible to the user. Rather, they are handled behind the scene by the application at the style/color level.
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.
For information about Oracle Single Sign-On and Oracle Retail Allocation 13.2.7, please see the latest Oracle Retail Allocation Installation Guide.
For information on how to integrate Allocation with Oracle Retail Workspace, see the latest Oracle Retail Workspace Implementation Guide.
Oracle Retail Workspace is a supported configuration of Oracle WebCenter Spaces 11.1.1.5 for Oracle Retail. For the Oracle Retail 13.2.x enterprise, Oracle Retail Workspace replaces previous versions of Oracle Retail Workspace. There is no more packaged Oracle Retail Workspace code, only configuration instructions for Oracle WebCenter Spaces 11.1.1.5.
The Oracle Retail Workspace configuration utilizes the external application functionality and the application navigator taskflow of the Oracle WebCenter Framework to configure Allocation in Oracle WebCenter Spaces.
