Anda di halaman 1dari 102

Oracle Retail Allocation

Operations Guide
Release 12.0
May 2006

Copyright 2006, Oracle. All rights reserved.


The Programs (which include both the software and documentation) contain proprietary information; they are
provided under a license agreement containing restrictions on use and disclosure and are also protected by
copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or
decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in
the documentation, please report them to us in writing. This document is not warranted to be error-free.
Except as may be expressly permitted in your license agreement for these Programs, no part of these
Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on
behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data
delivered to U.S. Government customers are "commercial computer software" or "commercial technical data"
pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As
such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and
technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license
agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial
Computer SoftwareRestricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood
City, CA 94065
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for such
purposes, and we disclaim liability for any damages caused by such use of the Programs.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third parties.
Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear
all risks associated with the use of such content. If you choose to purchase any products or services from a
third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the
quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third
party, including delivery of products or services and warranty obligations related to purchased products or
services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with
any third party.

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

2 Backend System Administration and Configuration........................ 3


Supported Environments............................................................................................................3
Supported Oracle Retail Products ..............................................................................................3
Exception Handling ...................................................................................................................3
Item Source Default for Item Search Page.................................................................................3
Allocation.properties file ...........................................................................................................4
Version of Merchandising System......................................................................................4
Logging...............................................................................................................................4
DEBUG Mode on off Switch..............................................................................................7
Minimum and Maximum Pool Size to Maintain ................................................................8
Calculation Settings ............................................................................................................8
Language to be Loaded.......................................................................................................8
Item Location Warning.......................................................................................................8
Type of Allocation..............................................................................................................9
Set End of Week Day for the System .................................................................................9
Number of Days before Release Date.................................................................................9
Bulk Warehouse Setting .....................................................................................................9
Minutes Until a System Locks from Inactivity...................................................................9
Bayesian Sensitivity Factor ..............................................................................................10
Flexible Column Definition ..............................................................................................10
Automatic Group Updates ................................................................................................11
LOV Configuration...........................................................................................................11
Respect the ordhead.include_on_order_ind......................................................................11
Enable Estimated Freight Cost .........................................................................................11
Display Future Unit Retail Price Values...........................................................................11
Default Promotions Associated ........................................................................................11
Crossing Legal Entities.....................................................................................................12
Supply Chain Path Setting (distribution_level) ................................................................12
Include Lead Time ............................................................................................................13
Presentation Minimums ....................................................................................................14
Default Store Calculation /PO Multiple............................................................................14
Location Exception Reason-product Sourced...................................................................14
Location Exception Reason what if ............................................................................14
Import Warehouses...........................................................................................................14
Default what if Import Warehouse.................................................................................14
What if Summary Default Action ..................................................................................15
What if Future Fulfillment Enabled ...............................................................................15
Enable Connection Pool Monitor......................................................................................15
Enable Size Profile ...........................................................................................................15
List of Values (LOV) Layout............................................................................................15
RSL IBM Settings.............................................................................................................16
ALC_SHIPPING_SCHEDULE Shipping Path Levels.....................................................16
Enable Sister Store Data if Need is zero ...........................................................................16

Operations Guide iii

JNDI Configuration File Related to RSL.................................................................................17


Internationalization ..................................................................................................................17
Multibyte Coding..............................................................................................................17
Interface Text that is Separated from Executable Code....................................................17
Translation ........................................................................................................................17
Single Executable .............................................................................................................18
Date Format Preferences...................................................................................................18
Properties Files .................................................................................................................18

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

4 Functional Design ............................................................................. 25


Functional Features and Assumptions .....................................................................................25
Overview What Does Oracle Retail Allocation Do? .....................................................25
Item Sources .....................................................................................................................26
How Need is Determined..................................................................................................26
What if Allocations ........................................................................................................28
Multi-level Distribution (MLD)........................................................................................29
Rush Flag and Freight Cost ..............................................................................................31
Allocation Approval Process ............................................................................................31
Functional Assumptions ...................................................................................................32
Allocation Status...............................................................................................................35
Allocation Process Status..................................................................................................36
Sources of Data Used by Rules to Determine Gross Need ......................................................39
Quantity Limits.................................................................................................................42
Stop Ship...........................................................................................................................43
Net Need at Store Level Calculation ................................................................................43
Closing Allocations..................................................................................................................44

5 Functional and Technical Integration .............................................. 45


Overview..................................................................................................................................45
Integration Interface Allocation-Related Dataflow..................................................................45
From Forecasting System to Oracle Retail Allocation via Merchandising System ..........47
From Planning Application to Oracle Retail Allocation...................................................47
From RPM to Oracle Retail Allocation ............................................................................47
From Warehouse Management System (such as RWMS) to Retail Allocation via
Merchandising System......................................................................................................47
From External Supply Chain Management System to Oracle Retail Allocation ..............48
From Merchandising System to Oracle Retail Allocation ................................................48
From Oracle Retail Allocation to Merchandising System ................................................48
From Merchandising System to Warehouse Management System (such as RWMS) ......49
From Active Retail Intelligence to Oracle Retail Allocation............................................49

iv

RSL and Persistence Layer Integration....................................................................................50


Oracle Retail Allocation and RSL for RMS and RPM .....................................................50
Persistence Layer Integration (Including Tables and Triggers) ........................................51
RMS Functional Dependencies and Assumptions ...................................................................56
RMS Differentiator Setup.................................................................................................56
Staple Item........................................................................................................................58
Pack Item ..........................................................................................................................58
Summary of Items and How Oracle Retail Allocation Handles Them .............................58
Oracle Retail Allocation Functional Assumptions Related to RMS .................................59

6 Allocation Calculations ..................................................................... 61


Calculation Queue Processing .................................................................................................61
Calculation Queue Process Description............................................................................62
Queue Scripts....................................................................................................................63
Plan Re-project Algorithm................................................................................................64
Guidelines.........................................................................................................................65
Satisfying Need Across Multiple Locations ............................................................................66
Rounding Conditions ...............................................................................................................67
Store Calculation Multiple.......................................................................................................67
Allocation of Packs ..................................................................................................................67
Algorithm with Packs and Singles....................................................................................69
Cascade Allocations.................................................................................................................70
Staple Cascade and Fashion Cascade.......................................................................................74
Staple Cascade ..................................................................................................................74
Fashion Cascade ...............................................................................................................75
MLD Calculation Flows ..........................................................................................................76
Staple MLD Calculation ...................................................................................................76
Fashion and Cascade MLD...............................................................................................79
Prepack Algorithm...................................................................................................................80
What if Future Fulfillment .......................................................................................................82
Overview ..........................................................................................................................82
Example Scenarios............................................................................................................82
Example 1 Item Source Location Selected - T2 Regional .............................................83
Example 2 Item Source Location Selected - T1 Deconsolidation Center ......................84
Example 3 Item Source Location Selected - T1 Deconsolidation Center ......................87

7 Java Batch Process........................................................................... 91


Characteristics of Java Batch Process ......................................................................................91
Java Batch Name and Java Package ........................................................................................91
Functional Description.............................................................................................................91
Running a Java-based Batch Process .......................................................................................92
Scheduler and Command Line..........................................................................................92
Summary of Executable Files ...........................................................................................92

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

Who This Guide Is Written For


Anyone who has an interest in better understanding the inner workings of the Oracle
Retail allocation system can find valuable information in this guide. There are three
audiences in general for whom this guide is written:
Business analysts:
Those who are looking for information about the processes that enables the
interface between Oracle Retail Allocation and a merchandising system such as
RMS.
Those who are interested in how allocation data is calculated within Oracle Retail
Allocation.
System analysts and database administrators:
Those who are looking for information about Oracle Retail Allocation processes
singly or in relation to the merchandising system.
Those who need to operate Oracle Retail Allocation on a regular basis.
Integrators and implementation staff: Those who have the overall responsibility for
implementing Oracle Retail Allocation.

What Is Not In This Guide


This guide does not show you how to use the front-end of Oracle Retail Allocation.
Rather, the focus here is on how data is managed, how it flows, and how it is processed.
This guide does not explain, except at a high level, the allocation-related data flow and
processing that occurs among other applications across an enterprise (for example, the
predictive planning system, the merchandising system, the price management system, the
distribution management system, and so on). If you wish to find further information
about how other Oracle Retail products handle allocation-related data, a list of applicable
Oracle Retail documents is provided later in this chapter.

Where You Can Find More Information

Oracle Retail Allocation User Guide


Oracle Retail Allocation Online Help
Oracle Retail Allocation Installation Guide
Oracle Retail Merchandising System (RMS) product documentation
Oracle Retail Warehouse Management System (RWMS) product documentation
Oracle Retail Price Management (RPM) product documentation
Oracle Retail Service Layer (RSL) documentation

Operations Guide vii

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

Third-Party Open-Source Applications


