Oracle Retail Assortment Planning Implementation Guide · PDF filexiv Review Patch ... Oracle Retail Assortment Planning Implementation Guide, Release 15.0 Oracle welcomes customers

[1] Oracle® Retail Assortment PlanningImplementation Guide

Release 15.0

E65529-01

December 2015

Oracle® Retail Assortment Planning Implementation Guide, Release 15.0

E65529-01

Copyright © 2015, Oracle and/or its affiliates. All rights reserved.

Primary Author: James Mork

Contributing Author: Nirmala Suryaprakasha

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Licensing Note: This media pack includes a Restricted Use license for Oracle Retail Predictive Application Server (RPAS) - Enterprise Engine to support Oracle® Retail Assortment Planning only.

Value-Added Reseller (VAR) Language

Oracle Retail VAR Applications

The following restrictions and provisions only apply to the programs referred to in this section and licensed to you. You acknowledge that the programs may contain third party software (VAR applications) licensed to Oracle. Depending upon your product and its version number, the VAR applications may include:

(i) the MicroStrategy Components developed and licensed by MicroStrategy Services Corporation (MicroStrategy) of McLean, Virginia to Oracle and imbedded in the MicroStrategy for Oracle Retail Data Warehouse and MicroStrategy for Oracle Retail Planning & Optimization applications.

(ii) the Wavelink component developed and licensed by Wavelink Corporation (Wavelink) of Kirkland, Washington, to Oracle and imbedded in Oracle Retail Mobile Store Inventory Management.

(iii) the software component known as Access Via™ licensed by Access Via of Seattle, Washington, and imbedded in Oracle Retail Signs and Oracle Retail Labels and Tags.

(iv) the software component known as Adobe Flex™ licensed by Adobe Systems Incorporated of San Jose, California, and imbedded in Oracle Retail Promotion Planning & Optimization application.

You acknowledge and confirm that Oracle grants you use of only the object code of the VAR Applications. Oracle will not deliver source code to the VAR Applications to you. Notwithstanding any other term or condition of the agreement and this ordering document, you shall not cause or permit alteration of any VAR Applications. For purposes of this section, "alteration" refers to all alterations, translations, upgrades, enhancements, customizations or modifications of all or any portion of the VAR Applications including all reconfigurations, reassembly or reverse assembly, re-engineering or reverse engineering and recompilations or reverse compilations of the VAR Applications or any derivatives of the VAR Applications. You acknowledge that it shall be a breach of the agreement to utilize the relationship, and/or confidential information of the VAR Applications for purposes of competitive discovery.

The VAR Applications contain trade secrets of Oracle and Oracle's licensors and Customer shall not attempt, cause, or permit the alteration, decompilation, reverse engineering, disassembly or other reduction of the VAR Applications to a human perceivable form. Oracle reserves the right to replace, with functional equivalent software, any of the VAR Applications in future releases of the applicable program.

v

Contents

List of FiguresList of Tables

Send Us Your Comments ......................................................................................................................... xi

Preface ............................................................................................................................................................... xiii

Audience..................................................................................................................................................... xiiiDocumentation Accessibility ................................................................................................................... xiiiRelated Documents ................................................................................................................................... xiiiCustomer Support ..................................................................................................................................... xivReview Patch Documentation ................................................................................................................. xivImproved Process for Oracle Retail Documentation Corrections ...................................................... xivOracle Retail Documentation on the Oracle Technology Network ................................................... xvConventions ............................................................................................................................................... xv

1 Introduction

Contents of this Guide ............................................................................................................................ 1-1Overview of the Fashion Planning Bundle ......................................................................................... 1-1Architecture of the Template Applications......................................................................................... 1-2Overview of the Business Flow ............................................................................................................. 1-3

Key Features and Capabilities of AP............................................................................................... 1-3Skills Needed for Implementation ....................................................................................................... 1-4

Applications ........................................................................................................................................ 1-4Technical Concepts ............................................................................................................................ 1-4

2 Implementation Considerations

Historical and Required Data ................................................................................................................ 2-1Wholesale/Franchise ................................................................................................................................ 2-3Hardware Space Impacts......................................................................................................................... 2-4Partitioning ................................................................................................................................................ 2-4Formatting.................................................................................................................................................. 2-4Plug-ins....................................................................................................................................................... 2-5Patch Considerations ............................................................................................................................... 2-5Batch Scheduling...................................................................................................................................... 2-5Security....................................................................................................................................................... 2-6Internationalization ................................................................................................................................. 2-8

vi

3 Build Scripts

Installation Dependencies...................................................................................................................... 3-1Environment Setup ............................................................................................................................ 3-1RPAS Installation ............................................................................................................................... 3-1

RPAS Client Installation ............................................................................................................ 3-1Post RPAS Installation Setup............................................................................................................ 3-2

Optional........................................................................................................................................ 3-2Optional for Slow Item Build .................................................................................................... 3-2

AP Installation .................................................................................................................................... 3-2Custom Domain Build................................................................................................................ 3-2

Handling Common Hierarchy Files in the Fashion Planning Bundle Applications................ 3-3Building the AP Domain ........................................................................................................................ 3-3

Files Required to Build the AP Domain.......................................................................................... 3-4Batch Designs...................................................................................................................................... 3-4

Building a Domain...................................................................................................................... 3-4Patching a Domain...................................................................................................................... 3-5

Configuration Files for the RPAS Fusion Client ............................................................................... 3-5Creating Users and User Groups........................................................................................................... 3-5Loading and Extracting Data.................................................................................................................. 3-6

4 Data Flow

Overview of the AP Data Flow .............................................................................................................. 4-1Integration Interface Data Flow Description.................................................................................. 4-2

From a Merchandising Application to Assortment Planning .............................................. 4-2From a Data Warehouse Application to Assortment Planning ........................................... 4-2From Assortment Planning to Allocation ............................................................................... 4-2

5 Fashion Planning Bundle Integration

Overview of the Fashion Planning Bundle ......................................................................................... 5-1Integration Interface Data Flow Description.................................................................................. 5-2

From Size Profile Optimization to Assortment Planning ..................................................... 5-2From Assortment Planning to Item Planning and an Allocation Application .................. 5-2From Item Planning to Merchandise Financial Planning ..................................................... 5-2From Merchandise Financial Planning to Item Planning ..................................................... 5-3From Merchandise Financial Planning to Assortment Planning......................................... 5-3

Execution Applications ..................................................................................................................... 5-4Optimization Applications ............................................................................................................... 5-4Planning Applications ....................................................................................................................... 5-4

6 Script Integration

Integration Scripts.................................................................................................................................... 6-1Batch Environment Scripts ............................................................................................................... 6-2Batch Designs...................................................................................................................................... 6-2Load Measure Data............................................................................................................................ 6-2Export to IP ......................................................................................................................................... 6-3Export to Allocation........................................................................................................................... 6-4

vii

Import from SPO ................................................................................................................................ 6-5Export to SPO...................................................................................................................................... 6-6Slow Item Build .................................................................................................................................. 6-6

AP Slow Item Build Web Service.............................................................................................. 6-7AP Slow Item Build to RMS ...................................................................................................... 6-8

Miscellaneous Scripts ..................................................................................................................... 6-11Formalize DPM Positions Created along the PPOS Hierarchy......................................... 6-11Convert RMS UDA Values to AP Attribute Values............................................................ 6-12Convert RMS Product Attributes to AP Product Attributes ............................................. 6-12List AP Attribute Values without a Corresponding RMS Attribute Value ID ............... 6-13

7 Batch Processing

Batch Structure Overview....................................................................................................................... 7-1Batch Script Summary Table.................................................................................................................. 7-1Batch Environment Scripts ..................................................................................................................... 7-2Batch Scheduling...................................................................................................................................... 7-3

8 Internationalization

Translation................................................................................................................................................. 8-1

9 Configuration Considerations

Calendar (CLND) Hierarchy .................................................................................................................. 9-1Assortment (ASRT) Hierarchy............................................................................................................... 9-2Product (PROD) Hierarchy..................................................................................................................... 9-2Cluster (CLRH) Hierarchy ...................................................................................................................... 9-3Location (LOC) Hierarchy....................................................................................................................... 9-4Product Attribute (ATT) Hierarchy ...................................................................................................... 9-4PoC Attribute (SATT) Hierarchy........................................................................................................... 9-5Color Attribute (AT1H) Hierarchy ........................................................................................................ 9-5Consumer Segment (AT2H) Hierarchy ................................................................................................ 9-5Picklist Position (POS1) Hierarchy ....................................................................................................... 9-6Picklist Position (POS2) Hierarchy ....................................................................................................... 9-6Picklist Position (POS3) Hierarchy ....................................................................................................... 9-6Fulfillment (FFIL) Hierarchy.................................................................................................................. 9-7Slot (SLTH) Hierarchy............................................................................................................................. 9-7Size and Pack Hierarchies ...................................................................................................................... 9-7

viii

ix

List of Figures

1–1 Fashion Planning Bundle Footprint ......................................................................................... 1-21–2 Architecture of the RPAS Template Applications.................................................................. 1-21–3 Business Process Workflow....................................................................................................... 1-34–1 AP Integration with Other Applications ................................................................................. 4-15–1 Conceptual Overview................................................................................................................. 5-15–2 Overview of Fashion Planning Bundle Integration ............................................................... 5-3

x

List of Tables

2–1 Required Load Files for Build .................................................................................................. 2-12–2 Recommended Historical Files to Load.................................................................................. 2-22–3 Recommended Image Data Files ............................................................................................. 2-22–4 User’s Access Permission for AP Workbooks........................................................................ 2-63–1 Build Scripts................................................................................................................................ 3-36–1 Integration Scripts...................................................................................................................... 6-16–2 Load Measure Data.................................................................................................................... 6-26–3 Export to IP Script Arguments................................................................................................. 6-36–4 Export to Allocation Script Arguments .................................................................................. 6-46–5 Export File Format ..................................................................................................................... 6-46–6 Import from SPO........................................................................................................................ 6-56–7 Export to SPO Arguments ........................................................................................................ 6-66–8 AP_SIB_WS.sh Arguments....................................................................................................... 6-76–9 AP_SIB_TORMS.sh Arguments............................................................................................... 6-86–10 ap_map_rms_atv_ids.ksh Argument................................................................................... 6-126–11 ap_map_rms_prodattribs.ksh Argument............................................................................ 6-127–1 Directories Used by Batch Scripts............................................................................................ 7-17–2 Batch Script Summary............................................................................................................... 7-29–1 Calendar Hierarchy ................................................................................................................... 9-29–2 Assortment Hierarchy............................................................................................................... 9-29–3 Product Hierarchy ..................................................................................................................... 9-39–4 Cluster Hierarchy....................................................................................................................... 9-39–5 Location Hierarchy .................................................................................................................... 9-49–6 Product Attribute Hierarchy .................................................................................................... 9-49–7 PoC Attribute Hierarchy........................................................................................................... 9-59–8 Color Attribute Hierarchy ........................................................................................................ 9-59–9 Consumer Segment Hierarchy................................................................................................. 9-59–10 Picklist Position (POS1) Hierarchy.......................................................................................... 9-69–11 Picklist Position (POS2) Hierarchy.......................................................................................... 9-69–12 Picklist Position (POS3) Hierarchy.......................................................................................... 9-69–13 Fulfillment Hierarchy................................................................................................................ 9-79–14 Slot Hierarchy............................................................................................................................. 9-7

xi

Send Us Your Comments

Oracle Retail Assortment Planning Implementation Guide, Release 15.0

Oracle welcomes customers' comments and suggestions on the quality and usefulness of this document.

