Allocation 12.0 Organization Guide

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.

Operations Guide iii

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

iv

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

Operations Guide v

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 vii

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

viii

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.

Operations Guide ix

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/

x

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/

Operations Guide 1

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.

Introduction

2

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.

GUI/Client tier

Business objects

Database

JDBC

Data access layer with the

database version

compatible driver

JSPsJavascript

HTMLJSP tag libraries

Business object tier

Database tierData access layer tier

Denotes separation of tier

Middle tier

Service Layer

Oracle Retail Allocations n-tier Architecture

Operations Guide 3

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.

Backend System Administration and Configuration

4

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/alc11dev-connection_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/alc11dev-error_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

Operations Guide 5

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: [email protected]

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.


For example: [email protected]

Log Email Subject This setting defines the log e-mails subject.


For example: loggerEmailSubject=Allocation Alert Message


6

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


Operations Guide 7

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#### %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


8

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


Operations Guide 9

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


10

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


Operations Guide 11

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.


12

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.


Operations Guide 13

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


14

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


Operations Guide 15

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\


16

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.


Operations Guide 17

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


18

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

Operations Guide 19

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.

GUI/Client tier

Business objects

Database

JDBC

Data access layer with the

database version

compatible driver

JSPsJavascript

HTMLJSP tag libraries

Business object tier

Database tierData access layer tier

Denotes separation of tier

Middle tier

Service Layer

Oracle Retail Allocations n-tier Architecture

Technical Architecture

20

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.


Operations Guide 21

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.

Technical Architecture

22

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.


Operations Guide 23

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 25

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

Functional Design

26

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.


Operations Guide 27

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

Functional Design

28

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.


Operations Guide 29

Multi-level Distribution (MLD) Note: The Oracle Retail Allocation, RMS, and RWMS interface is not capable of facilitating warehouse-to-warehouse 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.

Functional Design

30

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.

Oracle Retai

Documents

Allocation 12.0 Organization Guide