Oracle Retail Security Manager includes the following third-party open-source
applications:
Software Provider: Intalio Inc., and others
Software Name: Castor
Software Version: 0.9.5.2
Jar File Name: castor-0.9.5.2.jar
Provider Web Site: http://www.castor.org/
Software Provider: Apache Software Foundation
Software Name: cglib
Software Version: 2.0.2
Jar File Name: cglib-2.0.2.jar
Provider Web Site: http://cglib.sourceforge.net/
Software Provider: Apache Software Foundation
Software Name: Ant
Software Version:
Jar File Name: ant.jar
Provider Web Site: http://ant.apache.org/
Software Provider: Apache Software Foundation
Software Name: org.apache.commons.beanutils
Software Version:
Jar File Name: commons-beanutils.jar
Provider Web Site: http://jakarta.apache.org/commons/
Software Provider: Apache Software Foundation
Software Name: org.apache.commons.collections
Software Version:
Jar File Name: commons-collections.jar
Provider Web Site: http://jakarta.apache.org/commons/
Software Provider: Apache Software Foundation
Software Name: Commons Database Connection Pooling
Software Version: 1.1
Jar File Name: commons-dbcp-1.1.jar
Provider Web Site: http://jakarta.apache.org/commons/
Software Provider: Apache Software Foundation
Software Name: Jakarta Commons Lang
Software Version:
Jar File Name: commons-lang.jar
Provider Web Site: http://jakarta.apache.org/commons/

Operations Guide ix

Software Provider: Apache Software Foundation


Software Name: org.apache.commons.logging
Software Version:
Jar File Name: commons-logging.jar
Provider Web Site: http://jakarta.apache.org/commons/
Software Provider: Apache Software Foundation
Software Name: org.ORO
Software Version: 2.0.8
Jar File Name: Jakarta-oro-2.0.8.jar
Provider Web Site: http://jakarta.apache.org/oro/index.html
Software Provider: Apache Software Foundation
Software Name: Commons Object Pooling Library
Software Version: 1.1
Jar File Name: commons-pool-1.1.jar
Provider Web Site: http://jakarta.apache.org/commons/
Software Provider: IBM
Software Name: com.ibm.jvm.classloader
Software Version:
Jar File Name: ibmext.jar
Provider Web Site: www.ibm.com
Software Provider: JDOM.org
Software Name: JDOM
Software Version:
Jar File Name: jdom.jar
Provider Web Site: http://www.jdom.org/
Software Provider: Apache Software Foundation
Software Name: org/apache/log4j/
Software Version:
Jar File Name: log4j.jar
Provider Web Site: http://logging.apache.org/log4j/docs/
Software Provider: Apache Software Foundation
Software Name: Apache Xerces
Software Version: n/a
Jar File Name: xerces.jar
Provider Web Site: http://xerces.apache.org/
Software Provider: Apache Software Foundation
Software Name: Struts
Software Version:
Jar File Name: struts.jar
Provider Web Site: http://struts.apache.org/

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

N-tier Technical Architecture Overview


The following diagram provides a high-level overview of the general structure of the
system, including the various layers of Java code.
The graphical user interface (GUI) is comprised of lightweight Java server pages (JSPs),
enabling the GUI to adhere to todays thin-client standard. JSP tag libraries are used for
utility purposes.
The business object tier consists of business objects, which contain all the business logic.
The data access layer tier communicates with the database using a Java Database
Connectivity (JDBC) protocol.
For more information concerning this diagram and Oracle Retail Allocations technical
architecture, see Chapter 3 Technical Architecture.

JSPs
Javascript
HTML
JSP tag libraries

Service
Layer

GUI/Client tier

Business
objects

Business object
tier
Middle tier

Denotes separation of tier

Oracle Retail Allocations n-tier Architecture

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.

Supported Oracle Retail Products


This version of Oracle Retail Allocation is compatible with the following:
Oracle Retail Merchandising System (RMS) 12.0
Oracle Retail Service Layer (RSL) 12.0
Oracle Retail Price Management (RPM) 12.0

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.

Item Source Default for Item Search Page


The Item Source Default setting determines the default search type used on the Item
Search page. This parameter is specified in the Allocation.properties file. The valid
values are:
A Advanced Shipping Notification (ASN)
B Bill of Lading (BOL)
P Purchase Order
T Transfer
W Warehouse
For example:
item_source_default = W

Note: The system only allows for one default to be set.

Operations Guide 3

Backend System Administration and Configuration

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.

Version of Merchandising System


This defines the connection driver that the application uses to connect to the database.
This only changes if you are using a non-Oracle database.
For example:
driver=oracle.jdbc.driver.OracleDriver

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

Oracle Retail Allocation 12.0

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

Email Logging Enabled


This setting defines if the retailer would like to be emailed upon the logging of a
message. The valid values are true and false. By default this setting is set to false due
to high volume of emails that could be received.
For example:
loggerEmailEnabled=false

Default Log Email Address Recipient


This setting defines the default email address of the account that will receive emails of a
log when email logging is enabled.
Note: If the loggerEmailEnabled setting is false, this should

be set to null.
For example:
defaultEmailAddress=someone@oracle.com

Default Log Email Address Sender


This setting defines the default email address of the account that will send the emails of a
log when email logging is enabled.
Note: If the loggerEmailEnabled setting is false, this should

be set to null.
For example:
loggerEmailFromAddress=someone@oracle.com

Log Email Subject


This setting defines the log e-mails subject.
Note: If the loggerEmailEnabled setting is false, this should

be set to null.
For example:
loggerEmailSubject=Allocation Alert Message

Operations Guide 5

Backend System Administration and Configuration

Email Logger Level


This setting determines the log level that emails should be sent out for. This setting is
secondary to the loggerLevel setting. This setting uses the same log hierarchy as defined
in loggerLevel.
For example:
loggerEmailLevel=ERROR

Unix Syslog Enabled


This setting informs the logger if the Unix syslogging is enabled. The valid values are
true and false. This setting is false, if not running on a Unix environment.
For example:
loggerSyslogEnabled=false

Unix Syslog Host IP Address


This setting informs the logger of the Unix syslog hosts IP address.
Note: If the loggerSyslogEnabled setting is false, this should

be set to null.
For example:
loggerSyslogHost=10.10.10.10

Unix Syslog Logger Level


This setting determines the log level that should be recorded by the Unix syslog. This
setting is secondary to the loggerLevel setting. This setting uses the same log hierarchy as
defined in loggerLevel.
For example:
loggerSyslogLevel=ERROR

Log Level Size


This setting defines the maximum size in bytes that the log file can reach before it is
rolled over.
For example:
loggerMaxFileSize=100000000000000

Number of Rolled Over Log Files


This setting defines the maximum number of log files that the system should keep.
For example:
loggerMaxBackupIndex=100

Log In Asynchronous Mode


This setting defines if the logger should write to the log file in its own thread. The valid
values are true and false.
For example:
loggerAsynchMode=true

Oracle Retail Allocation 12.0

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

Redirect System.out and System.err


This settings defines whether the logger should redirect all System.out.* and
System.err.* statements to the log file. The valid values are true and false.
Note: This setting affects the entire Java Virtual Machine.

For example:
loggerCloseStdOutAndErr=false

DEBUG Mode on off Switch


Debugging parameters may be set to write dat files to a file and show the application the
parameters sent to the algorithm. In a production environment, this setting should be set
to false.
For example:
# DEBUG mode on/off switch for application logging. This prints out the dat file
IS_DEBUG_MODE=false
# DEBUG mode on/off switch for application logging. This prints to the console a
commented
#version of the alloc2Param that is sent
#to the algorithm.
debugCalcParms=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

Backend System Administration and Configuration

Minimum and Maximum Pool Size to Maintain


The pool size pertains to the number of available database connections that you intend to
keep available in the pool. A system administrator is encouraged to adjust these values
per configuration to match the retailers anticipated number of users. The default values
are intended to be a starting point. For more information, see the passage, Pooling, in
Chapter 3 Technical Architecture.
For example:
# Minimum and maximum pool size to maintain
pool.min=5
pool.max=10
pool.sqltrace=FALSE
pool.implicitCache=TRUE

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

Item Location Warning


Item location warning may be set to tell the application to check for possible invalid
item/location combinations where the status of the location is closed, inactive or deleted.
If it is closed, inactive or deleted, Oracle Retail Allocation displays a warning message
telling the user that some of the item/location combinations are invalid. You can then
view the invalid combinations and rectify the situation accordingly.
For example:
#itemLocWarn
item_loc_warn=true

Oracle Retail Allocation 12.0

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

Set End of Week Day for the System


The system administrator establishes this value to inform the system what that end of the
weekday is. Sunday is equal to 1, and Saturday is equal to 7. Note that this day must be
identical to that set up in the merchandising system (such as RMS).
For example:
end_of_week_day=1

Number of Days before Release Date