Your feedback is important, and helps us to best meet your needs as a user of our products. For example:

■ Are the implementation steps correct and complete?

■ Did you understand the context of the procedures?

■ Did you find any errors in the information?

■ Does the structure of the information help you with your tasks?

■ Do you need different information or graphics? If so, where, and in what format?

■ Are the examples correct? Do you need more examples?

If you find any errors or have any other suggestions for improvement, then please tell us your name, the name of the company who has licensed our products, the title and part number of the documentation and the chapter, section, and page number (if available).

Note: Before sending us your comments, you might like to check that you have the latest version of the document and if any concerns are already addressed. To do this, access the Online Documentation available on the Oracle Technology Network web site. It contains the most current Documentation Library plus all documents revised or released recently.

Send your comments to us using the electronic mail address: [email protected]

Please give your name, address, electronic mail address, and telephone number (optional).

If you need assistance with Oracle software, then please contact your support representative or Oracle Support Services.

If you require training or instruction in using Oracle software, then please contact your Oracle local office and inquire about our Oracle University offerings. A list of Oracle offices is available on our web site at http://www.oracle.com.

xii

xiii

Preface

The Oracle Retail Assortment Planning Implementation Guide describes post-installation tasks that need to be performed in order to bring Assortment Planning online and ready for production use.

AudienceThis Implementation Guide is intended for the Assortment Planning application integrators and implementation staff, as well as the retailer’s IT personnel. This guide is also intended for business analysts who are looking for information about processes and interfaces to validate the support for business scenarios within Assortment Planning and other systems across the enterprise.

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle SupportOracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related DocumentsFor more information, see the following documents in the Oracle Retail Assortment Planning Release 15.0 documentation set:

■ Oracle Retail Assortment Planning Installation Guide

■ Oracle Retail Assortment Planning Release Notes

■ Oracle Retail Assortment Planning User Guide for the Fusion Client

For more information on the Fashion Planning Bundle applications, see the following documents:

■ Oracle Retail Merchandise Financial Planning documentation

■ Oracle Retail Item Planning documentation

■ Oracle Retail Item Planning Configured for COE documentation

xiv

■ Oracle Retail Size Profile Optimization documentation

For more information about RPAS and the RPAS Fusion Client, see the RPAS documentation set.

Customer SupportTo contact Oracle Customer Support, access My Oracle Support at the following URL:

https://support.oracle.com

When contacting Customer Support, please provide the following:

■ Product version and program/module name

■ Functional and technical description of the problem (include business impact)

■ Detailed step-by-step instructions to re-create

■ Exact error message received

■ Screen shots of each step you take

Review Patch DocumentationWhen you install the application for the first time, you install either a base release (for example, 15.0) or a later patch release (for example, 15.0.1). If you are installing the base release or additional patch releases, read the documentation for all releases that have occurred since the base release before you begin installation. Documentation for patch releases can contain critical information related to the base release, as well as information about code changes since the base release.

Improved Process for Oracle Retail Documentation CorrectionsTo more quickly address critical corrections to Oracle Retail documentation content, Oracle Retail documentation may be republished whenever a critical correction is needed. For critical corrections, the republication of an Oracle Retail document may at times not be attached to a numbered software release; instead, the Oracle Retail document will simply be replaced on the Oracle Technology Network Web site, or, in the case of Data Models, to the applicable My Oracle Support Documentation container where they reside.

This process will prevent delays in making critical corrections available to customers. For the customer, it means that before you begin installation, you must verify that you have the most recent version of the Oracle Retail documentation set. Oracle Retail documentation is available on the Oracle Technology Network at the following URL:

http://www.oracle.com/technetwork/documentation/oracle-retail-100266.html

An updated version of the applicable Oracle Retail document is indicated by Oracle part number, as well as print date (month and year). An updated version uses the same part number, with a higher-numbered suffix. For example, part number E123456-02 is an updated version of a document with part number E123456-01.

If a more recent version of a document is available, that version supersedes all previous versions.


xv

Oracle Retail Documentation on the Oracle Technology NetworkOracle Retail product documentation is available on the following web site:


(Data Model documents are not available through Oracle Technology Network. You can obtain them through My Oracle Support.)

ConventionsThe following text conventions are used in this document:

Convention Meaning

boldface Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.


xvi

1

Introduction 1-1

1 Introduction

Retailers, especially in the fashion industry, need to determine the correct assortment of products to be made available for sale in stores. This is done 6 to 9 months before the merchandise is available in the stores. Oracle Retail Assortment Planning (AP) enables retailers to determine the appropriate mix of products that will maximize their organizational goals, such as sales, profit, and growth. For a more detailed overview of the functionality within AP, see the Oracle Retail Assortment Planning User Guide for the RPAS Fusion Client.

Contents of this GuideThis implementation guide addresses the following topics:

■ Chapter 1: "Introduction"- Overview of the AP business workflow and skills needed for implementation.

■ Chapter 2: "Implementation Considerations"- Explanation of the factors to take into consideration before performing the implementation.

■ Chapter 3: "Build Scripts"- Information on building and patching the AP domain.

■ Chapter 4: "Data Flow"- Overview of the AP data flow.

■ Chapter 5: "Fashion Planning Bundle Integration"- Overview of the Fashion Planning Bundle data flow.

■ Chapter 6: "Script Integration"- Overview of the script integration used for the Fashion Planning Bundle and Allocation.

■ Chapter 7: "Batch Processing"- Explanation of batch scheduling and batch designs.

■ Chapter 8: "Internationalization"- Translations provided for AP.

■ Chapter 9, "Configuration Considerations" - Explanation of configuration logic impacted by the hierarchy and data.

Overview of the Fashion Planning BundleThe Fashion Planning Bundle is the integration of Item Planning (IP), Clearance Optimization Engine (COE), Assortment Planning (AP), Merchandise Financial Planning (MFP), and Size Profile Optimization (SPO) as a full-suite planning solution for fashion retailers.

For details on integration, see Chapter 5 and Chapter 6.

Architecture of the Template Applications

1-2 Oracle Retail Assortment Planning Implementation Guide

Figure 1–1 Fashion Planning Bundle Footprint

Architecture of the Template ApplicationsFigure 1–2 shows the architecture of the Oracle Retail Predictive Application Server (RPAS) template applications.

Figure 1–2 Architecture of the RPAS Template Applications

This diagram describes the RPAS template applications. In the truest sense, these templates are not applications in the same way that the RPAS client is an application

Overview of the Business Flow

Introduction 1-3

since end-users are not presented a user interface specific to the template. The templates are pre-defined means by which to view specific types of data in the domain, so that the RPAS client user interface can be used to read and write to the domain.

The system administrator, who is responsible for maintaining the RPAS Configuration Tools, ensures that the appropriate templates are available. Each template has the following associated information to define its pre-defined attributes:

■ Measures

■ Special expressions

■ Rules

■ Workbook layout

A user requests to use one of the templates through the RPAS Configuration Tools. A number of XML files are then output that define the domain to be created. These XML files are used to build the specified domain, incorporating all the attributes mentioned above that have been specifically defined.

Once the domain has been created, the end user is able to access the domain data through the RPAS client. Based on the template used, workbooks, measures, rules, and so on, are available to the end user.

Overview of the Business FlowFigure 1–3 shows a typical workflow for AP. The Assortment Planning solution enables the creation, execution, and monitoring of the assortment or range.

Figure 1–3 Business Process Workflow

Key Features and Capabilities of APAP provides the following key features and capabilities:

■ Create store, site, and application clusters (attribute/optimal)

■ Determine the optimal number of style/color targets per cluster

Skills Needed for Implementation


■ Go to market with the Assortment Shopping List

■ Use Slow Item Build to connect the Assortment Plan to Oracle Retail Merchandising System (RMS) for style set-up

■ Automate the allocation of styles to clusters to create the wedge

■ Use visual time-phased view of the assortment (Visual style out)

■ Automate sales and receipt flow reconciled to constraints

■ Calculate optimal allocation to each selling/fulfilling location by size and pack

■ Reconcile to financial plans, capacity constraints, and assortment strategy

■ Embed best practice on top of the configurable platform

Skills Needed for ImplementationThe implementer needs an understanding of the following applications and technical concepts.

ApplicationsThe implementer should understand the interface requirements of the integrated applications and data sources for the master data, demand, and inventory history. For the AP, the implementer needs this knowledge for the following applications:

■ Oracle Retail Predictive Application Server

■ Oracle Retail Merchandising System (RMS)

In addition, knowledge of the following applications is optional:

■ Oracle Retail Clearance Optimization Engine

■ Oracle Retail Item Planning

■ Oracle Retail Merchandise Financial Planning

■ Oracle Retail Size Profile Optimization

■ Oracle Retail Allocation

Technical ConceptsThe implementer should understand the following technical concepts:

■ UNIX system administration, shell scripts, and job scheduling

■ Performance constraints based on the retailer’s infrastructure

■ Technical architecture for AP

■ Retailer’s hierarchical (SKU/store/day) data

■ AP batch processes

■ Setting up an RPAS domain

■ A basic understanding of RPAS configuration and how to use the RPAS Configuration Tools

■ Understanding of how RPAS rule language works

■ Understanding of measures and dimension constructs


Introduction 1-5

■ Understanding of how Fusion Client works



2

Implementation Considerations 2-1

2 Implementation Considerations

The following information needs to be considered before configuring AP:

■ Historical and Required Data

■ Wholesale/Franchise

■ Hardware Space Impacts

■ Partitioning

■ Formatting

■ Plug-ins

■ Patch Considerations

■ Batch Scheduling

■ Security

■ Internationalization

Historical and Required DataIt is recommended that you have at least one year of historical sales and inventory data for creating buy plans. Less data can be used, but the more data that is available, the more statistical significance can be given to the buy plans.

The Generally Available (GA) solution comes with the list of files to load through the base importlist.txt file. This file includes all the files which are used in the demo purpose and is not indicative of all required files.

The tables contains the list of files that are required during GA implementation:

Table 2–1 Required Load Files for Build

File Comments

adlyweekmaptx Mapping of last year week to current/future week.

adatclstatt1tx Internal Position Name for the Cluster Attribute 1.

If GA Clustering solution is being implemented then use the GA data file along with the GA Cluster hierarchy file.

adatclstatt2tx Internal Position Name for the Cluster Attribute 2.

If GA Clustering solution is being implemented then use the GA data file along with the GA Cluster hierarchy file.

Historical and Required Data


addvchannelx Integer value set for each Channel. Brick&Mortar channel must be assigned to "1".

Direct channel must be assigned to "2", and Wholesale/Franchise must be assigned to "3"

drdvecomb Boolean set to True for Direct channel only.

addvwandfb Boolean set to True for Wholesale/Franchise channel only.

Table 2–2 Recommended Historical Files to Load

File Comments

aptybopr Beginning of Period Inventory Retail

aptybopu Beginning of Period Inventory Units

aptyeopr End of Period Inventory Retail

aptyeopu End of Period Inventory Units

aptycustrtrnr Customer Return Retail

aptycustrtrnu Customer Return Units

aptygmpr Gross Margin Retail

aptyrecr Receipt Retail

aptyrecu Receipt Units

aptyslsregr Sales Regular Retail

aptyslsregu Sales Regular Units

aptyslspror Sales Promo Retail

aptyslsprou Sales Promo Units

aptyslsclrr Sales Clearance Retail

aptyslsclru Sales Clearance Units

aptyplcordr Placed Orders Retail - Direct PoC only

aptyplcordu Placed Orders Units - Direct PoC only

aptynbrtransu # of Transactions - Direct PoC only

aptynbrvistv # of Website Visits - Direct PoC only

