8.1.2 Admin

Administrator Guide
JDA® Allocation
Release 8.1.2.0
Legal notice
Rights to the content of this document
Copyright © 2005-2015 JDA Software Group, Inc. All rights reserved.
Printed in the United States of America.
Reproduction of this document or any portion of it, in any form, without the express written consent of JDA Software Group,
Inc. ("JDA") is prohibited.
These materials are protected by the Copyright Act of 1976, as amended, as an unpublished work and the foregoing notice and
legend shall not be deemed to constitute publication or an intent to publish thereunder. These materials are proprietary and
confidential information of JDA and may be disclosed and used only as authorized in a signed, written agreement controlling
such disclosure or use.
The fact that a particular name or logo does not appear on this notice does not constitute a waiver of any intellectual property
rights that JDA has established in any of its products, feature or service names, or logos.
Modifications to the contents of this document

JDA reserves the right, at any time and without notice, to change these materials or any of the functions, features, and
specifications of any of the software described herein. JDA shall have no warranty obligation with respect to these materials of
the software described herein, except as provided in the JDA software license agreement with an authorized licensee.
Rights to the functionality of this document

Described functionality may not be available as part of a customer's maintenance agreement or the JDA Investment Protection
Program. New features and products are subject to license fees. JDA warranty and support obligations apply only to the
documentation as delivered by JDA, and are void if the documentation is modified or supplemented by anyone other than JDA.
This document embodies JDA valuable trade secrets, is confidential to JDA, and must be kept in confidence and returned upon
the expiration or termination of your JDA license agreement. You are not permitted to copy, extract, distribute, transfer, or
share the contents of this document with anyone except authorized individuals within your organization.
Technical documentation
NOTICE: This design or technical documentation is supplied as a courtesy only and does not form part of the "Documentation"
as defined in your JDA license agreement. This design or technical documentation is supplied in the English language only and is
supplied "as is" and without warranties. JDA, at its discretion, may choose to offer this document in additional languages, but is
under no obligation to do so. JDA undertakes no obligation to update this design or technical documentation.
Patents
This product may be protected by one or more United States and foreign patents. Please see the JDA Patents website
(http://jda.com/JDAPatents).
Provide feedback on this document
JDA values your opinion and strives to ensure that the documentation you receive is clear, concise,
and provides the appropriate information required for you to use each JDA application efficiently.
If you would like to provide feedback on this document, you can submit your questions or suggestions
to the JDA Documentation Management team (mailto:[email protected]) and they will
be forwarded to the appropriate development teams for review and consideration in a future release.
Table of Contents
Chapter 1. Introduction to JDA Allocation ....................................................................... 1
Allocation Database Setup .......................................................................................... 1
Allocation Administration ............................................................................................ 1
Software implementation advisement ........................................................................... 1
What if I need help? ................................................................................................... 1
Chapter 2. Introduction to Database Setup ..................................................................... 3

Assumed knowledge................................................................................................... 3
JDA Allocation database tables..................................................................................... 3
Interfacing to JDA Allocation database tables ........................................................ 3
System tables .................................................................................................. 3
User tables ...................................................................................................... 4
Input and output ....................................................................................................... 4
Input .............................................................................................................. 4
Output ............................................................................................................ 4
Allocation database .................................................................................................... 5
Set up the Allocation database ............................................................................ 5
Set up the Allocation database using EKB product and location structure ................... 6
Set up the Allocation database using Assortment product and location structure......... 7
Backup and recovery ......................................................................................... 7
Rollback segments ............................................................................................ 8
System requirements ................................................................................................. 8
Estimate the size of your database ...................................................................... 8
Limitations................................................................................................................ 9
Dates in JDA Allocation ...................................................................................... 9
Table and column names.................................................................................... 9
Number datatype precisions ............................................................................. 10
Embedded spaces ........................................................................................... 10
Chapter 3. Implementation decisions ............................................................................ 11

When does an allocation take place?........................................................................... 11
Set up procedures ........................................................................................... 12
What are your product levels? ................................................................................... 12
Set up levels .................................................................................................. 12
On what basis is an allocation performed? ................................................................... 13
Set up data collection ...................................................................................... 13
What information do distributors want? ....................................................................... 13
Set up the information ..................................................................................... 13
How do you uniquely define a collection of merchandise? ............................................... 14
Set up merchandise types ................................................................................ 14
Do you have packs of merchandise? ........................................................................... 14
Set up packs .................................................................................................. 14
Do you have multiples? ............................................................................................ 14
How do you want to restrict merchandise? .................................................................. 15
Set up the information for restrictions ................................................................ 15
How is the merchandise structured? ........................................................................... 15
Set up hierarchies and groups ........................................................................... 16
List Source tables............................................................................................ 16
Non-hierarchical groups ................................................................................... 16
Chapter 4. Install the database tables ........................................................................... 17
Before you start ...................................................................................................... 17
Oracle primary key .......................................................................................... 17
Oracle users ................................................................................................... 18
Run the scripts ............................................................................................... 18
Run scripts using SQL*Plus ....................................................................................... 18
SQL*Plus ....................................................................................................... 18
Create the system tables .......................................................................................... 18
Create the tablespaces (CRETBLSP.SQL) ............................................................ 19
Create the schema (CREADMIN.SQL) ................................................................. 19
Create the Allocation system objects .................................................................. 20
Create the user tables .............................................................................................. 21
Sample scripts ................................................................................................ 21
Methods of creating tables................................................................................ 21
Location of the tables ...................................................................................... 21
Tablespaces ................................................................................................... 21
Table names .................................................................................................. 21
Install the database packages.................................................................................... 27
Database upgrade process ........................................................................................ 27
Verify the database ......................................................................................... 27
Chapter 5. Set up locations ............................................................................................ 28

Populate the Locations table ...................................................................................... 28
Set up the Locations table ......................................................................................... 28
Name the Locations table and its columns ................................................................... 28
Create the required columns ..................................................................................... 29
Location ID .................................................................................................... 29
Location Name ............................................................................................... 29
Available for Allocation flag............................................................................... 29
Warehouse flag............................................................................................... 30
Create additional columns to help distributors .............................................................. 30
Display in WorkSheet ...................................................................................... 30
Global Coordinates .......................................................................................... 31
Set the Main Key for the Locations table ..................................................................... 31
Chapter 6. Set up the WorkList ...................................................................................... 32

The WorkList and its related tables ............................................................................. 32
Set up the WorkList table.......................................................................................... 32
Name the WorkList and its columns ............................................................................ 33
Create the required columns ..................................................................................... 33
Allocation Number ........................................................................................... 33
Allocation User ............................................................................................... 33
WorkList Key .................................................................................................. 34
Auto-Allocation Job Number.............................................................................. 34
Status Code ................................................................................................... 34
Status Description ........................................................................................... 35
Status Change Timestamp ................................................................................ 35
Merchandise Type ........................................................................................... 36
Trouble Code .................................................................................................. 36
Current Activity .............................................................................................. 36
Collect Status ................................................................................................. 36
Collect Status Description................................................................................. 36
Collect Status Timestamp ................................................................................. 37
Collect Rule Info ............................................................................................. 37
Create the optional columns ...................................................................................... 37
Available Quantity ........................................................................................... 37
Default Store Selection .................................................................................... 38
Destination Warehouse .................................................................................... 38
Source Warehouse .......................................................................................... 38
Pack ID ......................................................................................................... 39
Number of Packs Available ............................................................................... 39
Quantity per Pack ........................................................................................... 39
Method Name ................................................................................................. 40
Model Name ................................................................................................... 40
Distribution Sequence ...................................................................................... 40
Data Collect Rule Key ...................................................................................... 40
Score ............................................................................................................ 41
Levels ........................................................................................................... 41
Groups .......................................................................................................... 41
Create additional columns to help distributors .............................................................. 42
Select a WorkList value from a custom drop-down list in the WorkList ............................. 42
Set the key for the WorkList table .............................................................................. 42
Set up merchandise IDs............................................................................................ 42
Where is the merchandise ID used? ................................................................... 43
Set up merchandise types ................................................................................ 43
Merchandise types and Shape tables .................................................................. 43
Bulk merchandise ........................................................................................... 43
Pack merchandise ........................................................................................... 43
Set up Merchandise Shape tables ............................................................................... 44
Define the composition of bulk merchandise........................................................ 44
Define the composition of packs of merchandise .................................................. 44
Merchandise Shape tables for bulk ............................................................................. 44
WorkList key .................................................................................................. 45
Levels ........................................................................................................... 45
Available Quantity ........................................................................................... 45
Merchandise Shape tables for packs ........................................................................... 45
WorkList Key .................................................................................................. 46
Pack ID ......................................................................................................... 46
Number of Packs ............................................................................................. 46
Quantity per Pack ........................................................................................... 46
Levels ........................................................................................................... 46
Preferred Pack ................................................................................................ 47
Set up detail tables .................................................................................................. 47
Set up List Source tables .......................................................................................... 47
Use the Database Setup utility for the WorkList, Shape, and Detail tables ........................ 48
Populate the WorkList tables ..................................................................................... 48
Discrepancies ................................................................................................. 48
Procedures for discrepancies ............................................................................. 48
Release multiple WorkList lines .................................................................................. 49
Release pre-allocated merchandise when goods are received ......................................... 49
Chapter 7. Set up host data collect procedures.............................................................. 51

Data collection system tables .................................................................................... 51
Set up tables to hold collected data ............................................................................ 51
Variable components ....................................................................................... 52
Levels ........................................................................................................... 52
Clean up format tables ............................................................................................. 53
Sample format table ................................................................................................ 53
Style/Color/Size level example .......................................................................... 54
Style level example ......................................................................................... 54
Class level example ......................................................................................... 55
Class level with more than one class example ..................................................... 55
Data collect hierarchy ranges .................................................................................... 56
Set up a data collect level hierarchy range .......................................................... 56
Data collect parameters ............................................................................................ 56
Set up data collect parameters .......................................................................... 56
Collect data ............................................................................................................ 57
Set up custom data collect procedures ............................................................... 57
XML data collect example ................................................................................. 60
Report errors from the data collect process ......................................................... 62
Data Collects tile on the Administrator Dashboard ........................................................ 62
Monitor data collect processes .......................................................................... 62
View data collect events ................................................................................... 62
Use the built-in data collect for performance data ......................................................... 62
Like Store Data Collect ............................................................................................. 63
Chapter 8. Set up Planning data collect ......................................................................... 64

Use EP or AP data from EKB ...................................................................................... 64
Format EKB product member IDs in JDA Allocation ....................................................... 64
Maintain the EKB structure context for Allocation .......................................................... 66
Populate plan data from other sources ........................................................................ 66
User populated plan data at multiple levels ......................................................... 67
Maintenance of plan staging area ...................................................................... 67
Chapter 9. Set up results collection procedures ............................................................. 68

Results collection tables ............................................................................................ 68
Collect results ......................................................................................................... 68
Delete results.......................................................................................................... 69
Chapter 10. Set up Store Grading .................................................................................. 70

Create the store grading table ................................................................................... 70
Create the columns in the store grading table .............................................................. 70
Location ID .................................................................................................... 70
Grade ............................................................................................................ 70
Time Period .................................................................................................... 71
Merchandise Information .................................................................................. 71
Set the Main Key for the GRADE table......................................................................... 71
Use the Database Setup utility for the GRADE table ...................................................... 71
Set up the GRADE table using Database Setup .................................................... 71
Chapter 11. Set up Currently Allocated Quantities ......................................................... 73

Create the CAQ table ............................................................................................... 73
Create the columns in the CAQ table .......................................................................... 73
Location ID .................................................................................................... 74
Groups .......................................................................................................... 74
Levels ........................................................................................................... 74
Quantity Allocated ........................................................................................... 74
WorkList Columns ........................................................................................... 75
Unique Key .................................................................................................... 75
Set the Main Key for the CAQ table ............................................................................ 75
Use the Database Setup utility for the CAQ table .......................................................... 75
Set up the CAQ table using Database Setup ........................................................ 75
Maintain CAQ .......................................................................................................... 76
Decrement values in the CAQ table .................................................................... 76
Rebuild the CAQ table ...................................................................................... 76
Rebuild the CAQ repository ............................................................................... 77
Chapter 12. Set up Model Stock ..................................................................................... 78

Set up for model stock ............................................................................................. 78
Models in the WorkList ............................................................................................. 79
Use model data ....................................................................................................... 80
Chapter 13. Set up Allocation Scoring............................................................................ 81

Technical details ...................................................................................................... 81
Allocation score color gradient ................................................................................... 81
Set up Allocation Scoring .......................................................................................... 81
Add custom scoring rules .......................................................................................... 82
Chapter 14. Set up Internal Grading .............................................................................. 83
Chapter 15. Set up Auto-Allocation Server .................................................................... 84

Set up the Auto-Allocation Server Windows service ....................................................... 84
Set up the Auto-Allocation Server login ....................................................................... 84
Stop the Auto-Allocation Server ................................................................................. 84
Specify global server configuration items .................................................................... 85
Set up the logging level for an Auto-Allocation Server ................................................... 85
Suspend and resume Auto-Allocation jobs ................................................................... 86
Chapter 16. Use the Database Setup utility ................................................................... 87

Before you start ...................................................................................................... 87
Configure the database connection criteria .................................................................. 87
Client Login ............................................................................................................ 88
Command line login ................................................................................................. 88
Support Logging Levels and other options ................................................................... 89
SQL Trace ...................................................................................................... 89
Setup procedure ...................................................................................................... 89
Set up the database ........................................................................................ 89
Start the Database Setup utility ................................................................................. 90
Jump to steps ................................................................................................. 90
Database setup files ................................................................................................. 91
Step 1: Enter the table names ................................................................................... 91
Enter a new table name ................................................................................... 91
Edit a table .................................................................................................... 92
Remove a table name ...................................................................................... 92
Step 2: Enter the dimension names ............................................................................ 92
Change the display name of a dimension ............................................................ 92
Step 3: Define the groups ......................................................................................... 93
Define a new group ......................................................................................... 93
Edit a group ................................................................................................... 93
Remove a group ............................................................................................. 93
Step 4: Define the hierarchies ................................................................................... 94
Create a new hierarchy .................................................................................... 94
Rename a hierarchy ........................................................................................ 94
Remove a hierarchy ........................................................................................ 94
Edit a hierarchy .............................................................................................. 94
Step 5: Enter the column information ......................................................................... 95
Edit the column information .............................................................................. 95
Step 6: Define the levels .......................................................................................... 96
Add a new level .............................................................................................. 96
Edit a level ..................................................................................................... 96
Remove a level ............................................................................................... 96
Step 7: Set up data collect parameters ....................................................................... 96
Add a new parameter ...................................................................................... 97
Edit a parameter ............................................................................................. 97
Remove a parameter ....................................................................................... 97
Step 8: Set up hierarchy ranges and associations ......................................................... 97
Add a new range ............................................................................................. 98
Edit a range ................................................................................................... 98
Remove a range ............................................................................................. 98
Change associated groups ................................................................................ 99
Step 9: Set up column mappings ............................................................................... 99
Map required and optional columns.................................................................. 100
Set the Main Key information .......................................................................... 100
Map columns to WorkList columns ................................................................... 101
Step 10: Set up merchandise types .......................................................................... 101
Add a new merchandise type .......................................................................... 102
Build the Unique Merchandise ID ..................................................................... 102
Build the Unique Pack ID ................................................................................ 102
Remove a merchandise type ........................................................................... 103
Set the Unique Merchandise/Pack ID column separator ....................................... 103
Step 11: Set the JDA Allocation system parameters .................................................... 103
Update the database .............................................................................................. 103
Set up product location restrictions by source warehouse ............................................ 104
Set up like store support ......................................................................................... 104
Chapter 17. Table definitions ....................................................................................... 105

Queue tables ........................................................................................................ 105
QUEUE_OUT ................................................................................................. 105
QUEUE_IN ................................................................................................... 106
Results tables ....................................................................................................... 107
RESULTS_HEADER Table ................................................................................ 107
RESULTS_DETAIL table .................................................................................. 108
RESULTS_STATISTICS table ........................................................................... 109
NEED_DETAIL table ....................................................................................... 110
Data collect tables ................................................................................................. 111
DC_FORMAT_HEADER table ............................................................................ 111
DC_RULE_HEADER table ................................................................................ 111
DC_RULE_DETAIL table ................................................................................. 112
RTMM_GROUPS table..................................................................................... 113
Plan tables............................................................................................................ 114
PLAN_STAGING table .................................................................................... 114
PLAN_TIME_ORDER table ............................................................................... 115
Chapter 18. Example tables ......................................................................................... 116

WorkList table ....................................................................................................... 116
Structure of the WorkList table ....................................................................... 116
Key information for the WorkList table ............................................................. 117
Mappings for the WorkList table ...................................................................... 118
Groups for the WorkList table ......................................................................... 118
Additional columns in the WorkList table........................................................... 119
Merchandise Shape tables ....................................................................................... 119
Structure of WLBULK ..................................................................................... 120
Key information for WLBULK ........................................................................... 120
Mappings for WLBULK .................................................................................... 120
Merchandise type for WLBULK......................................................................... 121
Structure of WLPACK ..................................................................................... 121
Key information for WLPACK ........................................................................... 121
Mappings for WLPACK .................................................................................... 122
Merchandise type for WLPACK......................................................................... 122
Detail tables ......................................................................................................... 122
Structure of WORKLIST_DETAIL ...................................................................... 123
Key information for WORKLIST_DETAIL ............................................................ 123
Main key mappings for WORKLIST_DETAIL ....................................................... 123
Structure of CLASS_DETAIL ............................................................................ 123
Key information for CLASS_DETAIL.................................................................. 124
Primary key mappings for CLASS_DETAIL ......................................................... 124
Chapter 19. Database tuning ....................................................................................... 125

Format table indexes .............................................................................................. 125
Staging table indexes ............................................................................................. 125
DCAQ/CAQ index ................................................................................................... 126
WorkList table indexes ........................................................................................... 127
Locations table indexes........................................................................................... 127
Grading indexes .................................................................................................... 128
Chapter 20. Database maintenance ............................................................................. 129
Chapter 21. Allocation system administration ............................................................. 130

Lock users out of the database ................................................................................ 130
Allow users to log in to the database ................................................................ 130
Maintenance tile on Administrator Dashboard ............................................................ 130
Status & Report tile on Administrator Dashboard ........................................................ 130
Chapter 22. Maintain users .......................................................................................... 132

Users tile on the Administrator Dashboard ................................................................. 132
Manage the User List .............................................................................................. 132
Open the User List ........................................................................................ 132
Add a user ................................................................................................... 132
Delete a user................................................................................................ 133
Unlock a single user ...................................................................................... 134
Change privileges for a user ........................................................................... 134
Log users out of the system............................................................................ 134
Select the locations for a user ................................................................................. 135
Set a location restriction for a user .................................................................. 135
Create a filter ............................................................................................... 135
Check the validity of a filter ............................................................................ 135
Change the columns a user can view in the WorkSheet ....................................... 136
Select the products for a user .................................................................................. 136
Set a product restriction for a user .................................................................. 136
Create a filter ............................................................................................... 136
Change the columns a user can view in the WorkList .......................................... 137
Sort the WorkList data ................................................................................... 137
Chapter 23. Maintain locations .................................................................................... 138
Locations tile on the Administrator Dashboard ........................................................... 138
Manage the Location List ........................................................................................ 138
Open the Location List ................................................................................... 139
Add a location .............................................................................................. 139
Delete a location ........................................................................................... 139
Make a location temporarily unavailable for allocation ........................................ 139
Determine whether a location has pending allocations ........................................ 139
Select the locations for a product ............................................................................. 140
Product location restriction hierarchy ranges ..................................................... 140
Product location restrictions and default warehouses .......................................... 141
Merchandise from different source warehouses .................................................. 141
Swing stores ................................................................................................ 141
Maintain product location restrictions ............................................................... 141
Select a list of locations .......................................................................................... 141
Create a new selection ................................................................................... 141
Sort the locations .......................................................................................... 142
Create a filter ............................................................................................... 142
Save a store selection.................................................................................... 142
Save a store selection with a new name ........................................................... 142
Edit a store selection ..................................................................................... 143
Delete a store selection.................................................................................. 143
Filters for store selections .............................................................................. 143
Chapter 24. Maintain variables .................................................................................... 145

Base variables ....................................................................................................... 145
Maintain the base variable list for plan data ............................................................... 145
Add a variable to the base variable list ............................................................. 145
Change a variable in the base variable list ........................................................ 146
Remove a variable from the base variable list ................................................... 146
Create, edit, and delete derived variables .................................................................. 146
Map an On Hand variable ............................................................................... 146
Map a Priority Order variable .......................................................................... 147
Revalidate a variable ..................................................................................... 147
Absolute and relative variables ................................................................................ 147
Relative variables .......................................................................................... 148
Absolute variables ......................................................................................... 148
Variable operators and functions .............................................................................. 148
Syntax conventions ....................................................................................... 149
Simple arithmetic operators ............................................................................ 149
Conditional statements .................................................................................. 149
Logical operators .......................................................................................... 149
Comparisons ................................................................................................ 149
Functions ..................................................................................................... 150
Vertical functions .......................................................................................... 150
Functions for other tables ............................................................................... 151
Additional functions ....................................................................................... 152
Chapter 25. Set up data collect .................................................................................... 153

Set up data collect levels ........................................................................................ 153
Data collect hierarchy ranges .......................................................................... 153
Create a data collect level .............................................................................. 154
Delete a data collect level .............................................................................. 154
Chapter 26. Administrator delete functions ................................................................. 155
Remove the results set name .................................................................................. 155
Results purge ............................................................................................... 155
Like Store Rules Purge ........................................................................................... 156
Delete a method .................................................................................................... 156
Delete a WorkList view ........................................................................................... 156
Delete a named data collect rule .............................................................................. 157
Chapter 27. Create and maintain Auto-Allocation schedules........................................ 158

Configuration considerations ................................................................................... 158
Auto-Allocation process .......................................................................................... 158
Requirements........................................................................................................ 159
WorkList mappings ................................................................................................ 159
Auto-Allocation tile on the Administrator Dashboard.................................................... 159
Schedule Auto-Allocation ........................................................................................ 159
Schedule table .............................................................................................. 160
Define the order of processing for the schedule records ...................................... 162
Schedule process .......................................................................................... 162
Run Auto-Allocation ............................................................................................... 164
Manually ...................................................................................................... 164
By command line .......................................................................................... 164
Schedule Auto-Allocation with a Windows scheduler ........................................... 164
Save the text buffer ............................................................................................... 165
Log file features .................................................................................................... 165
Processing assumptions .......................................................................................... 165
Reporting ............................................................................................................. 166
Maintain the Auto-Allocation report data ................................................................... 166
Suspend and resume Auto-Allocation processing ........................................................ 167
Monitor process ..................................................................................................... 167
Clean up .............................................................................................................. 167
Review results and release allocations ...................................................................... 168
Chapter 28. Build like store rules ................................................................................ 169

Select variables for use in like store support .............................................................. 169
Patterns ...................................................................................................... 169
Build like store rules .............................................................................................. 169
Edit a like store rule ...................................................................................... 170
Delete a like store rule ................................................................................... 170
Copy a like store rule to a new Apply To Store................................................... 171
Introduction to JDA Allocation
Chapter 1. Introduction to JDA Allocation

JDA Allocation (Allocation or AL) is a merchandise distribution system. It uses a client-server
environment where the application runs on PCs that communicate with a central Oracle database.
The application takes information about the merchandise from your orders, advanced shipping notices,
receipts, and reserve stock, and distributes the merchandise according to the needs of each location.
Distributors can customize the distribution of merchandise according to their judgment.
Allocation allows you to view your merchandise to be distributed, select merchandise to distribute, and
distribute that merchandise to the locations of your choice, based on information from your transaction
management system or JDA planning system.
The application produces a set of results you can feed to your transaction management system to send
the merchandise to the appropriate locations.
This guide covers the administrative functions in Allocation Database Setup and Allocation
Administration application utilities.
Allocation Database Setup

Allocation Database Setup allows you to configure the database for use with JDA Allocation. You
identify tables and required columns, establish the product hierarchy, and specify configuration
parameters.
Your Oracle Database Administrator (DBA) will have created the tables according to your
implementation design. You will have also established processes to interface data to these tables from
your host system and to return the results of the allocation.
Allocation Administration
Allocation Administration allows you to manage users, create restrictions, create and maintain Auto-
Allocation schedules, maintain and validate the variables used by the distributors, build data collect
levels and like store rules, and delete methods, store selections, WorkList views, and results.
The system is set up according to your implementation design. This design enables the application to
work using your business processes and terminology.
Software implementation advisement

IMPORTANT: Although JDA licenses packaged software, JDA solutions offer complex capability and
scalability requiring trained, experienced personnel to install and implement. Even robust
documentation is no substitute for JDA certified consultants. JDA implementation experience in
addition to training, both on the JDA solutions and on their underlying technologies as defined in JDA
solution documentation, are the keys to success. Given JDA’s mission to ensure customers achieve
optimal results, JDA strongly recommends you use certified consultants who understand JDA
applications and delivery methodologies. Without this guidance, you can expect to experience
implementation challenges that cannot be addressed effectively under your JDA support agreement. In
these circumstances, JDA Support Services will refer you to the Consulting Services team who can be
engaged to answer questions and guide the implementation.
What if I need help?

If you have a question about a JDA product, look in the online documentation or the JDA CD. If you
cannot find the answer, please contact JDA Support Services or your local agent or distributor. You can
find contact information on their website (http://www.jdauser.com).
JDA Allocation Administrator Guide 1

© 2005-2015 JDA Software Group, Inc.- Confidential
Introduction to JDA Allocation
For more information on setting your Allocation logging level for support purposes, see "Support
Logging Levels and other options" (on page 89).

Introduction to Database Setup
Chapter 2. Introduction to Database Setup

The next sections of this document explain how to set up a database to work with JDA Allocation. They
contain instructions for creating the basic system tables that are the core of the Allocation database,
information about the tables you have to create, and the requirements for each of those tables. They
describe how to set up the application to read the tables you create.
These sections also describe the processes necessary for setting up procedures to provide data from
your transaction management system for Allocation to use as the basis of its calculations. They
describe the format of the results output by the application that must be returned to your transaction
management system to be put into action.
Assumed knowledge
You should have a working knowledge of the following items.
 Currently supported Microsoft Windows operating system
 Oracle
 Concepts of retail allocation
JDA Allocation database tables

The Oracle database is the heart of JDA Allocation. It holds all user, merchandise, and location
information for the system.
Two types of tables are on the database: system tables and user tables.
Interfacing to JDA Allocation database tables

Custom interface code provided by implementation teams is not part of the base JDA Allocation
application. It is used as an interface for customer data to and from JDA Allocation. The ownership of
the code belongs to the customer, who is free to maintain the code with modifications as necessary to
support their business. The implementation code is not supported by the JDA Global Customer Services
or JDA Product Development teams.
Note that invalid data that is introduced or modified by the interface code can cause unexpected
behavior in JDA Allocation. However, any application behavior caused by invalid interface data is the
responsibility of the customer.
Note also that a JDA Allocation database consists both of system objects and implementation- specific
"user" objects. There are a few system objects that support direct interfacing, and those objects are
documented in this JDA Allocation Administrator Guide. Although modification or insertion of data in
other system tables is possible, it is NOT recommended or documented. These tables are proprietary
and JDA is at liberty to change them without client notification.
If a client modifies the system tables or the data contained within those tables, and JDA spends time
investigating a problem because of it, the client is liable for the costs associated with such work.
System tables
The system tables (the tables used internally by the application) are loaded onto the database and
partially populated by the installation process. To install these tables, you must run Oracle scripts to
create the system tables and populate the bare minimum of the database.

Among other things, the system tables contain information about your user tables. You run the
Database Setup utility after you have created your user tables, to add information to the system tables
about your tables, and to create hierarchies, groups, ranges, and so on.
User tables
You must create tables to hold all merchandise information that you want the application to use, such
as information on locations, planned and actual data that you want to use as the basis for your
allocation, and the products that you are allocating.
These tables reflect the way your organization works, so you must inform the application of the names
and contents of these tables, using the Database Setup utility. In some cases, you can use existing
Oracle tables that contain the necessary information.
Input and output

You provide information about the merchandise and the basis on which the allocation is to be carried
out. After the allocation is complete, the application produces results in a table that you use to update
your transaction management system and send the merchandise out to the appropriate locations.
Input
For the application to distribute merchandise, it needs the following information.
 Merchandise information
 Actual data, planned data, or both actual and planned data
You must set up procedures to write merchandise information to your JDA Allocation user tables
whenever there is merchandise to be allocated. These tables are the WorkList and Merchandise Shape
tables.
If you want to use planned data, it can be obtained from the JDA Enterprise Knowledge Base (EKB)
and stored in staging tables for use in JDA Allocation. If you want to use actual data, or a combination
of planned and actual data, you must set up procedures to read data requests, and provide data from
your transaction management system in a form that JDA Allocation can understand. This process is
known as data collect.
JDA Allocation also has an option of collecting data from a structured data staging area. This option
allows your interface code to maintain historical data in a staging area within the Allocation database,
instead of dynamically obtaining the data at the users' request. JDA Allocation automatically does the
collection of data from the staging area to the format table for use in calculating store Need.
If you choose to stage your data, your data is already in the correct format for Need generation, and
the necessary data can be collected very quickly. On the other hand, staged data needs to be loaded,
needs the appropriate amount of storage space, and needs to be maintained. Consult with your
database administrator for advice on the option that is appropriate for your business.
Note: JDA Allocation does not support leading or trailing spaces in any text data.
Output
The results of the allocation are written to the results tables. These tables contain information about
how much merchandise of each type is to be sent to each location. You set up procedures to read this
information from the tables and pass it to your transaction management system, so the appropriate
quantities of the right sizes and colors of the merchandise are sent to each location.

Allocation database
Set up the Allocation database
This section provides an overview of the steps involved in setting up the Allocation database. The steps
are covered in detail later in this manual.
To set up the central Allocation database, carry out the following procedures.
1. Check your system and network requirements. See the JDA Allocation Installation Guide
(INSTALL.PDF) for more information.
2. Install Oracle on your database server machine. See the Oracle documentation for details.
3. Install the Oracle Network client on every PC that uses JDA Allocation. Configure an Oracle Local
Net Service Name connecting each PC to the database that holds the JDA Allocation schema, which
is required for creating and updating the Allocation database using SQL*Plus.
4. Install Oracle SQL*Plus on the PC you are using to install JDA Allocation.
5. Install the JDA Allocation software onto every machine that uses the application.
6. Working with your distributors, review the "Implementation decisions" (on page 11), and decide
how you want the application to work.
7. Create the system tables on the Oracle database. See "Install the database tables" (on page 17)
for details. You need the help of an Oracle Database Administrator (DBA) for the initial stages of
creating the system tables.
8. Install the required PL/SQL database packages. See "Install the database tables" (on page 17) for
details.
9. Create the Locations table, which contains a list of all stores and warehouses to which you want to
send merchandise. See "Set up locations" (on page 28) for details. Note: See the EKB Integration
note following these steps.
10. Create the WorkList and Merchandise Shape tables, according to the decisions made by the
distributors. You must create the following tables.
 WorkList table
 Merchandise Shape tables
 Detail tables
 List Source tables Note: See the EKB Integration note following these steps.
See "Set up the WorkList" (on page 32) for details.
11. Set up procedures to write information to the WorkList and Merchandise Shape tables from your
transaction management system.
12. Set up procedures to provide the performance data that the application uses as a basis for the
allocation of merchandise. You must do the following.
 Create data collect format tables.
 Set up data collect procedures.
 Set up data collect parameters and data collect staging tables.
See "Set up host data collect procedures" (on page 51) for details.

13. Set up procedures to read the results that JDA Allocation produces, as follows:
 Set up procedures to collect results and update your transaction management system.
 Set up procedures to delete results and corresponding WorkList and Shape table information.
See "Set up results collection procedures" (on page 68) for details.
14. Optionally, set up a Store Grading table, which contains grades for each store by product and time
period. See "Set up store grading" (on page 70) for details.
15. Optionally, create a Currently Allocated Quantities (CAQ) table that contains a record of all
allocations that have not been updated in your transaction management system. See "Set up
currently allocated quantities" (on page 73) for details.
16. If intending to create a database that loads and maintains product and location structure directly
from EKB, you must link the allocation database to EKB before continuing this process.
For other databases, now run Run Allocation Database Setup from the Start menu. Configure your
connection criteria and save to a connection file.
17. Proceed with configuring the database using the Database Setup utility, as follows:
a. Enter the names for the tables you have created.
b. Enter the dimension names.
c. Define the groups.
d. Define the hierarchies.
e. Enter the column information.
f. Define the levels.
g. Set up the data collect parameters.
h. Set up the hierarchy ranges and associations.
i. Set up the column mappings.
j. Set up the merchandise types.
k. Set up the system parameters.
See "Use the Database Setup utility" (on page 87) for details.
EKB Integration Note: If the Allocation database structure is created and maintained from an EKB
database, some of these steps should not be taken, as the table structure creation and corresponding
data population and maintenance for the location and product lists are performed by the system.
Set up the Allocation database using EKB product and location

structure
As noted in the previous section, there are a few important differences between an Allocation database
that depends on Enterprise Knowledge Base (EKB) for its product and location structure and one that
does not. When integrating with EKB for product and location structure information, some parts of the
database creation use data obtained from EKB via a structure context.
That structure context must be created prior to building the Allocation database. It must identify the
subcube set for all EP and AP measures that will be used by Allocation. This structure context will be
built when Allocation is configured to use it. After that, it must be rebuilt whenever structure changes
are made to EKB. See "Maintain the EKB Structure Context for Allocation" (on page 66).

To set up the central Allocation database with a direct connection to EKB for product and location
structure information, perform the following procedure.
1. Run steps 1-15 in "Set up the Allocation Database" (on page 5).
2. Ensure that your EP Mid-Tier application server is running and the TNS entry used by the EP Mid-
Tier to connect to the EKB database exists not only on the application server machine, but also on
the AL database server.
3. Run Allocation Administration from the Start menu. Configure your connection criteria and save to
a connection file.
4. Select Maintain > EKB Information...
5. Enter the Machine Name and Port number for the EP Mid-Tier Application server, then select
Connect to EP Mid-Tier.
6. Select the structure context for Allocation. This will populate the hierarchy information.
7. Select the unique product level from the Product Hierarchy. This corresponds to the UMID level or
style level in Allocation Database Setup. Attributes below this level will be used as WorkSheet
levels, such as color or size.
8. Select the Product Groups, Data Collect Levels & Attribute Levels tab. Determine the order of
the unique product attributes to be used as WorkSheet levels in Allocation. Order the attributes
using the move up/down buttons. Note that once the product hierarchy and levels are established
in a database, they cannot be changed.
9. Select OK to close the EKB Information… dialog box. This step will create the appropriate
hierarchies, locations list, and product lists in the Allocation database.
10. Select Maintain > Location List. If reserve stock locations exist in the EKB structure context,
then the warehouse flag will have to be manually selected to identify them as reserve locations in
Allocation. Otherwise, add reserve stock warehouses to the location list and set the warehouse flag
and the avail_for_alloc flag. Any records manually added to the location list will not be updated by
EKB when Allocation loads new details from the structure context, although other location
attributes will be.
11. Exit Allocation Administration and run Allocation Database Setup from the Start menu.
12. Continue with step 17 in "Set up the Allocation Database" (on page 5) above in order to configure
the WorkList, shape detail tables, format tables, etc.
Set up the Allocation database using Assortment product and

location structure
If using Assortment as the source for product and location structure, the steps are nearly the same as
when using EKB for product and location structure. The biggest difference is that the Allocation
database connects directly to the Assortment database instead of using a mid-tier application. Follow
the steps in the previous section, using the Creall_RDM script instead of the Creall_EKB script, and
then configure the Assortment connection in Allocation Administration using the Maintain >
Assortment Integrator menu option.
Backup and recovery

Oracle provides sophisticated backup and recovery facilities, which can help prevent or minimize data
loss in the event of system or communications failures. You are encouraged to use these facilities, and
put procedures in place to ensure the safe backup and recovery of all vital information. See your
Oracle documentation or consult your Oracle DBA for details.

Rollback segments
Oracle uses a special database object called a "rollback segment" to store information it may need to
undo. For example, if a transaction fails, Oracle can use the data in the rollback segment to restore the
database to its state prior to the transaction.
You must ensure the rollback segments are of sufficient size to deal with the volume of data produced
by the application. See your Oracle documentation or consult your Oracle DBA for details.
System requirements
JDA Allocation uses a central Oracle database and client Windows-based PCs. See the JDA Allocation
Installation Guide (INSTALL.PDF) for details on system requirements.
Estimate the size of your database

This section provides a very rough guide to estimating the scale of your database and storage
requirements; for a more accurate estimate, consult your JDA implementation team.
The amount of space your operational Allocation database requires is dependent entirely on the level
of detail at which you work. You must ensure that the application has sufficient space on the Oracle
database to store all data, by increasing the size of the AAMDATA and AAMINDEX tablespaces. See the
Oracle documentation for details on increasing tablespaces.
WorkList tables
The WorkList tables take up space, dependent on the size of the WorkList table and the amount of
information stored there.
Add all values based on the datatype space requirements for each column to produce the average
space requirements for a WorkList line.
Additional information stored in Shape tables has to be added. There are often several lines in a Shape
table for each WorkList line. For example, if you have three colors and three sizes, there are nine lines
in a Shape table for the relevant WorkList line, assuming there is merchandise for each combination of
levels.
To determine required space:
1. Find the average number of combinations of levels.
2. Multiply this value by the number of bytes in an average Shape table line.
3. Add this value to the average space requirements for a WorkList line to produce the average
WorkList space requirements per record.
4. Multiply this value by the average number of collections of merchandise you intend to have in the
WorkList at any one time. This calculation produces the average amount of space you need to store
the WorkList.
Results
Results require an average of 100 bytes per record. Multiply this value by the combinations of levels at
which you allocate; average number of sizes by average number of colors, and so on. This calculation
produces the storage requirements for a single location for a single WorkList line.
Multiply this value by the average number of locations in an allocation. For example, if you have 200
locations, but usually allocate a single collection of merchandise to an average of 100 locations at a
time, multiply the value by 100.

Multiply this value by the number of WorkList lines allocated in a single day. This value is obtained by
multiplying the number of distributors by the number of collections of merchandise each distributor
allocates in a single day. Multiply this value by the number of days you intend to keep results on the
database.
Caution: If you allocate at a very low level (style/color/size/width, for example) to many locations,
you will find that stored results require a very large amount of space. You must make sure that results
are put into action and removed from the database as soon as possible after they have been released.
You may want to keep the number of days to a minimum that the merchandise is kept on the
database.
Staging tables
The staging tables hold staged performance data for use by the built-in data collect procedure. If using
the built-in data collect process, determine how much space each record of the staging areas requires
and multiply by the number of records expected in the staging areas. Staging areas for some levels of
data collect can be views, which do not have storage requirements. Note that significant additional
space may be required for maintenance of data in the staging area.
Format tables
The format tables hold collected data; their size depends on how many levels and variables you use.
These tables could become very large in a very short time; you must have procedures to clear them
out as soon as data is no longer needed.
Currently Allocated Quantities

If you implement Currently Allocated Quantities, this table requires a considerable amount of space.
Like the Results table, the space occupied depends on the combination of levels and number of
locations; every combination of merchandise that is allocated is stored in the CAQ_Host table for every
location to which the merchandise is allocated.
System tables
The system tables, including the Location and User list tables, and saved views, variables, and
methods should take up no more than the 20 MB set up by the installation procedure.
Indexes
If you are dealing with a large amount of data, you must get the help of an Oracle expert to optimize
your database. This process involves the addition of indexes to your database to speed up data access
times, which increases the size of your database.
Limitations
The following database limitations should be noted.
Dates in JDA Allocation

Dates in Oracle can be stored with values from 1 January 4712 BC to 31 December 4712 AD. However,
JDA Allocation can only use dates within the Microsoft limits of 1 January 1970 and 5 February 2036. If
data such as for product or location attributes consists of dates that fall outside of this range, then the
data should be converted into text values and stored in a text field, for example, VARCHAR2.
Table and column names

Oracle allows great flexibility with table and column names. For JDA Allocation, you must use
alphanumeric table and column names with no spaces, primes, or mixed case.

In addition to Oracle's restrictions on names for columns, no column names can be an exact match
with any of the application's operators. This restriction also applies to column descriptions.
Number datatype precisions

When passing values to JDA Allocation, a maximum precision of (28) for all Numeric datatypes is
strictly enforced by the .NET Framework. If a numeric datatype contains greater than 28 significant
digits, an error is displayed in JDA Allocation depending on where the value's column exists. AL
truncates numeric values to 15 significant digits. It is suggested that all Number datatypes have a
precision defined of (15).
Embedded spaces
JDA Allocation does not support leading, embedded, or trailing spaces in any group or level member
numbers or codes. For example, a style number cannot contain embedded spaces. In addition, any
data values with leading or trailing spaces are not supported and may cause unexpected application
behavior.

Implementation decisions
Chapter 3. Implementation decisions

JDA Allocation can be set up to work the way your retail organization works. You must make a variety
of decisions before setting up the system. You set up your Allocation database and host system
procedures according to these decisions before you install the PC software.
The system administrator sets up the application according to the information provided by the
distributors. The system should reflect the way your organization works, and should consider the
needs of the distributors. Any information that your existing system holds can be passed through the
application to allow the distributors to use it when allocating merchandise.
You must decide on the following items.
 "When does an allocation take place?" (on page 11)
 "What are your product levels?" (on page 12)
 "On what basis is an allocation performed?" (on page 13)
 "What information do distributors want?" (on page 13)
 "How do you uniquely define a collection of merchandise?" (on page 14)
 "Do you have packs of merchandise?" (on page 14)
 "Do you have multiples?" (on page 14)
 "How do you want to restrict merchandise?" (on page 15)
 "How is the merchandise structured?" (on page 15)
After you have obtained this information from the distributors, set up the database accordingly.
When does an allocation take place?

You have to decide when the allocation process takes place. Merchandise can be allocated at any stage
in the process. For example:
 After merchandise is received in a distribution center. If you allocate merchandise after it

has been received and counted in a distribution center, you can be more sure that you actually
have that merchandise to allocate. This option is safe, if you do not always receive what you
ordered.
 Close to receiving. You can allocate merchandise shortly before it arrives in a distribution center
or shortly before it is counted, for example. The allocation can be triggered by an Advance Ship
Notice (ASN), the packing slip, the receipt of the merchandise at the receiving dock, or a fixed
number of days before the merchandise is due to be received.
 When the vendor confirms that the merchandise is ready to ship. If your vendor sends
merchandise directly to your locations, you can allocate the merchandise as soon as your vendor is
ready to ship. This enables you to use the most up-to-date information about the Need of each
location, and send the results of the allocation directly to the vendor.
 When allocating merchandise from reserve stock. If you have merchandise kept in a
warehouse location, you can allocate it at any time.

Set up procedures
You have to set up procedures to write information from your transaction management system to the
WorkList. These procedures are triggered by one or more of the conditions described in the previous
section.
For example, you could set up procedures to send information to Allocation ten days before the
shipment is due (close to receiving), while also having special procedures for allocating from reserve
stock.
You could have a mixture of vendor multi-drop shipments for some products and shipments directly
from your distribution center for other products.
All procedures can be triggered by particular documents in your existing transaction management
system; for example, dock receipts or purchase order receipts. If you include a document type in the
WorkList display, you can allow your distributors to differentiate between the types of allocation.
The information from these documents (for example, the style, number of units, department, class,
and so on) is passed to the WorkList, and the distributor can allocate the merchandise.
What are your product levels?

The merchandise is allocated based on the particular features of your purchase order management and
receiving systems. The levels are the color, sizes, and dimensions of your merchandise, as defined in
your host system.
You can have as many as six levels of merchandise, which can have any names you choose.
Individual types of merchandise may be allocated to different levels. You do not have to use all levels
for each style of merchandise. You need to determine the maximum level of detail to which
merchandise is allocated, and decide on the names of the levels, depending on the information you can
obtain from your operational database.
Set up levels
To set up levels, you need to provide the names of the levels. See "Step 6: Define the levels" (on page
96) for details. You also need to create Merchandise Shape tables, tables that describe the
composition of a collection of merchandise. These tables contain information about the colors, sizes,
and other levels. See "Set up Merchandise Shape tables" (on page 44) for details.
The tables describe the quantities for each combination of levels; for example, how many large white
shirts, how many large red shirts, and so on. You can have several Merchandise Shape tables; your
system has to specify which one to use for each collection of merchandise.
When setting up the WorkList level, consider that:
 Product Location Restrictions cannot be set up below the WorkList level.
 The UMID (level 0) cannot be below the WorkList level. It must be at the WorkList level. (A pack
cannot contain more than one level 0, because a pack cannot include multiple WorkList lines.)
 Like all WorkSheet levels, the UMID (level 0) must use a text data type. If it consists of
concatenated fields to make the value unique, then it will automatically be treated as text;
however, if it consists of only one WorkList field, such as STYLE_NUMBER, then that field must be a
text data type on the WorkList.
 Criteria for Grading cannot be below the WorkList level.
 A source distribution center (DC) cannot be below the WorkList level. Each WorkList can have only
one source DC and one destination DC.

On what basis is an allocation performed?

You must decide the sort of information the application uses to determine the distribution of
merchandise. The application distributes merchandise based on the Need of each location. Need can be
based on performance data from your transaction management system, data from other systems,
planned data from your JDA planning system, or a combination of these.
With performance data, the application distributes merchandise according to the historical or current
performance data. With information from your planning system, merchandise is distributed according
to the planned figures for each location.
Data is collected and passed to the Allocation database so JDA Allocation can consider it when
distributing merchandise. The distributors can select a basis for store Need when allocating, based on
their judgment, but the procedures for collection of data must be set up at the time of installation.
Set up data collection

If you want to use performance data, you set up procedures to read the JDA Allocation request for
data, collect the data from the transaction management system, and write the information back to the
Allocation database in a format that JDA Allocation can understand. Alternatively, you can set up
staging areas and maintain performance data in them. JDA Allocation can read the data collect request
and collect the appropriate data from the staging areas.
What information do distributors want?

JDA Allocation can give distributors the information they need to make their decisions. Each collection
of merchandise is presented to them as a WorkList line; that is, a line of information showing the style
and amounts of merchandise to be allocated, as well as other information. JDA Allocation uses this
information for its own calculations, but the distributors can be given as much information as is
available on your transaction management system.
For example, if the transaction management system can track information about the fabric, the season
for which the merchandise is appropriate, and the advertising event for which the merchandise was
ordered, this information can be passed to the distributors, and it helps them in making their
decisions. They can also use this information to restrict their views of the merchandise.
Information such as the department and class of the merchandise can be presented to the distributors;
this method also allows the system administrator to restrict the access of individual distributors to
particular departments or classes to make the division of work easy to manage.
Set up the information

The information from the transaction management system is written to the WorkList table. This table
lists all individual collections of merchandise on which the distributors work. Design this table in
cooperation with the distributors so it provides all information they are likely to need for their work.
You must also set up procedures that write information to the WorkList table at the appropriate times;
for example, whenever there is merchandise to allocate.

How do you uniquely define a collection of

merchandise?
JDA Allocation needs to know the information that defines each collection of merchandise and makes it
distinct; for example, in your organization, the style number may not define the merchandise uniquely.
The department, class, and style number together may be required to form the unique definition for a
particular type of merchandise. Another retailer may require the department, class, vendor, and style
number. The structure of the Unique Merchandise Identifier (UMID) must be consistent for all
merchandise in JDA Allocation.
You must make sure that the WorkList table (along with the Merchandise Shape tables) contains
enough information to determine the shape of the merchandise and defines the “merchandise type” by
including information such as the department and class.
You decide on the different shapes of merchandise your system deals with (for example, hard goods
with no variations vs. soft goods with colors and sizes) and then you assign a corresponding number to
that shape during Database Setup (Step 10). These shape numbers are known as merchandise types.
Set up merchandise types

Each line in the WorkList table must have a merchandise type associated with it. The merchandise type
must be determined by the interface as the type associated with the merchandise sent by your
Set up the merchandise types using the Database Setup utility. You can have as many merchandise
types as you need. See "Step 10: Set up merchandise types" (on page 101) for details on using the
Database Setup utility to create merchandise types.
Merchandise types can be for bulk or pack merchandise.
Do you have packs of merchandise?

If some or all merchandise you receive is in packs, you must set up JDA Allocation to deal with packs.
For example, you might allocate towels in packs containing 6 bath towels, 6 hand towels, and 6 face
cloths. These packs are received in predefined collections.
If none of your merchandise is allocated in packs, and all of it is allocated in bulk, you do not need to
set up the WorkList to deal with packs.
Pack information must be incorporated into the Allocation database, in addition to the level
information.
Set up packs
To set up packs, you add columns to the WorkList and Merchandise Shape tables that provide
information on the pack ID, number of packs available, and quantity per pack.
You can include all pack columns (pack ID, number of packs available, and quantity per pack) in the
WorkList, or include all columns in a Shape table. You cannot have some pack columns in a Shape
table and some in the WorkList.
You must set up a merchandise type that includes the pack ID in the merchandise ID (UPID).
Do you have multiples?

As of version 2.2.0, multiples are no longer recommended as a valid shape type. The Pack engine
allocates this type of merchandise much more efficiently.

Multiples refers to merchandise that is received and distributed in single SKU packs. Prior to the 2.2.0
release of Advanced Allocation, they were the only packs that could consider Need below the store
level. As of Advanced Allocation 2.2.0, all packs should use a shape type of Pack. Although they have
limited use and constrained functionality, multiples have been maintained for those customers who
used them in releases prior to Advanced Allocation 2.2.0.
How do you want to restrict merchandise?

JDA Allocation can restrict the distribution of merchandise in a number of ways. For example, a
department called stationery could be restricted in the following ways.
 User JSMITH cannot allocate merchandise of department stationery.
 Merchandise of department stationery cannot be allocated to locations that do not stock stationery.
You can have multiple restrictions on merchandise. For example, if you are allocating clothing, you
might want to restrict heavy woolen items from being distributed to locations in southern California; in
this case, you would set a restriction based on the fabric type and location. Restrictions may also be
created by Source Warehouse (Distribution Center). See "Set up product location restrictions by source
warehouse" (on page 104).
Set up the information for restrictions

To allow users and administrators to set up restrictions, add the relevant information to the Allocation
database.
To create restrictions based on the department of merchandise, you would need to set up a group
called Department in the WorkList. To restrict clothing based on fabric and location, you would need to
include information on the fabric type in the WorkList and the region in the Locations table. This setup
would allow the administrators to create restrictions. See "Set a location restriction for a user" (on
page 135) and "Set a product restriction for a user" (on page 136) for details.
You should find out what information the distributors want to use for their restrictions. In general, the
more information you can provide from your transaction management system, the more flexible the
distributors' restrictions can be.
How is the merchandise structured?

You have to decide on the dimensions, hierarchies, and groups that JDA Allocation uses. The product
dimension contains the merchandise and is structured according to hierarchies that contain groups.
Hierarchies define the structure of the merchandise. You can have several hierarchies. For example,
you might have a hierarchy for your product dimension, called Main Hierarchy, that contains the
groups Department, Class, Style, and Color, and another hierarchy, called Planning Hierarchy that
contains the groups Department, Class, and Style.
Main Hierarchy Planning Hierarchy

Department Department
Class Class
Style Style
Color
Width
Department, Class, Style, Color, and Width are groups. Each refers to a column in the WorkList or
Shape tables that you must create to contain information about the merchandise to be allocated.

Hierarchies are used for data collection, and determine the level of data to be collected. JDA Allocation
uses the collected data to calculate the Need of each location. For example, if you collect information
for Class, the application calculates the Need for each class of merchandise for each location.
Hierarchies are used for Product Location Restrictions; you can set up conditions for merchandise
based on the values of members of the hierarchy.
Set up hierarchies and groups

To set up hierarchies and groups, use the Database Setup utility. Before you use the utility, you must
decide the structure of your hierarchies and the groups you need. Some groups may not belong to a
hierarchy and are set up solely to provide lists from which allocators can select a member.
Each group may be one of two types that contain:
 Any values. For example, price point.
 A range of values. For example, department.
List Source tables

If there is a specific list of values associated with a group, you can create a List Source table to hold all
of the values. For example, the list source table DEPTS will hold a list of all possible departments.
When a list source exists, it makes it easier for the distributors to choose from a list instead of having
to type in a member. For example, when a distributor chooses to modify the Department level in a
data collect request, the application displays the list of available departments from which they can
select.
Note: If you have a List Source table, the users are unable to select anything except a member of that
List Source table; therefore, List Source tables must be kept up-to-date.
For groups that correspond to WorkSheet levels, the list source can provide the default order for level
members in the WorkSheet. This is done using a sequence column, which can be identified on Step 3
of Allocation Database Setup. The column can be numeric or text. If present, it is used to order the
members in Multi-Dimensional Views (MDVs) such as the WorkSheet. The application of this ordering is
controlled via the user’s Member Order for Multi-dimensional Views preference setting in the
WorkList.
Non-hierarchical groups
Not all groups must belong to a hierarchy. Groups that do not are called non-hierarchical groups. An
example of a non-hierarchical group is price point. This group does not belong in a hierarchical
structure, but you may want to provide a list of prices from which to choose, so you would create a
group for these purposes.

Install the database tables
Chapter 4. Install the database tables

Load the system tables into the database by running Oracle scripts to create the tables. These scripts
also populate the database with the minimum requirements for the Database Setup utility to
communicate with the database.
Many of these scripts use the JDA_ALLOCATION_SCRIPTS environment variable, which specifies the
location of the scripts. This variable requires that the scripts are run using SQL*Plus from the Windows
machine where Allocation is installed. Do not modify this variable or run the scripts from a different
directory, because the scripts will not work.
There are two options for creating an Allocation database.
 To create a database that is dependent on EKB and has some of its components built and
maintained from an EKB Structure context, execute the provided CREALL_EKB.SQL script.
 To create a standalone Allocation database, execute the CREALL.SQL script instead. Note that
collection of Enterprise and Assortment Planning data from EKB can be performed with either type
of database. Once a database has been created, it cannot be changed to or from EKB dependency,
so confirm the intended implementation before deciding which script to execute.
To ensure these scripts are run in the correct order, the CREALL.SQL script is provided, which lists all
scripts in the order they should be run.
Note: Starting in Oracle 12c, the Allocation schema must reside in a PDB (Pluggable DataBase). If you
are using Oracle 12c or later, execute the CREALL script against the PDB, not the CDB root. Please
refer to Oracle documentation on how to create a PDB.
You then create your user tables, based on how you want the application to work.
After you have loaded and populated the system tables and created the user tables, run the Database
Setup utility to populate the system tables with information about the user tables and decisions you
made about how the system works.
Before you start

Make sure that Oracle is set up correctly before you begin installing the database tables.
Oracle primary key

Several tables cannot be created with an Oracle primary key. Oracle primary keys do not allow you to
insert null values. You cannot be certain that every column in these tables is populated; thus requiring
null values. The null values are important to the way JDA Allocation functions, so do not use the
default value modifier when creating columns in these tables to avoid null values. These tables are:
 Any table of type format, for example, PLAN_FORMAT, host format tables, data collect format
tables, and the format table you create for performance based data collects. The same restriction
holds true if you create an additional format table for Prior Results.
 GRADE
 CAQ_HOST
 RESULTS_DETAIL
JDA Allocation requires a Main Key to be set up in Database Setup. This key is not the same as an
Oracle Key or index; it is strictly informational and is used by the application to determine details
about some tables.

Oracle users
Ensure that you have set up a user for Oracle with full Database Administrator (DBA) rights. You need
this user for the preliminary setup, such as creating the tablespaces and users.
Run the scripts

To run the scripts from your PC, you must have Oracle SQL*Plus for Windows installed.
Run scripts using SQL*Plus

To run an Oracle script, you need Oracle SQL*Plus.
Tip: To copy and paste these commands, use the Text Select Tool in Acrobat Reader. Select the text,
copy it to the Clipboard, and paste it into a text editor for customization.
SQL*Plus
1. Start SQL*Plus.
2. To run scripts that are on your PC, type the following:

start drive:path\directory\script
Example: Because the drive and path are contained in the JDA_ALLOCATION_SCRIPTS environment
variable, if you have a script called TEST.SQL, you would type:
start %JDA_ALLOCATION_SCRIPTS%\AAM\TEST.SQL
and press Enter.
Create the system tables

You must run the scripts to create the system tables in three stages.
1. Create the tablespaces.
2. Create the schema.
3. Create the tables.
The three scripts to run to create the system tables are:
 CRETBLSP.SQL
 CREADMIN.SQL
 CREALL.SQL
Use the following procedures to run the scripts in the correct sequence from the appropriate Oracle
user. You should open these scripts, using a text editor, to review comments that provide more details
on the purpose and action of the scripts.
Caution:
 Do not interface directly to system objects other than those documented and required for data and
results. JDA reserves the right to change these objects at any time.
 Do not alter system objects in any way or future scripts will not be able to update them. For
example, do not rename system objects to fit other naming conventions.

 Run the scripts as outlined in this Guide. Do not deviate. Do not run from a session on the server
itself, as the scripts use Windows environment variables that are established during the
installation, and must be run from SQL*Plus on the Windows administrator machine.
Create the tablespaces (CRETBLSP.SQL)

Note: For Oracle 12c, create a PDB, which includes tablespaces, and proceed to the next section.
Specific instructions are not included, as the design decisions regarding the PDB creation are
implementation specific. Please refer to Oracle documentation on how to create a PDB.
Tablespaces are the parts of the Oracle database in which Oracle stores all tables, indexes, and other
information. You must tell Oracle the name of the data files in which the information is stored.
Two tablespaces are used: AAMDATA and AAMINDEX. AAMDATA holds all system tables and
AAMINDEX holds all index information for these tables.
Edit the CRETBLSP.SQL script to use your path names and directories on your database server
machine. This script creates the Oracle tablespaces used by the application.
The default script contains the following create tablespace statements.
Create Tablespace AAMDATA

Datafile '/U01/ORADATA/AAM/AAMDATA01.DBF'
/* Modify To Meet Site Standards */
Size 10m
/
Create Tablespace AAMINDEX
Datafile '/U01/ORADATA/AAM/AAMINDEX01.DBF'
/* Modify To Meet Site Standards */
Size 10m
/
The default script uses data files in the /U01/ORADATA/AAM directory. Using a text editor, change
these directory paths to suit your system. You must have access to this directory and have the
necessary space available.
Tip: You may find that performance is improved if you put the AAMDATA tablespace data file on one
disk, and the AAMINDEX tablespace data file on another. This split minimizes contention.
Run the Create Tablespaces script

You can now run the script. Log in to the Oracle database as a user with full DBA rights to create these
tablespaces. The script is in the root directory of the installed scripts.
From SQL*Plus, type:
start %JDA_ALLOCATION_SCRIPTS%\CRETBLSP.SQL
and press Enter.
Create the schema (CREADMIN.SQL)

The CREADMIN.SQL script creates the Allocation schema and administrator-related objects.
JDA Allocation needs an Oracle schema in which to store its database objects. All users of the
application connect to this schema, using an encrypted connection file. The CREADMIN.SQL script
prompts for the name of the schema before creating it with the required privileges.
The CREADMIN.SQL script allocates space on the AAMDATA and AAMINDEX tablespaces to the
specified schema, so you must run the CRETBLSP.SQL script before you run this script. See "Create
the tablespaces (CRETBLSP.SQL)" (on page 19) for details.

To retrieve information on the current Windows user and the time when changes were made to the
database, CREADMIN.SQL creates the JDA$OSUSER function in the Allocation schema.
Run the Create Schema script

To create the schema, start SQL*Plus from a machine where JDA Allocation has been installed with the
Database Maintenance and Setup component. Connect to the Oracle database as a user with full DBA
rights. All JDA Allocation database scripts reference an environment variable that is defined on the
administrator machine and related to the path where the scripts were installed.
start %JDA_ALLOCATION_SCRIPTS%\AAM\CREADMIN.SQL
and press Enter.
Follow and respond to all prompts.
Check the CreAdmin.log file in the allocation\scripts directory for errors and warnings. Resolve any
errors before continuing. Contact JDA Support Services for assistance in resolving any errors.
Create the Allocation system objects

To create the system objects and partially populate the system tables, carry out the following steps:
1. Create the tables.
2. Create the indexes.
3. Create the primary, unique, and foreign keys.
4. Create the procedures.
5. Create the triggers.
6. Populate the tables.
To ensure these scripts are run in the correct order, the CREALL.SQL or CREALL_EKB script is
provided, which lists all scripts in the order they should be run.
Run the CREALL or CREALL_EKB script

Determine whether the implementation will be integrated with EKB for product and location structure
data. If so, this step will use the CREALL_EKB script. All other databases use the CREALL script.
To run the script, log on to Oracle as the user that was specified when CREADMIN.SQL was run,
using a password the same as the user ID. The script is in the \AAM directory of the installed scripts.
From SQL*Plus, enter:
start %JDA_ALLOCATION_SCRIPTS%\AAM\CREALL.SQL
and press Enter.
If not integrating with EKB for product and location structure data, you must enter the data type and
precision of the Location ID columns you intend to use throughout the application, so the script can
create the relevant system tables with the correct type of Location ID. When you are prompted, you
must enter the data type and precision exactly as it should be used.
For example:
Creating the Allocation database

Enter the data type as it should appear in the RESULTS_DETAIL and RESULTS_LOCATIONS
table for the column location_ID

Enter value for data type: NUMBER(15)

Creating tables
Creating primary keys
Creating unique keys
Creating foreign keys
Creating indexes
Creating database stored procedures
Creating database triggers
Creating base data
Allocation database created
Create all tables that use location IDs with the same data type you enter here. Check the aam.log
spool file in the allocation\scripts directory for errors or warnings that may have occurred during
this session. Resolve any errors before continuing. Contact JDA Support Services for assistance in
resolving any errors.
Create the user tables

After you install the system tables, you create the user tables as laid out in your design meeting and
documentation. The format of the tables is extremely flexible, but there are some guidelines that you
must follow. These guidelines are described in the following sections.
Sample scripts
A sample script for creating user tables (CREDB.SQL) is provided in the SAMPLES directory of the
installation.
These scripts can be used as a basis for creating your own tables.
See "Example tables" (on page 116) for examples of user-defined tables.
Methods of creating tables

You can create Oracle tables in a variety of ways. You can use the Oracle Object Manager or create the
tables in SQL*Plus, either on your PC or UNIX machine. See the appropriate documentation for details.
Location of the tables

Create the user tables in the same schema as the Allocation system objects.
Tablespaces
When creating your user tables, use the AAMDATA tablespace for the tables and the AAMINDEX
tablespace for the indexes.
Consult your Oracle DBA for advice on the size of the tablespaces you should use. See the Oracle
documentation for information on increasing the size of your tablespaces.
Table names
The application reserves some table names for its own system tables. In addition, some names for
user tables can be used only for specific purposes. The WorkList table, for example, must be called
WORKLIST, and the name cannot be used for any other table.
Oracle allows great flexibility with table and column names; however, for JDA Allocation you must use
alphanumeric table and column names, with no spaces, primes, or mixed case. In addition to Oracle's
restrictions on names for columns, no column names can be an exact match with any of JDA
Allocation's operators. This restriction applies to column descriptions as well.

Reserved table names

In addition to the following tables, integration with EKB for product and location structure will also
create and maintain the LOCATIONS table as well as reserved tables for product lists by level. These
tables are named LIST_<EKB Level Name>.
 AA$ALERT_QUEUE
 AA$BATCH_DETAIL
 AA$BATCH_HEADER
 AA$JOB
 AA$SCHEDULE
 AAM_PARAMETERS
 ALLOCHOST$DCLOG
 ALLOCHOST$DCRULES
 ALLOCHOST$ERRORS
 ALLOCHOST$GRPLEVELS
 ALLOCHOST$HIERARCHY
 ALLOCPACK$ERRORS
 ALLOCPACK$ERRORSVIEW
 AUTO_ALLOCATION_ALERTS
 AUTO_ALLOCATION_SERVERS
 BASE$PKV
 BASE$RCV
 BASE$UKV
 CAQ$CHS
 CAQ$CHSV
 CAQ$CSC
 DC_COND_DETAIL
 DC_COND_DLG_DRV
 DC_COND_GRP_ASSOC
 DC_COND_HEADER
 DC_FORMAT_HEADER
 DC_RULE_DETAIL
 DC_RULE_DLG_DRV

 DC_RULE_GRP_ASSOC
 DC_RULE_HEADER
 DC_RULE_INFO
 DC_RULE_PARAMETER
 DC_VARIABLES
 DC_VARIABLE_LIST
 EKB_LOCATION_TECH_KEYS
 EKB_CALENDAR_TECH_KEYS
 EKB_PRODUCTS
 FOLDER_MANAGER
 FOLDER_OBJECT_XREF
 HIERARCHY
 HIERARCHY_DETAIL
 INTERNAL_GRADING_DETAIL
 INTERNAL_GRADING_DLG_DRV
 INTERNAL_GRADING_HEADER
 INTERNAL_GRADING_RULES
 LEVELS
 LIKE_STORE_DLG_DRV
 LIKE_STORE_PATTERNS_DETAIL
 LIKE_STORE_PATTERNS_HEADER
 LIKE_STORE_PRODUCTS_DETAIL
 LIKE_STORE_PRODUCTS_HEADER
 LIKE_STORE_VARIABLES
 LOV
 MD$DCSTATEMENTS
 MD$IMPORT_DATA
 MD$NAMES
 MD$PRODUCT
 MODEL_STOCK
 NEED_DETAIL
 OWNERSHIP

 PARAMS
 PLAN$COLLECT
 PLAN_FORMAT
 PLAN_STAGING
 PLAN_TIME_ORDER
 QUEUE_DC_ACTIVE
 QUEUE_IN
 QUEUE_OUT
 RDM$COLLECT
 REPORT_DETAIL
 REPORT_HEADER
 RES$RSV<number>
 RESULTS_ANALYSIS
 RESULTS_DETAIL
 RESULTS_HEADER
 RESULTS_LOCATIONS
 RESULTS_STATISTICS
 RST_COND_CRITERIA_SCRATCH
 RST_COND_DETAIL
 RST_COND_DLG_DRV
 RST_COND_GRP_ASSOC
 RST_COND_HEADER
 RST_COND_RESULTS_SCRATCH
 RTMM_COLUMN_MAP
 RTMM_COLUMNS
 RTMM_DATA_SOURCES
 RTMM_GROUPS
 RTMM_MAP
 RTMM_OBJECT
 RTMM_PRIMARY_KEY_MAP
 RTMM_TABLES
 SC_COND_DETAIL

 SC_COND_DLG_DRV
 SC_COND_HEADER
 SYSTEM_STATUS
 TECH_MM$DETAIL
 TECH_MM$DETAIL_PACK
 TECH_MM$HEADER
 TECHNIQUES_ALTLEVEL
 TECHNIQUES_DESCRIPTION
 TECHNIQUES_GRADING
 TECHNIQUES_HEADER
 TECHNIQUES_MINMAX_STORES
 TECHNIQUES_TEMPLATE
 TECHNIQUES_TEMPLATE_STORES
 UNIQUE_KEY_DETAIL
 UNIQUE_KEY_HEADER
 USERS
 VARIABLE_DETAIL
 VARIABLE_HEADER
 VARIABLE_REFERENCES
 VARIABLE_REFERENCES_NAMES
 VARIABLE_REFERENCES_VIEW
 VIEW_DETAIL_DISP_ATTRIB_TB
 VIEW_DETAIL_DISP_ATTRIBUTES
 VIEW_DETAIL_FILTER
 VIEW_DETAIL_FILTER_TB
 VIEW_DETAIL_SORT_ATTRIB_TB
 VIEW_DETAIL_SORT_ATTRIBUTES
 VIEW_HEADER
 VIEW_LAYOUTS
 VIEW_SUMMARY
Required names for user tables

 CAQ_HOST

 GRADE
 LOCATIONS
 WORKLIST
Extents for tables

Consult your DBA for advice on the size of extents, based on the volume of your data.
Drop a table
To drop a table that has been identified as a User table in Database Setup:
1. From Database Setup, "Step 1" (on page 91), select the table you want to remove from the list.
The table's details are displayed in the Table Name, Table Type, and Table Description boxes.
2. Click Remove, then click Yes to confirm. The table details are removed from the list.
3. Click Next to move to "Step 2" (on page 92) of Database Setup. Database Setup removes all
references to the table you removed; it does not remove the table from the database.
4. Click Finish, then click Update to commit the deletion.
5. After removing the table name through Database Setup, you can use SQL*Plus to issue the Drop
Table command for the tables you want to remove.
Note: Current versions of Oracle allow dropping a column from a table. Before dropping a column from
a table that has been identified in Database Setup, follow the previous steps so Allocation Database
Setup can correctly handle the change. After the table has been altered, re-add it in Database Setup.
Dropping List Source tables

Removing List Source tables requires extra steps. Perform the following steps in Database Setup. If
integrating with EKB for product and location structure data, the product list source tables are system
tables and should not be modified or dropped.
1. Start Database Setup and go to "Step 3: Define the groups" (on page 93).
2. Select the groups associated with the List Source table and specify <None> as a List Source for
each, clicking Set each time.
3. Click Finish to update the database.
Do these three steps first, because if you remove a List Source table without performing these
steps, Database Setup removes not only the List Source table, but the corresponding groups and
everything associated with those groups.
4. Restart Database Setup and go to "Step 1: Enter the table names" (on page 91).
5. Remove the List Source tables.
To re-add the List Source table after it has been modified:
1. Restart Database Setup and re-add the List Source tables on "Step 1: Enter the table names" (on
page 91). Click Next to go to "Step 2: Enter the dimension names" (on page 92).
2. Go to "Step 3: Define the groups" (on page 93), and specify the tables as List Source tables for
the appropriate groups.

3. Go to "Step 5: Enter the column information" (on page 95), and associate the appropriate product
hierarchy group with the appropriate code column for each table.
4. Go to "Step 9: Set up column mappings" (on page 99), and re-establish the appropriate main key
for each List Source table.
Install the database packages

You must install the Allocation database packages. Read, then run, the script INSTALL.SQL, which is
located in the SCRIPTS\AAM\PROCS\PACKAGES directory. If necessary, install old packages from
the SCRIPTS\ARCHIVES directory.
start %JDA_ALLOCATION_SCRIPTS%\AAM\PROCS\PACKAGES\INSTALL.SQL
If you do not use CAQ, run the script NOCAQINSTALL.SQL.
After running the script, check the packages.log in the scripts directory. Contact JDA Support
Services for assistance in resolving any errors.
Database upgrade process

When upgrading your database, make sure your database is valid and functional prior to the update. It
is highly recommended that you make a copy of your production database and use it as a test
database, before applying the upgrade to your production system. If your database is at least a 2005.1
version, run the archive scripts located in the SCRIPTS\ARCHIVES directory. If your database is at
version 2005.1 or newer, then you can simply run the script below to update it to the current version.
Read the current Release Notes to identify changes you may need to make to the user tables and
interface code.
The process for updating the system tables is also documented in the Release Notes for the current
version.
Caution:
Do not directly interface to JDA Allocation system objects other than those documented and required
for data and results. JDA reserves the right to change these objects at any time.
Do not alter system objects in any way or future scripts will not be able to update them. For example,
do not rename system objects to fit other naming conventions.
Verify the database

After the database has been updated, run tests against the database. After all testing has been
completed, run the same scripts on your production database and upgrade your user desktop
machines.

Set up locations
Chapter 5. Set up locations

The Locations table contains the list of all stores and warehouses to which you can send merchandise.
It can contain extra information about your locations that can help the distributors in carrying out their
allocations. They can narrow down the list of locations to which to send merchandise according to
region, district, or location size.
Populate the Locations table

If integrating with EKB for product and location structure data, the Locations table is a system table
and its data is populated from EKB and maintained by the system. If not using this EKB structure
integration, you can populate the Locations table in any of the following ways, or any combination of
these ways.
 Transferring information from another database to the application Locations table
 Using the Allocation Administration application
 Using data from an existing table in Oracle
If you use a text data type for your location ID, the values for the location IDs must not contain
spaces.
Set up the Locations table

Three types of columns make up the Locations table.
 Required columns. JDA Allocation needs all required columns for its own use.
 Optional columns. The optional columns can be used to change the way the application works. For
example, you can define some locations as warehouses by creating a warehouse flag column.
 Additional columns. You can use additional columns that help the distributors in their decisions; for
example, you can provide a column for climate that would allow distributors to narrow the range of
locations to warm climates when allocating summer clothing.
Name the Locations table and its columns

The Locations table must be called LOCATIONS. If you have a table that already contains all
information necessary for the Locations table, or that can be altered easily to add the necessary extra
information, you can use it, if you create a synonym of Locations for this table.
You can give the columns in the Locations table any names you want; this naming ensures that the
distributors deal with information that is familiar to them. You must map the required and optional
columns that you create in these tables to the names that JDA Allocation understands, using the
Database Setup utility.
Caution: Operators cannot be used as column names or descriptions in any JDA Allocation table.
You can do this process at any time after you have created the Locations table. The Database Setup
utility runs on the PC and modifies the Allocation database to consider your tables and the names you
have given the columns.

Set up locations
Create the required columns

There is a minimum set of columns that the application needs for its own procedures. You must have a
Locations table with these columns. They can be displayed in any order, and can have any names you
want. You must tell the application which column is which, using the Database Setup utility, after you
create all tables you need. See "Step 9: Set up column mappings" (on page 99) for details.
Keep a record of the names of the columns you create in the table, and to which required columns
they apply.
Location ID
The location ID is the code that the application uses to keep track of stores and distribution centers.
Each location ID must be unique in the location table. The location ID may be numeric or text;
however, you must ensure that the location ID contains no spaces.
Data type requirements

The location ID may be any data type. If you use a numeric data type, it must be an integer. Allocation
will enforce a maximum precision of 15 for NUMBER data types, if you do not provide one.
Caution: You must decide which data type you are going to use for your location ID before you install
the system tables. You must use the same location ID data type consistently in all tables that need a
Location ID column.
 The LOCATION_ID data type is used internally by Allocation when creating some system tables and
plan format/staging tables. It is particularly important to ensure that the precision is specified
when the user runs the database creation scripts.
 Database drivers occasionally report incorrect information for columns with a data type of
NUMBER, when the precision is not specified for the column. To avoid this issue, specify the
precision when creating tables with columns using numeric data types.
Location Name
The Location Name is the name or description of the location. JDA Allocation can display this name to
the users instead of the location ID when a list of locations is shown. For example, a location may have
the location ID 121 and the Location Name "Fosse Park."

The Location Name column must be able to hold a string of up to 50 characters with, for example, the
data type VARCHAR2(50).
Available for Allocation flag

The Available for Allocation flag tells JDA Allocation whether it is possible to send merchandise to each
location. The flag must be set to one of the following.
 Checked: The location is active.
 Unchecked: The location is inactive.
For example, you may set the Available for Allocation flag to Unchecked when the location has been
set up, but you have not started staging the merchandise for the store, or if it is being remodeled.
If you change the Available for Allocation flag from Checked to Unchecked on a location with pending
allocations (in Approved, Unapproved, or Discrepancy status), a warning message will appear
confirming your change.

Set up locations
Ensure that the Available for Allocation flag is set to Checked for all warehouses to which merchandise
can be distributed. If this flag is not set, you are not able to allocate merchandise to reserve. The
Distribution Centers and stores are held in the Locations table. The Available for Allocation flag can be
updated in the Locations Maintenance table in Allocation Administration. See "Maintain locations" (on
page 138) for details.

The Available for Allocation flag must be a single alphanumeric character with, for example, the data
type CHAR.
Warehouse flag
The Warehouse flag specifies whether the location is a warehouse, rather than a store. Warehouses
cannot be sent merchandise through the normal allocation procedure; they can be sent only
merchandise allocated to a reserve warehouse location.
You must have this column if you want to allocate merchandise to a reserve warehouse location.
The flag must be set to one of the following.
 Y: The location is a warehouse.
 N: The location is not a warehouse.

The Warehouse flag must be a single alphanumeric character with, for example, the data type CHAR.
Create additional columns to help distributors

You can create as many columns as your distributors want to provide extra information about the
location. For example, if your operational system contains information for the climate, you can add
that information to the Locations table so that distributors can consider it when allocating.
You do not have to populate every additional column in every row in the Locations table. If the
information is available on your transaction management system, you can provide it or leave the field
null.
Display in WorkSheet
The Display in WorkSheet column indicates to JDA Allocation whether the location should be displayed
in the WorkSheet. It is an optional column. If it is not present, locations of type store are displayed in
the WorkSheet if they are available for allocation.
Display in WorkSheet is used to allow locations to be displayed in the WorkSheet whether they are
stores or warehouses, even if they are unavailable for allocation, as long as they are not excluded due
to user or product location restrictions. Any locations that are unavailable for allocation but selected for
display appear in a read-only state. At the database level, the supported values for this column are Y
and N. If the column is present, any locations where the flag is unchecked (and contains a value of N)
will not be present in the WorkSheet.
 Checked: The location is eligible for display in the WorkSheet.
 Unchecked: The location is not eligible for display in the WorkSheet.

Set up locations

The Display in WorkSheet flag must be a single alphanumeric character with, for example, the data
type CHAR.
Global Coordinates
The Global Coordinates columns (Latitude & Longitude) provide JDA Allocation the global coordinates
of locations so that they can be displayed on the store selection map of the Locations tile on the
Administrator Dashboard. They are optional columns. If both of these columns are not present and
mapped on step 9 of Allocation Database Setup, then store selections are not displayed on the tile’s
map.
The global coordinates columns should be populated with the latitude and longitude coordinates of
every location. For example, a store in Atlanta, Georgia might have a Global Coordinates Latitude
value of 33.7489954 and Global Coordinates Longitude value of -84.3879824.

The Global Coordinates Latitude and Global Coordinates Longitude columns must be numeric and able
to hold fractional values, for example, the data type NUMBER.
Set the Main Key for the Locations table

You must set a Main Key for each table that you create. For the Locations table, this key must be the
Location ID column.

Set up the WorkList
Chapter 6. Set up the WorkList

The WorkList is the list of merchandise awaiting allocation that is presented to each distributor. JDA
Allocation displays a line of information for each collection of merchandise; this information is a
WorkList line. Each WorkList line contains a single distributable collection of merchandise.
Set up the WorkList table to display the information the distributors need to know to carry out their
allocations. This information may include styles, colors, sizes, pack sizes, quantities, and order date.
Information that exists on your transaction management system that can help the distributors should
be passed to the WorkList. The distributors can set up views onto the WorkList, allowing them to use
all or a subset of the information passed to them.
The WorkList is very flexible. You can create a WorkList to hold as much information as is available.
You can give each piece of information meaningful headings in the WorkList, using the terminology of
your own organization, so the distributors can readily understand the information.
The WorkList and its related tables

Three types of tables are used by the application for information related to products that are ready to
allocate. You must define these tables.
 The WorkList table. The WorkList table contains information from your transaction management
system and is displayed to the distributors. Each row in the WorkList table contains one collection
of merchandise. The exact columns in the tables must be defined in collaboration with the
distributors. There is only one WorkList table.
 Merchandise Shape tables. Merchandise Shape tables contain extra information about each
collection of merchandise. For example, a Merchandise Shape table might contain the quantities of
red, blue, and black colors and small, medium, and large sizes in a collection of T-shirts, or the
quantities for each size in a pack of running shoes.
 The merchandise type in the WorkList line specifies which Shape table is appropriate. You can have
as many Merchandise Shape tables as you need.
 Detail tables. Detail tables contain extra lines of description about parts of the WorkList. For
example, you could have several lines of description for each style. You can have as many Detail
tables as you need.
Set up these tables so they contain the columns the application needs to carry out the allocation of
merchandise and as much information as possible for the distributors.
See "Example tables" (on page 116) for examples of the WorkList table.
Set up the WorkList table

The WorkList table contains one collection of merchandise in each row. Determine the level of
granularity for this collection carefully. Each column is populated by a procedure that gets information
from your transaction management system and writes the appropriate information to the WorkList
table at the correct time.
Three types of columns make up the WorkList table.
 Required columns. The application needs all required columns for the system to work.

Set up the WorkList
 Optional columns. The optional columns can be used to change the way the application works. For
example, if a particular collection of your merchandise must be sent to a particular warehouse
location when there is merchandise left over from the allocation, you can add a warehouse number
column to the WorkList table.
 Additional columns. You can use additional columns that the application does not use for its own
purposes, but which can help the distributors in their decisions. For example, if your operational
system contains information for the fabric content and the merchandise label for all styles, you can
add that information to the WorkList table so that distributors can consider it when allocating. If
desired, data in these additional columns can be edited by users either directly, using a calendar
control for date columns, or selecting a value from a custom drop-down list.
JDA Allocation supports only one level 0 member (often the style level) per WorkList line. The Main Key
for Shape tables should not include anything above level 1 (as defined in "Step 6" (on page 96) of
Database Setup).
Name the WorkList and its columns

The WorkList table must be called WORKLIST. You can give the columns in the WorkList table any
names you want, so the distributors deal with information that is familiar to them. You must map the
required and optional columns that you create in this table to the names that the application
understands, using the Database Setup utility.
Mapping can be completed at any time after you create the WorkList table. The Database Setup utility
runs on the PC and modifies the Allocation database to consider your tables and the names you gave
the columns.
Create the required columns

There is a minimum set of columns that the application needs for its own procedures. You must create
a WorkList table with these columns. They can be displayed in any order and can have any names you
want. Using the Database Setup utility, you must tell the application which column is which, after you
create all tables you need.
Keep a record of the names of the columns you create in the table, and to which required columns
they apply.
Specify these required column mappings in Allocation Database Setup, step 9.
Allocation Number
The Allocation Number is used when the distributor decides to allocate a WorkList line. The line is given
an Allocation Number, which is used to track the merchandise as it goes through the system.
When each WorkList line is written to the WorkList table, the value of the Allocation Number must be
zero.

The Allocation Number column must be able to hold an integer of at least six digits with, for example,
the data type NUMBER(15).
Allocation User
The Allocation User is used to determine who is currently working on each WorkList line.
When each WorkList line is written to the WorkList table, the Allocation User column must be set to
null.

Set up the WorkList

The Allocation User column must be of data type VARCHAR2(30).
WorkList Key
The WorkList Key is a number that identifies the WorkList line. This number must be unique in the
WorkList table.
When each WorkList line is written to the WorkList table, the WorkList Key must be set to a unique
number. Sequential numbering of the WorkList Key is one way to get unique numbers.

The WorkList Key must be able to hold an integer of at least six digits with, for example, the data type
NUMBER(15). The WorkList Key cannot be null.
Auto-Allocation Job Number

The Auto-Allocation Job Number is required for Auto-Allocation.

The Auto-Allocation Job Number must be able to hold an integer of at least six digits with, for example,
the data type NUMBER(15).
Status Code
The Status Code indicates whether the WorkList line is available for allocation. When each WorkList
line is written to the WorkList table, the Status Code must be 10, the code for Available. The possible
values for Status Code are shown in the following table.
Status Code Description Explanation

10 Available The line is available for allocation.
20 In Progress The line is in progress by either a user or Auto-
Allocation.
25 Discrepancy The allocation was approved and saved, but the
available quantities changed. Under these conditions,
your interface code must set this status. Upon
WorkSheet entry, this allocation is recalculated to
determine where the discrepancies are. See
"Discrepancies" (on page 48) for details.
30 Approved The allocation is complete and has been written to the
database.
40 Released The complete allocation has been written to the
database and a message has been sent to the
QUEUE_OUT so your interface can pick up and process
the results.
50 Unapproved Written results are in the database, but the allocation
cannot be released. This status allows a recalculation
on entry to the WorkSheet to apply today's
restrictions. Alternatively, the line can be approved
directly from the WorkList and released.

Set up the WorkList
Status Code Description Explanation

60 Writing Results The application is in the process of either queuing the
results file or writing that file from the queue to the
database. If results writing fails, the status changes to
65 (Error Writing Results).
65 Error Writing Results If results writing fails for any reason, the line is set
with this status. For information on fixing the
problem, see the "Resolving Queue Results Error
Conditions" topic in the online help.
70 Allocation Error If Auto-Allocation fails for any reason, often due to
zero Need, the lines are set with this status. You can
run a script to reset the lines that failed to auto-
allocate back to Available. See "Create and maintain
auto-allocation schedules" (on page 158) for details.
99 Locked The client's interface can set this code so that no user
picks up the line while its status is being determined
or quantities updated.
Unknown If JDA Allocation does not recognize the status code
when attempting to update a WorkList line status, the
status description is set to Unknown.

The Status Code column must be a number data type; for example, NUMBER(15).
Status Description
The Status Description column displays the status of the WorkList line to the distributors.
When each WorkList line is written to the WorkList table, the Status Description must be Available.

The Status Description column must be able to hold a string of up to 50 characters with, for example,
the data type VARCHAR2(50).
Status Change Timestamp

The Status Change Timestamp is updated whenever the status of a WorkList line is updated by the
application. The Status Change Timestamp often is used when deleting entries from the WorkList
tables. The administrator can delete all allocations released before a certain date and time.
When each WorkList line is written to the WorkList table, the value of the Status Change Timestamp
must be set to the current system date.

The Status Change Timestamp must be a time and date; that is, data type DATE.

Set up the WorkList
Merchandise Type
The Merchandise Type specifies the shape of the merchandise. To allocate WorkList lines together,
they must have the same merchandise type. You define merchandise types using the Database Setup
utility, Step 10. You can have as many types as you want. For example, you may have a different
merchandise type for a style that has colors and sizes than a hardline SKU that doesn't. When each
WorkList line is written to the WorkList table, the Merchandise Type must be set by the interface to the
type associated with the merchandise.

The Merchandise Type must be able to hold an integer of at least six digits with, for example, the data
type NUMBER(15).
Trouble Code
The Trouble Code is used if there are problems with a WorkList line. If you have problems with the
merchandise in the WorkList line, you set this column to any non-null value. The application checks the
value of this column every time it tries to change the status of the line. If you have set the Trouble
Code, the application does not allow the use of the line and the merchandise it represents until the
Trouble Code is removed.
When each WorkList line is written to the WorkList table, the Trouble Code must be set to null.

The Trouble Code must be alphanumeric, for example, the data type VARCHAR2(2).
Current Activity
The Current Activity column holds special information about the allocation.
When each WorkList line is written to the WorkList table, the Current Activity column must be set to
null.

The Current Activity column must be of type VARCHAR2(81). Null is a legal value.
Collect Status
For background data collects, the Collect Status column is used to hold the data collect status of the
current WorkList line, as well as Auto-Allocation review information.
When each WorkList line is written to the WorkList table, this column must be null.

The Collect Status column must be of type NUMBER(15).
Collect Status Description

For background data collects, the Collect Status Description column is used to hold the description of
the data collect status of the current WorkList line, as well as Auto-Allocation review information.

Set up the WorkList

The Collect Status Description column must be of type VARCHAR2(50).
Collect Status Timestamp

For background data collects, the Collect Status Timestamp column is used to hold the time and date
of the last change in the data collect status of the current WorkList line, as well as Auto-Allocation
review information.

The Collect Status Timestamp column must be of type DATE.
Collect Rule Info

For background data collects, the Collect Rule Info column is used to hold information about the data
collect rule and Auto-Allocation review information.

The Collect Rule Info column must be of type VARCHAR2(50).
Create the optional columns

You can add columns to add to the functionality of the WorkList, as described in the following sections.
Keep a record of the names of the columns you create in the table, and to which optional columns they
apply.
Identify these optional column mappings in Allocation Database Setup, step 9.
Available Quantity
The Available Quantity column provides the quantities of the merchandise to be allocated. If there is
no Merchandise Shape table associated with the WorkList line, this column must exist and contain the
quantity of merchandise available for allocation. Available Quantity is not used to determine the
WorkSheet details for pack merchandise.
When each WorkList line is written to the WorkList table, the quantity of merchandise available for
allocation must be written either to the WorkList or to a Shape table. If the information exists in a
Shape table, you can still provide data in this column to help the distributors, but JDA Allocation will
use the details in the Shape table for updating the WorkSheet.
This column is required to be mapped and populated if using the status & report functionality on the
Administrator and Client Dashboards to show the total units by status code for a WorkList view.

The Available Quantity column must be able to hold an integer of at least six digits and have, for
example, data type NUMBER(15).

Set up the WorkList
Default Store Selection

The Default Store Selection is the name of the store selection that determines the set of locations that
are deemed appropriate for each collection of merchandise. For example, if you have two sets of
locations, one resort locations, the other non-resort locations, you can inform the distributors by
applying the store selection before they see the WorkList line. The store selection is a guide for
distributors; they can override it, if necessary.
When each WorkList line is written to the WorkList table, the Default Store Selection can be set to the
name of the store selection appropriate for the merchandise. If entered, this store selection must be a
saved global store view, created in Allocation Administration or the WorkSheet.
The Default Store Selection is loaded on entry to the WorkSheet, unless multiple WorkList lines are
allocated together and they contain different store selections. In this case, no store selection is
opened.
When loading a method and the method contains no store selection, the Default Store Selection is
preserved. If the method contains a store selection, the store selection from the method is opened
instead.

The Default Store Selection must be able to hold a string of at least 50 characters with, for example,
the data type VARCHAR2(50).
Destination Warehouse
The destination warehouse is the warehouse location to which unallocated merchandise in the current
WorkList line must be sent; for example, you might have three warehouses that store different items.
This column allows you to specify where the unallocated merchandise is sent. If the column is null, or if
you do not set up this column, the merchandise can be allocated to any of your warehouses. If the
column contains a 0 (zero), the merchandise from that WorkList line must be allocated to locations in
the WorkSheet; it will be restricted from sending to reserve.
The warehouse number must contain the valid number of a warehouse that is available for allocation;
this number is the location ID from the location table, where the location has the Warehouse flag set to
Y.
When each WorkList line is written to the WorkList table, the warehouse number must be set to the
number of the warehouse to which the merchandise must be sent, or null if the merchandise can be
sent to any warehouse.

The Destination Warehouse column must be the same data type as the Location ID column used
elsewhere in the database; for example, as in the format tables and Locations table.
Source Warehouse
The Source Warehouse is the warehouse location from which unallocated merchandise in the current
WorkList comes. For example, you might have a warehouse on the East coast and a warehouse on the
West coast. If you make this column a group, it allows you to create Product Location Restrictions
based on the source of the merchandise. For example, merchandise from the East coast goes to the
Eastern locations, while merchandise from the West coast goes to the Western locations. See "Set up
product location restrictions by source warehouse" (on page 104).

Set up the WorkList
The warehouse number must contain the valid number of a warehouse that is available for allocation;
this number is the location ID from the Location table, where the location has the warehouse flag set
to Y. When each WorkList line is written to the WorkList table, the warehouse number must be set to
the number of the warehouse from which the merchandise comes. If the column exists, it cannot be
null.

The Source Warehouse column must be the same data type as the Location ID column used elsewhere
in the database; for example, as in the format tables and Locations table.
Pack ID
The Pack ID identifies the pack. The Pack ID, appended to the UMID, makes up the unique pack
identifier (UPID). This column may exist in a Merchandise Shape table instead of in the WorkList table.
The Pack ID column, the Quantity per Pack column, and the Number of Packs Available column must
be included in the same table; that is, either the WorkList or the Shape table. You must also make the
Pack ID part of the Main Key.
When each WorkList line is written to the WorkList table, the Pack ID must be set to the unique ID of
the pack that makes up the collection of merchandise.
If the Pack ID column is associated with a group in Allocation Database Setup step 5, and the list
source table for that group has a description for each Pack ID, the Pack ID description can optionally
be displayed in the WorkSheet.

The Pack ID column may be of any data type.
Number of Packs Available

The Number of Packs Available is the number of packs in the collection of merchandise for each
WorkList line. If any merchandise is to be allocated in packs, you must include this column, the
Quantity per Pack column, and the Pack ID column in the same table; that is, either WorkList or the
Shape table.
This column may exist in a Merchandise Shape table instead of in the WorkList table. It is used only for
pack merchandise.
When each WorkList line is written to the WorkList table, the Number of Packs Available must be set to
the number of packs in the collection of merchandise.

The Number of Packs Available column must be able to hold an integer of at least six digits with, for
example, the data type NUMBER(15).
Quantity per Pack

The Quantity per Pack is the number of units of merchandise in each pack. If you are allocating
merchandise in packs, you must include this column, the Pack ID column, and the Number of Packs
Available column in the same table; that is, either the WorkList or the Shape table. Quantity per Pack
is used only for pack merchandise.
This column may exist in a Merchandise Shape table instead of in the WorkList table. When each
WorkList line is written to the WorkList table, the Quantity per Pack must be set to the number of units
in each pack.

Set up the WorkList

The Quantity per Pack must be able to hold an integer of at least six digits with, for example, the data
type NUMBER(15).
Method Name
The Method Name column contains the name of the method to be used to perform the allocation.
Method Name is required for Auto-Allocation. If multiple methods of the same name are created by
different users, you can specify which user's method to use by including the user ID preceded by a
tilde ~. For example, mymethod~marilyn.
Note: Do not use any special characters, such as a tilde (~), when initially saving and naming a
method.
When loading a method that contains no store selection, the Default Store Selection is preserved. If
the method contains a store selection, the store selection from the method is opened instead.

The Method Name column must be able to hold a string of at least 90 characters; for example data
type VARCHAR2(90). Null is a legal value.
Model Name
The Model Name column contains the name of the model to be used with the method. The name must
reference a model that has details for all merchandise contained in a WorkList line. The model name
will be associated with the level zero product member identified by the WorkList line, when the line is
allocated.

The Model Name column must be able to hold a string of at least 50 characters; for example,
VARCHAR2(50). Null is a legal value.
Distribution Sequence
The Distribution Sequence column contains a value that is used by the system to determine the order
for distributing goods when a SKU or pack from one source warehouse is allocated from multiple
WorkList keys in one allocation.
The system will hand out goods from WorkList rows in ascending order using Distribution Sequence,
followed by WorkList key. The system always distributes to WorkSheet locations first, followed by
reserve stock. As a result, the goods from WorkList keys with a higher value for distribution sequence
will be the units left for reserve stock, as long as the allocation meets the above criteria.

The Distribution Sequence column can be of type date, numeric, or text; for example, you may choose
to map this to your expected receipt date column. Null is a legal value, and will always be sequenced
after non-null values.
Data Collect Rule Key

The Data Collect Rule Key column is no longer used.

Set up the WorkList
Score
The Score column contains the calculated score of the allocation.

The Score column must be able to hold a string of at least 30 characters, for example, data type
VARCHAR2(30). Null is a legal value.
Note: The Score is displayed in the WorkList as a numeric value, but additional encoded information is
stored in this column.
Levels
The Level columns provide information about the merchandise below the style level; for example, the
color, size, and width. Level 0, the merchandise ID level, is defined by the merchandise type of the
WorkList line, but you can add the additional level columns to the WorkList or to a Merchandise Shape
table. Only include a level column on the WorkList if all merchandise uses that level. See "Set up
merchandise IDs" (on page 42) for details.
When each WorkList line is written to the WorkList table, the level information must also be written, if
available.

The Level columns must be defined as VARCHAR2. For example, data type VARCHAR2(6). Text data
cannot have leading or trailing spaces.
Note: The WorkList must contain only mapped level columns that are common to all merchandise
being allocated. For example, you cannot have a level column on the WorkList for Color, if some
merchandise does not use that level.
Groups
The Group columns provide information for product location restrictions and data collect; for example,
the Department and Class. These columns can be used to build a hierarchy of the products. You can
create hierarchies from groups using the Database Setup program. See "Step 4: Define the
hierarchies" (on page 94) for details.
You must also have groups for any information for which you want to collect data. For example, if the
allocation is to be based on department and class level plan information, you include columns for
Department and Class on the WorkList table.
Not all groups must belong to a hierarchy. Groups that do not belong to a hierarchy are called non-
hierarchical groups. An example of a non-hierarchical group is price point. It does not belong in a
hierarchical structure, but you may want to restrict data according to the price of the merchandise, or
to collect data for a range of prices. You would create a group for these purposes.
You can have as many groups as you want. You define Groups using the Database Setup utility. Any
table representing a group must have that information established on "Step 5" (on page 95) of
Database Setup.
Columns on the WorkList table that have associated Groups on "Step 5" (on page 95) of Database
Setup cannot accept Null values.

There are no restrictions on the data types used for group information. For example, you may have
NUMBER(15) for the department number, and VARCHAR2(50) for the department description.

Set up the WorkList
Create additional columns to help distributors

You can create columns to provide extra information for your distributors. For example, if your
operational system contains information for a special, advertised event for which the merchandise was
ordered, you can add that information to the WorkList table so that distributors can consider it when
allocating.
You can add extra columns for such information as style descriptions. You may have a column that
identifies the style by a number, but your distributors may prefer to see such information in more
descriptive terms. For example, you could add a Style_Desc column that would hold T-shirts whenever
the Style_ID column was 112.
JDA Allocation automatically displays all columns in the WorkList table to the distributors; you do not
have to tell the system about these extra columns. If this information grows too unwieldy, distributors
can tailor the display using WorkList views that show a subset of the available columns.
You do not have to populate every additional column in every WorkList line. If the information is
available on your transaction management system, you can provide it or leave the field null.
The sample WorkList tables provide examples of additional columns that distributors may find useful.
See "WorkList tables" (on page 116) for details.
Select a WorkList value from a custom drop-down list in

the WorkList
To enable additional editable columns to support user selection of values from a list, perform the
following steps:
1. Create a table in the Allocation schema to hold the list of values for the column. This list must
use a single column as its key.
2. Add the table in Allocation Database Setup step 1 (on page 91) as a list source table.
3. Create a non-hierarchical group in Allocation Database Setup step 3 (on page 93) to represent
the data. Identify the list source table for the group. Select the column that holds the values as
the code column.
4. Associate this group to the appropriate column on the list source table as well as the desired
column on the WorkList table in step 5 (on page 95). Set the WorkList column to be editable.
5. In step 9 (on page 99), configure the main key for this list source to be the single value
column.
After this configuration is complete, a user can enter a value into the column by selecting it from a list.
The control also supports manual editing of the data as well as pasting of a value from the clipboard. If
the data value must be constrained to entries on the list, an update trigger can be created to reject
any invalid entries.
Set the key for the WorkList table

You must set a Main Key for each table. For the WorkList, this unique key contains the WorkList Key
column only.
Set up merchandise IDs

The merchandise ID (Unique Merchandise ID or UMID) is the item to be allocated; for example, it
might be the style code, part number, product ID, or UPC number. This UMID is used as the top level
of merchandise, level 0 in the database.

Set up the WorkList
The merchandise ID should be a unique value. If you have the same style number used for different
products (for example, style number 21361 refers to both teapots and tea towels, depending on the
department and class), you must add additional columns from the WorkList to ensure uniqueness. In
this example, you would need to add a column for Department and a column for Class. If you are using
the built-in data collect, the merchandise ID must consist of groups in your hierarchy. You must
determine the separator character during database setup if you are using multiple columns
concatenated to make up your UMID. Like all WorkSheet levels, the UMID (level 0) must use a text
data type. If it consists of concatenated fields to make the value unique, then it will automatically be
treated as text; however, if it consists of only one WorkList field, such as STYLE_NUMBER, then that
field must be a text data type on the WorkList.
You must decide on the shapes of merchandise your system deals with, and what information defines
each one of the shapes. These shapes are known as merchandise types. The merchandise type is a
number assigned during database setup that describes the shape of the merchandise. Only WorkList
lines with the same merchandise type can be allocated together.
UMIDs and merchandise types are set up in Step 10 of Database Setup. See "Step 10: Set up
merchandise types" (on page 101) for details.
Where is the merchandise ID used?

You see the merchandise ID as the style dimension in the WorkSheet. It is also written to the results
table as the code that defines the merchandise that has been allocated. You must make sure that you
create a merchandise ID that your transaction management system can understand. It must contain
enough information to uniquely identify the merchandise.
Set up merchandise types

Each line in the WorkList table must:
 Have a merchandise type associated with it. This information must come from your transaction
management system.
 Contain all information used to define the merchandise ID.
Set up the merchandise types using the Database Setup utility. You must also set up the merchandise
separator character using the Database Setup utility.
Merchandise types and Shape tables

Each merchandise type can be associated with a Merchandise Shape table to look in to read the
merchandise information.
If a particular type of merchandise does not have a Shape table (for example, if all merchandise
information is stored on the WorkList line), you can choose to associate the merchandise type with no
Shape table.
Bulk merchandise
For bulk merchandise, the merchandise ID must be made from columns in the WorkList only.
Pack merchandise
For pack merchandise that contains the pack information in a Merchandise Shape table, the
merchandise ID must be composed of columns from the WorkList, with the Pack ID column from the
Shape table added as the final column.

Set up the WorkList
If you do not have a Shape table for a particular type of pack merchandise, and all pack description
columns are on the WorkList, your merchandise ID must be composed of columns from the WorkList,
with the Pack ID column from the WorkList added as the final column.
Set up Merchandise Shape tables

Merchandise Shape tables contain information that further describes the composition of the
merchandise; for example, the quantities of small, medium, and large sizes in a collection of red T-
shirts. You can have several Shape tables in your database. The merchandise type entry in the
WorkList line specifies which Shape table is appropriate.
Note: If a variation of an item is included in the Shape table for a WorkList key, it will be present
when a user takes the line into the WorkSheet, even if the available quantity is zero units. This allows
all the product’s variations to be present in the WorkSheet for visualization of current stock or proper
application of percentage size curves.
When the distributor views the WorkList line, the application checks the Shape table associated with
the WorkList line, and finds the rows that have the same WorkList key as the WorkList line. When each
WorkList line is written to the WorkList table, the rows of the relevant Shape table must be filled in at
the same time.
If your merchandise does not have information below the style level (for example, no sizes associated
with the style) you do not need a Shape table. If your merchandise has only a single combination of
levels (for example, one style, one color, and no sizes), you can store all merchandise information on
the WorkList, rather than in a Shape table.
See "Merchandise Shape tables" (on page 119) for an example of a Merchandise Shape table.
Define the composition of bulk merchandise

If your collection of merchandise contains extra levels that must be allocated, you must have a Shape
table associated with the WorkList line.
For example, if you have a collection of style 110 (men's polo shirts) with colors red, black, and blue,
in sizes small, medium, and large, you would have a Style column in the WorkList table, and a Shape
table with Color and Size columns. For each combination of size and color (small black polo shirts,
large red polo shirts, and so on), you would tell JDA Allocation the available quantity (100 small black
shirts, 150 large red shirts, and so on).
Define the composition of packs of merchandise

If your merchandise is received in packs, you need to have a Shape table to describe the components
of the pack, or include the pack columns in the WorkList.
For example, if you have packs of T-shirts that have small, medium, and large sizes in black, navy,
and maroon colors, you might have a Shape table specify how many of each color-size combination are
in each pack.
Caution: If you have two packs with the same merchandise ID, they must be identical in composition
and size. For example, within style 100.ABC, you have pack A; this pack is made up of three small,
two medium, and two large white T-shirts; a total of seven units. Accordingly, the merchandise ID
100.ABC.A can be used only for a pack comprising three small, two medium, and two large white T-
shirts.
Merchandise Shape tables for bulk

Merchandise Shape tables for bulk merchandise (merchandise that is allocated in units rather than
packs) specify how much of each allocable merchandise type is available in the collection; for example,
how many of each size-color combination.

Set up the WorkList
When you set up Shape tables for bulk, you create columns for the levels of detail and the quantity
available for allocation. For example, if the WorkList table contains style information and you want to
allocate down to the color and size level, you need to create columns for color, size, and quantity
available for allocation.
You also have to include the WorkList key. The Main Key of the Shape table must contain the WorkList
key first, plus the extra level information. In the above example, it would be WorkList key, color, and
size.
Include the following columns for a bulk Shape table.
 WorkList Key
 Levels
 Available Quantity
WorkList key
The WorkList key in a Shape table matches the WorkList key in the WorkList table. It is used to match
the WorkList line with the relevant merchandise information.
Levels
Add columns for the information that defines the composition of the merchandise: size, color, width,
and so on. These must be defined as levels using Database Setup. See "Step 6: Define the levels" (on
All allocable levels, such as UMID, color, and size levels, must be defined as VARCHAR2 columns. Text
data cannot have leading or trailing spaces.
Available Quantity
Add a column that specifies how much merchandise is available for each combination of levels.
Merchandise Shape tables for packs

Merchandise Shape tables for pack merchandise specify how much of each allocable merchandise type
is available in each pack, for example, how many of each size-color combination. Packs do not support
more than one UMID per pack.
When you set up Shape tables for merchandise that is ordered in packs, you must create columns for
the levels of detail and pack information. For example, because the WorkList table contains style
information, you need to create columns for Color, Size, Pack ID, Number of Packs, and Quantity per
Pack, if you want to allocate down to the color and size level.
You also must include the WorkList key. The Main Key of the Shape table must contain the WorkList
key first, then pack ID, followed by the extra level information. In the above example, it would be
WorkList key, pack ID, color, and size.
You can include all pack columns (Pack ID, Number of Packs, and Quantity per Pack) in the WorkList,
or include all columns in a Shape table. However, you cannot have some pack columns in a Shape
table and some in the WorkList.

Set up the WorkList
You can optionally include a Preferred Pack column, which the system will use in combination with the
Prioritize Preferred Packs allocation control option. It allows for the identification of specific packs that
the system will tend to allocate in favor of other packs by slightly increasing the calculation engine’s
tolerance for variation between the preferred pack’s shape and the allocation target values. This
increases the likelihood that the preferred pack would be allocated as opposed to other packs of the
same merchandise. The column allows the attribute to be set systematically; however, it can also be
set by an end user.
You must include the following columns for a pack Shape table.
 WorkList Key
 Pack ID
 Number of Packs
 Quantity per Pack
 Levels
WorkList Key
The WorkList key in a Shape table matches the WorkList key in the WorkList table. It is used to match
the WorkList line with the relevant merchandise information.
Pack ID
The Pack ID column identifies the pack. This column must be used as the last column in the
merchandise type for the pack. It is in the WorkSheet as part of the merchandise identifier code. You
can have more than one pack ID for each WorkList line, if the pack ID is on the Shape table.
Number of Packs
The Number of Packs, along with the Quantity per Pack, is used to determine how much merchandise
is available for allocation. The number of packs must be the same throughout the same pack ID for a
WorkList line. For example, if you have a WorkList line that contains merchandise in three pack types,
A, B, and C, all Shape table records for that WorkList line that contain pack A must contain the same
number of packs; you cannot have more than one quantity of packs for a single pack.
Quantity per Pack

The Quantity per Pack, along with the Number of Packs, is used to determine how much merchandise
is available for allocation.
Levels
You must add columns for the information that defines the composition of the pack: size, color, width,
and so on. These must be defined as levels using Database Setup. See "Step 6: Define the levels" (on
The composition of the pack is available for viewing by distributors to help them make decisions. JDA
Allocation supports the determination of store Need for the individual components of a pack, and
determines the best combination of available packs to meet store Need.
All allocable levels, such as UMID, color, and size levels, must be defined as VARCHAR2 columns. Text
data cannot have leading or trailing spaces.

Set up the WorkList
Preferred Pack
If this column is included, it must be mapped on step 9 of Allocation Database Setup and the
functionality enabled on step 11. The Preferred Pack column must be a single alphanumeric character
with, for example, the data type CHAR. Acceptable values are ‘Y’ and ‘N’.
Set up detail tables

Detail tables provide extra information about lines in the WorkList table. For example, if several lines
of 60 characters each of PO comments are available for some POs on your transaction management
system, you can set up a detail table to provide the extra information.
Each detail table contains one or more columns from the WorkList table. The lines in the detail table
are matched to lines in the WorkList for every detail table you have defined, and display the extra
information to the distributor.
You can create as many detail tables as you need. The only requirement is that the Main Key of each
table contains at least one column that is mapped to a column in the WorkList table.
Use Database Setup to map one or more of the primary key columns to the WorkList. See "Mapping
columns to WorkList columns" (on page 101) for details.
See "Detail tables" (on page 122) for an example detail table.
Set up List Source tables

List Source tables contain lists of possible values for group members. For example, the table DEPTS
may contain the list of all possible departments for the group Department.
The primary key column or columns in the List Source table identify the code for the member, and
another column contains the display name for the member.
For example, if you have Department codes that are unique, your Department's List Source table
would contain two columns: the Dept_Code column (the primary key) and the Dept_Name column.
If you have Class codes that are not unique, but are used in different Departments, you would use two
columns for the primary key, Dept_Code and Class_Code, and a Class_Name column to hold the name
for each class.
CLASSES Column name Group Main key Mapped to

Dept_Code Department 1
Class_Code Class 2 Code
Class_Name Name
Dept_Code Class_Code Class_Name

100 110 T-shirts
100 105 Shorts
200 110 Towels
It is important that the order of the primary key columns in a List Source table matches the order of
the groups in the hierarchy. In the example above, Department must come immediately before Class
in the hierarchy.

Set up the WorkList
Specify the List Source table to use during Database Setup, and the columns that refer to the code and
display name. If you have multiple columns in the primary key, select the last column in the primary
key as the code. In the example above, use Class_Code as the code, and Class_Name as the display
name. See "Step 3: Define the groups" (on page 93) for details.
Use the Database Setup utility for the WorkList, Shape,

and Detail tables
After you create your User tables, use the Database Setup utility to provide the structure and
mappings of the tables. See "Use the Database Setup utility" (on page 87) for full details of using
Database Setup.
Populate the WorkList tables

After you design and set up the WorkList tables, you must set up procedures to write information to
them, when there is merchandise to be allocated. For example, if you have decided to allocate
merchandise after it has been received in your DC, you must modify your transaction management
system to output the relevant WorkList table and Merchandise Shape table rows for each collection of
merchandise, as soon as the detail counts have been entered.
This procedure must transfer information automatically from your transaction management system to
the Allocation database.
Discrepancies
If you write information to the WorkList when merchandise has been ordered, you may find the
merchandise you receive does not match exactly what you ordered. Your distributors may have
allocated the merchandise already, based on the wrong figures.
Update quantities
To force the application to re-read the merchandise details, you must update the relevant values in the
WorkList line and associated Merchandise Shape table. This update can be done for WorkList keys in
an Available status. For Approved or Unapproved allocations, if the values are different from what was
originally allocated, update the values, and set the allocation status code of the relevant WorkList lines
to 25 and the status description to Discrepancy.
Remember original quantities

If you want the distributors to see the original quantities that were allocated, you can copy the original
available quantities into an unmapped column on the shape table, whenever you make changes to the
quantities.
Restricted status codes

If the WorkList line is in a restricted code status (Error Writing Results or Writing Results), there is no
way to know whether the allocation will have a status of Approved, Unapproved, or Released. You
must wait until results writing is finished before attempting to update the quantities.
Procedures for discrepancies

Note: This method does not work for In Progress WorkList lines.
If a discrepancy occurs for Available, Approved, or Unapproved merchandise, do the following.

Set up the WorkList
 Set the Status Code column to 99, because the application never uses that number. Set the
status description to Locked and update the Status Change Timestamp.
This update prevents anyone from working on the WorkList line while you are making changes. If the
WorkList line forms only part of an allocation, the rest of the lines also should be locked.
 Update the relevant quantities in the WorkList line and associated Merchandise Shape table.
 Optionally, copy the original quantities to another column.
 If the merchandise is Approved or Unapproved, set the status code of the WorkList line to 25, and
the status description to Discrepancy. Set the status code to 25 and the status description to
Discrepancy for all other WorkList lines that make up the same allocation.
 If the merchandise is Available, set the status code to 10.
 Update the Status Change Timestamp for all relevant lines.
If a discrepancy occurs for In Progress merchandise, wait until the allocation is no longer In Progress,
then attempt the update again, following these rules, based on its new status code.
 If it is in Released status, an update is not allowed.
 If it is in Approved or Unapproved status, set it to Discrepancy status.
 If it is in Available status, update.
 If it is in any other state, an update is not allowed, but can be attempted again later.
Release multiple WorkList lines

To select more lines for Release from the WorkList than are displayed on your current screen, you
must allow the screen to refresh each time as you page down. This refresh leaves the Release function
enabled. If the screen is allowed to refresh during multi-page line selection, JDA Allocation is able to
load all data and verify each line is in Approved status.
If you use the Shift function to select a large block of lines across multiple pages, the rows in the
middle may not be refreshed, and will not get loaded. Because JDA Allocation cannot determine the
status of those lines, it disables the Release function.
This behavior is intentional and acts to reduce the amount of memory overhead used when accessing
the WorkList.
Release pre-allocated merchandise when goods are

received
Automatically releasing allocations that match incoming receipts eliminates the need for manual
intervention that slows down the process. You can activate the release process for an entire allocation
or an individual WorkList line, using an application program interface (API).
Note: Some lines in the following example have wrapped due to page width and are actually on the
same line.
Example for AllocAutoRelease.ReleaseWorklistLine

SET ECHO OFF
SET TERMOUT ON
SET SERVEROUTPUT ON

Set up the WorkList
DECLARE
result NUMBER := -1; -- This will be set by the function on return
worklistKey NUMBER := 9999; -- Just a test number
BEGIN
-- Call the function

result := allocautorelease.releaseworklistline(WorkList_key => WorkListKey);
IF result = allocautorelease.RELEASE_SUCCESSFUL THEN

dbms_output.put_line('Release successful');
ELSIF result = allocautorelease.KEY_OR_NUMBER_NOT_FOUND THEN

dbms_output.put_line('WorkList key or allocation number not found; nothing
released');
ELSIF result = allocautorelease.WRONG_STATUS THEN

dbms_output.put_line('WorkList key or allocation number found but was in the wrong
status; nothing released');
ELSE
dbms_output.put_line('An Oracle error occurred: error code = ' || result );
END IF;
END;
/
Example for AllocAutoRelease.ReleaseAllocation

SET ECHO OFF
SET TERMOUT ON
SET SERVEROUTPUT ON
DECLARE
result NUMBER := -1; -- This will be set by the function
on return
allocationNumber NUMBER := 9999; -- Just a test number
BEGIN
-- Call the function

result := allocautorelease.releaseallocation(allocnumber => allocationNumber);
IF result = allocautorelease.RELEASE_SUCCESSFUL THEN

dbms_output.put_line('Release successful');
ELSIF result = allocautorelease.KEY_OR_NUMBER_NOT_FOUND THEN

dbms_output.put_line('WorkList key or allocation number not found; nothing
released');
ELSIF result = allocautorelease.WRONG_STATUS THEN

dbms_output.put_line('WorkList key or allocation number found but was in the wrong
status; nothing released');
ELSE
dbms_output.put_line('An Oracle error occurred: error code = ' || result );
END IF;
END;
/

Set up host data collect procedures
Chapter 7. Set up host data collect procedures

The data collect process obtains actual or planned data and passes it to the application so it can be
considered when distributing merchandise.
Merchandise is distributed based on the Need of each location. Need can be based on actual data from
your transaction management system, data from other systems, or planned data from your JDA
planning system.
To collect data to calculate the Need based on actual data, you must read the specifications for the
data required, obtain the relevant data from the data source (for example, your transaction
management system), and write this information in a form that can be understood. The information is
written to the appropriate format tables. You must create these format tables to hold the information
you want to use in calculating the Need of each location.
For definitions of the Data Collection tables, see "Table definitions" (on page 105).
Data collection system tables

You need to use the following system tables for host data collection.
 QUEUE_OUT table
 QUEUE_IN table
 DC_FORMAT_HEADER table
 DC_RULE_HEADER table
 DC_RULE_DETAIL table
 RTMM_GROUPS table
 DC_COND_HEADER table
 DC_COND_DETAIL table
Set up tables to hold collected data

A format table contains columns which hold collected data that the allocators want to use to determine
the store Need. You must set up these format tables to hold collected data. Each request for data (data
collect rule) is associated with a single format table to which the results must be sent.
Each format table must contain a column for the location ID, which represents the store to which the
results pertain. It must also contain a column for the allocation number of the merchandise. An
allocation number is assigned to a WorkList line when the process of allocation begins.
You must create columns on the format table for the following items.
 Variable components. Each component of the Need variables that the distributors use must be
included in a format table. For example, SALES_01AGO.
 Levels. A level is a product dimension/variation present in the WorkSheet. This begins with level 0,
the UMID, and goes all the way down to the lowest variation. For example, your levels below 0
might be assigned as level 1: color, level 2: size, and level 3: width. Levels only exist at the unique
merchandise level and below and must be included in a format table in which data is collected .
The levels are defined in Step 6 of Database Setup.

 Hierarchy group members. The hierarchies are created by naming them and selecting their groups
(members) in Step 4 of Database Setup. If you are using the Like Store Support functionality, you
must include all members of the Like Store hierarchy range for which data is collected in the
format table. The Like Store Hierarchy Range is defined in Step 8 of Database Setup. If you put
groups above level 0 in your format table, be sure your data collect procedure never populates
more than one record per location above level 0.
 Variable Key. If your business requires multiple levels of collected data to be used in a single Need
calculation, then the collected data must also be identified by Variable Key. This column must be
mapped in the optional columns in Allocation Database Setup.
Use the Database Setup utility to provide (Step 1) the names of the tables, associate (Step 5) the
hierarchy groups to the format table columns, and map (Step 9) the required columns (Location ID
and Allocation Number), optional columns (Level), and optional variable key.
Note: Variable columns that are mapped to logical fields in Step 9 will be populated by Allocation. The
data populated by Allocation could override any custom data collect. These variable columns include
the following logical fields on the format table:
 Prior Results
 Data Collect CAQ
 Model Threshold
 Model Target
Variable components
You must add columns for the components the distributors want to use in creating variables, such as
sales, stock, or historical sales.
For example, if a distributor wants to create a Need variable based on sales over three weeks, defined
by:
Sales3Weeks = Sales_01Ago + Sales_02Ago + Sales_03Ago

you would create columns for Sales_01Ago, Sales_02Ago, and Sales_03Ago. These columns become
the base variables from which users can create their derived variables.
When the data collect process is run, the data collect procedure collects the information for
Sales_01Ago, Sales_02Ago ,and Sales_03Ago, and stores it in the format table, so a value for
Sales3Weeks can be obtained.
Descriptions for base variables

You cannot include spaces or Oracle reserved words (for example, SIZE) in the descriptions you enter
for the base variable columns for your format tables.
Levels
If you want to use low-level Need, you must add columns for the merchandise levels. For example, if
you are allocating a collection of shirts in small, medium, and large sizes, and you collect data for
small, medium, and large sizes, you must have a column for the size code in the format table so the
correct data is used for the correct merchandise.
In this situation, there is more than one line of data for each location ID; there should be three rows,
one for each size.

All allocable levels, such as style, color, and size levels, must be defined as VARCHAR2 columns. When
the format table is populated, any level columns that are not used for the current allocation must be
left null.
For example, when the table contains columns for style, color, and size, but the distributor has
requested data at the style level, the column for Style contains the style ID for the merchandise being
allocated, but the color and size columns contain nulls.
Unique Merchandise ID
If you plan to collect data at the UMID level (level 0), you must populate the UMID column with the
merchandise ID used when displaying the merchandise.
For example, if the merchandise ID comprises the Department, Class, and Style columns concatenated
with a period as the separator, and the merchandise is from Department 100, Class 150, Style ABC,
you must populate the UMID column of the format table with 100.150.ABC. Alternatively, your UMID
could simply be constructed of the Style, because it is unique on its own. In this case, the UMID
column of the format table would contain ABC.
You must include columns for the members of your merchandise hierarchy, for example, Division,
Department, and Class, when using the Like Store Support function.
The application does not support multiple records per location above the unique merchandise (level 0)
on a format table for single data collect request.
Main Key
This key must comprise the allocation number, location ID, and all appropriate level columns; for
example, allocation number, location ID, UMID, color, and size. This key is not a primary key on the
format table. See "Format table indexes" (on page 125) for details on performance enhancements.
Clean up format tables

You must set up procedures to delete old data from format tables because the application never
removes data from format tables. However, you must not delete data from format tables while
distributors are working. We suggest you remove data from your format tables every night as a batch
process. Your database administrator can tell you the best way to remove data. Keep in mind that the
ability to review Need for jobs performed by the Auto-Allocation process depends on the format table
records being available. It may be appropriate for the nightly cleanup process to not delete records
from the format tables until the corresponding allocation has been released.
Sample format table

The following format table could be used to store three weeks' sales and the current stock for
merchandise down to the style/color/size level.
SALES_STOCK column name Unique key Mapped to

Allocation_Nbr 1 Allocation number
Location_ID 2 Location ID
UMID 3 Level 0
Color_Code 4 Level 1
Size_Code 5 Level 2
Sales_01Ago
Sales_02Ago
Sales_03Ago

SALES_STOCK column name Unique key Mapped to

Current_Stock
You can use this table for collected data at the following levels.
 Department
 Class
 Style
 Color
 Size
Style/Color/Size level example

For example, if you receive a request for data for merchandise:
Dept=01; Class=014; Style=ABC; Color=024; Size=044

you might populate the table with the following:
Style/Color/Size level data column Data Data Data

Allocation_Nbr 1005 1005 1005
Location_ID 030 030 030
UMID 01.014.ABC 01.014.ABC 01.014.ABC
Color_Code 024 024 024
Size_Code 044 045 046
Sales_01Ago 150 120 100
Sales_02Ago 165 135 120
Sales_03Ago 140 135 140
Current_Stock 295 400 350
You would populate the table for each location; this example shows data for location 030 only.
Style level example

If you receive a request for data for merchandise:
Dept=01; Class=014; Style=ABC

Style level data column Data

Allocation_Nbr 1005
Location_ID 030
UMID 01.014.ABC
Color_Code


Size_Code
Sales_01Ago 600
Sales_02Ago 750
Sales_03Ago 650
Current_Stock 1200
Again, you would populate the table with data for all locations.
Class level example

Dept=01; Class=014

Allocation_Nbr 1005
Location_ID 030
UMID
Color_Code
Size_Code
Sales_01Ago 1205
Sales_02Ago 1507
Sales_03Ago 1375
Current_Stock 3500
Class level with more than one class example

Dept=01; Class=014
Dept=01; Class=028

Allocation_Nbr 1005
Location_ID 030
UMID
Color_Code
Size_Code
Sales_01Ago 1205
Sales_02Ago 1507
Sales_03Ago 1375
Current_Stock 3500

You can have only one value per variable per store, if the data collect is above the unique merchandise
level; in this example, Department or Class. If you collect for more than one class, you sum or average
the values for each class and transfer the values for the variables to the format table.
Note: The built in data collect will sum the data, if collecting for more than one member above level 0
in a data collect request.
Data collect hierarchy ranges

You must set up hierarchy ranges for data collect; these ranges are used by the administrator to build
data collect levels. See "Set up data collect" (on page 153) for details.
You must use Database Setup to set up these ranges. See "Use the Database Setup utility" (on page
87) for full details.
You must create and set up your format tables and parameters before creating a data collect range.
Set up a data collect level hierarchy range

1. Start Database Setup.
2. Go to "Step 8: Set up hierarchy ranges and associations" (on page 97) of Database Setup.
3. Select Data Collect from the list.
4. Click New.
5. Select Product as the dimension.
6. Select the Format table for which you want to be able to create data collect levels.
7. Select the Parameter, if any, you want for the current range.
8. Select your main hierarchy from the Hierarchy list.
9. Select the first member of the hierarchy you want to use in data collect levels from the Start
Group list.
10. Select the last member of the hierarchy you want to use in data collect levels from the Stop
Group list.
11. Click Set.
12. If you want to add non-hierarchical groups to data collect levels, click Associate. See "Change
associated groups" (on page 99) for details.
Data collect parameters

Data collect parameters are an optional feature of JDA Allocation. You set them up to give your data
collect program additional information about a specific data collect request. For example, you normally
may collect data by Size for a Style, but you sometimes may want to collect data by Size for the entire
Class. A special data collect parameter can be used to instruct the data collect engine to collect Size
data for all Styles in the Class.
Set up data collect parameters

1. On "Step 7" (on page 96) of the Database Setup utility, enter a parameter code and description.
(Reserved parameter codes are A and H.)

2. When building a data collect range on "Step 8" (on page 97) of the Database Setup utility, select
the appropriate parameter.
A resulting data collect rule built from this data collect range will contain the parameter value. This rule
can be used by the data collect engine to apply special rules to the data collect.
Collect data
Data collection on demand occurs when the distributor requests a data collect from the application. For
collection of actual data, you must collect the data, and present it in a specified format table, which
can use the information to determine the Need of each location. If you are not using the built in data
collect, you must implement a custom data collect.
Note: If your business requires multiple levels of collected data to be used in a single Need calculation,
then multiple data collect requests can be issued at the same time for a single allocation. If you find
that this causes your server to become overburdened, you may want to process these requests serially
by user.
Set up custom data collect procedures

You must set up procedures on the host system to carry out the following steps.
1. Periodically read the QUEUE_OUT table in the Allocation database. This table contains the list of
actions to be performed by the host system.
The QUEUE_OUT table has the following columns.
 Queue_ID: This column contains a sequential number that identifies the queue entry. Process
the queue entries with the lowest queue IDs first.
 Queue_Entry_Type: For data collect requests, this column is set to RULE (carry out the
specified data collect rule).
 DC_Rule_Key: This column specifies the data collect rule to be implemented. The rule
determines the data to be collected and to which format table the data should be written.
 DC_Cond_Nbr: This column is no longer used and is set to 0.
 Allocation_Nbr: This number identifies the request and is written to the QUEUE_IN table to
specify the request for which data has been collected. Each request for data collection has a
unique allocation number.
 Action: For data collect requests, this column is set to COLLECT.
 CreateUser, CreateDate, UpdateUser, UpdateDate: These four columns provide information on

the queue entries. They are not used by the application.
 XMLRequest: This column contains an XML description of the data collect request. See "XML
data collect example" (on page 60).
 XML_REQUEST: This column serves the same purpose as the XMLRequest column, but
supports larger values. The XMLRequest column has been maintained for historical purposes.
Example
The QUEUE_OUT TABLE might contain the following information:
 Queue_ID: 1
 Queue_Entry_Type: RULE

 DC_Rule_Key: 83
 DC_Cond_Nbr: 0
 Allocation_Nbr: 1005
 Action: COLLECT
 XMLRequest / XML_REQUEST: See "XML data collect example" (on page 60).
2. Read the DC_RULE_HEADER and DC_FORMAT_HEADER tables to find the format table associated
with the rule. Delete any records in the format table for the current allocation.
Note: If your business requires multiple levels of collected data to be used in a single Need
calculation, then use the VARIABLE_KEY value from the DC_RULE_HEADER table to identify both
the data on the format table as well as the QUEUE_IN record. When cleaning the format table as
part of the data collect process, delete records by allocation number and variable key.
Match the contents of the DC_Rule_Key column of the QUEUE_OUT table to the DC_Rule_Key
column in the DC_RULE_HEADER table. The DC_Format_Nbr column for that row contains the
number of the associated format table.
Note: After the QUEUE_OUT request is handled, it should be deleted. See "QUEUE_OUT" (on page
105).
Next, match the DC_Format_Nbr column in the DC_RULE_HEADER table to the DC_Format_Nbr
column in the DC_FORMAT_HEADER table. The Table_Name column for that row contains the
name of the format table to which the data collect results must be written.
Example
If the DC_Rule_Key in the QUEUE_OUT table is 83, you read the row in the DC_RULE_HEADER
table that has a DC_Rule_Key equal to 83.
This row might contain a DC_Format_Nbr of 3, meaning that results for data collect rule number
83 must be written to format table number 3.
You would read the row in the DC_FORMAT_HEADER table with DC_Format_Nbr equal to 3, and
find that the Table_Name column contains the entry SALES_STOCK, meaning that data collect
format table number 3 is the table SALES_STOCK. Therefore, results from data collect rule number
83 should be written to the format table SALES_STOCK. Before inserting any data into
SALES_STOCK, delete any records for Allocation_Nbr 1005.
3. Read the DC_RULE_DETAIL table to find out what data to collect.
You need to read the rows in the DC_RULE_DETAIL table that have the DC_Rule_Key that was in
the QUEUE_OUT table. These rows make up the data collect rule; this rule describes what data
must be collected.
A data collect rule is made up of phrases and components; a phrase might be "Collect data where
Department equals 100, Class equals 10, Style equals 20, and Price Point is greater than $10.99".
A component is part of a phrase; for example, "Department equals 100" is the first component of
the above phrase.
You can have multiple phrases if you have implemented parameters; each phrase must have a
different parameter.
The DC_Rule_Phrase_Nbr column in DC_RULE_DETAIL specifies the phrase number.
The DC_Rule_Component_Nbr column specifies the number of the component in the current
phrase.
The DC_Rule_Parameter_Code column specifies the parameter code for the current phrase.

The following columns make up a single component.
 Dimension_Nbr: This column specifies the dimension of the group. For example, dimension 1 is
the Product dimension.
 Group_Nbr: This column, together with the Dimension_Nbr column, specifies the number of
the group. For example, dimension 1, group 2 may be Department in your hierarchy.
Read the RTMM_GROUPS table to find out the group that is being specified. Look for the line with
the same Dimension_Nbr and Group_Nbr, and read the Group_Name column; this column provides
the name of the group to which the data collect rule applies.
 DC_Rule_Operand_Code: This column specifies the comparison operator for the group. The
DC_Rule_Operand_Code may be one of the following.
= equal to
<> not equal to
> greater than
>= greater than or equal to
< less than
<= less than or equal to
Note that the built-in data collect process supports only the "=" equal to operand code.
 DC_Rule_Value: The DC_Rule_Value specifies the values for which data is to be collected.
Example
For example, for a single component, if:
Dimension_Nbr 1
Group_Nbr 2
DC_Rule_Operand_Code =
DC_Rule_Value 100
these values translate to "Department = 100", if dimension 1, group 2 is referred to as

"Department" in the RTMM_GROUPS table.
4. Collect the data from your transaction management system, based on the rule. You must fill the
columns of the relevant format table.
Example
If the rule states "Collect data where Department equals 100, Class equals 10, Style equals 20,
and Price Point is greater than $10.99", and the associated format table SALES_STOCK contains
columns for:
 Allocation Number
 Location
 Sales3WeeksAgo
 OnHand
you collect the Sales3WeeksAgo and OnHand data for all locations, where Department equals 100,
Class equals 10, Style equals 20, and Price Point is greater than $10.99, and fill the table with the
results.

You would populate each row with the allocation number from the QUEUE_OUT table.
calculation, then also populate the mapped variable key column on the format table with the
variable key from the DC_RULE_HEADER table for the data collect request.
5. When the collect process has finished, write an entry to the QUEUE_IN table specifying the
allocation number from the QUEUE_OUT table to allow JDA Allocation to retrieve the results. In the
same transaction, delete the QUEUE_OUT record that initiated the request.
calculation, then update the QUEUE_IN variable key column with the variable key from the
DC_RULE_HEADER table for the data collect request.
Example
The QUEUE_IN TABLE might contain the following:

Allocation_Nbr 1005
JDA Allocation recognizes the allocation number (in this case, 1005) and looks in the format table
that applies to the current allocation. This table contains the requested data.
This step completes the process of data collection.
XML data collect example

Note: The XML_REQUEST field and XMLRequest field both can contain an XML data collect request.
The XMLRequest field is limited in length, and can only store up to a 16 kb request. If the request
exceeds 16 kb in length, it will be written to the XML_REQUEST field but not the XMLRequest field.
In the following example, the XML data collect request is for data collect rule 742 and allocation
number 797. The host phrase is Grp#2='01' AND Grp#3='181' AND Grp#4='23646SK'. (We ignore a
parameter code of type A, which is used for plan data.) The target format table is SALES_STOCK.
Support Partial Format Table Records is enabled, so only SALES1_AGO, SALES2_AGO, SALES3_AGO, and
SALES4_AGO need to be collected, but the host still must issue a delete for the current allocation
number.
<xml xmlns:aal="http://jda.com/arthur/allocation">
<aal:HOST_REQUEST>
<aal:QUEUE_OUT QUEUE_ID="343" QUEUE_ENTRY_TYPE="RULE" DC_RULE_KEY="742"
DC_COND_NBR="0" ALLOCATION_NBR="797" ACTION="COLLECT">
<aal:DC_RULE PARTIAL_DATA_COLLECT="Y" DC_RULE_KEY="742" DC_FORMAT_NBR="1">
<aal:DC_PHRASE DC_RULE_PARAMETER_CODE="H" HIERARCHY_NBR="1">
<aal:DC_COMPONENT GROUP_NBR="2" DC_RULE_OPERAND_CODE="="
DC_RULE_VALUE="01" />
DC_RULE_VALUE="23464SK" />
</aal:DC_PHRASE>
<aal:DC_PHRASE DC_RULE_PARAMETER_CODE="A" HIERARCHY_NBR="4">
</aal:DC_PHRASE>
<aal:FORMAT_TABLE DC_FORMAT_NBR="1" TABLE_NAME="SALES_STOCK">
<aal:COLUMN NAME="SALES1_AGO" />


</aal:FORMAT_TABLE>
</aal:DC_RULE>
</aal:QUEUE_OUT>
</aal:HOST_REQUEST>
</xml>
The XML_REQUEST contents use the following XML schema definition.
<xs:schema id="xml" targetNamespace="http://jda.com/arthur/allocation"

xmlns:mstns="http://jda.com/arthur/allocation"
xmlns="http://jda.com/arthur/allocation" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" attributeFormDefault="qualified"
elementFormDefault="qualified">
<xs:complexType name="HostRequestType">
<xs:sequence>
<xs:element name="QUEUE_OUT" type="mstns:QueueOutType" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="QueueOutType">
<xs:sequence>
<xs:element name="DC_RULE" type="mstns:RuleType" minOccurs="0"
</xs:sequence>
<xs:attribute name="QUEUE_ID" form="unqualified" type="xs:integer" />
<xs:attribute name="QUEUE_ENTRY_TYPE" form="unqualified" type="xs:string" />
<xs:attribute name="DC_RULE_KEY" form="unqualified" type="xs:integer" />
<xs:attribute name="DC_COND_NBR" form="unqualified" type="xs:integer" />
<xs:attribute name="ALLOCATION_NBR" form="unqualified" type="xs:integer" />
<xs:attribute name="ACTION" form="unqualified" type="xs:string" />
</xs:complexType>
<xs:complexType name="RuleType">
<xs:sequence>
<xs:element name="DC_PHRASE" type="mstns:PhraseType" minOccurs="0"
<xs:element name="FORMAT_TABLE" type="mstns:FormatTableType" minOccurs="0"
</xs:sequence>
<xs:attribute name="PARTIAL_DATA_COLLECT" form="unqualified" type="xs:string" />
<xs:attribute name="DC_RULE_KEY" form="unqualified" type="xs:integer" />
<xs:attribute name="DC_FORMAT_NBR" form="unqualified" type="xs:integer" />
</xs:complexType>
<xs:complexType name="PhraseType">
<xs:sequence>
<xs:element name="DC_COMPONENT" type="mstns:ComponentType" minOccurs="0"
</xs:sequence>
<xs:attribute name="DC_RULE_PARAMETER_CODE" form="unqualified" type="xs:string"
/>
<xs:attribute name="HIERARCHY_NBR" form="unqualified" type="xs:integer" />
</xs:complexType>
<xs:complexType name="ComponentType">
<xs:attribute name="GROUP_NBR" form="unqualified" type="xs:integer" />
<xs:attribute name="DC_RULE_OPERAND_CODE" form="unqualified" type="xs:string" />
<xs:attribute name="DC_RULE_VALUE" form="unqualified" type="xs:string" />
</xs:complexType>
<xs:complexType name="FormatTableType">
<xs:sequence>
<xs:element name="COLUMN" type="mstns:ColumnType" minOccurs="0"
</xs:sequence>
<xs:attribute name="DC_FORMAT_NBR" form="unqualified" type="xs:integer" />

<xs:attribute name="TABLE_NAME" form="unqualified" type="xs:string" />

</xs:complexType>
<xs:complexType name="ColumnType">
<xs:attribute name="NAME" form="unqualified" type="xs:string" />
</xs:complexType>
<xs:element name="xml" msdata:IsDataSet="true" msdata:EnforceConstraints="False">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="HOST_REQUEST" type="mstns:HostRequestType" />
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
Report errors from the data collect process

Use the Status column of the QUEUE_IN table to report errors that may have occurred during the data
collect process.
If the data collect completed successfully, leave the Status column null.
If the data collect did not complete successfully, write a message to the Status column. This message
is interpreted as a failure, and the message is displayed to the user.
calculation, then update the QUEUE_IN variable key column with the variable key from the
DC_RULE_HEADER table for the data collect request. If any pieces of a multi-level data-collect request
report an error, the system will wait until the remaining requests finish before presenting that error to
the user.
Data Collects tile on the Administrator Dashboard

Monitor data collect processes
Note: This does not apply to the JDA Allocation built-in data collect process.
Use the Data Collects tile on the Administrator Dashboard to monitor the state of active host data-
collect processes, and also instruct JDA Allocation to stop waiting for a data collect process that is not
responding.
For more information, see the Online Expert (OLE) by selecting Help within Allocation Administration.
View data collect events

Use the Data Collects tile on the Administrator Dashboard to view data collect errors and warnings that
have occurred in the system.
For more information, see the Online Expert (OLE) by selecting Help within Allocation Administration.
Use the built-in data collect for performance data

To use the built-in data collect functionality, staging areas need to be created at every level (such as
Class, Size, and Department) for which you intend to collect data. These areas can be tables or
summarized views of the data. These tables must have the same level column names and variable
column names as the format tables, with the exception of mapped variables such as DCAQ and PR. In
addition, column names for levels above style need to match exactly the group names used in
Database Setup.

There is a sample script that can be used to create the staging areas. The sample script can be found
in SCRIPTS\SAMPLES. It creates staging area tables for Actual_Size and Actual_Class, and staging
area views of those tables for Actual_Division, Actual_Department, Actual_Style, and Actual_Color.
Summarizing historical data from the lowest level to the highest level using a view is not
recommended, unless performance tests yield acceptable timings.
The administrator specifies the names of the staging areas in Step 1 of Database Setup. You select the
type of table called Staging to identify staging areas. See "Step 1: Enter the table names" (on page
91) for details.
In Step 3 of Database Setup, you associate a staging area with a group. For each group, the
administrator selects a staging area from the list and clicks Set. The application performs all required
mappings and groups associations for all staging areas. There is no need to supply information for any
staging area table in Step 5 or Step 9 of Database Setup. See "Step 3: Define the groups" (on page
93) for details.
To enable built-in data collect, select the Enable Built-In Data Collect option in Step 11 of Database
Setup. See "Step 11: Set the JDA Allocation system parameters" (on page 103) for details. If you
select the Enable Host Data Collect option in Step 11 of Database Setup, you have to provide a data
collect procedure.
The built-in data collect from the staging areas only collects following a standard hierarchy, including
any non-hierarchical groups associated with hierarchical groups in the data collect range on Allocation
Database Setup Step 8. You are able to collect in conjunction with or instead of our process by
enabling both the Built-In Data Collect as well as the Host Data Collect options. If you enable both
options, the custom data collect procedure needs to purge the format table records for the current
allocation, even if USE_BUILT_IN_DC will be set to Y. If the database is configured to support multiple
levels of collected data, then this purge is keyed by allocation number and variable key. When a data
collect is initiated, the application waits until the Host Data Collect has updated the QUEUE_IN table
before performing the built-in data collect. The QUEUE_IN record indicates whether a built-in data
collect is required. To facilitate this data collect, a column called USE_BUILT_IN_DC is on the
QUEUE_IN table. Set this parameter to Y to use the built-in data collect.
Note: The built-in data collect procedure has an internal limit on the size of the data collect rule that
can be used. Many aspects of the implementation configuration come into play that can affect what fits
within this limit. However, a general approximation for most implementations is that the built-in data
collect will likely support up to a 100 phrase data collect rule at the size level. As the default behavior
is that each WorkList key being allocated generates one phrase, this means that the limit of built-in
data collect should allow a data collect for up to 100 WorkList keys.
Like Store Data Collect

Like store rules are applied after the data has been collected. The group columns in each row of
collected data on the format table are used to identify which rules to apply and where to apply them.
The DBA must add all members included in the like store hierarchy range as columns to the Format
Table.
Note: Using group columns on the format table to determine like store rule application means that if
you have a custom or alternate hierarchy data collect, you must decide how to populate these group
columns based on the data collect request (or on whatever you decide to use).
The Like Store column on the format table is populated with the like store number or like store
selection to indicate to the allocator that a like store rule has been applied during the data collect. The
like store column is always available for display on the WorkSheet via member select when it is
mapped. The Like Store column is listed in the Non-Variables folder in the Variable Edit dialog box.
Note: The like store/selection is still listed in the column, even if the Need calc does not reference
variables selected for inclusion in like store functionality.

Set up Planning data collect
Chapter 8. Set up Planning data collect

JDA Allocation (AL) collects Enterprise Planning (EP) and Assortment Planning (AP) data from the
Enterprise Knowledge Base (EKB), using the Enterprise Planning (EP) Mid-Tier application server
software. To collect EP or AP data for AL use, the plan measures must exist by location at some
calendar level member (often week) for levels in the product dimension that correspond to unique
products or product groups in Allocation.
Alternatively, JDA Allocation collects assortment data from the Buying and Assortment Management
(Assortment) database in a similar manner.
Use EP or AP data from EKB

To set up EKB data collection, perform the following steps.
1. Configure the database using Allocation Database Setup.
If the database is configured to use product and location structure data from EKB, go to the next
step.
For other databases, ensure that your level names on step 6 are valid Oracle column names and
that they match the corresponding group names on step 3. However, do not add a plan hierarchy,
plan staging table, plan format table, or plan data collect range. That information is all maintained
by the system. Simply select the Enable Planning Data From EKB option in step 11 of Database
Setup and update the database.
2. Ensure that your EP Mid-Tier application server is running and that the TNS entry used by the EP
Mid-Tier to connect to the EKB database exists not only on the application server machine, but also
on the AL database server.
3. Define an EKB structure context for AL to use. It must identify the subcube set for all EP and AP
measures that will be used by Allocation. This structure context will be built when AL is configured
to use it. After that, it must be rebuilt whenever structure changes are made to EKB so that
Allocation will be able to collect plan data.
4. Start Allocation Administration and select EKB Information… from the Maintain menu.
5. Configure your EP Mid-Tier connection, select the EKB structure context that was defined for
Allocation, map EKB levels to Allocation product groups for data collection, and select EKB
measures for use within Allocation Need calculations. The application will automatically set up the
hierarchy, data collect ranges, and data collect levels as well as the plan staging and format tables.
Detailed information on this configuration step is found in the Online Expert (OLE) by selecting
Help from within Allocation Administration.
6. By default, user-requested data is cached within the system. To clear the cache, you must purge
the PLAN_STAGING and EKB_PRODUCTS tables regularly. This purge can be scheduled for a
time when no users are in the system using a DBMS job within the Oracle database.
Format EKB product member IDs in JDA Allocation

If not using product and location structure directly from EKB in JDA Allocation, there is a possibility
that EKB unique product member IDs have had formatting applied to fit an EKB requirement and are
different than what is provided to JDA Allocation from the host interface. If this is the case, there is a
product level member format option that allows group member IDs in Allocation to be matched with
EKB level member IDs for corresponding product members where the EKB ID is composed of
concatenated members or contains additional text to make a member unique across the hierarchy.

The format can be defined for hierarchical groups in Allocation. It consists of a format string in which
the group/level code and additional characters are formatted to match the corresponding EKB member
ID. Additional text can be embedded, as long as it does not interfere with level names. To embed a
level member into this format string, start with a percent (%) symbol, followed by the minimum
number of characters for the level member ID and the group/level name in uppercase. The ID will be
prefixed with zeros if necessary to meet the minimum length. Trailing zeros or other text can be added
where required. Some examples are shown below.
EKB Level name / Allocation

AL Group name Format String Member ID EKB Member ID
COMPANY CO%3COMPANY 1 CO001
GRP GRP%2GRP 3 GRP03
DIV DIV%3DIV 7 DIV007
DEPT DEPT%3DEPT00 13 DEPT01300
SUBDEPT SDPT%3DEPT%0SUBDEPT 13 / 400 SDPT013400
CLASS CL%6CLASS 13907 CL013907
SUBCLASS SC%9SUBCLASS 95993521 SC095993521
ITEM ITM%5ITEM 5269143 ITM5269143
CHOICE %0CHOICE 20217747 20217747
SKU %9SKU 53933416 053933416
Before you collect data from EKB, the format strings must be manually entered using SQL*Plus into
the parameters table for levels where the formatting is required. If a format string record does not
exist in the parameters for a group/level, then the unmodified member ID is used when requesting
data from EKB. The parameter type to use is EKB_PROD_LEVEL_FORMAT. The parameter code is the
group name in upper case. The parameter value is the format string. Here are some examples based
on the previous table:
INSERT INTO AAM_PARAMETERS (PARAMETER_TYPE, PARAMETER_CODE, PARAMETER_VALUE)

VALUES ('EKB_PROD_LEVEL_FORMAT', 'SUBCLASS', 'SC%9SUBCLASS');
VALUES ('EKB_PROD_LEVEL_FORMAT', 'CLASS', 'CL%6CLASS');
VALUES ('EKB_PROD_LEVEL_FORMAT', 'DEPT', 'DEPT%3DEPT00');
VALUES ('EKB_PROD_LEVEL_FORMAT', 'SUBDEPT', 'SDPT%3DEPT%0SUBDEPT');
-- this must be done after modifying parameters, so that the parameter cache is updated
on the client machines
UPDATE AAM_PARAMETERS SET PARAMETER_VALUE = PARAMETER_VALUE + 1
WHERE PARAMETER_TYPE = 'DIMENSIONS' AND PARAMETER_CODE = 'DB_VERSION';
COMMIT;

Maintain the EKB structure context for Allocation

After Allocation has been configured to use product and location structure from EKB or to collect data
from EKB, any changes to location or product dimension members in EKB must be updated into the
Allocation database so that the system will be able to collect plan data. This can be done manually by
an administrator selecting the Action > Rebuild EKB context and update Allocation command in
Allocation Administration. It can also be executed via a command line option, which enables it to be
called from a batch process to run on an administrator's Windows machine where Allocation
Administration is installed. The option is %REBUILD_EKB_CONTEXT.
Example: Windows PC command line
"C:\Program Files (x86)\JDA\JDA Allocation\Alchemy.exe" [username] [password]

%REBUILD_EKB_CONTEXT
Notes:
 The username and password must have System Admin privileges.
 The user cannot be already logged into the system.
 You should successfully log in to establish a connection to the database prior to using the
command line syntax to start any of the AL applications. A connection file can also be included as
one of the command line options.
 Command line options do not support Active Directory users.
Populate plan data from other sources

To use plan data from other sources in JDA Allocation, you must carry out the following steps.
1. In "Step 4" (on page 94) of Database Setup, establish the plan hierarchy. If you intend to use data
at level 0 or below, be sure to include groups that are part of the unique merchandise ID. Your
group names must be valid Oracle column names.
2. Verify the levels are valid column names in "Step 6" (on page 96) of Database Setup.
3. Deselect "Enable Planning Data From EKB" and select the plan hierarchy in "Step 11" (on page
103) of Database Setup.
4. In Allocation Administration, build the base variable list. See "Maintain the base variable list" (on
The application creates the staging area (PLAN_STAGING) and format table (PLAN_FORMAT). The
columns are named using the following rule.
<VariableName>_<Time periods>OUT
For example, SALES for three time periods yields SALES, SALES_1OUT, and SALES_2OUT.
Note that the use of two placeholders for the number of time periods in the base variable names is
a new feature as of the 7.6.0 release. If your database was set up for manual population of the
PLAN_STAGING area prior to that version, then it will continue to use the original pattern of
SALES, SALES_1OUT, SALES_2OUT, etc.
The staging area contains columns for all groups in your plan hierarchy. These columns are
associated with proper groups in "Step 5" (on page 95) of Database Setup. In addition, any
required mappings ("Step 9" (on page 99)) are performed. No further mapping is required.
5. Establish the data collect range in "Step 8" (on page 97) of Database Setup.
6. Return to Allocation Administration and create the data collect levels for the PLAN_FORMAT table.

7. Populate the PLAN_STAGING table with your plan data. Do not populate the PRODUCT_KEY field.
This field is used by Allocation when interfacing data from EKB.
8. Populate the PLAN_TIME_ORDER table with your time codes. For format information, see "Table
definitions" (on page 105).
You may decide to use only one plan time code and replace all data in your PLAN_STAGING table
every time period.
9. In Allocation Administration, choose Action > Set Current Time Code > Planning, and select a
time code from the list.
10. Purge and refresh the data in PLAN_STAGING as appropriate.
Plan data coming into the application is always rounded into whole numbers.
User populated plan data at multiple levels

If you populate plan data only at the lowest level, but you want to collect data at a higher level, you
need to modify AAM_PARAMETERS to sum plan data.
From the SQL*Plus prompt, type:
SQL> INSERT INTO AAM_PARAMETERS (Parameter_Type, Parameter_Code, Parameter_Value)

VALUES ('DATACOLLECT', 'SUM_PLAN_DATA', 'Y')
Maintenance of plan staging area

Drop staging/format tables
Changes to your plan hierarchy or plan base variables will require dropping and rebuilding the plan
staging and format tables. These tables are maintained by Allocation, and do not require group
associations or mappings to be added in Allocation Database setup.
If the PLAN_STAGING or PLAN_FORMAT tables must be dropped and rebuilt, the AAM_PARAMETERS
table must be modified prior to rebuilding them in Allocation Administration. For PLAN_STAGING, set
the value of PLAN_STAGING_VALID to N. For the PLAN_FORMAT table, set the value of
PLAN_FORMAT_VALID to N. For the AAM_PARAMETERS table, execute the following statements:
SQL> UPDATE AAM_PARAMETERS SET PARAMETER_VALUE = 'N' WHERE PARAMETER_TYPE =

'PLANNING_EXPORT' AND PARAMETER_CODE = 'PLAN_STAGING_VALID';
SQL> UPDATE AAM_PARAMETERS SET PARAMETER_VALUE = 'N' WHERE PARAMETER_TYPE =
'PLANNING_EXPORT' AND PARAMETER_CODE = 'PLAN_FORMAT_VALID';

Set up results collection procedures
Chapter 9. Set up results collection procedures

After merchandise has been allocated, approved, and released, the results of the allocation are stored
in the RESULTS_DETAIL table. You must create procedures to read the information from this results
table, and update your transaction management system with the details.
The results table contains information about how much merchandise is to be sent to each location. For
example, the results table might contain a line that says that 150 small red T-shirts from a particular
WorkList line should be sent to the Fosse Park location. You must pass this information to your
transaction management system so the right quantities of the right sizes and colors of the
merchandise are sent to the right location.
Results collection tables

You need to use the following tables for results collection.
 QUEUE_OUT table
 RESULTS_DETAIL table
The QUEUE_OUT table informs you when there are results to collect, and the RESULTS_DETAIL table
contains the results to be collected.
For definitions of the Results Collection tables, see "Table definitions" (on page 105).
Collect results
When the allocation is completed, the results are written to the RESULTS_DETAIL table, and a
notification is written in the QUEUE_OUT table.
You must set up procedures on the host system to carry out the following steps.
1. Periodically read the QUEUE_OUT table in the Allocation database. This table contains the list of
actions to be performed by the host system. For results collection, the Queue_Entry_Type column
contains RES, meaning results collection.
The only code that can be displayed in the Action column for results collection is REL. This code
means the allocation results are released and ready for collection.
Example
For example, the QUEUE_OUT table might contain the following information.
Queue_ID 1
Queue_Entry_Type RES
Allocation_Nbr 1005
Action REL
This information means results for the allocation number 1005 are ready for collection.
2. Read the RESULTS_DETAIL table, and obtain the results from the allocation by finding all rows in
the results table that have the allocation number mentioned in the QUEUE_OUT table.
For bulk merchandise, the results table also can contain information about the levels (size, color,
width, and so on) of the merchandise.
Example

Set up results collection procedures
For example, one of the lines in the RESULTS_DETAIL table might contain the following
information.
Allocation_Nbr 1005
Location_ID 52
Unique_Mer_Key 2
Level1_Desc 012
WL_Key 175
Result_Qty 150
For the allocation number 1005, which refers to the WorkList line with the WorkList key of 175,
150 units should be allocated to the location with location number 52.
For pack merchandise, the result_qty would be the number of packs, not the total number of units.
3. Update the transaction management system with these results.
If CAQ is to be adjusted as results are purged, decrement the CAQ_HOST table for the allocation.
For example:
Execute AllocCAQ.DecrementCAQEx(1005);
If extra information is needed, for example, the purchase order number, this information can be
obtained from the WorkList table by looking at the line with the same WorkList key.
If you allow distributors to add comments to the WorkList by making some columns editable, you
can extract this information in the same way.
In a single allocation, there may be several WorkList lines.
Note: After the QUEUE_OUT request is handled, it should be deleted. See "QUEUE_OUT" (on page
105).
Delete results
After you update the transaction management system with the results, the results and WorkList
records need to be cleaned up. It is your responsibility to configure and execute a clean up process. A
Results Purge process is provided that can be configured in Allocation Administration and executed
programmatically. See the Enable Results Purge option under "Set the general parameters" in
Allocation Database Setup: Step 11.
Note: Many customers leave the results and their associated WorkList records in the Allocation
database for a short period of time, to be used as a reference for future allocations. After results have
been generated for an allocation, the WorkList and Shape table records are linked to the results and
cannot be purged independently.

Set up Store Grading
Chapter 10. Set up Store Grading

Store Grading is an indication of groupings of locations, based on any criteria your grading software
supports. The application does not grade locations itself, but allows you to use grading information
from elsewhere to help your distributors allocate.
You can provide a single grade per location, or a series of grades for each location, depending on the
merchandise being allocated or the current Grading time period. The merchandise information can be
taken from the WorkList, or you can let the distributors choose the grading attributes to use for an
allocation.
You can use grading information in variables, templates, and minimums and maximums.
Create the store grading table

Store grades are kept in the GRADE table. You cannot use the name GRADE for any other table.
When Store Grading is enabled, a Grading dialog box displays whenever a distributor goes into the
WorkSheet, allowing the distributor to select the grading criteria for the current allocation. While in the
WorkSheet, the Store Grading Dialog can be selected from the WorkSheet Criteria > Grading menu.
This table allows distributors to use grades to select groups of locations for templates and minimums
and maximums, as well as using the grade of each location when building the Need variables.
You must create the GRADE table and populate it with the locations and grading information from your
grading software. You must keep the grading data current.
Create the columns in the store grading table

The GRADE table must have the following columns.
 Location ID
 Grade
 Grading Time Period
Optionally, it can have Merchandise Information columns.
Location ID
The Location ID holds information for the locations for which you have a grade.

The data type of the Location ID must be the same data type as the Location ID column used
throughout your database; for example, in the Locations table or your data collect format tables.
Grade
The grade is the actual grade for the location.

The grade can be any data type. If your grading software produces numeric grades, use a specific
precision for the numeric data type, for example, NUMBER(15). If it produces text grades, use a text
data type, for example, VARCHAR2(2). The maximum size this field supports is a 50 character string.

Time Period
The time period is used to store the Grading time period for which the grade is relevant.
If you do not slice grade data by time, enter a dummy value in this column, for example, TIME.

The Grading time period must be of data type VARCHAR2(50).
Merchandise Information
Your Merchandise Information columns refer to the type of merchandise for which each grade is
relevant. For example, some locations might sell menswear in large quantities and womenswear in low
quantities; accordingly, they would have a high grade for menswear and a low grade for womenswear.
This data may be the hierarchical information from your JDA planning system; for example, the
department and class information. You can map these columns to your WorkList so the application
automatically selects the correct type of grade for the merchandise you are allocating. If the
information is not available on your WorkList, or you are allocating more than one sort of merchandise,
the distributor can select the criteria to use for grading.

The data types of the merchandise information columns must be the same as the related columns on
the WorkList.
Set the Main Key for the GRADE table

You must set a unique key as the Main Key for the GRADE table. It must include the location ID, the
time period (if you have one), and all merchandise information.
By making the Main Key a unique key rather than a primary key, you can leave some of the columns
blank when populating the table. For example, you can include both Department and Class level
grades by leaving the Class column blank for the Department level grades, and populating both for the
Class level grades.
Use the Database Setup utility for the GRADE table

After you create your GRADE table, you must use Database Setup to provide the structure and
mappings of the table. This section tells you how to use Database Setup to set up the GRADE table
correctly.
See "Use the Database Setup utility" (on page 87) for full details.
Set up the GRADE table using Database Setup

1. Start Database Setup. The first screen is displayed.
2. Click New, type the table name GRADE, then click Set.
3. Leave the Table Type blank and click Next. Database Setup processes the list of tables; if it
cannot find any table, it warns you. Check that your tables are set up correctly.
4. Go to "Step 9: Set up column mappings" (on page 99) of the Database Setup utility.
5. Select the GRADE table, and click Main Key. The Main Key Maintenance dialog box is displayed.
6. Enter the columns from the GRADE table that make up the unique key.

7. Click Map to WL to map your merchandise information columns to the WorkList, click Close, then
click OK.
The GRADE WorkList mappings are required for levels above level 0. Because a location may have
only one grade while in the WorkSheet, JDA Allocation does not support grading at or below level
0.
8. Select the table again, and click Mappings. The Mappings dialog box is displayed.
9. Map all required columns to their relevant columns on the table, and click OK.
10. Go to "Step 11: Set the JDA Allocation system parameters" (on page 103) of the Database Setup
utility.
11. Select the Enable Grading option.
12. Type a value to be used for the Default Store Grade.

Set up Currently Allocated Quantities
Chapter 11. Set up Currently Allocated Quantities

Currently Allocated Quantities (CAQ) is a record of the merchandise that has been allocated already,
but is not yet reflected in the on-hand or in-transit data being retrieved from your transaction
management system by the data collect process.
CAQ returns a value for the merchandise you are allocating, which may not be the merchandise for
which you have collected data. If you have a variable like Sales minus CAQ, where you are allocating
red T-shirts based on mapped collected data (using Like Products) for yellow T-shirts, the Sales value
is taken from the yellow T-shirts, and the CAQ value is taken from the red T-shirts you have already
allocated.
CAQ is always collected for the current product, even if alternate hierarchy data collect is used. DCAQ
follows the data collect rule, but it does not support alternate hierarchies.
Because CAQ looks at the Need level to determine what to load, and the Need level is never above the
WorkSheet level (0), it does not distinguish between different levels above the WorkSheet level. As
soon as it determines that Need is above the WorkSheet level, it uses information from the WorkList to
load CAQ for one level above the WorkSheet level. If quantities specific to a group in the data collect
rule are required, then the answer is to use DCAQ.
Note: CAQ for allocations that were produced using Planning data has no time period other than
current. The CAQ is written and read, using only the CAQ slice for the selected plan time code. This
CAQ does not age, so it never becomes current. If you want to include this CAQ in your other
allocations, do not map a time code on your CAQ_HOST table.
Create the CAQ table

Currently Allocated Quantities are stored in the CAQ_HOST table. You cannot use the name CAQ_HOST
for any other table.
When merchandise is allocated, the results from the allocation are written to the CAQ_HOST table
when the user leaves the WorkSheet, whether the status of the merchandise is Approved, Unapproved,
or Released. This table provides a record of the merchandise that has been allocated to date.
If you back out a collection of merchandise, the results from that allocation are removed from the
CAQ_HOST table and the quantities are reduced.
When you set up procedures to read from the results tables into your transaction management
system, you must adjust the quantities in the CAQ_HOST table accordingly. As soon as the allocated
merchandise is considered in the data received from the data collect process, it should no longer show
up in the CAQ values. See "Decrementing values in the CAQ table" (on page 76) for details.
Create the columns in the CAQ table

The CAQ table must have the following columns.
 Location ID
 Hierarchical groups above level 0
 Other groups from WorkList
 Levels
 Quantity Allocated

You can include extra columns to help identify the CAQ, which can be any WorkList columns that are
mapped to a group. Database Setup also must be used to map these columns to the WorkList. Because
these are groups, they cannot contain null values. The columns on the CAQ_HOST table are populated
with the appropriate data from the WorkList, if you follow these instructions.
Location ID
The location ID is used to store information for the locations to which you allocate.

The data type of the location ID must be the same data type as the Location ID columns used
throughout your database; for example, in the Locations table and your format tables.
Groups
You may include the hierarchical groups above level 0, if you intend to collect data above level 0.
These other groups should be included in the main key above level 0, and must be mapped to the
WorkList in that main key.

The data types of the group columns match the data types of the group columns in the WorkList and
list source tables.
Levels
You must include at least the column for level 0; the unique merchandise ID column. You also must
include the maximum number of levels to which you allocate; for example, if some of your
merchandise comes in combinations of only style and color, and other merchandise comes in
combinations of style, color, size, and width, you must include columns for level 0 (unique
merchandise), color, size, and width.

The data type of the level 0 column must be VARCHAR2(50). The data types of the other level columns
must match the data types of the relevant columns in the WorkList or Merchandise Shape tables.
Quantity Allocated
The quantity allocated is the amount of merchandise allocated for the current combination of location
and levels; for example, the merchandise allocated to location 001, unique merchandise
100.200.1ABC, color Red, and size Medium. The quantity allocated represents the bulk number of units
allocated, regardless of whether the initial allocation was for pack or bulk merchandise.
This quantity is cumulative. The application adds to it whenever more merchandise is allocated, and
subtracts from it whenever merchandise is backed out. You must set up procedures to subtract the
released merchandise quantities when you update your transaction management system. Alternatively,
you may decide to wait and refresh CAQ quantities nightly, for all Approved and Unapproved lines that
remain on the WorkList at the end of the day, to coincide with the updated stock quantity information
being made available from your transaction management system.

The data type of the allocated quantity must be NUMBER(15).

WorkList Columns
You can include any WorkList columns that are mapped to a group and cannot contain null values.
These columns may help identify the CAQ for specialized data collects.

The data types must be the same as the columns on the WorkList.
Unique Key
See "DCAQ/CAQ index" (on page 126) for the exact order of columns.
Set the Main Key for the CAQ table

You must set a unique key as the Main Key for the CAQ_HOST table. It must include the Location ID
and all hierarchical groups, as well as non-hierarchical WorkList groups, followed by the WorkSheet
levels. For all groups above the WorkSheet level 0, the main key columns must use group associations
on Step 5 and be mapped to WorkList group columns on Step 9 of Allocation Database Setup.
Use the Database Setup utility for the CAQ table

After you create your CAQ_HOST table, you must use Database Setup to provide the structure and
mappings of the table. This section lists all steps in Database Setup you use to set up the CAQ table
correctly.
Set up the CAQ table using Database Setup

1. Start Database Setup. The first screen is displayed.
2. Click New, type the table name CAQ_HOST, then click Set.
3. Leave the Table Type blank and click Next. Database Setup processes the list of tables; if it
cannot find any table, you are warned. Check that your tables are set up correctly.
4. Go to "Step 5: Enter the column information" (on page 95) of the Database Setup utility.
5. For all columns on the CAQ_HOST table that correspond to groups in your product dimension,
select the column and the appropriate group, then click Set.
6. Go to "Step 9: Set up column mappings" (on page 99) of the Database Setup utility.
7. Select the CAQ_HOST table, and click Main Key. The Main Key Maintenance dialog box is
displayed.
8. Enter the columns from the CAQ_HOST table that make up the unique key.
9. Click Map to WL to map your additional columns to the WorkList, click Close, then click OK.
The CAQ WorkList mappings are required for style level and above. These mappings are how CAQ
determines which levels are style level and above. Because JDA Allocation does not display any
level above level 0 (or UMID) in the WorkSheet, we need to use a different method to find the
corresponding values; for example, a lookup back to a WorkList column.
10. Select the table again, and click Mappings. The Mappings dialog box is displayed.
11. Map all required columns, and all optional columns you have used, to the relevant columns on the
table, and click OK.
To map the levels you may have used (for example, unique merchandise ID, color, and size), you
must have set up the levels previously.

You must map at least level 0.
12. Go to "Step 11: Set the JDA Allocation system parameters" (on page 103).
13. Select the Enable Currently Allocated Quantities option in the General section. CAQ values are
not used unless this parameter is set.
Maintain CAQ
Functions are available through Oracle scripts that provide support in maintaining CAQ.
Decrement values in the CAQ table

The following PL/SQL procedure decrements values in the CAQ_HOST table for the specified allocation.
As results are picked up, the values in the CAQ table can be decremented to reflect the changes by
using this procedure. For example:
EXECUTE ALLOCCAQ.DECREMENTCAQEX(AllocationNumber)
AllocationNumber is the current allocation number with a data type of NUMBER.
Data cached in the CAQ$CHS staging table is used, if it exists. Otherwise, the staging table is
populated using the original allocation results, WorkList, and Shape table data. RESULTS_HEADER,
RESULTS_DETAIL, WorkList, and Shape table records must exist for the specified allocation.
If the allocation number is not in an appropriate state, or if the required data is not present, no action
is taken.
For faster performance on future updates to the table, the procedure does not delete the record from
CAQ_HOST when the quantity allocated value is reduced to zero. It does not allow values to go
negative; if the result of the decrement is negative, the result is updated to zero.
When maintaining CAQ on an allocation-by-allocation basis using DecrementCAQEx, it is good practice

to periodically execute the RebuildCAQHost procedure. Interface maintenance due to receipt
discrepancies of the WorkList and Shape table quantities can cause minor discrepancies in the CAQ
data.
Rebuild the CAQ table

If you choose not to decrement CAQ as transactions are picked up throughout the day, you can
periodically refresh the data in the CAQ table. Execute the following PL/SQL procedure to rebuild CAQ
from the results table and the CAQ repository. No users should be connected while this procedure is
executing. For example:
EXECUTE ALLOCCAQ.REBUILDCAQHOST
The CAQ_HOST table is truncated and repopulated with results for all approved and unapproved
allocations on the WorkList. This update does not include released allocations.
The CAQ$CHS staging table is always repopulated using the original allocation results.
RESULTS_HEADER, RESULTS_DETAIL, and Shape table records must exist for all approved and
unapproved allocations on the WorkList.
The procedure removes records from CAQ_HOST for products not in Approved or Unapproved status.
As a result, performance degradation occurs the next time a user writes results for something that was
not approved on the WorkList prior to the execution of the rebuild.

Rebuild the CAQ repository

Rebuilding the CAQ repository takes place in Database Setup. Changes in the mappings in the WorkList
may require rebuilding the CAQ repository. After the administrator clicks Finish, JDA Allocation
determines if mapping changes may have taken place, and prompts for permission to rebuild the
repository.

Set up Model Stock
Chapter 12. Set up Model Stock

Model Stock supports the ability to manage replenishment-type fill levels for SKUs or the application of
external size curves for styles. Model Stock typically describes a quantity of merchandise that should
be maintained in each location at SKU level. The Model Stock capability is based on data collection. If
the user specifies a data collect rule at or below level 0, and the product being allocated is included in
the data collect rule, model data will be collected for that product. Model data will not be collected for
products in the data collect rule that currently are not being allocated in the user's WorkSheet.
Models must contain information at or below level 0 (unique merchandise). Models contain information
by Location. The Model Data Collect will bring in only data for locations that exist in the model. Models
can be established at any level, without establishing all higher levels. For example, if level 1 is color
and level 2 is size, you can create one model at the size level that pertains to all colors for the size.
You can specify a wildcard value at any level of a model, as well as for the location ID. The wildcard
value is a double asterisk (**) for level codes and -1 for the location ID. When a wildcard value exists
in a model, it is used for all members of the specified level that do not have values in the model for the
product being allocated with the model. A model that contains a wildcard value in one level can also
contain specific values at that level. For example, a model that has target and threshold values for
black, white, and ** can be used for allocating a product that comes in black, white, green, blue, and
yellow. In this example, the target and threshold values for green, blue, and yellow are populated
using the target and threshold specified by the wildcard. Levels specifying wildcard values need not be
contiguous. For example, you can specify level 1 and level 3 and set level 2 to a wildcard value. If the
model includes a wildcard for the location ID, the model data collect brings in data for all locations that
are available for allocation on the LOCATIONS table.
A model cannot contain values and nulls at the same level.
Set up for model stock

The scripts included with this release create the system tables required to support models.
MD$IMPORT_DATA is the table used to contain the details of your models. You must create and
maintain the model outside of the application.
First, update the MD$IMPORT_DATA table with new or changed model stock data. To associate a
model with a product, each model must be identified by a unique name. Each record of the model
must contain that unique name in the MODEL_NAME field. The Model_Key column is managed by the
application, and must not be edited. The Model_Key column is populated automatically when the
UPDATEIMPORTDATA procedure is run.
Execute the UPDATEIMPORTDATA procedure provided with JDA Allocation to update the application
links to the MD$IMPORT_DATA. This procedure is located in the AllocModels package. For example:
EXECUTE ALLOCMODELS.UPDATEIMPORTDATA;
COMMIT;
You cannot change the structure of the MD$IMPORT_DATA table.
The following sample MD$IMPORT_DATA table shows some example information required to provide
model stock functionality. Make sure no lines are duplicated in the MD$IMPORT_DATA table; this
duplication causes unexpected results in the data collect.
The import table can include different merchandise types, and use level codes instead of descriptions.
Model_ Location_
Key Model_Name Level_1 Level_2 Level_3 Level_4 Level_5 ID Threshold Target
? CasShirt70 002 055 1 10 40

Set up Model Stock
Model_ Location_
Key Model_Name Level_1 Level_2 Level_3 Level_4 Level_5 ID Threshold Target
? CasShirt70 002 055 2 5 30
? CasShirt70 … … … … …
? CasShirt70 002 057 1 8 15
? CasShirt70 002 057 2 12 24
? CasShirt70 … … … … …
? CasShirt70 001 055 1 20 40
? CasShirt70 001 055 2 15 30
? CasShirt70 … … … … …
? CasShirt70 001 057 1 15 30
? CasShirt70 001 057 2 18 24
…
? BallCaps100 008 1 20 30
? BallCaps100 008 2 10 20
? BallCaps100 … … … …
? BallCaps100 010 1 15 30
? BallCaps100 010 2 12 24
? BallCaps100 … … … …
? BallCaps100 ** ** 8 12
…
? H&BApplianc 1 8 15
es
? H&BApplianc 2 6 12
es
…
Models in the WorkList

A required column on the WorkList supports model stock. This column must be mapped to Model Name
in Database Setup. Model names must be included, either directly in the WorkList in this new column
or associated with a WorkList line using the Auto-Allocation schedule table. The WorkList model column
associates a given model to a product.
A single unique merchandise ID can be associated with only one model at a time. The association
occurs when that WorkList line is being allocated. For example, during manual allocation, the
association occurs on entry to the WorkSheet and remains associated with the product. If multiple
WorkList lines that have the same unique merchandise ID, but different models, are allocated
together, only one model is associated with that unique merchandise ID.
After a UMID has been associated with a model, it remains associated with that model until it is either
associated with a different model or the model is deleted from the MD$IMPORT_DATA table.
No error messages are generated if multiple models are listed for a unique merchandise ID in a single
allocation or if the model name on the WorkList does not exist.

Set up Model Stock
Use model data

Model stock is based on two values, threshold and target. Threshold value typically refers to the
reorder level. Target value typically refers to the maximum quantity to be reordered. It is expected
that model stock be set up so locations are replenished only when their stock position (stock position
refers to the sum of in-transit, CAQ, and stock on hand) is lower than the threshold level. Using both
the threshold and target values is not a requirement.
To use the functionality of Threshold and Target, you need to map Threshold and Target columns in
the format tables. See "Step 9: Set up column mappings" (on page 99) for details.
The most typical approach for an application to utilize model stock replenishment is to set up the data
collect and Need generation at the lowest level. The following statement is typical.
IF (stock_position < Threshold)

THEN Target - stock_position
ELSE 0
As part of the data collect process, the application collects model stock information from the
MD$IMPORT_DATA table and updates the format table, and uses this information to generate Need.
The model data that is retrieved is based on the products specified in the data collect rule that are
currently being allocated in the WorkSheet.
If the product specified in the data collect rule has no model, the target and threshold values are zero.
If the product in the data collect rule that is being allocated in the WorkSheet has a model, but the
model does not have details for all merchandise currently being allocated, the target and threshold
values for those missing details are returned as zero, unless the model contains wildcard values that
can be used for the missing merchandise details.
Because model data typically makes sense only at the level that it exists in the MD$IMPORT_DATA
table, JDA does not recommend collecting model data above the model's lowest level.

Set up Allocation Scoring
Chapter 13. Set up Allocation Scoring

The Allocation Score is a value that measures the difference between Need and Allocation results on a
scale from 0 to 100.
A score of 100 is the best possible score and occurs when an Allocation exactly matches its Need. A
score of 0 represents the worst possible score, meaning an Allocation where no goods were allocated
towards satisfying its Need.
Notes:
 An allocation without Need will have a score of 0.
 The score can be affected by Templates, Minimums, Maximums, and manual edits, as these all will
likely be departures from Need.
 A store without Need and allocated is not considered as part of the calculation.
Technical details
The Allocation Score is based on the root-mean-square deviation (RMSD), which serves to aggregate
the magnitudes of the variances into a single measure of accuracy.
Allocation score color gradient

The Allocation score is displayed as a color coded gradient based on rules defined in Allocation
Administration. The gradient is manipulated by two thresholds: ideal and acceptable. These thresholds
are designed to allow the Allocation administrator to affect the colors displayed for scores, based on
previous experience or expectation, to indicate to the user that certain allocations require additional
review.
Note: The scoring thresholds do not affect the score directly but only the color that represents that
score for the given product.
A system rule called "All Products" defines the default color gradient for every product, unless there is
a more specific rule for the product being allocated. Additional rules can be added that correspond to
different parts of the product hierarchy.
For example, an Allocation administrator could define the following set of rules:
 "Home Goods" Ideal: 60, Acceptable: 30
 "Men’s Apparel" Ideal: 75, Acceptable: 67
In this example "Home Goods" is predominantly pre-packed merchandise where the granularity tends
to create variance from Need, while "Men’s Apparel" merchandise with more packaging options tends
to track more closely to Need. As a result, the administrator increases the scoring tolerance for "Home
Goods."

To enable Allocation Scoring, follow these steps during Database Setup.

1. In "Step 5: Enter the column information" (on page 95), create a new column on the WorkList
table and add a description for the column, such as "Score." The Score column must be able to
hold a string of at least 30 characters, for example, data type VARCHAR2(30). Null is a legal value.
2. In "Step 8: Set up hierarchy ranges and associations" (on page 97), define the hierarchy range for
Scoring rules.
Add custom scoring rules

1. In Allocation Administration, select Maintain > Scoring Configuration.
2. Expand and navigate the product hierarchy tree, then select a level member to add a scoring rule.
3. Click Add new rule (+ icon) to create the new scoring rule.
4. Move the Ideal and Acceptable controls until the desired scoring gradients are achieved.
5. Click Apply.
The scoring rule is applied during initial entry to the WorkSheet, based on the level information in the
rule and on the WorkList. An allocation can use only one scoring rule. If multiple WorkList lines are
selected that would cause conflicting rules to be applied, then the rule that is more specific (applied at
a lower level in the hierarchy) is applied.

Set up Internal Grading
Chapter 14. Set up Internal Grading

Internal Grading allows an administrator to configure automatic grading criteria based on a default
calculation and fixed percentages for each grade code. An administrator can select whether to use
external (traditional) grading for the current product and time code, use internal grading for an
allocation, or allow both internal and external grading.
The administrator can select an internal grading calculation and specify a percentage breakout of
stores for each grade.
Notes:
 The grading calculation can use collected data at any level, but there will be only one value for
each store/allocation. This means that a low-level data-collect request and calculation will be
aggregated up to the store level for assignment of grades.
 Internal Grading requires the use of multiple levels of collected data.
 Even if both internal and external grading are enabled, an allocation can use only one of these
options at a time during the allocation.
The option to use internal grading can be stored in a method along with the specified grading variable
and data collect criteria. The internal grading data collect rule can be generic or specific.
To enable Internal Grading, define the Internal Grading hierarchy range in "Step 8: Set up hierarchy
ranges and associations" (on page 97) of Database Setup.
To add Internal Grading rules:
1. In Allocation Administration, select Maintain > Internal Grading.
2. Expand and navigate the product hierarchy tree and select a level member to add an Internal
Grading rule.
3. Click Add new rule (+ icon) to create a new Internal Grading rule.
4. Select a variable from the Default Calculation drop-down list.
5. Add grade codes and percentages for the rule. The percentages must add up to 100 to create a
rule.
6. Click Apply to save the rule.
The grading rule is applied during entry to the WorkSheet, based on the level information in the rule
and on the WorkList. An allocation can use only one grading rule. If multiple WorkList lines are
selected that would cause conflicting rules to be applied, then an error message is displayed and no
grading is loaded.

Set up Auto-Allocation Server
Chapter 15. Set up Auto-Allocation Server

Auto-Allocation Server is a Windows service that generates background Auto-Allocation processes to
perform Auto-Allocation jobs. Each server is configured to run up to <n> jobs for each CPU core in
parallel. This allows the Auto-Allocation administrator to fully leverage the capability of the server
without the burden of setting up multiple-server desktop sessions, user IDs, or using the Windows
Scheduler to start and stop the Auto-Allocation clients.
You can monitor configuration, error reporting, and status from the Auto-Server tile in the
Administrator Dashboard.
Set up the Auto-Allocation Server Windows service

When the Auto-Allocation Server component is selected during the installation process, the Auto-
Allocation Server is installed as a service named "JDA Auto-Allocation Server" running under the
LocalSystem account. If this security context is satisfactory, go to Set up the Auto-Allocation Server
login (on page 84). This context may be changed to any user with local administrator privileges.
Set up the Auto-Allocation Server login

1. Start the Auto-Allocation Server application from the JDA Allocation Start menu folder.
2. Enter the Allocation User ID and Password that the Auto-Allocation Server will use to launch
each Auto-Allocation background process.
3. Select a Connection File that specifies the location of the Allocation schema.
4. Select a Service Port number for the Auto-Server tile to communicate with the Auto-Allocation
Server.
5. Click Start to start the Auto-Allocation Server.
Notes:
 The JDA Allocation Administration Auto-Server tile communicates with the Auto-Allocation Server
using TCP, which requires a port number. The valid range for ports is from 0 to 65535, however
many of these may be in use on your network. It is recommended that you select a port in the
range of 49152 through 65535 to minimize the likelihood of a port conflict. In the event of a
conflict, select another port in the recommended range.
 The port that you select must be allowed to pass through any firewalls on the machine running
both Auto-Allocation Server and any machine running JDA Allocation Administration.
 If you specify an Allocation user that authenticates against Active Directory, then the Auto-
Allocation Server Windows service must use the same user and authentication. Additionally, the
connection file specified must have the Accept Windows Authentication option selected. This is
required because JDA Allocation does not store or sequester domain password information.
Stop the Auto-Allocation Server

To stop the Auto-Allocation Server service, select Auto-Allocation Server from the JDA Allocation
Start menu folder, then click Stop.
The Stop button toggles to display Start, which you can select as needed.
Notes:
After it has been configured, you can also start or stop the Auto-Allocation Server service:

 From the Windows MMC Service snap-in.
 From the Windows command line, using the net start/stop command.
Specify global server configuration items

1. Open the Auto-Server tile in the Administrator Dashboard to specify Auto-Allocation Server
configuration items.
2. Select the gear icon on the Global Configuration panel to configure the Auto-Allocation Server
settings:
 Target Number of Jobs/Core specifies the target number of Auto-Allocation clients to run in
parallel. The number specified is not required to be a whole number.
Example:
1.8 jobs/core
Server Alpha with 16 cores will target 28 jobs
Server Beta with 4 cores will target 7 jobs
 CPU Warning Threshold specifies the average summed CPU percent load to report as an
alert in the Status section of the Auto-Server tile.
 Memory Warning Threshold specifies the memory consumption percent utilization to report
as an alert in the Status section of the Auto-Server tile.
 Disk Utilization Warning Threshold specifies the disk space percent utilization to report as
an alert in the Status section of the Auto-Server tile.
 Process Runtime Warning Threshold specifies the longest amount of time an Auto-
Allocation client should be allowed to run before being reported as an alert in the Status
section of the Auto-Server tile.
3. Click Save to persist the changes for all Auto-Allocation servers. The configuration change is
effective immediately. No restart is required.
Set up the logging level for an Auto-Allocation Server

You can configure logging levels for each Auto-Allocation Server from the Auto-Server tile in
Administrator Dashboard.
1. Open the Auto-Server tile in the Administrator Dashboard.
2. Right-click the Auto-Allocation Server from the list displayed in the Auto-Allocation Servers panel.
3. Navigate to Logging Level in the context menu, and select the desired logging level.
Notes:
 The AAMDebug.log file for the Auto-Allocation service is located in

C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\JDA\JDA
Allocation\8.1.
 If you decide to change the Auto-Allocation Service login credentials, the log file is located in the
user’s AppData directory.
 To access the log file for an Auto-Allocation Server:

1. Open the Auto-Server tile in the Administrator Dashboard.
2. Right-click the server in the Auto-Allocation Servers panel and select Open Log File. The file is
opened on the administrator machine using the application registered to view log files on the
machine.
Suspend and resume Auto-Allocation jobs

To suspend Auto-Allocation processing, click the Suspend Auto-Allocation Jobs icon on the
Auto-Server tile. The Auto-Allocation Server continues to run but no longer generates new jobs.
To resume Auto-Allocation processing, click the Resume Auto-Allocation Jobs icon on the Auto-
Server tile.

Use the Database Setup utility
Chapter 16. Use the Database Setup utility

After you have set up your user-defined tables, you must run the Database Setup utility to inform the
Allocation database of the names and structure of your tables, and to specify the groups, hierarchies,
levels, and merchandise types you want to use.
The Database Setup utility runs on the PC and modifies the Allocation database to consider your tables
and the names you have given the columns.
Before you start

Before you use the Database Setup utility, you must do the following.
 Create your WorkList and its associated tables: the WorkList table itself, the Merchandise Shape
tables, and the Detail tables.
 Create your Locations table.
 Create your List Source tables.
 Create your data collect Format tables.
 Decide on your groups and hierarchies.
 Decide on your merchandise types.
 Decide on the levels that you want to use.
 Configure your connection criteria from the Login dialog box.
Most fields in the dialog boxes in Database Setup are empty when you start.
Configure the database connection criteria

The database connection is initiated from the Database Setup or Administration Login dialog box. You
configure the initial connection after the schema has been set up and the database tables have been
built.
Follow these steps to configure the initial database connection.
1. To establish the connection, start Database Setup and click Configure on the Login dialog box.
2. A second dialog box is displayed that contains the fields required to configure a connection
between the database and the client. Enter the following information:
 User Name
 Password
 Schema Name (required only if different from User Name)
 Port (defaults to 1521)
 Service Name
 Server (Host Machine) Name
 TNS Entry (for RAC support – replaces port, service, and server options)

Note: The use of a TNS entry allows JDA Allocation to leverage RAC functionality via the local
Oracle TNSNames configuration. If selected, the connection file will only function on machines
with the same TNS entry defined. With this option, alternate nodes within the cluster can be
used as necessary to support failover, etc. However, it may be necessary to restart JDA
Allocation following a node failure or other connection change.
 LDAP Path: This optional configuration parameter allows a Microsoft Active Directory service
user to authenticate against the specified directory. It is required only for directory service
users. See the chapter "Maintain users" (on page 132) for more information.
Note: Selecting the option to accept Windows authentication for LDAP users allows the system
to leverage a user’s credentials from the Windows login without requiring them to re-enter a
password. If this option is selected, then the password field becomes disabled when the
currently authenticated operating system user’s Windows login name has been detected.
3. After entering the connection criteria, click OK from the Configure screen.
4. In the Save As dialog box, save the details to a file. The connection details are encrypted and
stored in this file.
5. After you successfully save the file, the Login dialog box is displayed. The new connection file is
displayed in the Connection box.
6. Select OK to proceed through Database Setup.
After a connection has been established, the fields on the Allocation Connection Configuration screen
are populated, based on the currently selected connection file. If you enter data that does not match
the currently populated connection file data, upon selecting OK, you are prompted with a confirmation
message asking whether you want to overwrite the current connection or save to a new file. If you
select the option to save to a new file, a Save As dialog box is displayed.
Multiple connections can be established, producing multiple files for various Allocation environments.
For example, you may want to establish a second environment for testing. After an alternate
connection has been configured, click the Connection ellipsis button to browse to and select another
connection file.
JDA recommends that a connection file be stored locally for each user.
Client Login
The Allocation client Login dialog box allows the entry of a Connection string. Each user is given the
name and the location of the connection file. At the first sign in, the user must browse to the file name
by selecting the Connection ellipsis button. The Connection box is populated with the last used
connection file path the next time the user logs in.
The Configure button, used for creating or editing a connection file, is only available on the
administrative components of the application.
After establishing a link to an Allocation database via a connection file, any system processes on that
machine that start Allocation will use that connection.
Command line login

The Allocation applications support several command line options to run processes in a batch mode. In
addition, the user ID, password, and connection file can all be specified on the command line. Entering
these values on the command line allows the login details to be specified without requiring the user to
enter the information into the login dialog box.
To start Allocation from a command line:


To specify a database connection file when starting Allocation, use the %CXN option. Be sure to specify
the full path for the connection file, and enclose the path and filename in quotes as in the following
example:

%CXN=”c:\documents and settings\userid\my documents\AL_dev.cxn”
Notes:
command line syntax to start any of the AL applications.
Support Logging Levels and other options

Various support options are available from the Login dialog box. You may right-click in any empty area
on the dialog box to display a shortcut menu with Support options.
The Logging Level is selected from options on a cascading menu. The default for Logging Level is
Normal. Note that you must select OK from the Login dialog to complete the Logging Level selection.
The Logging Level can also be set from within the application. For JDA Allocation, Allocation
Administration, and Auto-Allocation, the Logging Level can be selected from the Help Menu. For
Allocation Database Setup, the Logging Level options are available on the right-click shortcut menu for
every step.
Note that detailed log levels are for use when investigating application behavior in partnership with
JDA Support Services. At all other times, normal logging levels should be used, as detailed logging can
degrade application performance.
 The Microsoft Data Access Components (MDAC) Version information is available by selecting the
right-click shortcut menu option on the Login dialog box.
 The SQL Trace option is disabled and defaulted to None.
SQL Trace
To enable the SQL Trace menu item, press <ctrl + shift> while right clicking on the dialog.
If SQL Trace is already enabled (trace files are being generated on the server), you can access the SQL
Trace menu on the login dialog by simply right-clicking on the dialog.
Setup procedure
The Database Setup utility reads information from the database directly, and updates the database
with the changes you have made. You can save your position at any point in the process by saving the
database configuration to a database setup file on your PC.
Set up the database

You need to complete 11 steps to set up the database.
 "Step 1" (on page 91): Enter the table names. Provide the names and types of the tables you
created.
 "Step 2" (on page 92): Enter the dimension names. Provide the names you want to use for the
dimensions.

 "Step 3" (on page 93): Define the groups. Provide the names of the groups you want to use for
each dimension.
 "Step 4" (on page 94): Define the hierarchies. Provide the names of the hierarchies you want to
use for each dimension, and the groups that make up these hierarchies.
 "Step 5" (on page 95): Enter the column information. Provide extra information about the columns
in the WorkList tables, the Locations table, and the table containing the user information. All
columns on a table representing a group must be associated with the group in Step 5, including list
source, shape, format, WorkList, and detail tables.
Any column that contains a UMID (level 0) should not be associated to a group on Step 5 of
Database Setup. UMID must be mapped in Step 9 only.
 "Step 6" (on page 96): Define the levels. Provide the names of the merchandise levels you want to
use.
 "Step 7" (on page 96): Set up data collect parameters. Provide the names of the data collect
parameters you want to use, if any.
 "Step 8" (on page 97): Set up hierarchy ranges and associations. Define the groups that can be
used for data collect rules and product location restrictions (ranges within the hierarchies and non-
hierarchical groups).
 "Step 9" (on page 99): Set up column mappings. Define the columns that make up the Main Keys
of the tables you have created, the columns in the detail tables that refer to columns in the
WorkList table, and the columns in the Locations table, WorkList table, and Merchandise Shape
tables that map to the required and optional columns.
 "Step 10" (on page 101): Set up merchandise types and the merchandise ID (UMID). The
merchandise types describe the shape of your merchandise. The UMID is the item to be allocated.
This UMID is used as the top level of merchandise, level 0 in the database.
 "Step 11" (on page 103): Set up the JDA Allocation system parameters. Set a series of system-
wide parameters that determine the way the application works; for example, these determine
whether Store Grading or Currently Allocated Quantities are to be used.
Start the Database Setup utility

1. Start the Database Setup utility. The Allocation System Login dialog box is displayed.
2. Type the system administrator user name and password, and click OK. Database Setup attempts
to process the system tables and regenerate the data types. Database Setup loads the tables and
Step 1: User-Defined Tables is displayed.
If Database Setup is unable to lock the users out of the database, you are prompted to retry (after
ensuring that no users are working on the database), cancel the operation, or skip the process. If you
skip the process, you will be unable to update the database.
Jump to steps
To move through the steps of Database Setup one at a time, click Back or Next. If you want to go to
a particular step, you can use the shortcut menu.
To choose a step from the shortcut menu:
1. Right-click in the gray area. The shortcut menu lists the 11 steps.
1. Tables

2. Dimensions
3. Groups
4. Hierarchies
5. Columns
6. Levels
7. DC Parameters
8. Ranges & Associations
9. Column Mappings
10. Merchandise Types
11. System Parameters
2. Choose a step. The program jumps to the step.
Database setup files

At any point while using the Database Setup utility, you can save changes you made to a database
setup file on your PC. When you next start the utility, you can open the file and continue where you
left off.
To save a setup file:
1. Click Save. The program asks for a name and location for the setup file.
2. Type a name and path for the setup file, and click OK. The setup file is saved.
To open a setup file:
1. Click Open. The program asks for a name and location for the setup file.
2. Select the setup file you want to open, and click OK. The setup file opens, and you can continue
making changes.
Step 1: Enter the table names

Provide the names and types of the tables you created. These tables must exist on the database. In
this step, you can enter a new table name, edit a table type and description, or remove a table name.
When you finish adding, editing, or removing the table names, click Next to go to "Step 2: Enter the
dimension names" (on page 92).
Enter a new table name

1. Click New. The Table Name, Table Type, and Table Description boxes at the top of the dialog
box are cleared.
2. Type the name of the table you created on the database in the Table Name field. Select the
Table Type from the list. The table type can be one of the following.
 Merchandise Shape
 Detail
 Format
 List Source

 Staging
Leave the table type for the Locations, Users, and WorkList tables blank. If you have a CAQ_HOST
or GRADE table, leave the type for those tables blank also.
3. Type a Table Description, if required. The table description must be fifty characters or less.
For data collect Format tables, the table description is used as the format name. When users are
prompted to select a format table, they can choose from the table descriptions entered here.
4. Click Set. The table is added to the list.
Edit a table
To change the type and description of a table:
1. Select the table you want to edit. The table's details are displayed in the Table Name, Table
Type, and Table Description boxes.
2. Change the Table Name, Table Type, and Table Description, as appropriate.
3. Click Set. The table details are updated.
Remove a table name

When removing a table name, verify that you have removed any references to the table.
1. Select the table you want to remove from the list. The table's details are displayed in the Table
Name, Table Type, and Table Description boxes.
2. Click Remove, then click Yes to confirm. The table details are removed from the list.
3. Click Next to move to Step 2 (on page 92) of Database Setup. Database Setup removes all
references to the table you removed; it does not remove the table from the database.
4. Click Finish, then click Update to commit the deletion.
5. After removing the table name through Database Setup, you can use SQL*Net, for example, to
issue the Drop Table command for the tables you want to remove.
Step 2: Enter the dimension names

Provide the display names of the dimensions. These names are displayed when users view the
dimensions. Product is the only dimension currently used by JDA Allocation, but Location and Time are
included for future compatibility.
Change the display name of a dimension

1. Select the dimension for which you want to change the display name. The dimension name and the
display name are displayed in the boxes at the top of the dialog box.
2. Type the new name for the dimension in the Display Name field, using fifty characters or less.
3. Click Set. The dimension name is updated.
When you finish naming the dimensions, click Next to go to "Step 3: Define the groups" (on page 93),
or Back to return to "Step 1: Enter the table names" (on page 91).

Step 3: Define the groups

Provide the names of the groups you want to use for the Product dimension. Each group may have an
associated List Source table. For example, if in Allocation Administration, you require vendor codes to
establish new product restrictions, you can add a List Source table of vendor codes. The List Source
table is the name of the Oracle table that contains the valid vendor names and codes.
These groups are ordered to make up your hierarchies.
When using the application's built-in data collect and plan data, do not use Oracle reserved words (for
example, SIZE) or words containing spaces for group names, because the group names will be used
for column names on your staging areas. You must also make sure that group names and level names
match.
JDA Allocation supports up to 32 groups for use as attributes in PLRs and Data Collect rules.
When you finish defining the groups, click Next to go to "Step 4: Define the hierarchies" (on page 94),
or Back to return to "Step 2: Enter the dimension names" (on page 92).
Define a new group

1. Click New.
2. Select a Dimension from the list.
3. Type a Group Name, using fifty characters or less.
4. Select a List Source table from the list, if required. You can select only those tables that were
flagged as List Source tables in Step 1: User-Defined Tables.
5. Select the column that contains the group member codes from the Code list.
6. Select the column that contains the names associated with the group member codes from the
Name list.
7. Select the Data Collect Operator code from the Op Code list. This code determines the
operations that can be performed on this group. You can choose from:
= Check for equality
=, <> Check for equality or inequality
All All operations (=, <>, >, >=, <, <=)
8. Select a Staging Area table from the list, if required. You can select only those tables that were
flagged as Staging tables in "Step 1: Enter the table names" (on page 91).
9. Click Set. The group is added to the list.
Edit a group
1. Select the group you want to edit from the list. The group's details are displayed in the boxes at
the top of the dialog box.
2. Change the details, as necessary.
3. Click Set. The group details are updated.
Remove a group
1. Select the group you want to remove from the list. The group's details are displayed in the boxes
at the top of the dialog box.

2. Click Remove. The group is removed from the list.
You cannot remove a group that is referred to elsewhere. For example, if the group Department is
associated with the column Dept_Nbr in the WorkList (using "Step 5: Enter the column information"
(on page 95)), you cannot remove the group.
Step 4: Define the hierarchies

Provide the names of the hierarchies you want to use for each dimension, and indicate which groups
make up these hierarchies. Each hierarchy belongs to a single dimension, and contains groups that
belong to the same dimension.
Any group that is not part of the actual or main hierarchy needs to belong to an alternate hierarchy, if
it is needed for a data collect. If the group is created for restrictions, it does not need to be part of a
hierarchy.
When you edit a hierarchy, you must re-enter any ranges or associations set up using "Step 8" (on
page 97). Database Setup removes all associations and ranges for a hierarchy that has been edited to
prevent inconsistencies in the database.
When you finish adding, renaming, or removing the hierarchies, click Next to go to "Step 5: Enter the
column information" (on page 95), or Back to return to "Step 3: Define the groups" (on page 93).
Create a new hierarchy

1. Select the Dimension for which you want to create a hierarchy. The current list of hierarchies for
that dimension is displayed in the Hierarchy field.
2. Click New. The Enter Hierarchy Name dialog box is displayed.
3. Type the name of the hierarchy, using fifty characters or less, and click OK. The new hierarchy is
displayed in the list. The hierarchy is empty. You must edit the detail of the hierarchy to add
groups. See "Editing a hierarchy" (on page 94) for details.
Rename a hierarchy
1. Select the hierarchy you want to rename.
2. Click Rename. The Rename Hierarchy dialog box is displayed.
3. Type the new name, and click OK. The new hierarchy name is displayed in the list.
Remove a hierarchy
1. Select the hierarchy you want to remove.
2. Click Remove, and confirm the removal. The hierarchy is removed from the list.
Edit a hierarchy
1. Select the hierarchy you want to edit.
2. Click Edit Detail or double-click the hierarchy name.
The Available Groups field shows the groups associated with the current dimension that have not
been put into the current hierarchy.
3. To add a group from the list of available groups to the list of groups in the hierarchy, select the
group you want to move, and click the >> button, or double-click the group you want to move.
When you add a group to the hierarchy, it is displayed at the bottom of the hierarchy. Add the
groups to the hierarchy in the order in which you want them to display.

4. To move a group from the list of groups in the hierarchy to the list of available groups, select the
group you want to move, and click the << button; or double-click the group you want to move.
5. Click OK when you finish.
Step 5: Enter the column information

Provide extra information about the columns in the WorkList tables, the Locations table, and the table
containing the user information.
It is critical that all columns on any table representing a group must have that information established
in Step 5, including list source, shape, format, WorkList, and detail tables. There are no exceptions to
this rule. Without this information, the application cannot function properly.
The tables are shown with any new tables at the bottom of the list.
You must provide:
 The dimension (if any) to which the column belongs
 The group (if any) to which the column refers
 The name to be displayed to the users instead of the column name
 The optional display format
 Whether the user can edit the entry in the column
Caution:
 You cannot use operators, reserved words, or special characters (for example, apostrophe) in
display names.
 The display names for each column on the table must be unique within that table.
 Display names cannot match column data values that could be used in filters, because JDA
Allocation parses the filter text to replace column descriptions with actual column names.
When you finish entering the column information, click Next to go to "Step 6: Define the levels" (on
page 96) or Back to return to "Step 4: Define the hierarchies" (on page 94).
Edit the column information

1. Select the line from the list that refers to the column you want to edit. The column's details are
displayed in the boxes at the top of the dialog box.
2. Do one or more of the following:
 To change the dimension, select one of the dimensions from the Dimension list. If you specify
a dimension, you must specify a group.
 To change the group associated with the column, select one of the groups associated with the
current dimension from the Group list. If you specify a group, you must specify a dimension.
 To change the name that is displayed to users, type the name in the Display Name box. Do
not user operators, reserved words, or special characters, for example, apostrophe (').
 Select a number format from the Number Format dialog box using the ellipsis button in the
Format column. For details on number formatting, see the Online Expert (OLE) by selecting
Help from Allocation Database Setup.

 To change whether users can edit entries in the column, select Yes or No from the Edit? list.
For example, you might have a column for distributors' comments in the WorkList table. You
would set Edit? to Yes to allow the user to type text into the column to be saved on the
database. This information could be extracted from the database along with the results.
3. Click Set. The column details are updated.
Step 6: Define the levels

Provide the names of the merchandise levels you want to use.
Two merchandise levels are used as the top level: the Unique Merchandise ID (UMID) and the Unique
Pack ID (UPID). The UPID consists of the UMID plus the pack ID. The UMID is used as the top level
when allocating bulk merchandise, and the UPID is used as the top level when allocating pack
merchandise. The application does not support multiple records per store above the top level on a
format table for a single data collect request. See "Set up tables to hold collected data" (on page 51)
for details.
When using the application's built-in data collect and plan data, do not use Oracle reserved words (for
example, SIZE) for level names. You must also make sure that level names and group names match.
When you finish adding, editing, or removing the levels, click Next to go to "Step 7: Set up data collect
parameters" (on page 96), or Back to return to "Step 5: Enter the column information" (on page 95).
Add a new level

1. Click New.
2. Type the name of the level in the Level Name box. Make sure you add levels in hierarchical order.
3. Click Set. The level is added to the list.
Edit a level
1. Select the level you want to edit. The level details are displayed in the boxes at the top of the
dialog box.
2. Edit the details.
3. Click Set. The level details are updated.
Remove a level
1. Select the level you want to remove. The level details are displayed in the boxes at the top of the
dialog box.
2. Click Remove, and confirm the removal. The level is removed from the list. The levels are
renumbered.
You cannot remove levels that are used in the logical mappings for the WorkList table, format tables,
or Merchandise Shape tables.
Step 7: Set up data collect parameters

You can set up data collect parameters to tell the host system the sort of data collect that is to be
carried out. This step is optional.
Data collect parameters are stored as part of the data collect rules. They can act as flags for your host
system to aid in determining the sort of data collection to be carried out.

Note: The Data Collect parameter 'A' is reserved for plan data and should not be changed or used for
any other purpose.
When you finish setting up the data collect parameters, click Next to go to "Step 8: Set up hierarchy
ranges and associations" (on page 97), or Back to return to "Step 6: Define the levels" (on page 96).
Add a new parameter

1. Click New.
2. Type the parameter code in the Parameter Code box. This code must be a single character and
cannot be "-".
Note: The parameter 'A' is reserved for plan data.
3. Type the description for the parameter in the Parameter Description box.
4. Click Set. The parameter is added to the list.
Edit a parameter
1. Select the parameter you want to edit. The parameter details are displayed in the boxes at the top
of the dialog box.
2. Edit the details.
3. Click Set. The parameter details are updated.
Remove a parameter
1. Select the parameter you want to remove. The parameter details are displayed in the boxes at the
top of the dialog box.
2. Click Remove, and confirm the removal. The parameter is removed from the list.
Step 8: Set up hierarchy ranges and associations

Specify the groups that can be used for data collect rules and product location restrictions. You specify
the ranges within the hierarchies can be used for each rule, and the non-hierarchical (associated)
groups.
For example, you might want a data collect rule that requires data to be collected for Dept 105, Class
10, Style 110, Vendor 1961. This rule consists of a range in the main hierarchy (Department, Class,
Style, and Color) and a non-hierarchical group, Vendor. To create the rule, you would specify a range
of the hierarchy.
Hierarchy Range Association

Division
Department Department
Class Class Vendor
Style Style
Color
Then, associate the non-hierarchical group Vendor with one or more groups in the range, for example,
Class. When the administrators select a value for Class, they can select a value for Vendor.
When you finish setting up hierarchy ranges and associations, click Next to go to "Step 9: Set up
column mappings" (on page 99), or Back to return to "Step 7: Set up data collect parameters" (on
page 96).

Note: After Ranges are established, any future changes to a range could make existing rules and
restrictions invalid. Before changing any range for data collect rules, product location restrictions, or
like stores, be sure to remove all items that depend on the range.
Add a new range

Set up ranges and associations for data collect rules and product restrictions.
1. Select one of the range types from the list at the top of the dialog box. This type can be one of the
following.
 Product Restrictions
 Like Store
 Data Collect
The current range or list of ranges for that type of hierarchy range is displayed.
2. Select the Dimension from the list.
3. Select the Hierarchy from the list of hierarchies (created in "Step 4" (on page 94)) in the current
dimension.
4. For Data Collect only, select a Parameter from the list. If you have no parameters, select
<None>.
5. For Data Collect only, select a Format name from the list. The format name is the description of
the format table provided in "Step 1: Enter the table names" (on page 91).
6. Select a Start Group from the list. This group is the first group in the hierarchy for which the user
can enter a value.
7. Select a Stop Group from the list. This group is the last group in the hierarchy for which the user
can enter a value. If you want the user to enter a value only for a single group, the stop group can
be the same as the start group.
8. Click Set. The hierarchy range is added to the list.
You can specify a single hierarchy range for Product Restrictions. When setting the hierarchy ranges
for Data Collect, you can specify a range once for each combination of format table and parameter.
You can only define one range for the like store hierarchy.
Edit a range
1. Select one of the range types from the list at the top of the dialog box.
2. Select the range you want to edit. The range details are displayed in the boxes at the top of the
dialog box.
3. Edit the details. After you create a range, you can change only the start and stop groups.
4. Click Set. The range details are updated.
Remove a range
1. Select one of the range types from the list.

2. Select the range you want to remove. The range details are displayed in the boxes at the top of
the dialog box.
3. Click Remove, and confirm the removal. The range is removed from the list.
Change associated groups

To associate non-hierarchical groups with members of the hierarchies:
1. Select the hierarchy range for which you want to set up the associated groups.
2. Click Associate. The Hierarchical Associations dialog box is displayed.
3. Select the member of the current hierarchy from the Hierarchy Member list.
The Groups in Dimension box shows the groups that can be associated with that member; the
Groups associated with Hierarchy Member box shows the groups that have been associated
with that member.
4. To associate a group with a member, select a group from the Groups in Dimension list and click
>>. The group is associated with the hierarchy member.
5. To disassociate a group from a member, select a group from the Groups associated with
Hierarchy Member box and click <<. The group is disassociated from the hierarchy member.
6. Select another member of the current hierarchy from the list, and confirm that you want to make
the changes.
7. Make associations for all hierarchy members you want, click Apply to apply the changes, then click
Close to return to the Hierarchy Ranges dialog box.
The associations are made. Every time the administrator creates data collect levels or product location
restrictions, these associated groups are available as optional components.
JDA Allocation does not support non-hierarchical group associations for Like Store. The Associate…
button is disabled when Like Store is selected as the hierarchy range.
Note: After external groups are associated with a group in a range, any future changes to the range or
group association could make existing rules and restrictions invalid. Before changing any associated
group for data collect rules or product location restrictions, be sure to remove all items that depend on
the group.
Step 9: Set up column mappings

Specify the columns that make up the primary keys or most important unique keys of the tables you
have created, the columns in the detail tables that refer to columns in the WorkList table, and the
columns in the Locations table, data collect Format tables, WorkList table, and Merchandise Shape
tables that map to required and optional columns.
New tables are displayed at the bottom of the list.
You must set up the keys for each table before carrying out this step. Database Setup does not create
the primary keys or unique keys in the database for you.

Map required and optional columns

When you create the WorkList table, the Locations table, data collect Format tables, Store Grading,
CAQ, and the Merchandise Shape tables, you must include some required columns that the application
needs for its own purposes. You can include some optional columns that change the way the
application works.
These columns may have any name, but you must specify the required and optional columns to which
they map, using this step.
To map required and optional columns:
1. Select the table for which you want to map the required and optional columns. You can choose the
WorkList table, the Locations table, CAQ table, Store Grade table, or any of the Merchandise Shape
tables or Format tables.
2. Click Mappings. The Column Mappings dialog box is displayed.
3. To map a required or optional column to one of the columns in the table, select the name in the
Required Columns or the Optional Columns list.
Note: The WorkList must contain only mapped level columns that are common to all merchandise
being allocated.
For example, you cannot have a level column on the WorkList for color if some merchandise does
not use that level. Although the Color column may exist on the WorkList, and be populated for
those items that go down to that level, it must not be mapped. If the merchandise does have a
color level, this level allows the user to quickly see the color of the items on the WorkList, but it
does not cause the system to attempt to include the color level for merchandise that has no color.
If some items to be allocated do not go down to the color level, the color information must be
mapped on the appropriate Merchandise Shape Table only.
Note: The Optional Column Source Warehouse must be mapped for the WorkList table, if a Default
Source Warehouse is to be specified on entry to the WorkSheet. See "Set up product location
restrictions by source warehouse" (on page 104).
If the column is already mapped, you can unmap it by clicking Un-Map. To map the column, select
the column to which it refers in the Columns on Table list and click Map. If the column is already
mapped, you can remap it by clicking Re-Map.
4. When you finish mapping all required columns, and as many of the optional columns as you used,
click OK.
Set the Main Key information

You must provide the Main Key information for all tables you create. This key is the major key in the
table you create; it can be the primary key if you have one, or the largest unique key. You must set
the primary key or unique key in the database for the table before you carry out this step.
To set the Main Key information:
1. Select the table for which you want to provide Main Key information, and click Main Key. The Main
Key Maintenance dialog box is displayed.
Available Columns lists the columns in the table that are not part of the Main Key. Main Key
lists the columns that are part of the Main Key.
2. To specify that a column is part of the Main Key, select the column name in Available Columns
and click >>. The column name is moved to Main Key. You must enter the columns for the Main
Key in the order in which they are displayed in the primary key.

3. To specify that a column is not part of the Main Key, select the column name in Main Key and
click <<. The column name moves to Available Columns.
If you are setting the Main Key for a Detail table, Currently Allocated Quantities (CAQ_HOST) table, or
Store Grading (GRADE) table, you must specify the columns in the primary key that refer to columns
in the WorkList table.
Map columns to WorkList columns

You must specify the columns in the primary key of a Detail table, Currently Allocated Quantities
(CAQ_HOST) table, or Store Grading (GRADE) table that refer to columns in the WorkList table. These
mappings are used to update CAQ and determine default grading.
To map columns to WorkList columns:
1. Select the table and click Main Key. The Main Key Maintenance dialog box is displayed.
2. Click Map to WL to set up the mappings to the WorkList table. The Map Main Key to WorkList
dialog box is displayed.
3. To map a column from the Main Key to a WorkList column, select one of the entries in the list. The
details are displayed in the Main Key and WorkList Column boxes at the top of the dialog box.
4. Select the WorkList column to which the column refers from the WorkList Column list.
5. Click Set.
6. When you finish mapping all columns in the Main Key that refer to columns in the WorkList table,
click Close.
Step 10: Set up merchandise types

You must set up merchandise types that describe the shape of the merchandise to be allocated. You
can set up as many merchandise types as you need. For example, you would set up a different
merchandise type for a style with colors and sizes than a SKU that has no color or size. You must set
up a merchandise type for packs. They may or may not have a different merchandise type than bulk
merchandise. To allocate WorkList lines together, the lines must have the same merchandise type.
As part of this step, you must select the columns from the WorkList table that make up the identifying
information of the Unique Merchandise ID (UMID). The merchandise ID refers to the item to be
allocated. You must make sure that this ID is unique across your product hierarchy and include as
many columns as necessary to make it so. The UMID columns must include the style group as the last
group in the UMID. This ID is used as the top level of merchandise, level 0 in the Allocation database.
Note: The built-in data collect requires that the UMID be populated from groups on your staging table
during the data collect. Only use groups in your UMID that exist as columns on your staging tables. In
other words, build your UMID using WorkList columns (groups associated with WorkList table columns
on Step 5)) that also exist as staging tables columns (groups associated with Staging table columns on
Step 5).
The Unique Pack ID (UPID) is used to identify packs and consists of the UMID plus the Pack ID. The
pack ID column may be selected from either the WorkList or the Shape tables. The Unique Pack ID
must uniquely identify a pack across all merchandise. For example, two packs of the same style and
size combinations but different colors must have different UPIDs.
The UMID structure for all merchandise types used in the database must be the same. Pack
merchandise types must use the same UPID structure.

If you are using multiple columns to uniquely describe your merchandise, you must decide on the
separator character to be used when displaying the UMIDs. For example, if the merchandise ID
comprises department, class, and style, and the separator character is a period, an item of department
100, class 20, style 17371 would be displayed as 100.20.17371.
Notes:
 Concatenating multiple columns to make up the UMID is only necessary if the item you are
allocating cannot be uniquely described by a single column. For example, if your style number is
unique on its own and is not duplicated in any other class, department, etc., the UMID can be
comprised of the style number column alone.
 Like all WorkSheet levels, the UMID (level 0) must use a text data type. If it consists of
concatenated fields to make the value unique, then it will automatically be treated as text;
however, if it consists of only one WorkList field, such as STYLE_NUMBER, then that field must be a
text data type on the WorkList.
 The UMID/UPID structures have a maximum length of 50 characters.
Add a new merchandise type

1. Click New Type. The New Merchandise ID Type dialog box is displayed.
2. Type the name of the Merchandise Type and assign a Type ID. (The Type ID is displayed in the
WorkList.)
3. Select the Allocation Type option, which can be Bulk or Pack. (We do not recommend the use of
Multiples).
4. Select the Merchandise Shape Table, if any, that you want to use for this merchandise type
from the list.
5. Click OK.
Note: Multiples are no longer recommended for use as a shape type and are only listed to support pre-
existing customers.
Build the Unique Merchandise ID

1. Select the WorkList radio button in the Show Columns For: box.
2. Select each column from the list on the left that defines your UMID and click >>.
3. To remove a column from the UMID, select the column you want to remove, and click <<.
Notes:
 You must add the columns to the Unique Merchandise ID in the order in which you want them to
display. The UMID must include the style column and it must be the last column.
 The UMID must contain the same columns for each Merchandise Type that is defined.
 The UMID must not exceed 50 characters.
Build the Unique Pack ID

1. Select the WorkList or Shape Table radio button in the Show Columns For: box.
2. Select each column from the list on the left that defines your UPID and click >>.
3. To remove a column from the UPID, select the column you want to remove, and click <<.

Notes:
 The UPID must contain the same columns (UMID + Pack ID) for each Pack Merchandise Type that
is defined. The UMID columns must come from the WorkList table. The pack ID column may be
selected from either the WorkList or the Shape tables. All columns from the WorkList table must
come before any columns from the Shape tables.
 The maximum length for a UPID (UMID + Pack ID) is 50 characters.
Remove a merchandise type

1. Select the merchandise type you want to remove from the Merchandise Type list.
2. Click Remove, and confirm the removal.
Set the Unique Merchandise/Pack ID column separator

1. Click Separator. The Merchandise ID Type Separator dialog box is displayed.
2. Type the character you want to use in the Separator box.
3. Click OK.
Note: The separator character must not be present in the data for any column that makes up the
UMID/UPID.
Step 11: Set the JDA Allocation system parameters

You must set the system-wide parameters. These parameters affect all users. They should be set up at
installation time and will not likely change. Details on parameter configuration can be found in the
Online Expert (OLE) by selecting Help from Allocation Database Setup.
Update the database

To update the database when you have made your changes:
1. Click Finish. You are asked if you want to make the changes, or to save your changes to a
database setup file.
2. To make the changes, click Update. The program modifies the database.
You can update the database only if no users are currently working on the database. If users are
working, you can save your changes in a database setup file and run the update later, when everyone
has logged out of the database.
Selecting the Update to SQL script file option allows you to update the database indirectly by
spooling the database update to a script that your DBA can run to perform the database update. If this
option is selected, the script that is produced must not be modified. The updates will not take place
until the script has successfully run.
When the database is being updated, you may be prompted to rebuild the CAQ Repository. This rebuild
does not refresh values in the CAQ_HOST table; it just makes sure that the procedures and tables
used by Allocation to maintain the data in CAQ_HOST are up-to-date, based on your current
configuration.
You may also be prompted to map and associate columns on the staging tables for historical data. If
using the built-in data collect, this process can verify that all required mappings and associations for
the staging areas have been performed. If the staging areas, groups, levels, or column data types
have not been set up correctly, this process will fail.

In addition, you may be prompted to update the Model Stock DC statement Cache. This cache is used
by Model Stock data collects and contains information linking Shape tables, the WorkList table, and
Model tables. It must be rebuilt if mapping or group information on these tables has changed.
Set up product location restrictions by source

warehouse
To enable the set up of product location restrictions for a Source Warehouse in Allocation
Administration, follow these steps during Database Setup.
1. In "Step 3" (on page 93), set up a group named Source Warehouse.
2. In "Step 5" (on page 95), associate the Source Warehouse group with the FROM_WHSE column on
the WorkList Table.
Note: Any column on the WorkList Table that has a Group associated to it with the intent to set up
Product Location Restrictions cannot accept Null values).
3. In "Step 8" (on page 97), associate the Source Warehouse group with a level in the hierarchy.
4. In "Step 9" (on page 99), map the optional Source Warehouse column to the WorkList
FROM_WHSE column.
5. In "Step 11" (on page 103), select a default warehouse from the Undefined Source Warehouse
drop-down menu.
Note: A default warehouse must be specified if the Host System does not always populate the
Source Warehouse WorkList Table column with a value.
6. Set up the product location restrictions in Allocation Administration.
Note: Product location restrictions set up for a default source warehouse are applied to WorkList lines
upon entry to the WorkSheet.
Set up like store support

Like store support provides the ability to apply select store or store group historical data by variable to
a location that has no history or has history that is not useful.
To enable the creation of like store rules in Allocation Administration, follow these steps during
Database Setup.
1. In "Step 1" (on page 91), set like store hierarchy range member list source tables.
2. In "Step 3" (on page 93), groups and their list sources must be set for each planned member of
the like store hierarchy range.
3. In "Step 4" (on page 94), establish a like store hierarchy if like store rules are going to be built for
members in addition to those in the main product hierarchy.
4. In "Step 5" (on page 95), associate format and list source table columns representing members
included in the like store hierarchy range with their corresponding Group.
5. In "Step 8" (on page 97), define the like store hierarchy range.
6. In "Step 9" (on page 99), map the optional Like Store column to the format table LIKE_STORE
column.

Table definitions
Chapter 17. Table definitions

The following sections contain definitions for the tables that must be used for results collection and
data collection. There are three table types.
 Queue tables. These tables are used to pass information about actions that must be carried out, or
actions that have been carried out, between JDA Allocation and the user-written host system
procedures.
QUEUE_OUT
QUEUE_IN
 Results tables. These tables are used to obtain results of allocations to be transferred to your
RESULTS_HEADER
RESULTS_DETAIL
 Data Collect tables. These tables are used to provide JDA Allocation with Planning or historical data
from your existing systems.
DC_FORMAT_HEADER
DC_RULE_HEADER
DC_RULE_DETAIL
RTMM_GROUPS
PLAN_STAGING
PLAN_TIME_ORDER
You use these tables when passing information to and obtaining information from the application.
Queue tables
The tables QUEUE_IN and QUEUE_OUT are used to pass information between JDA Allocation and the
user-written host system procedures. The QUEUE_IN table is used by the host to pass information to
JDA Allocation, and the QUEUE_OUT table is used to pass information to the host.
You must set up procedures to read the QUEUE_OUT table periodically to check for data collection and
results collection codes, and procedures to write information to the QUEUE_IN table.
QUEUE_OUT
The QUEUE_OUT table is used to pass information to the host about actions that must be carried out.
You should purge all old QUEUE_OUT requests that have been handled during the data collect and
results collection procedures. Deleting the requests should normally be a part of these procedures.
However, an alternative approach of purging specific QUEUE_OUT records at scheduled intervals can
sometimes be used where appropriate, as long as the volume of QUEUE_OUT records does not
negatively affect performance of data collect, results processing, or results purging operations.
Name Type Null?

Queue_ID NUMBER not null
Queue_Entry_Type VARCHAR2(4) not null
DC_Rule_Key NUMBER
DC_Cond_Key NUMBER
Allocation_Nbr NUMBER
Action VARCHAR2(50)

Table definitions
Name Type Null?

CreateUser VARCHAR2(255) not null
CreateDate DATE not null
UpdateUser VARCHAR2(255) not null
UpdateDate DATE not null
XMLRequest LONG
XML_REQUEST CLOB
Queue_ID is a sequential number that uniquely identifies the entry in the queue.
Queue_Entry_Type is the type of action to be carried out; this type can be:
 Rule: data collect rule
 Cond: data collect condition
 Res: results collection
DC_Rule_Key is the number of the data collect rule to be carried out.
DC_Cond_Nbr is the number of the data collect condition to be added, changed, or deleted.
Allocation_Nbr is the number assigned to the WorkList lines when the distributor chooses to allocate.
Action is the action to be carried out; this action can be:
 Collect: collect data
 Add: add a rule or condition
 Change: change a rule or condition
 Delete: delete a rule or condition
 Rel: release results
CreateUser is the user ID of the user who created the record.
CreateDate is the date the record was created.
UpdateUser is the user ID of the last user to update the record.
UpdateDate is the date of the last update.
XMLRequest contains an XML description of the data collect request and has been made redundant by
the more capable XML_REQUEST field.
XML_REQUEST contains an XML description of the data collect request, and uses a data type of CLOB.
This avoids the field length restrictions of the XMLRequest field, which has been retained for historical
purposes.
QUEUE_IN
The QUEUE_IN table is used by the host to pass information to the application about data collections
that have been carried out.
Name Type Null?

Allocation_Nbr NUMBER not null

Table definitions
Name Type Null?

Status VARCHAR2(50)
Use_Built_In_DC VARCHAR2(1)
Allocation_Nbr is the allocation number of the merchandise for which the data collect was carried out.
Status is empty when the data collect succeeded, but can contain an error message that is passed to
the user when the data collect fails.
Use_Built_In_DC is the flag that determines if you want to use built-in data collect; this flag can be:
 Y: Yes
 N: No
Results tables
RESULTS_HEADER Table
The RESULTS_HEADER table lists the results sets to which allocation results must be written. It maps
the allocation numbers to the actual names of the results sets.
Name Type Null?

Allocation_Nbr NUMBER(15) not null
Saved_Name VARCHAR2(50)
Saved_Desc VARCHAR2(255)
User_ID VARCHAR2(30)
AAM_CreateUser VARCHAR2(30)
Global_Flag VARCHAR2(1)
Planning_TimeCode VARCHAR2(50)
ENV_INFORMATION CLOB
Saved_Name is the name of the saved results set.
Saved_Desc is the description of the saved results set.

Table definitions
User_ID is the system user ID.
AAM_CreateUser is the login ID.
Global_Flag is the flag that determines if the results set is global or personal; this flag can be:
 Y: global
 N: personal
Planning_TimeCode is no longer used by the application. It is set to null for every allocation.
ENV_INFORMATION contains the ENV details from completed allocations in an XML format. This
information is displayed by the system when reviewing an allocation.
RESULTS_DETAIL table
The RESULTS_DETAIL table contains the results of an allocation.
Name Type Null?

Allocation_Nbr NUMBER(15) not null
Location_ID VARCHAR2(50) not null
Unique_Mer_Key VARCHAR2(50) not null
WL_Key NUMBER(15) not null
Level1_Desc VARCHAR2(20) not null
Result_Qty NUMBER(15) not null
Reserve VARCHAR2(1) not null
Location_ID is the code for the location to which the merchandise should be sent.
Unique_Mer_Key is the UMID or UPID that uniquely identifies the merchandise. For example,
10.115.456 might mean Department 10, Class 115, Style 456.
WL_Key is the WorkList key that associates lines in the results table with the relevant entries in the
WorkList tables.

Table definitions
Level[1-5]_Desc are the descriptions of the level data: for example, if level 1 is color, the Level1_Desc
column might contain blue, red, or green for a batch of T-shirts.
Result_Qty is the amount of merchandise to be sent to the location. For pack merchandise, this
quantity is the number of packs.
Reserve indicates if a location was actually a warehouse that received units in the WorkSheet with a
value of N for this column. A warehouse that receives units in the reserve view will have a value of Y
for this column. It is possible that a warehouse that is enabled for Display in WorkSheet receives
merchandise both from the WorkSheet as well as the reserve view. The results processing interface
should aggregate results by allocation number and location when reading from this table because of
this.
RESULTS_STATISTICS table
The RESULTS_STATISTICS table contains details about an allocation.
Name Type Null?

ALLOCATION_NBR NUMBER(15) not null
VARIABLE_KEY NUMBER
TECHNIQUE_KEY NUMBER
VIEW_ID NUMBER
MODEL_KEY NUMBER
HOST_DC_RULE_KEY NUMBER
PLAN_DC_RULE_KEY NUMBER
USER_ID VARCHAR2(30) not null
GRADING VARCHAR2(1)
TEMPLATES VARCHAR2(1)
MINMAX VARCHAR2(1)
MODEL_BASED_MINS VARCHAR2(1)
MANUAL_ADJUSTMENTS VARCHAR2(1)
FORCE_TO_STORES NUMBER(15)
FORCE_TO_RESERVE NUMBER(15)
SOURCE_WAREHOUSE NUMBER(15)
DATA_COLLECT_DURATIO NUMBER(15)
N
NEED_GENERATION_DURA NUMBER(15)
TION
ALLOCATE_DURATION NUMBER(15)
AUTO_ALLOCATION VARCHAR2(1)
UINPUT_VAR_DEF_CHANG VARCHAR2(1)
ED

Table definitions
Name Type Null?

LIKE_STORES_APPLIED VARCHAR2(1)
NUMBER_OF_PACKS NUMBER(15)
NUMBER_OF_UMIDS NUMBER(15)
NUMBER_OF_LEVEL1_MEM NUMBER(15)
BERS
BERS
BERS
BERS
BERS
OVERRIDE_LOC_REST VARCHAR2(1)
NEED_DETAIL table
The NEED_DETAIL table contains the final Need values by store at the level that Need was generated
in the allocation if Enable Saving and Loading of Need Values with Results is selected in
Allocation Database Setup step 11. The structure is similar to RESULTS_DETAIL; however, the Need
level may be higher or lower than the level of data in the RESULTS_DETAIL table. If the Need is above
the UMID level, then the WL_KEY will be set to -1, as Need by store cannot be associated with an
individual WorkList key of an allocation.
Name Type Null?

ALLOCATION_NB NUMBER(15) not null
R
LOCATION_ID NUMBER(15) not null
WL_KEY NUMBER(15) not null
LEVEL0_DESC VARCHAR2(50 not null
)
)
)
)
)
)
NEED_QTY NUMBER(15,4 not null
)

Table definitions
Data collect tables

DC_FORMAT_HEADER table
The DC_FORMAT_HEADER table lists the format tables to which collected data must be written. It
maps the format numbers to the actual names of the format tables.
Name Type Null?

DC_Format_Nbr NUMBER not null
Table_Name VARCHAR2(30) not null
DC_Format_Name VARCHAR2(50)
DC_Format_Nbr is the format number.
Table_Name is the name of the table to which the number applies.
DC_Format_Name is the name that the users pick when selecting a format table.
DC_RULE_HEADER table
The DC_RULE_HEADER table lists the data collect rules that can be carried out. The details of the rules
are stored in the DC_RULE_DETAIL table.
Name Type Null?

DC_Rule_Key NUMBER not null
DC_Format_Nbr NUMBER not null
Rule_Template_Param VARCHAR2(1) not null
DC_Rule_Name VARCHAR2(50)
Temporary_Flag VARCHAR2(1) not null
Variable_Key NUMBER
Parent_DC_Rule_key NUMBER
Host_DC_Template_key NUMBER
Plan_DC_Template_key NUMBER
DC_Rule_Key is the number of the data collect rule. This column is mapped to the DC_Rule_Key
column in the DC_FORMAT_DETAIL table.

Table definitions
DC_Format_Nbr is the number of the format table to which results must be written. This column is
mapped to the DC_Format_Nbr column in the DC_FORMAT_HEADER table.
Rule_Template_Param is the flag that determines whether the entry is a rule or a template; this flag
can be:
 R: rule
 T: template
DC_Rule_Name is the name of the data collect rule.
Temporary_Flag is the flag that determines whether the rule is temporary. Temporary rules are
deleted after the data collect is run; this flag can be:
 Y: temporary
 N: permanent
Variable_Key is the variable key of the request. This is used only if your business requires multiple
levels of collected data to be used in a single Need calculation.
The three remaining columns (Parent_DC_Rule_key, Host_DC_Template_key, and

Plan_DC_Template_key) are used internally by the application.
DC_RULE_DETAIL table
The DC_RULE_DETAIL table describes the data to be collected for each data collect rule.
Name Type Null?

DC_Rule_Key NUMBER not null
DC_Rule_Phrase_Nbr NUMBER not null
DC_Rule_Component_N NUMBER not null
br
DC_Rule_Parameter_Co VARCHAR2(1) not null
de
Dimension_Nbr NUMBER not null
Group_Nbr NUMBER not null
Hierarchy_Nbr NUMBER not null
DC_Rule_Operand_Code VARCHAR2(2) not null
DC_Rule_Value VARCHAR2(50)
DC_Rule_Key is the number of the data collect rule. This column is mapped to the DC_Rule_Key
column in the DC_RULE_HEADER table.

Table definitions
DC_Rule_Phrase_Nbr is the number of the phrase of the current rule. There can be several phrases
within each rule if you implemented parameters; each phrase uses a different parameter.
DC_Rule_Component_Nbr is the number of the component of the current phrase of the current rule.
DC_Rule_Parameter_Code is the parameter code associated with the rule. You can use this code to
mark different kinds of data collection, depending on how you collect data from your host system.
Dimension_Nbr is the dimension number of the rule element; for example, dimension number 1 might
be mapped to Product.
Group_Nbr is the group number of the rule element; for example, group 1 in dimension 1 might be
mapped to Department in the RTMM_GROUPS table.
Hierarchy_Nbr is the number of the hierarchy used for the current data collect rule.
DC_Rule_Operand_Code is the operation to be performed on the rule element; for example, "=". See
"DC_Rule_Operand_Code" under "Set up custom data collect procedures" (on page 57) for a list of
valid codes.
DC_Rule_Value is the value against which the rule element must be tested.
An example of Dimension_Nbr, Group_Nbr, DC_Rule_Operand_Code, and DC_Rule_Value is:
Dimension_Nbr 1
Group_Nbr 2
DC_Rule_Operand_Code =
DC_Rule_Value 20
which translates to "Division = 20", if group 2 in division 1 maps to "Division". This item is a single
component of the data collect rule.
RTMM_GROUPS table
The RTMM_GROUPS table describes the groups that can be used for data collection. You must look in
this table to find the names of the groups for which data must be collected.
Name Type Null?

Dimension_Nbr NUMBER not null
Group_Nbr NUMBER not null
DC_Operand_Code VARCHAR2(2)
Table_Name_Source VARCHAR2(30)
Attribute_Nbr_Display1 NUMBER
Attribute_Nbr_Display2 NUMBER
Group_Name VARCHAR2(50)

Table definitions
Name Type Null?

Staging VARCHAR2(50)
Format_Prefix VARCHAR2(50)
Dimension_Nbr is the number of the dimension.
Group_Nbr is the number of the group.
DC_Operand_Code is the data collect operand associated with the group. See
"DC_Rule_Operand_Code" under "Set up custom data collect procedures" (on page 57) for a list of
valid codes.
Table_Name is the name of the list source table for the group, if one exists.
Attribute_Nbr_Display1 is the column in the list source table that contains the codes for the group, for
example, Dept_Code.
Attribute_Nbr_Display2 is the column in the list source table that contains the display names for the
group members, for example, Dept_Name.
Group_Name is the name of the group.
Plan tables
PLAN_STAGING table
The PLAN_STAGING table contains columns for all groups in your plan hierarchy. Because it depends
on the implementation hierarchy, the following table is one example of how the table would be
structured.
Name Type Null?

Planning Variable 1-n NUMBER(15)
Division VARCHAR2(30)
Department VARCHAR2(30)
Class VARCHAR2(30)
Style VARCHAR2(50)
Level1 VARCHAR2(50)
Level2 VARCHAR2(50)
Level3 VARCHAR2(50)
Level4 VARCHAR2(50)
Level5 VARCHAR2(50)
Time_Code VARCHAR2(50)
Product_Key VARCHAR2(50)

Table definitions
Name Type Null?

Location_ID NUMBER(15)
Planning Variable columns are determined by the base variable list and the number of time periods.
Division, Department, Class, and Style are examples of columns, and are based on the planning
hierarchy.
Level[1-5] are the levels below style, such as color, size, and width.
Time_Code is the starting time period for the record.
Product_Key is an internal reference for the product for which you are collecting data. Do not use this
column.
Location_ID is the code for the location.
PLAN_TIME_ORDER table
The PLAN_TIME_ORDER table holds planning time codes used to determine the starting time period for
a planning data collect. You can choose to use only one plan time code and replace all the data in your
PLAN_STAGING table every time period.
Name Type Null?

Seq_Nbr NUMBER Not Null
Time_Code VARCHAR2(50) Not Null
CreateUser VARCHAR2(255) Not Null
CreateDate DATE Not Null
UpdateUser VARCHAR2(255) Not Null
UpdateDate DATE Not Null
TIME_TECH_KEY NUMBER
Seq_Nbr is an order of the record (Time_Code). This column contains sequential, continuous integer
values to indicate the intended order of the time codes. The minimum value should be 1.
Time_Code is the list of time codes.
CreateUser is the user ID of the user who created the record. This column is updated automatically.
CreateDate is the date the record was created. This column is updated automatically.
UpdateUser is the user ID of the last user to update the record. This column is updated automatically.
UpdateDate is the date of the last update. This column is updated automatically.
TIME_TECH_KEY is used by the system when it collects Enterprise or Assortment Planning data from
EKB. It should be left NULL when populating plan data from other sources.

Example tables
Chapter 18. Example tables

This chapter provides example user-defined tables for JDA Allocation. It contains examples of the
following tables.
 WorkList table
 List Source tables
 Merchandise Shape tables
 Detail tables
WorkList table
The WorkList table must be called WORKLIST.
Structure of the WorkList table

Here is the structure of an example WorkList table.
WORKLIST Column name Type Null? Keys

WL_Key NUMBER(15) not null Unique
Merch_Type NUMBER(15) not null
Alloc_Nbr NUMBER(15)
AA_Job_Number NUMBER(15)
Allocation_User VARCHAR2(30)
Status_Code VARCHAR2(4)
Status_Desc VARCHAR2(50)
Status_Timestamp DATE
Current_Activity VARCHAR2(81)
Trouble_Code VARCHAR2(3)
DC_Rule_Info VARCHAR2(50)
DC_Status_Code NUMBER(15)
DC_Status_Desc VARCHAR2(50)
DC_Status_Timestamp DATE
Method_Name VARCHAR2(90)
Model_Name VARCHAR2(50)
Store_View_ID VARCHAR2(50)
Dest_Whse_Nbr NUMBER(15)
Srce_Whse_Nbr NUMBER(15)
Avail_Qty NUMBER(15)
Document_Type VARCHAR2(15) not null 1
Document_Nbr NUMBER(15) not null 2
Division_Code NUMBER(15)
Division_Name VARCHAR2(25)
Dept_Code NUMBER(15) not null 3

Example tables
WORKLIST Column name Type Null? Keys

Dept_Name VARCHAR2(25)
Class_Code VARCHAR2(5) not null 4
Class_Name VARCHAR2(25)
Style_Code VARCHAR2(15) not null 5
Style_Name VARCHAR2(25)
Color_Code VARCHAR2(4)
Color_Name VARCHAR2(15)
Pack_ID VARCHAR2(1)
Nbr_Of_Packs NUMBER(15)
Qty_Per_Pack NUMBER(15)
Pack_Desc VARCHAR2(35)
Alloc_Comments VARCHAR2(40)
Vendor_Nbr NUMBER(15)
Vendor_Name VARCHAR2(35)
Priority VARCHAR2(15)
Season VARCHAR2(2)
Fabric VARCHAR2(20)
Retail_Price NUMBER(15)
Label_Code NUMBER(15)
Label VARCHAR2(15)
Event_Date DATE
Date_Ordered DATE
Exp_Ship_Date DATE
Auto_Allocation_Job_Nbr NUMBER(15)
Key information for the WorkList table

The previous table indicates the unique and primary key information for the example WorkList table.
Unique and primary keys are set up when you create the table.
Unique keys
The WL_Key column, the WorkList key, must be a unique column, separately indexed from the rest of
the primary key. It is set to Unique.
Primary key
The key columns on the WorkList are dependent on what makes a WorkList record unique for your
business. Each record uniquely identified by the key columns should have a unique value in the
WorkList key field. The columns that make up the primary key for the table cannot be null. In the
example "WorkList table" (on page 116), the following columns make up the primary key.
Column name Position in primary key

Document_Type 1
Document_Nbr 2

Example tables

Dept_Code 3
Class_Code 4
Style_Code 5
All of these columns are not null, as they must be if they are to form part of the primary key.
Mappings for the WorkList table

You set up the mappings for the WorkList table using the Database Setup utility. Be sure to map all
required columns, as well as any optional columns, using Step 9 of the Database Setup utility.
Groups for the WorkList table

The example WorkList table has columns for the following groups, all belonging to the Product
dimension.
 Division
 Department
 Class
 Style
 Color
 Vendor
These groups have two columns set up for them. One column holds the codes used by your transaction
management system, the other holds the descriptions associated with the codes. The descriptions are
for the benefit of the end users; they serve no internal purpose. When you set up your mappings to
groups using Step 5 of the Database Setup utility, you map the code to each group, rather than the
name.
Column name Group

Division_Code Division
Division_Name
Dept_Code Department
Dept_Name
Class_Code Class
Class_Name
Style_Code Style
Style_Name
Color_Code Color
Color_Name
Vendor_Nbr Vendor
Vendor_Name

Example tables
List Source tables for groups

The groups may have a List Source table associated with it. For example, the Class group has a List
Source table called LIST_CLASS set up for it. The table LIST_CLASS is specified as a List Source table
when the table names are entered using the Database Setup utility. When the Class group is created,
LIST_CLASS is specified as the List Source table for that group.
From that table, the column Class_Code is specified as holding the code for the group, and
Class_Name is specified as holding the name. JDA Allocation uses the codes internally, but displays the
associated names whenever the user is shown a list of possible classes.
LIST_CLASS Column name Mapped to

Class_Code Code
Class_Name Name
Example
LIST_CLASS Column name Value Value Value

Class_Code 101 102 103
Class_Name Paper Cards Pens
Additional columns in the WorkList table

The following columns also exist in the example WorkList table. These columns are not used by the
application, but the distributors can use them to help in the decision-making process.
The information for these columns comes from the transaction management system.
WORKLIST Column name Description

Document_Type The type of document from which the merchandise is allocated;
for example, Drop Ship or Close to Post
Document_Nbr The purchase order number or keyrec number, depending on
the document type
Fabric The fabric of the merchandise
Season The season for which the merchandise is appropriate
Priority High, medium, or low priority
Retail_Price Price of the merchandise
Event_Date Date of the event for which the merchandise was ordered
Date_Ordered Date the merchandise was ordered
Exp_Ship_Date Date the vendor is expected to ship the merchandise
Buyer_Comments Comments from the purchase order
Alloc_Comments A column in which the distributor can enter comments
The Alloc_Comments column is used by the distributor to enter comments, so this column has Edit?
set to Yes in the Column Information step in the Database Setup utility. You can type text in this field
in the WorkList, and the text is stored on the database.
Merchandise Shape tables

Merchandise Shape tables can have any name. The example tables are called WLBULK for bulk
merchandise and WLPACK for pack merchandise.

Example tables
Structure of WLBULK
Here is the structure of an example WLBULK Merchandise Shape table for bulk merchandise.
WLBULK Column name Type Null? Keys

WL_Key NUMBER(15) not null 1
Color_Code VARCHAR2(4) not null 2
Size_Code VARCHAR2(4) not null 3
Avail_Qty NUMBER(15) not null
Key information for WLBULK

The table in the previous section indicates the primary key information for the example WLBULK table.
You set up the primary key when you create the table.
Primary key
The following columns make up the primary key. They uniquely identify the merchandise to be
allocated.

WL_Key 1
Color_Code 2
Size_Code 3
Mappings for WLBULK

You set up the mappings for the WLBULK table using the Database Setup utility. The following columns
in WLBULK are mapped to required or optional columns.
Required columns
Column name Mapped to
WL_Key WorkList key
Optional columns
Color_Code Level 1 (Color)
Size_Code Level 2 (Size)
Avail_Qty Available to allocate
The levels are set up using the Database Setup utility.

Example tables
Merchandise type for WLBULK

You set up the merchandise types for each Shape table using the Database Setup utility. Each
merchandise type describes the composition of the merchandise, and specifies the Shape table which
contains the merchandise information.
Name Type Bulk or Pack Shape Table

Type A 10 Bulk WLBULK
Columns: WorkList
 Dept_Code
 Class_Code
 Style_Code
The merchandise with the merchandise type 10 is defined by the Dept_Code, Class_Code, and
Style_Code columns in the WorkList, and has the lower-level information stored in the WLBULK Shape
table.
If the merchandise type separator (set up by Database Setup) is a period, the unique merchandise ID
for a WorkList line with Department 100, Class 150, Style ABCD, and merchandise type 10 would be
100.150.ABCD.
Structure of WLPACK
Here is the structure of an example WLPACK Merchandise Shape table for pack merchandise.
WLPACK Column name Type Null? Keys

Pack_ID VARCHAR2(4) not null 4
Color_Code VARCHAR2(4) not null 2
Size_Code VARCHAR2(4) not null 3
Qty_Per_Pack NUMBER(15) not null
Nbr_Of_Packs NUMBER(15)
Key information for WLPACK

The previous table shows the primary key information for the example WLPACK table. The primary key
is set up when you create the table.
Primary key
The following columns make up the primary key. They uniquely identify the merchandise to be
allocated.

WL_Key 1
Color_Code 2
Size_Code 3
Pack_ID 4

Example tables
Mappings for WLPACK

You set up the mappings for the WLPACK table using the Database Setup utility. The following columns
in WLPACK are mapped to required or optional columns.
Required columns
WL_Key WorkList key
Optional columns
Color_Code Level 1 (Color)
Size_Code Level 2 (Size)
Pack_ID Pack ID
Nbr_Of_Packs Number of packs
Qty_Per_Pack Quantity per pack
The levels are set up using the Database Setup utility.
Merchandise type for WLPACK

You set up the merchandise types for each Shape table using the Database Setup utility. Each
merchandise type describes the composition of the merchandise, and specifies the Shape table which
contains the merchandise information.
Name Type Bulk or Pack Shape Table

Type B 11 Pack WLPACK
Columns: WorkList Columns: Shape Table

Dept_Code Pack_ID
Class_Code
Style_Code
The merchandise with the merchandise type 11 is defined by the Dept_Nbr, Class_Nbr, and Style_Nbr
columns in the WorkList, and the Pack_ID column in the WLPACK Shape table.
If the merchandise type separator (set up by Database Setup) is a period, the unique merchandise IDs
for a WorkList line with Department 100, Class 150, Style ABCD, and two pack IDs, AA1 and AA2, in
the Shape table, with merchandise type 11, would be 100.150.ABCD.AA1 and 100.150.ABCD.AA2.
Detail tables
Detail tables provide additional information about WorkList lines. They may have any name. You can
have as many detail tables as you need. The example tables are BATCH_DETAIL and CLASS_DETAIL.
You set the mappings to the WorkList, using the Database Setup utility.

Example tables
Structure of WORKLIST_DETAIL
Here is the structure of an example WORKLIST_DETAIL detail table. This table provides extra
comments for a single WorkList line. It matches the WorkList key, the unique identifier of each
WorkList line to entries in the detail table.
BATCH_DETAIL Column name Type Null? Keys

Seq_Nbr NUMBER(15) not null 2
Info VARCHAR2(50) not null
Key information for WORKLIST_DETAIL

The table in the previous section shows the primary key information for the example
WORKLIST_DETAIL table. You set up the primary key when you create the table.
Primary key
The following columns make up the primary key.

WL_Key 1
Seq_Nbr 2
All of these columns are not null, as they must be if they are to form part of the primary key. When
the information is displayed, it is sorted according to the primary keys; the sequence number is used
to sort multiple lines of comments for a single WL_Key.
Main key mappings for WORKLIST_DETAIL

At least one column from the primary key of a detail table must be mapped to a WorkList column using
Database Setup. In this case, it is the WL_Key column.
Detail table column Mapped to WorkList table column

WL_Key WL_Key
When the application displays the details for a WorkList line, it checks this table to see if the WL_Key
column in the WorkList table matches any of the entries in the WL_Key column of BATCH_DETAIL. If
so, it displays all records with WL_Key entries that match.
Structure of CLASS_DETAIL
Here is the structure of an example CLASS_DETAIL table. This table provides extra comments for each
Department/Class combination.
CLASS_DETAIL Column name Type Null? Keys

Dept_Code VARCHAR2(4) not null 1
Class_Code VARCHAR2(4) not null 2
Seq_Code NUMBER(15) not null 3
Class_Info VARCHAR2(50) not null

Example tables
Key information for CLASS_DETAIL

The table in the previous section shows the primary key information for the example CLASS_DETAIL
table. You set up the primary key when you create the table.
Primary key
The following columns make up the primary key.

Dept_Code 1
Class_Code 2
Seq_Code 3
All of these columns are not null, as they must be if they are to form part of the primary key. When
the information is displayed, it is sorted according to the primary keys; the sequence number is used
to sort multiple lines of comments for a single Department/Class combination.
Primary key mappings for CLASS_DETAIL

At least one column from the primary key of a detail table must be mapped to a WorkList column. In
this case, both Dept_Nbr and Class_Nbr are mapped. Use the Database Setup utility to set up these
mappings.
Detail table column Mapped to WorkList table column

Dept_Code Dept_Nbr
Class_Code Class_Nbr
When JDA Allocation displays the details for a WorkList line, it checks this table to see if the Dept_Nbr
and Class_Nbr columns in the WorkList table match any of the combinations of Dept_Nbr and
Class_Nbr in CLASS_DETAIL.

Database tuning
Chapter 19. Database tuning

This chapter describes how to improve data collect performance when using the built-in data collect,
DCAQ, or PR.
Your Oracle DBA may wish to turn off Oracle Logging on some objects such as Data Staging tables,
provided the data can be recovered from your host system. This change may improve performance
related to the maintenance of the data in the Staging Area.
Format table indexes

Format tables in JDA Allocation are temporary scratch tables. Performance can be improved by
creating each format table and index using the NOLOGGING option. Customers should save the script
used to create the table and indexes, in case they have to recreate it. Use of the NOLOGGING option
does not alter the fact that these tables must be truncated periodically.
To improve performance of built-in data collects, create an index for all format tables and these
columns: Allocation Number, Location ID, Level 0 (Unique Merchandise ID), Level 1, Level 2, Level 3,
and Level 4.
If your format table does not contain these levels, you do not need to add them. A table containing
only Class can have an index for just allocation number and location ID.
Do not include other levels to these indexes (for example, those above style such as division or dept).
The data collect procedures do not require them and, in fact, any performance gain may be lost.
For example, for a format table that can hold data down to Width (Level 3):
Create Index Sales_Stock_Idx

on Sales_Stock (
Alloc_Nbr,
Location_ID,
UMID,
Color,
Size_Code,
Width)
/
Here is another example pertaining to the plan format table.
Create Index Plan_Format_Idx

on Plan_Format (
Alloc_Nbr,
Location_ID,
Level0,
Level1,
Level2,
Level3)
/
Staging table indexes

To achieve optimal performance for the built-in data collect, create an index on the staging tables.
There is no need to modify the views. Because JDA Allocation adds only one index per table, there is
no confusion (unlike model stock).
The index should contain location ID, followed by the levels above, and including, style, and finally
followed by levels 1 through 5. You do not need to add the columns if you do not have them.

Database tuning
The first example pertains to the lowest level staging table. If you know this table contains unique
data, make the index unique. However, do not make this index your primary key.
These tables are created and maintained by JDA Allocation; however, these indexes are not created
automatically. If these tables are ever regenerated, you must remember to recreate the indexes.
The following example assumes that the data collect rules includes Department, Class, Style, Color,
Size, and Width.
Create Index Stage_Width_Idx

on Stage_Width (
Location_ID
Department,
Class,
Style,
Color,
Size_Code,
Width)
/
This example is for the Class level staging table.
Create Index Stage_Class_Idx

on Stage_Class (
Location_ID
Department,
Class)
/
This example is for the plan staging table. Although JDA Allocation generates this table, it does not
automatically create the index. If this table is ever regenerated, you must remember to recreate the
index.
Create Index Plan_Staging_Idx

on Plan_Staging (
Department,
Class,
Style,
Level1,
Level2,
Level3,
Level4,
Level5,
Time_Code)
/
DCAQ/CAQ index
The DCAQ/CAQ data collects depend on indexing for reading and writing. Create an index for each
level above style (excluding style), followed by unique merchandise (level 0), levels 1 through 5, then
location ID.
Example
Create Unique Index CAQ_Host_Idx

on CAQ_Host (
Department,
Class,
UMID,
Color,
Size_Nbr,
Width,
Location_ID)

Database tuning
WorkList table indexes

JDA Allocation performance when querying the WorkList can be improved by the creation of certain
indexes. Because the WorkList table is a client-generated table, the names of the columns may differ
for each customer. However, it should be intuitive as to what columns are expected.
By creating the following index, Allocation can quickly gather information about Worklist lines for the
current user.
Create Index WorkList_Userstatus_Idx on WorkList (Allocation_User, Alloc_Status_Code)

/
To improve performance during WorkList View creation, add indexes for commonly used columns.
Indexes will enable JDA Allocation to quickly populate the dialog box with possible values. For
example, if PO_NUMBER was frequently used during the creation of views, performance can be
improved by adding a non-unique index for PO_NUMBER on the WorkList.
WorkList indexes are used in the Need Generation wizard when going between the data collect
template page and the data collect rule page. Specifically, JDA Allocation reads the values from the
WorkList when populating the data collect rule.
For example, a data collect rule containing Dept, Class, Style, Color, Size benefits from the following
indexes.
Create Unique Index WorkList_UK on WorkList (WL_Key)

/
Create Index WorkList_Class_Idx on WorkList (Class)
/
Create Index WorkList_Dept_Idx on WorkList (Dept)
/
Create Index WorkList_Style_Idx on WorkList (Style_Nbr)
/
Create Index WorkList_Color_Idx on WorkList (Color)
/
Create Index WorkList_Aln_Idx on WorkList (Alloc_Nbr)
/
WorkList indexes can affect the performance of the Status and Report tile on the Administrator and
User dashboards. Indexes on columns used in WorkList views for the status and reporting feature, as
well as an index by status code can improve the performance of this dashboard tile.
Locations table indexes

Due to how JDA Allocation queries the Locations table, performance can be improved by the creation of
certain keys/indexes. Because the Locations table is a client generated table, the names of the
columns may differ for each customer. However, it should be intuitive as to what columns are
expected.
Example
Alter Table Locations Add Constraint Locations_PK Primary Key (Location_ID)

/
Create Unique Index Locations_UK1 on Locations (Locations_ID, Location_Name)
/
Create Unique Index Locations_UK2 on Locations (Warehouse_Flag, Avail_For_Alloc_Flag,
Location_ID, Location_Name)
/

Database tuning
To improve performance during Store View creation, add indexes for commonly used columns. Indexes
will enable JDA Allocation to quickly populate the dialog box with possible values. For example, if
DISTRICT_MGR is frequently used during the creation of views, performance can be improved by
adding a non-unique index for DISTRICT_MGR on the Locations table.
Grading indexes
Due to the statements generated for grading, you benefit from indexes based on the following
examples.
Create Index Grade_Dept_Idx on Grade

(Location_ID, Dept_Nbr)
/
Create Index Grade_SubDept_Idx on Grade
(Location_ID, Dept_Nbr, Sub_Dept_Nbr)
/
Create Index Grade_Class_Idx on Grade
(Location_ID, Dept_Nbr, Sub_Dept_Nbr, Class_Nbr)
/
Create Index Grade_Period_Idx on Grade
(Location_ID, Dept_Nbr, Sub_Dept_Nbr, Class_Nbr, Period)
/
Create UNIQUE Index Grade_Grade_UK on Grade
(Location_ID, Dept_Nbr, Sub_Dept_Nbr, Class_Nbr, Period, Grade)
/

Database maintenance
Chapter 20. Database maintenance

It is good practice to perform semi-regular (monthly) rebuilds of all JDA Allocation system object
indexes. It is your responsibility to configure and execute a data maintenance and clean up process.
You and your Database Administrator are responsible for all client object indexes, even if these are
part of a Host interface.
Your Database Administrator should be monitoring indexes and rebuilding them as necessary.
Rebuilding must be done to maintain optimal database performance.
Below is a list of some system tables you may want to periodically review.
AA$BATCH_HEADER and AA$BATCH_DETAIL: These two system tables constitute a report of the
Auto-Allocation jobs, which is available for analysis on the Administrator Dashboard. Data should be
cleared regularly after it has been reviewed.
ALLOCHOST$DCLOG, ALLOCHOST$DCRULES, and ALLOCHOST$ERRORS: These three system

tables hold information about current or failed built-in data collect processes. After the data collects
are successfully completed, any related records are removed from the two tables. (Information about
unsuccessful data collects will remain until it is manually removed.)
QUEUE_IN and QUEUE_OUT: You should not have to maintain these tables, but a periodic review
should find only a handful of records at any given time. Contact JDA Support Services if you find an
abnormal amount of records.
RESULTS_ANALYSIS, RESULTS_STATISTICS, and NEED_DETAIL: These tables hold additional

information about completed allocations for post-allocation analysis. Due to the potential volume of
data held in RESULTS_ANALYSIS and NEED_DETAIL, an administrator can control whether the
information is written to these tables via the Enable Results Analysis Capture and Enable Saving
and Loading of Need Values with Results options in Allocation Database Setup step 11. The
records are all linked to the RESULTS_HEADER table via foreign key constraints, so the data in these
tables will be purged as results are deleted from the system, and no additional maintenance is
necessary.
PLAN_STAGING and your actual (Host) format tables require regular maintenance. See "Maintenance
of data in the plan staging area" and "Clean up format tables" (on page 53).
Your list source tables, WorkList and Shape tables, Detail tables, and any other miscellaneous tables all
need maintenance as determined by your interface to JDA Allocation.

Allocation system administration
Chapter 21. Allocation system administration

To start Allocation Administration, double-click the Allocation Administration icon or choose Allocation
Administration from the Start menu.
When the Allocation System Login dialog box is displayed, type the system administrator user ID and
password, configure or select the connection file (for more information, see "Configure the database
connection criteria" (on page 87)), and click OK. When the application is installed, the user ID is AAM,
with password AAM.
Note: Change this password or delete this user as soon as possible. It is provided only for the purpose
of initially setting up other users. See "Manage the User List" (on page 132) below for details.
The Administration screen is displayed.
Lock users out of the database

Before making changes to the Allocation database, you must lock the users out of the database.
Choose Action > Disable User Logins, and confirm the action. No users are able to log in to the
database. Users who are currently logged in are allowed to continue working until they log out.
You can tell which users are working on the database from the User Active? flag on the User List.
Allow users to log in to the database

Choose Action > Enable User Logins and confirm the action. Users can log in to the database again.
You can execute these actions from a command line, which enables them to be called from a batch
process to run on an administrator's Windows machine where Allocation Administration is installed. The
options are %DISABLE_LOGINS and %ENABLE_LOGINS.

%DISABLE_LOGINS
In addition, this command can be executed via PL/SQL stored procedures in the AllocHost package:
AllocHost.Enable_Logins and AllocHost.Disable_Logins.
Note: Command line options do not support Active Directory users.
Maintenance tile on Administrator Dashboard

The Maintenance tile on the Administrator Dashboard allows you to monitor usage statistics for JDA
Allocation objects, such as views, variables, like store rules, methods, product location restrictions, and
users. This tile includes functionality such as object maintenance and deletion.
For more information, see the Online Expert (OLE) by selecting Help from Allocation Administration.
Status & Report tile on Administrator Dashboard

The Status & Report tile allows you to monitor the status of rows in WorkList views as well as analyze
results from any allocations in the view. If some of the standard tiles are closed to make room
available on the dashboard, multiple WorkList views can be monitored concurrently.
The Status & Report tile uses a mapped Available Quantity column on the WorkList in order to display
number of units by status code. This column can be configured in Allocation Database Setup, step 9.

Allocation system administration

Maintain users
Chapter 22. Maintain users

Each distributor must have an JDA Allocation user set up for logging in to the application. It is not
necessary to create individual database users, for example, Oracle users, for each JDA Allocation user.
You must set up users and grant them the appropriate privileges to allocate, approve, and release
merchandise. You also can specify products on which each user can work, and locations to which each
user can send merchandise. In this way, you can divide the workload among the distributors.
You can manage from:
 Users tile on the Administrator Dashboard
 User List
 User Location Restrictions
 User Product Restrictions
Users tile on the Administrator Dashboard

The Users tile allows the administrator to monitor and maintain the users of the system.
Manage the User List

The User List allows you to create users, delete users, grant and revoke privileges, and check whether
users are working on the database.
Open the User List

Choose Maintain > User List. The User List is displayed.
You can change the entries in the cells by clicking them, typing a new value, and pressing Enter.
Add a user
1. Do one of the following:
 Select Edit > Add.
 Right-click and select Add from the shortcut menu.
 Select Maintain > Add Directory Service Users… to open the Add Directory Service Users
dialog box. See the Allocation Online Expert Help for more information.
A new row is added to the list.
Note: If you added Directory Service Users, the User ID, First Name, Last Name, and
Password should not be entered for the user.
2. Enter a user ID for the user. The user ID must be unique. The user ID can be up to 30 characters.
Even though most fields in JDA Allocation do not support spaces, the User ID field does.
3. Enter the first and last name for the user. These can be up to 50 characters.
4. Enter a password for the user to enter to log in to the database. It can be up to 50 characters.

Maintain users
Note: Directory Service user passwords are maintained outside of Allocation and cannot be altered
from within Allocation. The Directory Service user column indicates whether the user is a directory
service user. This column cannot be directly edited.
5. To allow a user to access the Administration program, select the check box in the Administrator?
column.
6. To allow a user to create global methods, views, and results that can be accessed by everyone,
select the check box in the Create Global? column.
7. To allow a user to allocate and approve merchandise, select the check box in the Allocate?
column.
8. To allow a user to release allocated merchandise, select the check box in the Release? column.
9. To allow a user to override the location restrictions placed on merchandise, select the check box in
the Location Restrictions? column.
Note: The user can choose to override all location restrictions: User Location Restrictions, Product
Location Restrictions, and reserve warehouse restrictions as specified on the WorkList. For the
above options, clear the check box to revoke the privilege.
10. Select a default view in the Default WorkList View column. For example, Default~AAM, where
Default is the name of the WorkList view and AAM is the owner. It is not necessary to specify an
owner for global views.
11. Select a default WorkSheet view in the Default WorkSheet View column. For example,
DefaultWorkSheet~AAM, where DefaultWorkSheet is the name of the WorkSheet view and AAM is
the owner. It is not necessary to specify an owner for global views.
Notes:
 The Current OS User column is for JDA Allocation internal use only. It displays the Windows
user and machine where the user logged in.
 The Application Name displays the short name (CLIENT, ADMIN, AUTO, or SETUP) of the
application component where the user was last logged in.
 The User In WS Count and Last WorkSheet Access Date contain statistics about the user’s
WorkSheet access.
 The Application Login Count and Last Application Access Date contain statistics about the
user’s application access.
12. Press Enter. The user is created.
Delete a user
1. Select the row by clicking the tile at the left of the row. The row is highlighted.
 Choose Edit > Delete, and confirm the action.
 Right-click and select Delete from the shortcut menu.
The user is deleted from the User List. All WorkList views, methods, variables, results, and store
selections created by the user are deleted at the same time.

Maintain users
Unlock a single user

If a user has a communications failure while logged in, it is possible that the user is locked out of the
database.
Clear the check box in the User Active? column. The user can log in again.
Note: Editing the User Active? column does not log off a user. Modifying the value in this column
should be done only if a communications failure occurs.
Change privileges for a user

1. To revoke the privileges set up when the user was created, clear the check box in the following
columns:
 System Admin?
Access the Administration program.
 Create Global?
Create views, methods, and results that can be used by everyone.
 Allocate?
Allocate and approve merchandise.
 Release?
Release allocated merchandise.
 Location Restrictions?
Override location restrictions.
2. Press Enter.
Log users out of the system

Users can be logged out of the system using Allocation Administration. The Logout Active Users…
command not only disables user logins, it also displays a dialog box where the grace period and
warning message can be defined. This option logs off all users (including those running Allocation
Administration) except the one executing the command. If the Include Auto-Allocation Users option
is selected, the Auto-Allocation clients exit after completing their current job.
The Grace Period option allows the administrator to specify the amount of time the end users are
given before the logoff function executes. During that time, the warning message displays on the
operator's status bar.
This process can be configured and executed using Allocation Administration. Select Action > Logout
Active Users… from the menu. It can also be controlled via the command line, which enables it to be
called from a batch process to run on an administrator's Windows machine where Allocation
Administration is installed. The options are %DISABLE_AND_LOGOFF <Grace Period (in min)>
<Warning Message> [INCLUDE_AUTO].
The warning message must be 100 characters or less.
The valid values for the grace period are 0 (immediate), 1, 5, 10, or 15 minutes.

%DISABLE_AND_LOGOFF 1 "You are being logged off the system" INCLUDE_AUTO
Note: Command line options do not support Active Directory users.

Maintain users
In addition, it can be executed via a PL/SQL stored procedure in the AllocHost package. This procedure
takes three parameters as follows: Disable_And_Logoff(GracePeriod, WarningMessage, IncludeAuto).
The GracePeriod is in number of minutes (see valid values above). The WarningMessage is a text string
that will be displayed followed by a countdown time in minutes. The IncludeAuto is an optional
parameter that defaults to FALSE. Any errors encountered will be logged in the AllocHost$Errors table.
Example: PL/SQL procedure execution
SQL> exec AllocHost.Disable_And_Logoff(5, 'You are being logged out of the system.',
TRUE)
Notes:
 Once user this command has been executed, user logins must be enabled. See "Allow users to log
in to the database" (on page 130) for more information.
 This feature requires the use of Oracle 11g.
Select the locations for a user

You can specify locations (warehouses and stores) to which each user can allocate merchandise, using
user location restrictions.
User location restrictions let you filter the location list based on the attributes of the locations. Each
attribute of a location is a column in the Locations table.
Set a location restriction for a user

1. Choose Maintain > User Location Restrictions. The User Location Restrictions dialog box is
displayed.
2. Select the user for whom you want to create a restriction from the list.
3. Enter the filter for the user.
4. Click Save.
5. Click Close to finish, or select another user from the list.
Create a filter
1. Select the attribute onto which you want to put a constraint from the list of attributes. The list of
possible values for that attribute is displayed in the Members list.
2. Double-click the attribute, and the attribute name is displayed in the filter.
3. Click an operator in the operator toolbar, or double-click one of the operators in the Operator list.
The operator is displayed in the filter.
4. Double-click one of the values for the column. The value is displayed in the filter.
Check the validity of a filter

1. Click Validate.
2. Click Save. The application checks the validity of the filter.
See "Valid filters" (on page 143).

Maintain users
Change the columns a user can view in the WorkSheet

1. Click Columns. The Columns dialog box is displayed. This dialog box shows the available columns
on the left, and the columns currently displayed on the right.
2. To allow the user to view all columns, click Add All.
3. To prevent the user from seeing any of the columns, click Remove All.
4. To add columns, select them from the list on the left, and click Add.
5. To remove columns, select them from the list on the right, and click Remove.
6. To change the order of columns displayed, select one or more columns from the list on the right,
and drag them to the desired location.
7. Click OK.
Tip: You can select more than one column by pressing Shift+click to select a range of columns, or
Ctrl+click to select several columns.
Select the products for a user

User product restrictions let you select the products each user can allocate. You can specify a filter that
changes the user's default view of the WorkList.
Set a product restriction for a user

1. Choose Maintain > User Product Restrictions. The User Product Restrictions dialog box is
displayed.
2. Select the user for whom you want to create a restriction from the list.
3. Enter the filter for the user.
4. Click Save.
5. Click Close to finish, or select another user from the list.
Create a filter
1. Select the attribute that you want to put a constraint onto from the list of attributes. The list of
possible values for that attribute is displayed in the Members list.
2. Double-click the attribute, and the column name is displayed in the filter.
3. Click an operator in the operator toolbar, or double-click one of the operators in the Operator list.
The operator is displayed in the filter.
4. Double-click one of the values for the attribute. The value is displayed in the filter.
Example: If you want the user to see only those WorkList lines that relate to Vendor number 110, you
would enter a filter such as:
Vendor_Nbr = '110'

1. Click Validate.
2. Click OK. The application checks the validity of the filter.
See "Valid filters" (on page 143).

Maintain users
Change the columns a user can view in the WorkList

1. Click Columns. The Columns dialog box is displayed. This dialog box shows the available columns
on the left, and the columns currently displayed on the right.
2. To allow the user to view all columns, click Add All.
3. To prevent the user from seeing any of the columns, click Remove All.
5. To remove columns, select them from the list on the right, and click Remove.
6. To change the order of columns displayed, select one or more columns from the list on the right,
and drag them to the desired location.
7. Click OK.
Tip: You can select more than one column by pressing Shift+click to select a range of columns, or
Ctrl+click to select several columns.
Sort the WorkList data

1. Click Sort. The Sort dialog box is displayed.
This dialog box shows the available columns on the left, and the columns on which the data is
sorted on the right.
3. For each column in the list on the right, click Ascending or Descending to choose whether the
application sorts that column in ascending or descending order.
4. Click OK. The application sorts the rows based on the contents of the sort columns.

Maintain locations
Chapter 23. Maintain locations

The LOCATIONS table on the Allocation database holds all information about the stores and warehouse
locations to which the distributors can send merchandise.
Your database administrator will set up this table to contain the information the allocators need to
carry out their work. See "Set up locations" (on page 28) for details on creating this table.
You must create entries for all locations to which you want to send merchandise. You can also specify
the products that can be sent to each location.
You manage locations in three ways.
 Locations tile on the Administrator Dashboard
 Location List
 Product location restrictions
 Store selections
Locations tile on the Administrator Dashboard

The Locations tile on the Administrator Dashboard allows the administrator to review location status,
maintain store selections, view store selections on a map and by store attribute, and access other
locations administration functionality.
Manage the Location List

The Location List lets you set up the stores and warehouses to which merchandise can be sent.
Your database administrator will create display names for the columns in the Location List. Ask your
database administrator what the display names are for each column.
Three types of columns are in the Location List.
 Required
 Optional
 Additional
The application needs all required columns for its own purposes. The required columns are Location
ID, Location Name, Warehouse Flag, and Available for Allocation Flag.
Optional columns change the way the application works. The optional columns are Display in
WorkSheet and Global Coordinates.
Additional columns are used to provide additional information about the locations that can be used to
create restrictions and views.
Caution: Make sure that your database administrator has set up the appropriate columns in the
Location List so that they can be edited; otherwise, you will not be able to edit any of the location
details or add new locations.
See "Use the Database Setup utility" (on page 87) for details.

Maintain locations
Open the Location List

Choose Maintain > Location List. The Location List is displayed.
You can change the entries in the cells by clicking them, typing a new value, and pressing Enter. If
you cannot edit a cell by clicking it, it has been set up to be read-only in the database.
Add a location
Note: Adding locations is normally performed in a host system and applied to JDA Allocation through a
batch update process. However, locations are sometimes added directly by JDA Allocation for
demonstration or training environments.
 Choose Edit > Add.
 Right-click a row tile and select Add.

A new row is added to the list.
2. Enter a Location ID for the location. This ID must be unique.
3. Select the Available for Allocation Flag column; check it to allow merchandise to be allocated to
this location. Uncheck it to prevent merchandise from being allocated to this location.
4. In the Warehouse Flag or Location Name column, enter values for those columns.
5. Enter values for any of the other columns that have been set up in the Location List.
6. Press Enter.
Delete a location
Note: Removing locations is normally performed in a host system and applied to JDA Allocation
through a batch update process. However, locations are sometimes removed directly from JDA
Allocation for demonstration or training purposes.
1. Select the row by clicking the tile at the left of the row. The row is highlighted.
 Choose Edit > Delete.
 Right-click and select Delete from the shortcut menu.
There is no confirmation; the location is deleted immediately.
Make a location temporarily unavailable for allocation

Uncheck the Available for Allocation Flag column to prevent merchandise from being allocated to
this location. Check the Available for Allocation Flag to allow merchandise to be allocated to this
location.
Determine whether a location has pending allocations

This information about a location can be obtained by calling a PL/SQL stored procedure that exists in
the JDA Allocation database. The AllocLib package contains a procedure that can be used to determine
if a location is included in any pending (in Approved, Unapproved, or Discrepancy status) allocations.
AllocLib.CheckApproveFlagForLocation (LOCATIONID (in) VARCHAR2,

BSTOREPARTOFAPPROVEDALLOC (in out) NUMBER)

Maintain locations
For example, to see if location 120 is part of any pending allocations, run the following commands
from SQL*Plus:
var bAllocPending NUMBER

execute alloclib.checkapproveflagforlocation ('120', : bAllocPending)
print bAllocPending
The value of bAllocPending will be set to 1 (TRUE) if the location is currently used in any pending
allocations. Otherwise, it will be 0 (FALSE).
Select the locations for a product

You can specify locations to which certain types of product can be sent, using the product location
restrictions.
Each product location restriction is comprised of two parts.
 A condition rule
For example, Department = 100, Class = 105
 A global store selection

For example, Warm Stores
You can make the store selection exclusive or inclusive. When the conditions for the merchandise are
met, you can either send the merchandise to all locations except those in the store selection
(exclusive) or send the merchandise only to those locations in the store selection (inclusive).
Product location restrictions can be applied only at or above the WorkList level. For example, if your
WorkList level is style/color, the lowest level for restrictions is color.
Product location restriction hierarchy ranges

Before you create a product location restriction using Allocation Administration, you must ensure that
you set up a hierarchy range. You can set up hierarchy ranges and their associated groups using
Allocation Database Setup, Step 8. See "Step 8: Set up hierarchy ranges and associations" (on page
97) for details.
Hierarchy ranges describe the portions of the hierarchy you can use to create product location
restriction conditions; for example, in a Division, Dept, Class, Style, Color, Size, Width hierarchy, you
may be allowed to create conditions from the Dept, Class, Style range.
In each condition, you must start at the top of the range, and work down through the levels. For
example, with a Dept, Class, Style range, you could create the following three conditions:
Dept = value
Dept = value;Class = value
Dept = value;Class = value;Style = value
If you have associations with your hierarchy range, you can add nonhierarchical groups to your
condition. For example, you could have Source Warehouse and Price Point associated with the Style
group. You could choose to add Source Warehouse or Price Point to your condition when you add Style.
If you associate all nonhierarchical groups with the top-level member of the hierarchy range, you can
exercise maximum flexibility with the conditions. You can use some or all associated groups, with or
without any of the hierarchical groups. For more information, see the online help (ALCHEMY.CHM).

Maintain locations
Product location restrictions and default warehouses

You can set product location restrictions that are based on the warehouse where the merchandise was
received. This warehouse is referred to as the source warehouse. If the source warehouse is undefined
by the Host system, you can specify a source warehouse (Distribution Center) on Step 11 of Allocation
Database Setup, which is used as the default.
Merchandise from different source warehouses

You can have the same style of merchandise from different warehouses. For example, you can set up a
product location restriction stating that the merchandise from the East Coast warehouse goes to
locations in the East, and merchandise from the West Coast warehouse goes to locations in the West.
This setup requires the Source Warehouse column in the WorkList; this column is used to differentiate
between two pieces of merchandise of the same style that have different product location restrictions.
This column must be made into a group, and used as an associated group at the top level of the
product location restrictions hierarchy range during Allocation Database Setup. See "Use the Database
Setup utility" (on page 87) for details.
When allocating merchandise from multiple warehouses, you see an extra dimension in the
WorkSheet. This dimension is Distribution, and contains the source warehouses in the allocation.
Caution: The only time merchandise with the same style can have different product location
restrictions is when the merchandise comes from different source warehouses.
Swing stores
You can allocate merchandise to particular stores from more than one distribution center. Sometimes
known as swing or flip stores, this method allows you to give out the maximum number of goods from
all distribution centers.
JDA Allocation first tries to get goods from only one distribution center for one swing store. However, a
swing store may have goods allocated from two different distribution centers, if this behavior is
required to hit the available curve and maximize Need.
You can establish swing stores through Allocation Administration by creating multiple product location
restrictions for certain locations, with different distribution centers in each restriction.
Maintain product location restrictions

Product Location Restrictions are created, edited, and deleted from the Product Location Restrictions
Manager, available in Allocation Administration. For more information, see the online help
(ALCHEMY.CHM).
Select a list of locations

By default, the application distributes merchandise to all locations that are available for allocation. You
can specify a subset of these locations to send merchandise to, using store selections.
Store selections let you filter the location list based on the attributes of the locations. Each attribute of
a location is a column in the Location list. You can save selections for later use.
If you have the required privileges, you can save store selections as global selections that can be used
by everyone.
Create a new selection

Choose Maintain > Store Selections > New. The Store Selection dialog box is displayed.

Maintain locations
This dialog box lets you sort the data, apply a filter to the list of locations, and check the validity of the
filter. You use a filter for allocating to select locations.
Sort the locations

1. Click Sort. The Sort dialog box is displayed.
This dialog box shows the available columns on the left, and the columns on which the data is
sorted on the right.
3. For each column in the list on the right, click Ascending or Descending to choose whether the
application sorts that column in ascending or descending order.
4. Click OK.
JDA Allocation sorts the locations based on the contents of the sort column. Allocation uses
alphanumeric sorting. For example, a Descending sort by Grade would list D-A. If you sort on the
square foot value of the location in descending order, the largest locations are displayed first. You can
sort on any store attributes in the location list.
By default, if you have not specified a sort order, the application sorts the locations by order of Need,
after the allocation has been carried out.
Create a filter
1. Select the attribute onto which you want to put a constraint from the list of attributes. The list of
possible members of that attribute is displayed in the Members list.
2. Double-click an attribute, and the attribute name is displayed in the filter.
3. Click an operator in the operator toolbar, or double-click an operator in the Operator list. The
operator is displayed in the filter.
4. Double-click an attribute value from the Members list. The value is displayed in the filter.

1. Click Validate.
2. Click Save or OK. The application checks the validity of the filter.
Save a store selection

Click Save.
 If you have previously saved the selection, it is saved under the same name as before.
 If you have not saved the selection, the Save As dialog box is displayed.
Save a store selection with a new name

1. Click Save As.
2. To save the selection as a global selection that can be used by other users, click Global.
3. Type the name for the selection and click OK. The Description dialog box is displayed. Selection
names can be up to 50 characters, and can contain numbers, letters, and spaces.
4. Type a description for the selection, and click OK.

Maintain locations
Edit a store selection

1. Choose Maintain > Store Selection > Edit. The Edit Selection dialog box is displayed. This dialog
box lists all store selections you can edit. Global selections are marked with a small globe.
2. Click the store selection you want to edit.
3. Click OK. The Store Selection dialog box is displayed. This dialog box lets you change the selection
you are editing and save it, or save it under another name.
4. Click OK.
Delete a store selection

1. Choose Maintain > Store Selections > Delete. The Delete Store Selections dialog box is
displayed.
2. Select the store selection you want to delete, and click Delete.
3. Click Close.
Tip: Press Ctrl+click to delete more than one store selection.
Filters for store selections

The filter is the most important part of the store selection. It lets you select exactly which locations are
to be used.
The filter is applied every time the store selection is used. If you have a store selection that has a filter
set for locations in a warm climate, the application checks the climate of every store when the
selection is applied. If you reclassify a location, or a store was added or removed, the filter is applied
to the relevant locations.
Valid filters
A valid filter phrase has the form:
attribute operator value
 attribute must be one of the columns in the Locations table.
 operator must be one of the following:
= equal to
<> not equal to
> greater than
>= greater than or equal to
< less than
<= less than or equal to
 value can be any value the column may contain.
Example: If you want to send merchandise only to those locations that are in a warm climate, you
might enter:
Climate = 'Warm'

Maintain locations
Complex filters
You can create complex filters using AND, OR, and NOT to combine phrases. Use the left and right
parentheses to provide clarity.
You can use +, -, *, and / for addition, subtraction, multiplication, and division.
You can test whether a column is equal to one of a list of values using:
column IN (value1, value2, value3, ...)

Example
STORE_ID IN ('110', '120')

is equivalent to:
STORE_ID = '110' OR STORE_ID = '120'

Example
You could enter a complex filter such as:
(Climate IN ('Warm','Hot') AND State code <> 'CA') OR (Square feet >= '25000' AND
Building type = 'Mall')
This filter means "Send merchandise to all locations that have a warm or hot climate that are not in
California, or to all Mall locations with square footage greater than or equal to 25000".
NULL values in filters

You can test for a column being null (that is, empty) using:
 IS NULL: true if the column is null
 IS NOT NULL: true if the column is not null
Dates and times in filters

Use the following syntax for date and time stamps in filters.
{d 'yyyy-mm-dd'}
{ts 'yyyy-mm-dd hh:mm:ss'}
Example
{d '1999-06-25'}
{ts '1999-06-25 17:30:00'}
SQL statements
Depending on your database, you may be able to enter more complex SQL statements for the filter,
using functions that are available on your database.
For example, to compare any date to the current Oracle system date (that is, today), you can use the
Oracle to_date and sysdate functions. To compare the STATUS_TIMESTAMP column to today's
date, use:
(to_date(STATUS_TIMESTAMP,'DD-MM-YYYY')) = (to_date(sysdate, 'DD-MM-YYYY'))

which is true if STATUS_TIMESTAMP is equal to today's date.
See the Oracle documentation for more information on what functions Oracle provides.

Maintain variables
Chapter 24. Maintain variables

Variables are used to determine the Need for each location. Need is how much merchandise the
location should get. The information is derived from information in two places.
 Your transaction management system (known as the host system)
 Your JDA planning system
Your database administrator must set up procedures to collect data from your transaction
management system, your JDA planning system, or both.
Each piece of information from your host system or JDA planning system is a base variable. Base
variables from your planning system and host system can be combined to create derived variables.
Derived variables can be of two types.
 Relative
 Absolute
Relative variables are used to determine the ratio of merchandise to be sent to each location. Absolute
variables are used to determine the number of units to be sent to each location.
Base variables
Base variables are stored in columns on the Allocation database. For variables that follow a sequence
of time periods, each variable and time period combination corresponds to a column. This allows Need
calculations to be built that are relative to the current time. For example, a calculation that determines
the average of the last four weeks of sales data can be based on sales_01ago, sales_02ago,
sales_03ago, and sales_04ago. A calculation that depends on the planned sales for the next two weeks
could reference sales_01out and sales_02out.
The columns that can be used as base variables are:
 The variable columns in the Plan format table
 The variable columns in any of the Host format tables
The variable columns in the Plan format table can be used to create a Need based on planned data.
The variable columns in the Host format tables contain variables from your transaction management
system. These variables can be used to create a Need based on performance data.
Maintain the base variable list for plan data

The application provides the ability to collect plan data. If not using the built-in EKB integration for EP
data, the administrator creates and maintains the base variable list for plan data in Allocation
Administration.
Add a variable to the base variable list

1. Choose Maintain > Base Variable List. The Maintain Base Variable List dialog box is displayed.
2. Click New.
3. Enter a Variable name and Number of Time Periods. Variable names do not support spaces.
4. Click Set.
5. After all changes are made to the base variable list, click OK to update the database.

Maintain variables
Change a variable in the base variable list

1. Choose Maintain > Base Variable List.
2. Select the variable from the list.
3. Make the desired changes.
4. Click Set.
Remove a variable from the base variable list

1. Choose Maintain > Base Variable List.
2. Select the variable from the list.
3. Click Remove.
4. Click Yes to confirm the delete. The variable is removed from the list.
Tip: Be careful when deleting base variables because they may be used by Need calculations.
Create, edit, and delete derived variables

You can create and edit derived variables using the Variable Manager. The Variable Manager is
available in Allocation Administration, the WorkList, and the WorkSheet. Derived variables can be
created using base variables and other derived variables.
To create or edit variables during the Need selection process, the Variable Manager is invoked from the
Need Selection Wizard in the WorkSheet.
Only derived variables can be used for Need generation.
Information on how to use the Variable Manager is located in the Online Expert (OLE) by selecting
Help from within Allocation or Allocation Administration.
Map an On Hand variable

1. Choose Maintain > Variables > On Hand. The On Hand Default Variable Selection dialog box is
displayed.
2. Select the format table you want to use. Eligible On Hand variables for that format table are
displayed.
3. Select the On Hand variable you want to map to this format table.
4. Click Map. Only one On Hand variable can be mapped to a format table at a time. Click Un-Map or
Re-Map to change your selection.
5. Click OK.
If no eligible variables are displayed, you can create them. On Hand variables can be only Global, and
only a user with administrator privileges can create them. Close this dialog box and choose Maintain
> Variable Manager. Create a variable to calculate the On Hand value. All On Hand variable names
must begin with the tilde character (~).

Maintain variables
On Hand variables must be defined in a format table; if not, the application cannot complete a
calculation using the On Hand variables. If you use a plan variable from a plan format table, there is
no On Hand information. To access On Hand information for plan data, you may want to create
variables as performance variables that refer to plan data.
JDA Allocation calculates On Hand variables during Need generation, regardless of whether you
selected the Consider On Hand At or Above the Need Level option. As a result of calculating an On
Hand variable, it is displayed with the other variables in the WorkSheet.
To ensure that Model data, Target and Threshold are collected, add the following statement to your
Mapped OnHand variable: "NOP(Target) + NOP(Threshold)". This allows for the application of model
based minimums for any Need Calculation.
Map a Priority Order variable

You can select an Administration priority order default variable by mapping an existing global variable
for each format table using the Priority Order Default Variable dialog. A single priority order default
variable can be mapped per format table.
1. Choose Maintain > Variables > Priority Order. The Priority Order Default Variable Selection
dialog box is displayed.
2. Select the format table you want to use. Eligible priority order variables for that format table are
displayed.
3. Select the priority order variable you want to map to this format table.
4. Click Map. Only one priority order variable can be mapped to a format table at a time. Click Un-
Map or Re-Map to change your selection.
5. Click OK.
Revalidate a variable
You can select this option to automatically check and validate your variables' formulas, display names,
or derived variable descriptions. As JDA Allocation is validating, it may also modify the way some
variables were previously stored in order to tolerate base variable display and derived variable
description changes. This may also include some location table column display names used in Need
calculations. This option does not change formulas or display names that are viewed by you and the
distributors. If you open a previously saved variable, JDA Allocation always displays the display name
(if valid) instead of the column name.
If a display name is not found, JDA Allocation will simply validate the variable. If a variable is found to
be invalid, the variable is logged as invalid in the AAMDebug.log. The log file is maintained for
support purposes. For help diagnosing an error in a variable, contact JDA Services. Note: This variable
is not updated in the database and must be corrected by you before it can be used.
1. Choose Maintain > Variables > Revalidate. An Updating Variables wait panel is displayed.
The wait panel contains a progress bar. When the validation is complete, an informational message
is displayed that describes how many variables were present, updated (does not include derived
descriptions that matched names), and invalid.
2. Further details can be found in the AAMDebug.log.
Absolute and relative variables

There are two types of variables you can create, relative and absolute.

Maintain variables
Relative variables
Relative variables are used to determine the ratio of merchandise to be sent to each location. For
example, you could create a relative variable SalesLastWeek with the formula:
sales1ago
If Need is calculated at location level, this formula might produce a relative Need for locations A, B,
and C of 250:300:150, which is a ratio of 5:6:3. For every five units sent to location A, six should be
sent to location B, and three to location C. This ratio ensures that locations with the higher Need get
sent more merchandise.
Absolute variables
Absolute variables are used to determine the number of units to be sent to each location. For example,
you could create an absolute variable Sales4Weeks with the formula:
sales1ago + sales2ago + sales3ago + sales4ago

This formula might produce an absolute Need for locations A, B, and C of 400, 500, and 200. Location
A needs 400 units, location B 500, and location C 200. It ensures that the locations that need the most
get the most merchandise. In this case, the locations receive exactly what they have sold over the
past four weeks, assuming the merchandise is available.
Example
The following variable would provide an eight Weeks of Supply calculation; enough merchandise to last
the location eight weeks, based on the last four weeks' sales, subtracting the merchandise still on
hand.
Average Weeks of Supply for 8 weeks:
(((Sales1Ago + Sales2Ago + Sales3Ago + Sales4Ago) / 4) * 8) - On_Hand)

This formula would be an absolute variable, because you want to send enough merchandise to last
eight weeks to the location, not proportion the available merchandise to the locations based on their
past sales.
Variable operators and functions

Derived variables comprise one or more base or derived variables, combined with operators and
functions. All formulas must evaluate to a number. Each part of a variable formula that can evaluate to
a number is called an expression.
The simplest variable comprises a single base variable. For example:
sales1ago
from the host table might produce a value for actual sales one week ago. If you wanted to base the
Need for each location on the sales, but wanted to send more merchandise, you could modify the
variable as follows:
sales1ago * 2
This formula would produce a Need for each location of twice the sales one week ago.
You can include several variables in a formula. For example, if you want to add the sales for the last
three weeks together, you might use:
sales1ago + sales2ago + sales3ago

You can mix variables from different sources; for example, you could use a Planning variable to modify
performance data from the host system.

Maintain variables
Syntax conventions
 Words in UPPER CASE are words the application recognizes; these words are usually functions or
arithmetic operators. For example, ROUND is a function.
 Words in italics are generic terms. You must replace the word with the appropriate information. For
example, ROUND(expression) indicates that you should replace the word expression with a valid
expression.
 Square brackets [ ] indicate optional items. You can include one of the items or none of them. For
example, AVERAGE(expression [, expression, ...]) means that you must include at least one
expression, and may optionally include more.
 Parentheses ( ) are used to enclose parts of an expression. The items within parentheses are
calculated before items outside them. For example, B / (C - D) means that B is divided by the
result of C - D.
Simple arithmetic operators

You can use these operators in the formula of a variable.
+ INC
- MOD
/ VAR
* ZDIV
@ ZEXC
% ZMOD
EXC ZPCT
See the "Arithmetic Operators" topic in the online help (ALCHEMY.CHM) for details.
Conditional statements
You can use the following functions to make the result of a variable dependent on some condition.
IF ELSE
IF THEN ELSE
WHENTEST
WHENTESTs with Levels and Product Mappings
See the online help (ALCHEMY.CHM) for details and examples of conditional statements.
Logical operators
You can use these operators in the formula of a variable.
& AND
OR NOT
TRUE FALSE
See the "Logical Operators" topic in the online help (ALCHEMY.CHM) for details.
Comparisons
You can use the following comparisons in the formula of a variable.
> or GT Greater than
>= or GE Greater than or equal to
< or LT Less than

Maintain variables
<= or LE Less than or equal to
= or EQ or IN Equal to
<> or NE or NOTIN Not equal to
See the "Comparisons" topic in the online help (ALCHEMY.CHM) for details.
Functions
You can use the following functions in the formula of a variable.
ABS AVERAGE
ENV MIN
MAX NOP
ROUND SGN
SQRT STR
TRUNC VAL
See the online help (ALCHEMY.CHM) for details and examples of these functions.
Vertical functions
Because most of the functions for derived variables operate on variables for a single location, or a
single combination of levels for a single location, the following functions let you calculate sums and
averages for all locations, or for all colors within a single location, for example.
Given the following set of collected data for an allocation:
Store_ID Style_ID Color Size sales1ago sales2ago

001 100.ABC R S 11 10
001 100.ABC R M 18 17
001 100.ABC R L 22 18
001 100.ABC G S 12 15
001 100.ABC G M 15 14
missing row
002 100.ABC R S 16 16
002 100.ABC R M 22 24
002 100.ABC R L 18 16
002 100.ABC G S 15 12
002 100.ABC G M 9 6
002 100.ABC G L 12 11
There are two locations, one style, two colors, and three sizes. No data was collected for location 001,
Green, Large; that row is missing.
Horizontal functions act on values across this set of data; for example, the average of sales1ago and
sales2ago is given by:
AVERAGE(sales1ago,sales2ago)
This formula produces a value within each row of the above table.
Vertical functions, on the other hand, act on the columns of this set of data, working down the table.
For example, you might want to know the average sales last week for all sizes in color red for a
particular location; or even the average sales last week for all locations.

Maintain variables
The application considers the data relevant to the merchandise being allocated. Even if data for 20
colors is collected, if only three colors are being allocated, the number of colors that the application
reads from the collected data is three.
For example, given the following set of collected data:
Store_ID Style_ID Color Size sales1ago sales2ago

001 100.ABC R S 11 10
001 100.ABC R M 18 17
001 100.ABC R L 22 18
001 100.ABC G S 12 15
001 100.ABC G M 15 14
If you were allocating one style, in two colors (Red and Green) and two sizes (Small and Medium), the
highlighted line for Red Large would not be used by the application. It would be as if the line was not
written to the format table.
See the online help (ALCHEMY.CHM) for details on vertical functions: AVG, COUNT, SUM, ZAVG,
ZCOUNT, and ZSUM.
Functions for other tables

JDA Allocation provides functions for other tables in addition to the format table.
ID
ID is a shortcut for LOCATION_ID in addition to LOCATION (NAME).
Example
IF ID <10 THEN XRegionSales ELSE XAvg2wkSls

returns a Need equivalent to the region sales for all IDs less than 10, and the average of two-week
sales for all others.
LOCATION
The Location function retrieves attribute information about a location from the Locations table.
LOCATION(basevariable)
basevariable is the name of a column on the Locations table. The function is intended to be used
within a WHENTEST expression. LOCATION can return either a string or a numeric.
Example
WHENTEST( LOCATION( CLIMATE ) = 'Warm', 1, WHENTEST( LOCATION( CLIMATE ) = 'Hot', 2, 0

))
produces a value of 1 for locations described as being warm, a value of 2 for hot locations, and a zero
for all other locations.
You must use the Oracle column names, not the Locations table display names, when creating these
attributes.
Example
WHENTEST( LOCATION( REGION_NBR ) = '10', Avgsales_Rgn10_DC999, WHENTEST( LOCATION(

REGION_NBR ) = '20', Avgsales_Rgn20_DC998, Avgsales))

Maintain variables
In this example, we used the Oracle column name REGION_NBR instead of the Locations table display
name of Region Number.
Additional functions
The application provides functions that let you alter the results of a Need variable dependent on the
merchandise already allocated of that type, or the grade of the location, provided you implemented
Currently Allocated Quantities and Store Grading. See "Set up currently allocated quantities" (on page
73) and "Set up store grading" (on page 70) for details on implementing these features.
For details on CAQ, DCAQ, GRADE, and PR functions, see the online help (ALCHEMY.CHM).
Note: A Need calculation containing a constant variable (for example: PR, Prior Results) also must
reference a format table variable.

Set up data collect
Chapter 25. Set up data collect

The data collect process obtains actual or planned data and passes it to JDA Allocation so the
application can consider it when distributing merchandise.
The application distributes merchandise based on the Need of each location. Need can be based on
actual data from your transaction management system, data from other systems, or plan data.
Set up data collect levels

Data collect levels let your distributors request the data they want to use in their allocations. A data
collect level is a template for a data collect rule; the user picks a data collect level, and the values
from the merchandise the user is currently allocating are used to turn the level into a rule.
Once a data collect level has been established, rules are built from the levels. Because of this, data
collect levels cannot be modified after they have been established.
This level does not indicate the level in the product hierarchy at which the application generates Need,
because the application generates Need based on how the host system populates the format table.
Each level is associated with a single format table.
For example, assume you have the following data collect level, associated with your Sales and Stock
format table.
Dept = ?;Class = ?; Style = ?

When the distributor uses this level, the question marks are replaced by the values for the
merchandise for which the distributor wants to collect data, turning the data collect level into the
following data collect rule:
Dept = 01;Class = 014; Style = 1AAAP

The host system receives this message, and populates the Sales and Stock format table with the
appropriate data, which the application could read and use to generate a Need for each location.
This collect is a style level data collect; therefore, you name this level Style. The name you give the
level is what the distributor sees when asked to choose a level.
For most data collects, the default low-level rule uses the wildcard specified on "Step 11" (on page
103) of Allocation Database Setup to represent low-level members, if multiple members at level 1 or
lower are present on one WorkList line. For example, a color level data collect rule for four colors may
look like this example:
Dept = 01; Class = 014; Style = 23166; Color = All
Data collect hierarchy ranges

Before you create a data collect level using Allocation Administration, you must verify that you set up
hierarchy ranges for the format tables for which you want to collect data.
Hierarchy ranges describe the portions of the hierarchy that you can use to create data collect levels;
for example, in a Division, Dept, Class, Style, Color, Size, Width hierarchy, you may be allowed to
create data collect levels from the Dept, Class, Style range.
In each data collect level, you must start at the top of the range, and work down through the levels.
For example, with a Dept, Class, Style range, you could create the following three data collect levels.
Dept = ?
Dept = ?;Class = ?
Dept = ?;Class = ?;Style = ?

Set up data collect
If you have associations with your hierarchy range, you can add nonhierarchical groups to your data
collect level. For example, you could have Vendor and Price Point associated with the Style group. You
can choose to add Vendor or Price Point to your data collect level whenever you add Style. This
addition allows you to create the following additional data collect levels.
Dept = ?;Class = ?;Style = ?;Vendor = ?

Dept = ?;Class = ?;Style = ?;Price Point =?
Dept = ?;Class = ?;Style = ?;Vendor = ?;Price Point = ?
You can set up hierarchy ranges using Allocation Database Setup. See "Step 4: Define the hierarchies"
(on page 94) for details.
Create a data collect level

1. Choose Maintain > Data Collect Levels > New. The dialog box for selecting a format table is
displayed. Each data collect level is associated with a single format table.
2. Select the format table for which you want to create a data collect level from the list, and click OK.
The New Data Collect Level dialog box is displayed.
3. Type a Level Name. The level name is what the distributor sees when selecting the level for a
data collect. Level names can be up to 30 characters long, and may include spaces.
4. If you have more than one data collect parameter, for example, a base parameter and parent
parameter, you can enter lines for each parameter. Click the + sign next to each parameter folder
to open it.
If you do not have parameters, you see an expandable tree containing the members of the
hierarchy range for your format table.
5. Double-click the first member of the Hierarchy to add it to the level. For example, double-click
Department.
6. Double-click an operator from the Operators list to add it to the level. For example, double-click
=.
7. Continue with the next member of the hierarchy that you want to include in the level; for example,
Class.
You have a data collect line such as:

Host: Product; Department = ?; Class = ?
8. If you have nonhierarchical groups associated with any groups in the hierarchy, they display in the
same folder. You can add these groups by double-clicking the name, then the operator, or you can
leave them out of the data collect level.
9. Click New Row to create a new row with a different parameter. You must not create more than
one row, unless you have a different parameter in each.
10. Click Save to save the data collect level, and Close to close the dialog box.
Delete a data collect level

1. Choose Maintain > Data Collect Levels > Delete. The Delete Data Collect Levels dialog box is
displayed.
2. Select the Level Name from the list.
3. Click Delete.
Caution: There is no confirmation for deleting a data collect level.
4. Click Close.

Administrator delete functions
Chapter 26. Administrator delete functions

Users can create and save results, methods, and WorkList views. These can be global or accessible
only by the user who created them.
Administrators can build like store rules.
As system administrator, you can delete any of these items that are not used or may have expired.
Remove the results set name

1. Choose Maintain > Delete > Remove Results Name. The Remove Results Name dialog box is
displayed.
You can sort the results by name, user, or date by clicking the tiles at the top of the dialog box.
2. Select the results name you want to remove, and click Delete.
3. Confirm the deletion.
4. Click Close.
Tip: Press Ctrl+click to select more than one set of results.
Results purge
Named and unnamed results sets and their corresponding WorkList and shape table records remain
indefinitely, unless code is executed to clean them up. You can purge these potentially unneeded
records either programmatically or through Allocation Administration.
First, select the Enable Results Purge parameter on Step 11 of Database Setup. Next, in Allocation
Administration, specify the number of days to keep the results from the Action > Results Purge
menu. Then, execute the purge process. When executed, the results purge procedure uses your
configured settings to determine what should be purged. By default, unnamed results sets and their
corresponding WorkList and Shape records are eligible to be purged after 14 days. Named results sets
have a life of 999 days, by default.
Schedule the purge process to run from a command line on an administrator's Windows machine
where Allocation Administration is installed, or execute it directly from the database package in Oracle.

%PURGE_RESULTS
Notes:
Example: SQL*Plus
EXEC AALResultsUtils.PurgeResults

It is expected that the procedure will be scheduled to run once daily. It will delete only results and
their corresponding records for released allocations whose queue_out entry has been processed and
deleted by the interface. If a queue_out record still exists for an allocation, it will not be deleted.
See "Delete results" (on page 69) for more information about removing results data.
Like Store Rules Purge

A purge process is available to purge Like Store Rules.
To execute the purge process, select Action > Like Store Rules Purge > Execute…
All Like Store rules that meet the following passed date criteria are purged when this process is
executed:
 Rules with a Purge Date that is earlier than the current system date
Alternatively, rules can be purged programmatically. The purge process can be scheduled to run from
a command line on an Administrator's Windows machine where Allocation Administration is installed.
The command line option is %PURGE_LSPRULES.
Notes:
 The message that indicates when the process is complete is suppressed when the purge is
executed via command line.
It is expected that the procedure is scheduled to run as often as needed to purge expired rules.
Storing a high volume of rules (>1000) in the database may degrade performance.
Delete a method
1. Choose Maintain > Delete > Methods. The Delete Methods dialog box is displayed.
You can sort the methods by name, user ID, or date by clicking the tiles at the top of the dialog
box.
2. Select the method you want to delete, and click Delete.
4. Click Close.
Tip: Press Ctrl+click to select more than one method.
Delete a WorkList view

1. Choose Maintain > Delete > WorkList Views. The Delete WorkList Views dialog box is
displayed.
2. You can sort the views by name, user ID, or date by clicking the tiles at the top of the dialog box.
3. Select the view you want to delete, and click Delete.

5. Click Close.
Tip: Press Ctrl+click to select more than one view.
Delete a named data collect rule

1. Choose Maintain > Delete > Named DC Rules. The Delete Data Collect Rules dialog box is
displayed.
You can sort the views by name, user ID, or date by clicking the tiles at the top of the dialog box.
2. Select the data collect rule you want to delete, and click Delete.
4. Click Close.
Tip: Press Ctrl+click to select more than one set of results.

Create and maintain Auto-Allocation schedules
Chapter 27. Create and maintain Auto-Allocation

schedules
Auto-Allocation is a component of the JDA Allocation application. Auto-Allocation enables allocations to
run unattended, for example, overnight, to distribute merchandise to stores and reserve warehouses
using rules, restrictions, and Need calculation. Auto-Allocation has the ability to perform distributed,
unattended, scheduled allocations using models or established allocation methods. It provides progress
and error reporting as well as reviewing capabilities.
Auto-Allocation allows the user to focus on reviewing and adjusting allocations instead of stepping
through the process to produce the initial allocation. Auto-Allocation is well suited to support basic
stock replenishment.
Auto-Allocation provides a graphical user interface that lets you set controls for logging job details, and
displays the progress of the auto allocation as it is running. Tables and schedules that reference
existing WorkList lines within the JDA Allocation product control Auto-Allocation.
Configuration considerations
The following are suggestions to consider when planning your configuration for Auto-Allocation.
Determining the optimum configuration for your site may require some experimentation.
Issues that may have an impact on the configuration you select include the volume of network traffic,
number of users, and level of saturation your site supports. Machines running Auto-Allocation should
be close to the database. However, if you have a large number of machines dedicated to running Auto-
Allocation while nearby user machines are running interactive JDA Allocation, concurrent activity may
slow processing.
You may choose to run application server-type machines both day and night with Auto-Allocation
exclusively. Or, you may want to run user-type machines with JDA Allocation during the day and Auto-
Allocation at night. Each machine running Auto-Allocation must have its own user ID and password.
Start up and shut down of Auto-Allocation must be managed by the site. Users can manually shut
down JDA Allocation and start Auto-Allocation, and vice-versa. Third party scheduling products can be
used to start and stop Auto-Allocation.
Auto-Allocation process
Auto-Allocation provides all the functionality available in the interactive JDA Allocation product. In
addition, Auto-Allocation provides the ability to run allocations without real-time intervention. Auto-
Allocation uses the same files (with some additional files), and has the same requirements as JDA
Allocation.
Auto-Allocation can be installed on the same machine as JDA Allocation, but the two cannot run
simultaneously on the same machine. You can, however, set up Auto-Allocation to run during the night
on the same machine used to run interactive JDA Allocation during the day.
A schedule table holds the required information for Auto-Allocation, including run times, filters,
methods, and action to take when the allocation is complete. When there is conflicting information
between the WorkList and the schedule table in Auto-Allocation, the schedule table takes precedence.
The scheduling process creates the job queue entries that manage running each item. Each job is
assigned a job number in the queue. Multiple machines can be set up to check the queue to run the
next job. A machine checks the queue every five minutes. The scheduling process can be launched
interactively by users, or can be set to launch from Allocation Administration.

When a schedule record is queued, the appropriate WorkList line is updated to include the job number,
method, and filter information required for the allocation. The WorkList line is locked until the job is
completed. The schedule process cannot queue the item if the WorkList line is not available.
Auto-Allocation must have access to the Need variable for that particular method. Without a Need
variable defined in the WorkList or the method, Auto-Allocation cannot proceed.
All major events during an Auto-Allocation are written to a table that can be viewed in Oracle or an
Oracle-compatible reporting tool. Reporting is centralized so information from every job run from the
job queue is accessible in one location.
By including the option in the schedule table, you can choose to release the allocation automatically
after it is complete; or you can review and release the allocation manually.
Requirements
User IDs for Auto-Allocation must be established and set up as global administrator with all rights. In
Allocation Administration, choose Maintain > User List to add or edit user IDs.
All other requirements for Auto-Allocation are the same as for JDA Allocation. See the JDA Allocation
Installation Guide (INSTALL.PDF) for details.
WorkList mappings
When you first use Auto-Allocation, the following new columns must be added to the WorkList and
mapped using Allocation Database Setup. In some cases, mapping may be optional.
Example WorkList
Columns Map to JDA Allocation Auto-Allocation
METHOD_NAME Method Name Optional Required
AA_JOB_NUMBER Auto-Allocation Job Number Not Applicable Required
MODEL_NAME Model Name Optional Optional
STORE_SELECTION Default Store Selection Optional Optional
CURRENT_ACTIVITY Current Activity Required Required
Auto-Allocation tile on the Administrator Dashboard

The Auto-Allocation tile on the Administrator Dashboard allows the administrator to monitor the status
of current Auto-Allocation jobs, maintain and process the Auto-Allocation schedule, review and
maintain the Auto-Allocation batch report, and reset or re-queue failed jobs.
The Auto-Allocation tile uses a mapped Available Quantity column on the WorkList in order to calculate
allocated units. This column can be configured in Allocation Database Setup, step 9.
Schedule Auto-Allocation
Choose Maintain > Auto-Allocation Schedule in Allocation Administration, where you can enter the
required information into the schedule table. There is no validation.
The scheduling process checks the schedule table for any schedule items that need to be run.
Authorized users can interactively start the scheduling process, or it can be set to run at specified
times.

The product you want to allocate must be described by a filter for the WorkList. In the schedule table,
you can use the name of an existing filter, or you can type the text defining the filter. If you define the
filter in the schedule table, column names or descriptions can be used, but they are case sensitive. The
schedule table must also indicate the method to be used. This information is copied to the WorkList by
the schedule process.
When there is conflicting information between the WorkList and the schedule table in Auto-Allocation,
the application can be configured so that either the schedule table or the WorkList takes precedence. If
either the model or the method name column is null in the schedule table, the corresponding WorkList
columns are not overwritten.
Schedule table
Edit the schedule table in Allocation Administration by choosing Maintain > Auto-Allocation
Schedule. Columns in the schedule table include:
 Enabled indicates whether this schedule record is available to be processed. Y and N are the legal
values for this column. This column can be edited by the administrator and updated by the
schedule process. This column is required, and must be set to Y for the schedule record to be
processed.
 Process Record After Date is the date/time before which the record should not be processed.
The record will not be processed before this date/time. The calendar displayed when this cell is
selected includes time of day (based on a 24-hour clock). This column can be edited by the
administrator and updated by the schedule process when re-scheduling of the record takes place.
Null is a legal value. Populating this column is optional.
 Record Last Processed Date is the date/time the schedule record was previously processed. The
schedule process automatically includes this information. This column cannot be edited.
 Last Successful Job Created is the date/time when processing the schedule record resulted in a
job being created for Auto-Allocation. This column cannot be edited.
 Do Not Process After Date is the date/time after which the schedule record should not be
processed or rescheduled. The first time the schedule is processed after this date, the record is
disabled. Null is a legal value.
 Override allows you to override schedule information and force the schedule record to be
processed the next time the schedule is processed, as long as it is not after the Do Not Process
After Date. Y, N, and A are the legal values for this column. Y indicates that the record should be
processed during the next schedule processing, regardless of the Process Record After Date. Y
is a temporary override, which is set to N after processing. N indicates there is no override of the
Process Record After Date. A indicates that the record should always be processed, regardless
of the Process Record After Date. A is a permanent override and can only be changed by the
administrator. If a schedule record is processed due to the presence of Y or A in the Override
column, the Process Record After Date is unaffected. Null is a legal value. This column is
optional.
 Schedule Code is used during rescheduling, if the item was processed based on the Process
Record After Date. It allows you to set the schedule record to be processed certain days of the
week, as represented by a number. If a record is currently scheduled for a particular date/time
that does not correspond to the Schedule Code, the schedule record is processed based on that
date, then rescheduled for the next valid date matching the Schedule Code. Legal values for the
days of the week are 1, 2, 3, 4, 5, 6, and 7 (corresponding to Sunday through Saturday), used in
this format: D:<n>[,<n>].
For example: D:4,6

The 4 and 6 represent Wednesday and Friday respectively. Null is also a legal value.
This column is optional. If a schedule code is used, set Override to null and set the initial
date/time for Process Record After Date.
 Interval is used during rescheduling if the item was processed based on the Process Record
After Date. It contains a number representing days that specify how often the schedule record
should be processed. Legal values are 1 through 365. Null is also a legal value. This column is
optional. If this column contains a value, set the initial date/time for Process Record After Date.
 Filter contains the name of a view saved in the WorkList, or a filter as it would be entered in the
filter field in the WorkList View dialog box. If a WorkList view is used, it must contain a filter. If
column descriptions are used, you must type them exactly as they display in the WorkList, because
they are case sensitive. This column is required.
To indicate the text is a filter name (created and named using the WorkList or Store Selection
dialog box), the at sign (@) must precede the name. You then must specify the user ID, preceded
by a tilde (~), for personal filters. For example, @MyFilter1~Marilyn refers to a filter previously
created and saved as a WorkList view in the WorkList. It is recommended that you specify the
owner (user ID) for global views, although it is not required.
 Method contains the name of the method to be used to perform the allocation. Select a method
from the list in the Method column. Null is also a legal value. If no method name is included in the
table for this schedule record, there must be a method for this product in the WorkList for Auto-
Allocation to proceed.
Notes:
 Override Location Restrictions and Override Specified Reserve Warehouse options are
saved with methods. The user’s privileges are checked when the method is loaded; if user does
not have permission to override, the option is ignored.
 If any criterion in the method references grading, the method must include the grading
information.
 You should attempt to include all information typically provided by the user during an
interactive allocation within methods, to avoid assumptions by the application.
 To ensure that any methods for Auto-Allocation contain valid data collection criteria, you must
successfully collect data before the method is saved.
 The application does not prohibit multiple users from creating methods of the same name.
Specify the user that created the method, as well as the method name, when referring to a
method in the schedule table or WorkList to ensure that Auto-Allocation uses the intended
method. Use the following format: methodname~user id.
 Model Name contains the name of the model to be used with the method. The name must
reference a model that has details for all merchandise that matches the WorkList selection defined
by the filter. Null is a legal value. Model Name ensures that the product being allocated has an
associated model, which is required if the method's Need calculation references model data.
 Store Selection contains the name of the store selection to be used with this method. The name
must reference a valid store selection. Null is a legal value.
Note: If a store selection is specified in both the method and the Store Selection column, the store
selection in the method takes precedence.

 Final Action contains the instruction code to either approve or release on successful completion of
the allocation. A and R are the legal values for this column. Null is also a legal value. If this
column is left blank, the default is to approve the allocation.
 Process Information is used by the schedule process to display information resulting from
attempts to queue or re-schedule records. You cannot edit this column.
 User Notes can be used to enter any information relevant to that schedule record. Use of this
column is optional.
 Process Order can be used to define the order of processing for each of the schedule records. The
records will be processed in order from lowest to highest integer. Use of this column is optional.
Notes:
 When the schedule has been processed, a job code is displayed in the WorkList for each record
currently queued for Auto-Allocation. The user cannot enter the WorkSheet for these records until
the Auto-Allocation jobs are complete.
 When there is conflicting information between the WorkList and the schedule table in Auto-
Allocation, the Auto-Allocation Schedule Preferences in Allocation Administration define the order of
precedence.
Define the order of processing for the schedule records

The Process Order column defines the order in which the schedule records are processed. The records
that contain numeric values are processed in order from lowest to highest number. Any records that do
not contain values are processed last, and in the order they appear in the Schedule Record table. The
Process Order column can be edited directly in the Auto-Allocation schedule table. Click on each cell to
make the cell editable and enter a numeric value.
Reorder based on position in the schedule table

Schedule records can also be reordered by using drag and drop. Highlight one or more records in the
schedule table and drag them to their new position. Repeat this process until the desired sequencing is
achieved. To apply the current schedule table order:
Choose Action > Auto-Allocation > Apply Auto-Allocation Schedule Order.
A series of numeric values is inserted into the Process Order column that causes the records to be
processed in the current order.
Schedule process
The schedule process checks the schedule records and attempts to process records as appropriate.
Then, the schedule process reschedules records.
Process records
The schedule process attempts to process records by first checking for the Process Record After
Date date/time and selecting all records with a date/time that is past or equal to the current system
date/time, but before the Do Not Process After Date. If Enabled is Y for the record selected, the
schedule process checks the appropriate WorkList line to determine if it is available. If so, the record is
queued to run.
Similarly, the schedule process attempts to process all records with an Override value of Y or A.
These records do not calculate a Process Record After Date, based on a schedule record. If Run
Today was Y, it becomes N.

If the record is processed based on Process Record After Date, the record is rescheduled. Records
scheduled based on the Override value only are not rescheduled.
Reschedule records
The schedule process attempts to reschedule records by changing the date/time in Process Record
After Date for that record. The schedule process first attempts to determine the Process Record
After Date date/time, based on the Schedule Code (D:1,2,3,4,5,6,7).
If there is no Schedule Code, the schedule process reschedules based on Interval. If the Schedule
Code is invalid, Enabled is set to N for the record. If there is no Schedule Code and no Interval,
Enabled is set to N for the record.
If rescheduling a record results in a date/time after the Do Not Process After Date, Enabled is set
to N for that record.
Start the schedule process

The schedule process is managed by a PL/SQL stored procedure that exists in the JDA Allocation Oracle
database.
You can start the scheduling process in one of three ways.
 You can schedule the process to run as an Oracle job, using Oracle functionality. Check with your
DBA for details. The name of the procedure is ALLOCSCHED.SCHEDULEJOBS in the AAM schema.
Using SQL*Plus, enter the following in the AAM schema:
EXECUTE ALLOCSCHED.SCHEDULEJOBS;
 You can run the scheduling process from Allocation Administration, using Action > Process Auto-
Allocation Schedule.
 You can set up the process to be started using a command line statement. This option is available
on a machine where Allocation Administration is installed. Starting the scheduling process in this
way is useful particularly for schedule processing as part of other batch processes that run at
night. This option is the same as starting Administration and choosing Action > Process Auto-
Allocation Schedule. For example:
%PROCESS_SCHEDULE
Notes:
command line syntax to start any of the AL applications. A connection file can also be included
as one of the command line options.
How frequently can the schedule process be run?

You might want to run the schedule process nightly, after the WorkList has been updated.
You might prefer to run the process all the time; however, do not start the schedule process until the
previous run has been completed. The schedule jobs process does not support being executed more
than once at any given time.

The optimum frequency for running the schedule process depends on how big the schedule table is and
how long the process takes. You may need to experiment with your application to determine the best
approach to scheduling. A batch job that overlaps the previous batch job will not process.
Run Auto-Allocation
Auto-Allocation lets you set controls for logging record details, and displays the progress of the
application as it is running.
Manually
Double-click the Auto-Allocation icon.
By command line
Three different command line statements control starting and stopping Auto-Allocation.
 Starting Auto-Allocation from a command line:

"C:\Program Files (x86)\JDA\JDA Allocation\AlcAuto.exe" [username] [password]
 Stopping Auto-Allocation from a command line:

"C:\Program Files (x86)\JDA\JDA Allocation\AlcAuto.exe" %STOP_NOW
 Starting Auto-Allocation from a command line so it shuts down when the queue is empty:
"C:\Program Files (x86)\JDA\JDA Allocation\AlcAuto.exe" [username] [password]
%SHUTDOWN_WHEN_DONE
Notes:
 The username and password must have Allocation Administrative privileges.
Schedule Auto-Allocation with a Windows scheduler

By default, the Windows Task Scheduler launches applications using the Local System account.
Allocation applications require a Windows user account profile for registry settings, cache folders, and
log file path. When using the Windows Scheduler Service to launch Auto-Allocation, configure your
Task Scheduler Properties to Log On as a specific account.
After that option has been selected, you can run Auto-Allocation using commands similar to the
following examples.
at hh:mm %AAL_HOME%\ALCAUTO.EXE [username] [password] %SHUTDOWN_WHEN_DONE

To stop Auto-Allocation, use the %STOP_NOW switch, even if the queue is not empty. This switch can be
useful when controlling Auto-Allocation clients on several machines.
If you have the appropriate permissions, you can start Auto-Allocation with the following command.
at \\machine_name 12:00 "C:\Program Files (x86)\JDA\JDA Allocation\ALCAUTO.EXE"

[username] [password]

You can use the following command to shut down the Auto-Allocation session six hours later.
at \\machine_name 18:00 "C:\Program Files (x86)\JDA\JDA Allocation\ALCAUTO.EXE"

[username] [password] %STOP_NOW
Notes:
 The username and password must have Allocation Administrative privileges.
 The full path must be listed, not just the executable. The AAL_HOME environment variable can be
used to identify the Allocation installation folder if the scheduling is being performed on the
machine where Allocation is installed. If scheduling from a different machine, the Allocation
installation folder must be specified. If the directory name contains spaces, use the short path
format or put the path and executable name in quotes. You can also select the /interactive flag
for Auto-Allocation, so you can see the application while it is running.
Save the text buffer

You can select all or a portion of the text buffer in the display and save the selection to a file. You
choose the file name and whether you want a simple text format (.LOG) or a rich text format (.RTF)
file.
Log file features

You can set Auto-Allocation to write all minor and major events to a log file for each machine running
an auto-allocation. Writing to log files is optional, and can be selected from the Auto-Allocation
interface. The log file name is generated based on today's date. For example, January 15, 2006 would
be AA150106.LOG.
Log files are useful during debugging when you first are establishing your Auto-Allocation process.
Once your schedule records are processing smoothly, typically the major events included in reports are
sufficient information to track your allocations.
Processing assumptions
Assumptions generally mean that a new condition not previously considered in a method has been
encountered and should be resolved. An allocation that includes assumptions is not released. Auto-
Allocation handles the following three assumptions.
 If the method does not specify how to handle leftover goods, Auto-Allocation assumes that all
leftover goods are forced to reserve.
 If your method uses a variable that references planning data, and the method does not contain
planning time period information, Auto-Allocation uses the current time period.
 If your method requires grading criteria for store selections or Need, and the method does not
contain grading information, Auto-Allocation uses default grading criteria and current time period.

Reporting
Reporting is centralized so up-to-date status from every job is accessible in one location.
The application records all major events to the report tables as Auto-Allocation proceeds. There are
two tables, AA$BATCH_HEADER and AA$BATCH_DETAIL. All machines running Auto-Allocation from
the same schedule table report to the same centralized reporting table. You can use Oracle Forms or
another Oracle report reading tool to view these reports.
The header table includes the status field with major status information, such as approved or released.
The detail table lists any assumptions that were made or errors encountered. This table is specific to
Auto-Allocation, and is not the detail table used by JDA Allocation.
These tables require routine cleanup. JDA Allocation provides options for maintenance of data on these
tables.
In addition to the ability to review this Auto-Allocation data in the Administrator Dashboard, we have
provided a sample script, as shown below, that can be used directly or modified as required to create
simple Auto-Allocation reports.
START %JDA_ALLOCATION_SCRIPTS%\SAMPLES\AAREPORT.SQL
The report produced can be printed in Notepad using the following settings:
 Optimized for printing from Windows Notepad
 Courier New, Regular, Size 12, Western script
 Margins: L(0.183") R(0.171") T(0.165") B(0.183")
 The header and footer should both be blank.
 Paper size: Letter; Orientation: Portrait
These settings are suggested to provide appropriate page breaks in the report.
Maintain the Auto-Allocation report data

On the Auto-Allocation tile of the Administrator Dashboard, select Configure Data Maintenance and
specify the number of days of data to preserve when the report is cleaned.
Run the data maintenance process by selecting the option on the dashboard tile. You can also run this
process using a command line option or PL/SQL procedure.

%CLEANUP_AUTO_BATCH_TABLES
Notes:
 You should successfully log in to establish a connection to the database before using the command
line syntax to start any of the AL applications. A connection file can also be included as one of the
command line options.
 To control this via PL/SQL, run AllocSched.CleanupAutoBatchTables.

Suspend and resume Auto-Allocation processing

You can suspend and resume the processing of all Auto-Allocation jobs from a central location.
This can be controlled using the Auto-Allocation tile on the Administrator Dashboard or the Allocation
Administration Action menu. Select Action > Auto-Allocation > Suspend Auto-Allocation Jobs or
Resume Auto-Allocation Jobs. After Auto-Allocation jobs have been suspended, no more jobs will be
initiated, although jobs that have already started will continue until they have completed.
It can also be executed via a command line option, which enables it to be called from a batch process
to run on an administrator's Windows machine where Allocation Administration is installed. The options
are %SUSPEND_AUTO_JOBS and %RESUME_AUTO_JOBS.

%SUSPEND_AUTO_JOBS
Notes:
 To control this via PL/SQL, run either AllocHost.SuspendAutoJobs or

AllocHost.ResumeAutoJobs.
 This feature requires the use of Oracle 11g.
Monitor process
You have an option to configure and run a client service to monitor the running Auto-Allocation jobs
and generate an alert if a job fails to complete within a specified amount of time.
The AA$ALERT_QUEUE system table holds details about the job that failed to respond. You can query
this table for alerts and take action as necessary.
Detailed information on the configuration of this feature is located in the Online Expert (OLE) by
selecting Help from within Allocation Administration.
Note: This feature requires the use of Oracle 11g.
Clean up
You can clean up information related to jobs in the Auto-Allocation job table and in the WorkList, by
running commands from SQL*Plus.
The following command deletes all records from the AA$JOB table that represent either completed or
failed jobs. It does not delete any jobs in progress or newly scheduled jobs. WorkList lines
representing failed allocations are reset to available, with their auto-allocation job number cleared out,
as part of this process.
EXECUTE ALLOCSCHED.AUTOALLOCATIONCLEANUP;

In addition to performing everything described in the first example, this command also undoes any
scheduled jobs that have not begun, and clears out the auto-allocation job number as part of resetting
the associated WorkList lines to available.
EXECUTE ALLOCSCHED.AUTOALLOCATIONCLEANUP(TRUE);
You can reset failed Auto-Allocation jobs by choosing Action > Reset Failed Auto-Allocation Jobs in
Allocation Administration or by passing the %RESET_FAILED_AUTOALLOCATION_JOBS switch as a
command-line parameter to JDA Allocation.
You can reset all Auto-Allocation jobs by choosing Action > Reset All Auto-Allocation Jobs in
Allocation Administration or by passing the %RESET_ALL_AUTOALLOCATION_JOBS switch as a command-
line parameter to JDA Allocation.
Review results and release allocations

You can review results and release allocations just as you do in interactive JDA Allocation, or you can
choose to automatically approve and release an allocation when processing is complete. (The WorkList
line shows as "In Process" while Auto-Allocation is processing).
To approve and release the allocation automatically, set the option in the final action column of the
schedule table.
If Generate Need When Loading Auto-Allocation Results is enabled in Allocation Database Setup
step 11, you can view the calculated Need that Auto-Allocation used for a particular allocation. This
Need applies to Auto-Allocation results that are in either Approved or Discrepancy status, and is
generated during WorkSheet entry when reviewing the results from the original data collected.
However, if the format table is cleaned out before the review, JDA Allocation cannot display the
calculated Need. Dynamic information not stored in format tables, such as CAQ or GRADE, will have
been changed since Need was originally calculated. To address the issue of CAQ being dynamic, we
recommend using the DCAQ feature that collects CAQ based on the data collect rule and stores the
information in the format table. This feature allows re-use of the information as needed.
If any Auto-Allocation jobs are pending review, do not change methods that are referenced by the
Auto-Allocation job. If the referenced methods are changed, the review will no longer be meaningful.
An alternative approach is to Enable Saving and Loading of Need Values with Results in
Allocation Database Setup step 11. This does not require Need to be generated from the format table
data, and it is not affected by changes to CAQ. However, this functionality only loads the Need values
and does not provide access to the base & derived variables that were used to generate the Need.

Build like store rules
Chapter 28. Build like store rules

Like store support provides the ability to apply select store or store group historical data by variable to
a location that has no history or has history that is not useful.
The Like Store Support dialog box provides an easy to understand and easy to use mechanism for
building like store rules. A rule can be assigned to a high level of the product hierarchy and all levels
below inherit that assignment. Or you can assign different like stores to different product hierarchy
levels while easily keeping track of these assignments as you proceed.
Some database set up is required before proceeding to build the rules. See "Set up like store support"
(on page 104). You must then select variables for use in like store support.
Select variables for use in like store support

You must define like store variable criteria prior to applying like store rules. Like store variables do not
include those mapped for data collect CAQ (DCAQ), prior results, model target, or model threshold, as
the like store process does not apply to these variables.
Variable patterns are assembled by Allocation to enable quick and efficient criteria selections. The
selections you make for the pattern are inherited by the all of the members of the pattern.
Choose Action > Establish Like Store Variable Criteria…. The dialog box containing the variable
criteria options is displayed.
1. Select the format table that contains the variables you want to include in like store support.
Note: Planning format table variables and mapped variables, such as Model Target, Model
Threshold, Prior Results, and DCAQ, are not eligible for like store assignment.
2. Select the corresponding Time Period for the variable patterns. For example, if each member in
the pattern Sales_<n>_ago represents one week's worth of history, the corresponding time period
is Weekly for that pattern. You must select the length of time represented by each member of a
pattern in order to begin using the new store's history while continuing to use the like store's
history. Each time period, Allocation will use another portion of the new store's history, while
phasing out the like store's history. See "Build like store rules" (on page 169)
3. Check the Include Like Store check box.
Patterns
Click the Patterns… button to display the dialog box for suspending patterns. This dialog box also
displays pattern matched variable lists.

Choose Maintain > Like Store Support. This displays the dialog box for building like store rules.
1. Select the Apply To Store for which you want to create a like store rule from the list.
2. Select a Like Store or Like Store Selection.

Note: An Apply To Store can only reference itself as a Like Store in a direct Like Store reference.
However, a store cannot reference itself in an indirect reference via a Like Store selection. The
reason for this is that a store can be used both as an Apply To Store as well as a Like Store for a
different store. The system must determine how to apply the like store rules so that any Like
Stores that are also Apply To Stores are updated in an appropriate list. Like store circular
references are detected when the system applies the like store rules. If any are found, the like
store data collect will fail. To avoid the possibility of indirect circular references, the system filters
out the Apply To Stores from the Like Store Selections when applying like store rules.
3. Select the desired date criteria. The Transition To Like Store is the date when Allocation initiates
applying the like store's product data collection to the new store. The Transition From Like Store
date is the date when Allocation begins using the new store's own history as it accumulates, while
continuing to use some of the Like Store's history. The Purge Date is the last day that Allocation
uses the like store's data.
Note: These dates are applied to rules based on the date/time of the machine where the
application is running.
4. Check the box and type a Percent Increase to increase the like store's history by <n>% when
applying the data to the new store.
5. Choose a product. You can select multiple products that will use the currently selected location and
date criteria. Each product selection is separated into individual rules.
6. Select Add, to build a rule(s) and continue working. Note: By selecting Add, you are not yet
saving the rule to the database. Selecting Add before Apply or OK is optional.
7. Select Apply to save the rule to the database, and continue working in the Like Store Support
dialog box. Select OK save the rule to the database, and exit the Like Store Support dialog box.
Edit a like store rule

1. Select the Apply to Store. All rules for that Apply To Store are displayed in the Rules grid.
2. Select the rule from the list. The dialog box is populated with the rule criteria.
3. Edit the criteria.
4. Select Update Rule.
5. Select Apply or OK.
Delete a like store rule

2. Select the rule from the list. Select multiple rows by pressing Ctrl+.
3. Select Delete Rules.
4. Select Yes to confirm.
To delete all rules for that Apply To Store, right-click the Rules grid and select Delete All Rules.
Note: An expired Purge Date does not remove the rule from the Rules grid. You can remove expired
rules by selecting them and using the Delete Rules button or by executing the "Like Store Rules Purge"
(on page 156) process.

Copy a like store rule to a new Apply To Store

2. Right-click the Rules grid. Select Copy Rules. The Copy Apply To Store's Rules dialog box is
displayed.
3. Select the new To store.
4. Select the rules to copy.
5. Select OK. This dismisses the Copy Apply To Store's Rules dialog box. The Like Store Support
dialog box is now populated with the new Apply To Store, its copied rules, and any rules that
already existed for this store.


8.1.2 Admin

Uploaded by

Copyright:

Available Formats

8.1.2 Admin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8.1.2 Admin

Uploaded by

Copyright:

Available Formats

Administrator Guide

Modifications to the contents of this document

Rights to the functionality of this document

Chapter 2. Introduction to Database Setup ..................................................................... 3

Chapter 3. Implementation decisions ............................................................................ 11

Chapter 5. Set up locations ............................................................................................ 28

Chapter 6. Set up the WorkList ...................................................................................... 32

Chapter 7. Set up host data collect procedures.............................................................. 51

Chapter 8. Set up Planning data collect ......................................................................... 64

Chapter 9. Set up results collection procedures ............................................................. 68

Chapter 10. Set up Store Grading .................................................................................. 70

Chapter 11. Set up Currently Allocated Quantities ......................................................... 73

Chapter 12. Set up Model Stock ..................................................................................... 78

Chapter 13. Set up Allocation Scoring............................................................................ 81

Chapter 14. Set up Internal Grading .............................................................................. 83

Chapter 15. Set up Auto-Allocation Server .................................................................... 84

Chapter 16. Use the Database Setup utility ................................................................... 87

Chapter 17. Table definitions ....................................................................................... 105

Chapter 18. Example tables ......................................................................................... 116

Chapter 19. Database tuning ....................................................................................... 125

Chapter 20. Database maintenance ............................................................................. 129

Chapter 21. Allocation system administration ............................................................. 130

Chapter 22. Maintain users .......................................................................................... 132

Chapter 24. Maintain variables .................................................................................... 145

Chapter 25. Set up data collect .................................................................................... 153

Chapter 27. Create and maintain Auto-Allocation schedules........................................ 158

Chapter 28. Build like store rules ................................................................................ 169

Chapter 1. Introduction to JDA Allocation

Allocation Database Setup

Software implementation advisement

What if I need help?

JDA Allocation Administrator Guide 1

JDA Allocation Administrator Guide 2

Chapter 2. Introduction to Database Setup

 Currently supported Microsoft Windows operating system

 Concepts of retail allocation

JDA Allocation database tables

Interfacing to JDA Allocation database tables

JDA Allocation Administrator Guide 3

Input and output

 Actual data, planned data, or both actual and planned data

JDA Allocation Administrator Guide 4

 Merchandise Shape tables

See "Set up the WorkList" (on page 32) for details.

 Create data collect format tables.

 Set up data collect procedures.

 Set up data collect parameters and data collect staging tables.

JDA Allocation Administrator Guide 5

a. Enter the names for the tables you have created.

b. Enter the dimension names.

c. Define the groups.

d. Define the hierarchies.

e. Enter the column information.

f. Define the levels.

g. Set up the data collect parameters.

h. Set up the hierarchy ranges and associations.

i. Set up the column mappings.

j. Set up the merchandise types.

k. Set up the system parameters.