During a purchase order creation from a what if allocation, the system uses a default
number of days before the release date on the allocation as the not before date on the
purchase order. Oracle Retail Allocation does not know the start ship date. Thus, this
value has been added behind the scenes. The start ship date is derived from x days before
the release date set in Oracle Retail Allocation. This number is pre-set to 3 days before
the release date and can be changed by the system administrator.
For example:
days_before_release_date=3

Bulk Warehouse Setting


When a user creates a bulk purchase order (PO) during a what if scenario, the PO is cut
to this designated warehouse. The retailer should make sure that this bulk warehouse is
associated with a valid warehouse in the merchandising system (such as RMS). The
default value is intended to be a starting point.
For example:
# bulk_wh indicator
bulk_wh=1

Minutes Until a System Locks from Inactivity


This security feature is to prevent a user from walking away from the application and
leaving an allocation in progress. After this value (in minutes) of inactivity, Oracle Retail
Allocation returns the user to the home page and unlocks the specific allocation that he or
she was working on. The system is then available for the use of anyone with security
access. This value is set at 30 minutes and should by in sync with the session timeout
based on the server.
For example:
unLock.minutes=30

Operations Guide 9

Backend System Administration and Configuration

Bayesian Sensitivity Factor


Oracle Retail Allocation utilizes Bayesian forecasting in its Plan Re-project Rule. The
sensitivity factor is described below and is pre-set at .3. A system administrator can
change the setting anywhere from zero and one.
For example:
plan_sensitivity=.3

A higher sensitivity setting makes the forecast more reactive to actual sales, and a lower
setting makes the forecast less reactive to sales.

Description of Bayesian Sensitivity


Oracle Retail Allocations Plan Re-project Rule utilizes a Bayesian method to re-project
the future dates of the plan. The rule takes sales history and compares it with the plan to
create a forecast. This forecasting algorithm thus merges a retailers sales plans with any
available historical sales in a Bayesian fashion (that is, the algorithm uses new
information to update or revise an existing set of probabilities). A retailer would use this
rule mid-season to allocate products based on actual sales results to date and planned
sales.
Bayesian forecasting assumes that the shape sales will take is known, but the scale is
uncertain. In Bayesian forecasting, when no sales history is available, the sales forecast
figures are equal to the sales plan figures because there is no reason to mistrust the sales
plan. As point-of-sale data becomes available, the forecast is adjusted and the scale
becomes a weighted average between the initial plan's scale and the scale reflected by
known sales history. Confidence in the sales plan is controlled by the amount of sales
data on hand and a Bayesian sensitivity constant (which, as mentioned earlier, the system
administrator can set from zero to one). Unlike standard time series forecasting, which
requires only sales history to produce a forecast, Bayesian forecasting requires a sales
plan and sales history (if available). As sales information arrives during the first few
weeks of the season, the model generates a forecast by merging the information contained
in the sales plan with the information contained in the initial sales data. These forecast
updates can be critical to a companys success.
For more information, see the section Plan re-project algorithm in Chapter 6
Allocation calculations.

Flexible Column Definition


The system administrator initially establishes the default order and settings of the
applications columns. When a user customizes his or her windows, the result is saved
and will continue to appear in that configuration until changed again. The default user ID
(for flexible columns) is 1, which means that the user sees the column arrangement that
Oracle Retail has designed.
For example:
default_user=1

10

Oracle Retail Allocation 12.0

Automatic Group Updates


The automatic group updates setting allows control over whether or not the system
automatically updates location groups every time the user enters a worksheet allocation.
Note that if a front end user selects the never update check box, automatic updates do
not occur even if the system administrator has set the automatic value update in the
properties file.For example:
auto_update_groups=true

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

Respect the ordhead.include_on_order_ind


Oracle Retail Allocation allows you the ability to respect or ignore the order setting in
RMS purchase orders when calculating the stock on hand for an allocation. This is an
option because some allocators require visibility to all goods on order to effectively
manage their warehouse and store inventories, regardless of the ordering status.
For example:
#when calculating stock on hand
#false will not recognize order quantities on orders
#where ORDHEAD.INCLUDE_ON_ORDER_IND='N'
all_orders=true

Enable Estimated Freight Cost


This value determines whether or not the system uses the estimated future cost
calculation based on the in store date, release date, and transportation time in conjunction
with the ALC_FREIGHT_COST table.
For example:
enable_freight_cost=true

Display Future Unit Retail Price Values


This properties file setting is only applicable if the retailer is utilizing the Oracle Retail
Price Management (RPM) application. If the retailer does not have RPM, this value needs
to be set to false. The system allows the retailer to choose whether it wants the future
retail price displayed on the details screen. If a retailer uses future retail pricing to
determine the future value of an allocation, this parameter should be set to true.
If a retailer creates or approves allocations without factoring in future retail pricing, the
retailer should set this parameter to false.
For example:
enable_future_retail=false

Default Promotions Associated


This properties file setting is only applicable if the retailer is utilizing the RPM
application. If the retailer does not have RPM, this value needs to be set to false.

Operations Guide 11

Backend System Administration and Configuration

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

Crossing Legal Entities


Using this parameter, the retailer has the option to disallow allocations that cross legal
entities. Legal entities are the locations in an organization grouped together due to legal
requirements. Legal entities can be defined by brand, geography, country or some other
grouping defined by the retailer. Issues in crossing legal entities can arise related to
changes in cost and retail pricing, ownership, bookkeeping, and so on.
If you select Y, allocations cannot cross legal entities. Oracle Retail Allocation validates
whether a warehouse/location combination is valid before processing. If a
warehouse/location combination is not part of the same legal entity, the combination is
skipped for processing. The system moves to the next combination.
Note: When a retailer selects Y, the system allows the user

to select invalid combinations. The system does not process


these when calculating need.
If you select N, allocations can cross legal entities.
Parameter:
# Indicates whether or not the user can cross legal entities
# 'Y' indicates Allocations can not cross legal entities
# 'N' indicates Allocation can cross legal entities
enforce_MLE=N

Supply Chain Path Setting (distribution_level)


Note: The Oracle Retail enterprise does not support the
population of the ALC_SHIPPING_SCHEDULE. This
effort must be a part of the retailers implementation of the
application.

12

Oracle Retail Allocation 12.0

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.

Include Mid Tier on Hand Default


This value determines whether or not to include mid tier stock on hand checkbox on the
Select Rules Screen is checked or unchecked. Valid values are true and false.
For example:
multi_level_distribution=true
include_mid_tier_soh=true

Allow Flexible Import Warehouse Paths


This value determines whether or not flexible warehouse paths settings are enabled.
For example:
allow_flexible_import_warehouse_paths=true

Enable MLD Tier Deletion


This properties file determines whether or not you have the ability to delete an entire tier
of allocations from within the MLD Tier Screen. Values are True or False. False equates
to the delete checkbox columns not appearing in the MLD Tier Screen. True equates to
the presence of the tier deletion.
For example:
enable_mld_tier_deletion=true

Break Pack Enforced


This property file setting determines if break pack functionality is enabled or disabled.
For example:
break_pack_enforced=Y

Include Lead Time


This properties file setting determines the Include lead time check box default setting on
the Select Rules page in Oracle Retail Allocation. Valid values are Y or N.
For example:
include_leadtime_need=N

Operations Guide 13

Backend System Administration and Configuration

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

Default Store Calculation /PO Multiple


This properties file setting gives the retailer the ability to determine the default value for
the store or PO calculation multiple. Valid values are pallet, case, inner, and each.
For example:
store_calc_multiple=IN

Location Exception Reason-product Sourced


This allows the retailer to define the status of item location relationships that you would
like to exclude from the product sourced allocation. In the Oracle Retail Merchandising
System the possible item location statuses include Active, Inactive, Discontinued,
Deleted or NULL.
For example:
location_exception_reasons_product_sourced=C D I NULL

Location Exception Reason what if


This allows the retailer to define the status of item location relationships that you would
like to exclude from what if allocations. In the Oracle Retail Merchandising System, the
possible item location statuses include Active, Inactive, Discontinued, Deleted or NULL.
For example:
location_exception_reasons_what_if= C D I NULL

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

Default what if Import Warehouse


This setting determines the warehouse to use as the import based purchase order to
location. Valid values are any warehouse numbers within RMS. The warehouse entered
should be designated as the primary import warehouse. This value is only valid if the
Allow flexible import warehouse paths value is Y.
For example:
default_what_if_import_warehouse=1111111112

14

Oracle Retail Allocation 12.0

What if Summary Default Action


This setting enables the retailer to determine whether the What If Summary screen should
default to Create PO or Update PO view. The values entered are numerical, 1 for
create, and 2 for update.
For example:
what_if_summary_default_action=1

What if Future Fulfillment Enabled


This properties setting is used during the what if calculation process and the What if
summary purchase order (PO) creation process. The setting determines whether or not the
system should use future expected inventory or current stock on hand (SOH) at the
warehouses during the calculation of quantities for PO creation and PO update. Valid
values are the following:

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.

Enable Connection Pool Monitor