aptyinbsktu # of Put in the Basket - Direct PoC only

apdymkdnp Markdown % per Unit Sold Owned by Retailer. Only required if Wholesale/Franchise planning is required.

adtymkdnp Markdown per Unit Sold %. Only required if Wholesale/Franchise planning is required.

Table 2–3 Recommended Image Data Files

File Comments

bwimbackviewurl Style-Color back image

bwimdetailviewurl Style-Color detail image

bwimfrontviewurl Style-Color front view image

Table 2–1 (Cont.) Required Load Files for Build

File Comments

Wholesale/Franchise


Wholesale/FranchiseThe retailer has an option to implement AP to support Wholesale/Franchise in 15.0. To implement the Wholesale/Franchise component, the following hierarchy files need to support the Wholesale/Franchise channel:

■ loc.hdr.csv.dat

■ clrh.csv.dat

The GA demo data shows the format required to add the Wholesale/Franchise channel. The GA clustering solution does not support clustering the Wholesale/Franchise channel. The mapping of Wholesale/Franchise location is one to one mapping to cluster position. In order to support the Wholesale/Franchise both files must be updated accordingly.

The retailer also has the option to not incorporate support for Wholesale/Franchise planning. This requires update and patch of the configuration to remove the Tab/Worksheets specific to Wholesale/Franchise. The steps to remove are as follows:

1. Update the configuration of Taskflow to remove the tab/worksheets associated to Wholesale/Franchise. This applies to any tab/worksheets referred to as Wholesale/Franchise or WHSLE/FRCHS of W/F.

2. Save configuration and patch the domain.

3. Copy the $DOMAIN/fusionclient files and update the FC/config/MultiSolution.

4. Restart the WebLogic server.

bwimswatchurl Style-Color Swatch image

drimcolorgrpurl Color Group image

drimcolorurl Color image

drimcustomerurl Customer Segment image

drimskupviewurl Style-Color image for Pop up worksheet. This can be same as any one of the url files for Style-Color, for example: bwimfrontviewurl

drimskugviewurl Style image for Pop up worksheet. This can be same as any one of the url files for Style, for example: slimfrontviewurl

slimbackviewurl Style back image

slimdetailviewurl Style detail image

slimfrontviewurl Style front image

slimswatchurl Style Swatch image

adimfixtypetx Fixture type image

Note: The URL files contain the url link to the images stored in FC/repository folder.

Table 2–3 (Cont.) Recommended Image Data Files

File Comments

Hardware Space Impacts


Hardware Space ImpactsThe following factors can affect hardware space requirements:

■ Points of Commerce–number of physical, web, and other distinct retail outlets.

■ Clusters–number of available pool of clusters. If implementing what is configured in GA for Clustering solution then use the cluster hierarchy file and files mentioned in Required Data.

■ Calendar– number of historical and future time periods in the domain. This impacts the overall size of the environment.

■ Workbooks– amount of space used by workbooks. This is typically greater than the domain itself. The number of workbooks is related to the number of users.

■ Product Attributes – number of available Product Attributes and the attribute value increase will impact the data/workbook size.

PartitioningPartitioning is done to avoid contention for resources. Building a workbook and committing data are two processes that can cause contention.

How data is partitioned has an impact on the business process. The AP domain is defined as a global domain. For performance reasons, a single domain is not recommended. There should be an even distribution of users across a set of local domains. For example, men’s merchandise could be in a domain, women’s merchandise in a domain, and children’s merchandise in a domain. When a user is committing data in the men's merchandise domain, this will not affect the users in the women's or children's domains because of the use of partitioning.

Consider the following questions when defining the partitioning of the domain:

■ How do I partition to meet my business needs?

■ How do I partition my users?

■ How do I create groups of users to further partition the solution?

Domain partition is supported on any PROD and LOC dimension.

Note: The partitioning level in the AP configuration is department. It is recommended that this not be changed.

FormattingFormatting can be done in the configuration or the workbook after the domain is built.

■ An implementer can create generic styles for the measures and assign them to measure components or realized measures. For each measure, these styles can be overridden on each workbook template. Formatting can be changed by using the RPAS Configuration Tools or through the user interface. For more information, see the Oracle Retail Predictive Application Server Configuration Tools User Guide or the Oracle Retail Predictive Application Server User Guide for the Fusion Client.

■ After the domain is built, the implementer can set up worksheet sizes and placements, exception value formatting, gridlines, and other formatting. The implementer opens a workbook of the template to set up specific formatting by using the Format menu. The updated format is then saved to the template so that it is available to all users for any newly created workbooks. For information on

Batch Scheduling


how to use the Format menu, see the Oracle Retail Predictive Application Server User Guide for the Fusion Client.

Plug-ins

Note: There is no Configuration Tools plug-in for AP.

Plug-ins are application-specific Java code modules that run inside and automate the RPAS Configuration Tools to assist the implementer with specific application configuration. There are rules that an implementer must follow when configuring an application. A plug-in makes such adherence easier by automating parts of the configuration process and validity, checking entries that are made.

A prepack optimization plug-in is available to automate the steps required to configure the prepack optimization parameters. This plug-in is used to create optimized pre-pack definitions and is licensed with the SPO solution. Note that this plug-in is different from the pack optimization feature (optimization of receipts to define packs and eaches) available in the standard AP configuration. For information on this prepack optimization plug-in, see Oracle Retail Size Profile Optimization Implementation Guide.

Patch ConsiderationsThere are two types of patches that can affect the AP domain:

■ Changes to the code in the RPAS libraries

The configuration is not affected by this type of patch. For these types of changes, applying the patch is a straightforward process.

■ Changes to the configuration

These types of changes can be more complex. If you have customizations in the configuration, you can use the rpasConfigMgr utility to determine the differences between your existing configuration and the new one. Then, you can use the utility to merge the two configurations. Any changes that cannot be applied are written to a change log. For more information, see the Oracle Retail Predictive Application Server configuration Tools User Guide.

Batch SchedulingBatch scripts are lists of commands or jobs executed without manual intervention. A batch window is the time frame in which the batch process must run. It is the upper limit on how long the batch can take. Batch scripts are used for importing and exporting data. The retailer needs to decide the best time for running batch scripts within the available batch window.

How often to upload updated sales and inventory data needs to be determined. You have to consider at what interval to load the latest sales and inventory data. It is recommended that this is done on a weekly basis. For more information on batch scripts, see Chapter 7.

Security


SecurityTo define workbook template security, the system administrator grants individual users, or user groups, access to specific workbook templates. Granting access to workbook templates provides users the ability to create, modify, save, and commit workbooks for the assigned workbook templates. Users are typically assigned to groups based on their user application (or solution) role. Users in the same group can be given access to workbook templates that belong to that group alone. Users can be assigned to more than one group and granted workbook template access without belonging to the user group that typically uses a specific workbook template. Workbook access is either denied, read-only, or full access. Read-only access allows a user to create a workbook for the template, but the users are not be able to edit any values or commit the workbook. The read-only workbook can be refreshed.

When users save a workbook, they assign one of three access permissions to the workbook:

■ World– allow any user to open and edit the workbook

■ Group– allow only those users in their same group to open and edit the workbooks

■ User– allow no other users to open and edit the workbook

Note: A user must have access to the workbook template in order to access the workbook, even if the workbook has world access rights. If the administrator chooses to customize permissions, remember that the Principle of Least Privilege gives a user enough permissions to do their job and nothing more.

The following table provides a guidance on which AP users should have access to each of the workbooks.

Table 2–4 User’s Access Permission for AP Workbooks

Workbook User RolesData Types in the Workbook

Assortment Setup Visual Merchant Planning Data (edit): Administration Data.

Administration data includes: PoC attribute (store attribute), Strategy Weights (used in clustering), Product Attributes, Customer Definition (product attribute to customer segment assignment), Fixture Capacity, Inclusion Label, Decision Label, and History Mapping.

Central Sales Planner

Merchant/Trading Director

Lifecycle Curve Profile Maintenance

Central Sales Planner Planning Data (read): Sales Curve Data.


Security


Create POC Targets Merchandise Planner Historical Data (read-only): LY Sales Data, LY Receipt Data.

Integrated Planning Data (ready-only): MFP Sales Data, MFP Receipt Data, MFP Ecommerce Data, LP Sales Data, LP Receipt Data, LP Ecommerce Data.


Define Size Profiles and Packs

Buyer Analyst Integrated Planning Data (ready-only): SPO Size Data, SPO Pre-pack Data.

Planning Data (edit): Size Data, Pre-pack Data.

Allocator


Look Maintenance Buyer Analyst Planning Data: Look definition data.


Clustering Buyer Analyst Historical Data (read-only): LY Sales Data.

Integrated Planning Data (ready-only): LP Sales Data.

Planning Data (edit): WP Sales Data, WP Assortment, Product Data, Fixture Capacity Data.


Create Shopping List Senior Buyer Historical Data (read-only): LY Sales Data, LY Assortment Data.

Integrated Planning Data (ready-only): LP Sales Data.

Planning Data (edit): WP Sales Data, WP Assortment, Product Data, Fixture Capacity Data.


Build the Wedge Buyer Analyst Historical Data (read-only): LY Sales, LY Assortment Data.

Integrated Planning Data (ready-only): LP Sales.

Planning Data (edit): WP Sales, WP Assortment, Product Data, Fixture Capacity data.


Buying Plan Buyer Analyst Integrated Planning Data (ready-only): LP Receipt Data.

Planning Data (edit): WP Sales Data, WP Receipts Data, WP Product Data.


Merchandise Planner

Table 2–4 (Cont.) User’s Access Permission for AP Workbooks


Internationalization


For more information on security, see the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client.

InternationalizationInternationalization is the process of creating software that can be translated more easily. Changes to the code are not specific to any particular market.

Oracle Retail applications have been internationalized to support multiple languages.

The RPAS platform supports associated solution extensions and solution templates.

■ A solution extension includes a collection of code and generally available configurations. Typically, solution extensions are implemented by a retailer with minimal configuration.

■ A solution template does not include code. A solution template is most typically implemented as a retailer configuration.

Oracle Retail releases the translations of the RPAS server and client, as well as strings from the solution extensions.

Translations of the solution templates are not released. Since the labels for measures, hierarchies, dimensions, and workbook templates, are typically changed by the retailer at implementation time, languages for the templates are not released. All templates have the ability to support multibyte characters.

Optimize AP Size/Pack Allocations

Buyer Analyst Planning Data (edit): WP Receipt Data.


Merchandise Planner

Optimize SPO Size/Pack Allocation

Buyer Analyst Integrated Planning Data (ready-only): SPO Size Data, SPO Pre-pack Data.

Planning Data (edit): WP Receipt Data.


Merchandise Planner

In-Season Analysis In-Season Analysis Historical Data (read-only): TY Sales Data.

Integrated Planning Data (ready-only): LP Sales Data, LP Receipt Data.

Approved Plan Data (read-only): Buy Plan Sales Data, Buy Plan Receipt Data.

Planning Data (edit): Filter Criteria Data.

Buyer Analyst

Merchandise Planner

Allocator


Historical Analysis Senior Buyer Historical Data (read-only): TY Sales Data, TY Ecommerce Data, TY Receipt Data, TY Assortment Data.

Approved Plan Data (read-only): Buy Plan Sales, Buy Plan Receipt Data, Buy Plan Assortment Data.

Buyer Analyst

Merchandise Planner

Allocator


Table 2–4 (Cont.) User’s Access Permission for AP Workbooks


3

Build Scripts 3-1

3 Build Scripts

This chapter describes the scripts that must be executed to build the AP domain on RPAS.

