Operations Guide
Release 12.0
May 2006
Contents
Preface.................................................................................................... vii
Who This Guide Is Written For .............................................................................................. vii
What Is Not In This Guide...................................................................................................... vii
Where You Can Find More Information................................................................................. vii
Customer Support .................................................................................................................. viii
Third-Party Open-Source Applications.....................................................................................ix
1 Introduction.......................................................................................... 1
N-tier Technical Architecture Overview....................................................................................2
3 Technical Architecture...................................................................... 19
Overview..................................................................................................................................19
GUI Tier...................................................................................................................................20
Thin-Client Standard ........................................................................................................20
Java Server Pages (JSP) and HTML.................................................................................20
Screen Controller Servlet..................................................................................................20
JavaScript..........................................................................................................................20
JSP Tag Libraries..............................................................................................................20
Middle Tier ..............................................................................................................................21
Service Layer ....................................................................................................................21
Business Object Tier.........................................................................................................21
Data Access Tier...............................................................................................................21
Data Storage Tier .....................................................................................................................22
Accessing Merchandising System Data in Real Time ......................................................22
Summation of n-tier Architectures Advantages......................................................................22
Component Descriptions and Standards ..................................................................................22
iv
Operations Guide v
Preface
Oracle Retail Operations Guides are designed so that you can view and understand the
applications behind-the-scenes processing, including such information as the
following:
Key system administration configuration settings
Technical architecture
Functional integration dataflow across the enterpris
Customer Support
https://metalink.oracle.com
When contacting Customer Support, please provide:
Product version and program/module name.
Functional and technical description of the problem (include business impact).
Detailed step-by-step instructions to recreate.
Exact error message received.
Screen shots of each step you take.
viii
Operations Guide ix
1
Introduction
Welcome to the Oracle Retail Allocation Operations Guide. The guide is designed so that
you can view and understand key system administered functions, the flow of data into
and out of the application, and the applications behind-the-scenes processing of data.
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:
A Java HTML/JSP technology stack allows straightforward development and facile
deployment. Debugging can be performed more rapidly; maintenance and alteration
costs are kept low.
The applications interface takes advantage of Java database connectivity (JDBC),
minimizing the number of interface points that need to be maintained.
The applications robust algorithm executes rapidly.
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. Purchase
order, item, location, and allocation information is passed from RMS to a warehouse
management system, such as the Oracle Retail Warehouse Management System
(RWMS).
The application allows for retailers to adjust to changing trends in the market by
facilitating real time allocations.
Oracle Retail Allocation accounts for flexible supply chain paths to support
importing and domestic inventory supply.
Operations Guide 1
Introduction
JSPs
Javascript
HTML
JSP tag libraries
Service
Layer
GUI/Client tier
Business
objects
Business object
tier
Middle tier
Data access
layer with the
database
version
compatible
driver
Data access
layer tier
JDBC
Database
Database tier
2
Backend System Administration and Configuration
This chapter of the operations guide is intended for administrators who provide support
and monitor the running system.
The content in this chapter is not procedural, but is meant to provide descriptive
overviews of the key system parameters.
Supported Environments
For information about requirements for Oracle Retail Allocations database server,
application server, client PC, and web browser, see the Oracle Retail Allocation
Installation Guide.
Exception Handling
Oracle Retail Allocation-related exceptions are handled through AllocException.
AllocException is located in the following package:
com.retek.alloc.utils
The following types of exceptions are wrapped by AllocException:
SQLException
Other checked exceptions
Errors are logged to the error log file, error_messages.log. For information about error
logging, see the section, Logging, later in this chapter.
Operations Guide 3
Allocation.properties file
A backend system administrator defines configurations for Oracle Retail Allocation in
the Allocation.properties file. The key system parameters contained in this file are
described in this chapter. When retailers install Oracle Retail Allocation into an
environment, they must update some of these values to their applicable settings.
Properties files can be edited through a text editor.
The Oracle Retail Allocation Installation Guide contains step-by-step instructions as to
how to configure some of the environment-related values in the Allocation.properties file.
The TDM Enabled setting is only utilized internally by Oracle Retail. Retailers should
have this value set to false.
For example:
tdmEnabled=false
When Oracle Retail Allocation is packaged and shipped, included is the database driver
used, the URL for the application, and the username. For example:
#### for Alloc 11.1 TDM
url=jdbc:oracle:thin:@mspdev18.retek.int:1521:alctdm02
username=alcdev111tdm
datasource=rms11
Logging
Logging files should be set up to valid directories, so that you can generate logs regarding
errors and messages. For more information about the connection pool, see the passage,
Minimum and maximum pool size to maintain, in this chapter and see the passage,
Pooling, in Chapter 3 Technical Architecture.
The example below shows the default Oracle Retail settings:
For example:
# Log file for connection pool: one for Windows, and another for UNIX
windows.pool.log=c:\\develop\\alloc11.1\\log\\connection_pool.log
unix.pool.log=/u01/webadmin/oc4j_envs/oc4j904_alc11/j2ee/home/log/alc11devconnection_pool.log
# Log file for Error messages: one for Windows, and another for UNIX
windows.error.log=c:\\develop\\alloc11.1\\log\\error_messages.log
unix.error.log=/u01/webadmin/oc4j_envs/oc4j904_alc11/j2ee/home/log/alc11deverror_messages.log
Log Path
This setting defines the location of the file where the retailer would like the log file
written.
For example:
logpath=C:/logs/log.txt
Logger Level
This setting defines the lowest level logs to be written to the log file. The following list
represents the log priority levels in ascending order:
UNKNOWN
FATAL
ERROR
WARN
VALIDATION
INFO
DEBUG
The recommended logger setting is ERROR
For example:
loggerLevel=ERROR
be set to null.
For example:
defaultEmailAddress=someone@oracle.com
be set to null.
For example:
loggerEmailFromAddress=someone@oracle.com
be set to null.
For example:
loggerEmailSubject=Allocation Alert Message
Operations Guide 5
be set to null.
For example:
loggerSyslogHost=10.10.10.10
Log Format
This setting defines the default-logging format for the logging system. All of the
Log4j patterns are supported in addition to the following:
h: Localhost name
i: Database username
u: Database url
a: Application name
k: Exception message
d: Date/Timestamp
p: Severity
c: Location
For example:
log4jLayout=%n#### <Date / Time: %d{dd MMM yyyy HH:mm:ss,SSS}><Severity Level: %5p><Host Name: %h><DB User: %i><DB URL: %u><Location: %c><Message: %k>%n
For example:
loggerCloseStdOutAndErr=false
This value can be set to true if you want to view all of the SQL statements that are being
executed by the system. The majority of the time, this value should be false.
For example:
#Trace?
trace=false
#SQL Trace Level
#traceLevel=1
#traceLevel=4
traceLevel=8
#traceLevel=12
Operations Guide 7
Calculation Settings
The calculation queue polling interval determines the frequency that the queue table is
queried for requested algorithm calculations for allocations that need to be calculated. By
default, the calculation queue is polled once every five seconds. Also, the calculation
input mode on/off switch should be set to true if you need to view the dat files returned
from the algorithm. You also determine the file location to send the dat files.
For example:
calculation queue polling interval in ms.
calculationQueuePollingInterval=5000
# calculation input mode on/off switch for writing .dat files
logCalcInput=false
# Log file for Error messages: one for Windows, and another for UNIX
windows.calcInputLogDirectory=c:\\calculation_dat_files
unix.calcInputLogDirectory=/files0/alloc10/calculation_dat_files
Language to be Loaded
This defines the default language. If a user does not have a language defined, the system
will use this deault. See the section, Internationalization and localization later in this
chapter.
For example:
language=en
country=US
Type of Allocation
The type of Oracle Retail Allocation product purchased can be set as full or lite. If the lite
version has been purchased, the user does not have access to the following functionality:
complex groups, weeks from today, and what if allocations.
For example:
#Type of allocation.
allocType=FULL_VERSION
#allocType=LITE
Operations Guide 9
A higher sensitivity setting makes the forecast more reactive to actual sales, and a lower
setting makes the forecast less reactive to sales.
10
LOV Configuration
If Oracle Retail Allocation is run in a language other than English, this value must be
true. The value ensures correct population of all LOV field values.
For example:
lov_on_change=false
Operations Guide 11
Enabling this setting in the properties file takes default promotions associated with orders
and automatically associates them with the allocation.
For example:
enable_promotions=false
12
This parameter determines first whether or not the system allows allocations to be created
from a warehouse to a warehouse. Secondly, this parameter determines the data sources
for the MLD path. The valid values are shown below along with a description for each.
For more information about MLD, see the section, Multi-level distribution (MLD) in
Chapter 4 Functional design.
0 = Non-MLD
The system continues to utilize the default warehouse value on the store table as its
supply chain information.
1 = MLD using the TRANSIT_TIMES table
Retailers leverage the TRANSIT_TIMES table data that is maintained within RMS.
2 = MLD using the ALC_SHIPPING_SCHEDULE table
The Oracle Retail Allocation-owned table, ALC_SHIPPING_SCHEDULE, allows
the retailer to have a single view of a shipping schedule that is more detailed than the
RMS-owned TRANSIT_TIMES table.
Operations Guide 13
Presentation Minimums
This properties file setting determines the Presentation minimums and Quantity limit
check box default setting on the Select Rules page in Allocation.
For example:
default_presentation_minimum=true
Import Warehouses
The import warehouses properties file setting must be set for all MLD retailers. The value
defines the warehouse(s) that serves as the tier 1 level in the MLD path. These should be
the retailers import warehouses. All tier 1 warehouses must be listed. These warehouses
are used in all MLD item sourced allocations and Item Source Tier What If allocations.
For example:
import_warehouses=66,67
14
True
The selection of the Include Supply Chain On Hand checkbox for an item source
location based what if allocation determines whether or not the expected inventory
and current available inventory in the supply chain are accounted for in the what if
allocation.
False
The selection of the Include Supply Chain On Hand checkbox for an item source
location based what if allocation accounts only for the current available inventory.
For more information about what if functionality, see the Oracle Retail Allocation User
Guide and the section, What if allocations, in Chapter 4 Functional design.
Operations Guide 15
Indicates whether Oracle Retail Service Layer (RSL) for Oracle Retail Pricing
Management (RPM) is running on an IBM application server. The valid values are true
and false.
For example:
rsl_rpm_ibm_server=false
The parameter defines the hierarchy level on which the system queries the
ALC_SHIPPING_SCHEDULE table. The levels selected must include all the path levels
at which the retailer defines its supply chain. Each level added has a performance impact.
Therefore, it is recommended that the retailer use one or two levels to maintain their
shipping schedules. This parameter is necessary to ensure acceptable levels of
performance during product searches. Note that a retailer can enter multiple levels
separated by a comma. The first value represents the primary level of the hierarchy that is
queried, and the ensuing values represent exceptions in other hierarchies. For example, if
a retailer selected D,I, the system queries the table first on a department level and then
searches for item exceptions. The valid values are the following:
D = department
C = class
S = subclass
I = item
The system will use the sister stores need when the records dont exist for a stores need.
sister_store_null = false
The system will use the sister stores need when the records dont exist for a store and
when there are existing records and their need equals zero.
16
Internationalization
The technical infrastructure of Oracle Retail Allocation supports languages other than
English. Oracle Retail Allocation has been subject to the modifications associated with
internationalization, also known as I18N. (The I18N name stems from the fact that
eighteen letters exist between the first i and the last n in the word
internationalization.) Internationalization is the process of preparing software in order
to ensure that it can efficiently handle multiple languages. In other words, the software is
created so that it can be released into international markets.
This section describes configuration settings and features of the software that ensure that
the base application can handle multiple languages.
Multibyte Coding
Oracle Retail Allocation has been developed to be compatible with multibyte languages
(such as Japanese). In multibyte representation, a character may occupy more than one
byte.
Translation
Translation is the process of interpreting and adapting text from one language into
another. Although the code itself is not translated, components of the application that are
translated can include the following, among others:
Graphical user interface (GUI)
Online help
Some print documentation (such as Release Notes, and so on)
Error messages
Operations Guide 17
Single Executable
A single executable can handle multiple languages. Users can choose their preferred
language by setting their ALC User Profile to reflect their desired language. Because the
application contains a single executable, maintenance efforts are minimized. The retailer
does not have to recompile when switching from one language to another. When patches
are released, they only have to be applied once to the code and to the interface.
Properties Files
The internationalized text properties files are named with the standard ISO language and
country code abbreviations. For example, the English / United States properties file is
allocation_text_en_US.properties, and the French / France properties file is
allocation_text_fr_FR.properties. In the case of another English speaking country other
than the Unites States, say Great Britain, the allocation_text_en_US.properties, can either
be renamed or copied to allocation_text_en_GB.properties.
Properties file for internationalization are:
allocation_text_de_DE.properties
allocation_text_en_US.properties
allocation_text_es_ES.properties
allocation_text_fr_FR.properties
allocation_text_ja_JP.properties
allocation_text_ko_KR.properties
allocation_text_pt_BR.properties
allocation_text_zh_CN.properties
allocation_text_zh_TW.properties
18
3
Technical Architecture
This chapter describes the overall software architecture for Oracle Retail Allocation. The
chapter provides a high-level discussion of the general structure of the system, including
the various layers of Java code.
Overview
Oracle Retail Allocation utilizes a Java platform because it offers the optimum solution to
the challenges presented by the need for database independence. A Java platform solves,
for example, RMS version incompatibility issues.
The n-tier architecture of Oracle Retail Allocation allows for the encapsulation of
business logic, shielding the client from the complexity of back-end systems. The
following diagram, briefly discussed in Chapter 1 Introduction, is explained below in
detail according to each of the tiers shown in the diagram.
JSPs
Javascript
HTML
JSP tag libraries
Service
Layer
GUI/Client tier
Business
objects
Business object
tier
Data access
layer with the
database
version
compatible
driver
Data access
layer tier
JDBC
Database
Database tier
Middle tier
Denotes separation of tier
Operations Guide 19
Technical Architecture
GUI Tier
The GUI is responsible for presenting data to the user and for receiving data directly from
the user through the front end.
Thin-Client Standard
The GUI adheres to todays thin-client standard. Whereas a fat client can perform
significant data validations and business processing on the client side itself, a thin client
performs very little processing. Most of the application processing load is handled by the
server.
Oracle Retail Allocation utilizes a thin client because of its advantages. First, there are no
special requirements for the client-machine except that it can adequately run a browser.
Secondly, client machines require little maintenance. That is, there is no need to install
applications on each client machine because the application itself resides on a central
server. Clients need only the browser to access the application. Finally, because standard
HTTP is used, deployment can occur both inside and outside a firewall.
JavaScript
JavaScript is used to handle some non-business rule validations. For example, JavaScript
is responsible for the following:
Date-entry validations
Field-length validations
Alphanumeric validations (for example, a US zip code cannot contain characters, and
so on)
20
Middle Tier
Broadly speaking, the middle tier consists of a service layer, a business object tier, and
a data access tier. Each is described in this section.
Service Layer
The service layer primarily interacts with the GUI by manipulating the data coming from
it, as well as handling transaction processing. While not all business objects are impacted
by the presence of the service layer, allocation services such as saves or loads pass
through it.
Pooling
When the application disconnects a connection, the connection is saved into a pool
instead of being actually disconnected. A standard connection pooling technique, this
saved connection enables Oracle Retail Allocation to reuse the existing connection from a
pool. In other words, the application does not have to undergo the connection process for
each subsequent connection.
Operations Guide 21
Technical Architecture
22
Operations Guide 23
4
Functional Design
This chapter discusses the various functional aspects of Oracle Retail Allocation. The
chapter provides the following:
A functional overview of the system, along with its features and corresponding
functional assumptions.
The sources of data used by rules to determine gross need.
A description of the four possible methods of closing allocations.
Operations Guide 25
Functional Design
Oracle Retail Allocation can react to current trends. The system has sophisticated rules
that can compare current selling to a plan and create a forecast on which to base an
allocation. Oracle Retail Allocation provides the ability to both allocate in advance to
give vendor commitments and allocate at the last minute, utilizing up to date sales and
inventory information to determine individual store need. Some key features of the
application include:
Any PO that a user creates can be previewed through the front end.
In order to increase the efficiency of the allocations process, Oracle Retail Allocation
has the ability to split allocations. By splitting an allocation, the user has the option of
selecting the product hierarchy and location combinations that they would like to
remove from the original allocation.
Oracle Retail Allocation can automatically respect the existence of an item location
record in RMS. See the section, Location exception reason-product sourced, in
Chapter 2 Backend system administration.
Item Sources
Item sources represent the physical inventory that Oracle Retail Allocation can allocate.
The system allows the retailer to allocate based upon the following:
Advanced shipping notices (ASN)
Advanced Shipment Notifications (ASN) are batch communications that inform a
retailer when to expect a certain quantity of order inventory. ASN quantities are
received closer to the time of arrival at the distribution center. Allocations based
upon ASN quantities allow retailers to account for purchase order shortages or
overages as a part of their Oracle Retail Allocation process.
Transfers
Bills of lading (BOL)
Purchase orders
Warehouse-sourced inventory
Because of these item sources, the user is given more access and control to existing
transactions, which increases supply chain efficiencies. The benefit is found in that the
next inventory movement can be communicated to the distribution center before the
inventory arrives and is put on the shelf as warehouse stock.
26
Oracle Retail Allocation retrieves most data in real-time from the Oracle Retail
Merchandising System (RMS). Oracle Retail Allocation only has the need for visibility to
approved items and purchase orders. See Chapter 5 Functional and technical
integration for integration information.
In sum, Oracle Retail Allocation determines the needs of each individual store at the
item-location level through the following capabilities:
The application sorts through large quantities of data, such as sales history, current
on-hands, and store volume groups.
The application applies user-established rules, rule modifiers, and optional quantity
limits.
The application performs complex algorithms that can determine gross need for large
volumes of stores and products, using real time data.
Presentation Minimums
Due to the importance in balancing the need to maintain appropriate store presentation
level and effectively allocate to stores inventory needs, Oracle Retail Allocation can
access item/location Plan O Gram data and dictate to the algorithm the smallest amount
to allocate a given item/location. If the user does not enter any quantity limits manually
and selects the Default Auto Presentation Minimum and Quantity Limits selection in the
GUI, the values from the repository are populated into the algorithm parameters behind
the scenes. This functionality exists for all the valid quantity limits in allocations
including minimum, maximum, threshold, trend, weeks of supply and minimum need.
The defaults may be held at an item hierarchy level or the item level.
Sales history
Forecast
Plan
History and plan
Plan re-project
Corporate
Manual
Operations Guide 27
Functional Design
Although these rules are detailed, the occasion arises where the user needs to base
allocations upon like items. The User Merchandise Level Selection screen allows retailers
to select any combination of like data on which to base allocations. The user may choose
a merchandise hierarchy level, a combination of merchandise hierarchy levels, individual
items or merchandise hierarchy levels combined with individual items. Each combination
of data may be weighted and various date ranges may be selected. For example, an
allocation may necessitate the input of Subclass Zs sales history for week 1, item As
sales history during week 12, and item Bs sales history for week 5. The values selected
by the user are applied to each item on the allocation.
What if Allocations
What if Supply Chain on Hand
A what if source allows the user to create hypothetical allocations. What if allocations
provide users the flexibility of performing additional activities including defining optimal
pre-pack configurations, and creating purchase orders based upon the allocation
calculated quantities. The process is exactly the same as a regular allocation except that
the user starts with an infinite available quantity of the selected product. To avoid the risk
of warehouse imbalances or overstocking, what if allocations have the ability to account
for stock on hand in mid-tier warehouses that are in the supply chain for a given
item/location. By providing visibility to warehouse inventory and including it in the
what if need calculation, locations in the MLD path are stocked more accurately.
28
allow a single path to a store. This statement means that for a given
merchandise hierarchy, each store may be sourced from a single
warehouse. The product supports a V at the top of the supply chain
from one warehouse to another. The top level is defined based on the
table records for an entire MLD path. It does not account for the path
on an individual allocation item source level. The V path
functionality is intended to support multiple import warehouses that
fulfill the same regional warehouses. The system does not support
multiple supply chains at any other level. This statement means that
within a hierarchy level, the retailer cannot have two paths to the
same store.
What if allocations are utilized by retailers to run a number of different allocation
scenarios without being concerned about constrained inventory limitations. This allows
retailers to have a preview of different allocation amounts based on a variety of
calculations using history, plan, forecast, plan-reproject, history and plan, manual or
corporate rule based allocations. Retailers may also use what if allocations to determine
optimal pre-packs for retailer brand goods. After the retailer has determined the best
allocation scenarios, they can execute upon the what if allocation results by creating a
Oracle Retail Merchandising System purchase order from the What If Summary Screen.
Operations Guide 29
Functional Design
30
Operations Guide 31
Functional Design
Functional Assumptions
MLD Assumptions
32
Oracle Retail Allocation accounts for allocations where the same item is coming
from two different item sources. Oracle Retail Allocation prioritizes the use of item
sources based upon on the release date first and foremost. The system uses the earlier
release date item sources first. It then uses inventory from a PO, ASN, TSF, BOL and
WH stocked inventory.
An approval of an allocation results in datas being written to multiple RMS table
records (ALLOC_HEADER and ALLOC_DETAIL tables) for a single allocation
within Oracle Retail Allocation. The relationship is based on the item sources used
on the allocation, mid tier inventory, and the MLD path for the level of the approval
selected by the user.
MLD functionality allows any combination of location-to-location allocations,
excluding store-to-store and store-to-warehouse allocations, as long as the supply
chain path information exists. Need is always derived based upon the stores in the
MLD path for the destination location.
MLD path information does not utilize data entered from a supplier to a store or
warehouse. Any inventory originating with a supplier continues to be based upon the
purchase order date.
Retailers are not able to edit allocations within the Oracle Retail Allocation
application once any portion of the MLD allocation record is being processed by any
of the distribution centers. Any edits at that time would need to be completed by
stock order status messages from the distribution center.
Users may experience slow response from the application when using
ALC_SHIPPING_SCHEDULE to maintain their supply chain and the system is
generating release dates based upon in store dates entered at the location level.
Oracle Retail recommends that the retailer enter release dates to eliminate the system
generation of release dates when using the shipping schedule.
International orders are created six to nine months ahead of the expected delivery
date. If retailers want to utilize allocations to create international POs through the
what if capabilities, they must maintain the ALC_SHIPPING_SCHEDULE table
path six to nine months in the future. Volume considerations may prohibit meeting
performance standards based on the large volume of shipping schedule information
and processing required to contain paths six to nine months in advance.
Shipping schedules require that a store has a single path from the item source
location. However, to account for the importing process the top tier in an MLD path
may have two or more origin and destination records where the destination
warehouses are the same. This multiplicity is only allowed at the top tier in an MLD
path.
Valid shipping schedule information is required during the time period on the
allocation for a retailer to load a previously created allocation successfully. If the
retailer removes shipping schedule data for the date range of the allocation, the user
is not be able to access the allocation. If a store is closed that was open when the
allocation was originally created, the system allows the user to access the allocation,
but it is set to a 'Not Calculated' status.
Oracle Retail Allocation item sources are not individually selectable. A previously
generated allocation may be selected indirectly by being included in a BOL portion
of inventory.
ASN, BOL and TSF sourced allocations are available for MLD and non MLD
retailers. If a non MLD retailer is using the system, the alloc_header.alloc_parent
value is never populated.
Item-location Assumptions
The ITEM_LOC table is where item location relationships are held and maintained from
the Oracle Retail Merchandising System.
The system assumes that all of the items under a style have the same SOM as the
style. In other words, the SOM cannot differ by item under a style.
The ability to calculate an allocation based upon one multiple and create a PO based
upon another multiple may create a discrepancy between the total amount the
allocation calculated initially, and the amount of inventory included in the purchase
order.
The approach to respecting the break pack warehouse indicators assumes that users
accept a warehouse level determination of the break pack level within the supply
chain that spans merchandise hierarchy nodes.
This functionality enables the possibility of overage at the mid-tier warehouses. It
does not validate against the stock holding indicator. Therefore, an allocation could
be created where a non-stockholding DC would have an allocation order that is not
100% flow through.
Promotional buy rounding issue
The use of the order case size as the case multiple for PO sourced allocations creates
a scenario where rounding at the inner causes packaging discrepancies. Note that
when a purchase order is the source of an allocation, the suppliers case pack size may
be different than the pack size defined in the RMS Item data model. Because the
RMS Purchase Order front end does not hold a defined value for an inner size, the
inner defined for the item may not evenly round into the case on the purchase order.
Respecting the break pack warehouse indicator for what if allocation is not possible
because there is no source destination until the moment of PO creation. The Store
Calculation Multiple is the only enforceable number.
Operations Guide 33
Functional Design
What if
Front-end PO location selection only has an effect on the PO to location when the
user is creating a PO with a PO type of warehouse or cross dock, or updating a PO
with a PO type of warehouse. For all other types of PO actions, the value has no
relevance.
The major assumption associated with this functional area is that basing the
allocation amounts on future available supply chain on hand amounts assumes that
the amount inventory that is expected within the supply chain warehouses will arrive
and that the business user will create a separate allocation to move the inventory to
the stores. The records that Oracle Retail Allocation writes to ALLOC_HEADER
and ALLOC_DETAIL does not include the future available inventory at the mid tier
locations. Oracle Retail Allocation only writes records for inventory that is currently
available in the mid tier warehouses. There is no way to determine the source of the
expected inventory and write a cross-dock record for the mid tier expected inventory.
What if allocations utilize the primary suppliers primary origin countries inner,
case and pallet size only. If a retailer wants to use the dialogue to create a PO to a
supplier that does not have the same multiple as the primary supplier, the functional
recommendation is to calculate the allocation and create the order using an Each
multiple. The multiple can then be adjusted within the merchandising system.
34
The many-to-one functionality is available to users when using automatic rule types,
except for corporate rules and manual.
The system allows the user to add the same item or merchandise hierarchy level
twice. This is intentional because various date ranges and weights may be applied.
Users are responsible for adjusting the weight and date appropriately.
When a user changes the in store date, or adds/removes a date, the allocation should
be re-calculated.
Release dates for PO sourced allocations are used within the PO creation logic. The
in store date and release date do not take into account partial days. Same day delivery
is a possibility.
No freight cost is calculated if the In Store Date is not specified.
No freight cost is calculated if the item on the allocation does not have a weight and
weight unit of measure value in the ITEM_SUPP_COUNTRY_DIM table within
RMS.
No rush flag is calculated if the in store date is not specified.
Cost is always expressed in the systems primary currency.
Allocation Status
Significant functionality is attached to the status numbers in the system. The tables below
reflect the status column on the ALC_ALLOC table.
Description
Status #
Worksheet
Submitted
Approved
Processed
Closed
Cancelled
Operations Guide 35
Functional Design
Status
Description
Status #
Reserved
PO Created
10
Description
Status #
Deleted
Approval In Process
Reservation In
Process
36
Status
Description
Status #
Not Calculated
Calculation Waiting
Calculating
Calculated
Status
Description
Status #
Calculate Later
Calculation Error
7
Size Profile Calculation The size profile was not found for all
Error
style/color combinations on the allocation.
Users must adjust their size profiles and
recalculate the allocation.
Ideal Weeks of Supply
(IWOS) Calculation
Error
Quantity Limits
Conflict
Status Error
10
Status Waiting
Status Processing
Status Processed
13
Available Inventory
Error
14
Operations Guide 37
Functional Design
38
Status
Description
Status #
Legacy System
DEPT_SALES_HIST
This table contains one row for each deptlocation-week-sales type combination. Sales
history, forecast and plan information about
each combination is held.
CLASS_SALES_HIST
This table contains one row for each classlocation-week-sales type combination. Sales
history, forecast and plan information about
each combination is held.
SUBCLASS_SALES_HIST
This table contains one row for each subclasslocation-week-sales type combination. Sales
history, forecast and plan information about
each combination is held.
ITEM_LOC_HIST
This table contains one row for each itemlocation-week-sales type combination. Sales
history, forecast and plan information about
each combination may be held here.
Operations Guide 39
Functional Design
Legacy System
DEPT_SALES_FORECAST
CLASS_SALES_FORECAST
SUBCLASS_SALES_FORECAST
ITEM_FORECAST
40
Legacy System
DEPT_SALES_HIST
This table contains one row for each dept-locationweek-sales type combination. Sales history,
forecast, and plan information about each
combination is held.
CLASS_SALES_HIST
This table contains one row for each class-locationweek-sales type combination. Sales history,
forecast, and plan information about each
combination is held.
SUBCLASS_SALES_HIST
This table contains one row for each subclasslocation-week-sales type combination. Sales
history, forecast, and plan information about each
combination is held.
ITEM_LOC_HIST
This table contains one row for each item-locationweek-sales type combination. Sales history,
forecast, and plan information about each
combination may be held here.
Operations Guide 41
Functional Design
Legacy System
DEPT_SALES_HIST
This table contains one row for each deptlocation-week-sales type combination. Sales
history, forecast, and plan information about
each combination is held.
CLASS_SALES_HIST
This table contains one row for each classlocation-week-sales type combination. Sales
history, forecast, and plan information about
each combination is held.
SUBCLASS_SALES_HIST
This table contains one row for each subclasslocation-week-sales type combination. Sales
history, forecast, and plan information about
each combination is held.
ITEM_LOC_HIST
This table contains one row for each itemlocation-week-sales type combination. Sales
history, forecast, and plan information about
each combination may be held here.
Corporate Rules
For this rule, data is gathered from the selected column of the following tables in Oracle
Retail Allocation:
ALC_CORPORATE_RULE_HEAD
ALC_CORPORATE_RULE_DETAIL
The column selection is based on which corporate rule is picked by the user.
Note: If the retailer plans ideal weeks of supply (IWOS) by
Quantity Limits
Quantity limits allow the user to set parameters which affect different stages of the
allocation for the product-stores where they are entered. The values for each applicable
quantity limits selection are held on the applicable column of the
ALC_QUANTITY_LIMITS table.
42
Stop Ship
A stop ship is a product/location combination that prevents an item from shipping to
that location. The system looks at the release dates entered on the product window and
compares them with stop ship records entered via the merchandising system. If the
release date is on or between the stop ship dates, the system inserts 0 into the min and
max columns of quantity limits for this store-item. Stop shipment records appear as item
location exceptions.
The release date is on the ALC_ITEM_LOC table and is represented by the column,
release_date. The STOP_SHIP table contains the stop ship date range: start_date and
end_date. In order for a stop ship record to stop shipment of an allocation, the store,
department, class, and subclass of the allocated item must match the store, department,
class, and subclass on the stop_ship record, or the store and style (for fashion) or item
(for staple) of the item being allocated must match the store and item_id on the
STOP_SHIP table. See the Oracle Retail Allocation User Guide for more information.
Operations Guide 43
Functional Design
Outgoing transfers +
Return to vendor stock+
Unavailable stock+
Transfers on reserve
An abbreviated version of this equation would be the following:
(SOH +InTransit+OnOrder+TSF Expected+OnAlloc)
(TSFOut+RTV+Unavailable+TSF Reserved)
Closing Allocations
This section addresses the three possible methods of closing allocations. Note that the
closure of the allocation in Oracle Retail Allocation entails all or nothing processing
logic.
Oracle Retail Allocation and RMS in the context of the three methods of allocation
closures:
1. Warehouse and Store initiated Closures:
The majority of RMS allocation records should be closed as part of the retailers
Warehouse Management system and the retailers Store Inventory Management
system integration with RMS.
2. For purchase orders closed via batch functionality:
RMS allocation records attached to these closed purchase orders are closed, if the
allocation meets RMS validations. RMS cancels the associated quantities on the
RMS allocation records and closes the RMS allocation records. All the quantities
remaining for related RMS allocation records are cancelled, and the RMS allocation
records are closed if no quantities are in transit. If the RMS allocation records cannot
be closed, there is no further action.
3. For purchase orders closed manually online:
If RMS allocation records exist when the user attempts to either cancel an item or
cancel all items, a message offers the user an option to cancel the associated RMS
allocation records or not. If the user selects to close the allocations, all the quantities
remaining for related RMS allocation records are cancelled, and the RMS allocation
records are closed if no quantities are in transit. If the user selects to not close the
allocations, there is no further action.
Note: The Oracle Retail Allocation application is updated
44
5
Functional and Technical Integration
Overview
This chapter discusses the integration among Oracle Retail Allocation and other systems.
The chapter 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.
Operations Guide 45
External supply
chain
management
system
Oracle Retail
Price
Management
(RPM)
Merchandising
system
(RMS
Legacy systems)
Planning
table
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.
Oracle Retail
Warehouse
Management System
(RWMS)
46
Active
Retail
Intelligence
Plan data
Oracle Retail Allocation accesses plan data from RMS. Oracle Retail Allocation
accesses department, class, subclass, style-color, or item plan data at the store-week
level. When interfacing with legacy planning information, Oracle Retail Allocation
accesses item, style-color, subclass, class, or department level plan data at the
location-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 retailers plan or forecast and execute it. 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.
Appointment data
Appointment data is one source that identifies item(s) to be allocated.
Warehouse inventory position data
ASN, BOL, and Transfer information
Operations Guide 47
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)
48
Operations Guide 49
50
Functional Description
PurchaseOrderServiceWrapper.java
PriceServiceWrapper.java
Operations Guide 51
52
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.
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
LOC_LIST_HEAD
LOC_LIST_DETAIL
LOC_LIST_CRITERIA
DEPS
CLASS
Operations Guide 53
RMS Tables
SUBCLASS
Organizational hierarchy data
STORE
WH
WH_STORE_ASSIGN
Shipment data
SHIPMENT
SHIPSKU
STORE_GRADE_GROUP
STORE_GRADE
STORE
BUYER
STORE_GRADE_STORE
Security data
SEC_USER_LOC_MATRIX
SEC_USER_PROD_MATRIX
LOC_TRAITS
LOC_TRAITS_MATRIX
LOC_AREA_TRAITS
LOC_REGION_TRAITS
LOC_DISTRICT_TRAITS
Transfer data
TSFHEAD
TSFDETAIL
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
54
RMS Tables
Appointment data
APPT_HEAD
APPT_DETAIL
Multi-level distribution
TRANSIT_TIMES
Details
ALC_TABLE_ALD_AUR 1 4
ALLOC_STATUS_TRIGGER
ALLOC_STATUS_TRIGGER_AU
Operations Guide 55
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
56
UPC-A
400000152035 - 100%
Cotton Sheets:Dark
Blue:Plaid:N
UPC-A
400000152073 - 100%
Cotton Sheets:Dark
Brown:Plaid:N
UPC-A
400000152042 - 100%
Cotton Sheets:Dark
Blue:Plaid:S
UPC-A
400000152080 - 100%
Cotton Sheets:Dark
Brown:Plaid:S
UPC-A
400000152011 - 100%
Cotton Sheets:Dark
Blue:Leopard:N
UPC-A
400000152059 - 100%
Cotton Sheets:Dark
Brown:Leopard:N
UPC-A
400000152028 - 100%
Cotton Sheets:Dark
Blue:Leopard:S
UPC-A
400000152066 - 100%
Cotton Sheets:Dark
Brown:Leopard:S
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 will have their item and differentiator aggregate
indicators = '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
Operations Guide 57
Staple Item
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 will be no roll
up of item information as there is behind the scenes when the retailer is looking at fashion
items at the style/differentiator level. 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.
Pack Item
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.
58
Operations Guide 59
6
Allocation Calculations
Calculation Queue Processing
The following diagram offers an overview of the calculation queue process. Explanations
of the numbered steps follow the diagram. Note that the numbers do not necessarily
reflect the systems order of operation but are provided to facilitate the discussion of the
process.
Calculation
queue
Gather need
Gather on-hand
Algorithm
Database
Operations Guide 61
Allocation Calculations
62
Queue Scripts
Oracle Retail Allocation includes sample scripts for queue management. These scripts are
examples provided for the retailers convenience.
The queue process includes calculation, prepack optimization, fashion recalculation, and
all approval processes.
There is no maximum number of queues that can be run at any given time. Processor and
memory limits (specific to a retailers implementation) on a given Windows or UNIX
box determine a maximum number.
Start (queue_111.sh)
This script is used for queue management. The script calls set111.sh to set variables that
are needed to run the queue. The command syntax is as follows:
queue_111.sh start x
The command starts an instance of the queue. x represents an integer which serves as
the ID for the queue being started. This integer should be unique among all instances of
the queue being run.
When the queue is started, the script attempts to create a log for the queue in a
subdirectory of the current directory. Note that this subdirectory is referred to as logs in
the script template. Retailers can specify any location they wish for these log files. The
referenced directory should be created prior to running the script. Existing log files are
overwritten when a queue is started.
Stop (queue_111.sh)
The command syntax that stops an instance of the queue specified by the integer x is as
follows:
queue_111.sh stop x
Status (queue_111.sh)
The command syntax that provides status information about an instance of the queue
specified by the integer x. is as follows:
queue_111.sh status x
Restart (queue_111.sh)
The command syntax that stops and restarts an instance of the queue specified by the
integer x is shown below. The newly started instance of the queue contains a new
process identification number (PID) and creates a new log file that replaces the existing
log file.
queue_111.sh restart x
where <name> represents any name you would like to use to refer to the queue.
Operations Guide 63
Allocation Calculations
be a constant between 0.0 and 1.0 (This parameter influences the balance between
model sensitivity and robustness, that is, how responsive the model is to new sales
data).
Additionally, define
M
P p ( j ) as the sum of the sales plan over the entire season, and
j =1
M
P
X P
x ( j ) p( j ) + p( j )1 for periods j = M+1, , N.
P
P P
64
The motivation for this forecast is relatively clear. The forecast is a convex
combination of a scaled version of the sales plan, p ( j ) X , and the original sales
P
plan itself. The scaled version of the sales plan is scaled based upon the ratio of the
achieved historical sales to the historical sales plan (for example, if the retailer sold
twice what it had planned to sell in the past, then the scaled plan would be twice the
original plan). Thus, if the retailer had no confidence in the magnitude of the original
sales plan (but still believed in its time profile or shape), then the scaled plan would
probably be a good forecast on its own. On the other hand, if the retailer really still
believes in the plan and the retailer does not believe that the recent past performance
is indicative of future performance, then it would make sense to stick with the
original sales plan as the forecast.
In the forecasting algorithm, the weights assigned to the scaled and original plans
represent the confidence in the respective portions. As P becomes larger (that is,
P
the portion of the plan that can be compared to historical sales increases), the retailer
tends to have more confidence in the scaled plan. For example, if P = 0.01, then
P
the retailer really does not have much information upon which to base the scaled
plan. On the other hand, for example, as the quantity approaches 0.5 (that is, the
season is half way over), then the retailer really should start seriously considering
why the plan was incorrect. The retailer may have greater belief in the scaled plan.
Additionally, the parameter is used to tweak the sensitivity of the forecasting
method. As increases, the forecast will tend to stay closer to the original plan. For
small values of , the forecast will move rapidly towards the scaled plan as
historical sales data becomes available. Retailers should use their own data and
judgment to determine an appropriate for their particular business problem at
hand. For more information, see the section Bayesian sensitivity factor in Chapter
2 Backend system administration and configuration.
Guidelines
Bayesian forecasting is primarily designed for use with new product-location positions.
The following guidelines should be followed:
1. No more than one plan should exist for a given product-location position.
2. Any time period with non-zero actuals for a given product-location position should
have a corresponding plan component (otherwise the system will assume a plan
exists and equals zero and will act accordingly).
3. Any non-zero actuals not within the time period of interest should be overridden to
zero.
Operations Guide 65
Allocation Calculations
e4
St
or
e5
St
or
e
St 8
or
e1
0
St
or
e2
St
or
e9
St
or
e6
St
or
e1
St
or
e7
St
or
St
or
e3
0%
When this staircase container fills with water, all locations to the left of the waterline
would receive an allocation quantity that satisfies need. All locations to the right of the
waterline would not receive an allocation because their existing stock satisfies need. The
final allocation does not guarantee that all stores end with the same percentage of need,
but instead guarantees that all locations which receive an allocation has the same
percentage of need and that all others are at or above this percentage of need.
100%
80%
60%
40%
20%
0%
Store3
Store5
66
Store10
Store9
Store1
Rounding Conditions
Some allocation algorithms use rounding rules to determine when to round fractional
components up or down to whole number answers. However, simple rounding often
causes problems if not handled appropriately, including the allocation of too many or too
few items. By using sophisticated optimization techniques, Oracle Retails allocation
algorithm deals in whole numbers directly and avoids rounding.
Allocation of Packs
Oracle Retail Allocation optimally allocates packs of multiple items based on stores
need for the individual component items in the packs. The benefit of this approach is that
the system does not follow arbitrary rules for allocating packs and items. Instead, a
consistent holistic approach is used. The potential answers are evaluated by how well the
resulting allocation of component items satisfies the stores need for the individual items.
See front-end documentation for a definition of the two types of packs, sellable and nonsellable.
Note the following conditions that apply to sellable packs:
A sellable pack is connected to plan data and to forecast data via the pack_no rather
than the component items.
The ITEM_LOC_HIST table is used to determine the item-level history for a sellable
pack.
The on-hand value for a sellable pack is for the pack rather than for the components.
Note the following condition that applies to non-sellable packs:
When the user selects a style-color to allocate, the system retrieves all non-sellable
packs that contain only that style-color.
Retrieved non-sellable packs are not displayed for the user, but the contents of the
pack are included in the available quantity.
The on-hand value for a non-sellable pack is at the component level. The on-hand
value can be generated for the style-color.
The need value for a non-sellable pack is determined at the component level. The
need value can be generated for the style-color.
Allocation transactions respect both open stock (items) and the associated pack level.
Operations Guide 67
Allocation Calculations
By considering the entire matrix of available packs against component-store need for
optimization, Oracle Retail Allocation provides a sophisticated solution for the
distribution of multi-product packs.
The following example illustrates a relatively simple fashion prepack allocation:
The user selects a style to allocate. The system determines the availability of the
style, in the warehouse or from a PO, and understands the quantity available to
allocate and the prepack matrix (the component makeup of the pack). The user sees
the total number of items available for the style, 420 units in the example below.
Prepack
Matrix
Packs
Available
S
Items
Available
Pack 1
20
240
Pack 2
15
180
The user picks a rule that defines the need for the styles being allocated. Note that
this need is for the style, not for the component items or for the packs.
Need for style
Store 1
150
Store 2
150
Store 3
100
The allocation system looks up the appropriate size curve for each style-store, based
on the style or subclass. Size curves are not calculated during the allocation process.
Oracle Retail Curve or another similar system is used to calculate size profiles.
Size curve
S
Store 1
20%
50%
30%
Store 2
20%
30%
50%
Store 3
20%
30%
50%
Need for each individual item is calculated by multiplying style need by the size
curve.
Item need
S
68
Total
Store 1
30
75
45
150
Store 2
30
45
75
150
Store 3
20
30
50
100
Finally the allocation algorithm determines the optimal allocation of packs. Inputs to
the process are the Prepack Matrix, Packs Available, and Item Need above. Other
inputs not shown in this example may be included (for example, minimum,
maximum, threshold, store on-hands, and so on).
Pack allocation
Pack 1
Pack 2
Store 1
12
Store 2
11
Store 3
The user sees the result in terms of number of allocated per style, as shown in the
following table:
Style allocation
Need
Allocation
Store 1
150
156
Store 2
150
156
Store 3
100
108
The user can also view the results by individual item to make sure the size
distribution is correct. If the distribution is poor, action may need to be taken such as
the ordering of more products or the breaking packs before allocation.
Item allocation
S
Store 1
39
75
42
Store 2
39
45
72
Store 3
27
30
51
The objective of the algorithm is to minimize the variance between the actual
allocation and need across all item-store combinations.
Operations Guide 69
Allocation Calculations
Cascade Allocations
In many circumstances, merchandise issues that come up at the item level can be
accommodated by adjusting allocations at higher levels in the merchandise hierarchy.
The Oracle Retail Allocations allocation optimization algorithm is applied to cascade
allocations.
The following example illustrates a cascade allocation:
The retailer is running an ad for t-shirts, with a picture of the yellow one. All t-shirts
are displayed on a store table all together. The yellow t-shirt has been allocated, and
the next step is to make sure that every store has an adequate stock of all t-shirts to
support other customer choices.
On a per item basis, the simple mode allocation distributes as much quantity as is
available, up to the calculated need. However, the cascade mode allocation exceeds
the item need if it is necessary to meet the category need. The chart, Total item need
vs. allocation, illustrates that more of all the t-shirts are distributed by cascade
mode, and that two of the t-shirts are allocated above and beyond their need in order
to satisfy the total category demand.
60
50
40
30
20
10
0
Need
Simple Mode
Cascade Mode
70
The chart, Total category-store need vs. allocation, illustrates that the category
need is exactly met by cascade mode. This simplistic example illustrates the systems
preference for stocking the store for category performance rather than for mere item
performance.
80
70
60
50
40
30
20
10
0
Store 1
Need
Store 2
Simple Mode
Store 3
Cascade Mode
To obtain these results, the user selects the t-shirts to be allocated, using a plan rule,
at subclass (or any appropriate) level, in cascade mode. Remember that selecting
cascade means instructing the allocation to favor the need to fill the t-shirt table, over
the need or lack of available quantity for any specific shirt. Constraints such as
minimum and maximum can be used to ensure the resulting assortment is reasonable.
Behind the scenes, the system determines setup information, including the number of
items available to allocate, the number of items on hand at the stores, and the need by
category-store.
Operations Guide 71
Allocation Calculations
Solid
Striped
Solid
Striped
Logo
Logo
Color
Yellow
Yellow
White
Blue
White
Blue
Available
80
85
16
20
Total
201
Solid
Striped
Solid
Striped
Logo
Logo
Color
Yellow
Yellow
White
Blue
White
Blue
Total
Store 1
50
50
20
20
15
15
170
Store 2
30
30
10
10
10
95
Store 3
30
30
10
10
90
Total
110
110
40
30
35
30
On-hand
Store 1
250
170
Store 2
125
95
Store 3
125
90
The next steps involve the examination of the need by category-store in order to
determine the need by item-store. The following results occur when allocating using
the Oracle Retail Allocation algorithm in simple and cascade mode. Cascade mode
uses exactly the same information as simple mode, with the addition of the category
targets. Constraints such as minimum, maximum, and threshold could be added to
both calculations. Cascade mode can consider optional constraints at the category
level.
72
Solid
Striped
Solid
Striped
Logo
Logo
Color
Yellow
Yellow
White
Blue
White
Blue
Total
Store 1
10
Store 2
Store 3
Total
Cascade-Mode Allocation
Style
Solid
Striped
Solid
Striped
Logo
Logo
Color
Yellow
Yellow
White
Blue
White
Blue
Total
Store 1
35
35
80
Store 2
12
30
Store 3
12
10
35
Total
50
59
16
20
Operations Guide 73
Allocation Calculations
Staple Cascade
Explanations of Pass 1 and Pass 2 follow the diagram.
Pass 1
Pass 2
Staple Cascade
Pass 1
GN1 = Gross need at a location
SOH1 = Sum of SOH for all items in ItemList-D-C-SC at that location
NN1 = Net Net (after Pass 1)
NN1 = GN1 = SOH1Pass 2
Divide NN1 among all items (X) at a location [NN1x=NN1/3]
NN11 = Cascaded need for item 1 at the location
NN12 = Cascaded need for item 2 at the location
NN13 = Cascaded need for item 3 at the location
Each item-location still has individual SOH.
SOH21 = SOH for item 1 at the location
SOH22 = SOH for item 2 at the location
SOH23 = SOH for item 3 at the location
Need applied to each individual item at the location
NN21 = NN11 SOH21
NN22 = NN12 SOH22
NN23 = NN13 SOH23
74
Location 1
Fashion Cascade
Explanations of Pass 1, Pass 2, and Pass 3 (not shown in the diagram) follow the
diagram.
Location 1
GN
Pass 1
Pass 2
Style color level
NN11
NN12
NN12
NN21
NN22
NN23
NN31
NN32
Fashion Cascade
Pass 1
GN=Gross need at a location
Pass 2
Divide GN among all styles at given location to get GN, and subtract SOH, for each
style-color to get NNx
NN1 = GN1 SOH1
NN2 = GN2 SOH2
NN3 = GN3 SOH3
Pass 3
Explode NNx out to sizes to get applied net need NNxy
Style 1
Style 2
Style 3
NN11
NN21
NN31
NN12
NN22
NN32
NN13
NN23
NN33
Operations Guide 75
NN33
Allocation Calculations
Tier 2
Tier 3
Store1
WH2
Store2
WH1
WH3
Store4
76
WH4
Store3
Calculation 1
NN13
WH4
Store3
SOH13
Avail =
Calculation 2
NN11
Store1
SOH11
WH2
NN12
Avail =
Store2
SOH12
Calculation 3
R1-SOH
WH3
WH4
Avail =
Where:
NNxy is the net need for item x at location y.
SOHxy is the stock on hand for item x at location y.
Rx is the result of Calculation x.
Operations Guide 77
Allocation Calculations
Calculation 4
R2-SOH
WH2
R3-SOH
WH1
WH3
NN14
Store4
SOH14
Where:
NNxy is the net need for item x at location y.
SOHxy is the stock on hand for item x at location y.
Rx is the result of Calculation x.
78
Allocation Phase
The allocation phase is used to determine the amount to be allocated to each of the stores
where the available at the source location is based on the amount allocated to the source
location plus the stock on hand at that location. The following diagrams illustrate the
calculations performed in the allocation phase.
Calculation 5
NN11
Store1
SOH11
WH2
NN12
Avail = RWH2
Store2
SOH12
Calculation 6
R1-SOH
WH3
WH4
Avail = RWH3
Calculation 7
NN13
WH4
Store3
SOH13
Avail = RWH4
Allocation Phase
Where:
NNxy is the net need for item x at location y.
SOHxy is the stock on hand for item x at location y.
RWHx is the amount allocated to warehouse x.
Operations Guide 79
Allocation Calculations
Prepack Algorithm
Retailers sometimes want to configure the number of prepacks and the configuration of
prepacks that are to be used to provide merchandise to stores. The benefit of optimizing
prepack definitions is reduced warehouse handling costs. More efficient packs result in
better in-store levels using packs purchased, and less time and money spent breaking
packs at seasons end.
In these instances, a prepack algorithm provides suggested prepack configurations that
will most closely fit store needs. The prepack configuration algorithm is a different
algorithm than the one called out earlier in the diagram, Oracle Retail Allocation
calculation queue process. The prepack algorithm does not write any transactions inside
the merchandising system.
The following example illustrates the prepack algorithm:
The table below shows item-store need, which was calculated as the product of stylestore need and a size curve.
Item need
S
Total
Store 1
30
75
45
150
Store 2
30
45
75
150
Store 3
20
30
50
100
The need represents the ideal allocation. Configuring two prepacks allows that need
to be satisfied, assuming that the working environment is pre-season mode and that
the supplier allows for the specification of prepack configurations.
For a given set of items, and a corresponding item-store allocation such as the need
above, the user specifies some values:
How many prepacks would you like to create?
What is the minimum and maximum size for these, in total items?
For this example, the values selected are 2, 12, and 12.
Prepack configuration
# Packs
Item Set
Min
Max
12
12
Using the same logic that the system utilizes when engaged in a prepack calculation,
the system evaluates the possible prepack combinations to find which allows for the
best allocation for the need defined.
Prepack matrix
S
80
Pack 1
Pack 2
By running the allocation above with this prepack matrix, the following allocation
can be achieved.
Pack allocation
Pack 1
Pack 2
Store 1
Store 2
Store 3
At a style level, the following values more closely satisfy the stores total need.
Style allocation
Need
Allocation
Store 1
150
156
Store 2
150
144
Store 3
100
96
At an item level, the results for medium and large items are very similar, but for the
small item, the result is much better. Need by store is 30 30 20, and the result, 33 27
18, is better than 39 39 27.
Item allocation
S
Store 1
33
75
48
Store 2
27
45
72
Store 3
18
30
48
A retailer could now communicate the ideal configuration to the supplier. The
configurations can be set up in the merchandising system and used when creating the
purchase order.
Operations Guide 81
Allocation Calculations
Example Scenarios
The examples below demonstrate how the system determines the path for any given store.
The examples are based upon the month of July, shown below.
July
Sun
Tues
Wed
Thurs
Fri
Sat
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
82
Mon
Las Vegas
Holiday HUB DC
Physical WH 350
Virtual WH 351
SOH = 0
Las Vegas
Store 6789
Need = 20
ASN 24
PO 3001
Expected Date 7/16/2005
Item - TV
Quantity - 52
ITEM_ID
TV
TV
TV
RELEASE_DATE
7/14/2005
7/16/2005
7/17/2005
LOCATION_ID
251
351
6789
LOCATION_DESC
Utah
Las Vegas
Las Vegas
ALLOCATED_QTY
20
CALCULATED_QTY
20
NEED_QTY
20
ON_HAND_QTY
FUTURE_ON_HAND_QTY
52
The allocator sees the following numbers through the front end screen related to what if
summary data.
Item
SOH
Future Fulfillment
PO Amount
TV
251
20
20
Operations Guide 83
Allocation Calculations
Depart= 7/4/2005
Arrive=7/5/2005
Seattle
Deconsolidation Center
Physical WH 100
Virtual WH 101
SOH = 0
Depart= 7/2/2005
Arrive=7/4/2005
Denver
Regional Distribution Center
Physical WH 200
Virtual WH 201
SOH = 5
Colorado Springs
Store 1234
Need = 20
Depart= 7/4/2005
Arrive=7/5/2005
Depart= 7/2/2005
Arrive=7/5/2005
L.A.
Deconsolidation Center
Physical WH 150
Virtual WH - 151
SOH = 0
Utah
Depart= 7/5/2005
Regional Distribution Center Arrive=7/6/2005
Physical WH 250
Virtual WH - 251
SOH = 0
ASN 24
PO 2001
ASN 22
PO 2000
Expected Date - 7/4/2005
Item - TV
Quantity - 18
84
Las Vegas
Holiday HUB DC
Physical WH 350
Virtual WH 351
SOH = 1
Depart= 7/6/2005
Arrive=7/7/2005
Denver
Store 4567
Need = 20
Las Vegas
Store 6789
Need = 20
ITEM_ID
TV
TV
TV
TV
TV
TV
TV
RELEASE_DATE
7/2/20
05
7/4/2005
7/5/2005
7/6/2005
LOCATION_ID
101
201
1234
4567
251
351
6789
LOCATION_DESC
Seattle
Denver
Colorado
Springs
Denver
Utah
Las
Vegas
Las
Vegas
ALLOCATE_QTY
25
25
20
20
19
20
CALCULATED_QTY
25
25
20
20
19
20
NEED_QTY
25
25
20
20
19
20
ON_HAND_QTY
FUTURE_ON_HAND_QTY
15
20
Operations Guide 85
Allocation Calculations
The allocator sees the following number through the front end screen related to what if
summary data.
Update Type = Warehouse, cross-dock or bulk quantities
Select PO Location = Blank (the default will always be the warehouse selected by the user as the
item source location)
Item Warehouse
Final Allocation
SOH
Future Fulfillment
PO Quantity
TV
60
29
25
101
Note the future fulfillment value is 29 not 30 (only 19 of the future SOH at
WH 251 is necessary to fulfill the need
at store 6789)
Update Type = Warehouse, cross-dock or bulk quantities
Select PO Location = Regional
Item Warehouse
Final Allocation
SOH
Future Fulfillment
PO Quantity
TV
60
30
25
101
Final Allocation
SOH
Future Fulfillment
PO Quantity
TV
60
30
60
101
inventory quantities.
86
Depart= 7/4/2005
Arrive=7/5/2005
Seattle
Deconsolidation Center
Physical WH 100
Virtual WH 101
SOH = 0
L.A.
Deconsolidation Center
Physical WH 150
Virtual WH - 151
SOH = 0
Denver
Regional Distribution Center
Physical WH 200
Virtual WH 201
SOH = 5
Colorado Springs
Store 1234
Need = 20
Depart= 7/4/2005
Arrive=7/5/2005
Utah
Depart= 7/5/2005
Regional Distribution Center Arrive=7/6/2005
Physical WH 250
Virtual WH - 251
SOH = 0
Las Vegas
Holiday HUB DC
Physical WH 350
Virtual WH 351
SOH = 1
Depart= 7/6/2005
Arrive=7/7/2005
Denver
Store 4567
Need = 20
Las Vegas
Store 6789
Need = 20
ASN 30
PO 300
ASN 32
PO 332
Operations Guide 87
Allocation Calculations
ITEM_ID
TV
TV
TV
TV
TV
TV
RELEASE_DATE
7/4/2005
LOCATION_ID
201
1234
LOCATION_DESC
Denver
ALLOCATED_QTY
25
20
20
14
14
20
CALCULATED_QTY
25
20
20
14
14
20
NEED_QTY
25
20
20
14
14
20
ON_HAND_QTY
7/5/2005 7/6/2005
4567
251
351
6789
FUTURE_ON_HAND_QTY 15
0
0
0
6
0
The allocator sees the following number through the front end screen related to what if
summary data.
Update Type = Warehouse, cross-dock, or bulk quantities
Select PO Location = Blank (the default is always the warehouse selected by the user as the item
source location)
Item Warehouse
Final Allocation
SOH
Future Fulfillment
PO Quantity
TV
201
60
10
25
TV
251
20
14
88
Item Warehouse
Final Allocation
SOH
Future Fulfillment
PO Quantity
TV
60
55
151
Final Allocation
SOH
Future Fulfillment
PO Quantity
TV
60
55
39
151
Operations Guide 89
7
Java Batch Process
Oracle Retail Allocation contains one batch process that is run in Java. This batch process
deletes allocation records that have been marked as delete in the database.
Batch Process
Package
Batch purge
Purge.java
com.retek.alloc.batch
Functional Description
The following table includes a description of Oracle Retail Allocations batch process.
Batch Processes
Details
Batch purge
(Purge.java)
Operations Guide 91
setPurge.sh
purge.bat (Windows)
and
purge.sh
92