This will only be utilized by Oracle Retail. All customers should have this value set to
false.
For example:
enable_conn_pool_monitor=false

Enable Size Profile


This setting enables you to specify whether or not you want size profile validation to
occur when selecting the calculate button. If this value is set to false, the validation
occurs as part of the off line calculation process.
For example:
enable_size_profile_validation=true

List of Values (LOV) Layout


This setting enables the retailer to specify whether you want the default LOV display to
be IDs or descriptions.
For example:
lov_layout_first_value=id\

Operations Guide 15

Backend System Administration and Configuration

RSL IBM Settings


Indicates whether Oracle Retail Service Layer (RSL) for Oracle Retail Merchandise
System (RMS) is running on an IBM application server. The valid values are true and
false.
For example:
rsl_rms_ibm_server=true

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

ALC_SHIPPING_SCHEDULE Shipping Path Levels


Note: The parameter below is only valid for those retailers

who have selected the value 2 in the property parameter,


Supply chain path setting (distribution_level), described
earlier.
For example:
alc_shipping_schedule_path_levels=D,I

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

Enable Sister Store Data if Need is zero


This configurable setting allows the retailer to determine whether they want to use the
sister store need whenever the need is calculated as zero or only when no need records
exist for each location. The property in allocation.properties file is: sister_store_null. The
valid values are true and false.
For example
sister_store_null = true

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

Oracle Retail Allocation 12.0

JNDI Configuration File Related to RSL


The JNDI settings are contained in the file jndi_providers.xml. Oracle Retail Allocation
uses this file as part of its RSL-based integration with RMS. The JNDI providers file
contains the RSL server information for the Oracle Retail application that Oracle Retail
Allocation calls. When the retailer deploys Oracle Retail Allocation, this file must be
configured to point to the application server where RSL for RMS resides, which provides
PO creation service, and RSL for RPM which provides future retail pricing information.
For the steps to configure this file, see the Oracle Retail Allocation Installation Guide.
See also the latest RSL documentation.

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.

Interface Text that is Separated from Executable Code


An application that can run in various languages must be transformed into somewhat of a
generic product. That is, the features of the application that could be specific to just one
language or locale (such as text, date formatting and so on) must not be hard-coded into
the software. Instead, locale-specific information is intentionally placed in files external
to the application.
Much of what is locale specific in Oracle Retail Allocation has been pulled out of the
code and placed into files. The content of these files is interface related, as distinct from
executable code. The text in multiple allocation.properties files is translated so that the
interface functions in local settings. These files comprise the interface layer. The
allocation_gui.properties file contains the text within the GUI strings (for example,
button names, menu names, title bars, and so on) that is translated.

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

Backend System Administration and Configuration

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.

Date Format Preferences


To provide a user-friendly date format that is understood by the users, a number of date
formats are available.
The date tag will handle the display and selection of dates from the calendar widget. The
date tag will pass in the appropriate date format from the user in the session. (Note that
date formats will now be defined on each language text properties file, allowing for the
appropriate date format based on that particular language. The default date format will
still reside on the allocation.properties file, and should be accessed via the
AllocTextPropertiesFactory.)

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

Oracle Retail Allocations n-tier Architecture

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.

Java Server Pages (JSP) and HTML


The GUI is comprised in part of lightweight JSPs. JSP technology is a critical piece of
Suns J2EE-initative.
JSPs are compiled into servlets. JSPs also provide access to middle tier objects.
JSPs consist of JavaScript and standard HTML. They make calls to tag-libraries and
contain minimal Java code. This code is located within standard HTML formatting tags.
An extension of Java servlet technology, JSPs allow for the separation of the GUIs page
layout from the applications content. The look and feel of the GUI is easy to customize,
and dynamic functionality is easy to create.
As noted earlier, because the JSP/HTML GUI is lightweight and uses standard hyper
test transfer protocol (HTTP), the application can be deployed both, inside the firewall or
outside the firewall.

Screen Controller Servlet


The screen controller servlet controls mappings (request/response) and the navigational
control throughout the Oracle Retail Allocation application.

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)

JSP Tag Libraries


JSP tag libraries are called for utility purposes. The use of tag libraries enables
reusability. In other words, utility code does not have to be duplicated across all JSPs. For
example, a paging tag allows pagination on any JSP page that refers to the paging tag. In
addition, any changes that may be required can be made in one place.

20

Oracle Retail Allocation 12.0

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.

Business Object Tier


Business objects implement business rules. A common business object infrastructure
allows for the components to be utilized again and again within an enterprise. The
business objects within Oracle Retail Allocation are represented as business objects,
which are, in essence, reusable Java classes.
In terms of Oracle Retail Allocation, business objects represent the logic of functional
entities. Because the logic is wrapped into a component of software, it may be
instantiated repeatedly. For example, in Oracle Retail Allocation, item is represented as
business object. Thus, as business object, any type of item in the merchandising system
becomes a reusable component.
Note that there is not necessarily a one-one relationship between a business object and a
database table.
Business rule validations are handled by server-based middle-tier business objects.

Data Access Tier


This portion of the middle tier allows for business logic to be separated (physically and in
the software) from the applications presentation and database functions. Thus, the data
access tier keeps the business logic and GUI isolated from any database issues.

JDBC Protocol and Drivers


The middle-tier talks with the database via the industry standard Java database
connectivity (JDBC) protocol. JDBC facilitates the communication between a Java
application and a relational database. In essence, JDBC is a set of application
programming interfaces (API) that offer a database-independent means of extracting
and/or inserting data to or from Oracle Retail Allocation.
To perform those insertions and extractions, SQL code also resides in this tier facilitating
create, read, update, and delete (CRUD) actions.

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

Data Storage Tier


The database tier is the applications storage platform, containing the physical data (user
and system) used throughout the application. This tier is only intended to deal with the
storage and retrieval of information and is not involved in the manipulation or in the
delivery of the data. This tier responds to queries; it does not initiate them.

Accessing Merchandising System Data in Real Time


The data that Oracle Retail Allocation utilizes is located in both allocation-specific tables
and merchandising system (RMS, for example) tables. Because Oracle Retail Allocation
shares the same schema as the merchandising system (RMS, for example), Oracle Retail
Allocation is able to interact with the merchandising systems data directly, in real time.

Summation of n-tier Architectures Advantages


The following list is a summary of the advantages that accompany the n-tier architecture.
N-tier architecture has become an industry standard.
The separation of presentation, business logic, and data makes the software cleaner,
more maintainable, and easier to modify.
The hardware and software for each of the tiers can be easily scaled.
The look and feel of the application can be updated more easily because the GUI is
not tightly coupled to the back end.
Market-proven and industry-standard technology is utilized (for example, JSPs,
JDBC, and so on).
Component-oriented modeling promotes the reuse of code, saving development time.

Component Descriptions and Standards


Java Development Kit (JDK)
Standard Java development toolkit from Sun Microsystems.
Java Server Pages (JSP)
JSPs contain embedded Java and JavaScript within an HTML page. To the user, these
pages appear in the Web browser as files with a .jsp extension. JSPs are part of Suns
J2EE specification. They compile into servlets and allow for the separation of the user
interface from business logic.
Java Servlet
Java Servlets are used for server side Java development; the Java Servlet is part of Suns
J2EE specification.
JDBC
JDBC is a means for Java-architected applications such as Oracle Retail Allocation to
execute SQL statements against an SQL-compliant database, such as Oracle. As part of
Suns J2EE specification, most database vendors implement this specification.

22

Oracle Retail Allocation 12.0

Naming conventions in Java


Packages: The prefix of a unique package name is written in all lowercase letters.
Classes: These descriptive names are unabbreviated nouns that have both lower and
upper case letters. The first letter of each internal word is capitalized.
Interfaces: These descriptive names are unabbreviated nouns that have both lower
and upper case letters. The first letter of each internal word is capitalized.
Methods: Methods begin with a lowercased verb. The first letter of each internal
word is capitalized.

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.

Functional Features and Assumptions


Overview What Does Oracle Retail Allocation Do?
A good allocation application enables retailers to make important decisions as close as
possible to the time the product must be sent to the stores. A critical link in the supply
chain process, the allocation process presents the final chance to distribute products
successfully. The challenges facing retailers for allocating product is the same, whether
they sell fashion items, groceries or hard lines. Merchants want an efficient, accurate
method of translating their merchandise plans into store level allocations. Effectively
allocating products is a critical step in product life cycle management and the last chance
the retailer has to get the right product to the right location.
Oracle Retail Allocation enables retailers to take advantage of the most current, up-todate sales and inventory information. The application also has the flexibility to allow
allocations to be calculated months in advance for vendor commitment purposes.
Oracle Retail Allocation was designed to address the following challenges (among
others) related to the correct allocation of product:
How to put many a variety of merchandise plans into action.
How to allocate product to support diverse marketing efforts and selling profiles.
How to effectively and accurately allocate product without increasing head count
while continuing to grow the business.
How to streamline the training process for allocators, due to the positions high level
of turnover.
If these challenges are not met, the wrong product can be sent to the wrong store in the
incorrect quantity at the wrong time. The net result is higher markdowns and lower
profits.
Oracle Retail Allocation allows multiple parameters to be selected when creating an
allocation. The system determines store need based on metrics that fit the product, store
characteristics and product life cycle. The result is allocations based on individual store
need, the key to maximizing sales and profits.
In Oracle Retail Allocation, the retailer has the option of executing a plan, history or
forecast at any level of the hierarchy. The retailer can allocate a collection of products
using a class plan or allocate one item using its history. Oracle Retail Allocation has the
functionality to create and reuse templates to save time and produce consistent results.

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.