Installation DependenciesRPAS infrastructure (including the server and client), and AP must be installed before setting up and configuring AP.

■ For information on installing RPAS server and the relevant client, see the Oracle Retail Predictive Application Server Installation Guide.

■ For information on installing AP, see the Oracle Retail Assortment Planning Installation Guide.

Environment SetupBefore downloading the installation package to the UNIX server, a central directory structure to support the environment has to be created. This central directory is referred to as AP_HOME. The UNIX user performing the installation needs to set up an environmental variable called AP_HOME in the user's profile:

■ export AP_HOME=<full path name to AP home>

■ export PATH=$PATH:$AP_HOME/bin

RPAS InstallationThe Java-based RPAS installation programs that are included with the installation package are used to install the server-side RPAS components on UNIX operating systems.

The RPAS installer performs the following functions:

■ Installs the RPAS server.

■ Installs the Configuration Tools on the server. On Windows, an InstallShield package is used to install the Configuration Tools.

■ Defines the DomainDaemon port.

RPAS Client InstallationThe RPAS server installation package also includes the following RPAS client:

■ RPAS Fusion Client: A web-based client developed using Oracle Application Development Framework (ADF).

Installation Dependencies


Each RPAS client installation package includes a separate installer to help you install the client. For more information on installing the RPAS clients, refer to the Oracle Retail Predictive Application Server Installation Guide.

Post RPAS Installation SetupAfter the RPAS installation process is complete, it is necessary to modify portions of two files: delphi.log4j.properties and delphi.properties. These files are located in the $RPAS_HOME/applib/resources/Engine directory. Each file contains an absolute path for a specific file, and these two paths must be valid paths to execute the Assortment Planning Prepack Optimization logic:

■ The delphi.log4j.properties file contains an entry named log4j.appender.Delphi.File. Ensure that the path for this parameter is a valid one.

■ The delphi.properties file contains an entry named engine.agorai.lib. This parameter's value needs to be the absolute path to the $RPAS_HOME/applib directory.

OptionalThe delphi.properties file contains an entry named delphi.sku.store.combination.upperBound. The value of this parameter defines the maximum number of sku-store combinations that the calculation engine optimizes. This variable may need to be increased based upon the size of the optimization problem.

Optional for Slow Item BuildThere is an rms-ItemManagementPortType_JavaServiceConsumer.zip file in the $RPAS_HOME/applib directory. This zip file contains the jar files released by RMS to support the Item Induction web service. To run slow item build, extract all the jar files to the $RPAS_HOME/applib directory.

AP InstallationThe AP installer performs the following functions:

■ Downloads the configuration and batch scripts into the $AP_HOME/config and $AP_HOME/bin directories.

■ Downloads a set of sample hierarchy and data files into the $AP_HOME/input directory.

■ Builds a sample domain at $AP_HOME/domain/APFA.

Custom Domain BuildTo do a custom build of a domain, perform the following steps:

1. Change to the configuration directory: cd $AP_HOME/config.

2. Update the globaldomainconfig.xml file with the correct domain paths.

3. Change to the bin directory: cd $AP_HOME/bin.

4. If needed, update the default environment variables in environment.ksh.

5. Execute the build_ap.ksh script: ./build_ap.ksh.

Building the AP Domain

Build Scripts 3-3

Handling Common Hierarchy Files in the Fashion Planning Bundle ApplicationsThe following hierarchy files contain the superset of all the dimensions along the product, location, and calendar hierarchies:

■ prod.hdr.csv.dat

■ loc.hdr.csv.dat

■ clnd.hdr.csv.dat

These common hierarchy files are shared among AP, IP, MFP, and SPO.

Note: The common hierarchy is not available for IP Configured for COE.

Each hdr.csv.dat (hdr) hierarchy file contains a header line that lists all the dimensions for which position information is contained in the file. The RPAS build process handles these hdr files, so that every application extracts the position information relevant to itself and ignores dimensions not configured in the application.

The filterHier utility is run on the hdr files to convert them into standard hierarchy files that are then passed to loadHier. The build process, which uses rpasInstall, can differentiate between standard and hdr hierarchy files. There is no need for the implementer to make any changes in the domain build process.

If using hdr files, the implementer needs to run filterHier before running loadHier. The filterHier utility converts the hdr files into standard hierarchy files that can be processed by loadHier. Note that there is no need to run filterHier if the standard hierarchy files are already available.

Note: The hdr files must reside outside the domain input directory before running filterHier. By default, the filterHier utility puts the newly created filtered hierarchy files into the input folder of the domain.

See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the RPAS utilities.

Building the AP DomainThe following scripts are not part of a normal batch schedule but are executed only to build or patch a domain.

Table 3–1 outlines the build scripts. These scripts are located in the $AP_HOME/bin directory.

Table 3–1 Build Scripts

Description Script Name Dependency

Build a domain build_ap.ksh None

Patch a domain when the configuration changes do not affect formatting

patch_ap_keepformats.ksh None

Building the AP Domain


Files Required to Build the AP DomainBefore building the domain, set up the following types of file:

■ Standard RPAS Hierarchy files

■ AP-specific Hierarchy files

■ Data files

For information on the standard and AP-specific hierarchy files, see Chapter 9.

In addition, there are some general environmental requirements needed for running any sort of AP-related batch script. For information on these requirements, see Chapter 7.

Batch DesignsThis section contains detailed information on the following build scripts:

■ Building a Domain

■ Patching a Domain

Building a DomainScript

build_ap.ksh

Usage

build_ap.ksh

Notes

■ The script overwrites an existing domain, so it should never be run on top of an existing domain unintentionally. Updating an existing domain should be done through the <AP_HOME>/bin/patch_ap_keepformats.ksh or <AP_HOME>/bin/patch_ap_deleteformats.ksh scripts.

■ The script uses the Configuration Tools rpasInstall utility to build a domain. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on this utility.

■ The script also uses the following RPAS utilities: mace, loadmeasure, and domainprop. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on these utilities.

■ All hierarchy and measure files should be placed in $AP_HOME/input.

■ The commit later functionality is disabled.

■ The script generates logs for itself and each called script. These logs are written to the directory indicated by the environment variable BSA_LOG_HOME. By default, this is set to $AP_HOME/logs. Any error in processing aborts the script, and the logs are designed to provide detail on what caused the error.

Patch a domain when the configuration changes require updates to formatting

patch_ap _deleteformats.ksh None

Table 3–1 (Cont.) Build Scripts

Description Script Name Dependency

Creating Users and User Groups

Build Scripts 3-5

Patching a DomainWhen changes have been made to AP that require changes to the domain, the following scripts are used to apply the patch to the domain.

Script

patch_ap_keepformats.ksh

or

patch_ap_deleteformats.ksh

Usage patch_ap_keepformats.ksh patch_ap_deleteformats.ksh

Notes

■ The main difference between the scripts patch_ap_deleteformats.ksh and patch_ap_keepformats.ksh is that patch_ap_deleteformats.ksh runs the rpasInstall command with the -updatestyles option. (This option causes rpasInstall to import formatting information configured in the Configuration Tools. Omitting it leaves existing formatting information unchanged.)

■ The scripts use the Configuration Tools rpasInstall utility to build a domain. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on this utility.

■ The script generates logs for itself and each called script. These logs are written to the directory indicated by the environment variable BSA_LOG_HOME. By default, this is set to $AP_HOME/logs. Any error in processing aborts the script, and the logs are designed to provide detail on what caused the error.

Configuration Files for the RPAS Fusion ClientThe AP installation software enables you to install the activity taskflow and online help files for the RPAS Fusion Client. In order to install the activity taskflow files, the RPAS Fusion Client must already be installed. For more information on installing the RPAS Fusion Client, refer to the Oracle Retail Predictive Application Server Installation Guide.

During the RPAS Fusion Client installation, the installer automatically sets up the RPAS domain connection configurations in the ProfileList.xml file. In case you choose to set up the domain connection after the installation or set up an additional domain you must manually set up the connection. For more information, refer to the Oracle Retail Predictive Application Server Administration Guide for the RPAS Fusion Client.

Note: The GA Images are included in the GA install package. The files are located in $AP_HOME/media/repository. In order to use the GA images, the Fusion Client image repository must point to this folder during the Fusion Client installation.

Creating Users and User GroupsFor security purposes, users and user groups are not automatically created when you build or patch a domain. To create users and user groups, you must use the usermgr utility. To learn more about usermgr, see the Operational Utilities chapter of the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client.

Loading and Extracting Data


Loading and Extracting DataData is loaded into AP using the standard RPAS approach. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on formatting the load data files and on the utilities that enable administrators to load data into RPAS. For information on integration using scripts, see Chapter 6. For information on any other batch script, see Chapter 7.

The files ADATClstAtt1Tx and ADATClstAtt2Tx need to be loaded in domain, in order to map attributes that are used to cluster to the cluster labels.

4

Data Flow 4-1

4 Data Flow

This chapter describes the flow of data among Assortment Planning with other applications.

Overview of the AP Data FlowFigure 4–1 shows the integration of AP with other applications and the flow of data between the applications.

Figure 4–1 AP Integration with Other Applications

Overview of the AP Data Flow


Integration Interface Data Flow DescriptionThese descriptions explain the some of the data flows in Figure 4–1. For information about the data flows among Fashion Planning Bundle applications, see Chapter 5.

From a Merchandising Application to Assortment PlanningData for the following hierarchies is imported into AP from a merchandising application:

■ Product (PROD) hierarchy

■ Location (LOC) hierarchy

■ Calendar (CLND) hierarchy

■ Sales, incremental updates

The merchandising application provides the foundational data and sales history for the last six months as well as the incremental updates, which are the latest updates for the week.

From a Data Warehouse Application to Assortment PlanningThe following data is imported into AP from a data warehouse application:

■ Floor set calendar

■ Historic sales (cost, retail, unit)

■ Inventory (cost, retail, unit)

■ Markdowns

■ Receipts (units)

From Assortment Planning to AllocationRetailers, especially in the fashion industry, need to determine the correct assortment of products to be made available for sale in stores. AP enables retailers to determine the appropriate mix of products that will maximize their organizational goals. This is typically done well in advance of when the merchandise is available in stores. The export of this data from AP to Allocation, particularly when bolstered with information from other applications in the Fashion Planning Bundle, can greatly enhance the overall performance of the Allocation application.

The following Assortment Planning measures can be used by your Allocation process/solution:

■ Sales and Receipt plan from the Buying Plan step

■ Initial Allocation from the Size/Pre-Pack Allocation step

5

Fashion Planning Bundle Integration 5-1

5 Fashion Planning Bundle Integration

This chapter describes the overall flow of data among the Fashion Planning Bundle applications.

For information about script integration for the Fashion Planning Bundle, see Chapter 6.

Overview of the Fashion Planning BundleThis section describes the integration between solutions within the Fashion Planning Bundle. It does not describe external integrations.

The Fashion Planning Bundle is a full-suite planning solution for fashion retailers that integrates the following applications: Item Planning (IP), Item Planning Configured for Clearance Optimization Engine (IP COE), Assortment Planning (AP), Merchandise Financial Planning (MFP), and Size Profile Optimization (SPO).

Figure 5–1 shows the conceptual overview of the integration of these products.

Figure 5–1 Conceptual Overview

This solution supports data sharing among these applications. Note that the data sharing functionality is not dependent on the presence of all these applications. The defined data sharing between any of the applications works for the entire suite as well as for a subset of the applications.

Overview of the Fashion Planning Bundle


Integration Interface Data Flow DescriptionThese descriptions explain each of the data flows in Figure 5–1.

From Size Profile Optimization to Assortment PlanningThe following data is imported from SPO to AP:

■ Store-level size profiles (current and archived versions) with corresponding escalation levels

■ Store-clustered size profiles

■ Prepack definition configuration at style-color/size/prepack-ID and prepack validity periods at prepack-ID week

The size profiles are used by AP to obtain more detailed buy plans at style-color/size or prepack per store per receipt week. The prepack optimization module of SPO addresses the optimization of not only the number of units within a pack, but also the size ratios for each style-color within the pack. This enables the product to be tailored to the consumer selling patterns at each specific location.

SPO can group stores based on historical data into clusters, and these clusters can be used as a basis for creating prepacks.

For more information on SPO, see the Oracle Retail Size Profile Optimization documentation.

Note: AP also sends the receipt plan to be loaded into SPO at Week/Style-Color/Store.

From Assortment Planning to Item Planning and an Allocation ApplicationThe following data is exported from AP to IP and an allocation application:

■ Buy plan

AP sends the buy plan to IP and the allocation application. The allocation application can use the sales plan or receipt plan created by AP to determine what inventory is allocated to stores. IP uses the pre-look duration assortment plan to track the performance of items during the look duration and to provide a framework to respond accordingly.

From Item Planning to Merchandise Financial PlanningThe following data is exported from IP to MFP:

■ Item plan

Approved data is exported from IP and loaded into MFP at the subclass level. The aggregation takes place within IP when exporting. Only the plans that have been approved since the last export in IP are imported into MFP.

MFP users can review and reconcile their merchandise financial plans (which are planned at the subclass level) to the approved item plans from IP.



From Merchandise Financial Planning to Item PlanningThe following data is exported from MFP to IP:

■ MFP current and original plans

The current and original plans are used by IP to help with the creation of item plans.

From Merchandise Financial Planning to Assortment PlanningThe following data is exported from MFP to AP:

■ MFP current plans

MFP current plans are critical inputs into the AP process. They define the financial goals for that look duration. AP uses these plans as targets to determine the number of options it should carry, the number of weeks it should carry them, and the amount of markdown it can afford in order to meet the targets for sales and gross margin.

Figure 5–2 shows the applications and data flow that are part of the Fashion Planning Bundle.

Figure 5–2 Overview of Fashion Planning Bundle Integration



The applications shown in the diagram are in the following categories:

■ Execution Applications

■ Optimization Applications

■ Planning Applications

Execution Applications

Note: Full data transfers from the execution applications are not part of the Fashion Planning Bundle integration. They are included in the diagram to illustrate that historical data needs to be obtained from applications outside the applications included in the Fashion Planning Bundle.

The execution applications provide the foundation and historical data that is input to the optimization applications.

■ A data warehouse application provides the initial load of sales and inventory data.

■ A merchandising application provides the daily and weekly data updates, or deltas, of the sales and inventory data. It provides data updates of master information such as styles, prices, stores, and so on.

Optimization ApplicationsThe optimization applications take the foundation and historical data and produce size and markdown recommendations that are used by the planning applications.

■ SPO creates profiles of the optimal size distribution by both merchandise category and store. This gives insight into consumer demand patterns by size. These size profiles feed into AP.

For more information on SPO, see the Oracle Retail Size Profile Optimization documentation. For more information on AP, see the Oracle Retail Assortment Planning documentation.

■ COE provides markdown recommendations and forecasts that enable retailers to make informed markdown decisions. What-if data feeds back into COE from IP. COE is only available with IP configured for COE.

For more information on COE, see the Oracle Retail Clearance Optimization Engine documentation. For more information on IP, see the Oracle Retail Item Planning documentation.

Planning ApplicationsThe planning applications take data from the optimization applications and create plans for the retailer.

■ AP creates buy plans for the retailer based on size profiles from SPO and the subclass plans from MFP. The buy plans feeds into IP.

■ IP takes the buy plan from AP and the subclass plan from MFP to create an item plan. When configured for COE, markdown data from COE is also used. IP output feeds back into MFP. What-if data feeds back into COE to create new markdown plans.



■ MFP takes data from IP which is consulted when creating the subclass plan in MFP. Based on financial goals, the subclass plans determine how much merchandise should be available in a store in order to meet the goals. Subclass plans are fed into AP and IP.



6

Script Integration 6-1

6 Script Integration

This chapter describes the script integration of Assortment Planning with the Fashion Planning Bundle applications.

Integration ScriptsIntegration scripts are used for moving data between applications. The following rules apply to integration scripts:

■ The exportMeasure utility is used to export data in comma-separated values (CSV) format. This maintains the consistency of start and width attributes across different applications.

■ Data exported from a source application is placed in the destination domain input directory.

■ Measure names should not be hard-coded. The names are included in a text file named <source application>_<destination application>_transferList.txt. For example, AP_IP_transferList.txt includes the measure names exported from AP to IP.

Each transfer file includes three columns that correspond to the following data:

– Source measure name

– Destination measure name

– Measure base intersection

When the transfer file is used for a load script, it contains the name of the measure to be loaded. The file names correspond to the measure names.

■ Do not hard code domain paths. The paths are entered as command-line arguments.

■ The Batch Script Architecture (BSA) is utilized to provide enterprise-ready architecture for parallel process control, log consolidation, and dependency checks. See the Oracle Retail Batch Script Architecture Implementation Guide.

Table 6–1 lists the integration scripts for AP.

Table 6–1 Integration Scripts

Application Script Name

MFP/DW ap_load_measures.ksh

IP exportToIP_noODI.ksh

Allocation exportToAlloc.ksh

SPO importfromSPO.ksh, exportToPPK.ksh

Integration Scripts


Batch Environment ScriptsFor information on these scripts, see "Batch Environment Scripts" in Chapter 7.

Batch DesignsThis section contains detailed information on the following integration tasks:

■ Load Measure Data

■ Export to IP

■ Export to SPO

■ Export to Allocation

■ Slow Item Build

Load Measure DataThis script loads the data for the measures listed in the base_importlist.txt file. The list of measures captures all the data expected to be loaded to AP from other applications. During implementation, this list should be divided into files that should be loaded daily, weekly, monthly, yearly, and so on.

Scriptap_load_measures.ksh

importdata.ksh

Usageimportdata.ksh <measurelist>

Table 6–2 Load Measure Data

Argument Description Notes

measurelist Sets the location of the file that contains the list of measures to be loaded.

By default, these files are provided with the package in the $AP_HOME/bin directory. The file name can be tailored during implementation and used with the importdata.ksh script. The file name used in the GA version is base_importlist.txt.

Exampleimportdata.ksh base_importlist.txt

Notes■ ap_load_measures.ksh is a wrapper script to call the importdata.ksh to load the

data listed in the base_importlist.txt file.

■ This script uses the RPAS loadmeasure utility. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on this utility.

RMS AP_SIB_WS.sh, AP_SIB_TORMS.sh, ap_map_rms_atv_ids.ksh, ap_map_rms_prodattribs.ksh

Table 6–1 (Cont.) Integration Scripts

Application Script Name

Integration Scripts


■ The script ignores any missing or empty measure load files.

■ All measure files are placed into the domain’s input folder. Master domain input directory if the domain structure is Global domain.

■ All errors and messages are processed by BSA. Refer to the BSA log files for information.

■ importdata.ksh can be utilized to set up the daily, weekly, monthly, and yearly data load process.

Export to IPThis script exports the AP data required for IP. AP exports the data in flat file format which can then be imported directly by IP using the standard RPAS loadmeasure utility.

ScriptexportToIP_noODI.ksh

UsageexportToIP_noODI.ksh <maxprocesses> <destination> <measurelist>

Table 6–3 Export to IP Script Arguments


maxprocesses Sets the maximum number of export processes to run in parallel.

The default is 1.

destination Sets the path to the input folder of the destination domain where the exported files are placed.

The export script creates the CSV file containing the exported measure data in the input folder of the destination domain.

measurelist Sets the location of the file which contains the list of measures to be exported.

By default, this file is provided with the package in the $AP_HOME/bin directory. The file name used in the GA version is AP_IP_transferList.txt.

ExampleexportToIP_noODI.ksh 4 /{domainpath}/itemplan AP_IP_transferList.txt

Notes■ This script is optional and should be used only if exports to IP are required.

■ The script uses the RPAS exportData utility to export measure data from the domain. It also uses the RPAS mace utility to preprocess the AP data for the IP export. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on these utilities.

■ By default, the script generates the output CSV file with a .rpl extension. This can be changed to other file extension types depending on the destination domain's requirement for this data import. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for the data file extension types.

■ This script calls a rule group called AP_to_IP. This rule group preprocesses the AP data for the IP export. See Chapter 7 for more details about this rule group.

Integration Scripts


Export to AllocationThis script exports the AP Receipt Units measure for use by Allocation. AP exports the data in a flat file formatted for use within Allocation. Allocation then uses Oracle Retail Extract Transform and Load (RETL) to extract this information.

ScriptexportToAlloc.ksh

UsageexportToAlloc.ksh <domain> <excluded diff>

Table 6–4 Export to Allocation Script Arguments

Argument Description Values Allowed

domain Sets the path to the current domain.

-d {current domain}. Master domain in Global domain environment.

excluded diff Sets the no color differentiator for the output file.

-e {excluded diff}

Default value: None

Export File Naming ConventionThe output file name starts with lower-case p and follows a standard naming convention:

p<diff count><product level><domain ID> where

■ <diff count> represents the number of differentiators included in the output. Only a single differentiator which is color is exported. Hence this value is always 1; 0 if -e exclude differentiator is not used.

■ <product level> is a four-character sequence representing the product level at which the export is prepared. The valid values are itpt (item), scls (subclass), clss (class), and dept (department).

■ <domain ID> is a constant with a value 01.

ExampleProducts: item1, item2, item3, item4

Diff/Color: Red, Blue, Purple, Blue

Receipt U: 10, 11, 12, 13, 14

When executed with "exportToAlloc.ksh -d {domain} -e Blue" would result in 2 outputs:

■ p0itpt.01 file containing: item1 Red 10, item3 Purple 13

■ p1itpt.01 file containing: item2 Blue 11, item4 Blue 14

Export File Format

Table 6–5 Export File Format

Field Name Start Position Width FormatSample Content

Product ID 1 25 Alpha 100045078

Integration Scripts


Import from SPOThis script loads the data from Oracle Retail Size Profile Optimization (SPO). Measure data files from SPO need to be placed in the <domain>/input directory. This script calls importdata.ksh with a list of measure names defined in SPO_AP_transferList.txt.

ScriptimportFromSPO.ksh

UsageNone

Import List of File Names

Table 6–6 Import from SPO

SPO export file name AP import file name

sztyarchsp1up sztyarchsp1op

sztyarchsp2up sztyarchsp2up



szeptpackdefu eptpackdef

szwpssncodeb szwpssncodeb

sztysizeprflb sztysizeprflb

adwpsizeorderu adwpsizeorderu

szwpescleveltx szwpescleveltx

sztyclssszmapb sztyclssszmapb

Notes■ This script uses the RPAS loadmeasure utility through importdata.ksh. See the

Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on this utility.

■ This script renames the SPO file names to AP file names that are expected by the measure defined in SPO_AP_transferList.txt. Measure name corresponds to file name expected during the import process.

■ Size profiles and prepack definition data can be entered manually through the Size & Pack Profile Maintenance workbook in AP.

Location ID 26 20 Alpha 10000002

Diff ID 46 48 Alpha _Cc1001

EOW Date 94 8 Alpha 20150125

Quantity 102 12 Numeric 100

Table 6–5 (Cont.) Export File Format

Field Name Start Position Width FormatSample Content

Integration Scripts