How Need is Determined


The logic of Oracle Retail Allocation is based on establishing need at the item/location
level. The user determines need by choosing a rule, rule modifiers and setting optional
quantity limits. The system accesses gross need values provided. The application applies
constraints to the data, such as on-hands and on-order, and determines the net need. At
this point, the algorithm determines how to spread the available inventory across all of
the locations net need, and the allocation is created.
When attempting to allocate with a store which has a zero need, the system will use the
sister-store data instead of allocating no product.
A new configurable setting (sister_store_null) has been added to the allocation.properties
file to allow for the retailer to determine whether they want to use the sister store need
whenever the need is calculated as zero or only when no need records exist for each
location.

26

Oracle Retail Allocation 12.0

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.

Lead Time Need


Net need is based upon the rule selected by the retailer less the stores future on hand.
Gross need is based upon the rule selected by the retailer without any store stock on hand
consideration. The addition of multi-level distribution allocations functionality, which
extends the item lead time from its initial location to its destination location, leaves a
calculation adjustment for the expected sales during the shipping time. This adjustment
capability, lead time need, is an option for the user. The addition of sales that occur
during the shipping lead time for an item prevents the possibility of shorting high volume
stores based on the sales that occur between the time the order was received and allocated
and the time the order arrives at the stores.

Weight and Date User Selection


The premise of Oracle Retail Allocation is establishing need at the item/location level via
rules and rule modifiers. There are seven different rule possibilities, and they are as
follows:

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.

Purchase Order Addition


In Oracle Retail Allocation, the user has the ability to allocate many items on a single
allocation. This ability is dependent on what rules are utilized when gathering an item, or
set of items need values. The user has the ability to add quantities to existing POs from
the front end screen dedicated to what if summary data. Valid items to add to the PO
must not previously exist on the PO. If the item already exists on the PO, the allocator
should modify the quantities within the ordering dialogue.
The purchase order addition functionality calls the Oracle Retail Service Layer (RSL)
API. Any defaulting and/or rounding that occur within this API are not modified. The
Oracle Retail Merchandising System owns this code and the standards it enforces
regarding PO creation. The current API validation includes: location exists, item exists,
supplier exists, item/supplier exists, item/supp/country exists, item is orderable and
checks for dept_level_orders.

28

Oracle Retail Allocation 12.0

Multi-level Distribution (MLD)


Note: The Oracle Retail Allocation, RMS, and RWMS

interface is not capable of facilitating warehouse-towarehouse inventory movements.


Multi-level distribution is the ability to create an allocation that flows from one
warehouse to another warehouse that is based on the store need. The aggregated store
allocation may be viewed and edited at its associated warehouse. By enabling this
functionality, the application allows inventory to flow through warehouse tiers until it
arrives at its final store destination.
Many retailers import a portion of their inventory. Importing goods typically involves the
arrival of an inbound purchase order at an import distribution center. Inventory then
travels to a regional warehouse and finally to a store. This inventory flow is referred to as
the MLD path. Importing goods leads to a greater need for warehouse-to-warehouse
allocations. Oracle Retail Allocation allows users to send allocation orders to RMS at two
levels.
Next destination: The first level would be from the first level on the MLD path to the
second level on the MLD path.
Stores: The second level would be from first level on the MLD path through all mid
tier warehouses to the stores.
Users have the ability to edit values for the two approval levels. The approval options are
limited when final quantities are edited by the user.
Note: Oracle Retail Allocation multi-level distribution allocations

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

MLD Purchase Order Creation


The systems purchase order creation abilities include MLD PO creation, the inclusion or
exclusion of supply chain stock on hand, as well as updating of existing purchase orders.

Expected Inventory for MLD what if Allocations


Where an item source location is selected, the system can account for future fulfillment
inventory as part of the MLD PO creation process. This functionality prevents retailers
from ordering quantities that are greater than their required quantities by recognizing
inventory amounts that are inbound to the distribution centers. Expected inventory
amounts that are inbound to stores are accounted for by allocating to net need.

Data Sources for MLD Path


Oracle Retail Allocation includes possible data sources for the multi-level distribution
(MLD) path.
MLD using the TRANSIT_TIMES table
Retailers leverage the TRANSIT_TIMES table data that is maintained within RMS.
This data exists at the department, class, or subclass level.
MLD using the ALC_SHIPPING_SCHEDULE table
Note: The Oracle Retail enterprise does not support the population

of the ALC_SHIPPING_SCHEDULE. This effort must be a part of


the retailers implementation of the application.
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. This data exists at the department, class,
subclass, or item level.
The Oracle Retail Allocation product houses a
ALC_ITEM_SOURCE_SHIP_SCHEDULE table whereby MLD paths are stored for
each item source of an allocation. The paths stored in this table are refreshed at
calculation and approval time. If there is a path discrepancy between the path at
calculation time and the path at approval time, the allocation is set to a status of
Supply Chain Error.
For more information about these data sources, see the section, Supply chain path setting
(distribution_level), in Chapter 2 Backend system administration and configuration.
Also see the Oracle Retail Allocation Data Model and the RMS Data Model.

30

Oracle Retail Allocation 12.0

Rush Flag and Freight Cost


When allocations are created, it is usually under the assumption that they will follow their
standard logistics path because this is the most cost effective way to ship product.
However, there are instances where the established item/Store/WH relationship cannot
fill allocated need.
For item-sourced allocations, the system takes the number of days that occurs between
the release date to the arrival date and compares those days to the in-store date. The
system marks the allocation as a rush allocation whether the items can arrive in time.
Oracle Retail Allocation provides visibility to an estimated cost based upon different
freight date options (in store date - release date day = number of freight days, also known
as lead time). The user has visibility to an estimated cost to meet the in-store-date. This is
calculated based upon the weight of the goods. It allows the user to split the allocation
based on the product source and location. This assists users in making an intelligent
decision about an in-store date requirement based solely on the cost of freight.

Allocation Approval Process


The process of approving an allocation has been moved to an off line, queue based
procedure. The functionality is consistent with the calculation process and allows the user
to work on other allocations while one is being submitted, reserved or approved. In
addition, the validation has been enhanced to ensure that all inventory quantities are up to
date at the time approval occurs, including supply chain on hand and the item source
quantities. This validation prevents the system from creating an allocation order against
quantities that were available at the time of calculation but have since been claimed by
another allocation or system.

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 12.0

ASN-based Allocation Assumptions

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.

Presentation Minimum Assumptions


No user interface exists for the maintenance of the Presentation Minimums repository.

Store Calculation Multiple Assumptions

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.

Lead Time Need Assumptions

Utilizing Oracle Retail Allocation is generally applicable to reactionary situations


and is not intended to replace replenishment or advanced inventory replenishment
functionality.
The shipping days used to determine lead time need are based upon the MLD path. It
accounts for inbound processing days at mid tier warehouses.
Lead time need is not available for corporate or manual allocations. The lead time
need related fields are removed from the Select Rules Screen when the user selects an
allocation Rule of Corporate or Manual from the Rule list box.
The application is capable of accounting for lead time need in what if allocations if
they are utilizing in-store date functionality. If an in store date is not entered into the
system, there is no logical time period to leverage.
The lead time need functionality uses regular and promotional sales as the history
query criteria if the selections on the rules screen have led to the disabling of the
checkboxes.

Weight and Date User Selection Assumptions

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.

Oracle Retail Allocation 12.0

Rush Fag and Freight Cost Assumptions

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.

Proportional Allocation Assumption


The system assumes that a proportional allocation will not contain more than 10,000 units
going to one store. The 10,000-unit value is a hard limit, and if exceeded, an infeasible
solution arises in the systems algorithm. This pertains to MLD allocations and non-MLD
allocations.

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.

Visible through the User Interface


Status

Description

Status #

Worksheet

This allocation is in the initial stages of


creation or it is being updated by the user.

Submitted

This allocation has been submitted


successfully.

Approved

This allocation has been approved


successfully. The allocation records have
been sent to the merchandising system.

Processed

The warehouse system has started executing 3


this allocation. The allocation cannot be
updated.

Closed

The allocation has been executed by the


warehouse. The inventory movement is
complete.

Cancelled

This allocation has been cancelled by an


external system. The allocation cannot be
updated.

Operations Guide 35

Functional Design

Status

Description

Status #

Reserved

This allocation has been reserved


successfully. The allocation records have
been sent to the merchandising system.

PO Created

This status exists for what if allocations


only. A purchase order has been created
within this what if allocation. The user
cannot edit anything within the allocation
except creating or updating additional
purchase orders within the front end screen
that holds what if summary data.

10

Not Visible through the GUI


Status

Description

Status #

Deleted

Allocations have been set to be deleted from 7


the allocation application tables by the user
selecting the Delete button in the within
the front end screen that holds what if
summary data. The next time the allocation
deletion logic is run, the record is removed
from the tables.

Approval In Process

This status is used when the system is


writing an approval request to the queue.

Reservation In
Process

This status is used when the system is


writing a reservation request to the queue.

Allocation Process Status


Significant functionality is attached to the status numbers in the system. The tables below
reflect the process_status column on the ALC_ALLOC table.

36

Status

Description

Status #

Not Calculated

This allocation has not been calculated.

Calculation Waiting

The allocation is waiting to be processed 2


by the algorithm. The user cannot enter an
allocation with this status.

Calculating

The system is in the process of calculating 3


this allocation. The user cannot enter an
allocation with this status.

Calculated

This allocation has been calculated


successfully.

Oracle Retail Allocation 12.0

Status

Description

Status #

Calculate Later

This allocation is calculated during a


5
scheduled batch run based on each
retailers timeline requirements. The value
is accessible to users and they may change
the allocation to calculate real time.

Calculation Error

An error was encountered during


calculation.

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

This error occurs if the cascade allocation 8


weeks of supply data are not sufficient for
the algorithm requirements for
calculation.

Quantity Limits
Conflict

This error occurs if quantity limits are


defined for a pack and non sellable pack
containing the same item. The system
requires the user to resolve the conflict
manually.

Status Error

The system encountered an error when


submitting, reserving or approving this
allocation.

10

Status Waiting

The system is in the process of submitting, 11


reserving or approving this allocation. The
user cannot enter an allocation with this
status

Status Processing

The system is in the process of submitting, 12


reserving or approving the allocation. The
user cannot enter an allocation with this
status

Status Processed

The allocation has been approved,


reserved or submitted successfully.

13

Available Inventory
Error

This error occurs if the inventory


quantities that the allocation was based
upon has increased or decreased by
another part of the system since the time
of calculation. The user must recalculate
and approve based on the current
inventory.

14

Operations Guide 37

Functional Design

38

Status

Description

Status #

Next Destination Error

This error occurs when the user has edited 15


allocations amounts at the store level and
selected Approved to Next Destination
as the status selection. The error is
received if the quantity of inventory being
sent to the stores is entirely fulfilled by the
mid tier warehouses. This means there is
no quantity to approve to the next
destination level, and the error is received.
Users should select Approved to Stores
as their approval level or adjust the
allocation quantities.

Supply Chain Error

This error occurs if the original path built 16


at calculation time is no longer valid at
approval time. The validity of the path is
determined by whether or not the
locations of the path are still valid, not
whether the dates of the path have
changed. An error occurs if a path to the
warehouses or stores that existed during
the original calculation is no longer found.
The user must recalculate and approve
based on the new path. Locations without
paths are noted as item location
exceptions.

Oracle Retail Allocation 12.0

Sources of Data Used by Rules to Determine Gross Need


To accurately determine individual store gross need, retailers want the flexibility to
choose forecast data, plan data, sales history data, or combinations of this data.
Through the front end, retailers select a rule based on a portion of this data that accurately
gathers gross need. The source of the data used by each rule is illuminated in this section.
To determine the net need at the store level, the system takes the gross need and subtracts
from it the stock-on-hand at the store level. The equation that Oracle Retail Allocation
uses to determine the stock-on-hand at the store is described later in this chapter.
Note: For a description of how the following rules use the

data to determine gross need, see the Oracle Retail


Allocation User Guide.

History Data Sources


For this rule, data is gathered primarily from the following tables:
RMS 12.0

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

Forecast Data Sources


For this rule, data is gathered from the following tables:
RMS 12.0

Legacy System

DEPT_SALES_FORECAST

This table holds the forecast


information summed to the
department-location-eow_date.

CLASS_SALES_FORECAST

This table holds the forecast


information summed to the classlocation-eow_date and should be
partitioned by domain_id, as well.
Thus, if only a portion of the domains
is forecasted, then the rebuild is done
by domain_id.

SUBCLASS_SALES_FORECAST

This table holds the forecast


information summed to the subclasslocation-eow_date and should be
partitioned by domain, as well. Thus,
if only a portion of the domains is
forecasted, then the rebuild is done by
domain_id.

ITEM_FORECAST

This table holds the item level


forecasted information from the RDF
extractions. This table holds all item
types. This table should be partitioned
according to the domain level.

Plan Data Sources


For this rule, data is gathered from the following table:
ALC_PLAN
For a more detailed description of this table, see the section, Planning table in Oracle
Retail Allocation, later in this chapter.

40

Oracle Retail Allocation 12.0

History and Plan Data Sources


For this rule, the plan portion of data is gathered from the following plan table in Oracle
Retail Allocation:
ALC_PLAN
The history portion of data is gathered from the following tables:
RMS 12.0

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

Plan re-project Data Sources


Note: For a description of the Bayesian algorithm that is

used in this section, see Chapter 6 Allocation


calculations.
For this rule, the historical and future plan data is gathered from the following table in
Oracle Retail Allocation:
ALC_PLAN
The history portion of data is gathered from the following tables:
RMS 12.0

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

product-location, the corporate table can be accessed to


create different ideal weeks of supply by store. If the retailer
does not plan IWOS, a field can be created that contains the
same IWOS for every store.

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

Oracle Retail Allocation 12.0

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.

Net Need at Store Level Calculation


On a fundamental level, net need is gross need minus the on-hand at the store.
Note: Although quantity limits also effect net need, they are

not addressed in the calculation illustrated by this passage.


To determine the gross need, Oracle Retail Allocation gathers the information based upon
one of the rules selected by the retailer through the front end. Oracle Retail Allocation
uses the following equation to determine the on-hand at the store that is subtracted from
the gross need result.
Stock-on-hand at the store+
Stock in transit+
Stock on order [stock that is expected by the on order commit date]+
Transfers of stock expected+
Stock on allocation

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

via table triggers when actions occur on RMS allocation


records.

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.

Integration Interface Allocation-Related Dataflow


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.
The diagram below 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.

Operations Guide 45

Functional and Technical Integration

External supply
chain
management
system

Oracle Retail
Price
Management
(RPM)

Merchandising
system
(RMS
Legacy systems)

Oracle Retail Allocation

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)

Oracle Retail Allocation-Related Dataflow Across the Enterprise

46

Active
Retail
Intelligence

Oracle Retail Allocation 12.0

From Forecasting System to Oracle Retail Allocation via


Merchandising System
Note: RMS 12.0 is not integrated with Oracle Retail

planning and forecasting systems (for example, Oracle Retail


Demand Forecasting).
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 from RMS. 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 groups data from RMS. Oracle Retail
Allocation 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.

From Planning Application to Oracle Retail Allocation

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.

From RPM to Oracle Retail Allocation

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 Chapter 2 Backend system administration and configuration.

From Warehouse Management System (such as RWMS) to


Retail Allocation via Merchandising System

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

Functional and Technical Integration

From External Supply Chain Management System to Oracle


Retail Allocation

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 RMSowned TRANSIT_TIMES table. This data exists at the department, class, subclass, or
item level.

From Merchandising System to Oracle Retail Allocation


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)

From Oracle Retail Allocation to Merchandising System


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.

48

Oracle Retail Allocation 12.0

From Merchandising System to Warehouse Management


System (such as RWMS)
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.

From Active Retail Intelligence to Oracle Retail Allocation


Active Retail Intelligence (ARI) is an exception management and resolution system
driven by custom business rules. Depending upon ARIs 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.

Operations Guide 49

Functional and Technical Integration

RSL and Persistence Layer Integration


This section is divided into the following two sections that address Oracle Retail
Allocations methods of integration:
Oracle Retail Service Layer (RSL)-based integration
Persistence layer integration

Oracle Retail Allocation and RSL for RMS and RPM


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 RMS integration purposes, these RSL SSBs invoke a stored procedure in RMS.
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 (jndi_providers.xml) in Chapter 2
Backend system administration and configuration. Also, see the latest RSL
documentation which addresses client application layer configuration.

Client Application and Service Provider Processing Through RSL

50

Oracle Retail Allocation 12.0

Description of Class Using RSL


The table below briefly describes the functional role that Oracle Retail Allocations RSL
classes have within the application.
Class

Functional Description

PurchaseOrderServiceWrapper.java

This call allows the system to create/update a


purchase order in RMS from a what if
allocation through RSL.