Export to SPOThis script is used to send input data to the Prepack Optimization module in SPO. This is not to be confused with the pack optimization in AP which is used to optimize receipt drops into predefined prepacks and eaches.

ScriptexportToPPK.ksh

UsageexportToPPK.ksh <maxprocesses> <destination> <measurelist>

Table 6–7 Export to SPO Arguments


maxprocesses Sets the maximum number of export processes to run in parallel.

The default is 1.

destination Sets the path to the input folder of the destination domain where the exported file is placed.

The export script creates the file containing the exported measures in the input folder of the destination domain.

measurelist Sets the location of the file which contains the list of measures to be exported.

By default, these files are provided with the package in the $AP_HOME/bin directory. The file name used in the GA version is AP_PPK_transferList.txt

Notes■ This script is optional and should be used only if export to SPO (Prepack

Optimization module) is required.

■ The Prepack Optimization module is available as a plug-in which is licensed with SPO. Licensed customers can configure the plug-in with AP.

■ The script uses the RPAS exportData utility to export measure data from the domain. It also uses the RPAS mace utility to preprocess the AP data for the IP export. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on these utilities.

Slow Item BuildSlow item build is a process which enables the interaction of RMS and AP concerning the Dynamic Position Management (DPM) of new style-colors and styles created in AP. This is a four step process:

1. The user creates DPM styles or style-colors in the AP workbook. An AP batch process counts the number of DPM style/style-colors and sends a request to RMS to reserve item numbers for the new style/style-colors through a web service call. The web service call returns the reserved item numbers. AP renames the DPM positions according to the returned item numbers. This batch process is implemented in the AP_SIB_WS.sh shell script. For more information, see "AP Slow Item Build Web Service."

2. The attribute information for the new style/style-colors is extracted from the AP domain and uploaded into the RMS staging tables. This process is implemented in the AP_SIB_TORMS.sh shell script. For more information, see "AP Slow Item Build to RMS."

Integration Scripts


3. The RMS user decides which new style/style-colors are to be formalized. A list of style/style-color names is delivered from RMS to AP. The RPAS informalPositionManager utility can be used to formalize the style/style-color positions.

4. In addition, there are a number of scripts supplied to facilitate the translation and storage of RMS UDA_Value IDs to the corresponding attribute values in AP. For information on these scripts, see "Miscellaneous Scripts."

AP Slow Item Build Web ServiceThis script performs the following:

1. Check all the new informal style and style-color positions in the domain and reserve their item numbers through the RMS web service.

2. Using the returned item numbers, rename the new informal positions.

3. After renaming, flag all the renamed positions as old so that the positions do not get sent again.

ScriptAP_SIB_WS.sh

UsageAP_SIB_WS.sh -d DomainPath -dimName DimensionName -expireDays ExpireDays -wallet WalletPath -wsURL WebServiceURL -sqnURL WebServiceQnameURL [-wsOutFile OutFile]

Table 6–8 AP_SIB_WS.sh Arguments

Argument Description

-d Domain path

-dimName Dimension name (style or style-color)

-expireDays Expiration in days. The item numbers reserved in RMS through this web service call are guaranteed to be available until the expiration is reached.

-wallet Wallet directory path

-wsURL Web service URL

-sqnURL Web service qname URL

-wsOutFile Optional argument used to store the ItemManagementService returned reserved item numbers

NoteThe user name and password used to access the RMS ItemManagement web service must be stored in a wallet. The wallet can be created with the following commands:

save_credential.sh -a user -u user -p ims -l testwalletsave_credential.sh -a password -u password -p ims -l testwallet

The wallet must have the following credentials after it is created. To check the credentials, run the following command:

dump_credentials.sh testwallet

Integration Scripts


The following is an example of the output from the command:

Application level key partition name:imsUser Name Alias:password User Name:passwordUser Name Alias:user User Name:user

AP Slow Item Build to RMSThis script performs the following:

1. Extract all informal position names for the style/style-color dimensions.

2. Export the information for the positions from Step 1 and format into a predefined template. This template is in XML format and contains a relevant subset of fields available in the RMS staging tables.

3. Archive the template into a file to be consumed by RMS. (The archived XML is saved with a ".ods" extension. This is the format used by Oracle Open Office spreadsheet files, and can be opened and read with Open Office.)

In AP, product attribute values are stored along a one-dimensional hierarchy (POS1) associated with an attribute hierarchy (ATT). This is done to allow flexibility in defining and changing attribute values. For Slow Item Build, these values must be copied into one-dimensional measures (see below for more information.) Many examples of these measures and transforms are found in the Batch/Slow_Item_Build rule group. This rule group must be executed prior to running the AP_SIB_TORMS.sh script in order for values to be communicated to RMS.

ScriptAP_SIB_TORMS.sh

Note: Make sure that ap_sib_batch.ksh is executed prior to running AP_SIB_TORMS.sh. ap_sib_batch.ksh process. For more information, see Chapter 7.

UsageAP_SIB_TORMS.sh -d DomainPath -configFile ConfigFilePath -ODSFile sample.ods -dimName DimensionName [-create]

Table 6–9 AP_SIB_TORMS.sh Arguments


-d Domain path

-configFile Configuration file path

-ODSFile sample.ods (empty ods file)

-dimName Dimension name of extracted dimensions (style or style-color)

-create Optional argument that indicates that only style/style-colors that have never been sent to RMS will be exported:

■ If the configuration file's action column is specified as "ITEM_MASTER action NA NA create", the generated output file will have the action column filled with create (rather than update).

■ Without -create, only style/style-colors previously sent to RMS will be exported. If the configuration file's action column is specified as "ITEM_MASTER action NA NA update", the generated output file will have the action column filled with update (rather than create).

Integration Scripts


Configuration FileThe configuration file is used to specify what data needs to be extracted from the domain, formatted into the spreadsheet, and uploaded to RMS. The script will only export new informal style/style-color positions in the domain. The contents of this configuration file will vary from application to application, depending on what information is available and important to send to RMS. The configuration file format, with an example entry, is as follows:

Table Column Measure Dimension Comments

ITEM_MASTER DIFF_1 BWWPClrAttrValTx NA Color

The configuration file is a text file that can have multiple lines. Each line describes a column. Every line can have five fields separated by a space. The five columns are described below:

■ Table is the target database table name in RMS in the staging area.

■ Column is the column name in the database table.

■ Measure must contain a valid one-dimensional measure name. The measure must be based on the primaryKey dimension, typically style or style-color. It also indicates this column is for measure content export. The measure column cannot be blank.

■ Dimension contains a valid dimension name that is equal to or above the primaryKey dimension. The dimension column cannot be blank.

■ Comments can have a value of "Y," "N," or other strings. "Y" means this column is a primary key for the output table. "N" means that the column is not a primary key for the output table. A string not equal to "Y" or "N" means this column is to be filled with the string constants.

Following is an example of a control file:

ITEM_MASTER itemnum NA skup YITEM_MASTER subclass NA scls NITEM_MASTER class NA clss NITEM_MASTER color APWPColorTX NA NITEM_MASTER comment NA NA testATTRIBUTE itemnum NA skup YATTRIBUTE User_Defined_ATTR NA NA Silhouette,VendorATTRIBUTE VALUE APWPSilhouetteTx,APWPVendorTx NA N

The control file requires the actual RPAS dimension names. In AP, the style-color dimension has a name of "skup" and a label of "Style-Color." Likewise, the style dimension has a name of "skug" and a label of "Style." References to "skup" or "skug" should be read as referring to style-color and style, respectively.

This example configuration file will generate two tables. One table is named ITEM_MASTER, and the other table is named ATTRIBUTE. The ITEM _MASTER table will have five columns:

■ The line, ITEM_MASTER itemnum NA skup Y, specifies a column named itemnum. The values in the column are skup position names. This column contains the primary key of the ITEM_MASTER table.

■ The line, ITEM_MASTER itemnum NA skup Y, specifies a column named subclass. The values in the column are corresponding subclass position name per skup.

Integration Scripts


■ The line, ITEM_MASTER class NA clss N, specifies a column named class. The values in the column are corresponding class position name per skup.

■ The line, ITEM_MASTER color APWPColorTX NA N, specifies a column named color. The values in the column are the corresponding color per skup. The color information is stored in the measure APWPColorTx, which must be a one dimensional string measure based on skup.

The attribute table is specified by the following three lines:

ATTRIBUTE itemnum NA skup YATTRIBUTE User_Defined_ATTR NA NA Silhouette,VendorATTRIBUTE VALUE APWPSilhouetteTx,APWPVendorTx NA N

■ The first line specifies a column named itemnum. This column contains the skup position names.

■ The second line specifies a column named User_Defined_ATTR. The column will be filled with the values from the comment field: Silhouette or Vendor.

■ The third line specifies a column named Value. This column contains the corresponding value per style from either the APWPSilhouetteTx or APWPVendorTx measure. Both of the measures must be one dimensional measures based on style. Multiple measures names can be comma separated to put into the third line to have a Value field that outputs multiple measure contents. The User_Defined_ATTR field must have comma-separated attribute names corresponding to the measure names.

In the above example, each skup position will be exported twice; one for the export of Silhouette and another for the export of Vendor.

For two new informal skup numbers 1000 and 2000, the exported table will look like the following:

ITEM_MASTER table:

itemnum subclass class color comment

1000 100 10 green test

2000 200 20 yellow test

Attribute table:

itemnum User_Defined_ATTR VALUE

1000 Silhouette A-Line

1000 Vendor Kate Spade

2000 Silhouette A-line

2000 Vendor Kate Spade

In the nightly batch process of slow item build, this script will be called four times with different options:

AP_SIB_TORMS.sh -d . -dimName skup -configFile create_skup.txt -ODSFile create_skup.ods

AP_SIB_TORMS.sh -d . -dimName skup -configFile update_skup.txt -ODSFile update_skup.ods

Integration Scripts


AP_SIB_TORMS.sh -d . -dimName skug -configFile create_skug.txt -ODSFile create_skug.ods

AP_SIB_TORMS.sh -d . -dimName skug -configFile update_skug.txt -ODSFile update_skug.ods

In the RMS application, the user_defined_attr and its value must be RMS positionIDs for the file to be successfully loaded. For the integration to work, the previous example of the control file must be modified to the following:

ITEM_MASTER itemnum NA skup YITEM_MASTER subclass NA scls NITEM_MASTER class NA clss NITEM_MASTER color APWPColorTX NA NITEM_MASTER comment NA NA testATTRIBUTE itemnum NA skup YATTRIBUTE User_Defined_ATTR NA NA 1,2ATTRIBUTE VALUE APWPSilhouetteNm,APWPVendorNm NA N

The resulting Attribute table will look like the following:

itemnum User_Defined_ATTR VALUE

1000 1 1

1000 2 1

2000 1 1

2000 2 1

Miscellaneous ScriptsThere are several scripts included in the Slow Item Build feature that are designed to facilitate the transfer of information from RMS to AP. There are other scripts that are designed to help manage a common set of product attributes.

Formalize DPM Positions Created along the PPOS HierarchyThis script will formalize any informal (DPM) positions found along the Picklist Position (POS1) hierarchy. In AP, attribute values are defined as a list of values associated with a particular attribute. An example could be the attribute "Fabric," with attribute values of "Wool," "Cotton," and "Polyester." These values are defined dynamically in the Assortment Setup workbook. In this case, the attribute (from the ATT hierarchy) is "Fabric," and the options are defined along a list dimension. Occasionally an attribute will have an exceptionally large number of options, exceeding the size of the list dimension. This is accommodated by making the list dimension (ppos) DPM-enabled. This script just formalizes any DPM positions that exist along the ppos dimension.