PriceServiceWrapper.java

Oracle Retail Allocation is the inquiring system


that requests the effective retail for an item at a
specified location on a given date through RSL
for RPM. RPM provides the future retail price.

Persistence Layer Integration (Including Tables and


Triggers)
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, but Oracle Retail does
not provide this script.
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.

Operations Guide 51

Functional and Technical Integration

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
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.

52

Oracle Retail Allocation 12.0

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

Location list data

LOC_LIST_HEAD
LOC_LIST_DETAIL
LOC_LIST_CRITERIA

Merchandise hierarchy data

DEPS
CLASS

Operations Guide 53

Functional and Technical Integration

RMS Tables
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

54

Oracle Retail Allocation 12.0

RMS Tables
Appointment data

APPT_HEAD
APPT_DETAIL

Multi-level distribution

TRANSIT_TIMES

Oracle Retail Allocation-owned Triggers Residing on RMS Tables


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.

Operations Guide 55

Functional and Technical Integration

RMS Functional Dependencies and Assumptions


RMS Differentiator Setup
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

56

Oracle Retail Allocation 12.0

Retek Item Number


100011006 - 100%
Cotton Sheets

In order to have this result, the item parent


(100011006) needs to have the following
indicators:
Item Aggregate Indicator = 'Y'
Diff 1 Aggregate Indicator - Color = 'N'
Diff 2 Aggregate Indicator - Pattern = 'Y'
Diff 3 Aggregate Indicator - Width = 'Y'

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

Functional and Technical Integration

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.

Summary of Items and How Oracle Retail Allocation


Handles Them

58

Single staple item


These items are individually allocated and can be selected from item LOV search
criteria.
Single fashion item
These types of items cannot be allocated individually. They are allocated as part of
their style/color.
Style/color
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.

Oracle Retail Allocation 12.0

Oracle Retail Allocation Functional Assumptions Related to


RMS

The only way to allocate fashion items is by style/color.


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

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

Merchandising Oracle Retail


Allocation
system
tables

Oracle Retail Allocation Calculation Queue Process

Operations Guide 61

Allocation Calculations

Calculation Queue Process Description


1. A continuously running thread pulls an allocation to be calculated into the calculation
queue.
Note: Steps 2, 3, and 4 are repeated and processed through

each tier in the supply chain if multi-level distribution


(MLD) functionality is enabled. Multi-level distribution is
the term used to describe the automation of inventory flow
through n layers of locations to ultimately arrive at a final
destination. For more information regarding Multi-level
distribution (MLD), see Chapter 4 Functional Design.
2. Need is gathered based upon the applicable rule and the data from the database. For
example, the need gathered could be based upon plan data, sales history data, forecast
data, plan re-project (Bayesian-calculated) data, and so on. These calculations are
internal to the Java in Oracle Retail Allocation. For more information about the data
that the system uses to generate gross need, see Chapter 4 Functional design.
3. On-hand is gathered, as necessary, from the database depending upon whether gross
need or net need is desired. These calculations are internal to the Java in Oracle
Retail Allocation. For more information about the source of on-hand data and how
on-hand is calculated, see Chapter 4 Functional design.
4. The algorithm, an external library written in C++, is called to make a statistical
determination of the best allocation possible given the parameters and constraints of
the problem. Inputs passed to the algorithm function include the following:
Available quantity by item
An exact/proportional flag
Item-store matrices of need, on-hand, minimum, maximum, and threshold
Cascade mode uses additional vectors for cascade-level targets, minimum, maximum,
and threshold. Pack mode uses a matrix representing the pack component quantities.
Depending upon the mode (for example, simple, cascade, or pack) and the constraints
of a given problem, an algorithm is selected to calculate the allocation, including an
objective function representing a relative score for the evaluation of different
options. In every mode, the return values represent the item (pack)-store amount to be
allocated and shipped. In all modes (for example, simple mode, cascade mode, and so
on), optimization is performed through a heuristic algorithm.
5. The results are retrieved and saved to the database.

62

Oracle Retail Allocation 12.0

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 x represents the unique integer specifying the ID of the queue.


The QueueProcess utilizes the parameters passed in at execution time to know which
type(s) of queue it is. The operative command used to start a queue is:
java com.retek.alloc.queue.QueueProcess <name> standard_calculation prepack
recalculation approval_stores approval_next_destination

where <name> represents any name you would like to use to refer to the queue.

Operations Guide 63

Allocation Calculations

Note: Some JDK implementations on UNIX boxes do not

have the classic option. The -classic argument can be


removed from the script/command or substituted with server (if the server option exists on your JDK
implementation).

Batch Queue (queue_batch_mode_111.sh)


To process allocations that have been selected for batch calculation by the user selecting
the Calculate Later option, a systems administrator must schedule the nightly process.
The start, stop and restart commands are the same as noted above. An example command
used to start a batch queue is:
queue_batch_mode_111.sh restart x

Plan Re-project Algorithm


A Bayesian algorithm is one that is based on a mathematical theorem developed in the
eighteenth century by the Reverend Thomas Bayes. This theorem is a basic starting point
for inference problems that use probability theory as logic.
Let:
N be the number of periods in the current season (and N = for staple products),
M be the current period,

p ( j ) be the sales plan for periods j = 1, , N,

x( j ) be the achieved sales for period j = 1, , M, and

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 up to the current period,


j =1

P p ( j ) as the sum of the sales plan over the entire season, and
j =1
M

X x( j ) as the sum of the achieved sales up to the current period.


j =1

Finally, compute the forecasts as

P
X P
x ( j ) p( j ) + p( j )1 for periods j = M+1, , N.
P
P P

64

Oracle Retail Allocation 12.0

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

Satisfying Need Across Multiple Locations


One way to think of the applications methodology is by comparing its process to that of
water filling a container.
The fill line of the container represents 100% of need for all the locations, and the
quantity of water available represents the stock available. By pouring all of the water into
the container, the water level naturally reaches the target stock.
Suppose that the bottom of the container is partitioned, and each partition represents a
different store.
The water would naturally level itself to maintain consistent stock across all stores.
Suppose two of the following three conditions, as depicted in the accompanying chart:
Stock is already available at each store.
The height of each partition in the container represents the amount of that locations
existing stock.
The partitions are sorted from left to right in ascending stock percentages.
100%
80%
60%
40%
20%

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%

Stores Existing Stock and Need Before Allocation

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

Stores Stock After Allocation

66

Store10

Store9

Store1

Oracle Retail Allocation 12.0

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.

Store Calculation Multiple


A store calculation multiple refers to the multiple that the application allocates in during
the calculation process. Valid multiples are pallet, case, inner and each. By determining
the store calculation multiple, Oracle Retail Allocation has the ability to move inventory
with multiples other than the supplier case size. This ability prevents over allocation to
stores that have need levels below the supplier case size.
In a supply chain, not all warehouses have the ability to break cases. Oracle Retail
Allocation accounts for this limitation by enforcing the case multiple at warehouses that
cannot break cases, but breaking the inventory as soon as it encounters a break case
warehouse within the MLD path. This design ensures that warehouses receive valid stock
order quantities. The ability to indicate the multiple for the allocation is available for
product sourced allocations and what if allocations.
Oracle Retail Allocation has the ability for the user to define a separate multiple at PO
creation time in the front end screen relating to what if summary data.

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

Oracle Retail Allocation 12.0

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.

Algorithm with Packs and Singles


The algorithm determines the optimum result based on the overall allocation of every
individual product. Both packs and singles are allocated to stores as needed. Packs,
however, are preferred to singles in order to minimize the total number of units
distributed, thereby lowering handling costs.

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

Total item need vs. allocation

Note: The overstocking of two items, which takes place in

this example, is due to the fact that constraints (for example,


minimum, maximum, threshold, and so on) are not being
used to limit the results. The example is designed to
highlight the effects of the two different modes of
calculating.

70

Oracle Retail Allocation 12.0

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

Total Category-Store Need vs. Allocation

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

Item Available Quantity To Allocate


Style

Solid

Striped

Solid

Striped

Logo

Logo

Color

Yellow

Yellow

White

Blue

White

Blue

Available

80

85

16

20

Total
201

Item On Hand At Stores


Style

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

Category Need And On-Hand At Stores


Need

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

Oracle Retail Allocation 12.0

Simple Mode Allocation Not Cascade


Style

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 and Fashion Cascade


The following diagrams illustrate the systems approach to a staple cascade calculation
and to a fashion cascade calculation.

Staple Cascade
Explanations of Pass 1 and Pass 2 follow the diagram.

NN1 = GN1 SOH1

Pass 1

Pass 2

NN21 = NN11 SOH21

NN22 = NN12 SOH22

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

NN23 = NN13 SOH23

Oracle Retail Allocation 12.0

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

NN1 = GN1 SOH 1

NN12

NN12

NN2 = GN2 SOH2

NN21

NN22

NN23

NN3 = GN3 SOH3

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