Scriptap_formalize_ppos.ksh

Usageap_formalize_ppos.ksh

ArgumentsNone

Integration Scripts


Convert RMS UDA Values to AP Attribute ValuesThis script reads a file of RMS UDA Values and converts them to the corresponding attribute values in AP. The script does this by matching the string values of the attribute values to the string values of the UDA values within a given attribute/UDA. (This makes it possible to have an attribute value for "Floral" in both the "Pattern" and "Fragrance" attributes.)

Scriptap_map_rms_atv_ids.ksh

Usageap_map_rms_atv_ids.ksh -r <path to RMS_Attribute_Value_ID_File>

Table 6–10 ap_map_rms_atv_ids.ksh Argument


-r The path to a file which contains the RMS Attribute Value information. This file is expected to be a comma-separated values text file, with the following format:

Attribute ID, Attribute Value ID, Attribute Value Label

Note: In RMS, these will likely be coming from the UDA tables, but that is not a requirement. This script assumes that the Attribute ID is common between RMS and AP, and that the Attribute Value Labels also match. This script matches on label per attribute ID, and retains the position of the matching value on the ppos dimension in the POS1 hierarchy. It then prepares a load file for the measure ADDYAttrValTx to store the RMS Attribute Value ID, and loads that measure file.

Convert RMS Product Attributes to AP Product AttributesThis script is very similar to ap_map_rms_atv_ids.ksh, but instead takes existing attributes defined for a product in RMS and translates those to the corresponding attribute for the corresponding product in AP. It uses the same lookup mechanism to create a measure load file for attributes assigned to a product (SLWPProdAttrTx) and then loads the file.

Scriptap_map_rms_prodattribs.ksh

Usageap_map_rms_prodattribs.ksh -r <path to RMS_Product Attribute_File>

Table 6–11 ap_map_rms_prodattribs.ksh Argument


-r The path to a file which contains the RMS product attribute assignments. This file is expected to be a comma-separated values text file, with the following format:

Product ID, Attribute Name ID, RMS Attribute Value ID

Note: This script assumes the Product ID and Attribute ID are common between RMS and AP. It also assumes that the RMS attribute value IDs are already stored in AP. For each row where this is not the case, a notice is written to the log and the script proceeds to the next line.

Integration Scripts


List AP Attribute Values without a Corresponding RMS Attribute Value IDThis script produces a file that lists all AP attribute values that lack an RMS attribute value ID. This is meant to facilitate setting up the corresponding attributes in RMS. The listing of the unmapped attribute values is written to the domain's output directory.

Scriptap_rms_unmapped_attrib_vals.ksh

Usageap_rms_unmapped_attrib_vals.ksh

ArgumentsNone

Integration Scripts


7

Batch Processing 7-1

7 Batch Processing

This chapter contains a summary of the scripts that are needed to execute and maintain AP.

Details of the batch scripts are described in Chapter 6. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on formatting the load data files and on the utilities that enable administrators to load data into RPAS.

Note: Comma-separated values (CSV) files are recommended to reduce the sizes of load files.

Batch Structure OverviewThe following directories are used by the batch scripts. These directories are subdirectories of the $AP_HOME directory.

Table 7–1 Directories Used by Batch Scripts

Directory Name Content of the Directory

bin Batch scripts

config AP template configuration

domain Domains

input Input files for building the domain

logs Log files from running any of the batch scripts

temp Temporary files used by the batch scripts

Batch Script Summary TableTable 7–2 summarizes the available batch scripts, rule groups, and custom menu actions. The batch scripts are located in the <AP_HOME>/bin directory. The following information is included in the table:

■ Name of the batch operation

■ Type (rule group, script, custom menu)

■ Suggestion on how often to run the script

■ List of other batch operations on which there is a dependency

Table 7–2 Batch Script Summary

Name Type Suggested Frequency Dependencies

ap_sib_batch.ksh Script Daily environment.ksh

ap_load_measures.ksh Script Weekly base_importlist.txt, environment.ksh

ap_batch.ksh Script Weekly environment.ksh

importfromSPO.ksh Script As needed environment.ksh, SPO_AP_transferList.txt

exportToIP_noODI.ksh Script As needed environment.ksh, AP_IP_transferList.txt

exportToAlloc.ksh Script As needed environment.ksh

exportToPPK.ksh Script As needed environment.ksh, AP_PPK_transferList.txt

environment.ksh Script As needed None

Batch Environment Scripts


Batch Environment ScriptsTwo scripts are included in the other batch scripts to control logging and set environment variables.

The first script, message.ksh, controls the overall logging. The script writes batch script details to a daily log file. The daily log file is created in the $AP_HOME/logs directory and can be in the format of MnthID_Day.log, for example, Apr_02.log.

The second script, environment.ksh, is called at the beginning of every batch script. This script must be called prior to starting a DomainDaemon so that the necessary environment variables are set. This script sets the following variables:

■ export AP_CONFIGNAME=APFA

■ export AP_CONFIGHOME=$AP_HOME/config

■ export AP_DOMAINHOME=$AP_HOME/domain

■ export AP_EXPORT=$AP_MASTERDOMAIN/output

■ export AP_INPUTHOME=$AP_HOME/input

■ export AP_LOG_DIR=$AP_HOME/logs

■ export AP_MASTERDOMAIN=$AP_DOMAINHOME/APFA

■ export AP_TEMP=$AP_HOME/temp

■ export AP_BATCH=$AP_HOME/bin

■ export AP_GUROBI_DUMP_PATH=$AP_HOME/logs

■ export RECORDLOGLEVEL=warning

The script environment.ksh also exports the variable RPAS_JAVA_CLASSPATH. The required components for RPAS_JAVA_CLASSPATH are:

■ $RPAS_HOME/applib/adflogginghandler.jar

■ $RPAS_HOME/applib/adfm.jar

■ $RPAS_HOME/applib/adf-share-base.jar

■ $RPAS_HOME/applib/adf-share-ca.jar

Batch Scheduling


■ $RPAS_HOME/applib/aaiAP.jar

■ $RPAS_HOME/applib/aaijni.jar

■ $RPAS_HOME/applib/castor-1.3.3-core.jar

■ $RPAS_HOME/applib/castor-1.3.3-xml.jar

■ $RPAS_HOME/applib/coherence.jar

■ $RPAS_HOME/applib/commons-cli-1.2.jar

■ $RPAS_HOME/applib/commons-collections-3.2.1.jar

■ $RPAS_HOME/applib/commons-io-2.4.jar

■ $RPAS_HOME/applib/commons-lang-2.6.jar

■ $RPAS_HOME/applib/commons-lang3-3.3.2.jar

■ $RPAS_HOME/applib/commons-logging-1.1.1.jar

■ $RPAS_HOME/applib/commons-math-2.2.jar

■ $RPAS_HOME/applib/gurobi.jar

■ $RPAS_HOME/applib/javax.persistence_2.0.jar

■ $RPAS_HOME/applib/jps-api.jar

■ $RPAS_HOME/applib/junit.jar

■ $RPAS_HOME/applib/log4j-1.2.17.jar

■ $RPAS_HOME/applib/lpspec.jar

■ $RPAS_HOME/applib/ojdbc7.jar

■ $RPAS_HOME/applib/resourcebundle.jar

■ $RPAS_HOME/applib/rse_analytics.jar

■ $RPAS_HOME/applib/rse_common.jar

■ $RPAS_HOME/applib/spring-beans-4.0.2.RELEASE.jar

■ $RPAS_HOME/applib/spring-context-4.0.2.RELEASE.jar

■ $RPAS_HOME/applib/spring-core-4.0.2.RELEASE.jar

■ $RPAS_HOME/lib/oracleRpasUtils.jar

■ $RPAS_HOME/lib/rpasjni.jar

The script environment.ksh has the correct format for this environment variable.

A system administrator can scan the logs for any errors, exceptions, or failures. If there are none, the batch completed successfully.

Batch SchedulingDuring implementation, the following scheduling of the batch processes is required:

■ Daily batch

■ Weekly batch

■ Monthly batch

■ Yearly batch

Batch Scheduling


The Generally Available (GA) solution does not provide all the scripts to cover the batch processes. The shell scripts function as the wrapper for calling the RPAS utility to execute a specific task. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on RPAS utilities for batch maintenance.

Some of the key batch processes to consider during implementation are:

■ Start/Stop DomainDaemon process which allows user connection to the application

■ Backup process (both domains and log files/processed data files)

■ Check for CommitASAP process

■ Hierarchy load and purge process

■ Load measure process: importdata.ksh script can be utilized to perform this task

■ Export data process

Daily Batch ProcessDaily batch covers the process of updating the hierarchy, importing data, and exporting the plan data.

The general standard process is as follows:

1. Stop the DomainDaemon process. This prevents the users from connecting to the application while the batch process is executing. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on how to start/stop the user connections to the application using the RPAS utility DomainDaemon.

2. Create a job to run the script ap_sib_batch.ksh. This script calls rule groups in the domain to refresh the data sent to RMS using the Slow Item Build process.

Note: This step is only necessary if the implementation is using the Slow Item Build feature. No daily batch is necessary if Slow Item Build is not used. For more information on Slow Item Build, see the Oracle Retail Assortment Planning User Guide for the RPAS Fusion Client.

3. Start the DomainDaemon process. This enables the users to connect to the application after the batch processes are complete.

Weekly Batch ProcessWeekly batch covers the process of updating the hierarchy, importing data, and exporting the plan data.

The general standard process is as follows:

1. Stop the DomainDaemon process. This prevents the users from connecting to the application while the batch process is executing. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on how to start/stop the user connections to the application using the RPAS utility DomainDaemon.

2. Create and run a script that calls the RPAS utility loadHier. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on this RPAS utility. The hierarchy files must be placed in the domain/input directory.

Batch Scheduling


This process updates the domain hierarchy positions/labels with the latest hierarchy definition.

3. Run the import data script to load the latest data into the domain. This is the ap_load_measures.ksh script. The script detail is provided in Chapter 6. The data files must be placed in the domain/input directory. This process updates the measure data based on the measure file extension. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on load file format and extension types.

4. Run the post-processing script called ap_batch.ksh. This script runs the following batch rule groups that processes the loaded data into the format required for measures shown in the application:

■ Batch_GB: This rule group sets the flag for weeks that are considered to be elapsed in the application. If the week ending day is Saturday, this batch process must run from midnight Saturday through Sunday.

■ Batch_WP_Update: This rule group updates the Working Plan (WP) measures with the weekly posted data for elapsed weeks. This maintains the planned data for unelapsed weeks, but updates the elapsed weeks with the actuals.

■ Batch_Inv_Flow: This rule group updates the inventory flow measures, that is, Beginning of Period Inventory (BOP) values and End of Period Inventory (EOP) values based on the latest posted Sales and Receipt values.

■ Curve_Calc: This rule group updates the Sales Curve % and Seasonality Curve % measures based on the loaded MFP targets and loaded Sales Curve profiles. This rule group is not required in batch if the targets and profile values are planned within the application using the Maintenance workbooks provided.

5. Export plan data to IP, Allocation, and Prepack (if required). The export script details are provided in Chapter 6. Some of the export script also calls batch rule groups to pre-process the plan data into the format required for export. The following rule groups are used for export:

■ AP_to_IP: This rule group pre-processes the data into the format required by IP. It takes the plan measure and aggregates/spreads the data into the base intersection that matches the format required by IP. The base intersection required is specified in the file AP_IP_transferList.txt.

■ AP_to_Alloc: This rule group pre-processes the data into the format required by Allocation. It takes the measure data to populate the export measure which conforms to the format required by the export script.

■ AP_to_Alloc_Cl: This rule group sets the mask measure flag to false after the pre-processing of AP_to_Alloc is completed.

6. Start the DomainDaemon process. This will allow the users to connect to the application after the batch processes are complete.

Batch Scheduling


8

Internationalization 8-1

8 Internationalization

Internationalization is the process of creating software that can be translated more easily. Changes to the code are not specific to any particular market.

Oracle Retail applications have been internationalized to support multiple languages.

TranslationTranslation 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 include the following:

■ Graphical user interface (GUI)

■ Error messages

The following components are not translated:

■ Documentation (online help, release notes, installation guide, user guide, operations guide)

■ Batch programs and messages

■ Log files

■ Configuration tools

■ Reports

■ Demonstration data

■ Training materials

The user interface has been translated into the following languages:

■ Chinese (Simplified)

■ Chinese (Traditional)

■ Croatian

■ Dutch

■ French

■ German

■ Greek

■ Hungarian

■ Italian

Translation


■ Japanese

■ Korean

■ Polish

■ Portuguese (Brazilian)

■ Russian

■ Spanish

■ Swedish

■ Turkish

Note: For information about adding languages for the first time or for translation information in general, see the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client.

9

Configuration Considerations 9-1

9Configuration Considerations

This chapter provides information on the configuration changes that can be made for AP. For some retailers, parts of the released version of the AP configuration might fit perfectly. However, it is anticipated that changes are needed to make the AP configuration match the organization of the retailer.

Hierarchies are limited to the determination of hierarchy aspects that pertain directly to dimensions, attributes, facts, and escalation. Due to RPAS limitations on intersection, distinct hierarchies must exist for the construction of all intersections to support all facts. No more than one dimension from any hierarchy can exist in a measure intersection. Some dimension, position ID, and position Label must match what is configured in the GA solution, otherwise, it needs to be updated to match the hierarchies. See the Oracle Retail Predictive Application Server Configuration Tools User Guide for details on how to use the configuration tool.

For information on the configuration changes that can be made, see the following sections:

■ Calendar (CLND) Hierarchy

■ Assortment (ASRT) Hierarchy

■ Product (PROD) Hierarchy

■ Cluster (CLRH) Hierarchy

■ Location (LOC) Hierarchy

■ Product Attribute (ATT) Hierarchy

■ PoC Attribute (SATT) Hierarchy

■ Color Attribute (AT1H) Hierarchy

■ Consumer Segment (AT2H) Hierarchy

■ Picklist Position (POS1) Hierarchy



■ Fulfillment (FFIL) Hierarchy

■ Slot (SLTH) Hierarchy

■ Size and Pack Hierarchies

Calendar (CLND) HierarchyTable 9–1 shows the structure of the Calendar hierarchy in the AP configuration.

Table 9–1 Calendar Hierarchy

RPAS Name Label Hierarchy Type

day Day Main

week Week Main

mnth Month Main

ssn Half Main

year Year Main

woy Week of Year Alternate

Assortment (ASRT) Hierarchy


The Calendar hierarchy represents the time in all RPAS solutions. This is a standard hierarchy interface required in all RPAS solutions. The file has the extension of hdr.csv.dat. Header extension allows you to have more columns in the file, but RPAS will load only the appropriate dimensions required in the solution. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements.

Assortment Planning requires the Day, Week, and WOY dimensions, which have been hard-coded in the calc logic in the rules. The recommendation is to not change the dimension ID (RPAS Name) for Day, Week, and WOY. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.

Assortment (ASRT) HierarchyTable 9–2 shows the structure of the Assortment hierarchy in the AP configuration.

Table 9–2 Assortment Hierarchy


look Look Main

lgrp Look Group Main

The Assortment Hierarchy is a vital part of the Assortment Planning process that represents the planning periods (grouping of weeks). This hierarchy is maintained within Assortment Planning and is not interfaced from other systems. The system administrator should maintain this file and load it when required. Looks no longer being used should be purged from the hierarchy and new Looks required for planning should be added. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements and purging information.

Assortment Planning requires the dimensions Look and Look Group. The recommendation is to not change the dimension ID (RPAS Name) for Look and Look Group. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.

Product (PROD) HierarchyTable 9–3 shows the Product hierarchy in the AP configuration.

Table 9–3 Product Hierarchy


sku Style-Color Main

skug Style Main

scls Subclass Main

clss Class Main

dept Department Main

pgrp Group Main

Cluster (CLRH) Hierarchy


The Product hierarchy represents the retail items in all RPAS solutions. This is a standard hierarchy interface required in all RPAS solutions. The file has the extension of hdr.csv.dat. Header extension allows you to have more columns in the file, but RPAS will load only the appropriate dimensions required in the solution. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements.

Assortment Planning requires the Style-Color, Style, and Subclass dimensions, which have been hard-coded in the calc logic in the rules. The recommendation is to not change the dimension ID (RPAS Name) for sku, skug, and scls. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.

Cluster (CLRH) HierarchyTable 9–4 shows the Cluster hierarchy in the AP configuration.

Table 9–4 Cluster Hierarchy


clus Cluster Main

clst Cluster Parent Main

chn2 Cluster Group/ Channel

Main

szgp Space Group Alternate

The Cluster Hierarchy is required to support the GA clustering workbook which provides the process to cluster stores based on performance and store attributes. It is recommended to not alter the cluster hierarchy, as every dimension is important in the overall Assortment Planning configuration logic. The dimension labels can be changed if required.

The clrh.csv.dat file also must be kept as is in the GA solution. This ensures the correct workings of Store Clustering.

Note: It is important for the Cluster Group/Channel (chn2) dimension to have a position ID/Label to match the position ID/Label of the Location hierarchy Channel (chnl). That is, 1,Brick & Mortar; 4,Direct. This is critical for mapping the data between the cluster hierarchy and location hierarchy. The Batch_GB rule group is hard-coded to use the Cluster Group/Channel label. If the label is changed from the GA cluster hierarchy, the rules in this rule group must be updated.

Location (LOC) Hierarchy


Location (LOC) HierarchyTable 9–5 shows the Location hierarchy in the AP configuration.

Table 9–5 Location Hierarchy


str PoC Main

rgn Region Main

chnl Channel Main

The Location hierarchy represents the retailer Point of Commerce used in all RPAS solutions. This is a standard hierarchy interface required in all RPAS solutions. The file has the extension of hdr.csv.dat. Header extension allows you to have more columns in the file, but RPAS will load only the appropriate dimensions required in the solution. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements.

Assortment Planning requires the Store and Channel dimensions, which have been hard-coded in the calc logic in the rules. The recommendation is to not change the dimension ID (RPAS Name) for str and chnl. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.

Product Attribute (ATT) HierarchyTable 9–6 shows the Product Attribute hierarchy in the AP configuration.

Table 9–6 Product Attribute Hierarchy


attr Product Attribute Main

attg Product Attribute Group

Main

The Product Attribute hierarchy represents all the attributes associated to items. This enables the solution to provide the breakdown view of the plan by key attributes. This hierarchy is maintained within Assortment Planning. The configuration expects the following attributes to exist with the exact label of Silhouette, Fabric, Brand, and Embellishment. These attribute labels are hard-coded in the BW_Set_calc and Shop_List_calc rule groups. If these labels need to change, the configuration needs to be updated to reflect the new labels.

Consumer Segment (AT2H) Hierarchy


The security dimension is set for Subclass. This can change to a higher or lower level if required by the business, however, the recommendation is to maintain at the Subclass level because most of the logic, within the GA configuration, is users having specific ownership of subclasses. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the User Security workbook.

PoC Attribute (SATT) HierarchyTable 9–7 shows the PoC Attribute hierarchy in the AP configuration.

Table 9–7 PoC Attribute Hierarchy


stra PoC Attribute Main

strg PoC Attribute Group Main

The Point of Commerce Attribute hierarchy represents all the attributes associated to the Point of Commerce. This enables clustering by attributes associated to each Point of Commerce. This hierarchy is maintained within Assortment Planning. The configuration expects all the attributes defined in the satt.csv.dat file. These attribute labels are hard-coded in the AP_Setup_calc rule group. If these labels need to change, the configuration needs to be updated to reflect the new labels.

Color Attribute (AT1H) HierarchyTable 9–8 shows the Color Attribute hierarchy in the AP configuration.

Table 9–8 Color Attribute Hierarchy


stra PoC Attribute Main

strg PoC Attribute Group Main

The Color Attribute hierarchy represents all the colors available for retailer items. This hierarchy is maintained within Assortment Planning. Both dimensions are used in the multiple calc rules, which means it should not be updated.

Consumer Segment (AT2H) HierarchyTable 9–9 shows the Consumer Segment hierarchy in the AP configuration.

Table 9–9 Consumer Segment Hierarchy


csd Consumer Segment Main

The Consumer Segment hierarchy represents all the colors available for retailer items. This hierarchy is maintained within Assortment Planning. Both dimensions are used in the multiple calc rules, which means it should not be updated.

Picklist Position (POS1) Hierarchy


Picklist Position (POS1) HierarchyTable 9–10 shows the Picklist Position hierarchy in the AP configuration.

Table 9–10 Picklist Position (POS1) Hierarchy


ppos Picklist Position Main

The Picklist Position (POS1) hierarchy is required in the solution to allow the user to define the product attribute values associated to each attribute. This hierarchy is maintained within Assortment Planning. The number of positions should be based on the maximum number of values required by an attribute. This dimension is used in multiple rule groups. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration; but for this hierarchy, this would not be required.




ppo2 Picklist Position Main

The Picklist Position (POS2) hierarchy is required in the solution to allow the user to define the product attribute values associated with each attribute. This hierarchy is maintained within Assortment Planning. The number of positions should be based on the maximum number of values required by an attribute. This dimension is used in multiple rule groups. Other dimensions and hierarchy branches could be added without changes required to other elements of the Assortment Planning configuration; but for this hierarchy, this would not be required.




ppo3 Picklist Position Main

The Picklist Position (POS3) hierarchy is required in the solution to allow the user to define the PoC attribute values associated with each attribute. This hierarchy is maintained within Assortment Planning. The number of positions must be 8. This hierarchy and file must be used, as is, in the GA solution, which is created to work with the Cluster Hierarchy positions.

Size and Pack Hierarchies


Fulfillment (FFIL) HierarchyTable 9–13 shows the Fulfillment hierarchy in the AP configuration.

Table 9–13 Fulfillment Hierarchy


ffch Child Fulfillment Option

Main

ffgr Parent Fulfillment Type

Main

The Fulfillment hierarchy represents the different types of fulfillment options. This hierarchy is maintained within Assortment Planning, however it needs to correspond to the fulfillment options available for data integration. The Sales, Gross Margin, and Customer Return data are expected to be loaded per the fulfillment option (at ffch level). Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.

Slot (SLTH) HierarchyTable 9–14 shows the Slot hierarchy in the AP configuration.

Table 9–14 Slot Hierarchy


slth Slot Main

The Slot hierarchy hierarchy is used solely to support the time-phased view of the wedge. For this view, slot groups correspond to looks and slots represent style-colors offered as part of the look over time. Depending on the number of looks included in an assortment and the number of style-colors in each look, additional slot group and/or slot positions may need to be added to this hierarchy over time.

The algorithm that generates the time-phased view of the wedge depends on the two-tier structure of the hierarchy. Adding or removing levels will likely render the time-phased view of the wedge algorithm inoperable.

Size and Pack HierarchiesThe Size and Pack hierarchies are interfaced from SPO. It should not change as it is defined in the GA solution.

Size and Pack Hierarchies