MLD Calculation Flows


Staple MLD Calculation
The staple MLD allocation is calculated in three phases. The first phase is the need
gathering phase, the second is the source location phase, and the third is the allocation
phase. Each of the phases is described in this section for the following supply chain:
Tier 1

Tier 2

Tier 3

Store1
WH2
Store2

WH1

WH3

Store4

Example Supply Chain

76

WH4

Store3

Oracle Retail Allocation 12.0

Need Gathering Phase


The need gathering phase is used to determine the need, and quantity limits for each tier
one destination warehouse. For the supply chain illustrated above, the tier one destination
warehouses are WH2 and WH3. The need is gathered starting at the deepest tier in the
supply chain and proceeding up to tier 1. The following calculations are performed in the
need gathering phase:

Calculation 1
NN13
WH4

Store3

SOH13
Avail =

Calculation 2
NN11
Store1

SOH11
WH2

NN12
Avail =

Store2

SOH12

Calculation 3
R1-SOH
WH3

WH4

Avail =

Need Gathering 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.
Rx is the result of Calculation x.

Operations Guide 77

Allocation Calculations

Source Location Phase


The Source location phase is used to determine the amount to be allocated from the tier
one source location. The source location phase always consists of a single calculation
from the tier one source location to each of its destination locations. The following
diagram illustrates the calculation performed in the source location phase:

Calculation 4
R2-SOH
WH2

R3-SOH
WH1

WH3

NN14
Store4

SOH14

Source Location 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.
Rx is the result of Calculation x.

78

Oracle Retail Allocation 12.0

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.

Fashion and Cascade MLD


A fashion MLD allocation is handled in the same manner as a staple MLD allocation.
However, when each calculation is performed, it is first performed at the style level and
is then performed at the item level as described in the fashion cascade section above.
Similarly, a cascade MLD allocation is handled in the same manner as a staple MLD
allocation. However, when each calculation is performed, it is first performed as a level
calculation and then performed as a cascade calculation as described in the staple cascade
section above.

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

Oracle Retail Allocation 12.0

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

What if Future Fulfillment


Overview
Future fulfillment is defined as the quantity of inventory that is to be fulfilled by expected
inventory. The future fulfillment visible in the What If Summary screen is discussed in
the following section. The second area that the Allocations application displays future
fulfillment is within the Allocation Details screen. The Allocation Details column
displays the future fulfillment at the store level only. There is no relation to the supply
chain future inventory that this section outlines.
The What If future fulfillment value is calculated based upon the following logic:
FutureX = FutureSOH SOH
If the calculated value > 0
Future Fulfillment = FutureX
Else
Future Fulfillment = Minimum of (Mid Tier DC Need or FutureX)
Future fulfillment is the amount of inventory that the algorithm results are expecting to be
fulfilled by future expected inventory. In other words, it is the amount per
product/location/source that the allocator must fulfill with additional allocations for the
entire quantity of inventory to be allocated to the stores. Giving users visibility to the
future fulfillment quantity is critical to ensuring that they are aware of the quantities that
PO creation and update logic is accounting for when the system determines the correct
quantity to be ordered.
FutureSOH and SOH can be queried from the ALC_ITEM_LOC table for the warehouse
and item. The FutureSOH value is held in the future_on_hand_quantity column. This
column includes the future quantity and the current on hand quantity. The application
displays the difference. The SOH value is held in the on_hand_quantity column.
Note: The creation of allocations for the future fulfillment

quantities is not performed by the system. The creation of


allocations is a manual process for the allocators.

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

Oracle Retail Allocation 12.0

Example 1 Item Source Location Selected - T2 Regional


Utah
Regional Distribution
Center
Physical WH 250
Virtual WH - 251
SOH = 0

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

7/14/2005 release date from Virtual WH 251


Because there is two days of transportation time between 251 and 351, the date passed
into the call to ITEM_LOC_QTY_SQL.GET_FUTURE_AVAIL for WH 351 is
7/16/2005. When 7/16/2005 is passed into the RMS function call, ASN 24 is included in
the future expected inventory at WH 351.
The ALC_ITEM_LOC records are reflected in the data below:
ALLOC_ID

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

Warehouse Final Allocation

SOH

Future Fulfillment

PO Amount

TV

251

20

20

Operations Guide 83

Allocation Calculations

Example 2 Item Source Location Selected - T1


Deconsolidation Center
BOL 23
TSF 2333

Note: Direct to Store


purchase orders inclusion or
exclusion from the calculation
is determined by the on order
commit date and weeks from
today selections on the Select
Rules Screen.

Expected Date - 7/4/2005


Item - Sony TV
Quantity - 10

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

Expected Date - 7/5/2005


Item - TV
Quantity - 2

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

Oracle Retail Allocation 12.0

7/14/2005 release date from virtual WH 101


There are two days of transportation time between 101 and 201. There are three days of
transportation time between 101 and 251. Thus, the date passed into the call to
ITEM_LOC_QTY_SQL for WH 201 is 7/4/2005. The date for WH 251 is 7/5/2005. The
resulting records are written to ALC_ITEM_LOC.
The ALC_ITEM_LOC records are reflected in the data below:
ALLOC_ID

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

Update Type = Direct to Store


Select PO Location = Blank
Item Warehouse

Final Allocation

SOH

Future Fulfillment

PO Quantity

TV

60

30

60

101

Note: Based on the example above, if the shipping schedule

between WH 101 and WH 251 had been two days, ASN 24


would not have been included in the future available
inventory quantity returned from ITEM_LOC_QTY_SQL
because a date of 7/4/2005 would have been passed into the
package and the date on ASN 24 is 7/5/2005. In this case,
the future fulfillment value would have been 28 (10 future
from WH 201 and 18 from WH 251).

Note: Current inventory quantities are used before future

inventory quantities.

86

Oracle Retail Allocation 12.0

Example 3 Item Source Location Selected - T1


Deconsolidation Center
BOL 23
TSF 2333
Expected Date - 7/10/2005
Item - Sony TV
Quantity - 10

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

Expected Date - 7/30/2005


Item - TV
Quantity - 5

Expected Date - 7/4/2005


Item - TV
Quantity - 5000

Operations Guide 87

Allocation Calculations

7/4/2005 Release Date from Virtual WH 201 and 251 - T2 Regional


with Two Warehouses
There is one day of transportation time between 201 the stores. There are two days of
transportation time between 251, through the HUB and to the stores.
The ALC_ITEM_LOC records are reflected in the data below:
ALLOC_ID

ITEM_ID

TV

TV

TV

TV

TV

TV

RELEASE_DATE

7/4/2005

LOCATION_ID

201

1234

LOCATION_DESC

Denver

Colorado Denver Utah


Springs

Las Vegas Las


Vegas

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

Note: If the user changes the select PO location to

deconsolidation center, the PO quantity does not account for


ASN32 because it is higher in the supply chain. Therefore,
the front end screen related to what if summary data would
look exactly the same as for the regional selection. If a user
had selected deconsolidation center 151 as his or her item
source location, their what if summary data totals for the
deconsolidation center and the virtual warehouses would be
updated according to the data below.
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)

88

Oracle Retail Allocation 12.0

Item Warehouse

Final Allocation

SOH

Future Fulfillment

PO Quantity

TV

60

55

151

Update Type = Warehouse, cross-dock or bulk quantities


Select PO Location = Regional
Item Warehouse

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.

Characteristics of Java Batch Process


Note the following characteristics of Oracle Retail Allocations Java batch process:
It is not accessible through a graphical user interface (GUI).
It is scheduled by the retailer.
It is designed to process large volumes of data.
It should only be executed during off-hours (that is, during a time when users are
not in the system such as nights).

Java Batch Name and Java Package


The following table describes Oracle Retail Allocations batch process and its associated
Java package.
Batch Name

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)

The batch purging process deletes Oracle


Retail Allocation records that have been
marked as delete in the database. This
Oracle Retail Allocation deletion process
must be run only during off-hours (that is,
during a time when users are not using the
online Oracle Retail Allocation application
system such as nights).

Operations Guide 91

Java Batch Process

Running a Java-based Batch Process


Scheduler and Command Line
If the retailer uses a scheduler, arguments are placed into the scheduler.
If the retailer does not use a scheduler, arguments must be passed in at the command line.
For Unix systems, the Java process is scheduled through an executable shell script (.sh
file). For Windows systems, the Java process is scheduled through an executable batch
file (.bat file).
Oracle Retail provides sample shell scripts (.sh files) and batch files (.bat files). These
sample shell scripts must be modified according to the retailers installation. They
perform the following internally:
Set up the Java runtime environment before the Java process is run.
Trigger the Java batch process.

Summary of Executable Files


To kick off the deletion process, use one of the scripts shown in the table below.
Executable Shell Scripts (UNIX)

Executable Batch File For


Windows

setPurge.sh

purge.bat (Windows)

and
purge.sh

92

Anda mungkin juga menyukai