The SAP APO Knowledge Book

Supply and Demand Planning

Wolfgang Eddigehausen

Copyright Notes
All rights reserved. With the exception of quoting brief passages for the purpose of review, no part
of this publication may be reproduced or distributed in any form or by any means without the prior
written permission from the author. This includes the storage in any form of database or retrieval
system.
It is recognized that certain words and abbreviations used in this book are the property of the
respective trademark holder. They are used for clarification and information purposes only. This
book is not an official publication of any company mentioned in it. SAP, R/2, R/3,
AcceleratedSAP, and ABAP/4 are registered trademarks of SAP Aktiengesellschaft,
Neurottstrasse 16. 69190 Walldorf, Germany. The book The APO Knowledge Bank Demand
and Supply Planning is an independent publication. Neither SAP, nor any other company
mentioned in this publication is responsible for the contents of this book under any aspect of press
law.
The information in this book is correct and complete to the best of the authors knowledge. It is
based on APO release 3.0 and patch level 20 as well as the published information of APO release
3.1. All recommendations made in this book are made without any guarantee whatsoever. The
author also disclaims any liability in connection with the use of this book, the used data, and the
recommendations contained in there.
The views expressed in this book are solely those of the author.
ISBN Number:

0-9581791-0-7

This book is dedicated to all those that helped me realizing it.

My wife, Desire, who supported me with her ideas and

helped wherever possible.
My son, Dean, who provided technical input, and
carried out the proofreading.
My sister-in-law, Marilyn, who helped proofreading the
book.

Many thanks to all of you!

About the Author

Wolfgang Eddigehausen was born and grew up in Germany. He studied at the Technical University
in Darmstadt where he earned a degree in Mechanical Engineering, Finance and Accounting.
After completing his degree, he started to work for a large German multi national company in 1986.
Based on the subjects studied, it was a natural progression getting involved in the Supply Chain
Management. He gained a wealth of knowledge in the warehousing and distribution areas as a
project member in various countries such as France, Great Britain, and South Africa. In 1992 he
took up an offer as a project manager for the SAP R/2 implementation of the Material Management
and Production Planning. From there it was a small step to get involved in SAP R/3, which he did
when joining a consulting house in 1994.
The next progression step was into the SAP Supply Chain Management tool APO. Starting early in
1999, he worked on all APO releases and specializes on APO Knowledge Management. Since the
year 2000 he worked as an independent consultant for several clients.
He is a certified SAP consultant in Supply and Demand Planning (APO) as well as in Material
Management (MM), Production Planning (PP), and Accelerated SAP (ASAP). During the last years
he was involved in various activities and projects in Europe, South Africa, Singapore, Taiwan,
Australia, and the USA. Currently residing in Australia, he is fully dedicated towards the Supply
Chain Management area and the use of SAP APO in particular. His area of expertise includes not
only the general Supply Chain Management area, but also a very detailed knowledge of the APO
package. Knowing the problems accompanied with getting started on a new platform like APO, he
decided to write the first available APO related book Understanding SAP APO.
He serves various clients worldwide working through Square-One International. He can be reached
using the e-mail address listed below.
apohelp@square-one.com

About Square-One International

Square-One International is a company specializing in the provision of services around the SAP
APO package. This includes the provision of consulting services throughout an entire
implementation cycle as well as support after having gone live. Of specific focus is conceptual
work at project start as well as user empowerment through training and knowledge transfer
workshops. Based on these focus areas, it does come as no surprise that a product like the SquareOne APO Knowledge Bank was developed. It has been developed over a long time period and
currently supports the following areas:

Demand & Supply Planning

Demand Planning (DP)
Supply Network Planning (SNP)

Manufacturing
Production Planning and Detailed Scheduling (PP/DS)

Order Fulfillment
Global ATP (ATP)
Transportation Planning and Vehicle Scheduling (TP/VS)
You may also want to view the section The UPPER-1 Approach, which describes the approach
on which the Square-One APO Knowledge Bank is based. The product is available to all interested
companies, either as part of the Square-One consulting services or as a web-based knowledge
product that can be accessed by the project members. The benefits can be broken down into short-,
medium-, and long -term benefits. Some of these benefits lead to direct project cost savings, while
others improve the deliverables of the project, and in the long term the efficiency with which the
APO system is used.

Short Term Benefit

Using the Square-One APO Knowledge Bank, it is possible to achieve a substantial time
saving during the implementation and roll-out of APO. Specifically the Understanding
section provides extremely helpful information to all those working on the implementation
project, but not being part of the core implementation team or a competency center.

Medium Term Benefit

The amount of time spent creating the required documents for user training can be reduced
greatly. The resources usually dedicated to this task are freed up to concentrate on tasks that
are closer to their core area of expertise. It must also be noted that the creation of user
documentation requires a certain skill set and experience that does not need to be acquired by
the implementation team.

Long Term Benefit

While at the end of most implementations the user is adequately prepared and capable of
exploiting the system, this ability reduces gradually over time, caused by changing business
requirements and new system functionality. Quite often implementation projects limit the used
functionality for various reasons, but without good post-implementation user support, these
missing bits of functionality will not be implemented, although required.
For further information please visit our web page.
www.square-one.com

Contents

PREFACE....................................................................................................................

1.1
1.2
1.3
1.4

COVERED AREAS .......................................................................................................

CONCEPT ....................................................................................................................
THE UPPER-1 APPROACH ......................................................................................
FEEDBACK ................................................................................................................

INTRODUCTION.....................................................................................................

2.1
APO PLANNING .......................................................................................................
2.2
SUPPLY CHAIN MANAGEMENT IN PERSPECTIVE...................................................
2.2.1 DEVELOPMENTS PAST AND FUTURE ......................................................................
2.2.2 BUSINESS AND SYSTEM INTEGRATION...................................................................
2.2.3 SCM TARGET GROUP.............................................................................................
3

UNDERSTANDING .................................................................................................

3.1
PROCESS OVERVIEW ...............................................................................................
3.1.1 DEMAND PLANNING (DP) ......................................................................................
3.1.1.1 Master Data in Demand Planning .......................................................................
3.1.1.2
Characteristics Based Forecasting........................................
3.1.1.3 Forecasting with Bills of Material.......................................................................
3.1.2 SUPPLY NETWORK PLANNING (SNP).....................................................................
3.1.3
DEPLOYMENT (DEP)...............................................................
3.1.3.1
Transportation Planning .......................................................
3.1.4 TRANSPORT LOAD BUILDER (TLB) .......................................................................
3.1.5 PLANNING WITH R/3 AND APO ..............................................................................
3.2
PLANNING SEQUENCE..............................................................................................
3.2.1 DEMAND PLANNING SUPPLY NETWORK PLANNING ...........................................
3.2.2 SUPPLY NETWORK PLANNING PRODUCTION PLANNING / DS.............................
3.2.3 SUPPLY NETWORK PLANNING DEPLOYMENT .....................................................
3.2.4 DEPLOYMENT TRANSPORT LOAD BUILDER ........................................................
3.3
TIME CALCULATIONS AND DISPLAY ......................................................................
3.3.1
FACTORY CALENDARS ..........................................................
3.3.2
TIME LINE DEFINITIONS ........................................................
3.3.2.1
Storage Buckets Profile.........................................................
3.3.2.2
Planning Buckets Profile.......................................................
3.3.2.2.1 Telescoping Planning Buckets Profile .............................................................
3.3.2.3
Time Streams .......................................................................
3.3.3 POINT OF TIME DEFINITIONS..................................................................................
3.3.3.1
Time Calculation...................................................................
Contents

3.3.3.2
Time Display .....................................
3.3.4
TIME HORIZONS....................................................................................
3.4
METHODOLOGY ...................................................................................
3.4.1
FORECASTING METHODOLOGY ...........................................................
3.4.1.1
Forecasting Techniques......................
3.4.1.1.1 Time Series Based Forecasting .......................................................................
3.4.1.1.1.1
Forecast Preparation .
3.4.1.1.1.2
Forecast Evaluation ...
3.4.1.1.2
Causal Forecasting ....
3.4.1.1.2.1
Forecast Fit ...............
3.4.1.1.3
Judgmental Forecastin
3.4.1.1.4
Composite Forecast ...
3.4.1.1.5
Consensus Based Fore
3.4.1.2
Planning Approach ............................
3.4.1.2.1
Aggregation and Disa
3.4.1.2.2
Fixing of Values ........
3.4.1.3
Life Cycle Management ...................
3.4.1.4
Promotion Planning...........................
3.4.2 DEMAND AND SUPPLY CALCULATION ................................................................
3.4.2.1
Stock Definition ................................
3.4.3
REORDER PROCESS...............................................................................
3.4.3.1
Reorder Decision...............................
3.4.3.1.1
Deterministic Reorder
3.4.3.1.2
Stochastic Reorder Pro
3.4.3.1.2.1
Reorder Point Procedu
3.4.3.1.2.1.1 Reorder Point Procedures in SNP............................................................
3.4.3.1.3
Optimization Reorder
3.4.3.2 Defining the Source of Supply .........................................................................
3.4.3.3 Determining the Procurement Order Quantity .................................................
3.4.3.3.1
Rounding Procedures
3.4.3.3.2
Scrap Calculation ......
3.4.3.4 Scheduling the Procurement Order ..................................................................
3.4.3.5
Deployment Rules ............................
3.4.3.5.1
Fair Share Rules ........
3.4.3.5.2
Push Distribution.......
3.4.3.5.3
Deployment Order Pri
3.4.4
SAFETY STOCK ....................................................................................
3.4.4.1 Safety Stock in SNP .........................................................................................
3.4.4.2 Extended Safety Stock Methods.......................................................................
3.4.5 TARGET STOCK LEVEL ........................................................................................
3.4.5.1 Target Stock Level in SNP...............................................................................
3.4.6
DAYS SUPPLY.......................................................................................
3.4.6.1 Days Supply in SNP........................................................................................
3.4.7 SUPPLY CHAIN MODEL AND PLANNING VERSION ..............................................
Contents

3.4.8
REQUIREMENTS STRATEGIES ...............................................
3.4.9
PRODUCTION STRATEGIES ...................................................
3.4.10
PLANNING LEVELS ...............................................................
3.4.11
PRIORITIES............................................................................
3.5 RESOURCES AND CAPACITY CONSUMPTION........................................................
3.5.1
RESOURCES ..........................................................................
3.5.1.1
Bucket Resources .................................................................
3.5.1.2
Time-Continuous Resources ................................................
3.5.1.3
Mixed Resources...................................................................
3.5.1.4 Standard Capacity and Capacity Variants.........................................................
3.5.1.5
Definitions.............................................................................
3.5.1.6
Capacity Determination .......................................................
3.5.2
PRODUCTION PROCESS MODEL............................................
3.5.3
CAPACITY CONSUMPTION CALCULATION ...........................
3.6 FORECAST DATA FLOW.........................................................................................
3.6.1
FORECAST CONSUMPTION....................................................
3.6.2 FORECAST KEY FIGURES......................................................................................
3.7 OPTIMIZATION IN APO .........................................................................................
3.7.1
THE SNP OPTIMIZER .............................................................
3.7.1.1
The Decision Space...............................................................
3.7.1.2 The Cost and Penalty Model .............................................................................
3.7.1.3
Constraints and Feasibility....................................................
3.7.1.4
The Model Size ....................................................................
3.7.1.5 Optimization at Aggregated Level ....................................................................
3.7.1.6
Optimization Time Buckets .................................................
3.7.1.7 The SNP Optimizer Modes ...............................................................................
3.7.1.7.1
Continuous Optimization .....
3.7.1.7.1.1
Hard Prioritization.................
3.7.1.7.1.2
Product Decomposition.........
3.7.1.7.1.3
Time Decomposition.............
3.7.1.7.2
Discrete Optimization ..........
3.7.1.7.2.1
Product Decomposition.........
3.7.1.7.2.2 Cross Period Lot Sizing ..............................................................................
3.7.1.8
The Planning Run.................................................................
3.7.2 THE DEPLOYMENT OPTIMIZER.............................................................................
3.7.2.1 The Deployment Optimizer Parameters............................................................
3.8
DOCUMENT FLOW ......................................................................................
3.8.1 SNP ORDER CATEGORIES ....................................................................................
3.8.2 TRANSPORTATION ORDER CATEGORIES ..............................................................
3.8.3 INTER MODULE DATA FLOW ...............................................................................
3.9
COLLABORATIVE PLANNING .....................................................................
3.9.1 COLLABORATIVE SUPPLY AND DEMAND PLANNING ...........................................
3.9.2 COLLABORATIVE TRANSPORTATION PLANNING .................................................
3.9.3
COLLABORATIVE PROCUREMENT ........................................
Contents

3.9.4

VENDOR MANAGED INVENTORY

274
3.9.4.1 Special VMI Functionality
275

3.10 SUPPLY CHAIN MONITORING

278
3.10.1 EXCEPTION BASED MANAGEMENT
278
3.10.2 SUPPLY CHAIN INFORMATION RETRIEVAL
287
3.10.3 NOTES MANAGEMENT
287
4 PREPARING.......................................................................................................................289
4.1 THE PLANNING ENVIRONMENT
290
4.1.1 THE SDP PLANNING ENVIRONMENT
292
4.1.1.1 Order Categories
294
4.1.1.2 Category Groups
294
4.1.1.3 Planning Area Environment
295
4.1.1.4 Characteristics
305
4.1.1.5 Planning Version
307
4.1.1.6 Planning Book and Data View
308
4.1.1.7 Advanced Macros
310
4.1.1.8 InfoCube
313
4.1.1.8.1 InfoCube Logical Structure
314
4.1.1.8.2 InfoCube Technical Structure
317
4.1.1.8.3 InfoCube Setup and Maintenance
319
4.2 THE DATA ENVIRONMENT
322
4.2.1 PROFILES
322
4.2.1.1 Forecasting Profiles
325
4.2.1.1.1 Forecast Profile Maintenance
328
4.2.1.2 Product Master Profiles
339
4.2.1.3 Rounding Profile
341
4.2.1.4 SNP Lot Size Profile (Transportation Lanes)
342
4.2.1.5 TLB Profile
344

4.2.1.6 SNP Optimization Profile

346
4.2.1.7 SNP Optimization Bound Profile
354
4.2.1.8 SNP Cost Profile
356
4.2.1.9 Factory Calendar
358
4.2.1.10 Time Stream
359
4.2.1.11 Transportation Method
361
4.2.1.12 External Cost Function
363
4.2.1.13 Hierarchy Structure
364
4.2.1.14 Requirements Strategy
369
4.2.2 GENERAL MASTER DATA
371
4.2.2.1 Location
373
4.2.2.2 Product
383
4.2.2.2.1 Global Product Master Data
388

Contents

4.2.2.2.2 Location Specific Product Master Data .........................................................

4.2.2.3
Resource........................................................
4.2.2.3.1
Resource Header ..........................................
4.2.2.3.2
Resource General Data..................................
4.2.2.3.3
Resource Planning Parameters......................
4.2.2.3.4
Resource Standard Capacity ........................
4.2.2.3.5
Resource Downtimes ...................................
4.2.2.3.6
Resource Characteristics ..............................
4.2.2.3.7
Resource Short Texts ....................................
4.2.2.3.8
Resource Definitions.....................................
4.2.2.3.9
Resource Capacity Variants ..........................
4.2.2.4 Production Process Model (PPM).....................................................................
4.2.2.4.1 SNP Plan/PPM Data Panel.............................................................................
4.2.2.5
Transportation Lane ......................................
4.2.2.6 Transportation Lane Mass Maintenance ...........................................................
4.2.2.7
Quota Arrangement.......................................
4.2.2.8
Hierarchy........................................................
4.2.3 COST DATA MAINTENANCE .................................................................................
4.2.3.1 SNP Cost Maintenance (Directory) ..................................................................
4.2.3.2
SNP Cost Maintenance .................................
4.2.4
ALERT MONITOR DEFINITIONS ....................................................................
4.2.4.1
Settings..........................................................
4.2.4.2
Automatic Messaging ...................................
4.2.4.3
Alert Type Prioritization ...............................
4.2.4.4
Alert Profile Allocation..................................
4.2.5 MODULE SPECIFIC MASTER DATA.......................................................................
4.2.5.1
Characteristic Value Combinations................
4.2.6 MODEL AND VERSION MANAGEMENT .................................................................
4.2.6.1
Supply Chain Engineer .................................
4.2.6.1.1 Supply Chain Engineer Work Area................................................................
4.2.6.1.2 Supply Chain Engineer User Settings ............................................................
4.2.6.2
Work Area.....................................................
4.2.6.3
Logical View.................................................
4.3 THE TRANSACTION ENVIRONMENT .....................................................................
4.3.1 TIME BUCKET BASED TRANSACTIONS.................................................................
4.3.2 ORDER BASED TRANSACTIONS ............................................................................
4.3.3
OPERATION BASED TRANSACTIONS ............................................................
5 PERFORMING.......................................................................................................

5.1
INTERACTIVE TRANSACTIONS ....................................................................
5.1.1
SDP INTERACTIVE PLANNING......................................................................
5.1.1.1 SDP Interactive Planning SNP Data View........................................................
Contents

5.1.1.2 SDP Interactive Planning TLB Data View

562
5.1.1.3 SDP Interactive Planning Alert Monitor
567

5.1.1.4 SDP Interactive Planning Notes Management

568
5.1.1.5 SDP Interactive Planning Heuristics
569
5.1.1.6 SDP Interactive Planning Capacity Leveling
570
5.1.1.7 SDP Interactive Planning Optimization
571
5.1.1.8 SDP Interactive Planning Deployment Heuristics
574
5.1.1.9 SDP Interactive Planning Transport Load Builder
575
5.1.1.10 SDP Interactive Planning DP Data View
575
5.1.1.10.1 SDP Interactive Planning DP Univariate View
583
5.1.1.10.2 SDP Interactive Planning DP MLR View
589
5.1.1.10.3 SDP Interactive Planning DP Composite View
591
5.1.1.11 SDP Interactive Planning Promotion View
593
5.1.2 PROMOTION PLANNING INTERACTIVE PLANNING
600
5.1.3 TLB INTERACTIVE PLANNING
600
5.2 BACKGROUND TRANSACTIONS
602
5.2.1 SNP HEURISTICS
602
5.2.2 SNP OPTIMIZATION
604
5.2.3 DEPLOYMENT HEURISTICS
606
5.2.4 DEPLOYMENT OPTIMIZATION
608
5.2.5 TRANSPORT LOAD BUILDER
611
5.2.6 EXTENDED SAFETY STOCK CALCULATION
613
5.2.7 KEY FIGURE RELEASE AND ORDER CONVERSION
617
5.2.7.1 Forecast Release to SNP
620
5.2.7.2 Time Series Transfer
622
5.2.7.3 Conversion of SNP Orders
624
5.3 SCHEDULED BACKGROUND TRANSACTIONS
627
5.3.1 DP SCHEDULED BACKGROUND TRANSACTIONS
627
5.3.2 SNP SCHEDULED BACKGROUND TRANSACTIONS
632

5.4 COMMON UTILITY POP-UP WINDOWS

634
5.4.1 MULTIPLE SELECTIONS
634
5.4.2 TABLE SETTINGS
637
5.4.3 CHOOSE VARIANTS
639
5.5 UTILITY TRANSACTIONS
640
5.5.1 SELECTION MAINTENANCE
640
6 EVALUATING....................................................................................................................643
6.1 INTERACTIVE EVALUATING
644
6.1.1 SUPPLY CHAIN COCKPIT
644
6.2 REPORTS AND LOG FILES
652
6.2.1 SNP OPTIMIZER LOG
652
6.2.2 SNP OPTIMIZATION RESULTING COST
653

Contents

6.2.3
DEPLOYMENT REPORT .........................................................................................
6.3
GRAPHICAL DISPLAY ............................................................................................
6.3.1 STANDARD GRAPHICAL DISPLAY ........................................................................
6.3.2 ADVANCED GRAPHICAL DISPLAY........................................................................
6.4
LIST MAINTENANCE ..............................................................................................
7

RESOLVING ..........................................................................................................

7.1
7.1.1
7.1.1.1
7.1.1.2
7.1.1.3

ALERT MONITOR ...................................................................................................

ALERT LIST ..........................................................................................................
Forecast Alerts ..................................................................................................
SDP Alerts.........................................................................................................
TLB Alerts ........................................................................................................

INDICES..................................................................................................................

8.1
8.2

INDEX OF GRAPHICS..............................................................................................
INDEX OF TABLES ..................................................................................................

Preface

1 Preface
1.1

Covered Areas

The APO system is grouped into three planning areas, each linked to one or multiple modules.
They are listed below.

Supply and Demand Planning

This planning area, which is covered by this book, consists of the Demand Planning (DP) and
Supply Network Planning (SNP) modules of APO.

Manufacturing
The Manufacturing planning area is covered by the Production Planning and Detailed
Scheduling module of APO. A separate book covering specifically this area is under
development.

Order Fulfillment
The modules Global Available to Promise (G-ATP) and Transportation Planning and Vehicle
Scheduling (TP/VS) make up this planning area. A separate book covering specifically this
area is under development.

Since the APO Knowledge Bank is process rather than module driven, a lot of information
supplied in this book is of equal importance to those interested in the other planning areas and
modules.

1.2

Concept

The APO Knowledge Bank is a totally new concept of gathering information and staying up -todate with APO. The majority of information available from other sources concentrates on the
technical ability to perform a given task assuming the user knows precisely what the business
background is. Some other sources of information focus on business processes to such an extent
that the novice user, specifically, has no chance to link this theory to an activity on the APO
system. Consequently, the aim of the APO Knowledge Bank is to provide the knowledge required
to understand and operate the system. It does not just provide technical information on how to
carry out certain tasks using APO but it is also provides the background information required to
understand these activities.
The current APO Knowledge Book is the printed version of the APO Knowledge Bank. It includes
all main streams of the UPPER-1 Approach (see below) but excludes the Interactive Learning
stream with the exercises. Any reference to the APO Knowledge Bank can be seen as a reference
to the APO Knowledge Book.

Preface

10

The APO Knowledge Bank covers all aspects from long-term strategic planning right through to
operational planning. The scope includes, from a functional point of view, the five major modules
Demand Planning (DP), Supply Network Planning (SNP), Production Planning / Detailed
Scheduling (PP/DS), Transportation Planning / Vehicle Scheduling (TP/VS), and Global
Available-to-Promise (G-ATP).
The target industry type is the Discrete Manufacturing Industry including those operating in a
repetitive mass production environment. This does not imply that the information contained in the
Knowledge Bank is not suitable for other industry types that work in similar environments.
Typically excluded are all processes and functions in APO that are focused towards a single
industry type (e.g. Automotive or Oil & Gas).
Although not a technical requirement of APO, the assumption is that APO is used in conjunction
with an R/3 system.
The current version of the APO Knowledge Bank covers the APO releases 3.0 and 3.1. All texts
that relate to the APO release 3.1 only are marked with the
pictogram.

1.3

The UPPER-1 Approach

Working with any business software requires a sound understanding of its underlying model and
principles, the ability to define the right parameters, data and last but not least the ability to
perform all required tasks. Traditional On-Line Transactional Processing (OLTP) systems allowed
for a large portion of users to perform required tasks without really understanding the entire
system and the impact of their actions. It was not really required for a sales order-capturing clerk
to understand the whole Sales Order process. This is not the case with an Advanced Planning and
Scheduling (APS) system like APO. It is, for example, very important for the planner in the
Rough- Cut planning area to not only understand the results of his or her planning activities but
also to see the possible impact of this planning result on activities further downstream like in
Production Planning or in Deployment. The emphasis shifts more and more from a repetitive
mechanical Doing to a conceptual Thinking.
Exception Based Management, another core element of APS systems, can only be introduced to
environments where individuals, who understand the cause of the exception very well, manage the
exceptions. Only then they are in a position to find a solution for it.
This functional job enrichment needs to be accompanied by new ways of preparing and training
the individual users and keep them at the appropriate level of knowledge at any time. If this
cannot be guaranteed the introduction of APO, or any other advanced planning and scheduling
system, will not provide the possible and desired benefits. The system is potentially a sleeping
functional giant not mastered by anyone in the organization.
The traditional approach to training and employee empowerment focuses more on the technical
abilities required to use the system (the Doing) and the transfer of information (the Knowing)

Preface

11

rather than on the conceptual aspect of mastering the whole process and system (the
Understanding). Working with APO requires the individual to be more self-motivated and selfexploring. Training provided to a user is only one way of empowerment and needs to be
accompanied by self-studies in an ever faster changing world. These self-studies can be motivated
and supported by companies via learning circles (workshops) and the provision of the required
tools. Books as well as other documentation in either paper or electronic format provide an
excellent possibility to increase own knowledge and capabilities. It is the individuals task to
transform this Knowledge into Understanding for the own benefit (personal market value) and that
of the company (competitive edge). It is this principle that led to the development of the unique
UPPER-1 Approach upon which this book is based.
In order to support the learning process, learning materials need to cater for the specific learning
requirements by being structured in the appropriate way. The UPPER-1 Approach emphasizes on
the five main streams required to carry out the day-to-day tasks and supports each of them in an
optimal way by providing the required knowledge. An additional support stream (My First Plan)
concentrates on helping the First-Time-User to get a head start optimally supporting the
knowledge transfer for these five main streams.
The five main streams supported by, and incorporated into the UPPER-1 approach as well as the
support stream are listed below.

Understanding the Business Model

Preparing and Setting up the System
Performing the Planning Task
Evaluating the Results
Resolving Conflicts
My First Plan

Preface

12

The information provided is arranged according to this Five-Plus-One-Stream-Model. It is equally

suited to make the user not only perform the day-to-day tasks well but also to develop initiative
based on a sound understanding of the underlying principles of the APO system.

nderstanding
the Business
Model
aimed at and
all those
readers
who want
what is happening
behind
theis scenes
actively
contribute
to toa understand
successful
implementation and/or usage of the system. It is of utmost importance to understand the
system thoroughly before attempting to align the companys requirements with the

systems abilities. Too often a misalignment can be seen and valuable time and money is spent on
adding functionality to a system that is actually present if one only knew! This also applies to
misunderstood functionality, where certain system functionality is used for tasks it is not intended.
Understanding the Business Model empowers the reader to better evaluate the system
functionality and align it with the business requirements. At the same time it will open the readers
eyes to new functionality and business principles not thought about before. To this extent it
supports a Package Enabled Reengineering (PER) process.

Pr eparing and
up the
Systemsystem
deals with
all (parameter
tasks that are
required
terms of master
data
setupSetting
as well
as initial
setup
and
profileindefinition).
It is thus
subdivided into the areas of initial setup and ongoing master data maintenance. As we
shall see, there is not always a clear line between these two

areas, what is master data maintenance for the one implementation might be an initial once-off
task for the other. Master data as well as system parameters are aimed towards enabling a process
in a predefined way. For this reason there are lots of cross-references between this data orientated
section and the following process orientated section. Data is meaningless without a process and
processes are impossible without data. In this section we shall also find guides for hands-on
activities showing how to define the master data, system profiles and parameters. These guides
come in very handy for all those who occasionally need to know where and how to define all data
that is required for a certain process.
Various pointers provide information about the usage of the described master data elements. This
is vital as not all data defined on the system is consistently used by all applications and/or
modules.

Pe

rforming
the Planning
deals planning
with the individual
processes,
which
are carried of
outthe
on
the system.
TheseTask
mainly
tasks require
a good
understanding
underlying principles and business models, which are the subject of the first section
(Understanding the Business Model). In order to achieve the desired result, the

process must be based on a correctly and fully maintained master data, which is the subject of the
second section (Preparing and Setting up the System). Cross-references from this section to the
other afore mentioned sections make it easy to achieve the desired planning result.

Various process flow diagrams provide helpful guidance not only on individual planning processes
but also on the whole picture. Crucial data for each process is pointed out together with
descriptions that allow putting the individual function in perspective with regards to the whole
planning task. The planning step is the initial task of the three day-to-day operational tasks of:
performing-evaluating-resolving. Often this task is carried out as a background task, which is then
evaluated by the planner. Equally important to this background planning task is the as-and-whenrequired individual interactive planning. The interactive planning method is used in specific

Preface

13

circumstances as determined by the planner. In both cases (background and interactive planning)
the next step is the results evaluation dealt with in the next section.

valuating the Results requires the highest degree of system understanding, as the planner needs to
be in a position to fully understand the drivers behind the planning results. Even or maybe
specifically if, using optimization routines, the planner needs to have a clear vision of what the
results in broad terms should be. If the result is not in accordance with

the planners ideas, it is left to his or her judgment to check the underlying data model and system
settings, which could have a big impact on the realized result.

The result evaluation can be a follow -up step carried out after a batch planning run or an integral
part of an interactive planning task. In both cases the process and the tools used are the same.

esolving
Conflicts isplanning
the finalmethods
step of(Heuristics),
any planning
Conflicts
inherent
using repair-based
butactivity.
can obviously
alsoare
occur
when when
using
optimization routines and not enough resources are available. While the latter type of
conflict might be mathematically solved through the cost/penalty setup, it is still

advisable to monitor these situations and potentially interact with the system to resolve the
situation in a case-specific manner.

Conflicts can also be highlighted by alerts with their predefined threshold values. This process,
also referred to as Exception Based Management, requires a sound setup of threshold values,
which is part of the system setup and preparation. Consequently, the planner needs to find suitable
actions to overcome the conflicts or at least forward the conflict impact to other interested internal
and external parties.

MyItFirst
Plan, step-by-step
classified as exercises
a support outlining
stream, focuses
on the
first
planning
steps to
a user
is
likely to perform.
provides
firstly the
tasks
that
are required
set up
the required master data for a planning task. Secondly it shows the basic functionality of the planning
step. The environment the user builds up in these exercises can be easily used for further self studies.
They provide a head start for all those new in the APO

environment or maybe only new to a certain area of APO.

The thorough study of all sections is crucial, and depending on the individuals task one or the
other section of this electronic book will serve as an ongoing source of information and
reassurance while working with APO. Those involved in an APO implementation will concentrate
more on sections one and two, while those busy as users of the system will find sections three
through to five very handy to support their daily duties. Thus the information is not intended to be
absorbed in one long session, but it should be applied during daily workings.

1.4

Feedback

Somebody who is truly working with an APO system and knows what it requires to set up such a
system successfully wrote this book. It is therefore based on real experience in the Supply Chain
Management discipline rather than on generic knowledge. Should anybody have any further
question regarding Supply Chain Management issues, APO in general, or about this book in

Preface

14

particular, I would be more than happy to help as much as possible. I can be contacted using the
following e-mail address:
apohelp@square-one.com
It is my intention to complement this book with another edition that will cover specifically the
Manufacturing environment. Providing me with your feedback will allow me to concentrate even
more on topics of general interest. I encourage you to do so to help me giving the APO community
with the most valuable information possible.
This book is not meant to be a replacement for qualified training.

Introduction

15

2 Introduction
2.1

APO Planning

In order to discuss the subject Planning agreement is required on some terminology. There is
also a lot of conflicting information and terminology available dealing with this subject in a
generic non-APO specific way. We will find that the same terms are used for different subjects or
activities and the same task has different names depending on the author of the document. It is not
our intention to add a new set of definitions and terms. Explained underneath are the terms we
decided to use.

Supply Network Planning

Supply Network Planning is a tool to develop a rough-cut long and medium-term production,
transportation, and procurement plan. An integral part of this step is in most cases the
optimization of the network load, which provides a first high-level plan about expected
material and capacity requirements.
Production Planning
Production Planning takes over the rough-cut planning from SNP per location and further
refines or redefines the scheduled dates and times to derive the finite production schedule. It
is the last planning step before the production is carried out.
Detailed Scheduling
Detailed Scheduling is integral part of the production planning process and is either carried
out together with the production planning step or additionally, afterwards as part of a
rescheduling exercise.
Transportation Planning
Transportation Planning is the name of the high-level process that deals with all tasks and
procedures that are required to move products from one location to another. This includes not
only all tasks but also all planning horizons. The process Transportation Planning is carried
within APO using various transactions that are allocated to different APO modules.
Distribution Requirements Planning
Distribution Requirements Planning, also referred to as Distribution Resource Planning, is a
subset of Supply Network Planning dealing specifically with the Transportation Planning
tasks.
Deployment
Deployment is the short-term planning tool that compares (expected) available supply with
demand at downstream locations. It provides a first short-term overview of products that need
to be transported between locations.
Transport Load Builder
Transport Load Builder is a tool used specifically to replenish own or VMI locations from
upstream locations. It focuses primarily on filling the transport media in an optimal way even
if that leads, within limitations, to early or late delivery. It is part of the operational planning.
Vehicle Scheduling
Vehicle Scheduling is used where sophisticated operational transportation planning is
required. It supports functionality that is primarily required in sales order related deliveries.
This

Introduction

16

includes multi-pick, multi-drop, and roundtrip capabilities. It focuses primarily on delivering

in time even if that leads, within limitations, to transport media that are not filled to their
maximum capacity. It is part of the operational planning.
Carrier Selection
Carrier Selection focuses on the selection of the best carrier for a given transport requirement
as defined in the previous steps. The carrier selection process works together with the carrier
service contract management and shipment costing processes. It is part of the operational
planning.

Equally challenging is the definition of the various orders created by APO. Whoever has read
more than one APO document will remember to have seen a multitude of names of the same type
of order or the same name used for different types of order. There are planned orders for
transportation, transportation orders, SNP transportation orders, transport orders (with or without
the prefix planned), purchase requisitions for stock transport orders, and even transfer orders.
Again, in order to speak a common language, we decided to use the following terminology and we
hope we did this as consistent as humanly possible. These are the definitions as used in this book:

Planned Production Order

APO creates two very different planned production orders. The first one is the SNP planned
production order, also referred to as the planned order or SNP order, which is the output in
terms of planned production of the SNP planning step for the mid to long-term horizon.
The second one is the PP/DS planned production order, which is created by the PP/DS
module. It reflects the finite scheduled production plan.
The SNP planned production orders are all such orders that are created by the SNP
module of APO. They can be seen in an R/3 system as planned orders. They refer to
the APO order category EE.
PP/DS planned production orders are all such orders that are created by the PP/DS
module of APO. They can also be seen in an R/3 system as planned orders. They refer
to the APO order category AI.

Production Order
The production order most of the times is a converted PP/DS planned production order,
although it can also be created manually in an R/3 system. From a process point of view, a
production order is created close to its execution and should, once created, not be subject to
normal planning activities. This does not mean that it could not be rescheduled if required.
Production orders are finally released before production commences.
Production orders are finite scheduled orders, which were converted from planned
production orders. They can be seen in an R/3 system as production orders. They refer
to the APO order category AC (created production order) and AD (released production
order).

Distribution Order
The distribution order is a generic description of an order that is related to the distribution of
products. It does not stipulate a relation to any specific planning horizon or tool used when
creating it. It can be seen as a group name for all other order descriptions below. Any
distribution order has two legs, the one at the receiving location where it represents a supply,
and the other at the sourcing location where it represents a demand.
The distribution order does not refer to any specific APO order category, as it is a generic
term.

Planned Transportation Order

Planned transportation orders are created by the SNP and/or distribution requirements
planning steps in the mid to long-term horizon. The PP/DS module also creates planned
transportation

Introduction

17

orders, but for the short-term horizon. They are both used to describe internal replenishment
orders and can also be created manually.
The two legs of the (SNP) planned transportation order refer to the APO order categories
EA (receiving location) and EB (sourcing location).
The two legs of the (PP/DS) planned transportation order refer to the APO order
categories AG (receiving location) and BH (sourcing location).
Deployment Order
Deployment orders are created only by the deployment run in the short-term horizon. They
are used to describe internal replenishment orders.
The two legs of the deployment order refer to the APO order categories EF (receiving
location) and EG (sourcing location).
TLB Order
TLB (Transport Load Builder) orders are created only by the TLB run as part of the
operational planning. They are used to describe internal replenishment orders and can also be
created manually.
The two legs of the TLB order refer to the APO order categories EI (receiving location)
and EJ (sourcing location).
VMI Sales Order
VMI (Vendor Managed Inventory) sales orders are created by APO as part of various
planning steps. They are based on forecasts and/or stock levels maintained at a customer VMI
location. While being created in the APO planning system they are also created in the OLTP
(R/3) system as sales orders. There is no distinction between the previously discussed
normal distribution orders and the VMI sales orders at the receiving location. At the
sourcing location a distinction can be made between SNP, deployment, and TLB VMI sales
orders.
The VMI sales order does not refer to any specific APO order category, as it is a generic
term.
Planned VMI Sales Order
Planned VMI sales orders are created by the SNP and/or distribution requirements planning
steps in the mid to long-term horizon. They can also be created manually.
The two legs of the planned VMI sales order refer to the APO order categories EA
(receiving location) and ED (sourcing location).
Deployment VMI Sales Order
Deployment VMI sales orders are created only by the deployment run in the short-term
horizon.
The two legs of the deployment VMI sales order refer to the APO order categories EF
(receiving location) and EH (sourcing location).
TLB VMI Sales Order
TLB VMI sales orders are created only by the TLB run as part of the operational planning.
They can also be created manually.
The two legs of the TLB VMI sales order refer to the APO order categories EI (receiving
location) and EK (sourcing location).
Shipment Order
The shipment document, created by the TP/VS module, contains all information required to
ship the goods including shipment stages, means of transport, and assigned carriers. It is a
container document, which incorporates other documents such as delivery documents
(outbound shipments) or advance shipment notifications (inbound shipments).

Introduction

2.2

18

Supply Chain Management in Perspective

In a highly competitive market, efficient Supply Chain Management is no longer just a way to
improve the overall profitability of an enterprise, but it becomes more and more a prerequisite for
those companies that want to remain in the market. Up to some years ago, the majority of
enterprises focused on the optimization of internal processes. While this possibly provided an
optimum for the specific entity, the overall efficiency of the supply chain starting at the vendor
and going right through to the customer was not considered and in the worst case was even
negatively affected by these activities. Optimizing one element of the supply chain certainly
increased the elements overall efficiency but sometimes negatively affected the overall efficiency
of the entire supply chain. Striving for local optima was quite often the only possibility. Powerful
software and hardware was either not available or out of reach from a financial point of view.
Reduced cost for hardware and software as well as an increased awareness for this problem
resulted in the advent of powerful yet more affordable solutions. Supply Chain Management right
now is one of the fastest growing areas within the area of business software and with increasing
demand the cost will further decrease. This self-accelerating process is predicted to last for the
foreseeable future. Technologies like the Internet support efficient Supply Chain Management and
at the same time force companies to deploy Supply Chain Management tools more often.
Consumers nowadays demand more customized products with lower lead times. The time where
everybody drove the same type of car after waiting for it for several weeks or months is over;
consumers want their personalized car and that within a short lead-time. The challenge is to
minimize all non-value adding waiting time and to synchronize all activities within the supply
chain. This leads to a responsive and highly adaptable environment where not only the consumer
satisfaction is ensured, but where at the same time, intermediate stock holding levels and stock
obsolescence are minimized.
Efficient Supply Chain Management breaks traditional Planning Kingdoms. Companies are still
responsible for efficient shop floor planning but when it comes to the optimization of the entire
supply network; collaboration across multiple companies is not an option but a prerequisite. This
is a cultural issue that will have, by far, more of an impact on a company than the implementation
of a new ERP system, whether this is SAP or another package. The introduction of Supply Chain
Management solutions must go hand in hand with intensive Change Management activities.

2.2.1

Developments Past and Future

The first wave of streamlining the logistical process focused on the optimization of internal
processes for the supplier, manufacturer, or customer. This approach leads to savings within the
three entities but at the same time often increased costs on the other level. In a second wave, the
entities were linked and exchanged information via Electronic Data Interchange (EDI) for
example. This again reduced cost due to faster response times.
Introduction

Optimize
Link

Supplier

Optim
ize

Manufacturer

Optim
ize

Customer

Optimize

Link

Graphic 1 Supply Chain Optimization

Note that in the context of the above graphic the expression supply chain optimization refers to
the aim of perfecting, or optimizing, the supply chain and not necessarily to the usage of
mathematical optimization routines (programs).
Currently with the Supply Chain Management approach, the whole chain, from component
supply through to consumer consumption is seen as a chain that needs to be optimized across
all levels. Supply Chain Management requires powerful systems that are open to exchange data
with various other systems, thus optimizing the entire supply chain.
Supply Chain Management is an approach where data from various entities is collected,
processed, and presented in a form that supports the decision-making process. More and better
information leads to faster response times and lower stock levels thus improving customer
satisfaction and reducing the overall supply chain cost.
Which business processes or activities are part of the Supply Chain Management approach? All
processes dealing with the planning of critical raw materials and components needed to
manufacture finished products, as well as the finished products themselves, are part of the Supply
Chain Management process. This excludes the planning of any materials that do not become an
integral part of the finished product. Examples are consumables used in production (e.g. lubricants
and even non-critical components) as well as any other materials used in areas other than
production (e.g. office stationary or plant maintenance spare parts). The management of these
processes is part of Operating Resource Management, which also includes the provision of nonmaterial services such as services provided by other companies (e.g. travel, cleaning, or
maintenance). Processes that are not supported by the Supply Chain Management system are
usually carried out in the organizations ERP system and are also more frequently using exchanges
or portals.
Introduction

Manufacturing

Graphic 2 Scope of Supply Chain Management

Supply Chain Management includes all planning activities in the supply chain but excludes the
execution of the plan. The plan execution (e.g. the manufacturing process) is controlled by the
ERP system. In a typical Supply Chain Management system a production order for example is
displayed as in process but cannot be changed at this stage anymore in the Supply Chain
Management system but only in the execution system. With the final receipt of the goods, the
production order is deleted in the planning system (and certainly not in the ERP system) and the
stock figures are updated.
Supply Chain Management systems did not appear overnight. Several software vendors have
offered these systems for quite some time. Due to the hype surrounding integrated ERP systems,
the existence and importance of Supply Chain Management systems was either questioned or
just overlooked up to the mid 90s. Good examples are the products from Manugistics and i2.
From the mid 90s onwards this changed and Supply Chain Management systems were a hot
topic. While this was good news to the traditional SCM software vendors, the bad news was that
the powerful ERP software vendors also saw this market and pushed into it alongside the
aforementioned SCM software vendors. Examples of this are SAP and Oracle. Despite the fact
that both groups of software vendors offer SCM systems, their approach is radically different.
One-System Integrated Approach
Some of the ERP software vendors, such as SAP, started some time ago to develop their own
SCM packages. The approach they used is very different and can be easily explained with the
example of SAPs R/3 and APO packages. SAP R/3 contained, and to this day contains, plenty of
basic SCM functionality. Some of the SCM functionality in R/3 is absolutely adequate but
sometimes restricted by data structures that were optimized for an ERP system. In an initial step
a new SCM optimized database was defined allowing the development of efficient SCM tools.
Nevertheless, a lot of the tools available in APO actually originated in R/3. The main advantage
of this approach is the use of proven tools in a new SCM package and, what might even be more
important, the focus

Introduction

21

on and realization of an extremely tight integration between R/3 and APO. Efficient and reliable
interfaces between the systems (APO and R/3) were on the development task list from the
beginning and did not come as an after-thought.
The software vendors in this group are concentrating on functionality depth and width to compete
with those packages perceived to offer better functionality. While the main target group is still the
users of the complementing ERP packages, the offered SCM packages become more and more
mature and independent.
Two-System Best-of-Breed Approach
In this group, to which the aforementioned products from Manugistics and i2 belong, we find very
specialized SCM systems. Their claim is that they provide the best SCM functionality as SCM
specialists developed it with no specific ERP system in mind. The emphasis is on functional
excellence rather than integration with other systems. Most of the time, these systems are linked to
ERP systems by means of batch interfaces that might even have to be developed by the users
organization. Where these systems possibly score, is in the provision of highly sophisticated bestof-breed SCM tools if the user requires this. Based on the two-system approach, the user
interface and used terminology differ greatly between such an SCM package and the
organizations ERP system.
The software vendors in this group are currently engaged in easing the burden of interfacing
through standard batch and real-time interfaces for other ERP packages. The common
understanding is that the usage of two best-of-breed packages (ERP and SCM) does not
necessarily lead to a good overall solution.
Comparison
While the second group promotes a concept of bringing together best-of-breed packages, the first
group focuses on the development of an overall best-integrated package. The final result might
actually be very similar but this can only be seen in years to come. The majority of organizations
that do not require very specific and highly sophisticated functionality might well be better of
implementing one of the packages offered by the first group.

Introduction

ERP

22

SCM

ERP

Group 1

SCM

Group 2

ERP

SCM

Graphic 3 SCM Evolution Paths

2.2.2

Business and System Integration

During the last few decades we have learnt to know that only such systems that are integrated are
acceptable. Information management systems were deemed to be inappropriate if they did not carry
the integrated solution stamp. Integrated systems enable businesses to work in an integrated way.
The importance is to understand that they enable and support working in this integrated manner,
but they cannot force any business to do so. This is also the case when using information system
packages like SAP R/3 and APO. Conceptually they promote a highly integrated approach. Since
they are written based on predefined business processes, which in turn are based on best practices,
the implementing enterprise is required to follow the packages concept to a large degree. The
majority of implementation failures of standard software (SAP or others) can actually be attributed
to the failure of adhering to this principle.
To which extent can the combination of ERP and SCM, as offered by SAP with R/3 and APO,
support this integrated approach?
Business Integration can be defined as an approach where several business activities are conducted
in such a way, that the individual activities are well coordinated with each other, achieving a
continuous flow of activities which are carried out efficiently, which means free of gaps and
without redundant steps. Business integration thus achieves cost reduction and/or time saving
throughout the business process. Business processes can be carried out within a specific
organization or cross-organizational. Initially, business integration and enterprise business
integration were used as synonyms, forgetting the fact that most business processes actually span

Introduction

23

over various organizations or enterprises. This was also shown in the section Developments Past
and Future. The emergence of ERP systems went hand in hand with this idea of concentrating on
single enterprises. A primary target of these systems was the own enterprise, comprising of
either one or multiple linked companies. Even in the case of multiple companies working under
one umbrella, and on the same information system, the cross-company process integration was
very limited. The reason for this negligence was twofold. Transforming an organization into an
integrated business by means of newly defined processes and their implementation, with the help
of information systems, was and is a huge task binding a lot of resources. The second problem is
that cross-organizational business processes are even more complex and change more frequently.
Additionally, no adequate information system support was available at an affordable cost. Neither
the organizations nor the technology were ready to tackle this task.
We are now at a stage where the technology to support the cross-enterprise integration is readily
available at costs that can be justified. Specifically those companies that adopted the integrated
business approach early are now in a situation to take the next step, the cross-enterprise
integration. Business integration in this context must be seen as cross-enterprise integration. It
appears that at the moment various supply chain management systems on the market are far ahead
of that what todays organizations are ready for and prepared to use. Change management
becomes an even larger task, as it is required to coordinate processes that span various legally
independent organizations, the enterprises. While it was possible, to a certain degree, to enforce
the implementation of integrated ERP systems within an organization, it is impossible to do this
across independent organizations. Each decision in a collaborative planning process needs to be
agreed upon by all stakeholders. One can imagine the resistance of a customer providing its sales
projections of the product to the manufacturer, or that of the manufacturer providing resource
capacity data to the customer. Without having both the demand and supply projections, real supply
chain management is to a large degree pointless.
The majority of software vendors in the market claim that their supply chain management systems
are integrated. Although this claim might be questionable, it is not further discussed here. The
interesting aspect for us is to see why there appears to be a necessity for supply chain management
systems (packages) that are not integral part of the ERP system. Save to say that software vendors
still claim that the use of these packages together does not interfere with the request for integrated
systems. It is required to find a definition for integrated supply chain management systems and I
would like to suggest the following.
Integrated supply chain management systems support an integrated cross-enterprise supply
chain management planning process. They enable seamless process integration across
functional areas and enterprises, timely automatic update of all relevant data, and adapt easily
to process and organizational changes.
Cross-enterprise process integration is a difficult goal to achieve. It requires a common approach
by various enterprises to the workflow, responsibilities, and data used. Data synchronization
and/or standardization are vital for success. A key criterion for any supply chain management
system is its ability to easily adapt to changing environments. Tight integration with the
enterprises own ERP system is as important as the ability to quickly integrate new supply chain
management partners into it. If it takes a three month long project to add a new vendor to the
supply chain management system, then the system is inadequate. Whats meant here is not the
definition of a new vendor master record but the linking of the vendors ERP or SCM system to
the enterprises own one to enable cross-enterprise processes.

Introduction

24

The requirements for data exchange between systems that belong to different enterprises are also
very different compared to those for intra-enterprise data exchange between (ERP and SCM)
systems. Data translation (e.g. customer product number versus own product number) and
consistency checks (e.g. stock opening and closing balances on systems) are essential. Tight
system integration is the goal but data integrity and security are a necessity.
The timely update of data is of utmost importance in todays business world with ever increasing
demands for speedy decision-making. Timely update means in most cases real-time. Batch
updates are usually less resource intensive, therefore preferred, and adequate in some cases. While
the link to ones own ERP system should tight using real-time updates in most cases, it is quite
often required for an external partner to be linked via easier to manage batch interfaces.
It must be noted though that the synchronization of R/3 and APO data is an ongoing task requiring
human monitoring and interjection. The real-time synchronization of R/3 and APO data is much
better than solutions offered by other vendors that rely on batch updates for intra-enterprise data
synchronization.
Using the SAP APO system together with R/3 can be classified as an integrated intra-enterprise
approach, as it meets the requirements listed above. Since it is a rather new product, it sometimes
lacks the convenience of an easy process flow. This is not the result of conceptual mistakes but
rather of missing fine-tuning and cross-alignment of APO and R/3 functionality and applications.
It is also expected that all tasks, at least within the enterprise, can be performed using a common
user interface that has a consistent appearance, irrespective of the actual task. Furthermore,
identical work steps in various applications need to be triggered by the same screen symbols and
the terminology used must be consistent. It is not acceptable that the owner of a business process
has to familiarize him or herself with different user interfaces.
The SAP GUI together with a mostly consistent way of defining application screens fulfills these
requirements when working with any SAP product. This is particularly true when working with
R/3 and APO, as both utilize the same GUI. It is even possible to centrally logon to all SAP
products in one step thus eliminating the feel of working on different systems.

2.2.3

SCM Target Group

Who needs Supply Chain Management tools? The currently available Supply Chain Management
systems were designed with big companies in mind. They are, at least currently, not thought to be
appropriate for small and medium sized enterprises. Keeping in mind that Supply Chain Management
is about managing a chain of various organizations, leads to the immediate conclusion that also small
and medium sized companies are potential users of systems like APO. In this case they are an
external user of a system owned by a larger organization of whose supply chain they form part of.
Typical examples would be VMI customers or subcontractors. Supply chain management needs to
include all parties of the supply chain to be successful and specifically those partners that are important
for or critical to the business must be included irrespective of their size. Imagine a manufacturer that
requires a specific component from a small supplier with specialized

Introduction

25

manufacturing knowledge. Either the manufacturer builds up a large safety stock (which is not the
idea of efficient supply chain management) or involves the supplier in the planning process in a
very tight manner.
Besides the organization size another important criteria is the type of business or industry an
organization belongs to. A business that does not use products other than the typical office
consumables is not the typical user of a Supply Chain Management tool. Early implementers of
APO could be found in the area of Consumer Packaged Goods, Industrial Products, and the
Automotive Industry. Specifically the Automotive Industry is a fine example of sophisticated
supply chain management. Tight cooperation with vendors has been a domain of this industry for a
long time and these organizations can be seen at the forefront of the Supply Chain Management
development.
The strategy with which an organization plans and manufactures products is of less importance. As
it can be expected from a modern system, APO amongst others supports the make-to- order and
make-to-stock requirements strategies as well as various shades in between. As we will see later,
APO actually permits one to forecast the same product with more than one requirements strategy.
This is important to companies that make-to -stock for the anonymous market but at the same time
have larger orders for the same product from time to time that are done in a make-to-order fashion.

Understanding

27

3 Understanding
The section Understanding provides the required background knowledge to understand the
planning principles and the way that they are realized in APO. It empowers the reader to better
understand and evaluate the system functionality and align it with the business requirements.

Understanding

3.1

28

Process Overview

The Process Overview section provides a first high-level description of the various planning tasks
depending on their time horizon. Besides the differentiation according to the different planning
horizons, as described below, one can also distinguish the planning tasks according to their
primary focus. In this first section we shall concentrate on a general overview per planning
horizon and spend more time on the specific planning tasks that are performed in each of them.

Long-term Planning
Two main tasks constitute Long-term Planning. The creation of the unconstrained forecast in
Demand Planning is the first part. The second is its release to the aggregated Supply Network
Planning enabling a first feasibility snapshot of the long-term forecast.
Strategic Demand Planning
The strategic forecast is created in the DP module of APO. This aggregated forecast is
used primarily for strategic long-term purposes and for verification of long-term business
decisions and investments. It might also be used for budgeting purposes. It is usually
carried out on a product group level or a product aggregate level, which are planned
using monthly time buckets. Depending on the location network setup, it might even be
appropriate to combine various physical locations into location groups.
Aggregated Supply Network Planning
The long-term aggregated supply network plan is carried out based on rough-cut
planning principles. It is using SNP functionality. The definition of long-term has to be
seen in relation to the specific business requirements. There are no definite time horizons
but often the long-term horizon starts at approximately +6 months. These horizon
definitions vary greatly from business to business. What does not vary is the type of tasks
that are performed in the planning steps. Long-term planning is carried out on aggregated
levels such as product groups and resource clusters. Although the planning activities are
calculated in daily buckets, it is common to view and evaluate them in weekly and
monthly buckets. If transportation is a significant constraint in the business, the
transportation resources should be modeled and included in this planning task. The result
is a first feasibility proof of the unconstrained forecast released from Demand Planning.
Often this plan is handed back to DP for adjustment if major discrepancies between
forecast requirements and network capabilities are detected. Even if the transportation is
not a significant constraint for the business, the results of this planning step can be used
for strategic fleet planning and/or negotiations with carriers. The planning results provide
a good base for long-term contracts with carriers.

Medium-term Planning
The difference between the medium and long-term planning is the level of detail used for
planning. Medium-term planning is more detailed than long-term planning and focuses more
on single products and resources rather than product groups and resource clusters. Coupled
with a time horizon closer to the current date are smaller time buckets such as weeks or days.
Mid-term Demand Planning (Forecasting)
The mid-term forecasting is carried out on a product per location level. The usual time
bucket size is week, which is broken down into days during the release from DP,
where this planning step takes place, to SNP. Promotion planning is not part of the base
forecast.

Understanding

29

It is carried out separately on the same level and added to the base forecast before its
release.
Mid-term Supply Network Planning
The aim of mid-term SNP is still not to plan each and every product and resource but
rather to concentrate on specific strategic products and bottleneck resources. Promotion
products are part of the group of strategic products and thus it is not a contradiction to
include them explicitly as part of the mid-term planning. The rough-cut feasibility for
those important objects needs to be verified while keeping enough space for additional
products and resources that are not planned in this planning step. Network constraints are
considered on a more detailed level and the sourcing decision where to produce what is
part of this planning step. The sourcing decision will feed the production planning
activity in a consequent step and is also of importance to transportation planning. Again
the results of this planning step can be used for fleet planning and/or negotiations with
carriers. The SNP plan constitutes a rough-cut medium planning. The term medium has to
be seen in relation to the specific business requirements. Often the medium-term horizon
covers the two to five months time span between +1 and +6 months in relation to the
current date. It must again be stressed that these time definitions vary greatly from
business to business. The difference between the medium and long-term SNP planning is
the level of detail used for planning. Medium-term SNP planning is carried out in daily
and weekly buckets. Time buckets in DP do not have to have the same granularity as
those used in SNP. Weekly forecasts, for example, can be split up into daily buckets when
being released to SNP.
Sales and Operations Planning
The idea of the Sales and Operations Planning approach, which is part of the SNP
module, is to combine the two-step process of forecasting and subsequent supply network
planning into one single step. This can be achieved by having one combined database
including the forecast data and the forecast constraining elements like production and
transportation resources. The benefit is that in a collaborative process the sales and
operations people can work out a feasible plan together. Often this is carried out for a
shorter horizon that is not too far out from the production horizon. It must also be seen
that this way of forecasting requires more system resources as each forecast change needs
to be planned through all affected resources immediately to see the effects of the forecast
change.

Short-term Planning
During the previous planning steps, the emphasis was on planning the requirements upstream.
What is meant by this is that product requirements at the lowest level are propagated upstream
to a point where the product was either bought or manufactured. Short-term planning kicks in
when the required supplies are available and need to be distributed according to the previous
plan and/or more updated actual requirements. The supply is planned in a downstream
approach starting from the manufacturing or buying location through to the demanding
location. The planning is on a detailed product and location level considering transportation
lanes and methods. It is though still not the final shipment instruction but rather a tentative
allocation of supplies.
Deployment
Deployment is more short-term orientated, focusing at the horizon from +1 week to + 2
to 3 weeks in relation to the current date. SNP planning was driven by the task to match
demand and supply. Deployment focuses on the task to provide the supply that was
produced or is due to be produced in accordance with the rough-cut plan to those
locations that require it. In cases where the forecast error is low, this task should not be
too much of

Understanding

30

a problem but whenever the forecast differs from the reality Deployment needs to react
to the new demand situation, and possibly apply fair share rules or push distribution
principles. Deployment takes the transportation constraints into consideration. It is still
using bucket-orientated resources and does not carry out a finite scheduling task in terms
of individual transportation units like trucks. The Deployment functionality is part of the
SNP module.

Operational Planning
Within operational planning, all such steps are performed that finally prepare the activity that
is carried out using functionality of the OLTP system. Operational planning has two streams,
which are either production or transportation orientated.
Within the production planning environment we have two streams of activities, the production
planning and detailed scheduling activities. Production Planning and Detailed Scheduling
within APO pick up the constrained mid-term plan generated in SNP. Unlike SNP, PP/DS is
orientated towards a single plant. The result of Production Planning and Detailed Scheduling
is a feasible plan. For the task of optimizing the production order operation sequences, a
dedicated optimizer is available.
Production Planning
Production planning is primarily focused around the availability of the finished product
and the components required for the production orders. It ensures that planned
production orders are scheduled in time to balance demands and supplies at a certain
point in time. Scheduling is carried out while performing the production planning
function.
Detailed Scheduling
Detailed scheduling is primarily orientated towards capacity requirements leveling of
resources and assuring that enough capacity is available to fulfill the requirements of the
production orders. It ensures that operations and activities are scheduled in such a way
that resources are used optimally over a period of time. No orders are created by detailed
scheduling; its sole focus is the resource orientated scheduling.
Production Planning supports a Product Demand & Supply Orientated approach, Detailed
Scheduling is Resource Load Orientated. Both functional aspects are implemented in the
PP/DS module. Since Production Planning and Detailed Scheduling are highly interwoven,
not only from a system point of view but also when looking at the business process, they will
be dealt with as one topic in most other sections.
Operational planning also includes the transportation planning activities. Production and
transportation planning are activities that run in parallel, relate, and require each other.
Predominantly for internal transports (replenishment between own locations and/or VMI
sites), the TLB functionality can be used. Vehicle scheduling and the subsequent carrier
selection are focused towards the transportation of products in a sales environment.
TLB
The time horizon is within the range of days and depends primarily on the flexibility of
the warehouse and the time required arranging for the appropriate transport media. TLB
combines previously created deployment orders into groups. Each group represented by a
stock transport order refers to a transport media. Thus the main task of TLB is the
grouping of deployment orders into loads. Availability is checked within TLB on the
same level as within deployment. As TLB is still a planned movement, the final
availability check is carried out in the OLTP system. The TLB functionality is part of the
SNP module.
Vehicle Scheduling

Understanding

31

Orders handled in vehicle scheduling are short term orders predominantly based on sales
orders, but could also include replenishment orders. These orders are possibly multiproduct orders. The main emphasis is the timely delivery using external (carriers) and
internal (own fleet) transportation enablers. The shipments created in vehicle scheduling
combine individually ATP checked orders and as long as no rescheduling takes place the
availability of the product should be ensured.
Carrier Selection
Carrier selection is the last task before the product is issued and the order shipped. This
task is an operational one but could be based on long-term contracts with carriers.
Shipment costing, carried out in R/3, interacts with the carrier selection.
Operational Planning supports a Load-Route-Volume Orientated (TLB), Vehicle-RouteVolume Orientated (VS), or Carrier-Vehicle Orientated (CS) planning effort. The vehicle
scheduling as well as the carrier selection functionality is part of the TP/VS module.

Planning Support
To support the various planning tasks that deal with demand and supply matching, a
sophisticated availability check is required. The availability check function is thus not
required for the forecasting task but within; the supply network, production, and
transportation planning.
Basic Availability Check
The long and medium term demand, supply network planning and the short-term
deployment functions are all part of the SNP module and have a module-built-in
availability check. It can be described as basic but absolutely sufficient. The same applies
to the operational transport load builder planning functionality (part of SNP again). The
availability check of the operational planning carried out in the production (PP/DS)
environment is based on these simplified rules as well.
Advanced Availability Check
The task of an advanced availability check is to ensure that during the operational sales
order entry only such orders that can be supplied are confirmed. This function applies to
the sales order as well as to the follow-up delivery and shipment documents. This
functionality can be found in an own dedicated module called Global-ATP.
It is now also possible to use some of the Advanced Availability Check
functionality within PP/DS (see above). Using this sophisticated tool ensures that
production orders are created only when all components can actually be made available
in time.

As we can see above, the focus of the different planning horizons differ and can be grouped as
follows.

DP is product (group) and location focused

SNP, Long Term Transportation Planning, and Deployment are product focused

PP/DS is product/resource and location focused

TLB is product/transportation lane quantity focused

TP/VS, the operational Transportation Planning, is order focused

The graphic below provides a first overview of the planning horizons supported by the various
APO modules.
Understanding

Ope

TLB

PP &
Past

Graphic 4 Planning Horizons

Planning horizons are never exactly the same from one company to the next and they might even
differ from one product group to the next. Demand Planning for example might effect operational
planning due to last minute changes in promotions. This possible phasing in and out of functions is
symbolized by the triangles.
There might also be a wanted overlap between the rough-cut Supply Network Planning and
the finite Production Planning. In this case both planning methods share a common planning
period.
The Process Steps and results are shown in the graphic below.

Today Fut

Understanding

DP

SNP
Dep

33

U n c o n s tra in e d S a le s P la n (F o r e c a s t)
C o n s tra in e d R o u g h C u t
P ro d u c tio n & T ra n s p o rta tio n P la n
I n fin ite P la n , fe a s ib le ( a n d o p tim iz e d )

C o n s tra in e d F in ite P ro d u c tio n P la n

P P /D S

F in ite P la n , fe a s ib le S e q u e
n c e o p tim iz e d

C o n s tra in e d F in ite T ra n s p o rta tio n P la n

T P /V S
TLB

F in ite P la n , fe a s ib le
O p tim iz e d w h e n u s in g T P /V S

Graphic 5 Process Steps

The SNP planning result is only feasible if the SNP Optimizer is used or if the Heuristic based
planning was manually checked and possibly adjusted.
The Process Overview section provided a first high-level description of the various planning tasks
depending on their time horizon. Another view at the different planning steps supported by APO is
more process goal orientated rather than planning horizon or module focused.
DP
SNP
PP/DS
Deployment
TLB
TP/VS
While this view starts from the modules within APO it must be understood that this orientation
towards an APO module is not limiting. Tasks within SNP as an example might require the usage
of typical PP/DS tools and vice versa. An example would be the definition of safety stock levels
using the extended safety stock methods. They can be found within the SNP module but
immediately drive the safety stock levels in PP/DS and have an impact on deployment.
The graphic below depicts the APO module interdependencies and their relation to planning
horizons and the OLTP system.
Understanding

Historical Data

Procurement & Shipment Orders

Stock and Sales Data

APO

DP

Graphic 6 Planning Horizons and Modules

*

Please note that Deployment and TLB both belong to the SNP module although they actually
support non-SNP planning tasks in the short term (Deployment) and operational planning
(TLB) horizon.

Initially the APO functionality was described by means of modules as listed above. Lately a more
process-orientated view was introduced by SAP that groups the functions in a way that is closer to
the described planning horizon approach introduced here. The new process orientated views
according to SAP are:

Supply and Demand Planning (SDP)

This comprises the long, medium, and short term planning of DP and SNP including
Deployment as well as the operational transportation planning of TLB. This is an approach
that is more reality related than the module division but still TLB is a bit out o place. This is
for technological reasons, as TLB is embedded in SNP.

Manufacturing
The operational production planning carried out in PP/DS is the domain of the manufacturing
view.

Order Fulfillment
Most probably the least used functionality of APO, order fulfillment comprises the modules
of the operational transportation planning of TP/VS and the Global ATP module.
Starting with release 3.0 of APO this process view is being used in some areas of the system. This
refers mainly to the usage of the term Supply and Demand Planning and the common user
interface for both modules.

Understanding

3.1.1

35

Demand Planning (DP)

The aim of APO Demand Planning is to create a forecast (demand plan), which will then be used
as a driver for Supply Network Planning. Demand Planning offers a set of powerful forecasting
models and tools exceeding those within R/3. Forecast models include the well-known Trend,
Seasonal and Trend-Seasonal models, Exponential Smoothing models, and new ones such as
Causal models and Composite Forecasting. Somebody with good working knowledge of the R/3
forecasting tools and methodologies will feel at home within a short time span. What is left is to
get used to a new user interface and to some new forecasting tools. To see the impact on using
different forecast models for the same product and historical data, it is a good exercise to run
several forecasts (or planning scenarios) for the same product and store them for subsequent
comparison. APO also offers various tools to validate usability of the different models. The
underlying methodology and forecasting models are explained in detail in the section Forecasting
Methodology.
There is another similarity between APO and R/3. Flexible Planning reads data of the Information
Systems within R/3, and APO uses the Data Mart, which is in essence a scaled down Business
Information Warehouse (BW) system. The use of the data mart with the InfoCube is only one of
two data storage methods for historical data. The other method is to use liveCache.
Nothing is black and white in forecasting, and no model does really explain and predict future
requirements with certainty. The idea is to come as close as possible to a stable and reliable
demand plan. It is imperative to understand interdependencies of consumption with factors leading
to the usage (sales) of a product. Although very similar, the task to forecast sales and internal
consumption is different. Internal consumption might be caused by production and dependent
requirements of sold products, maintenance of assets with a predicted service part usage, or any
other item required to run the business (e.g. consumables). Dependent requirements of production
or maintenance orders do not need to be forecasted as this is done for the higher-level product in
which the components are used. Unplanned consumption in production on the other hand can be
subject to forecasting.
Forecasting is not a mandatory task, and a company might very well be successful without
creating any forecast. How can this be? First of all, there is the possibility to use re-order point
procedures instead of forecasts. This will work well in a world of steady demand with or without
growth and where the supply of products or components is secure in terms of lead-time stability.
In other cases, the demand might be not predictable but the supply side is characterized by short
lead times with a multitude of possible vendors. Thirdly and this is true only for time series-based
and causal models, the higher the amount of markets served and the respective market penetration,
the easier the forecast job will be. Lower sales (or product usage) in Asia might be compensated
by higher ones in Europe and vice versa. This leads to the situation described first. Never forget
that forecasting (except judgmental models) is applied statistics, and the higher the number of data
elements, the more reliable the results are.
The open nature of APO allows collaboration on forecasts with interested parties, internal and
external. Forecasts can be shared with customers and vendors long before the execution in terms
of purchase orders or sales orders takes place. Multi level planning is carried out using a top
down, middle through, or bottom up approach. Planning is consistent and supported by
aggregation

Understanding

36

factors. Version Management allows the maintenance of various planning versions by means of
copying and deleting versions.
APO did away with a lot of limitations, which can be found in R/3. Forecasting can be done on
several levels such as product groups or products (multilevel vertical flexibility), and it can be
done on virtually any organizational structure as long as it is defined in APO (multi-organizational
horizontal level). The possibility to plan for Sales Promotions is new as well. Here, an entire sales
campaign for a product or a product range can be planned individually, which adds Market
Intelligence to the forecast. Effects such as cross product cannibalization and deferred consumer
purchases can also be taken into account.
The output of the Demand Planning exercise is a realistic prediction of future demand per product,
time period, and location (either manufacturing sites with own stocks and sales, or distribution
centers). This plan is not optimized in terms of technical feasibility or profitability; it just predicts
the anticipated quantities that can be sold. It therefore represents maximum quantities, rather than
achievable throughput of the supply chain network. Constraint based optimization is the domain of
Supply Network Planning which is the next step in the process.
Demand plans can be stored in various versions, and APO allows passing multiple planning
versions from DP to SNP (and PP/DS). This is helpful when for example investigating the
feasibility of altered supply chains and/or for checking up capacity constraints before the final
forecast figures are released to the active planning version. The released forecast is seen by SNP
and PP/DS as demand elements. These demand elements are not module specific. Both SNP and
PP/DS use the same forecast demand elements.
Forecasts obviously need to be changed as and when required. This is done using the DP
Interactive Planning transaction or in batch mode. A change could also entail deleting a quantity
completely for a period. After the revised forecast was saved, a new release of the demand
forecast to SNP (and PP/DS) needs to be carried out. With the new release, the old forecast values
will be replaced with the new ones. In a separate step, a new SNP and/or PP/DS planning run
(Heuristics, Optimizer) needs to be carried out to adapt the supply plan to the changed set of
forecast data (independent requirements).
The unconstrained DP plan cannot only be released to SNP but also to an R/3 system where the
DP plan is used to create R/3 independent requirements.

3.1.1.1

Master Data in Demand Planning

Information for Demand Planning is stored in liveCache or in an InfoCube. The n-dimensional

InfoCube usually stores transaction data from R/3 or another On-Line Transaction Processing
(OLTP) system connected to APO. Additionally, some other data required by APO could also be
stored in the InfoCube. Examples of this would be a global forecast (e.g. car sales for a country)
as well as predictions of competitors sales. Various planning versions using the same historical
data allow a What-If Analysis on exactly the required level of detail. Historical data is stored in
the planning version 000.

Understanding

37

In order to populate the DP planning area (InfoCube or liveCache), no general master data needs
to be set up. This is no surprise as the DP planning area is a tool developed to store data in a data
warehouse like environment. As long as the loaded data conforms to the technical settings of the
Info Object in terms of length and type, no problems will occur. Even most Demand Planning
functions can be carried out without any general master data.
Demand Planning does not require a lot of data to be set up. The main task is the creation and
population of the planning area (liveCache and/or InfoCube). In addition to this, profiles and time
series, which are also types of master data, need to be set up before demand planning can be
carried out.

Location
Although most probably defined as a characteristic in the planning area, no location master
data needs to be set up in order to carry out demand planning. When selecting a location
during the forecasting process using the search facility, the location description is displayed if
a corresponding location master record was defined. Yet even if this is not the case, a location
can be selected using the search facility and be used in forecasting.
Location master records must be defined before releasing the unconstrained DP forecast to
SNP!
Product
Although products must be loaded into the planning area in order to perform the forecasting,
no product master data needs to be set up for the initial step of loading an InfoCube or
liveCache. Any product and/or location can be loaded into the planning area irrespective of
whether master records exist or not. When selecting a product during the forecasting process
using the search facility, the product description is displayed only if a corresponding product
master record was defined. Even if this is not the case, a product can be selected and used in
forecasting.
Product master records must be defined before releasing the unconstrained DP forecast to
SNP! The products must have the same unit of measure as the planning area unit of measure,
either as the base of unit of measure or as an alternate unit of measure.
DP BOM
The DP Bill of Material (BOM), which is actually a production process model, only needs to
be set up if dependent demands of components need to be visible during the DP planning
process. This is a rather exceptional situation, as in most cases the dependent requirements
calculation is carried out only in SNP. See the section Forecasting with Bills of Material.
Characteristic Value Combination
Characteristic Value Combinations are needed to carry out planning of demand for a certain
combination of characteristics. There is no Characteristics master record that can be updated
by the planner. Characteristics are defined together with the key figures in the planning area
as part of the initial set up. Characteristic Value Combinations are also referred to as Planning
Objects. There are two ways of creating Characteristic Value Combinations:
Mass Generation based on Historical Data
In this mode, APO creates characteristic value combinations for all combinations of
characteristics that can be found within a certain period. The period under observation
can be specified. This means that planning can be carried out on the same level as sales
were reported in the period under observation. When planning on higher levels, APO
applies distribution rules to spread the forecasted figures over the subordinate elements.
Combinations of characteristics are created in the planning area if a demand occurred

Understanding

38

anytime within the observation period. It is required to specify the planning version to be
used as a basis for the calculation of Characteristic Value Combinations.
Individual Generation
It is possible to additionally define any specific characteristic value combination for such
combinations of characteristics where no demand was reported in the period under
observation. This is required for example for any new products where no history exists.
For practical reasons, the mass generation of characteristic value combinations should be
carried out first. In a second step, all those combinations missing will be defined one by one.
Example:
Cumulated sales figures for the month July 99 are shown below. We have the two products
needles and pins, two customers Brown and Smith, and we deliver from our two locations Denver
and Atlanta. The first table contains all possible permutations with the exception of one as there
have no sales been recorded.

Product
Needles
Needles
Needles
Needles
Pins
Pins
Pins
Table 1 Characteristic Value Combination Example 1
There are no sales of the product Pins to customer Brown from our location Atlanta. This is
depicted in the table below.

Product
Pins
Table 2 Characteristic Value Combination Example 2
Running Mass Generation based on historical data in July 99 creates seven different characteristic
value combinations. The only non -existing characteristic value combination is for the
combination Pins Smith Atlanta as no demand occurred for this combination in July 99. If
we also want to plan our product pins to customer Smith from our location Atlanta we need to
manually create this combination.

Understanding

3.1.1.2

39

Characteristics Based Forecasting

The aim of Characteristics Based Forecasting (CBF) is the forecasting of products that are
manufactured in several variants. Examples of this are highly configurable products such as cars
or PCs. In order to reduce the forecasting effort, only the base product is forecasted in Demand
Planning and not each of the variants. The historical data required to perform Characteristics
Based Forecasting is stored in an InfoCube and requires the use of special characteristics as well
as a Characteristics Based Forecasting Plug-In (additional software).
Characteristics Based Forecasting is linked directly to the finite scheduling task carried out in
PP/DS. It totally bypasses the rough-cut planning carried out in SNP. It requires the use of the
Integrated Product and Process Engineering (iPPE) object, which is functionally similar to the
PPM used otherwise. The use of the PPM is not supported. Each product has several variants,
described by its characteristics. In order to use Characteristics Based Forecasting is it therefore
required to set up classes and characteristics.
Characteristics Dependent Planning (CDP) in PP/DS is not a follow-up process for Characteristics
Based Forecasting (CBF) in DP. CDP is used without creating the forecast in a CBF environment.
Although both planning functions have very similar descriptions, technically they require
different, not compatible, settings. Any APO client can only be configured to support one of the
planning functions not both.
The characteristics of a product have nothing in common with the characteristics used to describe
the planning area or InfoCube in DP and SNP. Characteristics in Characteristics Based Forecasting
are used to describe possible variants of the product. Characteristics in Demand Planning and
Supply Network Planning make up a key to read a logical data record.
Characteristics Based Forecasting is currently not part of the APO Knowledge Bank.

3.1.1.3

Forecasting with Bills of Material

In general, forecasting is carried out for finished products only. Once the finished products
forecasts have been established, they are released to SNP where the dependent demands (the
products components or raw materials requirements) are established. During the forecasting
process the planner does not have the possibility to see the impact of the finished products
forecast on the components, as the determination of these dependent demands is only carried out
later.
In some instances it might be required to view the finished products impact on the dependent
component demand immediately during the forecasting process. To achieve this it is required to
carry out a BOM explosion during the forecasting activity. A Bill of Material (BOM) describes the
quantity relation between a finished product and its components. An example would be that for
one PC it is required to have one case, one power supply and one motherboard. The moment we

Understanding

40

forecast the sales of 100 PCs the system breaks this down via the BOM explosion to demands of
100 cases, power supplies, and motherboards each. APO does not have any bills of materials but
uses the production process models for the same function. A production process model is the
combination of a bill of material with a routing (see PPM). Consequently, the required
information for forecasting with bills of material is obtained via the PPM. The PPM type used is
either D or S. A PPM of type D can only be used for forecasting with bills of material, a
PPM of type S can be used for SNP planning and forecasting with bills of material (see SNP
Plan/PPM Data Panel).
The (independent) product demand, which was forecasted, as well as the (dependent) component
demand, which was calculated using the BOM, needs to be stored in two separate key figures.
During the release from DP to SNP only one of the key figures can be used to create the
requirements in SNP. For the release, three different options exist.
1. Release of Independent Demand only
This is pretty much the standard way of Demand Planning. The product is forecasted and the
result is used to create independent requirements in SNP. The information regarding the
dependent demand in DP, which is based on the BOM used, is not carried across to SNP. Its
task was merely that of informing the planner of the impact the product forecast has on the
component demand.
During the SNP planning the dependent demands are established using the SNP type PPM.
2. Release of Dependent Demand only
In this scenario, the product is forecasted and the forecast result is used to create dependent
demand in DP. This dependent demand is based on the BOM used, and carried across to SNP
as the independent demand of the component. No independent demand for the product is
created in SNP. While the planner forecasts the product, SNP receives independent
requirements for the components.
During the SNP planning, the system only plans for the components that were established
during the DP BOM explosion. No independent requirements exist for the finished product.
3. Release of Independent and Dependant Demand
Now the demand of the product is forecasted and via the BOM explosion the dependent
demand is established. Both demands are used during the release to SNP, to create
independent requirements (for the product and the components).
During the SNP planning, the system plans for the products as well as for the independent
components. If an SNP type PPM exists for the products, dependent demands for the
components are possibly created. This would duplicate the dependent component demand! In
order to release both demands to SNP, a macro needs to be created that adds up the two key
figures for dependent and independent demand and writes the result into a new key figure that
is used for the release. In this scenario the same finished product might have independent
demands (the forecast) as well as dependent demands (via the BOM explosion).
The graphic below shows the three release options when using bills of material during forecasting.

Graphic 7 Release with BOM Forecasting

This might sound a bit complex, but going through some examples will clarify the situation.
1. Release of Independent Demand only
This is, as said, the standard forecasting procedure. We use the information about the
dependent demand just as a feedback for the planners. This information can be used by them
to judge the feasibility of their forecast. One could see this as an option for a manually created
forecast based on the judgmental approach (see Judgmental Forecasting). Since the BOM
explosion certainly requires additional system resources compared to the standard forecast
without BOM explosion, one needs to be careful whether the benefits are worth the while.
2. Release of Dependent Demand only
In this scenario, the forecast is carried out for the finished product. With the help of the bill of
material the demand of the components is established and consequently released to SNP.
Within SNP the finished product might be known, but it does not have to be this way.
Organizations that could use this type of forecasting are for example the manufacturers of
PCs. While the forecast is carried out on PC level, the components demands are released to
SNP where the manufacturing of them is triggered. With the receipt of the order for the PC,
the assembly is carried out.
Another example would be a component manufacturer (e.g. for cars, electronics, or
appliances) that receives the forecast of the finished product from the manufacturer of such
finished products (this is part of a collaborative planning effort). Based on the finished
product forecast,

Understanding

3.

42

the component manufacturer can directly see the demands for the components to be
manufactured.
Release of Independent and Dependant Demand
This scenario is useful when the bill of material contains finished products on both levels, as a
finished product and as a component. Care is required not to duplicate the demands. If
dependent demands of finished products are established in DP (as it is the case with this
option), no PPM explosion must be carried out in SNP. The other challenge is in the DP area.
The forecasts now need to be carried out on two levels. The one is the normal product level;
the other level is that representing a higher-level product, which influences the
aforementioned through the BOM explosion.
Examples are banded products in a promotion (see Promotion Planning). Quite often
normal finished products are wrapped together as one new temporary product. Any demand of
the finished promotion product immediately leads to dependent demands of the wrapped
finished products.

3.1.2

Supply Network Planning (SNP)

Supply Network Planning (SNP) is a network orientated planning approach with a view from
existing demand to potential supply. Demands are propagated right through the network. Finally
all demand is matched by either a planned production order, an internal requisition for a
transportation order, an external procurement placed on a non- specified vendor (anonymous
vendor that is not part of the supply chain model), or on a vendor that is part of the supply chain
model. Several planning methods are supported in APO.

Heuristics Planning
The Heuristics planning method basically follows the same principles as the traditional
material requirements planning. Resources are assumed to have infinite capacity and
requirements for components are created irrespective of their availability from the vendor or
own location. The system matches all demand elements (created by DP) with a supply
element not considering any constraints. The process is also referred to as Repair-based
planning. What is meant is that the planning result of the Heuristics is not necessarily
feasible and requires the planner to repair it. Repairing means the adjustment of the plan
through capacity leveling of the affected resources and ensuring the required components will
be available. Heuristics planning is regenerative planning. This means that at the start of each
planning run all non-fixed supply elements of the planned product will be deleted within the
planning horizon and then regenerated if required. The Heuristics planning can be carried out
in several modes:
Location
This option plans a product at the selected location only. If the product is required from
another location via transportation order this order will be created but not planned for at
the sourcing location. Should a PPM explosion be carried out during the creation of a
planned production order the dependent demands are created but not planned for.
Network
This option plans the selected product at all locations in which it exists. The process is
sequential, planning location by location. Should a PPM explosion be carried out during

Understanding

43

the creation of a planned production order at any location the dependent demands are
created but not planned for (as with the mode above).
Multi-Level
This option plans the selected product at all locations in which it exists. The process is
once again sequential, planning location by location. Should a PPM explosion be carried
out during the creation of a planned production order at any location the dependent
demands are created and also planned for.
Common to all modes described above is that all demands of a certain bucket are matched by
a supply element in the same bucket. The period of a bucket is a day in the standard delivered
system. Source determination is carried out based on various settings such as for example
those in the transportation lanes. Common to the Heuristics used in SNP is that they are not
customizable as is the case in PP/DS. The underlying algorithm of the SNP Heuristics does
not permit any parameterization besides the options explained above. For more information
on this process please refer to the section Reorder Process.

Optimization
Optimized planning within SNP is carried out by means of the SNP Optimizer. The SNP
Optimizer finds the cost-optimum solution based on the cost parameters defined by the
planner. Various constraints can be modeled and used by the SNP Optimizer (e.g. resource
capacity). The planning result is feasible based on the activated constraints. The SNP
Optimizer aims to match all demands by supply elements in the same bucket or buckets prior
to the demand. However it might also satisfy a demand late or not at all if the demand
fulfillment does not appear to be economical based on the cost settings. For more
information on this process please refer to the sections Reorder Process and The SNP
Optimizer.

Supply and Demand Propagation

Supply and Demand Propagation is a tool to search for feasible but not optimized solutions.
Several restrictions, such as resource capacities or quantities, are considered. Unlike all other
SNP planning methods within SNP, it uses time-series based and not order based data
structures. It is a typical interactive planning tool where different demand scenarios can
quickly be checked for feasibility. It also provides a good understanding of the possible
impact of changing resource capacities. Demand elements stored in a time series are
compared with the restrictions that are also stored in a time series. The result is a supply
quantity per period, which is also stored in a time series. This resulting supply quantity stored
in a time series needs to be converted into supply orders for further processing in SNP and/or
PP/DS. Supply and Demand Propagation is also known as Sales and Operations Planning
(SOP) as it is a tool to plan the sales (demand) and the procurement (operations) in one
process.

Multi-Level Supply and Demand Matching

Multi-Level Supply and Demand Matching (SDM) is realized within APO by using the
Capable-To-Match (CTM) algorithms. CTM allows an efficient match of demand and supply
specifically in situations with supply shortages. It can be used to create mid-term production
and distribution plans just as the Heuristics or the Optimizer planning methods. The output of
CTM is supply orders. One difference compared to the other SNP planning tools is that it can
also use the more detailed Single/Multi Activity Resources. Therefore it can consider
sequencing constraints in the resource and thereby deliver a short-term feasible plan.
Furthermore, demands can be pegged with supplies. CTM uses Constraint Based Propagation
techniques, which is a combination of traditional program logic and artificial intelligence.
Understanding

SNP Heuristics and Optimization

Using the Heuristics planning method might lead to excess usage of resources whereby the
Optimizer might opt to leave a demand unsatisfied if this is appropriate based on the cost/penalty
model. The Optimizer caters for interdependencies between products (e.g. two independent
products need to be manufactured using the same resource with limited capacity) and can also
optimize the usage of transportation lanes and methods. It performs parallel processing for all
products at the same time. The Heuristics run is performed per product even if run in batch for
various products. It performs sequential processing, product by product.
The result of both SNP planning approaches is SNP planned procurement, distribution and
production orders. SNP planning runs can change or delete only SNP orders that are not fixed.
Any other orders like deployment or PP/DS production orders cannot be changed.
SNP medium-term planning uses bucket resources of type T to represent transportation lane
and method capacities. The load of these transportation resources can be used for determining
constraints and medium-term capacity usage projections. SNP is a rough-cut planning tool and
the transportation capacity projections are on a rough-cut level as well, displaying bucketed
requirements per transportation lane, method, and day. The same transportation resource can be
allocated to several transportation lanes and methods, thus allowing a global view of
transportation capacities for a range of transportation lanes and methods (e.g. all requirements for
trucks in a certain region or within the entire supply chain model). Transportation resources
allocated to a transportation method represent method capacities and not individual units (e.g.
trucks) capacities.
The key functionality of the SNP planning methods is shown in the table below.

Method
Quantity Determination
Source location
Determination
Rough-Cut plan for
Transportation Routing
Transportation Method
Determination
Rough-Cut plan for
Transportation Method
Table 3 SNP Planning Methods

Understanding

3.1.3

45

Deployment (Dep)

Deployment in its basic approach is source location orientated with a view from possible supply to
distribution demand that was previously established, using for example the SNP Heuristics or
Optimizer. Deployment picks up SNP planned distribution orders and converts them (supply
permitting) to deployment orders. Deployment can be seen as the first preliminary step of finite
scheduling in transportation. A good quality SNP and PP/DS plan coupled with a reasonably
steady demand should make a deployment optimization (not the deployment as such) redundant.
The key advantage of Deployment optimization is its network orientation and ability to change
sourcing decisions made prior to Deployment in SNP. This capability to switch over from one
source of supply to the next must not be mixed up with what is referred to as Dynamic
Sourcing. Dynamic Sourcing is a feature at the sales order entry and/or delivery document
creation stage where, depending on parameters such as product availability or full truckload, a
source location is determined. Dynamic Sourcing is thus an ATP feature and not necessarily part of
Deployment. The deployment optimization requires a full network view to provide good results.
For this reason it is a contradiction to perform on the fly deployment optimizations for a
selected location or small range of locations, as it is often required in VMI business scenarios. The
deployment heuristic in real time mode should in this scenario provide an as good solution in a
shorter time frame.
Real Time Deployment
An extension to the Deployment approach is Real Time Deployment. With the Real Time
Deployment option, the system does not use the SNP planned distribution orders as a starting point
but rather the demand elements at target locations. They are then compared with the possible
supply elements at the source location. This planning step is similar to SNP Heuristics.
Technically, APO is initially performing an SNP Network Heuristics planning run followed by an
immediate deployment run. Deployment Heuristics Real-Time re-plans all SNP orders with a
Heuristics method. All SNP orders are deleted during this process and re-created as and when
required depending on the actual demand and supply situation. Deployment and TLB orders
remain unchanged. Care needs to be taken in the following situation.
The stock transfer horizon is set to a value equal to or higher than the pull deployment
horizon. In this case, demands at the target location can never be converted to deployment
orders, as with every deployment heuristics real-time planning run the SNP order is pushed
out again to the day after the end of the stock transfer horizon before being converted to a
deployment order. By doing so the SNP order remains out of the pull deployment horizon. To
avoid this problem, the pull deployment horizon must be set to a value greater than the stock
transfer horizon.
The output of the Real Time Deployment planning is a deployment order, if the demand at the
target location can be satisfied by supply at the source location. It is an SNP planned distribution
order, if the demand at the target location cannot be satisfied by supply at the source location. The
definition of supply can be determined very flexibly and if required different per sourcing
location. Real Time Deployment balances demand and supply at the target location, but leaves the
planning situation potentially unbalanced at the source location. This is based on the fact that Real
Time Deployment is a variation of the SNP Network Heuristics, which is not a Multi-Level SNP
planning.
The standard Deployment as well as the Real Time Deployment are both non-optimizing planning
methods that perform the planning run for exactly one sourcing location. Both Deployment
Understanding

Heuristics methods can calculate deployment order priorities. These priorities are picked up by
the subsequent TLB run to determine the shipping sequence.
Deployment Optimizer

The Deployment Optimizer is a third option that optimizes the product flow within the specified
network of locations and products as well as the usage of transportation methods. It can be seen
as an extension or special version of the SNP Optimizer. The main difference between the SNP
Optimizer and the Deployment Optimizer is that the latter creates deployment orders within the
deployment horizon and not planned distribution orders. Deployment orders are always oneproduct orders.
The result of the Deployment Heuristics and Optimizer is deployment orders (transport
recommendations).
Deployment short-term planning uses bucket resources of type T to represent transportation
capacities and shares them with the SNP plan (see above section Supply Network Planning).
The key functionality of the Deployment planning tools are shown in the table below.

Deployment
SNP Source Location
Adaptation
Source Location
Determination
SNP Transportation
Method Adaptation
Transportation Method
Determination
Caters for changed
Demand
Table 4 Deployment Planning Methods

3.1.3.1

Transportation Planning

Transportation Planning is the name of the high level process that deals with all tasks and
procedures that are required to move products from one location to another. This includes not
only all tasks but also all planning horizons. The process Transportation Planning is carried
out within APO using various transactions that are allocated to different APO modules.

Supply Network Planning

Understanding

47

Supply Network Planning is the tool to develop a rough-cut long and medium-term
production and transportation plan. An integral part of this is in most cases the optimization of
the network load, which provides a first high-level plan about expected transportation
volumes.
Distribution Requirements Planning
Distribution Requirements Planning, also referred to as Distribution Resource Planning, is a
subset of Supply Network Planning dealing specifically with the Transportation Planning
tasks (see above). There is no specific module in APO that uses the terms described here; the
functionality is part of SNP. This is true although a specific planning book exists within which
carries the name Distribution Requirements Planning. This planning book is merely another
way of presenting the SNP data.
Deployment
Deployment is the short-term planning tool that compares available supply with demand at
downstream locations. It provides a first short-term overview of products that need to be
transported between locations. Deployment is usually run in a way where it picks up and
updates the long-term transportation plan developed by DRP (which is a logical subset of
SNP).
Transport Load Builder
Transport Load Builder is a tool specifically used to replenish own or VMI locations from
upstream locations. It focuses primarily on filling the transport media in an optimal way, even
if that leads within limitations to early or late delivery. It is part of the operational planning.
Vehicle Scheduling
Vehicle Scheduling is used where sophisticated operational transportation planning is
required. It supports functionality that is primarily required in sales order related deliveries
(outbound). This includes multi-pick, multi-drop, and roundtrip capabilities. It focuses
primarily on delivering in time even if that leads, within limitations, to transport media that
are not filled to their maximum capacity. It is part of the operational planning.
Carrier Selection
Carrier Selection focuses on the selection of the best carrier for a given transport requirement
as defined in the previous steps. The carrier selection process works together with the carrier
service contract management and shipment costing processes. It is part of the operational
planning.

Equally challenging is the definition of the various orders created by APO. Whoever reads more
than one APO document will see a multitude of names of the same order (document) type or the
same name used for different types of order. There are planned orders for transportation,
transportation orders, SNP transportation orders, transport orders (with or without the prefix
planned), purchase requisitions for stock transport orders, and even transfer orders. Again, in order
to speak a common language, the following terminology is used. These are the definitions as used
in the Knowledge Bank.

Distribution Order
The distribution order is a generic description of an order that is related to the distribution of
products. It does not stipulate a relation to any specific planning horizon or tool used when
creating it. It can be seen as a group name for all other order descriptions below. Any
distribution order has two legs, the one at the receiving location where it represents a supply,
and the other at the sourcing location where it represents a demand.
The distribution order does not refer to any specific APO order category, as it is a generic
term.

Planned Transportation Order

Understanding

48

Planned transportation orders are created by the SNP and/or Distribution Requirements
Planning steps in the mid to long-term horizon. They are used to describe internal
replenishment orders and can also be created manually.
The two legs of the planned transportation order refer to the APO order categories EA
(receiving location) and EB (sourcing location).
Deployment Order
Deployment orders are created only by the deployment run in the short-term horizon. They
are used to describe internal replenishment orders.
The two legs of the deployment order refer to the APO order categories EF (receiving
location) and EG (sourcing location).
TLB Order
TLB (Transport Load Builder) orders are created only by the TLB run as part of the
operational planning. They are used to describe internal replenishment orders and can also be
created manually.
The two legs of the TLB order refer to the APO order categories EI (receiving location)
and EJ (sourcing location).
Shipment Order
The shipment order is created by TP/VS and combines one or multiple sales orders for
delivery at the same time.
VMI Sales Order
VMI (Vendor Managed Inventory) sales orders are created by APO as part of various
planning steps. They are based on forecasts and or stock levels maintained at a customer VMI
location. While being created in the APO planning system they are also created in the OLTP
(R/3) system as sales orders. There is no distinction between the previously discussed
normal distribution orders and the VMI sales orders at the receiving location. At the
sourcing location a distinction can be made between SNP, deployment, and TLB VMI sales
orders.
The VMI sales order does not refer to any specific APO order category, as it is a generic
term.
Planned VMI Sales Order
Planned VMI sales orders are created by the SNP and/or distribution requirements planning
steps in the mid to long-term horizon. They can also be created manually.
The two legs of the planned VMI sales order refer to the APO order categories EA
(receiving location) and ED (sourcing location).
Deployment VMI Sales Order
Deployment VMI sales orders are created only by the deployment run in the short-term
horizon.
The two legs of the deployment VMI sales order refer to the APO order categories EF
(receiving location) and EH (sourcing location).
TLB VMI Sales Order
TLB VMI sales orders are created only by the TLB run as part of the operational planning.
They can also be created manually.
The two legs of the TLB VMI sales order refer to the APO order categories EI (receiving
location) and EK (sourcing location).

Understanding

3.1.4

49

Transport Load Builder (TLB)

Transport Load Builder (TLB) is a planning method based on a specific transportation lane and
method. This implies that TLB plans the product flow between exactly two locations. It is based
on deployment orders that were created in previous steps. The task of the TLB planning step is to
combine previously created deployment orders without changing any of their characteristics, for
example the transportation method. Deployment orders can be pulled forward to ensure full loads
or delayed if minimum load requirements are not fulfilled, but the total deployment order quantity
as such is not changed. TLB orders are one-product or multi-product orders. The TLB run does not
consider deployment orders in the past. These orders can, however, be manually converted or
added to a transportation order.
The TLB profile minimum and maximum values are logically combined using an or relation.
This means that if any of the minimum (maximum) values is fulfilled, the load build can (cannot)
be carried out. The system ignores any minimum value if it is left blank. If for example the
minimum value should only be determined based on the weight, then the fields volume and
number of pallet positions must be left blank. Only if a TLB profile has been defined in the
transportation lane, a load can be shown in the Interactive TLB screen for weight, volume and
number of pallets. The TLB profile defines the number of pallet positions, not number of pallets.
The number of pallet positions multiplied with the stacking factor results in the total number of
pallets. The stacking factor can be defined in the product master (attributes tab) or in the product
specific transportation method (which overrules the product master definition).
If no deployment order priorities are calculated the deployment orders are allocated to TLB orders
based on the following sequence:
1. Delivery Date
2. Quantity (ascending)
If deployment order priorities are calculated the deployment orders are allocated to TLB orders
based on the following sequence:
1. Delivery Date
2. Priority
3. VMI Purchasing Group
Should all three criteria be identical, no further rule exists and the deployment orders are listed
with no specific rule for a given delivery date, priority, and VMI purchasing group. TLB orders
always inherit the highest priority of all included deployment orders. The use of deployment order
priorities has no impact on the way the TLB profile is applied.
The result of TLB is TLB orders (transport orders).
Transportation resources allocated to a transportation method represent method capacities and not
individual units (e.g. trucks) capacities. Note that the TLB profile contains capacity definitions
and constraints per unit (e.g. truck). The emphasis of TLB is the usage of the individual unit. It
does nevertheless update the transportation method resource capacity requirements.
Understanding

3.1.5

Planning with R/3 and APO

When starting to work with APO a lot of functions look very familiar to an experienced R/3 user,
although there is a whole lot of new terminology. In fact looking at R/3 release 4.5 (or higher)
shows plenty of commonality. In this section we will discuss the planning process as realized in
R/3 and compare it with that of the functionality offered in APO.

R/3 planning starts with the Sales and Operations Plan (SOP), which is an unconstrained demand
(sales) plan. It is also called the forecast. This plan is usually carried out in monthly or weekly
buckets and is also referred to as Flexible Planning. The data R/3 uses for the Sales and
Operations Plan is stored in Information Structures, which are fed by the core R/3 transactions.
The database used is not the transactional one where one would find, for example all sales orders.
The Information Structure provides an accumulated view on data and is customizable according
to individual needs.
Once the unconstrained demand plan is finalized, Independent Requirements are created. These
Independent Requirements are broken down into daily buckets and constitute the exact
production and/or transportation demand. Rough Cut Capacity Planning and Infinite Scheduling
are possible after the Independent Requirements have been picked up by the Master Production
Schedule (MPS) run, which creates planned orders. Only a subset of all materials is (or better
should be) planned using the MPS run. The MPS run creates a constrained plan as it takes
resource capacities into account or at least highlights possible resource problems. The planner
then adjusts the MPS plan to make it feasible before continuing.
The last step in this process is the Material Requirements Planning (MRP) run with the
subsequent Scheduling or Capacity Requirements Planning (CRP). This step involves all
materials that require planning. Capacity Requirements Planning (CRP) is also referred to as
Finite Scheduling.

Short Long Term

R/3 Leve

Graphic 8 Planning with R/3

Understanding

51

If we have a look at APO, not too much is different. At least at a first glance. The long term
unconstrained plan is generated in an environment called Demand Planning (DP). Data storage for
historical data is usually in an InfoCube or in liveCache. Both storage possibilities are possible
and have their distinct advantages and disadvantages, which will be discussed later. Forecast data
is always stored in liveCache. The InfoCube is very similar in function to the Information
Structures in R/3 and data is also accumulated according to individual company needs and
definitions. What is different is; the comfort with which tasks are performed, the much more userfriendly graphical user interface, and last but not least there is lots of additional functionality not
available currently in R/3. The output of this planning step is again an unconstrained plan as it is
with R/3.
In the next step, the unconstrained plan is released from DP to Supply Network Planning (SNP)
for further processing. SAP calls the input to SNP; Forecast, although the word Independent
Requirements is also used sometimes. In essence it is the same. SNP picks up these forecasts like
MPS the Independent Requirements. It then transforms this unconstrained plan into a constrained
plan during the SNP run. The big difference is that APO provides the option to not only just load
resources assuming an infinite capacity as R/3 does, it can create feasible plans and optimize them
when using the SNP Optimizer. A non-optimizing version called the Heuristics does pretty much
the same as the R/3 MPS does but on network level. Again the difference is how the planning is
carried out. Furthermore APO is really a network-planning tool, planning for the entire network in
one run and taking into considerations production and distribution. This is really a huge
difference! SNP also offers Transportation Planning and Deployment (with possible optimization).
Usually, and as is the case with an MPS run, not all products and resources will be planned in SNP.

Short Long Term

The last step for the production planning cycle is again Finite Scheduling, which is done in
Production Planning & Detailed Scheduling (PP/DS). PP/DS offers sophisticated tools far above
R/3 and allows for example the optimization of the planned order sequence to minimize setup and
tear down times. In addition to the finite scheduling of the production, TP/VS offers a
functionality that can be described as finite scheduling for transportation. The main emphasis of
TP/VS is the transportation planning of sales order related deliveries. It can though also be used
for internal replenishment tasks.
Understanding

Graphic 9 Planning with APO 1

In addition to the above-described functionality, APO offers the Capable-to-Match (CTM)

functionality. CTM is a hybrid between the SNP run and the Finite Scheduling in PP/DS. CTM
can create a finite scheduled feasible plan that requires no further refinement. PP/DS sequence
optimization might still be carried out. SNP could still be carried out, but is actually not necessary.

Short Long Term

APO Levels of Planning 2

Graphic 10 Planning with APO 2

SNP & Dep

PP/DS & TP/VS CTM

Understanding

53

As we have seen above, APO replaces the SOP, MPS, MRP, and CRP planning tasks usually
carried out in the OLTP system. Based on this there is no need to perform these activities in the
OLTP system anymore. This assumption is right and wrong; it depends on whether you plan all or
only some products in APO.
Most companies run MPS for all strategic products or other products that require special attention
during planning. These might be all products manufactured on bottleneck resources. It is good
practice to plan such products that were part of the MPS run using APO. For the remaining
products, two options are feasible.
1. All products planned in APO
If all remaining (non-MPS) products are also planned in APO no other planning activities
need to take place in the OLTP system. This might be the most elegant solution as only one
system is used to perform all planning activities. For this scenario one must consider the
additional load on APO as the number of planning objects increases rapidly when adding the
non-MPS products. It is also required to use production process models that include all
components, which will certainly slow down not only the SNP planning, but also the detailed
scheduling in PP/DS.
2. Some products planned in R/3, some in APO
Should some of the products not be planned in APO, it is required to plan them separately in
the OLTP system. This solution might be rather confusing for the planner, as the question will
always be where the product/component is planned, in APO or the OLTP system. If the
intention is to use APO for strategic products/components only, this is the option to go for.
In the above comparison the expression all products means products for which dependent
requirements should be created. Products or components that are replenished using re-order point
procedures or forecast-based procedures do not need to be planned in APO at all. The assumption,
for products planned with one of these procedures, is that there is always enough stock available
when required. An individual BOM explosion with determination of exact requirements is not
carried out for planning purposes. The BOM explosion can nevertheless be done in the OLTP
system to generate the shop floor control papers.
APO has its own Production Process Models that contain the Bill of Material and Routing data,
usually held in R/3. If a product is planned in APO, there is no need to store the bill of material
and routing data anymore in R/3, at least for the production planning purposes. If the PPM in APO
contains all data required for the execution of the planned production order in R/3, then this area
also does not need anymore the bill of material and routing to be in R/3. The problem is that we
still need this data for Costing purposes. First of all, the standard cost of the product needs to be
established (Costing with Quantity Structure). To do so the system, which is R/3, needs the bill of
material (product and component quantities) and the routing (resource consumption). During the
execution of the production order in R/3, this data is needed again to compare planned and actual
consumption to derive the deviations.
As a result, PPM information stored in APO must be duplicated in R/3 in the form of the BOM
and routing, otherwise product costing will not be possible. This is the case as long as these data
objects are not properly integrated and accessible from both systems. In my mind, the PPM data
object needs to be enriched by costing information and be made available to both, APO and R/3.
Where the PPM is stored physically is of no functional importance and must be decided based on
access considerations.

Understanding

3.2

54

Planning Sequence

The previous sections provided an overview of the various steps of planning ranging from the
long/medium-term DP and SNP planning tasks right through to the operational Vehicle Scheduling
and Carrier Selection. All these tasks need to be performed in a pre-described sequence and in a
coordinated manner. Specifically the transition from one planning step to the next needs to be
looked at carefully so that planning decisions from the previous step are not overlooked or even
negated. This is even more important when using both Heuristics and Optimization algorithms.
This section provides an introduction into the handshake mechanisms between the planning steps
considering the various options the system offers.
The evaluation is carried out in a multi-step process. Firstly we shall look at the Demand Planning
and Supply Network Planning options. This is followed by the transition from Supply Network
Planning to Production Planning and Detailed Scheduling as well as to Deployment Then in a
subsequent step we shall investigate the follow up steps of Transport Load Builder, Vehicle
Scheduling and Carrier Selection.
The list below provides an input-process-output overview for the processes from Demand
Planning through to Deployment.
Demand Planning
Input
Sales History from attached transaction processing system (e.g. R/3) or business
information warehouse (e.g. BW)
Market Information from various sources as required

Process
Batch and Interactive Forecasting including Promotion Planning

Output
Product Forecast

Supply Network Planning

Input
Product Forecast from Demand Planning
Sales Demand from the attached transaction processing system (e.g. R/3 via CIF) and/or
other systems (via batch interface)
Stock Levels from the attached transaction processing system (e.g. R/3 via CIF) and/or
other systems (via batch interface)

Process
Reads Network Demand (Product Forecast, Sales)

Output
Creates Rough Cut Network Transportation Plan (finished goods and components)
Creates Rough Cut Location Production Plan
Creates Rough Cut Location Procurement Plan

To be used in Purchasing only for long lead-time components For

other components no procurement orders should be created

Understanding

55

Production Planning / Detailed Scheduling

Input
Bucketed SNP Planned Production Orders
Transportation Demand from Supply Network Planning
Product Forecast from Demand Planning
Sales Demand from the attached transaction processing system (e.g. R/3 via CIF) and/or
other systems (via batch interface)
Stock Levels from the attached transaction processing system (e.g. R/3 via CIF) and/or
other systems (via batch interface

Process
Reads (changed) Location Demand (Product Forecast, Sales, Transport)

Output
Updates Rough Cut Transportation Demand
Creates Finite Location Production Plan
Updates Location Procurement Plan
Deployment

Input
Transportation Demand from Supply Network Planning
Product Forecast from Demand Planning
Sales Demand from the attached transaction processing system (e.g. R/3 via CIF) and/or
other systems (via batch interface)
Stock Levels from the attached transaction processing system (e.g. R/3 via CIF) and/or
other systems (via batch interface)
Finite Planned Production Orders from PP/DS
Process
Reads (changed) Location Demand
Output
Creates updated Transportation Plan

As can be seen above, the PP/DS module is not listed anywhere as the input for any other planning
step. The object of PP/DS planning is the production and once the production has been planned
and executed, stock is made available. The available stock in turn is input to basically all planning
steps except Demand Planning. PP/DS planned orders might impact other modules to the extent
that orders created in PP/DS are used as expected stock. This might be the case in Deployment
where the deployment plan can include not only stock but also expected stock in the form of
PP/DS planned orders.
The planning tools within APO can be categorized according to planning area, planning horizon,
and planning object. Each of these tools support one of the classical planning tasks that need to be
carried out in order to efficiently manage the supply chain. The following table gives an overview
of a possible network of planners with their corresponding responsibilities. This is not meant to be
the solution for any business using APO; it merely gives an idea of the complexity of a planning
hierarchy.
Understanding

Planning Area
Planning Horizon
Supply Chain

Long-term Strategic
Long-term
Mid-term
Transportation
Long and mid-term
Short-term
Operational
Operational
Production
Long and mid-term
Operational
Operational
Strategic Sourcing / Purchasing
Long and mid-term
Short-term
Operational
Demand Planning (Forecasting)
Long-term Strategic
Mid-term
Mid-term
Mid-term
Table 5 Planning Hierarchy

Understanding

3.2.1

57

Demand Planning Supply Network Planning

During the initial forecasting and promotion planning task, a plan was developed that is referred to
as an unconstrained forecast. Unconstrained, because it is not taking into consideration whether
the available resources, production and transportation, can cope with the required demand. In most
business cases, people creating the forecast already have its feasibility in mind and change the
forecast with what they think is feasible. This is common but should not be done specifically if the
SNP Optimizer is used.
The output of Demand Planning in technical terms is a forecast stored in a key figure. The time
granularity is in most cases weeks or months but could also be in other buckets or according to
fiscal year variants. The forecast from Demand Planning is released to Supply Network Planning.
In this step, the forecast is broken down into daily buckets, as this is required by SNP. How the
forecasted quantities are distributed over time depends on product master settings and the
combination of time bucket profiles used in DP and SNP. A user exit exists, which allows the
programming of different rules. The forecast in SNP is also referred to as independent
requirements.
The forecast in SNP is stored in orders and is independent of the forecast stored in DP. If for
example the forecast is changed in DP after it was released to SNP, then the SNP forecast remains
the same up to the moment where the changed forecast is again released to SNP. The system
ensures that no unwanted duplication of forecast data occurs.
Depending on definitions in the product master and settings in the requirements strategy that
might be attached to a product, the forecast can be consumed. Consuming the forecast has
various advantages, which are explained in a dedicated section. Forecast consumption though is
resource intensive. The user can monitor the forecast and its consumption situation.
APO also caters for environments where the base forecast and the promotion forecast need to be
handled independently. Both forecasts are stored, if required, in separate key figures in Demand
Planning and can be released to SNP independently. An application for this is the separate
definition of target stocks for base and promotion demand.
The separation of Demand Planning and Supply Network Planning is strict and there is no
problem to send the DP forecast to other systems or to receive a forecast into SNP that was not
created by DP. In fact, a standard interface can be found in APO to create independent
requirements in R/3 based on the DP forecast.

3.2.2

Supply Network Planning Production Planning / DS

SNP creates a mid-term plan based on a simplified PPM and bucket resources. In PP/DS, the
short-term plan is based on a more detailed PPM and time-continuous resources. The PP/DS
planning horizon, called the production horizon marks the beginning of the mid-term SNP
planning horizon. Any SNP order that enters the production horizon with at least one activity is
not planned by SNP anymore. It needs to be converted to a PP/DS order and can be subsequently
planned using PP/DS

Understanding

58

functionality. The conversion of SNP orders to PP/DS orders has to be carried out manually or via
a batch job. It does not happen automatically! During this conversion, the order is re-exploded
using the PP/DS PPM. At this time the bucket resource capacity load will be deleted, and the
PP/DS time continuous resource will be loaded with the capacity requirements. The SNP order
remains in the production horizon up to the moment that the conversion has been carried out,
which also deletes the SNP order.
SNP cannot create or change any orders (not even SNP orders) within the production horizon,
although it displays the PP/DS orders in the production horizon on an aggregated basis per day.
An exception is the SNP Optimizer that can be set to create SNP planned production orders within
the production horizon if required. Automated PP/DS processes, on the other hand, do not
(usually) create or update any orders outside the production horizon. There is also an exception,
where the PP/DS planning run can create PP/DS production orders outside the production horizon.
A new feature starting with release 3.1 is that two different horizons can be defined for the
PP/DS and SNP production horizons. This allows overlapping of the two horizons and jointly plan
a common period as long as mixed resources are used.
The planner can manually create orders inside and outside the production horizon. The PP/DS
orders outside the production horizon are considered during the SNP planning runs, but cannot be
changed or deleted by SNP. The total of SNP and PP/DS orders is displayed on an aggregated
basis outside the production horizon. Should the SNP planning run detect a product shortage
within the production horizon, it will create an SNP order directly after the end of the production
horizon, which is the start of the SNP planning horizon. This is the same principle as with the R/3
MPS run.
Some planning tasks cannot be covered by SNP at all. An example is the subcontracting process,
which is supported by PP/DS but not by SNP! The VMI planning process on the other hand can
only be carried out in SNP. This makes sense, as VMI is about the creation of special
transportation orders (VMI Sales orders), which is not a production-planning task. Some safety
stock procedures also pose a problem, as SNP and PP/DS react differently to the same settings.
The majority of master data is used by both SNP and PP/DS. Synchronizing both activities in a
proper way will be a challenge to any project team. There are endless possibilities to let SNP
interact with PP/DS and quite often these planning tasks interfere with each other. The clearer the
cut between medium- long-term SNP based rough-cut planning and short- term PP/DS finite
planning is, the easier it will be to master this task. In situations where SNP is used to plan all
products on a detailed level it will be difficult to achieve this separation.
Other Related Process Flows
The transfer of requirements from SNP to PP/DS is the most common but not only way of
creating requirements for the PP/DS module. Other possibilities exist that are either
complimentary to the process described above or replacing it. The sources for the requirements
are:

Demand Planning
In this scenario no rough-cut planning using SNP is carried out. Instead requirements are
transferred directly to PP/DS (see the section Demand Planning Production Planning /
Detailed Scheduling).

ATP

Understanding

59

During an ATP check requirements are passed through to PP/DS in order to carry out a
feasibility check (see the section ATP Production Planning / Detailed Scheduling).
OLTP
In this scenario the PP/DS module of APO is used instead of a production planning system
that might be integrated into the OLTP system. In most cases no other APO modules are used
(see the section OLTP Production Planning / Detailed Scheduling).

3.2.3

Supply Network Planning Deployment

APO offers, for the rough-cut planning, the use of the SNP Heuristics or the SNP Optimizer. For
Deployment there is the Deployment Optimizer and the Deployment Heuristics. The latter can be
switched to the Real Time Mode. All of these planning tools were discussed in detail in the
previous sections.
As various tools are available that provide similar results, it needs to be determined what the
differences are, in order to decide which method is used. In this section we will discuss the
combination of the SNP Optimizer with the various deployment tools (group 1) and then the usage
of the SNP Heuristics in conjunction with the various deployment tools (group 2).

Group 1 SNP Optimizer

The SNP Optimizer carries out a cost parameter based calculation, which determines amongst
other decisions, the best source location for each demand together with the best transportation
method. The result of the SNP optimization can be used for long to medium-term
transportation planning, as it provides a rough-cut plan of necessary transportation resources
(if linked to the transportation method). From a transportation point of view, the SNP
optimization can be redundant in environments where no dynamic sourcing decision is
possible, required, or desired (see SNP Heuristics). The SNP Optimizer can be used to create
quota arrangements that are used by the SNP and Deployment Heuristics.
Option A Deployment Optimizer
The usage of the Deployment Optimizer seems to be the next logical step when using the
SNP Optimizer. However, this is only required in an environment where the demand
situation, the possible sourcing locations, and/or the available transportation methods
(possibilities) are likely to change between the SNP and the Deployment planning
activities. If the requirement is mainly to check the transportation method, the usage of
the Vehicle Scheduling functionality should be considered. The Deployment Optimizer
can only select the cost optimal source location if the defined data environment permits
this. If for example exactly one source and one target location are selected when starting
the Deployment Optimizer, the system will only optimize timing and transportation
methods but not the source location.
Option B Deployment Heuristics
The Deployment Heuristics adheres to the SNP Optimizer decisions in terms of order
timing and quantity as well as selected sourcing location and transportation method. One
can see the Deployment Heuristic as an Order Converter that picks up all due SNP
orders and converts them to Deployment orders, as long as the Available-to-Deploy
quantity permits this. This is sufficient in cases where frequent SNP optimization runs
and/or steady demand situations prevail. As a general rule, one can assume that the more

Understanding

60

often an SNP optimization run is carried out, the more likely it is that the usage of the
Deployment Heuristics is sufficient. This, on the other hand, does not mean that the SNP
Optimization should be done frequently just to enable an accurate up-to-date deployment.
If this is a requirement and there is no other need to run the SNP Optimizer frequently,
then the use of the Deployment Optimizer is the better solution.
Option B Deployment Heuristics Real-Time
The main difference of Deployment Heuristics Real-Time compared to Deployment
Heuristics is that the Deployment Heuristics Real-Time incorporates an SNP Heuristics
run. It can thus be used in a situation where no SNP run was carried out and where the
Deployment Heuristics is expected to pick up changes in the demand situation.
Nevertheless, care must be taken if Deployment Heuristics Real-Time is used after an
SNP Optimization run. In this case the SNP Optimizer provides a cost based optimal
solution, which is virtually thrown away by the Deployment Heuristics Real-Time and
replaced by a Heuristics based (non-optimized and potentially not feasible) solution in
terms of sourcing location, transportation method and/or transportation capacity usage.
The use of quota arrangements and cost based transportation method selection can lower
this problem (see SNP Heuristics below). Nevertheless, for the reasons given above, the
combination of SNP Optimization and Deployment Heuristics Real-Time does not appear
to be a recommendable combination.
Group 2 SNP Heuristics
The SNP Heuristics carries out a rough-cut planning whereby the algorithm used pairs each
requirement with a receipt element. This algorithm does not consider available capacities
(production or transportation) and the result of the SNP Heuristics is neither optimal nor
necessarily feasible. The planning results of the SNP Heuristics usually require manual
intervention, also referred to as repair activities (repair based planning). In situations where
no optimized production planning is required and sourcing and transportation method
decisions cannot be made, the use of the SNP Heuristics is a viable option, as it not only
requires less processing time but also does not require that a whole set of cost and penalty
data to be defined and maintained. The SNP Heuristics can use quota arrangements and/or
procurement priorities when determining the source location. Furthermore, the lowest
transportation cost is used to select a transportation method but the result is still not
optimized. An optimized sourcing and transportation method decision can also be
accomplished in the shorter term Deployment planning (see below).
Option A Deployment Optimizer
Using the deployment optimizer as a follow up step after the SNP Heuristics is feasible in
situations where no sourcing and transportation method decisions need to be made at the
time of the SNP run. This might also be the case where alternate source locations can be
selected via quota arrangements or procurement priorities. The deployment optimizer can
carry out a shorter term sourcing location optimization based on the production quantity
framework of the SNP plan. It can also react to changing demands and select the optimal
transportation method and shipment times.
Option B Deployment Heuristics
As explained above, the Deployment Heuristics adheres to the SNP decisions in terms of
order timing and quantity as well as selected sourcing location and transportation
method. One can see the Deployment Heuristic as an Order Converter that picks up all
SNP orders due and converts them to Deployment orders, as long as the Available-toDeploy quantity permits this. The combination of these two tools will most probably
lead to an increased amount of manual corrections and fine-tuning.
Option C Deployment Heuristics Real-Time

Understanding

61

The Deployment Heuristics Real-Time incorporates an SNP Heuristics run. It can thus be
used in a situation where no SNP run was carried out and/or where the Deployment
Heuristics is expected to pick up changes in the demand situation. If no mid- term
production and transportation planning in SNP is required, the sole usage of the
Deployment Heuristics Real-Time can be considered. The use of manually defined quota
arrangements and cost based transportation method selection are still working. This is
coupled with an appropriate reaction to changing demand.
The results of the SNP and deployment planning steps influence the follow-up processes, TLB and
Vehicle Scheduling. TLB takes over sourcing location and transportation method as defined by the
Deployment planning step. Vehicle scheduling takes over deployment source location but can
optimize transportation method depending on the selected data environment.
When deciding which method combination is appropriate for a specific implementation, it is an
absolute requirement to consider the organizations and individual planners readiness. The use of
a highly sophisticated tool like an optimizer requires an enormous amount of preparation in terms
of cost data definition and user training. A good approach would be defining the end- solution and
a viable transition plan giving both the organization and the planners enough time to cope with the
change.
The follow-up process of deployment is either the transport load builder (TLB) or vehicle
scheduling. TLB is more geared towards internal product movements (replenishment), which
might include VMI locations where the full truckload requirement is desired. The domain of
vehicle scheduling is the cost optimal planning of deliveries to customers, which does not exclude
the planning of internal replenishments. The advantages and disadvantages of both methods are
discussed in the respective sections.

3.2.4

Deployment Transport Load Builder

In the previous section we have discussed the transition from SNP to Deployment and the various
options that exist there. The main emphasis there was to establish the coexistence of the
optimization and heuristic tools. The output of the deployment step was, irrespective of the used
methods, deployment orders. These deployment orders need be picked up by the Transport Load
Builder (TLB) functionality now. The main task in this step is to use the one-product deployment
order to create the multi-product TLB order.
The APO created deployment orders can be sent to R/3 as purchase requisitions or as purchase
orders. In order to use TLB functionality (and not TP/VS functionality instead), it is required to set
the deployment-planning step to create purchase requisitions.
Deployment orders can be created with or without priorities. Priorities are not used within the
deployment logic and their sole task is to influence the sequence of loading carried out by the TLB
run. Other than this dependency there are no touch points between deployment and TLB
functionality that require an in-depth discussion.

Understanding

62

The TLB planning step is the last possible planning activity within the APO transportation
planning in all those situations where no TP/VS functionality is used. The TLB orders are
mirrored in R/3 by stock transport orders that need to be carried out.

Understanding

3.3

63

Time Calculations and Display

In virtually every transaction, APO displays time stream data or orders and order related data with
a certain date and time. Multiple custom settings as well as system-predefined procedures drive
the date and time calculations. Calendars and time streams are used to distinguish between
working and non- working days, hours, minutes, and even seconds. Planning buckets profiles
define the planning periods for some APO applications and storage buckets profiles determine the
way data is stored.
Some of the APO transactions allow settings for the time display, others not. The situation
becomes more complex, as the locations with their corresponding orders are usually in various
time zones that might even use daylight saving time. Definitions in the user master record also
influence the time display. The possibilities seem endless and sometimes the logic behind the date
and time display is not obvious.
Before we start looking at the various time related settings some definitions and terminology
require clarification.

Time Horizon
The Time Horizon is a generic description for time duration. In most cases the horizon is
defined in days, weeks, or months. Time horizons are used to describe the length of planning
horizons or the validities of profiles.

Planning Horizon
The Planning Horizon is a generic description and defines various horizons used during the
planning activity. A planning horizon is defined by a time profile or by means of a start and an
end date complemented by the resulting number of periods (e.g. the forecast horizon). The
Production Horizon is an example for a relative horizon only specified in days starting from
the current day.

Time Profiles
The Time Profile is a generic term and groups all those profiles and profile-like definitions in
APO that are used to define time relevant data.

Factory Calendar
The Factory Calendar is also referred to as just Calendar, which causes confusion (see
further down). It is an APO term and is used to define working and non-working days. Nonworking days are for example weekends and public holidays but can also include holidays.
The lowest periodicity is the day. Calendars are linked for example to time streams.

Planning Buckets Profile

The Planning Buckets Profile, or Time Buckets Profile, is an APO term and describes the
length of a viewing or planning period (e.g. 24 periods) as well as its periodicity (e.g.
months). A special variant is the telescoping Time Buckets Profile, which has more than one
periodicity. The lowest periodicity is the day.

Time Stream
The Time Stream, or Planning Calendar, is an APO term and describes a period length (e.g. 3
years). The periodicity is always seconds. Time streams are used together with storage
buckets profiles as well as with various master data objects. There are time streams with gaps
(based on a factory calendar) and there are time streams without gaps (without factory
calendar). CTM requires the use of time streams without gaps.

Calendar

Understanding

64

Based on a time stream a calendar with specific periods is generated. The calendar specifies
the times the system uses to determine when production, transportation, etc. can be carried
out. Examples are the calendars linked to the location master or the transportation calendar of
the transportation lane.
Storage Buckets Profile
The Storage Buckets Profile is an APO term and defines the technical periods. The technical
periods determine the periodicity of the stored data (e.g. weeks). More than one periodicity
can be defined. The definitions of the storage buckets profile influence the ways time based
aggregation and disaggregating is carried out.
Time Characteristics
The Time Characteristics is an APO term. One or multiple time characteristics are used to
define the periodicity that is used to store data in an InfoCube. They serve a similar function
as the storage buckets profiles that are used in connection with data storage in liveCache.
Data storage using an InfoCube is limited to the Demand Planning module.
Time Series
The Time Series is an APO term. It describes a series of values, absolute or as a percentage,
which are related to time. Various planning tasks use these definitions (e.g. weighting groups
within Demand Planning). Distribution functions in SDP also use time series.
External Time Series
Similar to above but used to import data to or export data from APO.

3.3.1

Factory Calendars

The factory calendar is used to determine the working and non-working days and is linked
directly to some master data objects such as resources or to a time stream as well. A factory
calendar, which is also referred to as just a calendar, defined on a lower level overrules the
definition on a higher level. If for example the factory calendar allocated to a production resource
in a certain location is different to that allocated to the locations production calendar, the resource
calendar definition applies. Factory calendars are made up of the Public Holiday definition and
the Holiday Calendar. The precision of a calendar goes down to the level of day.
The term Calendar is sometimes used as a synonym for the factory calendar and in connection
with time streams.
Public Holidays
Country specific public holidays are predefined in the standard delivered system. New ones
can be added if required. Each public holiday has rules, which define for example, for
moving holidays like Easter when they take place.

Holiday Calendars
They are also predefined and are made up of country specific public holidays. Newly defined
public holidays can be added or taken off. Each holiday calendar has an ID number and can
be displayed in calendar form to give an overview. The exact amount of public holidays per
year is also displayed. Holiday Calendars as well as the assigned Public Holidays have
validity periods.

Factory Calendars
Understanding

These calendars combine the Holiday Calendar definition with individual per day definitions.
Here each day of the week is marked as a working or a non-working day. This includes
public holidays that can be set to working days as well. A Special Rules function can be used
to define, for example, factory holidays or times of extended workdays.

Public Holidays
International
January 01 USA,
July 04 - USA

Factory Calendar
S M T W T F S
June
25

26

Graphic 11 Factory Calendar

3.3.2

Time Line Definitions

Any activity can be characterized by the time it starts and its duration. Time Line Definitions deal
with the specification of periods (time duration) by means of time profiles. The final result of all
time line definitions and subsequent calculations is to determine whether a certain period is valid
(within the horizon) and whether it is working or non-working time.
Time profiles in APO are used to describe time horizons and periodicity of data. Periodicities
(time buckets) within APO can be for example day, week, month, or posting periods (based on
fiscal year variants). Possible periodicity settings depend on the planning task. Within Demand
Planning, for example, the lowest periodicity is the Day. A distinction is made between storing,
using, and displaying data. The definition of time profiles is particularly important within time
based data storage in Supply and Demand Planning. In other areas the system uses an approach
where all orders from the OLTP system are stored irrespective of time aspects.
Understanding

Data Storage Definitions

Time series based data is stored within Supply and Demand Planning in accordance with the
settings of the Storage Buckets Profile and the Time Stream. Only one storage buckets
profile can be defined per planning area. Using time streams allows the adaptation of
periodicities down to the second and the allocation of factory calendars.
The storage buckets profile defines the periodicity (or periodicities) and the number of
periods used to store the DP or SNP data. Typically the storage buckets profile for DP
contains the weeks and months periods and that for SNP days and weeks periods, which does
not mean that other settings are not possible. The defined periodicity (data granularity) is
always the same for the entire horizon, as data must be stored with the same level of detail

irrespective of the time horizon. The storage buckets profiles are also referred to as the
periodicities of the DP and SNP planning areas.

Time Profil

Storage Buckets P

With attached

Time Stream

(Planning Calend

With attached

Factory Calend

Graphic 12 Storing Data

Data Viewing Definitions

In order to view and, within Supply Network Planning, plan time series based data in a
flexible way, Planning Buckets Profiles are created. One or more planning buckets profiles
can be used in conjunction with the same planning area. In fact, the planning buckets profiles
are defined independent of any planning area. The planning buckets profile defines the
number and type of periods that can be viewed in DP, and viewed or used in SNP including
Deployment and TLB. The minimum granularity is limited by the storage buckets profile.

DP uses the planning buckets profiles to determine the periods to be displayed. Although
common, it is not required within DP to use the same planning horizons for viewing the data
in
Understanding

the planning book and performing a forecasting run. Separate planning buckets profiles are
defined in Demand Planning for the display of the historical and forecast periods. The
planner might want to see longer or shorter time horizons than those used by the planning
run. The planning buckets profiles are typically set up in a way that multiple period types
(e.g. weeks and months) can be viewed. The further away the specific period is from the
current day, the more condensed the displayed data. This method is also referred to as a
telescoping planning buckets profile.
SNP uses the planning buckets profiles to accomplish the task of planning horizon definition
for both viewing data and using it for planning runs. Combining the viewing and planning
definitions into one profile is not as flexible as DP. Telescoping planning buckets profiles are

also supported. The planning buckets profiles defined for the SNP and Deployment planning
runs determine the respective planning horizons and thus are the key factor for defining the
boundaries of long, medium, short, and operational planning. Since various time bucket
profiles can be defined and used in conjunction with different planning runs, it is possible to
use different planning horizons per planning run or in other words per product or group of
products.
Some master data objects are linked to time streams and possibly factory calendars. This
determines the master data objects availability (e.g. when the warehouse is open). Both
definitions are required in order to schedule orders during the planning activities.

Time Profile

Planning Buckets Pr

(Time Buckets Pro

Time Stream

(Planning Calenda

With attached

Factory Calenda

Graphic 13 Viewing Data

Within the manufacturing environment (the PP/DS module) the Production Horizon is
defined per single product. The production horizon is a horizon that determines the horizon

Understanding

68

covered by the PP/DS planning activities. By default the period before the production horizon
is covered by PP/DS planning, and the period after the production horizon by SNP. Specifying
an offset value in SNP planning runs can be used to possibly leave a gap between the
production horizon and the SNP planning horizon.
The Production Horizon is now replaced by the PP/DS Horizon, which determines
the end of the planning horizon for PP/DS and the SNP Production Horizon, which in turn
determines the start of the SNP planning horizon. Both horizons can overlap. In this case and
if mixed resources are used the SNP and PP/DS planning runs have a joint planning
responsibility during this period. This requires careful master data synchronization
specifically for the PPM but once that has been done a seamless integration between SNP and
PP/DS has been achieved.
Interdependencies
There are some logical interdependencies between the data storage and planning related
profiles. The planning buckets profile cannot span a horizon that is greater than that defined in
the storage buckets profile. Another restriction is that the lowest level periodicity used in the
planning bucket profiles must also exist in the storage buckets profile. This makes sense, as
data cannot be planned on a lower level than it is stored.
When linking a time stream to a storage buckets profile, the time validity of the time stream
must be the same as or greater than that of the storage buckets profile.

3.3.2.1

Storage Buckets Profile

The Storage Buckets Profile defines the periodicity and number of periods used to store the DP or
SNP time series based data. It is linked to a planning area. Typically the storage buckets profile for
DP contains weeks and months periods and that for SNP days and weeks periods, which does not
mean that other settings are not possible. If DP data is stored in an InfoCube as well, the storage
buckets profile of the planning area and the time characteristics settings of the InfoCube need to
match each other. The storage buckets profile also determines the lowest level periodicity that can
be used for the planning buckets profile.
The storage buckets profile can be linked to a time stream and the time stream to a factory
calendar. By doing so, the storage buckets profile inherits the working and non-working day
definitions of the factory calendar. This is mandatory to enable the workday correction function of
Demand Planning. The example below is also based on such a chained link.
It is important to understand that the storage bucket profile determines the way the data is stored
in DP. This also has an impact on the release of data from DP to SNP. The following example
shows this dependency. The same (visible) forecast data in DP is stored based on three different
storage bucket profiles.
Understanding

No Calendar in DP

27.08.01
(142)

28.08.01
(142)
August

28.08.01
27.08.01
(177.5)

Graphic 14 SBP without Factory Calendar

5 Workday Calendar in DP

27.08.01

28.08.01

(200)

(200)

August

28.08.01
27.08.01
(250)

Graphic 15 SBP with Factory Calendar

5 Workday Calendar with Public Holidays in DP

28.08.01
27.08.01
(200)

August

28.08.01
27.08.01
(200)

Graphic 16 SBP with Factory Calendar and Public Holidays

Understanding

70

Option 1 does not use any factory calendar, option 2 uses a calendar with 5 working days per
week, and option 3 uses a factory calendar with 5 working days per week and public holidays. The
forecast released to SNP is different for all three scenarios!

3.3.2.2

Planning Buckets Profile

The Planning Buckets Profile defines the number and type of periods that can be viewed in DP or
SNP. One planning buckets profile is linked to a planning book as the default profile but any
planning buckets profile can be selected by the planner for interactive or batch planning. The only
condition is that the periodicity of the planning areas storage buckets profile is at least that of the
used planning bucket profile. The planning buckets profile is typically set up in a way that
multiple period types (e.g. days and weeks or weeks and months) can be viewed. The further away
the specific period is form the current day, the more condensed the displayed data is. This method
is also referred to as a telescoping profile. The planning buckets profile determines the type and
number of periods displayed and used by the planning run in SNP. Reducing the number of
displayed periods affects the planning precision negatively, specifically in forecasting, but at the
same time improves the planning run time.
In order to transfer the unconstrained plan from DP to SNP it is necessary to define a time bucket
profile with daily buckets. For further information regarding the transfer to SNP please refer to the
appropriate section.
The planning buckets profile contains the following information:
Number of buckets
The number of buckets represents the number of periods used in this profile.

Sequence within time bucket

It is common practice to plan short term in weeks, and long term in months. If we want to
follow this approach we need two time bucket sequences within the profile. One would be in
weeks with for example 4 weeks, and the other one would be for 11 months to complete one
year, which is the total planning horizon. Within APO the first line of the time buckets profile
refers to the entire horizon and the most coarse time granularity (e.g. quarters). The second
line then determines how many periods (as defined in line 1) are then broken down into
smaller periods (e.g. weeks). This can be repeated down to the period days. Also note that
the system applies the time buckets profile definitions from the starting period forward
(backward) for future (historical) data.

Underneath is a graphic showing this approach where the future and the historical data is
displayed in weeks and months.

Understanding

71

Buckets Profile Line 2 (Historical) Buckets Profile Line 2 (Forecast)

Buckets Profile Line 1 (Historical)

Buckets Profile Line 1 (Forecast)

2 2
1

1
Planning Buckets Profiles

Planning Horizon

Graphic 17 DP Time Buckets 1

The graphic above refers to Demand Planning where two planning buckets profiles are used, one
for the historical data and one for the future data. Within Supply Network Planning no planning
buckets profile is required for historical data. The planning buckets profiles in SNP are used to
determine the periods viewed and used during planning runs.
Time definitions within DP are not only defined in the planning book. The master forecast profile
also contains information regarding the forecast and the historical horizon. The forecast horizon in
the master forecast profile defines the period for which a forecast has to be carried out. The
historical horizon defines the period on which the forecast is based on if Time Series Based, Causal,
or Composite forecast models are deployed. The system requires that both, the planning buckets
profile used for the historical and the forecast horizons be defined at least with the same number of
periods as stipulated in the master forecast profile. Whether or not historical data is available from
the planning area (liveCache or Info Cube) is immaterial. The following graphic shows these
dependencies based on an example where the forecast is based on 24 months history and carried out
for a future period of 12 months. The data available in this example is 18 months.

Understanding

72

Only 18 months available

Data in liveCache or Info Cube

Forecast Profile
24 Months
Historical Data

12 Months
Forecast Data

Planning Buckets Profile

Must be greater or equal 24 months Must be greater or equal 12 months

Planning Horizon

Graphic 18 DP Time Buckets 2

The graphic above specifically refers to a Demand Planning environment. The number of periods
(months) is an example.
Note for planning using weekly buckets:
The first day of the week by default is Monday. This cannot be changed.
The planning horizon start date will be set to the Monday of the week, if the defined planning
horizon date does not represent a Monday.

Planning using Weekly and Monthly Buckets

Planning with weekly and monthly buckets reveals an adherent problem of our calendar. The
relation between weeks and months is neither the same from month to month nor is the number of
weeks in a month a natural number. As a result of this, in daily life we work with an approximation
of 4.25 weeks per month. This is not good enough for a sophisticated planning system like APO.
The shortest month in our calendar has 20 workdays (assuming a five-day week) and the maximum
number of workdays is 23 in any month. Within APO the concept of Transitional Days is used.
Example
We plan using 13 weekly buckets and thereafter 9 monthly buckets, which completes one years
cycle. The forecast horizon starts on July 1, 1999. First of all APO will reset the forecast starting
date to the previous Monday, which is June 28, 1999. From there onwards 13 weekly buckets will
be displayed. The last weekly bucket represents the week from September 20, 1999 onwards. After
that APO will show the total for the 4 Transitional Days (Monday 27 through Thursday 30) in a
column with the header September. After that the 9 monthly buckets from October 1999 through
to June 2000 are displayed.
Understanding

The different amount of workdays per month can be accounted for by the system through the use
of an average of workdays per period and a subsequent correction when forecasting (workday
correction).

Month

Week

Table 6 Week-Month Transition (Year 2000, no public holidays considered)

3.3.2.2.1

Telescoping Planning Buckets Profile

Planning buckets profiles used for the DP as well as SNP planning (optimization or heuristics) are
often created as so called telescoping time buckets profiles. This section describes a telescoping
time buckets profile consisting of 35 days, 8 weeks and 9 months used within SNP. Telescoping
planning buckets profiles are interpreted by SNP depending on the planning start date. The
following facts need to be considered in the example.

Months
The system always shows 9 months of which one could be a transitional month.
Month 1 (the first after the weekly bucket) is a full month if the first week of this month
is shorter than 4 calendar days. The last week is then a transitional week reflecting the
demand of these 1 to 3 calendar days.
Month 1 (the first after the weekly bucket) is a transitional month if the first week of this
month is between 4 and 6 calendar days. The first month is then transitional, which is not
including the demand of the last week.
Month 1 (the first after the weekly bucket) is a full month if the end of month coincides
with the end of a week. The last week is then also a full week.

Days

Understanding

74

The system displays between 29 and 35 calendar days depending on the current day of the
week. This is in accordance with the setting 35 days and the requirement to get through to the
next end of week (Sunday). It does not show 35 days plus current week.

Weeks
The number of weeks displayed depends on two factors.
The month/week transition as explained under Months
The day of the week as explained under Days
The day of the month
The number of days and the number of months that are displayed are determined as explained
above. What is left is displayed in weeks. The result is that what we see is not a rolling twelve
months but rather anything between eleven and twelve months.
The SNP Optimizer input log (when using SNP optimization) reports exactly the same number of
technical periods as can be seen in the SNP Interactive Planning transaction.
The tables below show for various planning dates (and the telescoping time buckets profile as
described here) how the number and type of periods fluctuate.

Period Start

Planning Date
M09/01
Transition
W31
29/06/2001
Planning Date
M09/01
Transition
W31
30/06/2001
Planning Date
M10/01
Transition
Understanding

Period Start
W31
1/07/2001

Planning Date
M10/01
Transition
W32
2/07/2001

Planning Date
M10/01
Transition
W32
3/07/2001

Planning Date
M10/01
Transition
W35
28/07/2001

Planning Date
M10/01
Transition
W36
31/07/2001

Understanding

Period Start
Planning Date
M12/01
Transition

W36
1/08/2001

Planning Date
M12/01
Transition
W40
31/08/2001

Planning Date
M12/01
Transition
W40
1/09/2001

Planning Date
M12/01
Transition
W40
2/09/2001

Table 7 Telescoping Time Buckets Profile Examples

Conclusion:

Understanding

77

When using telescoping time bucket profiles, the number of buckets used during the SNP planning
run varies depending on the date. This is of particular interest when using the SNP or Deployment
Optimizer, as both are restricted to a certain model size. One important factor for the model size is
the number of planned time buckets.
The way time buckets profiles are used in APO requires considering the following:

In order to see at least 12 months at any time using the described telescoping time buckets
profile one needs to define the profile with 35 days, 8 weeks, and 10 months.

In order to see a t least 35 days at any time one needs to run the SNP planning always on a
Sunday or define the profile with 42 days, 7 weeks, and 9 months.
If both requirements need to be fulfilled, the total number of periods fluctuates between 45 and 52.

3.3.2.3

Time Streams

The Time Stream, which is also sometimes referred to as Planning Calendar, defines the planning
periods used in APO down to the precision of a second. If a factory calendar is specified in the
time stream when generating the periods, then the definition of working and non-working days is
taken over from it. If no factory calendar is specified, then periods are created for all days of the
time stream as defined in the calculation rules. A time zone can optionally be specified, but must
be set to UTC if the time stream is to be used within SNP. Despite this restriction, the time zone
specified in the location master may be UTC or any other time zone.
Time streams can be defined with or without gaps. A typical example for a time stream with gaps
is one that is used in a production environment. The time stream then defines all working times in
the manufacturing process. The gaps are the non-working times that can subsequently not be used
for any planning activities. Time streams without gaps are used for example in conjunction with
transportation activities that can run at any time. The term without gaps does not imply that no
non-working times can exist in such a time stream. When defining time stream with no gaps, it is
not required to specify the end of a period, as the end of the period is automatically set to the
beginning of the next period (no gaps!).
The definition of the planning periods, which is done during the calendar generation, needs to
adhere to either a weekly or a monthly pattern to allow automated generation. For these patterns
APO offers the Calculation Rules Weekly and Monthly. After using either the weekly or
monthly calculation rule, a final manual adjustment for each period is possible. Selected periods
can also be deleted, which implies that a certain time is a non-working period although this fact is
not defined in the factory calendar used. Periods can be fixed manually to avoid a re-definition
when changing the calculation rules. Whenever a time steam is changed, it must be regenerated to
make the changes effective! In the time stream definition it is required to define the duration of
each time segment by specifying the starting time of the first and the ending time of the last time
unit. Let me provide an example. The time stream is supposed to run from 06.00 in the morning up
to 18.00 in the evening. The time stream, which is defined with second-precision, has to be
defined as follows:
Start Time
06.00:00
Understanding

End Time
18.00:00

Time streams are linked in the location master as production, shipping, and storage location
calendars. Here they define the times where production, shipments or internal receipts and issues
can be carried out. The Shipping Calendar time stream linked to the location master is also
used to determine the working and non-working days when releasing a forecast from DP to SNP.

In the product master, time streams are defined on the ATP tab to enable the ATP check against
Checking Horizon. Furthermore, the time streams are linked to transportation lanes where they
define the periods where activities can be carried out on this transportation lane.
Factory Calendar and Time Steam Definition
Combining a factory calendar with a time stream definition allows a much more sophisticated
definition of working and non-working times. The factory calendar defines the working and nonworking days. This definition is then applied during the generation of time streams. Coupled with
the precise start and end times per day, the system generates a stream of time segments, each
identifying possible working periods. A further optional refinement when creating time streams is
the use of time zones with the appropriate daylight saving time settings. Time streams can also be
created without reference to a factory calendar. In this case all days, as defined in the time
streams, are seen as working days. The following graphic illustrates the combination of factory
calendars and time stream settings.

Factory
Calendar
S

June
25

26

12 h
8h

0h
8h

Time Stream
Graphic 19 Time Line Definitions

Understanding

79

In the example above the combination of factory calendar and time stream provides the following
information:

When linked to a DP or SNP planning area the working days are 5 or 4 out of the 7 days per
calendar week

When linked to a master data object the available capacity (64 or 52 hours per calendar week)
can be seen per day and with start and end dates (not displayed here).

3.3.3

Point of Time Definitions

The previous sections dealt with the definition of working and non-working periods. Once this has
been established, it is required to define the exact date and time of an event. Some events do only
have one time (e.g. the G/R for a purchase order), others have a start and an end time (e.g. an
entire production order). The following sections deal with how the system calculates these dates
and times and finally displays them on screen for the user.

3.3.3.1

Time Calculation

When looking at the date and time calculations, we need to distinguish between system-defined
times which are used in some instances and dates and times that are calculated based on given
requirements. Within SNP and its bucket-orientated way of planning, some elements (order types)
have predefined times for the G/R or G/I point of time. This time determination is carried out by
the planning algorithm and also depends on the type of planning. Typical examples of this type of
time determination are SNP created production orders and the forecast that is released from DP to
SNP. What influences the time as well is the planning buckets profile used. With daily planning
the SNP production orders are set (usually) at 23.59:59 of the planning day. This changes to a
specific day of the week when planning in weekly buckets, and a specific day on the month with
monthly planning.
SNP requires that all locations be set to the time zone UTC, otherwise calculation errors might
occur. This is true for the time zone defined in the time streams linked to a location, but not for the
time zone defined in the location master.
In PP/DS, no preset definitions for production orders have to be made, as the exact date and time
of every order is calculated during the scheduling of the orders, operations and activities.

3.3.3.2

Time Display

In a first step, dates and times are calculated according to finite scheduling parameters (e.g. in
SNP and PP/DS), or determined using preset times (in some instances within SNP). Then these
times are displayed in accordance with the settings of the respective transaction. Most of the APO
transactions allow the user to display times in one of the following three ways:

Understanding

1.

2.

3.

80

All Times in UTC

The UTC based time option displays all times in GMT and does not change according to
daylight savings time. This is the case even if the time zone used contains settings for daylight
savings time.
Time Zone of Location
Times shown with this mode are based on the time zone defined in the location master record.
Each order is related to a specific location, which is used to determine the orders time zone.
If the time zone stipulated in the location master distinguishes between normal and daylight
savings time, then the time display is changed automatically in accordance with the daylight
savings time settings. If the Time Zone of Location is set to UTC then this option displays
the same time as option 1.
Local Time Zone of User
Times shown with this mode are based on the time zone defined in the user master record.
Each user can be linked to a specific time zone. If the time zone stipulated in the user master
record distinguishes between normal and daylight savings time, then the time display is
changed automatically in accordance with the daylight savings time settings. It is advisable to
use, in the location and user master, the same type of time zones (either with or without
daylight savings time). This is not due to of technical reasons, but rather to avoid unnecessary
user confusion. In this case the time display of orders within the users location is identical to
option 2 above. If the Local Time Zone of User is set to UTC then this option displays the
same time as option 1.
This requires the definition of the users time zone. Select System > User profile > Own
Data (transaction SU3) from the APO main menu to open the Maintain User Profile
transaction. Set the personal time zone on the Defaults tab as required.

3.3.4

Time Horizons

Time Horizons determine the length of time on the time axis used to display data or in some
instances to calculate orders. The time horizons can be maintained via profiles or in the respective
interactive transactions, and are often independent of the planning period used during the
calculation. The following list gives an overview of the main interactive transactions and how the
display and calculation periods are defined.

DP Interactive Planning
When starting the DP Interactive Planning transaction, a specific planning book is used. The
default planning book that is used is the one that was used when leaving the transaction last.
Planning books can also be manually assigned to users. Switching over from one planning
book to another is possible.
Each planning book data view in turn has two profiles attached to it that specify the number
of periods displayed for the past and the future. These planning buckets profiles can be found
in the planning book data view information. The profiles settings are planning book
dependent and do not determine the horizon used when performing the forecast. The horizons
used by the forecast run are defined in the forecast profiles.

SNP Interactive Planning

The period display is handled the same way as it is for the DP Interactive Planning. The
definition of a time buckets profile for past periods is not required. The settings are planning

Understanding

81

book data view specific and carried out by means of planning buckets profiles. The displayed
horizons per data view are also used by the planning run.
PP/DS Product View
The PP/DS Product View transaction does not require any time horizon settings, by default all
existing elements (orders) are displayed. It is possible to limit the display horizon, but other
than that no specific settings are required. The PP/DS Interactive Planning function plans the
product within the product specific production horizon as defined in the product master. No
other specific settings are required.
PP/DS Planning Board
The display and the planning period can be defined independently from each other in the
Time Profile. The planning period determines the calculation horizon. A specific time profile
can be defined per user. The settings are user specific. The PP/DS Optimizer uses its own
horizon settings according to the settings in the Optimization Profile.

Understanding

3.4

82

Methodology

In the following sections we shall go through the underlying concepts and methods that are built
into the APO system. Specifically for those who want to do more than just operate the system it is
important to understand these sections. They provide valuable insight into the APO blueprinting,
not on a high level but done a way that the information can be applied to everyday problems and
tasks.

3.4.1

Forecasting Methodology

There are various primary forecasting techniques available within APO. They can be broken down
into three basic areas.

Time Series Based

Causal

Judgmental Models
A special type of primary forecasting technique combines some of the above listed techniques and
presents a forecast based on a weighted mix of the primary forecasting techniques results. This
concept is referred to as

Composite Forecasts
Primary forecasting techniques are carried out first in time. Furthermore, an optional secondary
forecasting technique can be used as a follow-up activity after any of the basic forecast techniques
have been applied. This is the subject of

Consensus Based Forecasts

To support an efficient forecasting process some additional tools are available within APO. The
forecast support tools can be grouped according to the following criteria:

Forecast Preparation
Correction or adjustment of historical data immediately before the forecast values are
calculated.
Outlier Correction
Workday Correction
Phase-In/Out Modeling
Like Modeling

Forecast Adjustment
Adjustment of the calculated forecast during the forecast calculation.
Workday Correction

Forecast Evaluation
This is the evaluation of calculated error values or the quality assessment of forecasted values
after the forecast calculation.

Promotion Planning
Promotion Planning is the adding of market intelligence as a way to adapt forecasts that are
based on mathematical models. Unlike the other forecast support tools, Promotion Planning is

Understanding

83

in most instances carried out after the forecast has been created. It can though also be an
independent task where the promotion planning results are amalgamated with the base
forecast. A regeneration of the forecast might require updating the promotion plan.
Note that not all of these tools can be applied to all of the listed forecasting models. In some cases,
although technically possible, the result of applying such tools might be meaningless.

3.4.1.1

Forecasting Techniques

Time Series Based Models are based on the assumption that the future demand pattern can be
described with reasonable quality by extrapolating the consumption pattern found in the past. That
is why these models, as the first step, require a thorough investigation of past consumption
patterns. The investigation includes the elimination of any outliers as well as the workday
correction. Once this step has been carried out, the forecast as such is a simple extrapolation of the
past consumption pattern. There is a magnitude of time series-based models strategies. This type is
the most commonly used way to perform a forecast. These forecast methods, which we shall
further explore in the following sections, are based on a single set of data, the time series. In APO
they are also called Time Series Based or Statistical Forecasts as well as Univariate Forecasts.

Statistical method to extrapolate historical data, which does not require logical relations
to other external variables.

Causal Models explain past demand based on coefficients and forecast the future demand based on
the equation developed in the first step. A coefficient is an independent variable (indicator), which
is used to describe the change of the dependent variable (the sales demand). Causal models can
have one or multiple independent variables, which influence the dependent variable according to
fixed or variable relations. Furthermore, it might be possible that an independent variable has a
significant influence only within a certain interval. The idea of Causal Models is to explain the
consumption of a specific product by using global and easier to predict parameters.
Lets look at the following example. In a simplified model, the consumption of petrol for
passenger cars is depending on the number of cars (independent variable x 1) and the price per liter
(independent variable x2). Both will influence the consumption (dependent variable y). We now
assume that the variable x1 explains the model for any number of passenger cars from Zero to
indefinite. Variable x2 is only valid for petrol prices between a defined lower level x 2 min and an
upper level x2 max. This is valid due to the fact that people will not exceed a certain mileage per
year even if the price falls below a level x 2 min. On the other hand, they will do a minimum
mileage per year even if the petrol price exceeds the upper level x2 max. Once we know the relation
between petrol price and number of cars, on the one hand, and the petrol consumption on the other
hand, we can easily extrapolate and predict the petrol consumption.

Method based on historical data and its relationship to consumption in the past, which
is then carried forward.

Judgmental Models are no mathematical models like the other two explained above. This model
builds on peoples expertise and experience. The input is market knowledge and maybe even
Understanding

intuition and ideas of what is likely to happen in the future. Various methodologies are known.
Some literature also talks of applying Market Intelligence emphasizing the fact that an
individuals knowledge or intelligence is used to create a forecast. Any planning system must
support these forecasting activities by providing complete and structured information. This is

achieved by the use of the Business Information Warehouse (BW) with its highly configurable
and open approach. Furthermore it is required to have an easy way to capture and view forecasts
derived. This can be done using the APO Demand Planning functionality.
Subjective assessment of probable future consumption carried out by individuals or
groups.

After explaining the three primary forecasting techniques, it must be stressed that in real life
usually none of them are deployed in their purest form. Planners will for example run a time
series-based model but change a few figures, as they know (judgmental) that in a certain
month the sales will be different. After gaining an understanding for the primary forecasting
techniques, we shall learn in the next step how these differently derived forecasts can be
combined and further refined by applying any of the secondary forecasting techniques.
The following table provides an initial overview of the APO forecast strategies. Note that the
numbering is in accordance with the definitions used in the APO system. These numbers can be
found for example in the Univariate Forecast Profile when defining the default strategy for
forecasts.

Forecasting
Technique
Time Series Based

Causal
*
Table 8 Forecast Strategies

Understanding

85

The External Model permits a custom specific implementation of any forecast technique.

3.4.1.1.1

Time Series Based Forecasting

This group comprises basically all the well-known forecasting algorithms. A few of them are also
available in the R/3 system and for this reason they should be well known to any R/3 user. Some
are very basic methods that, although simple in concept but fast in processing, might well do the
job. All univariate forecasts are based on a past time series.
Which model and thus forecasting strategy should be used depends primarily on the products
sales patterns and the permitted processing time. APO supports the grouping of products in such a
way that various groups of products are forecasted using different forecasting strategies. The
decision, which one to use is at the users discretion.

Constant Model (Group 10)

This model is characterized by a stable demand with little-to-no fluctuation over time.
Products following this pattern can usually be found in saturated markets. Constant models
assume that the demand or consumption of a product will be the same in the forecasted period
in comparison to the past periods used to derive the forecast. This does not imply at all that
these models do not react to changes in consumption; they just do not anticipate a change. If
for example the actual demand in the month of August differs from the forecasted demand for
this month, all constant models will forecast a new changed forecast for the month of
September. The difference of the various strategies offered within this model is that they adapt
faster or slower to such a change.
Example:
Products in the midst of their life cycle, where sales patterns are independent of external
factors and which at the same time are not subject to increased competition. An example
would be the sales pattern of fire matches in the supermarket or the usage of service parts for
a fleet of cars with a stable number of units and average age.

Trend Model (Group 20)

In this model, a stable, but growing (or shrinking) demand is assumed. The result of the
forecast is a quantity, which changes from period to period by exactly the same absolute
figure. There is only a subtle difference between the Constant and the Trend Model. The latter
examines trends in consumption and anticipates changes to it. This is a proactive approach
unlike the Constant Model, which is reactive. The Trend Model pattern could also easily be
explained using a causal model if the cause (originator) of the change is known.
Example:
This pattern also applies most to products at the midst of their life cycle. Unlike the above
there is a certain change (stable increase or decrease) per period, which usually is based on an
external factor that cannot be influenced. Examples are the sales of basic groceries (e.g. salt)
where the usage is not dependent on external factors besides the population.

Seasonal Model (Group 30)

The seasonal model assumes consumption changes based on one or multiple seasons per
group of periods (e.g. per year). The season is finished after the seasonal effect (increase or
decrease of demand) is over and the demand is back to its usual value. The season may
consist of an increase or a decrease in demand, or both. A seasonal pattern can be caused by
certain events (Christmas or New Year), by the average temperature (summer or winter), or
weather conditions (rainy season). Event-driven seasons are rather easy to handle, as the time
of the

Understanding

86

occurrence is predictable. Seasons based on weather are difficult to predict for known
reasons. Furthermore, the overlay of two independent seasonal effects is complicated, and in
this case the usage of a causal model might be more appropriate.
Example:
We all know the standard example for seasonal behavior, the ice cream consumption during
summer. But there are others, which are not as obvious. Wind screen wiper blades shortly
after the start of the rainy season, chocolate before Easter and slimming agents after
Christmas and Easter.
Seasonal Trend Model (Group 40)
This again is a combination of two effects, the seasonal usage combined with a growing or
shrinking number of sales. The seasonal factors (or indices) calculated per period are adjusted
by the growth factor. Otherwise the calculation follows the principle of the Seasonal Model.
Example:
All the examples above are valid again; the difference is an overlay of an increasing or
decreasing market pattern caused by an external factor.
Automatic Model Selection 1 and 2 (Group 50)
All forecast models described above require the planner defining which forecast strategy and
model is to be used for calculating the forecast. APO offers the possibility of Automatic
Model Selection, where the system determines the model with the best fit. This is particular
helpful if the planner does not know which model and strategy is the best. The strategies with
automatic model selection should only be used as an exception or when the planner assumes a
significant change in the time series pattern. This is due to the fact that their run time is longer
than those of other strategies, as the selection process is resource intensive. APO provides
feedback as to which model was chosen. This allows setting the chosen model as the default
model for future forecast runs.
Example:
There is no typical example of product that would follow this principle.
Copy History (Groups 60)
In cases where applying mathematical forecast models do not promise to deliver satisfactory
results, it is possible to copy past historical sales data as the future forecast. In this scenario,
we follow the idea that even no forecast is a forecast, and just copy last periods (e.g. years)
results and assume we shall use or sell the product the same way we did last year.
Example:
Again, there is no typical example of product that would follow this principle.
Manual Forecast (Group 70)
The manual forecast model is a variation on the seasonal trend model of group 40. After an
initial forecast based on strategy 40 was carried out, the planner can manually define the
basic, trend, and/or seasonal indices values. The Manual Forecast can only be used in
interactive planning (i.e. not in background).
Example:
See above group 30 and 40.
Intermittent Model Croston Method (Group 80)
Irregular demand is the nightmare of any planner. Nothing is predictable and consumption
comes and goes without obeying any rule (or at least we dont know the rule). Croston
developed a model specifically for such demand. It works best if a high number of historical
data sets of the forecasted product are available. The principle is a two-step calculation. Step
one determines the intervals of demand reoccurrences and the second the demand value per
occurrence. Alternatively, as nothing is predictable, the only chance is to have a higher safety

Understanding

87

stock and hope to cope with peaks. In this case, it would be advisable to use a re-order point
procedure instead.
Example:
Any product could be an example for this pattern; it really depends on the actual market
position the company is in. Usually spare parts for technical items of which only few were
sold have such a consumption behavior.
One rule is valid for all the forecasting methods described above. The more good data (that is data,
which is correct and reliable) you have to run a forecast, the better the result is. In cases where
historical data is not reliable, it might be the better choice to not use it. This is quite often the case
when a new system like APO is implemented, and the data coming from the old system is either
not complete, incorrect, or was stored with a different organizational structure in mind.
The forecast models described above are implemented in APO through various forecast strategies.
For almost all of these models, various strategies are available that allow the planner to forecast
demand as precisely as the data and his or her knowledge allow. It must be stressed again that
forecasting is to a large extent an interactive task between the planner and the system. A good
planner needs to fully understand the concept behind each and every strategy to make the right
decisions. The system will only provide feedback, give data quality measurements, and help to
cope with huge amounts of data. It will not replace sound business knowledge and experience!
The time based (univariate) forecast models and strategies are listed in the table below. The group
of forecast models is referred to as the Type of Forecast Model in the DP Interactive Planning
transaction.

Group

Forecast Model

10

Constant Model

20

Trend Model

30

Seasonal Model
Season + Linear
Regression

40

Seasonal Trend
Model

50

Automatic Model
Selection 1

Understanding

88

Group

Forecast Model

Automatic Model
Selection 2
60

History

70

Manual Forecast

80

Croston Method

Table 9 Univariate Forecast Models and Strategies

Model Initialization
When using any of the forecast models contained in the groups 10 through to 40 it is required to
perform a model initialization before the forecast can be carried out. During this process, which is
carried out automatically, basic values (also referred to as model parameters), that are dependent on
the model chosen, are calculated. To carry out this step, it is obviously necessary to have a minimum
amount of historical data sets. The amount of datasets is dependent on the chosen model and is a
mathematical minimum. It does not imply whatsoever that the result will be meaningful.
The minimum number of historical data values required to perform the model initialization per
forecast model is shown in the following table. The table also shows the parameters calculated for
the respective forecast models. Note that the Ex-Post Forecast starts after the required number of
historical datasets (periods) was read. Depending on the chosen forecast strategy, parameters that are
not required are populated with default values.

Forecast
Model
Constant
Trend
Seasonal
Seasonal Trend

Table 10 Model Initialization

Understanding

The calculation of the model parameters is, as seen above, dependent on the chosen forecast model.
In order to understand these calculations, the following variables are used in the table further down.
The same variables are also used to depict the mathematical rules of the forecast strategies.

Variable Name
Period
Forecast Value of Period
Actual Value of Period
Seasonal Index Value of Period
Basic Value of Period
Weighting Factor of Period
Number of Periods
Number of Periods in Season

Table 11 Forecast Execution Variable Definitions

The most recent period (current period) is defined as period t 0 with preceding periods shown as t -1,
t-2 and so on. The first forecasted period is defined as t 1. Increasing positive values for t depict
periods that are further in the future for forecast values and further in the past for historical values.

The first (closest to actual period) forecast value is thus:

The first (closest to actual period) historical value is thus:
Based on the above variable definitions the formulas used for the model initialization are the
following.

Forecast
Model
Constant

Par

Tre

Understanding

Forecast
Model

Par

Bas
Sea

MA
Trend

Tre

Bas

Sea

MA

Seasonal

Tre

Bas

Sea

MA
Seasonal
Trend

Tre

Bas

Sea

MA

Table 12 Model Initialization Formulas

Understanding

91

Forecast Strategies
The following sections provide an introduction to forecasting strategies available in APO.
Forecasting Strategies in APO have a numeric identifier (see above) that is used to select a
strategy. This identifier can be seen in the header of each section referring to a strategy. For
Constant Models the mathematical formula used to derive the forecast is introduced. These
formulas are added to gain some basic knowledge about the calculation and to also develop an
idea about the complexity of these calculations.
For models other than the Constant Models, no formulas are added, as it is not the core emphasis
of the APO Knowledge Bank to provide the theoretical background and all formulas required for
statistical forecasting. An abundance of literature is available for this topic.
The used variables are explained further above (see Model Initialization).

Constant Models
Constant Models can be found in Strategy Group 10.
Selecting strategy 10 results in strategy 11 being used!
Strategy 11 - 1st Order Exponential Smoothing
1st Order Exponential Smoothing is also known as Single Exponential Smoothing abbreviated
SES. Like the weighted moving average, this strategy is also based on the principle that, the older
the historical data, the less impact it has on the forecast. In addition to this, the previous periods
forecast error is taken into account. Weighting is achieved by using the so-called Alpha () factor
and the basic formula for the 1st Order Exponential Smoothing is the following:

(t0)

(t0)

1 B

(t1)

This means that the basic value for the current period is based on the current periods actual values
multiplied with the alpha factor plus the previous periods basic value multiplied with 1 minus
alpha. But what are the previous periods basic values? The basic values are calculated in some
type of a reverse chain reaction. Whenever the basic value of a previous period is calculated we
need the basic values of the period just before this one. This is repeated through to the beginning
of the historical data horizon. The basic value for the oldest period t = n is as follows:

(tn )

(tn )

In other words the oldest basic value is the actual value of this period! Once the system has started
there it can roll forward and calculate all other basic values. Assuming the forecast is based on 12
historical data values (n = 12 and t running from 0 through to 11), representing 12 periods under
observation, the formula for the basic value of the period t = 0 looks like this:
Understanding

B(t0) A(t0) 1 A(t1) 1 2 A(t2)

.... 1 10 A(t10) 1 11 A(t11)
Now that we know how to calculate the basic values, we can apply the last calculation.

F B

(t0)

The forecast value F equals the basic value of the last calculated basic value. It is the same for all
forecasted periods.
The greater the Alpha factor, the more weight is put on the most recent consumption data and
vice versa. Note that when using the theoretical value of Zero for the Alpha Factor with this
strategy, the forecast for the following period equals the consumption (sales) of the very first
period under observation (which might be a year old)! The other extreme with Alpha equal to 1
results in the forecast for the coming period to be equal to the last periods consumption.
Common values for alpha are in the range of 0.3 to 0.5. The weights based on the alpha factor
applied to all past data sum up to approximately 1. The impact of historical data decreases
exponentially. The following table gives the weight per period for the three alpha factors 0.3, 0.4,
and 0.5 based on a 12 period observation frame. The results are always rounded to four digits.

Alpha
Period t
0
1
2
3
4
5
6
7
8
9
10
11
Table 13 Alpha Smoothing Factors

Understanding

93

It is easily visible that the impact of historical data diminishes faster with greater alpha values and
vice versa. When applying high alpha values, the number of periods under observation can be
easily reduced without having a significant loss in forecast quality.
Strategy 12 - Automatic Alpha Optimization (1st order)
The Constant Model with Automatic Alpha Optimization (1 st order) optimizes the Alpha factor
while calculating the forecast values. Other than that there are no differences compared to the
strategy explained above. In order to optimize the alpha factor, the system has to carry out the
forecast applying various alpha factors. In a consequent step the calculated forecasts are compared
using the error values ET (Total Error) and MAD (Mean Absolute Deviation). They are explained
in the following sections.
The alpha optimization starts with the alpha factor as defined in the univariate profile or a value of
0.30 if none is defined. From there the alpha factor is changed in an iterative process between 0.05
and 0.90. The alpha factor with the lowest error is chosen.
Strategy 13 - Moving Average
The Moving Average model is also referred to as Moving Average Forecast abbreviated MA (n)
whereby n depicts the number of periods used. The system calculates the average over the
historical time pattern and carries forward this average as the new demand for the following
periods of the forecast horizon. All past periods are added up with the same weight. If as an
example the forecast horizon is twelve months, all 12 months will have the same impact on the
forecasted value, which is the average of the past periods. All periods have the same weighting,
and for this reason the model adapts to changes only very slowly. This strategy is suitable for
products with a stable constant demand although it will adapt to changes over time. The higher the
number of periods used, the more stable the result on one hand and less responsive to changes on
the other hand.
1n

F n1 A(t )
t0

The forecast value F is the same for all forecasted periods.

Strategy 14 - Weighted Moving Average
Strategy 14 is a derivation of strategy 13. As with the strategy explained above, the system
calculates the average over a specified period and carries forward this result as the forecast. Unlike
the above strategy, each historical value is multiplied with a factor as specified in the Weighting
Group. The total of all weighting factors used is 1. Based on the assumption that the weights
decrease over time, this model results in a situation where the most recent historical data has a
greater impact than older data.

Understanding

F n1

1n

A(t )

94

*W
(t )

t0

1n

W 1

(t )
t 0

The forecast value F is the same for all forecasted periods.

Trend Models
Trend Models can be found in Strategy Group 20.
Selecting strategy 20 results in strategy 21 being used!
Trend Models are very similar to the constant models. The main difference is that all constant
models assume a consumption that is stable over time, with no up or downward trend. In other
words, a constant model has a Zero Trend. For this reason constant models can be seen as a
special form of trend models. The result of a trend model forecast with perfectly constant
historical data will therefore be the same as it would be when applying the constant model
directly. The general notation for a trend model is depicted below.

Yt a bXt
In this formula the time independent basic value a, the slope multiplier b, and the time
dependent observation value Xt explain the forecast value Yt. The sign of the multiplier b
indicates the relation between the forecast value Yt and the observation value Xt. In case of a
positive sign, the forecast value Yt rises (falls) with a rising (falling) observation value X t and, in
case of a negative sign, the forecast value Y t rises (falls) with a falling (rising) observation value
Xt.
APO provides the Trend Dampening Profile as an optional entry for all trend models. A trend
dampening profile is used in situations where the identified trend in the past is likely to decrease
(flatten out). Mathematically spoken the slope as identified in the formula above decreases from
period to period as specified in the trend dampening profile. When attaching a trend dampening
profile to a product, the slope b will be adjusted as specified when calculating the forecast.
Strategy 21 - 1st Order Exponential Smoothing
As it is the case with 1 st Order Exponential Smoothing for constant models, using this strategy,
more weight is put on more recent data. The weight of historical data decreases exponentially over
time. 1 st Order Exponential Smoothing, which is also called the Holts Method, uses the Alpha
Factor, which determines the decrease of the weight factor used per historical data point. Alpha
Factors range from Zero to 1. The higher the Alpha Factor, the more weight is put on recent

Understanding

95

historical data and vice versa. High Alpha values lead to forecasts that are very responsive towards
changes. At the same time, they tend to overreact in situations where extraordinary sales were
encountered.
Also see the above section Strategy 11 - 1 st Order Exponential Smoothing for further
information on the Alpha Factor.
Strategy 22 - 2nd Order Exponential Smoothing
1st Order Exponential Smoothing is a rather weak strategy to use when trends are imminent. The
forecast results trail behind by several periods depending on the Alpha Factor. 2 nd Order
Exponential Smoothing overcomes this problem by specifically recognizing trends and
incorporating them into the forecast. With this method, two smoothing constants, named Alpha
and Beta are used. Both run between Zero and 1. It is important to choose the Alpha and Beta
factors in such a way that the error of the forecast is minimized. A method to do so would be to
compare the Mean Square Error (MSE) for various Alpha/Beta combinations. The lowest MSE
indicates the best-fit Alpha/Beta combination.
The MSE is explained further down in the section Forecast Accuracy Analysis.
Strategy 23 - Automatic Alpha Optimization (2nd order)
As seen in strategy 22, it can be a rather laborious task to determine the best-fit Alpha/Beta
combination. Using the Strategy 23 - Trend Model with Automatic Alpha Optimization (2 nd order)
the system will perform this optimization for the planner and automatically use the best
combination.
In order to optimize the factors, the system has to carry out the forecast applying various alpha and
beta factors. In a consequent step the calculated forecasts are compared using the error values ET
(Total Error) and MAD (Mean Absolute Deviation), They are explained in the following sections.
The optimization starts with factors as defined in the univariate profile or a value of 0.30 if none
are defined. From there the factors are changed in an iterative process between 0.05 and 0.90. The
alpha and beta factors with the lowest errors are chosen.

Seasonal Models
Seasonal Models can be found in Strategy Group 30.
Selecting strategy 30 results in strategy 31 being used!
A periodical increase and decrease of consumption characterize seasonal models. Typical
examples are the sales of ice cream, which peak in summer and the increased energy consumption
of private households during winter. In order for such models to work, it is required to define the
number of periods per season. Seasonal models cannot be used if the seasonality varies too much.
The underlying forecast after the elimination of the seasonal effect is a constant or trend model.
The

Understanding

96

system calculates an average for the periods in questions and then a seasonal factor per period
ranging from Zero (no sales) to One (average sales) to Greater One (above average sales).
Strategy 31 - Seasonal Model based on Winters Method
The methods of the groups 10 and 20 discussed above can cope with historical data that shows a
constant and/or trend pattern. They would be totally inadequate for situations where a seasonal
pattern is detected. Specifically for this type of historical data pattern Winter developed a method
that is also known as the Holt-Winters method. The Holt-Winters method is an extension of the
original Holts method, which is used for trend models. The Holt-Winter method is implemented
in APO as strategy 31. Winters model can deal with seasonal and trend patterns and is using in
such cases the three parameters Alpha, Beta, and Gamma. In APO this model is used only in
connection with seasonal models without a trend and therefore does not require the Beta
parameter. The quality of the forecast is dependent on the right combination of the Alpha and
Gamma parameter. Using strategy 31, the planner must optimize them manually. To do so it is
appropriate to run various forecasts using different sets of the Alpha and Gamma factor and
monitor the forecast error (e.g. the Mean Square Error, MSE). This is obviously a rather laborious
task and it might be advisable to instead use one of the strategies with automatic model selection.
Strategy 35 - Seasonal Linear Regression
This strategy for seasonal models overcomes a weakness of the strategy 31, which return large
basic values if the seasonal index is zero or close to zero. It should though not be used if the
historical data has a significant trend.

Seasonal Trend Models

Seasonal Trend Models can be found in Strategy Group 40.
Selecting strategy 40 results in strategy 41 being used!
Seasonal Trend Models are the combination of a trend with a seasonal model. Due to this it is
mandatory to define the periods per season. As it is the case with trend models, the usage of a
Trend Dampening Profile is possible (see above sections for more information).
Strategy 41 - 1st Order Exponential Smoothing
The model used for historical data that follows a seasonal trend pattern is similar to the one
described above. In addition to the Alpha and Gamma factor introduced in the last section, a new
parameter called Beta is required. The Alpha parameter is used for smoothing of the basic value,
the Beta parameter is used for smoothing of the trend value, and the Gamma parameter is used for
smoothing of the seasonal index.

Understanding

97

Automatic Model Selection Procedure Models

Automatic Model Selection Procedures can be found in Strategy Group 50.
Up to now all strategies we discussed required the planner deciding which strategy the system
should use when carrying out the forecast. Specifically, when dealing with a large number of
products or in cases where the pattern is not easily recognizable by the planner, this tends to be a
challenge. The answer to this problem is the usage of Automatic Model Selection strategies, which
will be introduced in the following sections. Automatic Model Selection strategies are not entirely
new strategies. The system evaluates the historical data and carries out various forecasts. The
strategy with the best fit is then used to carry out the forecast. Automatic Model Selection is
resource intensive and should therefore not be used as the default strategy. On the other hand the
usage of Automatic Model Selection ensures that products where the underlying model has
changed are forecasted more accurately. APO provides feedback as to which model was chosen.
This allows setting the chosen model as the default model for future forecast runs.
Strategy 50 - Test for Constant, Trend, Seasonal, and Seasonal Trend
With this strategy the system tests by means of a regression analysis for any of the above
mentioned patterns. The forecast will be based on the constant model if no significant trend is
detected.
Strategy 51 - Test for Trend
With this strategy the system tests by means of a regression analysis for a trend pattern. The
forecast will be based on the constant model if no significant trend is detected.
Strategy 52 - Test for Season
In a first step, any trend values are eliminated form the historical data. Then an Auto-Correlation
test is carried out (see the section Model Fit Analysis for Causal Forecast). Should the AutoCorrelation test indicate correlation, the trend model is applied. Otherwise the constant model is
used.
Strategy 53 - Test for Trend and Season
Strategy 53 is a combination of the strategies 51 and 52. In an initial step, the system tests by
means of a regression analysis for a trend pattern. Then any trend values are eliminated form the
historical data, which is followed by an Auto-Correlation test. Depending on the results, a Trend,
Seasonal, or Seasonal Trend model will be applied. Should none of these models clearly apply to
the historical data, the product will be forecasted using the constant model. Required entry is the
periods per season.

Understanding

98

Strategy 54 - Seasonal Model and Test for Trend

When using manual model selection strategies, the planner must provide some input. By doing so
the number of possibilities is limited which reduces the overall runtime of the model selection.
The two strategies explained in this and the next section follow this principle. They are very
similar to the strategies 51 and 52 discussed above.
Based on the assumption that a seasonal model applies to the historical data, the system tests with
the strategy 54 for a trend pattern by means of a regression analysis. If the test is successful, the
forecast will be based on a seasonal trend model, otherwise a seasonal model is used.
Strategy 55 - Trend Model and Test for Seasonal Pattern
This test assumes that a trend model applies to the historical data. In a first step, the trend values
are eliminated from the historical data. Then an Auto-Correlation test is carried out (see the
section Model Fit Analysis for Causal Forecast). Should the Auto-Correlation test indicate
correlation, the seasonal trend model is applied; otherwise the trend model is used.
Strategy 56 - Forecast with Model Selection Procedure 2
According to SAP the automatic selection procedure 2 is more precise than the automatic
selection procedure 1 used by the strategies discussed earlier, but has longer running times. With
strategy 56, the system tests for:

Constant

Trend

Season

Seasonal Trend
It deploys various combinations of Alpha (), Beta (), and Gamma () factors to determine the
optimum result, which is determined by the lowest Mean Absolute Deviation (MAD). Should
none of these models clearly apply to the historical data, the product will be forecasted using the
constant model. Required entry is the periods per season.

Copy History
The strategy group 60 consists of one strategy only. Using this strategy with the same number as
the group, previous historical data is simply copied and used as the next periods forecast. The
periods that are copied depend on the historical horizon defined in the forecast profile. If the
historical horizon is 24 months and the forecast horizon is 12 months, the system will copy across
the historical data of the months 24 through to 13 as the forecast for the months 1 through to 12.

Manual Forecast
The strategy group 70 consists of one strategy only. With this forecast strategy the system carries
out a forecast based on strategy 40 after which the planner can manually (interactively) define one
or any combination of the following parameters:

Understanding

99

Basic Value
Trend Value
Seasonal Indices
The definition of a trend dampening profile is optional. Based on these parameters the system
carries out a seasonal trend forecast based on the seasonal trend model. Setting the trend value
(seasonal indices) to Zero will result in a seasonal (trend) model. Populating both the trend value
and the seasonal indices returns a seasonal trend model.

Croston Method
The strategy group 80 consists of one strategy only. The strategy has the same number as the
group. One of the most difficult tasks in forecasting is to deal with intermittent or lumpy demand.
Such cases are characterized by having no dominant pattern, periods without any consumption,
and unpredictable consumption in other periods. Croston developed a model specifically for such
demand. It works best if a high number of historical data sets of the forecasted product are
available.

3.4.1.1.1.1

Forecast Preparation

In some instances historical data should be adjusted before the forecast is carried out. Reasons
might be the quality of data (outlier correction), period adjustment (workday correction), or the
requirement to consider the products life cycles (life cycle management). Workday correction also
affects the calculation of forecast figures.
Outlier Correction
By definition an outlier is a value, which lies out of the demand pattern and will disable the
detection of this pattern or at least have a negative influence on the mathematical correct
explanation of the demand pattern. In graphical format, outliers can be easily seen and eliminated
by the planner. Again, this is an intuitive approach where the planners experience is very
important. Outliers are not wrong data; they are just an occurrence, which was untypical and will
not be repeated. An example would be an export sale in an environment where otherwise only
domestic sales take place. In this case the sales data of this period should be corrected so that only
the domestic sales remain. This is a logical approach to correcting an outlier. Although precise,
this is not feasible in an automated system controlled process. Here mathematical algorithms have
to be applied. APO offers such an approach in the form of Outlier Correction.
Outliers are identified as such if they lie outside of a tolerance lane which is dependent on the
results of the Ex-Post Forecast, the Mean Absolute Deviation (MAD) and a user definable value
called Sigma. The planners task is to define Sigma in a way that the tolerance is neither too wide
nor too narrow. Default Sigma is set to 1.25. The tolerance formula is as follows:

TLt EPt * MAD

Understanding

100

The used abbreviations are as follows:

Variable Name
Tolerance Lane point at time t
Ex Post Forecast value at time t
User definable value Sigma
Mean Absolute Deviation

Table 14 Outlier Correction Variables

Should a historical value be identified as an outlier, then it will be replaced by the corresponding
value of the ex post forecast. Outlier Correction functionality works only in connection with TimeBased Forecasting. It can be activated in the Univariate Forecast Profile.

Historical Data
Tolerance Lane
Outlier

Time
Graphic 20 Outlier Correction

Understanding

101

Workday Correction
Workday Correction is used to compensate for the fact that months have different numbers of
workdays. The system first corrects the history according to the actual workdays in the past
period. Then in the next step, the forecast is adjusted according to the actual workdays in the
forecasted period. Workdays are defined according to the valid calendar of the planning area.
The following is an example for this correction based on a trend model with a base demand of
100, a monthly increase of 10, and an average 20 workdays during the year 1999. In this example
a factory calendar with no public holidays was used. Results are rounded with no decimals.

Month
History
Workdays
Corrected History
Table 15 Workday Correction
Workday Correction functionality works only in connection with Time-Based Forecasting. When
calculating the Corrected History (HC) the system corrects the Original History (H O) according to
the following calculation:

HC HO *WDAV /WDAC
Workday Correction is also applied to the calculated forecast in which case it acts as a forecast
adjustment tool. When calculating the Forecast Value (F) the system adjusts the temporarily-stored
Forecast (FT) as follows:

F FT *WDAC /WDAV
Actual Workdays (WDAC) are taken from the Factory Calendar, the Average Number of Workdays
(WDAV) is defined in the Univariate Forecast Profile. The average number of workdays needs to
be aligned with the period defined in the profile. When planning in weeks (months) it makes sense
to set the average to 5 (20) days. Workday Correction normalizes the forecast result and adjusts
the history before using it.
Workday Correction is applied to both historical data and forecast or to none.
The factory calendar used for the workday correction is defined in the time stream that is
attached to the planning areas storage bucket profile.

3.4.1.1.1.2

Forecast Evaluation

Understanding

102

Demand Planning offers several tools that allow the evaluation of univariate (or time series-based)
forecasts. The evaluation result gives the planner a good idea how usable and reliable the forecast
will be. Error values are calculated automatically and can be seen on the Interactive Planning
Screen.
The calculation of all evaluation error values is based on a comparison of forecasted past demand
with actual past demand. The higher the deviation is, the higher the error value will be.
Monitoring these forecast errors provides a good indication of the accuracy of the forecast. Which
error value is best suited to point out a bad forecast model depends on the forecast model and the
business environment. Within APO the term Ex Post Forecast is used for this technique.
During the Ex Post Forecast the following steps are carried out:
Define the Initialization and the Ex Post Forecast periods by dividing the historical data into
two groups. The length of these groups of data is determined by the system. The length of the
initialization period is based on the chosen forecast model (see Model Initialization). Any
periods not required are then allocated to the Ex Post period.

Calculate as required the basic value, trend value, seasonal indices, and mean absolute
deviation.

Calculate the difference between the actual and the forecasted consumption.
For the Initialization and the Ex Post Period, historical data is available. The forecast is carried out
for the Ex Post period and the future. The following graph shows the principles of the Ex Post
Forecast. In most cases the initialization period is significantly shorter than the ex post period.

Quantity

In itia liz a tio n P e r io d

E x P o s t P e r io d

H is to r ic a l D a ta

F o r e c a s t D a ta

Time
Graphic 21 Ex Post Forecast
Special care must be taken if only very little data is available. In order to carry out an ex post
forecast, only a few data points (historical demands) are required. The existence of a low forecast
error value specifically in this case does not necessarily mean that the forecast model selected and
the demand predicted are reliable.

Understanding

103

Forecast Error Calculation

The six different principles available in APO for calculating forecast error values and determining
the forecast accuracy are listed below.
Following abbreviations are used:

Variable Name
Period

Actual Value of Period

Forecast Value of Period
Number of Periods
Factor

Table 16 Forecast Evaluation Variable Definitions

MAD
n

MAD n

At F t

t 1

The mean absolute deviation represents the sum of all deviations of the forecast from the
actual demand divided by the number of periods. With this calculation method, over and
under estimation of actual sales do not cancel each other out. The result is the absolute
average deviation per period.
Possible Values:

ET

Zero to indefinite (positive only)

Error Total
n

ET At F t
t 1

Understanding

104

The total error represents the sum of all deviations of the forecast from the actual demand.
Using the Error Total, over and under estimation of actual sales cancel each other out. High
absolute figures and high amount of periods lead automatically to high total errors as this
method uses absolute and not relative figures. Furthermore the result is not averaged but
accumulated over time.
Possible Values:

MPE

Zero to indefinite (positive or negative)

Mean Percentage Error

*100

MPE

The mean percentage error adds up the relative deviation of the forecast and provides an
average result for the period in question. Over and under estimation of actual sales cancel
each other out using this calculation.
Possible Values:

MAPE

Zero to 100% (positive or negative)

Mean Absolute Percentage Error

MAPE
The mean absolute percentage error adds up the relative deviation of the forecast and provides
an average result for the period in question. With this calculation method, over and under
estimation of actual sales do not cancel each other out.

MSE

MPE

The mean squared error adds up the absolute deviation of the forecast and provides an average
result for the period in question. With this calculation method, over and under estimation of
actual sales do not cancel each other out, as the deviation is always squared and therefore
positive.
Possible Values:

Zero to indefinite (positive only)

Understanding

105

RMSE

MPE

Same as the mean squared error, but providing lower figures due to the fact that the square
root of the summation result is calculated.
Possible Values:

3.4.1.1.2

Zero to indefinite (positive only)

Causal Forecasting

All forecast models explained so far had one assumption in common. That is that future
consumption can be seen as a function of time. Causal models follow a different approach, which
is an explanatory method. The future consumption is determined not as a function of the time but
rather to another parameter, the cause of the demand change. Causal forecasts are not necessarily
time-dependent although the influencing factor could be time (as in the time-based forecasting
techniques). The driver of the forecast, that is the value, which influences the forecast, is called the
independent variable. Simple Linear Regression explains the behavior of the dependent variable in
relation to one independent variable. Multiple Linear Regression (MLR) uses two or more
independent variables to explain the dependent variable. APO offers Multiple Linear Regression,
which includes Simple Linear Regression if only one independent variable is used. The general
formula for Multiple Linear Regression is shown below.

Y a bX1 cX2 dX3......

Y
X
a, b, c, d,

represents the Dependent Variable (that is the value, which is forecasted).

values represent the Independent Variables (these are the values that cause
changes in the forecasted quantity).
are the Coefficients (these are multipliers of the independent variables or the
basic value intercept - in the case of coefficient a).

The formula for the Simple Linear Regression is shown below.

Y a bX1
For both models the sign of the coefficient indicates the relation between the Dependent and
Independent Variable. In case of a positive sign, the dependent variable rises (falls) with a rising
(falling) independent variable and in case of a negative sign the dependent variable rises (falls)
with a falling (rising) independent variable. High coefficient values denote independent variables
with a big influence on the dependent variable and vice versa. Both Linear Regression models
assume a linear relation between the independent and dependent variables. Non-linear relations
cannot be projected using these techniques. During the forecast, the system estimates the values of
the

Understanding

106

coefficients a and b in the case of Simple Linear Regression and additionally the values of
c, d, and so on for Multiple Linear Regression.
The calculation of the coefficients in Single Linear Regression can be understood without
requiring an in-depth knowledge of mathematical functions or statistical models. We shall
therefore go through the basics of Single Linear Regressions but omit the theoretical background
and formulas for the Multiple Linear Regression. For those interested in this topic, I suggest
reading one of the many available books regarding forecasting techniques.
Below are the formulas used in Simple Linear Regression for the slope b and the intercept a.
n

1(Xt X )(Yt Y )

bt

(Xt X )2
t 1

a Y bX
The fit of formula, that is how good the found equation explains the real consumption, can be
assessed using the correlation between the X and Y data points. The Correlation Coefficient
symbolized rxy ranges from 1 to +1. For more information please refer to the section Model Fit
Analysis for Causal Forecast.
The task of the planner is to clearly identify the independent variable that is causing the dependent
variable to react. The problem is that a high correlation between two variables does not necessarily
mean that there is a causal relation between the two.
The Independent Variable needs to be stored to be available for on-line and batch processing. Two
possibilities exist.
1. Variables can be key figures and are stored in the planning area together with the other
forecast related information. At least one key figure (in the case of Simple Linear Regression)
or multiple key figures (in the case of Multiple Linear Regression) need to be defined. This
data is stored per period just like any other consumption or forecast data.
2.

The second possibility is to store time series variables. Time series variables are not stored in
the planning area like the key figures and require the definition in the MLR profile. The
minimum number of time series entries is the total of historical and forecast periods as
defined in the forecast master profile. The time series data is related to a start date that is
specified in the MLR profile. The use of time series is adequate in cases where one does not
want to load the independent variable into a key figure. It has the disadvantage that it has to
be edited every time a forecast is carried out in a new time period.

Should an independent variable for a given period only affect the dependent variable with a time
lag, a transformation value can be defined. This transformation value acts as a time offset in MLR.
An example would be that the selling price of a product (independent variable) affects the sales
volume (dependent variable) only 2 months later. The transformation factor is then 2 months. The

Understanding

107

Transformation parameter can only be specified when using a key figure as an independent
variable.
When performing an MLR based forecast in interactive mode, the system switches over to the
Causal tab. This tab displays various control parameters (see the section Model Fit Analysis for
Causal Forecast) as well as the used independent variables.
MLR based forecasts in APO have the strategy identifier 94.

3.4.1.1.2.1

Forecast Fit

Demand Planning offers several tools that allow the evaluation of the Causal Analysis results. The
evaluation result gives the planner a good idea how usable and reliable the forecast will be. These
values are calculated automatically and can be seen on the Interactive Planning Screen. APO can
perform various tests to determine the quality of an MLR result. These tests provide the planner
with information that allows judging whether and how reliable the forecast based on the MLR run
will be. As said before, forecasting is based on probabilities, and even if all tests provide a
perfect fit, care has to be taken as the result is always based on assumptions that most probably
will also be valid in the future but only most probably. The challenge is to forecast as
precisely as possible but to expect at the same time the unforeseeable.
The analytical measurements in APO can be grouped into the first group that measures the quality
(or usability of the entire MLR based forecast) and a second group that provides information about
a specific independent variable. Group one comprises the Goodness to Fit measurements R square
and adjusted R square, the Auto Correlation Test according to Durbin-Watson, and the Mean
Absolute Percentage Error (MAPE). Within the group two we find the Mean Elasticity Test, which
tests the influence of a specific independent variable, the Auto Correlation t-test, and the Durbin-h
Auto Correlation test.
On the MLR tab of the Interactive Planning screen, the four values that belong to group one are
displayed in the top row. Underneath, one can find the other three values of the second group. As
these values are calculated per independent variable, they are shown in separate rows and per
individual variable. In addition the coefficient for each independent variable is shown in these
rows as well as the Constant (a) of the MLR regression formula.

Goodness to Fit
The first question when examining the result of an MLR run is how well the independent
variable(s) explain the dependent variable. During the MLR run a linear formula is calculated
(see above). In the Goodness to Fit test, the deviation between each known historical value
(observation) is compared with the value calculated based on the formula. The difference
between these two values is used to determine the quality of the formula. Two methods are
supported by APO.
1. R square
Calculation of R square, which is shown as R**2 on the Causal tab in Interactive
Planning, is done according to the following formula.

Understanding

108

R2 et2
t 1

e denotes the individual error for each observation.

2.

R square values range from 1 to +1. A value of +1 (-1) indicates a perfect (inverse)
effect of the independent variable on the dependent variable. Values close to Zero
indicate that the MLR model does not explain the behavior of the dependent variable. A
good fit can be assumed for R square values higher than 0.75 (positive or negative). It
must be noted that the R square value tends to rise with the number of observations,
putting the planner under the possibly false impression that the MLR model provides a
good fit.
Adjusted R square
The calculation of the adjusted R square value which is shown as Corr. R**2 on the
Causal tab in Interactive Planning overcomes the problem mentioned above. The
following formula is used.

1 (1 R2 )

k denotes the number of independent variables used in the model.

It is commonly accepted that this method provides a more reliable goodness to fit result.
3.

Mean Absolute Percentage Error

The Mean Absolute Percentage Error adds up the relative deviation of the forecast and
provides an average result for the period in question. With this calculation method, over
and under estimation of actual sales do not cancel each other out. The following formula
is used:

MAPE
Possible values range from Zero to 100%.

Influence of Independent Variables

Once a MLR model is found with a reasonable low R square and/or adjusted R square, it is of
importance to find out how strong the influence of the independent variable(s) is on the
dependent variable. This is done using the Elasticity Test. The Elasticity Test measures the
effect of a one- percent change of an independent variable on the dependent variable. The
effect on the dependent variable is usually different for each observation point. The Mean
Elasticity, which is shown as M elasticity on the Causal tab in Interactive Planning shows
the average percentage of deviation of the dependent variable caused by the one-percent
change of the independent variable. High values for the Mean Elasticity propose a highly
responsive dependent variable.

Understanding

109

Correlation Test
The MLR model should contain only such independent variables as are truly independent
from the dependent variable. Otherwise the model would be recursive and cannot provide
reliable forecast data. The t-test, which is shown as t-test on the Causal tab in Interactive
Planning, provides information about this independence. Correlation is the opposite of
Independence and needs to be avoided. The correlation test does not provide any information
regarding the significance of the independent variable; this is measured using, for example,
the Elasticity described above. SAP recommends leaving all independent variables in the
MLR model that shows a t-test value of greater than 1.4 (positive or negative).

Auto-Correlation Test
Another way to test for Correlation is the Durbin-Watson test. It measures Auto-Correlation in
time series where no time lag is specified. Its range is from Zero to 4 with 2 as the median
indicating the non-existence of Auto-Correlation. Positive Auto-Correlation is depicted by
values between Zero and 2; values from 2 to 4 mean negative Auto-Correlation. Acceptable
values for this test are in the range of 1.5 to 2.5. The Durbin-Watson test is shown as DurbinWatson on the Causal tab in Interactive Planning. It provides information with respect to all
used independent variables. When using time series with lags, the Durbin-Watson test
becomes unreliable and should therefore not be used.
Specifically for time series with defined lags, the Durbin-h test provides useful information
for a single independent variable. It is suitable only for MLR models with a large number of
observations (greater than 100). Auto-Correlation exists for Durbin-h tests with values greater
than 1.96. The Durbin-h test is shown as Durbin h on the Causal tab in Interactive
Planning.

For some of the tests explained above, limits can be defined in a Diagnosis Group that is linked to
the MLR Profile. Should a measured value exceed a limit, an alert can be generated. The alert will
be displayed in the Alert Monitor and indicated in the Supply Chain Cockpit along with any other
possible alerts. The following limits can be defined:

R square lower limit

Durbin-Watson lower limit

Durbin-Watson upper limit

Durbin h upper limit

t-test lower limit

MAPE upper limit

Any value that exceeds the limit is displayed with a red background on the MLR tab of the
Interactive Planning Screen.

3.4.1.1.3

Judgmental Forecasting

Judgmental Forecasting is a manual task where various specialists within a given interest group
come together to develop a demand plan. The input they provide is based on their respective
knowledge and experience. No formalized input media can be defined. During such a session, a
joined demand plan will be worked out and captured in APO. This can be done using the

Understanding

110

Interactive Planning Screen. The decision finding and consequent data input is a manual task. No
mathematical or other validation of the captured data takes place.

3.4.1.1.4

Composite Forecast

Composite Forecasting is a method where various forecast results are joined together to form a
new forecast. Composite forecasts are usually generated automatically based on the result of
mathematically derived forecasts such as univariate and/or causal forecasts. A composite forecast
represents the view of a certain interest group (e.g. the sales department). In opposition to this, the
consensus-based forecast (see separate section) is the result of a consensus meeting where various
interest groups (e.g. the sales and the marketing department) jointly formulate a common forecast.
Composite Forecasting is an approach where various alternate forecasts using different forecasting
models are combined into one forecast. The benefit is that the forecasts using different models
(time series based and causal) with different strengths and weaknesses are combined into one
forecast and, by doing so, overcome the individual models weaknesses. Composite forecasts are a
combination of different models from a planner with a given business goal or view (e.g. the longterm sales forecast view). Composite forecasts are known for their excellent quality and reliability
provided the composition rules are defined with care.
The composition is carried out according to mathematical rules such as average of, greatest of all,
or others. The rules and the weighting of the forecasts that provide input to the Composite
Forecast are defined in the Composite Forecast Profile. Within APO the Composite Forecast has
two or more components, time series based forecasts and causal forecasts. Its parameters are
defined in the Composite Forecast Profile. The composition of the forecasts can be defined as a
time-dependent parameter. Note that macros are used in Consensus Based Forecasts, but not for
Composite Forecasts.

3.4.1.1.5

Consensus Based Forecast

The Consensus Based Forecast is the result of a consensus meeting where various interest groups
(e.g. the sales and the marketing department) jointly formulate a common forecast. Input to the
consensus-based forecast can be any type of forecast, univariate, causal, judgmental, composite, or
manual.
Consensus Based Forecasting, although it might sound like it, is not another forecast model or
composition of forecasts. It is an approach that describes the process where various parties involved in
the final forecast meet and agree on an overall forecast. Different interest groups represented in such a
consensus-based forecast meeting are, for example, the long term strategic planning group, the medium
term tactical sales group, the short term marketing group, and the medium to short term operations
(supply chain management) group. APO provides on-line display of forecasts in absolute and relative
numbers, as well as graphical displays with easily adjustable forecast figures. By doing so it supports
the process of Consensus Based Forecasting. APO refers to this as well as Collaborative Forecasting.
The term judgmental forecast is used predominantly when all

Understanding

111

participants of the forecast meeting are of the same company. Collaborative Forecasting describes
a forecasting process in which stakeholders of various companies participate.
The difference to the judgmental model is that here several stakeholders (interest groups) from
different business areas find a consensus; whereby in the judgmental model one or multiple people
from the same business area develop a forecast.
The task of a Consensus Meeting is to either capture the forecast values manually into the
system (see Manual Forecast) or it could also be the development of an advanced macro, which
will then subsequently be applied to a whole range of products. The creation and execution of
macros is dealt with in a separate section.

3.4.1.2

Planning Approach

Common to all forecast techniques is the deployment of a bottom up, middle through or top down
planning approach. APO stores data consistently, not disproportional, over all levels using
aggregation and disaggregation factors. This ensures that the sum (or average) of all forecast
values in one level of the hierarchy is equal to the figure shown on the next hierarchy level.
Distribution is carried out by means of Proportional Factors or using the Pro Rata approach.

Top-Down Planning
Top -Down Planning starts at the highest level of the hierarchy and uses Proportional Factors or
the Pro Rata Method, which will distribute the forecasted quantities to all subordinate levels down
to the lowest level. The advantage of a Top-Down Planning approach is that only one value on a
high level is forecasted and all dependent values are updated automatically by the system.
Proportional Factors can be defined to be either valid for a certain period or for the entire planning
horizon. The definition of proportional factors is based on historical data, on the planners input,
or on both. It is a disadvantage of this planning approach that data on the lower levels are subject
to higher deviations. The key is the quality and reliability of the proportional factor.
Example:
A canned food manufacturer might define as the top level (level one) of the planning hierarchy the
product group of Canned Vegetables. One level down, one could find a breakdown according to
the Vegetable Type (e.g. beans, tomatoes, and carrots). Finally, on the third level, the
distinguishing characteristic is the shipping Location, which is defined per vegetable type. There
are two locations Denver and Atlanta. Before forecasting is carried out, the planner will
generate all proportional factors from level one to level two and then from level two to three. This
task is carried out either by calculating proportional factors based on historical data or is captured
by the planner. This approach with the corresponding factors is shown below. It is assumed that
the 3 sets of proportional factors for level two are valid only within the given periods. For level
three (locations) the proportional factors are the same for the whole planning horizon.
Data Table:

Month/Quarter
Understanding

Month/Quarter
07/99

112

08/99
09/99
III/99
Table 17 Top Down Planning Example
The total forecasted demand for the quarter III/99 is 10.000 cans per month or 30.000 for the
whole quarter. The resulting distributed demands can be seen in the illustration below.

Month 07/99

Beans

%
0

800 Cans
Beans
Denver
25 / 40 %
1,000
25 / 40 %
1,000
Total
2,800

Graphic 22 Proportional Factors Example

The blocks at the bottom of the graphic show the values for the other two months 08/99 and 09/99
as well as the total for the quarter. Each block provides the following information:

Understanding

113

Line 1: Share in % of level 2 from upper level 1 and of level 3 from upper level 2 (month 08/99).
Line 2: Absolute quantity after applying the percentages through both levels (month 08/99). Line
3: Share in % of level 2 from upper level 1 and of level 3 from upper level 2 (month
09/99).
Line 4: Absolute quantity after applying the percentages through both levels (month 09/99).
Line 6: Total absolute demand for quarter III/99
Any change in forecasted quantity of the product group Canned Vegetables leads to an update of
the Vegetable Type and the Location forecast quantity. This approach can be used if the
proportions between the various vegetables and the respective locations are stable and a change in
demand applies to all products in the same way. That means if more beans are sold the demand for
carrots also goes up, and at the same time the production split over the different locations remains
the same.
Although not specified above, another distribution rule was incorporated in our model. It is the
rule that demand of a quarter can be distributed evenly over the three months. Any change on the
lowest level would automatically update the two superior levels and recalculate the proportional
factors.
The section Aggregation and Disaggregation provides a detailed introduction to all APO
supported data aggregation and disaggregation methods.

Bottom-Up Planning
Bottom-Up Planning is an approach where forecasts are carried out at the lowest level. From there
the system aggregates forecast data automatically to the superior levels.
The advantage of a Bottom-Up Planning approach is the creation of a very detailed forecast on the
lowest level with high quality data being passed to the next level. This approach can be used when
combining forecasts from various sources as it is the case with Vendor Managed Inventory
(VMI).
Example:
Let us look at the previous example of the canned food manufacturer. Using the same environment
the following data has to be determined to derive the consolidated demand plan.
Data Table:

Can Size per Month

Denver
Denver
Denver
Understanding

114

Can Size per Month

Atlanta
Atlanta
Atlanta
Table 18 Bottom Up Planning Example
The result obviously will be the same as in the previous example, a demand of 10,000 per month
and 30,000 for the quarter. For this reason no graphical presentation of forecast data aggregation is
included. The emphasis is to understand that the Bottom-Up planning requires more input-data
compared to the Top-Down approach.
The section Aggregation and Disaggregation provides a detailed introduction to all APO
supported data aggregation and disaggregation methods.

Middle-Through Planning
Middle-Through Planning is a combination of the Top-Down and Bottom-Up planning approach.
It is used where the Top-Down approach using proportional factors does not provide the required
accuracy on the lower levels, but where at the same time the lowest level approach of the BottomUp approach is either not required or not possible. Another situation might be one in which a VMI
customer provides forecasts on product group level only, and the manufacturer breaks this demand
down into products using proportional factors. As long as the proportional factors are the same
over the time, this approach will work well.
Example:
We shall again follow up on our previous example. The data required to generate the demand plan
is somehow in the middle between the Bottom-Up and the Top-Down approach.
Data Tables:

Quarter
III/99
Table 19 Middle Through Planning Example 1

Cans per Month

07/99
08/99
Understanding

Cans per Month

09/99
Table 20 Middle Through Planning Example 2

115

The system applies the proportional factors to distribute the demand of cans into the subordinate
level to derive the demand per location. The aggregation provides the totals per month and quarter.
The section Aggregation and Disaggregation provides a detailed introduction to all APO
supported data aggregation and disaggregation methods.

Comparison of Planning Approaches

Each of the planning approaches described above requires an estimation of demand (the forecast)
to be carried out. The difference, as we have seen, is the direction in which forecast data is either
consolidated (aggregated) or distributed (disaggregated). It is important to understand that using
the same historical data, the three planning approaches can lead to substantially different results.
The following example illustrates this effect.
Example:
We are investigating the demand for two products, Orange and Pineapple Juice. They are the only
members of a product group Juices. The historical demand per product as well as the accumulated
product group demand can be seen in the following table.

Product
Orange Juice
Pineapple Juice
Group
Juices
Table 21 Planning Approach Comparison: Historical Data
We now investigate the results of the forecast based on the two planning approaches Bottom Up
and Top Down. The third planning approach, Middle Through as a combination of the two
aforementioned would react the same way, depending on the direction you plan.
Bottom-Up Planning
We can see easily that Orange Juice is on the incline. Sales increase month by month steadily by
20. In opposition to this, the Pineapple juice is not doing well and sales are declining every month

Understanding

116

by 10. Based on a univariate-forecast model, the result would be a trend upwards for the Orange
Juice and a trend downwards for the Pineapple Juice. On the product group level the total demand
appears to be inclining. It is calculated by means of aggregation type Total. The first forecast
result is as follows:

Product
Orange Juice
Pineapple Juice
Group
Juices
Table 22 Planning Approach Comparison: Bottom-Up
Top-Down Planning
With this planning approach and when applying the univariate forecast, the planning will be
carried out on product group level first. In a consequent calculation the forecasted demand will be
distributed using either an even distribution or, if defined, a proportional factor. In our example we
assume a proportional factor with the value 66.6% for Orange Juice and 33.4% for Pineapple
Juice. The second forecast result is as follows:

Product
Orange Juice
Pineapple Juice
Group
Juices
Table 23 Planning Approach Comparison: Top-Down
Comparison of Results:
Bottom Up planning indicates an even stronger demand for Orange Juice in the future. Using the
Top Down planning approach we have an estimated moderate increase for both juices! This is
obviously a simplified example, but the principle is clear. If a planning group (in our case the
Juice) has members with opposite trends (Orange and Pineapple Juice), then the planning result
using a Top Down approach will probably give wrong results.

Understanding

117

We could overcome the latter problem by projecting time dependent proportional factors per
month. But then we get into the area of forecasting proportional factors, which in the long run
might be even more complicated and less transparent than carrying out the forecast on product
level in the first place.

3.4.1.2.1

Aggregation and Disaggregation

Forecasting is not always carried out on the same planning level (e.g. product or product group).
This was explained in the Planning Approach section. Because of this it is required to somehow
aggregate data (with bottom-up and middle- through planning) or disaggregate data (with topdown and middle-through planning). The process handling these calculations is called
Aggregation and Disaggregation. In the case where Totals (Aggregates) are created, aggregation is
simply an addition of all values of a given level where the result is stored on the higher level.
Another possibility is to store the average of all elements of the subordinate level on the superior
level. Distribution (Disaggregation) takes place according to Proportional Factors or using a Pro
Rata method. Proportional factors can be derived from historical data before the first forecast is
carried out or defined manually. The proportional factor with the fixed key figure name
APODPDANT relates to exactly one key figure (e.g. the key figure containing the historical
data or the corrected history. Other than that it is possible to carry out aggregation and
disaggregation based on any key figure of the planning area. It is thus possible to aggregate and
disaggregate various key figures at the same time according to different other key figures, one of
them possibly (but not necessarily) being the predefined key figure APODPDANT.
Aggregation and disaggregation happens automatically in the background while creating or editing
forecast values. Aggregation and disaggregation rules are defined per planning area. The
calculation of aggregated and disaggregated key figures is obviously resource intensive.
Proportional factors are defined as decimal values ranging from Zero to 1 (also displayed as
100%) with the total being 1.
When using proportional factors for disaggregation, great care must be taken in the following
scenario. Based on historical demand proportional factors are calculated. After this calculation is
carried out, a new characteristics value combination is set up in the system. This new combination
obviously carries a proportional factor of Zero, as it was not defined while calculating the factors.
A rerun of this calculation would not change the situation, as the past demand for the new
characteristics value combination is Zero. Forecasting on a higher level with subsequent automatic
distribution of the forecasted demand figures will allocate no forecasted demand to this new
characteristics value combination. Worse, it will possibly even overwrite an existing value
manually defined specifically for this new characteristics value combination. To avoid this, it is
mandatory to fix the forecast value so that the distribution does not overwrite it. A regeneration of
proportional factors should be carried out afterwards to not carry forward this problem. See also
the chapter Fixing of Values.
The enabling technology for aggregation and disaggregation is the macro. Macros are defined
calculation procedures to manipulate data in a planning book and its rows, columns, and cells. The
aggregation and distribution macros are predefined and therefore only need to be applied, rather
than being developed and applied. For further information regarding macros refer to the chapter

Understanding

118

Advanced Macros. The aggregation and disaggregation types are defined in the planning area
parameters.
Data is not only aggregated and disaggregated vertically, as described above, but also horizontally
over time. The aggregation rules are obvious, but disaggregation can be carried out in several
ways.
The following aggregation and disaggregation rules can be set up:
Vertical Disaggregation and Aggregation (level to level)

Calculation Type S Pro Rata

Activity
Disaggregation
Create
Exception
Change
Aggregation
Create
Change

54 Pieces

Graphic 23 Type S1D

Understanding

119

180

60 Pieces

60

Pieces

Pieces

60

Pieces

Graphic 24 Type S2D

54 P
72 P

Graphic 25 Type S3D

60

Pieces

60

Pieces

60 Pieces

Graphic 26 Type S1A

Understanding

60

Pieces

Graphic 27 Type S2A

54 Pie

144 Pie

Graphic 28 Type S3A

Calculation Type I Pro Rata 2

Activity
Disaggregation
Create
Exception
Change
Aggregation
Create
Change
Understanding

Graphic 29 Type I1D

180

Pieces

Graphic 30 Type I2D

54 P
72 P

Graphic 31 Type I3D

Understanding

60

122

60

Pieces

60

Pieces

Pieces

Graphic 32 Type I1A

60

Pieces

Graphic 33 Type I2A

Graphic 34 Type I3A

Understanding

Calculation Type P Based on another Key Figure

Activity
Disaggregation
Create / Change
Exception
Aggregation
Create / Change

Disaggregation
Key Figure does
not exist

Graphic 36 Type P2D

Understanding

124

60

60

Pieces

Pieces

Graphic 37 Type P1A

60 P

Graphic 38 Type P2A

Calculation Type A Average of Key Figures

Activity
Disaggregation

Create
Change
Aggregation
Create / Change

$
$

Graphic 39 Type AD

$
$

$6 . 0 0
$

Graphic 40 Type AA

Calculation Type N No Disaggregation

Activity
Disaggregation
Create / Change

Aggregation
Create / Change

Understanding

disappears when leaving the transaction

100

Pieces

Graphic 41 Type ND

Graphic 42 Type NA

Horizontal Disaggregation (over time)

Time Based Disaggregation Type

P

Description
Proportional distribution of the initial
according to the period length. The sum o
equals the initial value.
Equal distribution of the initial value to e
of the period length. The sum of the perio
initial value.

The same initial value is copied into each

Understanding

period values is greater than the initial va

Proportional
figure. The disaggregation key figure is a
planning area. The sum of the period valu

value.
Aggregation is always according to the calendar or fiscal year variant.
There are no differences between create and change mode.

Month

Week

Graphic 43 Used Calendar for Examples

Initial Value

Disaggregated
Values

Graphic 44 Type Time 1

Initial Value

Disaggregated
Values

Graphic 45 Type Time 2

Understanding

128

Initial Value

Disaggregated
Values

Graphic 46 Type Time 3

Initial Value

Disaggregation

Key Figure
Disaggregated
Values

Graphic 47 Type Time 4

3.4.1.2.2

Fixing of Values

Fixing of values is a technique where one or multiple values on the lowest level in the planning
hierarchy are fixed. The lowest level of the planning hierarchy is the one where all values of a
characteristics value combination are defined explicitly and physically stored. In other words, no
aggregation has been carried out whatsoever. If aggregates are defined for a planning area, it is
possible to also fix values on the aggregated level. Fixed values do not get changed during the
distribution (disaggregation) of data from a superior level to the subordinate level. Fixing of
values works the same way, irrespective of whether the Pro Rata method is used or Proportional
Factors. This technique is extremely useful when adding new characteristics value combinations.
Fixing of Values has no impact on the aggregation as all data values on the subordinate level are
used to aggregate according to the average or total principle.
Fixing or unfixing of values is initiated by activating the context sensitive menu on the cell (of the
forecast or any other value) which should be fixed, and selecting Fix/Unfix Value.
Example:
The following example is based on the Distribution Type Pro Rata in conjunction with
Aggregation Type Total Change.
The system carries out the following calculation:

Understanding

129

Step 1
Step 2
Step 3
Step 4

Calculate quantity to be distribut

Calculate factor for product B
Calculate factor for product C
Calculate quantity for product B

Step 5

Calculate quantity for product C

In order to store fixed values for a key figure, it is required to define a second key figure that
contains the fixed values. This second key figure must have the suffix F. If for example the used
key figure is called ABC01, then the key figure to store the fixed value must be named
ABC01F. The fixing of a value can be performed on-line irrespective of whether this second key
figure exists or not. The problem is that without the second key figure being defined the fixed
value cannot be stored separately.

Graphic 48 Proportional Factors: Fixing Before Editing

150

Pieces

ProductC86Pi
eces

Graphic 49 Proportional Factors: Fixing After Editing

Understanding

130

The following practical example joins the aspects of Characteristics Value Combination creation,
the calculation of Proportional Factors, and the Fixing of Values. We start off with a table that
gives us the historical demands per product, customer, and location for the last three months. The
last column shows the Proportional Factors, which were calculated based on the total demand in
these periods. To simplify the example, a constant model is used.

Product
Needles
Needles
Needles
Needles
Pins
Pins
Pins
Table 24 Planning Example 1
There are no sales of the product Pins to customer Brown from our location Atlanta. This is
depicted in the table below.

Product
Pins
Table 25 Planning Example 2
Characteristic Value Combinations are now defined for all those combinations where demand
existed in the past. This is done using the Mass Generation function. Additionally we define a
Characteristic Value Combination for the new combination as shown in the second table. In a
bottom-up approach, we forecast the demand for the new Characteristic Value Combination Pins
Smith Atlanta to be 1000. Additionally we fix this value! In a top-down approach, the
demand per product is forecasted to be 2000 for Needles and 3000 for Pins.

Product
Needles
Needles
Needles
Understanding

Product
Needles
Pins

131

Pins
Pins
Pins
Table 26 Planning Example 3
Note that the forecasted demand for the product Pins is not distributed over the fixed value. In the
last column the new Proportional Factor including the new Characteristic Value Combination is
depicted. It was calculated after all planning was carried out. The overall total new forecasted
demand is now 6000 and the Fixing can be released.

3.4.1.3

Life Cycle Management

In some instances historical data should be adjusted before the forecast is carried out. Reasons
may be the quality of data (outlier correction), period adjustment (workday correction), or the
requirement to consider the products life cycles (life cycle management).
Any new product requires some time to gain general acceptance. This phase-in period is
different for each product and requires careful planning in order to avoid initial oversupply. After a
while the product will fall into its normal demand pattern, whether that is a constant, trend,
seasonal, or any combination thereof. Towards the end of the products life cycle, a slowdown of
demand can usually be seen which is either due to market saturation or the expectation of the new
successive product. This period called phase-out requires accurate planning, as it is usually very
difficult to sell the product after a certain point in time.
Life Cycle Management is the tool in APO to model product life cycles and consider them during
the forecasting process. Various life cycle patterns can be set up to determine the demand pattern
for a product throughout its whole life cycle while taking into consideration factors like product
switching or cannibalization, market penetration, or market fatigue to name a few. In actual fact,
the profiles in APO are not attached to a specific product but to one or multiple characteristics.
The most likely characteristic used will be this for the product (9AMATNR in the standard
delivered DP planning area). But it is also possible to add or use up to 6 characteristics. If life
cycle management has to be possibly carried out with different values per product and location,
then the characteristic for the location (9ALOCNO in the standard delivered DP planning area)
should be used as well. The definition, which characteristics are to be used, is defined per planning
area.
Understanding

Also note that the described functionality of Life Cycle Management is not an extension of the
SAP mySAP module Product Lifecycle Management, which is a by far more sophisticated and
complex tool installed separately from APO and for other purposes.
Within APO, tools for the creation of Phase-In and Phase-Out profiles as well as LikeModeling profiles exist. Life Cycle Management profiles do not work in conjunction with
Multiple Linear Regression, as this would contradict the approach of multiple linear regressions.
The same applies when using composite and manual forecasts.
It is possible to define phase-in, phase-out, and like profiles for the same set of characteristics.
The following text refers generically to products as the objects for Life Cycle Management.
Please note that the system permits to apply Life Cycle Management correction factors as
defined in the profiles not only to products but also to other freely definable characteristics
and combinations thereof.

Phase-In Process
The planner defines a percentage value for the Phase-In periods of the product. These percentages
are the relation between this periods consumption and the normal or mature consumption
that will be achieved after the products Phase-In period is over. The percentages increase
therefore from period to period (e.g. month to month), up to the time where they reach 100%.
This indicates that the Phase-In period is at its end.
Example:
A new product will be launched. The Phase-In period is estimated to last 4 months starting in
January 2002 and to finish in April 2002, after which the normal consumption of 25,000 pieces
per month is reached. At the end of the Phase-In period, a constant model will explain the
demand figures. The estimated demand figures for the new product are shown in the following
table. The Estimated Sales (%) is the relation between the months sales forecast and the
mature demand, which will be reached in May 2002 and continue from there onwards.

Estimated Sales (Pieces)

Estimated Sales (%)
Table 27 Phase-In Process Example 1
All that needs to be done when setting up the new products Phase-In profile is defining the four
percentages (30, 50, 60, and 80) for the Phase-In period and the constant sales of 25,000 pieces
per month. If we are now running the forecast for April 2002 onwards, either interactively or in
batch mode, the system will correct the historical data. It will then estimate the future sales as
follows:

Understanding

133

Original History (Pieces)

Corrected
(Pieces)
Estimated Sales (Pieces)
Table 28 Phase-In Process Example 2
What happened? To make it easier lets assume that forecasted sales and actual sales for the
months January to March 2002 are identical. The original sales figure for January, as an example,
is 7,500. The Phase-In percentage is 30%. The system now divides 7,500 pieces by 30% to receive
the normal sales of 25,000. This step is repeated for all months in the Phase-In period up to the
current date. As we can see easily, the consumption is according to a constant model and in return
the forecasted sales for May and June 2002 is 25,000 as well. In the month of April, which belongs
to the Phase-In period, the estimated sales have to be adjusted in accordance with the Phase-In
profile (80% of 25,000).
The above example could be enriched by also specifying a Like profile, which provides the history
for the new product based on the Like product.
No doubt, this process can be much more complex when planning products, which are assumed to
have a seasonal trend pattern! But the principle and the steps involved are the same.
The Phase-In Profile is a tool to correctly predict sales based on the planners knowledge
regarding the Phase-In behavior of a product. APO firstly corrects the demand in the Phase-In
period as if there is no Phase-In period, secondly it forecasts demand according to a model, and
then thirdly adjusts forecasts if the period in question is still within the Phase- In period. The
periods used are in accordance with the planning periods and do not necessarily have to be months
(as in our example).
Phase-Out Process
The planner defines per period a percentage value for the Phase-Out period of the product. This
percentage is the relation between this periods consumption and the normal or mature
consumption that was usually achieved. The percentage decreases therefore from period to period
(month to month), up to the time where it reaches Zero.
Example:
A product is about to be discontinued. The Phase-Out period is estimated to last 4 months starting
in March 2002 and to finish in June 2002, after which no demand will exist anymore. At the
moment a constant model explains the demand figures. The estimated demand figures for the

Understanding

134

product are shown in the following table. The Estimated Sales (%) is the relation between the
months sales forecast and the mature demand that exists up to February 2002.

Estimated Sales (Pieces)

Estimated Sales (%)
Table 29 Phase-Out Process Example 1
All that needs to be done when setting up the discontinued products Phase-Out profile is defining
the four percentages (80, 50, 20, and 10) for the Phase-Out period. If we are now running the
forecast for April 2002, either interactively or in batch mode, the system will correct the historical
data. It will then estimate the future sales as follows:

Original History (Pieces)

Corrected
(Pieces)
Estimated Sales (Pieces)
Table 30 Phase-Out Process Example 2
What happened this time? We again assume that forecasted sales and actual sales for the months
January to March 2002 are identical. The system calculates a demand of 25,000 pieces per month
for the three months of April through to June. It then applies the Phase-Out percentages, which
provides as an example, the final result of 12,500 pieces for the month of April 2002.
The Phase-Out Profile is a tool to correctly predict sales based on the planners knowledge regarding
the Phase-Out behavior of a product. APO adjusts forecasts if the period in question is within the
Phase-Out period according to a planner-defined percentage. The periods used are in accordance with
the planning periods and do not necessarily have to be months (as in our example).

Like Modeling
Like Modeling is used in a case where for a product
No historical data exists
Not sufficient historical data exists
Only unreliable historical data exists

Understanding

135

It is a basic method where the historical data of one or multiple Like products are used for the
forecasted product. In the case where the Like profile refers to multiple Like products, it is
possible to define either the sum or average the referred Like products demands. After this
definition has taken place, forecasting takes place the normal way. To enable Like Modeling it is
necessary to define the Like Product(s) in a Like Profile that is then attached to the product to be
planned.
The option to use the average of various products can improve the planning quality in cases where
a product behaves similar to a number of products. This is even more the case in situations where
the Like Products have a somewhat erratic demand. Summing up the demand of various products
is used when a new product replaces a number of old products. Using Like profiles, it is also
possible to have a time offset between the Like product and the forecasted product.

3.4.1.4

Promotion Planning

Promotion Planning allows planning of entire sales campaigns for a product or a product range to
add Market Intelligence to the forecast developed initially. The promotion level (e.g. product or
product group) can be defined freely. This allows planning promotions on any level as long as this
level is defined as a planning characteristic of the planning area. The term Promotion Level is
used by SAP to describe the lowest level at which the promotion is stored. This is usually, but does
not have to be, the product level. In the following text the generic term product is used to
describe promotion planning on any level. The planning of promotions is a complex task, which
often is not carried out properly due to missing or inadequate system support. APO offers tools to
cope with effects like cross product cannibalization and deferred consumer purchases to name
only two of the most common challenges when planning and evaluating a promotion. Various
products can be listed in a cannibalization group and used for various promotions. Cannibalization
groups can also include products that are positively affected by a promotion of another product.
Promotions cannot be created for past periods. Let us work with an example.
Example:
We are planning a promotion for a washing detergent (promoted product) where a fabric softener
(banded product) is attached free of charge. Obviously there are several effects that have to be
taken into account. First, consumers will buy this special instead of other manufacturers products,
which is the idea. But there are also various side effects:

The consumer purchases the special instead of our own other product; we cannibalize this
other product and have to reduce its projected sales.

The consumer would have bought the regular product in either case and just buys more (early
purchase), which leads to a dip in the sales in the future.

The banded product will probably see lower sales as the consumer gets it free with the
promoted product and does not need to buy it separately.

Alternatively, the consumer might like the banded product after trying it and purchases it later
on its own. This again is a desired effect.
All these effects need to be planned carefully, and APO here allows reference to past promotions
as an aid.
Promotion Planning has two purposes:

Understanding

136

Plan future promotion the purpose here is to plan an upcoming promotion, which will
ensure the right stock levels are maintained to cope with the promotion demand.
Exclude past promotion effects on history the purpose here is to correct past demand, which
was influenced by a previous promotion. This ensures the right stock levels to cope with the
normal demand in future periods.

APO offers tools that ensure a strict separation of forecasts derived from historical data or other
methods on the one side, and promotion planning on the other. This separation also allows
carrying out forecasting and promotion planning in separate steps and by different planners.
Promotion plans are stored separated from the base forecast. It is therefore possible to subtract the
promotion plan from the actual sales to correct the sales history. By doing so, time-based forecasts
provide more reliable results. Promotion plans can be defined for the whole supply network or
portions thereof. The periodicity used for the promotion plan does not have to coincide with that
of the forecast as long as the used periodicity is defined in the storage buckets profile linked to the
planning area. Promotions can be viewed by product (which might show several promotions) or
by promotion (which might show several products).
Promotion Planning in APO offers the definition of the Promotion Plan
In Absolute Figures
With this option the promotion quantities per period are defined by the planner in absolute
figures per product. They are then aggregated automatically by the system to make up the
total promotion quantity.

In relative figures
With this option the promotion is defined by the planner as a percentage of the promoted
products base forecast. The same percentage applies to all products of the promotion. The
defined percentages per period are used by the system to calculate for all products their
absolute quantities during the promotion. The usage of relative figures requires the existence
of a base line forecast beforehand.

Based on past promotions

Past promotions (absolute or relative) can be used to create new ones. These newly created
promotions can be edited as required. The same principles, as explained above, apply.

Promotion Planning is carried out using the Promotion Planning Screen and not the DP Interactive
Planning Screen. The Promotion Planning Screen appearance is similar to the DP Interactive
Planning Screen. The results of the promotion planning activities are visible in the DP Interactive
Planning Screen if the promotion is active. Basic promotion plans could also be defined in the
Interactive Planning Screen using custom developed macros. This approach is helpful for small
and uncomplicated promotion plans. In this case it is still required to define specific key figures
for the promotion values into which the macro writes the data. While doing so, it is also possible
to pick up promotion plans that are in the past. The history on which the forecast is based can then
be corrected.
Example ctd.:
The following example is based on the promotion described above. The promotion runs from
week 1 through to week 4. We shall be planning the promoted product, the banded product, and a
cannibalized product. The planning of the promoted product is done in relative figures, which will
be then used by the system to calculate absolute figures. The absolute figures of the promoted
product are used to calculate the additional demand of the banded product. The assumption here is

Understanding

137

that half of the additional demand of the banded product is additional demand, the other half
results in lost sales of the banded product. This is true only for the period of the promotion (week
1 to 4).

Promoted Product
Baseline Forecast
Promotion (%)
Promotion (absolute)
Table 31 Promotion Planning Example Promoted Product

Banded Product
Baseline Forecast
Promotion (%)
Promotion (absolute)
Table 32 Promotion Planning Example Banded Product
An interesting aspect for the banded product is that its forecasted sales demand drops (as shown
above), but therefore we will have additional dependent demand. This dependent demand is
caused by the banding of the promoted product together with that of the banded product. There are
several ways how to model these dependent requirements within DP and SNP. They are discussed
separately.
We also have a cannibalized product, which is similar to the promoted product. Its sales will drop
with a rate of 20% of the increase we achieve on the promoted product the week before (decrease
of sales of the promoted product have no influence). This effect lasts throughout the promotion.
All products have a baseline forecast based on a constant model.

Cannibalized Product
Baseline Forecast
Promotion (%)
Promotion (absolute)
Table 33 Promotion Planning Example Cannibalized Product

Understanding

138

The above quantitative relations between the products can be modeled directly in Promotion
Planning but not by using a cannibalization group. The cannibalization group does not provide the
possibility to specify time lags (offsets). Under the assumption that there is no time lag we would
have the following quantity structure.

Product
Promoted
Banded
Cannibalized
Table 34 Promotion Planning Example Cannibalization Group
Although the example above referred to a promotion carried out on the product level, it is possible
to plan promotions at any level of the planning hierarchy (e.g. for a product group or an entire
brand). Promotion plans would then be based on an aggregated set of data and distributed to
product level automatically.
The standard procedure when releasing the unconstrained DP forecast to SNP is to use exactly one
DP key figure and then transfer its values to SNP where independent requirements are created.
When using Promotion Planning, it is necessary to write a macro that adds the corrected forecast
to the promotion values and stores it subsequently in a new key figure. This new key figure is then
used for the release from DP to SNP. Do not overwrite either the corrected forecast, or the
promotion planning key figures! When releasing the DP plan to SNP, use this new key figure
instead of the corrected forecast. Alternatively, the two demands, base forecast and promotion, can
be released to SNP separately as two different independent requirements. This is extremely helpful
within SNP when calculating safety stocks that should not be adjusted due to promotions.

Promotion Patterns
Once a promotion has been carried out, promotion patterns can be calculated for usage in further
new promotions. The promotion pattern is calculated based on a linear regression or seasonal
linear regression method. It uses the historical data and bases an ex-post forecast on it. The
difference between the historical data (the real sales) and the ex-post forecast (representing the
expected sales without a forecast) are seen as caused by the promotion. The newly calculated
values can be stored in a time series and then be subsequently used to create other promotions
without the need to specify all promotion values per period.

Promotion Evaluation
The task of promotion evaluation is to provide the planner with feedback regarding the monetary
aspect of the promotion. Promotion evaluation is an optional activity that can be carried out per
promotion if required. The promotion evaluation functionality in its current form is very basic, as
it

Understanding

139

does not cater for quantity dependent cost and other important factors. The terminology used in the
SDP Interactive Planning Promotion View is likely to cause confusion and requires some
definitions. The following terms are used per promoted product.

Phrase
Base Forecast

Promotion

Planned Total
Planned Price

Promotion Price

Planned Sales

Promotion Sales

Table 35 Promotion Evaluation Terminology Lines

The following terms are used for the promotion header.

Phrase
Costs
Planned Sales

Understanding

Phrase
Promotion Sales

140

Profit

Table 36 Promotion Evaluation Terminology Header

All the values explained above are totaled in the last row to provide the promotions overall
profitability.

Promotion Attributes
APO permits the definition of up to 10 Promotion Attribute Types. These types are freely
definable texts that are attached to the promotions. Their only function is to support the search for
promotions according to their attributes.

3.4.2

Demand and Supply Calculation

What is the demand at a certain point in time? It depends on how you have customized the system.
APO offers a highly flexible approach for calculating the demand used in the SNP module. The
standard delivered system comes with a whole lot of settings. They are not unchangeable
definitions but rather a collection of settings that are business proven and logical within. It is
advisable to first try to fully understand them and in a second step change them, if needed, to cater
for the exact business requirements where applicable.
All stock, receipt (supply), and issue (demand) elements are reflected by orders, which in turn are
allocated to order categories. The order categories are also referred to as the ATP categories as
they are also used to setup the ATP logic. The majority of order categories is matched by an R/3
MRP element, but keep in mind that the used identifiers are totally different. In the case of
demand calculation, obviously only those elements referring to demand are of interest. The
definition of the order categories does not require any customization. Order categories are
allocated to category groups whereby any order category can be allocated to several category
groups. APO comes with a whole set of defined category groups that work but might need to be
adapted to suit individual business requirements. A more technical view of the use and adaptation
of order categories and category groups can be found in the section The SDP Planning
Environment.
Understanding

Each of the key figures visible in the SDP Interactive Planning transaction is linked to a category
group. The linkage between key figures and category groups is carried out per planning area.
Within a data view of a planning book it is possible to show the key figures of the planning area
on which the planning book is based. Within the APO system the following five demand key
figures are defined for usage in the standard delivered planning area and book.

Sales Order Demand

Allocated to this key figure should be a category group, which in turn contains all such
categories that deal with Sales Orders and related documents. A related document could be,
for example, a Customer Enquiry or a Scheduling Agreement. Objects belonging to these
categories and category groups originate mostly in an OLTP system such as R/3.

Dependent Demand
APO creates as a result of a planning run or while orders are created, interactively
dependent demand (that is if the planned product has a valid PPM attached to it). All such
dependent demands can be found in this key figure. Dependent demands could also
originate from the OLTP system. They are grouped together in category groups, which again
are linked to the key figure.
Planned Distribution Demand
During an SNP planning run, the planned distribution demand is calculated. Planned
distribution demand represents all planned stock movements between locations in APO. All
objects making up the planned distribution demand are allocated to certain categories and
then grouped in category groups. These category groups are then linked to this key figure.
Confirmed Distribution Demand
Confirmed distribution demand is the output of the deployment activity. Demand objects are
all converted planned distribution demands, as deployment orders cannot be created directly.
These demands are allocated to categories as well, which in turn are allocated to category
groups and finally to this key figure.
TLB Confirmed Distribution Demand
The TLB run finally provides the planning of the imminent shipment. The TLB confirmed
distribution demands are also allocated to categories, which in turn are allocated to category
groups and finally to this key figure.
Forecast
The forecast displayed in SNP originates in DP. The DP based forecast is used to create
independent requirements in SNP. These independent requirements are represented by a
single order category that is allocated to a single category group and finally to this key
figure.

What are the benefits of this rather complex setup? The flexible allocation of demand elements
to make up the total demand allows setting up the APO areas of Supply Network Planning and
Deployment precisely to and in accordance with the business needs.
The total demand when using the forecast consumption logic is derived as shown below:
Total Demand
+
+
+
+
+
Understanding

+
Note that in this case the displayed forecast demand is adjusted (reduced) by the incoming
orders. The stored forecast demand as such remains the same.
In situations where the forecast consumption logic is not used, the calculation of the demand is
carried out according to different rules within the forecast horizon and after the end of it. Within
the forecast horizon (that is starting from the present for the number of the days defined here),
total demand is calculated according to the following formula:
Total Demand
+
+
+
+
+

After the end of the forecast horizon, total demand is calculated according to the following
formula:
Total Demand
+
+
+
+
+
This allows coping easier with situations where the forecast was over or understating the actual
demand. Within the forecast horizon (which is actually the time where the system does not
bother what the forecast is, demand is calculated irrespective of the forecast). After the end of
this forecast horizon, APO compares the key figure Sales Order Demand with the key figure
Forecast and uses the greater of the two before adding the other demand key figures. The
question when the forecast horizon should be set depends on the individual business
requirements.
Like the demand definition, the supply definition is also highly customizable but not to the same
degree. As mentioned before, all stock, receipt (supply), and issue (demand) elements are
reflected by order categories, which are allocated to category groups. For supply calculation
purposes, the category groups are linked to the Supply Key Figures. In the standard delivered
APO system the following seven supply key figures are defined for usage in the standard
delivered planning area and book.

Planned Production Supply

Planned production orders are created by the SNP or PP/DS planning runs or interactively
by the respective planner.
Joint Production
Joint production products are also referred to as by-products. While manufacturing the main
product, the by-product is manufactured at the same time. For APO purposes it is of no
interest whether the by-product is manufactured purposely or not. Under this key figure you
only find

Understanding

143

the by-product, not the main product, which can be found under the key figure Planned
Production Supply.
Firmed Production Supply
Allocated to this key figure should be category groups that contain all such categories that
deal with production orders, which are firmed. Objects belonging to these categories and
category groups usually represent orders dealt with by PP/DS. They are already in a finite
planning status.
Planned Distribution Receipt Supply
In this key figure, planned transportation orders run can be seen.
Confirmed Distribution Receipt Supply
In this key figure, planned transportation orders converted by the deployment run can be seen.
TLB Confirmed Distribution Receipt Supply
In this key figure, planned orders generated by the TLB run or created interactively can be
seen.
In Transit Supply
In this key figure, all products that have left the sending location but have not yet arrived in
the receiving location can be seen.

The total supply quantity is calculated according to the following formula:

Total Supply
+
+
+
+
+
+
+
The Available-to-Deploy (ATD) quantity that is used in Deployment and TLB is not necessarily
the available or physical stock that can be found at the respective location. The calculation rule for
the ATD quantity can be defined individually per location in the location master record. There are
two fields in the location master record, ATD Receipts and ATD Issues, which determine which
supply and demand elements are taken into consideration when calculating the ATD quantity.
Allocated to these two fields are category groups that in turn are made up of various order
categories. Should no specific ATD rules be linked to the location, the standard delivered system
will use the category groups ATR and ATI. The ATR category needs to include the order category
for unrestricted stock (CC) in order to enable a deployment and TLB based on the available stock.
The stock defined in order category CC includes the safety stock and consequently the safety
stock is used for deployment. If this is not desired, a user exit can be utilized to subtract the safety
stock level from the unrestricted stock.

3.4.2.1

Stock Definition

SNP calculates the stock figure via the definitions of a category group. The category group to be
used is defined per location in the location master SNP tab. By changing the category group that is

Understanding

144

linked to the location master it is possible to include or exclude specific stock categories that SNP
displays and uses during planning. This functionality can be used to exclude e.g. blocked or
quality inspection stock from planning. The category group ST1 is the default category group
and is used if no other category group has been defined in the location master.

3.4.3

Reorder Process

The reorder process deals with the timely ordering of products that are required either by internal
or external sites. The outcome of the reorder process is a procurement order, which is also referred
to as a replenishment order. The procurement order can be internal (production) or external
(purchase or stock transfer). The term external refers to external of the demanding location and not
external to the demanding company. There is a further distinction between orders that are placed
on locations within the supply chain model and those that are placed on anonymous vendors
(vendor with no location in the supply chain model). This distinction though has only minimal
impact on the calculations performed during the reorder process. The reorder process consists of
various decisions that are dealt with in the following sections. While the reorder process as
described below is aimed to provide an overview of the APO reorder process, it must be
understood that the way the reorder process is implemented in each module may not always be
exactly the same. There are differences between the way SNP and PP/DS work. Difference can
also be seen when comparing the SNP Optimization and Heuristics approaches. The reorder
process in PP/DS can be carried out using different Heuristics and depending on which one is
used, the system reacts differently. Furthermore, additional own Heuristics can be programmed to
cater for specific business requirements.
The reorder process provides answers to the questions:
Whether a certain product is due to be replenished
The triggering of the reorder process is dependent on the type of reorder process. APO
supports two different groups of Heuristics approaches, the deterministic and the stochastic
approach. Deterministic processes are such where a replenishment order is raised based on an
explicit demand. No stock besides any potentially defined safety stock is held and ordering is
triggered by demand. Stochastic processes base the reorder decision on predefined stock
levels that need to be maintained. Alternatively, the reorder process can be based on an
optimization algorithm like the SNP Optimizer.
The triggering mechanisms are discussed in the section Reorder Decision.

How the demand shall be satisfied

Any demand can be satisfied by means of in-house production, stock transfer from another
location or by raising a purchase order on a vendor. Mixing of various sources of supply is
also supported. The SNP Optimizer uses the cost optimum solution and potentially selects
more than one source for an established demand. Quota arrangements can be setup to support
a Heuristics multi-source planning.
More information can be obtained in the section Defining the Source of Supply.

What the quantity is that needs to be ordered

The reorder quantity is determined based on the reorder process, the current stock holding,
and settings in the product master. Scrap percentages as well as rounding values, if defined,
also influence the reorder quantity. In the case of transportation orders, a second lot sizing
procedure might take place. Lot sizing plays a less important role for the SNP Optimizer, as
lot

Understanding

145

sizes are normally calculated dynamically in accordance with the goal to achieve a cost
optimal solution.
More information can be obtained in the section Determining the Procurement Order
Quantity.

For which date the order must be scheduled

Generally, the supply should arrive just before the requirement. Various time settings in the
product master influence the precise definition of the schedule time (e.g. G/R Time, Safety
Days Supply, and Pegging definitions). The scheduling process also differs depending on the
procurement type and the application area (SNP versus PP/DS). The SNP Optimizer bases the
order date not only on the requirement date but also on the feasibility of this date in terms of
available capacity. In doing so, some supply elements might be before or even after the
requirement depending on the cost/penalty situation. The scheduling in PP/DS is the most
complex, and various scheduling strategies can be used.
More information can be obtained in the section Scheduling the Procurement Order.
The reorder process definitions are largely driven by the settings in the product master at the
location where the demand arises. All types of replenishment orders, internal and external, share
them. This can potentially lead to conflicts where a product is procured internally and externally
and different parameters (e.g. rounding values) should be used depending on the procurement
type. In order to understand the reorder process, it is also necessary to be familiar with the Target
Days Supply as well as the Safety Stock concepts. To obtain the required information, refer to the
appropriate sections.

3.4.3.1

Reorder Decision

The triggering event for a reorder decision and the follow-up procedures depend greatly on the
used reorder process. There are three main groups:

Deterministic Reorder Process

The deterministic reorder processes base the reorder decision on the comparison of defined
requirements such as a sales order, or a dependent demand from another production order,
with the available supply elements. Safety Stock and Target Days Supply definitions are seen
as requirements in this context.

Stochastic Reorder Process

The stochastic reordering process bases the reorder decision on a user-defined stock level
rather than on demand elements. Stock is held just in case and replenished when the stock
level falls below defined levels. Safety Stock and Target Days Supply definitions are
potentially influencing the defined reorder levels.

Optimization
Optimization processes compare individual demand elements with the available supply
similar to the deterministic process described above. The main difference is that demand
elements are valuated according to their importance. User defined penalties for non- or late
delivery are taken into consideration as well as the cost of satisfying the demand elements.
Other restrictions like production or transportation capacities might also influence the reorder
decision (and the scheduling of the order). Safety Stock definitions are seen as requirements
in this context.

Understanding

3.4.3.1.1

146

Deterministic Reorder Processes

The group of deterministic reorder processes comprises three different methods that are explained
in this section.

Lot for Lot

With the Lot for Lot process, also known as the Exact Lot Size, any open requirement is
offset by a supply element with an identical quantity. This initial supply lot size, which is
exactly the same as the requirement quantity, is then possibly adjusted using minimum and
maximum values as well as rounding values and rounding profiles.
The Lot for Lot process is the default process used in a Make to Order and Engineer to Order
environment. This applies even if another process is defined in the product master. Due to
this, the same product might be planned using two different lot-sizing processes, one for a
make-to-stock order and the other for a make-to-order or engineer-to-order order. Other lot
sizing processes (explained subsequently) need to be permitted explicitly for products that are
manufactured based on a Make-to-Order or Engineer-to-Order manufacturing strategy. The lot
for lot process ensures that no surplus is created, but often requires the usage of rounding
procedures, as is not always practical to manufacture or order in a lot size exactly as required.
Required Master Data:
The Lot for Lot process does not require any additional definitions, as each demand element
is paired with a supply element of the same quantity and date.

Fixed Lot Size

With the Fixed Lot Size process, the system creates one or multiple orders with a quantity as
defined in the fixed lot size field whenever one or multiple open requirements exist. It is
likely that the requirement quantity is not equal to the fixed lot size, and thus a stock surplus
can usually be encountered. The fixed lot size process is of particular importance in situations
where the product can only be manufactured or delivered in certain predefined quantities (e.g.
full tank load).
The Lot Size Always flag, if set, allows products in a Make to Order or Engineer to Order
environment to use this process.
Required Master Data:
The Fixed Lot Size process requires the definition of the fixed lot size.

Periodic
The Periodic Lot Sizing process accumulates all demand of a certain number of periods as
defined by the user and places one replenishment order against these demands at the same
time when the first requirement arises (requirements date equals availability date). This can be
changed so that the availability lies anywhere between the first and the last requirement. This
process is specifically useful during the rough cut planning, as it will keep the number of
orders at a lower level while providing a good overview what is required (e.g. per week).
The Lot Size Always flag, if set, allows products in a Make to Order or Engineer to Order
environment to use this process.
Required Master Data:
The Periodic process requires a period indicator (e.g. day), the number of periods to
accumulate, and a planning calendar if only working days should be used.

3.4.3.1.2

Stochastic Reorder Process

Understanding

147

The group of stochastic reorder processes comprises of one single method that is explained in this
section.

Reorder Point Procedure

The Reorder Point triggers an ordering process, which should bring the stock, depending on
the used lot size, to at least the level defined as the Target Stock Level. The target stock level
method must therefore be defined when using a reorder point procedure. If no target stock
level method is defined, the system will only maintain the defined reorder point level, which
will potentially lead to a frequent reordering with small quantities. In this case the reorder
point and the target stock level are the same. The reorder point can be defined as either a
quantity (reorder point stock) or as a number of supply days (reorder point days of supply).
Both definitions are static and do not change over time. Alternatively, the greater of the two
can be used to trigger the reordering process. The reorder point stock and reorder point days
of supply can also be defined dependent of time. In this case a different value for the reorder
point might exist per day. This type of definition is referred to as dynamic reorder point
procedures. The reorder point stock is defined in the products base unit of measure. The
reorder point days of supply needs to be converted (calculated) using all demand elements in
the specified number of days. The reorder point must be set high enough to cover the
expected demand between ordering and receipt (the lead-time) as otherwise the receipt might
occur only after the entire stock has been used.
Required Master Data:
The Reorder Point Procedure requires the definition of the reorder point in the form of a
reorder days supply (time based definition) or a reorder point (quantity based definition).
Furthermore, a maximum stock level needs to be defined. This is also either a time-based
target stock level (target days supply) or quantity based (product storage capacity).
Optional Master Data:
This includes minimum and maximum lot sizes, scrap and rounding values, safety days
supply and safety stock definitions.
A detailed view of how the reorder process is implemented in the APO system can be found in the
section Reorder Point Procedures.

3.4.3.1.2.1

Reorder Point Procedures

The reorder point procedure is a process commonly used for product with a steady demand and of
no strategic planning importance. Most often these products are of lower value as well. This
process is for example common with manufacturing supplies and spare parts. The main advantage
of reorder processes is that they do not require any forecast to be carried out. Ordering of stock
takes place after the consumption (replenishment principle) and not before as it is the case with
deterministic processes. The required data is easier to maintain when compared with the
deterministic processes and the effects on stockholding are not negative when applied properly.
There are two groups of reorder point procedures, the time independent and time dependent
methods.

Time Independent Reorder Point Procedure

Methods belonging to this group allow the definition of a reorder point that is constant over
time. Obviously the reorder point can be changed as and when required, but the value is the
same for all upcoming planning periods. The reorder point value in this case is stored in the
product master.

Time Dependent Reorder Point Procedure

Understanding

148

In this group we can find methods that allow the definition or calculation of a reorder point
that changes over time. The reorder point value is stored in a time series (key figure) and not
in the product master.
Reorder point settings can be carried out in two ways, expressed in a quantity or a demand related
figure.

Quantity Based Reorder Point Procedure

A quantity based reorder point is expressed in the products base unit of measure and
stipulates a certain level falling under which is triggered by the system and initiates a reorder
process.

Demand Based Reorder Point Procedure

Demand based reorder point definitions relate the reorder point to the products demand and
is expressed in time (usually days). If the expected demand goes up, the reorder point moves
up as well.

3.4.3.1.2.1.1

Reorder Point Procedures in SNP

The table below provides a first high-level overview of available reorder point procedures for
SNP. The SNP (and PP/DS) Heuristics planning algorithms take the reorder point procedures into
account. The SNP Optimizer does not recognize the reorder point levels and is subsequently not
planning according to them.

Reorder Point

Basic Methods
Time Independent
Time Dependent

Note the following:

The demand based reorder point is always defined and displayed of calendar (not working)
days.

The generic term demand used in the reorder point calculations refers to the same demand
that can be seen in the key figure Total Demand in the SNP Interactive Planning
transaction.

When using a reorder point procedure the target stock level in the product master must be
defined, as it serves as the upper stock limit. If the target stock level is below the reorder
point, then during planning tasks the target stock level is set to the value of the reorder point.
This means that the system will suggest reorder quantities that maintain at least the reorder
point if no target stock level is defined.

Understanding

149

The reorder point procedure and value can be defined for time independent reorder point
procedures per product in the Lot Size tab. Time dependent reorder point procedures require that
the levels are maintained in the SNP Interactive Planning transaction. The reorder point is
calculated and displayed in the SNP Interactive Planning transaction only if the reorder point
procedure method is defined in the product master.

Basic Reorder Point Procedures Time Independent

All time independent reorder point procedures require the data to be captured in the product
master.
Reorder Point Procedure 1
For method 1 the user defines in the product master the reorder point in the products
base unit of measure. The same reorder point is applied to all periods.
Reorder Point Procedure 2
For method 2 the user defines in the product master the reorder days supply. Note that
the reorder days supply is always defined and displayed in calendar (not working) days.
If the demand is rising, the reorder point level expressed in units rises and vice versa. As
the system uses calendar and not working days this leads automatically to changing
reorder points (in units) as the result of demand-free weekends.
Reorder Point Procedure 3
Using method 3, the system reads the reorder point setting from the product master as it
is the case with method 1 and compares it with the result of the demand based calculation
of method 2. It then applies the greater of the two values as the final reorder point.
Basic Target Stock Level Methods Time Dependent
Reorder Point Procedure 4
The reorder point procedure 2 requires that the reorder days supply be defined per period
in the SNP Interactive Planning transaction. There is no key figure defined in the standard
delivered system and thus the key figure needs to be defined first. Distribution functions
can be used to facilitate the task of data capturing. No further parameters are required or
considered and the SNP or PP/DS Heuristics runs consequently consider the individual
time dependent reorder points.
Reorder Point Procedure 5
For reorder point procedure 5 the user defines the required reorder point per period in the
SNP Interactive Planning transaction. There is no key figure defined in the standard
delivered system and thus the key figure needs to be defined first. Distribution functions
can be used to facilitate this task. No further parameters are required or considered and
the SNP or PP/DS Heuristics runs consequently consider the individual time dependent
reorder points.
The time reorder procedures 5 and 6 work with either workdays or calendar days
depending on the macro definition for workdays. Set the macro definition for workdays
to a seven-day calendar to plan with calendar days. Several workday definitions could be
used in the same planning book.
Reorder Point Procedure 6
This method is again a combination of two other reorder point procedures the methods 4
and 5. As it is the case for those methods, it is also required for this method to define the
desired values per period. This can become rather laborious as for each period a reorder
point as well as the reorder days supply needs to be captured using the SNP Interactive
Planning transaction. Per period the reorder point is compared with the result of the

Understanding

150

demand based calculation. The greater of the two values is finally used as the reorder
point. If only one of the two values is defined it is automatically used as the greater.
In order to calculate the reorder points, the key figures as listed below are used.

Key Figure
Name
Reorder Point
(planned)
Reorder Days
Supply (planned)
Reorder Point

Table 38 Target Stock Level Key Figures

The following flow chart provides an overview of the ways the different reorder point procedures
derive the final reorder point.
Flow Charts exceed the available printing space and are only part of the on-line APO Knowledge
Bank.
Graphic 50 Reorder Point Determination

3.4.3.1.3

Optimization Reorder Process

When using optimization routines, demand and supply elements are compared according to user
defined cost/penalty settings. Based on the defined costs and penalties the optimization algorithm
tries to find the cost optimal solution. The result is that potentially the optimization routine
suggests not initiating a reorder process although there is an unsatisfied demand. Typically
optimization routines do not require any specific reorder process settings as required for nonoptimizing routines. An exception is a potentially defined safety stock, which the optimization
algorithm tries to fulfill if the user requests this. Optimization routines are available for SNP
planning and for Deployment.
A detailed explanation of the APO optimization routines can be found in the section Optimization
in APO.

3.4.3.2
Defining the Source of Supply
Understanding

The possible sources of supply can be combined into the two groups: internal and external source.
An internal source is the own production facility and thus the order created is a production or
planned production order. External supply sources include the stock transfer from an own
alternate location and the purchasing of stock from a vendor location. Some other special forms
of external supply exist, such as subcontracting and purchase of consignment stock. The

difference of a normal purchasing order and a consignment purchase order is merely a financial
one, and for this reason of no interest when discussing the quantity and scheduling aspect of the
reorder process. It has although a big impact on the attached OLTP system, which holds the
general ledger. Subcontracting describes a situation where a vendor is asked to deliver a product
and receives at the same time all or some of the components to manufacture the required product.
The important aspect in this scenario is that the system also plans dependent demands for all
components that need to be made available to the subcontractor. APO also provides the possibility
to raise purchase orders without specifying a vendor explicitly (anonymous vendor). The
possibilities are depicted in the graphic below.

Supplier
Location

Supply Chain Model

Graphic 51 Procurement Source Possibilities

Purchase orders placed on a vendor to whom a transportation lane is defined (known vendor) can
be created based on purchasing documents maintained in the R/3 system. All purchasing
documents mentioned here can only be used when planning in the active planning version.
Following possibilities exist:

Scheduling Agreement
The scheduling agreement is a special type of purchase order that stipulates the product(s) to
be purchased, its quantity and a time period during which the delivery has to take place. No

Understanding

152

final delivery dates are set in the scheduling agreement and the products are called off as and
when required. The individual call off request is also referred to as a scheduling agreement
line. If a scheduling agreement document number is linked to the transportation lane product
procurement, PP/DS creates a scheduling agreement line instead of the purchase requisition.
Note that there are also scheduling agreements in the sales environment. Within SNP, no such
releases are created. Instead normal purchase requisitions are created.
SNP Heuristics planning (i.e. not the SNP Optimizer) recognizes scheduling
agreements and creates scheduling agreement call off requests as long as they are not for
subcontracting purchase relations.
Purchasing Contract
The purchasing contract is not a purchase order but a contract on which purchase orders are
based. These contracts can stipulate agreed quantities (quantity contract) or monetary
amounts (value contract). If a contract number is linked to the transportation lane product
procurement, APO creates a purchase requisition using the contract details.
Info Record
Materials (products) are linked in R/3 to specific vendors using info records. One or multiple
info records can exist for a product. Each of them is stipulating specific information (e.g.
price and/or lead time) about the vendor-product relation. In R/3 it is possible to enforce the
usage of info records, meaning that products can only purchased from such vendors where an
info record exists. If an info record is linked to the transportation lane product procurement,
APO creates a purchase requisition using the info record details.

The first key for the definition of the source of supply is in the product master, which classifies it
as either internally (in-house production) or externally procured. Another possibility is to allow
both options with a preference for internal procurement. Procurement can also be switched off, in
which case no planning takes place irrespective of the demand situation. This procurement type
means that the system only works with available receipt elements as far as they exist (limited
availability) It does not mean indefinite availability. In-house production requires the definition of
a production process model, which allows the system to plan dependent demands and resource
requirements. For external procurement (that is from a vendor or an alternate location) it is
required to define a transportation lane, which provides transportation specific information. This
includes the required transportation times to enable scheduling. There might be a choice of several
transportation methods for such products that are procured externally and shipped via a
transportation lane that is defined in the supply chain model. In this case, part of the source
definition is the selection of a transportation method. Products that are manufactured in house also
require the definition of at least one production process model (PPM). The PPM combines the bill
of material (BOM) with the routing.
Various sources of supply can be mixed and even the same requirement can potentially be satisfied
using several sources of supply. When using the SNP or PP/DS Heuristics, quota arrangements can be
used to determine the share of business allocated to a certain source. This share can be used to split
each requirement or to maintain the quota over time. The Heuristics allows selecting the source
location including in-house production by priority, procurement cost, and/or transportation cost while
always adhering to the quota arrangement. If a quota arrangement is defined the system adheres to it
even if the source as defined in the quota arrangement is not the least expensive or the one with a lower
priority. The SNP Optimizer selects the source of supply according to the overall least cost principle
while considering the feasibility of the solution. Capacity constraints can be considered. Common for
all approaches is that the procurement type defined in the product master limits the search path for the
possible source of supply. Only when it is set to Internal and External

Understanding

153

Procurement can all options be used. In the case of external procurement with the use of
transportation lanes and multiple transportation methods, the system must also determine which
transportation method is to be used. The SNP and PP/DS Heuristics use the least expensive
transportation method and the SNP Optimizer the solution with the overall lowest cost.
If a cost is defined in the Procurement Cost field (product master procurement tab), the
Optimizer interprets this as an indicator that procurement from an anonymous vendor is permitted.
In a case where transportation lanes to the requiring location exist and the product procurement
cost is defined in the product master, the Optimizer decides between external procurement using a
transportation lane and external procurement from an anonymous vendor. The SNP and PP/DS
Heuristics use the anonymous vendor only as a last possibility if no other solution can be found.
PP/DS requires additionally that this option (anonymous vendor) be permitted in the planning
version parameters.
Flow Charts exceed the available printing space and are only part of the on-line APO Knowledge
Bank.
Graphic 52 Source Determination
The above graphic displays the search path assuming the user has not restricted the possible
procurement methods. This is a valid assumption in the PP/DS Product View transaction. In the
SDP Interactive Planning transaction, the order quantity is typed into a cell belonging to a specific
key figure. Via this key figure (e.g. planned distribution receipt) a procurement method restriction
takes place in such a way that the system selects the appropriate order type (e.g. EA for SNP
planned purchase requisition). In this way the search for a source is restricted to a certain
procurement method (external in this example).
In the special constellation of having defined the procurement type E for in-house production
without a valid PPM available, the system creates a planned production order without PPM
explosion and thus no resource load or dependent requirements.
Another major difference between the Heuristics and Optimization with regards to the cost
determination of a procurement option is that a Heuristics approach in SNP and PP/DS is a singlelevel search and the Optimization a multi- level search algorithm. This can be seen easily when
comparing the way both methods deal with procurement options using several transportation lanes
and methods.

The Heuristics compares Total Procurement Cost of various options. The procurement cost,
which is defined in the transportation lane, can also originate from an external procurement
relation such as an info record, purchase contract, or scheduling agreement when planning in
the active planning version. These costs are used by the SNP and PP/DS Heuristics to
determine the valid source of supply.

The SNP Optimizer does not use these costs. Each of the procurement options consists of a
procurement cost and a transportation cost. The SNP Optimizer checks the transportation cost
of the transportation lane and adds to this the real procurement cost at the delivering location,
which could be a cost determined via a PPM, or external procurement. The Optimizer
calculates the entire cost of all possibilities in the entire supply chain for the product in an
attempt to find the cost optimum solution. This can be best described as an incremental multilevel procurement cost determination.

Understanding

3.4.3.3

154

Determining the Procurement Order Quantity

Once the requirement to reorder has been established and the source of supply is known, it is
required to determine the exact reorder quantity. The reorder quantity is not necessarily the same
as the determined shortage quantity established initially. Depending on the selected reorder
process, adjustments to this quantity might be carried out. Possible adjustments are the application
of:

Minimum Order Quantity

Minima are usually applied to avoid too small orders specifically in a production
environment. This leads to an oversupply of products.

Maximum Order Quantity

Maxima might have to be set in situations where certain values cannot be exceeded. Examples
are production orders in the process industry where not more than a certain quantity can be
handled in a tank or similar restricted area. Another example is a tanker truck, which
obviously has a limited available capacity. If an order exceeds the maximum it is initially
capped at the maximum and the remaining quantity is used to create a second order. The
definition of a maximum does not imply that an undersupply occurs.

Rounding Values or Rounding Profiles

A rounding value is used to facilitate the economical handling of goods. The product master
might have a base unit of measure in pieces, but all orders should be in multiples of 10 pieces,
as this the quantity per case. Rounding profiles offer multi-level definitions of rounding
values according to quantity ranges and an easier way of maintaining large numbers of
products. Rounding profiles can be attached to products and product specific transportation
methods in the transportation lane.

Scrap Values
The way scrap values are applied differs compared to the application of the other adjustments
explained above. Scrap values are used to change the requirement quantity rather than the
supply (reorder) quantity. The SNP Optimizer and Deployment Optimizer also adhere to the
scrap value settings.
The SNP Optimizer and Deployment Optimizer can only apply the lot sizing rules and procedures
(except scrap value definitions) if they are run in discretization mode. Minimum, maximum and
rounding values can be used by switching on the appropriate Discretize option. The Discretize
flags are set in the optimizer profile. If the appropriate flag is not set, the proposed quantities are
determined based on a linear function cost-optimal solution and are not adjusted according to e.g.
rounding values. This does not pose any problem for the SNP rough-cut plan generated by the
SNP Optimizer but might be of a problem when using the Deployment Optimizer, as deployment
quantities should usually be rounded according to package or pallet sizes. Running the SNP and
Deployment optimizer in discretization mode requires more calculation effort and subsequently
the runtime worsens.
Note that in the case of transportation orders between two locations that are defined in the supply
chain model, a second lot sizing procedure might take place. A Lot Size Profile for
Transportation Lanes can be defined per product specific transportation method, which is a
combination of a transportation method and a product procurement definition. If this lot size
profile for transportation lanes is defined, its minimum and maximum definitions as well as the
rounding values or rounding profiles are applied. This second lot sizing procedure is carried out in

Understanding

155

conjunction with the SNP planning run and with deployment. The usage of the lot sizing processes
as defined in the product master and in the transportation lane based lot sizing procedure is a twostep sequential process. Note the following interdependencies if both lot sizing processes are
applied:
1. The transportation lane based definition is not used in situations where the
minimum/maximum ranges of the two lot sizing procedures exclude each other.
2. The re-order quantity is potentially increased if the transportation lane based definition has a
minimum quantity requiring this.
3. The order might be split into several orders if the transportation lane definition has a
maximum quantity that is smaller then the previously established re-order quantity.
4. If rounding values and/or rounding profiles are defined in both lot size profiles, those defined
in the transportation lane are used.

3.4.3.3.1

Rounding Procedures

Rounding of order quantities can be carried out by means of a rounding value (single-level
rounding) or a rounding profile (multi-level rounding). Rounding values are discrete values
defined for example in the products master and the suggested order quantities are in multiples of
this rounding value. Alternatively, rounding profiles can be used. Should both be defined then the
rounding profile is used.
The Rounding Profile is used to round up or down previously established demand. It can be linked
to a product master, to the lot size profile, or to an SNP lot size profile. The SNP lot size profile
itself is linked to the product specific transportation method of the transportation lane. The
following graphic provides an overview.
Understanding

Transportation Lane
(Product Specific
Transportation Method)
SNP Lot Size Profile

Graphic 53 Rounding Profiles

Each Rounding Profile has several levels. For each level a threshold value and a rounding value
is defined. Let me explain how the final result is derived with the help of an example. To make it
easier to understand, I have allocated to the different levels different package media.
Calculation
Initial Step: Compare Original Demand with Threshold Value of level 1. If Original Demand is
less than Threshold Value of level 1 then the Rounding Value equals the
Original Demand (which means no rounding takes place). If the Original
Demand is greater or equal than the Threshold Value of level 1 continue to
step 1.
Step 1: Divide Original Demand by Threshold Value of Level 3 and determine how many times
the Rounding Value of Level 3 goes into the Original Demand Value. Do not
consider the decimals now. We now have the number of pallets. Subtract the
number of units on this pallet from the Original Demand, which gives us
Demand 2.
Now compare Demand 2 with the Threshold Value of level 3. If Demand 2 is
greater than the Threshold Value of level 2 then add 1 more pallets (round up)
and we are finished. If not proceed to step 2.
Step 2: Divide Demand 2 by Threshold Value of Level 2 and determine how many times the
Rounding Value of Level 3 goes into the Demand 2 Value. Do not consider
the decimals now. We now have the number of cartons. Subtract the number
of units in this carton from Demand 2, which gives us Demand 3.
Now compare Demand 3 with the Threshold Value of level 2. If Demand 3 is
Understanding

greater than the Threshold Value of level 2 then add 1 more carton (round up)
and we are finished. If not, proceed to the next step.
Final Step: Divide Demand 3 by Threshold Value of Level 1 and determine how many times the
Rounding Value of Level 1 goes into the Demand 3 Value. Round up to the
next number. We now have the number of boxes.
Sounds maybe a bit too complex, but it is not really. Each time the system has to perform
rounding calculations, it will go through the initial step and the final step. Additionally it will go
through n calculation steps with n being the number of rounding levels minus 1.

Level
1
2
3
Table 39 Rounding Profile Setup Example
Here are some numerical examples for the model in the table above:

Original Demand
8
43
83
134
161

185
Table 40 Rounding Profile Data Example

3.4.3.3.2

Scrap Calculation

APO offers two ways to calculate scrap values. In a top down approach for each product, an
assembly scrap value can be defined in the product master. The Assembly Scrap is a product
dependent parameter. This scrap value applies if the product is the one to be assembled which
means it is on the top level of the PPM (or BOM). If the assembly scrap value is maintained, all
components required are supplied to the production process in a higher number according to the
assembly scrap value. This applies independent of the used PPM.

Understanding

158

This option should be used in an environment where, only at the end of the process, the usability
of the product can be tested after all components have already been utilized in the manufacturing
process of the product. An example would be the manufacturing of PC motherboards.
A second possibility is a bottom- up approach where scrap value can be defined that applies to the
product if it is a component in a PPM (or BOM). The Component Scrap is defined in the PPM
and is a process dependent parameter. Only the single component will be supplied in a higher
number to the production process and only if this is defined in the used PPM. Component Scrap
can be defined time dependent.
This option should be used in an environment where, during the production process, components
are likely to have different scrap percentages and/or where interim process checks can reveal nonusable products. Examples are multi-step assembly lines with interim quality tests.
Care must be taken if both scrap percentages are used, as the system will calculate scrap values in
the top down and bottom up approach.
Example 1: Assembly Scrap
Assembly Scrap Value
Required Quantity
Planned Process Quantity

20%
1000 pieces
1000 pieces/80% = 1250 pieces

All components will be supplied with a 25% surplus.

Example 2: Component Scrap
Component Scrap Value
Required Quantity
Planned Process Quantity

20%
1000 pieces
1000 pieces/80% = 1250 pieces

The single component will be supplied with a 25% surplus.

3.4.3.4

Scheduling the Procurement Order

The scheduling of the order is another step in the reorder process. Typically SNP Heuristics
processes schedule the order on the date as required. PP/DS Heuristics processes additionally
perform a feasibility check and schedule the order according to the resource capacity constraints.
Scheduling in PP/DS is a highly complex task and driven by settings in the scheduling profile.
Special functionality is provided to reschedule operations of existing orders. The SNP Optimizer
schedules the order in accordance with the overall cost minimization approach. Orders are
scheduled even in SNP with a precision of a second. Some demand elements like forecasts from
Demand Planning that are created in the SNP environment have predefined times of the day for
which they are created (see the section Time Calculations and Display). Based on this artificial
time all further scheduling is carried out. If for example a forecast was created with a requirements
time of 12.00.00, the corresponding receipt element (e.g. a transportation order) will be scheduled
to arrive at 11.59.59 when using an SNP Heuristics planning approach. The precise timing of
orders depends on various factors as listed below.

Calendars
Understanding

Shipping Calendar
The shipping calendar, which is linked to a location, is used when planning goods receipt
(G/R) and goods issue (G/I) transactions. It is a time stream that determines working and
non-working time with a second-precision. The shipping calendar is also used during the

release of the DP unconstrained forecast to SNP. It must for technical reasons start at
00.00:00.
Storage Calendar
The storage calendar is also linked to a location. It is used when scheduling storage
activities. It is not the calendar used by a storage resource. The storage calendar must
have a 24-hour work time definition; otherwise the SNP Optimizer assumes the
warehouse cannot be used at any time. In this case the SNP Optimizer plans emptying
the warehouse during non-working times.
Production Calendar
The production calendar is also linked to a location. It is used for example when
scheduling production orders without a valid PPM. It is not the calendar used by a
production resource.
Transportation Calendar
The transportation calendar is defined in the transportation method of the transportation
lane. The definition is optional. Should no transportation calendar be defined, a 7-day
24-hour operation is assumed.
Time Settings
G/I Time
The goods issue time is defined in days or portions thereof. It must always be read in
conjunction with the shipping calendar. A setting of for example 0.5 days translates to 4
hours goods issue time using a shipping calendar with a work time of 8 hours. The goods
issue time might start late on a working day and proceed on the next working day
according to the shipping calendar.
G/R Time
The goods receipt time works, in principal, the same as the goods issue time.
Transportation Time
The transportation time is calculated using the same logic as the goods issue and goods
receipt time. If no transportation calendar is linked to the transportation method the
system assumes a 7 days times 24 hours working (transportation) time.
Load and Unload Times in VS
The location load and unload times are used by TP/VS only and modeled via a single or
multi mixed resource. As the same resource is used in transportation planning as a
bucket resource, it is possible to monitor the bucket and finite load using the same
resource.
Location Opening Hours in VS
The location opening hours are used by TP/VS only. They are modeled via a time
continuous resource. It allows vehicle scheduling to plan activities during the opening
hours only. The usage of opening hours has no initial impact on the order scheduling
process.
Resources and their Calendars
Various resources are used during the planning process. They all have own calendars attached
to them, which determine the working and non-working times. Examples are the handling,
storage, and transportation resources.
Scheduling Adjustments
Safety Days Supply

Understanding

160

The safety days supply only has an impact on the PP/DS order scheduling. SNP uses this
field to derive the planned safety stock. PP/DS uses this field to bring forward the supply
element relative to the demand element thus crating a safety stock.
Availability Date Indicator
Periodic reorder processes combine various requirements of a certain period into one
bucket. The procurement for this periodic demand is then carried out via one single order.
The availability date indicator permits the switching on of the period factor function,
which is used only in conjunction with periodic reorder processes.
Period Factor
If a periodic reorder process is used and the availability date indicator is switched on then
the period factor determines when the goods receipt for a periodic has to be scheduled
for. The value can be set between 0 (earliest) and 1 (latest).

3.4.3.5

Deployment Rules

The Deployment run can be instructed to react in certain ways in the case of product shortages
and/or oversupply. Only the deployment algorithm uses the settings Fair Share Rules and Push
Distribution.
Deployment rules are actually nothing else but rules that influence the reorder decision in the case
of internal replenishment. The term internal replenishment includes the Vendor Managed
Inventory (VMI) replenishment activities. The deployment push and fair share rules influence the
reorder process as follows:

Reorder Decision
The application of a push rule leads to a situation where the reorder decision is based on the
supplying locations stock rather than the demand at the receiving location.

Source of Supply
The source of supply is usually not affected by deployment push and fair share rules.

Order Quantity
The order quantity is the main parameter influenced by the deployment push and fair share
rules. Order quantities might be reduced (fair share) or increased (push).

Scheduling
Indirectly, the deployment push and fair share rules influence the timing, as orders might be
created earlier or later than required. The actual scheduling is the same as with any other
procurement order.

3.4.3.5.1

Fair Share Rules

In a situation where the demand is greater than the available supply, APO applies so called Fair
Share Rules. As the name depicts, a fair share rule is a set of rules and conditions with the aim to
distribute products with insufficient supply to all sources of demand in a fair way. Fair share
distribution logic is defined per location product in the product master record. It is possible to use
a deployment profile to which a product is linked. See the master data section for more
information about using profiles.

Understanding

161

The field Fair Share Rule determines the type of fair share logic that is applied to a specific
location product whenever the Available-to -Deploy (ATD) quantity is smaller than the total
requirements for a product. Leaving this field blank is a valid possible entry, indicating that no fair
share rules must be applied. The ATD quantity is defined by means of a category group, which
links various order types. The following Fair Share Rules are available:

Percentage Division by Requirements (Indicator A)

The available stock to deploy is split across the target locations in the same ratio as the
locations demands. This comparison is carried out per requirement period.

Percentage Fulfillment of Target (Indicator B)

With this rule, the system tries to ensure that the available stock is used in a way that the
target stock levels at all target locations reach the same level. During this calculation the
system tries first to raise all locations projected stocks to at least Zero (in other words to have
enough to cover any demands). Only if any stock is left over after that distribution the then
remaining stock is used in a way that the target stock levels at all target locations reach the
same level.

Percentage Division by Quota Arrangement and/or Demand Priority (Indicator C)

The available stock is distributed based on the outgoing quota arrangement of the source
location to the respective target locations. There is no distribution according to any demand
priority although the name might lead to this assumption. If the available supply for a specific
location based on the quota arrangement is higher than the demand of the location, then the
remaining supply is not distributed to other locations but rather kept for deployment planning
in the next period. Demand of location A is 100 and its quota is 60%. Total supply is 500,
which results in a quota of 300. As only 100 is required, 200 are kept for the next period (day)
and not allocated to other locations.

Division by Priorities (Indicator D)

The available stock is distributed according to the distribution priority (not the deployment
order priority), which is defined in the transportation lane procurement method. The location
with the highest priority transportation lane pointing to it receives enough stock (if possible)
to satisfy the entire requirements. Then the requirements of the location with the second
highest
priority transportation lane pointing to it are satisfied and so on.
Although technically possible, the setting blank for the fair share rule should not be used. The
resulting distribution of stock in a shortage situation is not clearly defined when not defining a fair
share rule.
Understanding

Graphic 54 Fair Share Rules

The Deployment Heuristics and Deployment Heuristics Real Time planning runs use the Fair
Share Rule as determined in the product master. The Deployment Optimizer does not use this
setting. In case of a product shortage, the Deployment Optimizer distributes the available
quantities based on the least cost principle or according to the Fair Share Rule A or B. When
starting the Deployment Optimizer, it can be set to one of these two options. Note that in this case,
the definition of a Fair Share Rule is not per product but for all products. This setting overrules the
product master setting for this specific Deployment Optimization planning run.
View the section Push Distribution for a summary of master data that needs to be maintained
when using fair share rules.

3.4.3.5.2

Push Distribution

Whenever the ATD supply exceed the demand, APO can apply so called Push Rules. These
rules, which again are defined in the product master, stipulate how excess stock at the source
location is distributed to the target locations. In this scenario the stock is pushed to the target

Understanding
163
a specific location product whenever the ATD quantity exceeds the total requirements for a
product. Leaving this field blank is a valid possible entry, indicating that no push rules
must be applied and products are deployed using pull principles only. Pushing of product
locat
quantities is carried out (if activated) for all supply elements that exceed the demand. There
ion
is no specific stock level that needs to be exceeded in order to apply push principles. With
earli the exception of the push distribution rule Q, none of the push distribution rules ever
er
push products with no demand, they merely ships products prior to the required time. The
than following Push Rules exist:

Pull (Indicator blank) No Push

the
Supply all demands for the time as defined in the Pull Deployment Horizon on the date
defin
as required if the ATD quantity permits. With this option no push principles are used.
ed
Deployment is based solely on pull principles. Quantities and delivery dates are
requi
determined by the requesting location.
reme
If the Pull Deployment Horizon minus the Transportation Lead Time is smaller (or
nt.
greater) than the Push Deployment Horizon then some of the available quantity is not
This
considered (or is not available) for timely delivery.
is
done
amo
ngst
ATD
other
reas
ons
to
relea
Shi
se
ware
hous
e
capa
city Rec
at
the
sour
ce
locat
ion.
The
field
Pus
h
Dist
ribut
ion
deter
mine
s the
type
of
push
logic
that
is
appli
ed to

20

Demand
10

Period
10
20

Req

Graphic 55 Push Deployment 1 (No Push)

Target Location

Understanding

164

Pull/Push (Indicator P)
Supply all demands for the time as defined in the Pull Deployment Horizon immediately if
the ATD quantity permits. With this option products as needed by the requesting location
within the Pull Deployment Horizon are pushed immediately.

ATD

20

10

Shi

10

20

Supply

Rec

Req

20

Demand
10

Period

Graphic 56 Push Deployment 2 (Type P)

Push by Demands (Indicator X)

Push by Demands pushes according to all requirements that are within the planning horizon
as defined in the Time Buckets Profile for Demand Planning and Supply Network Planning.
The Pull Deployment Horizon does not limit the scope of the considered demand elements.
The push takes place immediately.

Understanding

165

M
ATD

20
10

Shi.

10
20

Rec.
20

Deman
10

10

Req.

20

Target Location

Graphic 57 Push Deployment 3 (Type X)

Push by Quota Arrangement (Indicator Q)

Uses the outgoing quota arrangement that must be defined for the source location. The entire
available quantity is pushed to all those locations to which a quota arrangement exists. Note
that this push strategy pushes stock even if there is no demand at the target location.

Push Taking the Safety Stock Horizon into Account (Indicator S)

This push distribution option allows the pushing of all stocks with the exception of the safety
stock. This is true as long as the requirement date does not fall within the period specified in
the product master field Deployment Push Horizon when using Safety Stock, which is
situated on the SNP2 tab. This way all requirements of all target locations are satisfied in a
push principle as long as no safety stock has to be used. The safety stock might get used
nevertheless if the requirement is close enough according to the aforementioned field.

The Deployment Heuristics and Deployment Heuristics Real Time planning runs use the Push
Distribution setting as determined in the product master. The Deployment Optimizer does not use
this setting. When starting the Deployment Optimizer, it can be set to one of three Push
Distribution settings (blank, P, X). Note that in this case, the definition of the Push Distribution
setting is not per product but for all products. This setting overrules the product master setting for
this specific Deployment Optimization planning run.

Understanding

166

In order to use push/pull or fair share rules the following fields must be maintained in addition to
the normally required data:

Rule Type
Rule Indicator
Product
Target Stock
Level
Deployment
Safety Stock
Push Horizon
Quota
Arrangement
Outbound
Quota
Transportation
Lane
Procurement
Priority
Distribution
Priority
Table 41 Required Data for Push/Pull Distribution
Push Distribution, as described above, is enabled for the Deployment Heuristics per product and
source location in the product master. The Deployment Optimizer does not consider the product
master settings but a push distribution according to rule P or X can be specified and is then
valid for all planned products during the planning run. In both cases, push distribution can be
disabled per target location by setting a flag in the location master SNP tab.

3.4.3.5.3

Deployment Order Priority

The definition of deployment order priorities is quite an unknown function. It is used to provide the
transportation planner with information how critical a deployment order for the receiving location is.
The greater the stock shortage at the receiving location, the higher the priority is set. The priorities are
picked up by the TLB run and the system generates loads according to the deployment orders
priorities. The TLB loading sequence is described in the section Transport Load Builder. Deployment
order priorities are only calculated by the Deployment Heuristics Real Time planning and not by any
other deployment algorithm. The Deployment Heuristics provides a result without

Understanding

167

priority definitions and the Deployment Optimizer always plans according to a cost optimal
solution.
Deployment orders including replenishment and VMI orders can be created with a priority rating
from 1 (highest) to 99 (lowest). There is no priority 0 although this figure can be seen if the
deployment priority function is not enabled. The priority is calculated based on the ratio of
existing stock to target stock level at the destination location on the planned receipt date. For this
calculation it is obviously required to define a target stock level. This does not imply that the fair
share rule B (Percentage Fulfillment of Target) is activated for the product at the destination
location. The deployment order priority calculation works with any fair share rule and also without
any. Predefined settings are applied for deployment orders of products where no target stock level
is defined at the receiving location. The deployment order priority is always set to 1 if a backlog
at the receiving location exists. If no backlog is detected the deployment order priority is set to
99.
The deployment order priority calculation uses the following algorithm in all cases where a target
stock level is defined:

Deployment order to raise stock at receiving location to target stock level

The deployment order quantity, provided that enough stock is available at the source
location, is TSL - X with X being the projected stock level before deployment.
The priority is set to (X/TSL)*10. This leads to deployment order priorities between 1
and 10 for all quantities required to reach the target stock level. All values below 1
including negative numbers are rounded up to 1. Fractions are always rounded up to the
next whole number.
Priority 1 is more severe than priority 10.

Deployment order to raise stock at receiving location above target stock level in order to
satisfy other demand
The deployment order quantity, provided that enough stock is available at the source
location, is the DEMAND - Y with Y being the projected free stock that is not required to
satisfy the target stock level. Y should be Zero in all cases where a deployment order was
created to satisfy the target stock level.
The priority is set to 10+(Demand/TSL)*10. The resulting priority value is capped at a
value of 99. Fractions are always rounded up to the next whole number.
Priority 11 is less severe than priority 99.
The implication of this calculation is that the system creates two deployment orders in cases where
the projected stock is below the target stock level and demand exists at the same time. It must also
be noted that the use of the deployment order prioritization excludes the usage of rounding
profiles. Orders are split according to the above calculations and do not consider possible existing
rounding values.

3.4.4

Safety Stock

The discussions regarding safety stock are never ending. Companies usually keep safety stock as a
type of insurance to avoid situations where they could not deliver in time without having it. Then
secondly after the safety stock is built up no one is really allowed to touch it, which then in turn
raises the question why we have it in the first place. I shall not get into this discussion here. We

Understanding

168

shall just have a look at the tools APO provides for calculating the safety stock level. It is
important to understand that safety stock is kept for three reasons: to buffer unexpected peaks in
demand, for late delivery from a supplier or own production facilities, or when the forecasted and
actual demand differs significantly.
Safety stock can be defined irrespective of the reordering process. The Safety Stock is a minimum
quantity that should be maintained at any point in time. It works with deterministic, stochastic,
and optimization processes. There are two groups of safety stock calculation methods, the time
independent and time dependent methods.

Time Independent Safety Stock Method

Methods belonging to this group allow the definition of a safety stock that is constant over
time. Obviously the safety stock setting can be changed as and when required, but the value is
the same for all upcoming planning periods. The safety stock value in this case is stored in the
product master.

Time Dependent Safety Stock Method

In this group we can find methods that allow the definition or calculation of a safety stock
level that changes over time. The safety stock value is stored in a time series (key figure) and
not in the product master.
Safety stock settings can be carried out in two ways, expressed in a quantity or a demand related
figure.

Quantity Based Safety Stock Definition

A quantity based safety stock is expressed in the products base unit of measure and stipulates
a certain amount that should be kept as a safety stock irrespective of any other factor.

Demand Based Safety Stock Definition

Demand based safety stock definitions relate the safety stock to the products demand and is
expressed in time (usually days). If the expected demand goes up, so does the planned safety
stock.
The third criteria to distinguish is the way the safety stock values are established, either
programmatic or as a manual input.

Programmatic Safety Stock Calculation

An algorithm (program) is used to calculate safety stock levels based on other factors such as
e.g. forecast error and/or service levels. This requires that the influencing factors are available
for (stored in) the system. Time dependent methods rely heavily on this principle, as the user
cannot easily define hundreds of safety stock values for a product.

Manual Safety Stock Definition

The user defines based on knowledge and experience or strategic decisions what the safety
stock should be. This method is required in particular when new products are introduced and
no reliable information can be obtained. It is suitable for time independent definitions.
As another criterion the main influencing parameters with their respective deviations can be used
to distinguish the safety stock calculation methods (see above).

Forecast Error Based Safety Stock Definition

It is common to base a safety stock on the forecast error, which is a comparative value between the
forecast and the realized sales. The higher the error, the higher the safety stock should be.

Supply Reliability Based Safety Stock Definition

A supply reliability based safety stock bases the safety stock on the comparison of the
planned and realized supply situation in terms of quantity and time.
Forecast Error and Supply Reliability Based Safety Stock Definition
With this combination both influencing factors are used during the safety stock calculation.

Understanding

169

Safety stock calculations and available functionality differ slightly between SNP and PP/DS. The
following sections provide an overview of how the concept of safety stock is implemented in
them.

3.4.4.1

Safety Stock in SNP

The table below provides a first high-level overview of available safety stock calculation methods
for SNP. All SNP planning algorithms, Heuristics and Optimization, take the safety stock
definitions into account.

Safety Stock

Basic Methods
Time Independent
Time Dependent
Extended Methods
Alpha Service Level
Beta Service Level
No Safety Stock
None
Table 42 Safety Stock Methods
Note the following:
The demand based safety stock level is always defined and displayed in calendar (not
working) days.

The generic term demand used in safety stock level calculations refers to the same demand
that can be seen in the key figure Total Demand in the SNP Interactive Planning
transaction.

The safety stock is a part of the target stock level. Consequently, if the target stock level
method (see separate section) is disabled, no safety stock is maintained by the system at all.

The safety stock method and value can be defined per product and location in the Lot Size tab.
This setting defines where the safety stock value is stored and read by the planning algorithms
(product master or key figure) and how it is defined (related to the product demand or not).
Defining a safety stock is optional and leaving the safety stock indicator blank indicates that no
safety stock planning is required for the product. The safety stock value is calculated and
displayed

Understanding

170

in the SNP Interactive Planning transaction only if the safety stock method is defined in the
product master. System generated safety stock values can be changed in the SNP Interactive
Planning transaction when using basic or extended methods to influence the results of the current
planning run.
Time independent methods require the system to determine the required safety stock in the
products base unit of measure as part of the planning activity. In the case of a demand-based
definition (methods SZ and MZ) this requires the user to evaluate the demand situation and to
transform the demand based time definition into a quantity. As demand changes over time, the
time independent definition appears to be time dependent when expressed in a quantity unit. The
method SZ has therefore a different quantity based safety stock value per day depending on
demand. In the case of method SB, the same quantity based safety stock value can be seen per day.
Time dependent methods are likely to reveal a different quantity based safety stock value per day.
The method MB has a different quantity based safety stock value per day, which reflect the
different safety stock value definitions per day. A different quantity based safety stock value per
day can also be seen with method MZ. But this one is depending on the changing demands and
definitions.
We shall now go through the various possible safety stock calculations offered in the SNP module
of APO, which includes Deployment.

Basic Safety Stock Methods Time Independent

The Basic Safety Stock Methods are all dependent on the user typing in a value based on an
external decision. None of them use the forecast error. The required settings for all The Basic
Safety Stock Methods are stored in the product master. The safety stock values can be used
directly or edited before the reorder planning takes place.
Safety Stock Method SB
For method SB the user defines, in the product master, the required safety stock in the
products base unit of measure. No other parameters are required or considered and the
same safety stock level is applied to each period.
Safety Stock Method SZ
For method SZ the user defines, in the product master, the number of calendar days that
the safety stock must be able to cover in the case that no other receipts occur. The safety
stock is expressed in the products base unit of measure changes from day to day
depending on the changing demand situation. Note that this demand based safety stock is
always defined and displayed in calendar (not working) days. If the demand is rising, the
safety stock expressed in units rises and vice versa. As the system uses calendar and not
working days this leads automatically to changing safety stock levels as the result of
demand-free weekends. No other parameters are required or considered.
Safety Stock Method SM
Using method SM, the system reads the safety stock setting from the product master as it
is the case with method SB and compares it with the result of the demand based
calculation of method SZ. It then applies the greater of the two values as the final safety
stock level.

Basic Safety Stock Methods Time Dependent

Safety Stock Method MB
For safety stock method MB the user defines the required safety stock per period in the
SNP Interactive Planning transaction. The key figure Safety Stock (Planned) is used to
capture the information. Distribution functions can be used to facilitate this task. No

Understanding

171

further parameters are required or considered and the SNP planning runs consequently
consider the individual safety stock values.
Safety Stock Method MZ
The safety stock method MZ requires that the safety days supply be defined per period in
the SNP Interactive Planning transaction. The key figure to do so is not defined in the
standard delivered systems planning book and therefore needs to be defined beforehand.
Distribution functions can be used to facilitate the task of data capturing. No further
parameters are required or considered and the SNP planning runs consequently consider
the individual safety stock values.
The Time dependent safety stock methods MZ and MM work with either workdays or
calendar days depending on the macro definition for workdays. Set the macro definition
for workdays to a seven-day calendar to plan with calendar days. Several workday
definitions could be used in the same planning book.
Safety Stock Method MM
This method is again a combination of two other safety stock methods, namely method
MB and MZ. As is the case for those methods, it is also required for this method to define
the desired values per period. This can become rather laborious as for each period a
safety stock level as well as the safety days supply needs to be captured using the SNP
Interactive Planning transaction. Per period the safety stock value is compared with the
result of the demand based calculation. The greater of the two values is finally used as the
safety stock level. If only one of the two values is defined it is automatically used as the
greater value.
Extended Safety Stock Methods
The Extended Safety Stock Methods are all service level dependent methods. The service
level is a location product dependent value that is stored in the product master. It is also
required to store forecasts and realized sales in an appropriate way as well planned and
realized supply lead times and quantities. A special program carries out the safety stock
calculation. The results can be used directly or edited before the reorder planning takes place.
Refer to the separate section Extended Safety Stock Methods, which deals specifically with
these methods and how the safety stock levels are derived.
Safety Stock Methods AS and AT
With these methods a time dependent safety stock value is established in a special
planning step (separate program). The methods are based on the alpha service level. This
program populates the key figure, Safety Stock (Planned), with the required safety
stock information. Manual updates to the safety stock planning results can be carried out
and saved before the SNP planning run (Heuristics or Optimization) is carried out.
Distribution functions could also be used to facilitate this task.
Safety Stock Methods BS and BT
Besides the fact that these methods are based on the beta service level, the procedure is
the same as described above.

It is common to all quantity based safety stock methods (SB, SM, MB, and MM) as well as
extended safety stock methods (AT, BT, AS, and BS) that the result of the safety stock
determination is stored as the target value in the SNP key figure with the technical name
SAFETY. The phrase determination in this context could also be the manual capturing into a
key figure. This key figure has the label Safety Stock (planned) in the SNP Interactive Planning
transaction. For safety days supply based safety stock methods (SZ, SM, MZ, and MM) the target
values are stored in the SNP key figure Safety Days Supply (planned) which needs to be linked

Understanding

172

to the planning book, as it is not present in the standard delivered system. It is also required that
the macros in the respective planning books are adapted to work with the key figure.
The various planning algorithms (Heuristics, Optimizer) pick up the values in these key figures
depending on the selected safety stock methods and plan accordingly. The projected required
safety stock level during the planning run is stored in the SNP key figure with the technical name
SAFTY. This key figure has the label Safety Stock in the SNP Interactive Planning
transaction. The key figure names, and even the key figures used for this matter, could be changed
to suit specific requirements. After a Heuristics run the key figures with the planned values are
matched by the realized safety stock. When using the Optimizer, this is only the case if enough
resource capacity is available to procure the product in sufficient quantities.
In order to calculate the safety stock levels, the key figures as listed below are used. PP/DS reads
the same key figures using some CTM definitions and algorithms.

Key Figure
Name
Safety Stock
(planned)
Safety Days
Supply (planned)
Safety Stock

Table 43 Safety Stock Key Figures

The safety stock value that can be seen in the key figure SAFTY is part of the overall definition
of the target stock level and therefore incorporated into the key figure LAGRZ. The following
flow chart provides an overview of the ways the different safety stock methods derive the final
required safety stock per period.
Flow Charts exceed the available printing space and are only part of the on-line APO Knowledge
Bank.
Graphic 58 Safety Stock Determination

3.4.4.2

Extended Safety Stock Methods

The standard safety stock methods require the user to define either a safety stock quantity or a
safety days supply, which is transferred to a stock figure based on the expected demand. In both

Understanding

173

cases the safety stock is based on rather subjective decisions that need to be made by the planner.
The data maintenance can become very time-consuming specifically when time dependent
methods are used. As a result of this, safety stock levels are not monitored with the care they
require and often are either too low or too high. The extended safety stock methods overcome the
aforementioned problems and also provide tools to determine the safety stock more accurate. The
main features are the following.

Decision based Calculation

A multitude of parameters are used to derive the final safety stock levels. The main drivers
are:
Forecast and forecast error
Planned and actual lead time
Future demand
Service level
These parameters in conjunction with other settings based on a complex mathematical model
drive the final safety stock levels.

Demand and Supply Orientation

The safety stock is based on the demand variance (forecast error) through the comparison of
the past forecast and the achieved sales for the same period. The supply side is checked via
the comparison of the planned procurement lead-time versus the real lead-time. All four
values need to be stored in a time series (e.g. in the Demand Planning InfoCube) but it is not
required to base the safety stock on demand and supply variation.

Multi Level Approach

Safety stock levels are calculated from the most downstream location upwards to the most
upstream location. Forecasts and related forecast errors that exist at the downstream location
are aggregated to the next higher level. Lead times and lead-time deviations are used
depending on the source of supply. For each step the correct safety stock level is calculated
and is also taken into account at the more upstream locations. As safety stocks are calculated
for all levels at the same time, no unnecessary safety stocks are built up.

Service Level Orientation

The desired service level is an important driver for the safety stock level. It is defined as a
percentage ranging (in theory) from Zero to 100%. It is important to understand that a service
level of 80% does not mean that 80% of the demand is guaranteed to be satisfied. It means
that, with a probability of 80%, all demands can be satisfied as and when requested. In theory
a 100% service level requires an endless stock! The graph below shows the impact of the
desired service level on the safety stock factor. Have a look. In order to increase our service
level from 80% to 95%, we need to nearly double the safety stock (2.06/1.05 = 1.96). And it
gets worse if you want to climb further up.

Understanding

174

S afe ty F ac to r

S erv ice L e v e l
Graphic 59 Service Level Graph
As explained above, the Safety Factor is a function of the desired Service Level. The Safety
Factor increases exponentially with an increasing Service Level. This is depicted in the
graphic above.

Reorder Policy Orientation

The extended safety stock level calculation can be based on a reorder point or on a reorder
cycle approach.
The reorder point approach (methods AS and BS) assumes that the product can be
reordered whenever it falls below the reorder point. The term reorder point used here is
not the same as the reorder point used in the reorder point procedure (see the section
Reorder Process). It merely depicts that the product can be reordered at any point in
time whenever it is required.
The reorder cycle approach (methods AT and BT) assumes that a procurement order
(internal or external) can be created only in certain time intervals (reorder cycles) and not
straight away when a shortage arises. The period length between two possible reorder
points, the reorder cycle or reaction time, is defined in the field Target Days Supply,
which can be found on the product master lot size tab.
Reorder point based extended safety stock levels are lower than reorder cycle based extended
safety stock methods.

Common Approach for all Products

The same approach is used for finished products on all levels of the supply chain linked by
transportation lanes. Even components are included which are linked to the products via the
production process model.

Recognized by all Planning Algorithms

Safety stock levels calculated by the advanced safety stock methods can be used during SNP
Heuristics and Optimization as well as by PP/DS planning algorithms.
Depending on the level for which the safety stock is calculated different input parameters are used
to derive the result. A typical minimum supply chain model consists of a distribution center and a
manufacturing plant. This model can obviously be expanded but the principles remain the same.
Understanding

Level

Type

DC

Plant

Plant

Table 44 Extended Safety Stock Levels

The main drivers for the safety stock level as calculated by the APO extended safety stock
methods are:

Forecast Error
The method to calculate the forecast accuracy (or its error) is Mean Absolute Deviation
(MAD). It runs from Zero upwards and increases with the deviation of forecasted and actual
demand. The MAD does not have an upper limit. The principle behind the usage of the
MAD is that if we have a good forecast, we need less safety stock. The MAD is independent
of desired service levels.

Lead Time Deviation

A smaller but significant impact has the products replenishment lead-time deviation. This
applies to the production, stock transfer, and purchasing lead-time. In the model used by
APO, the length of the lead-time as well as the deviation of the actual lead-time around the
average lead-time has an impact.

Reaction Time
The reaction time describes the time period between two reorder planning runs. It is used in
connection with the cycle reorder policy (see above) used by the extended safety stock
methods AT and BT. The reaction time is defined via the product master field Target Days
Supply on the lot size tab.

Service Level
The extended safety stock method on APO offers two different ways of defining the target
service level.
Service Level
The (alpha) service level is based on the amount of periods where all orders were
satisfied. This is an activity based service level. The service level is the relation of
periods where all sales orders are satisfied (activities or events) in comparison to the
total number of periods. A period where not all demands are satisfied is a period with a
shortfall event.
The extended safety stock methods AS and AT use this service calculation approach.
Service Level

Understanding

176

The (beta) service level is based on the product quantity shipped per period. This is a
quantity based service level. The service level is the relation of the total quantity
shipped over a certain period in comparison to the total required quantity. The shortfall in
this case is not an event but a quantity.
The extended safety stock methods BS and BT use this service calculation approach.
The two service level measurement approaches lead to different results. An example is shown
in the table below. In this example we have 5 periods with a demand of 100 per period. In
period 3 not all orders could be satisfied and thus a shortage occurred.

Period
1
2
3
4
5
6
Total:
6
Service Level:

Table 45 Service Level Comparison

The Service Level is 5 out of 6. This equals to 83.3%.
The Service Level is 580 of 600. This equals to 96.7%

Using the same data, this example shows that the service level is lower than the service
level. This is usually the case but does not have to always be like this. Based on the service
level, the system calculates a safety factor, which is a function of the desired service level
based on the assumption of a normal distribution of orders and order quantities. With rising
service levels, the safety rises and vice versa.
Safety Horizon
The safety horizon is based on the reaction time and the products lead-time. It combines
those two definitions. The lead-time is described as the time between placing an order and
receiving the products. In case of in-house production this figure is derived from the
production time as defined in the PPM. The safety horizon describes the time period required
to overcome a detected stock shortage. The safety stock has to be big enough to cover
potential shortages during this period.

The following flow chart provides an overview of the Extended Safety Stock drivers.

Understanding

177

Flow Charts exceed the available printing space and are only part of the on-line APO Knowledge
Bank.
Graphic 60 Extended Safety Stock Method Drivers
As discussed above it is important to understand that the safety stock based on an extended safety
stock method is calculated by APO in a separate program that needs to be executed regularly. How
often depends on the individual business situation. Sudden and big changes in any of the
influencing parameters require an early re-calculation. In most situations a weekly run should be
sufficient. The safety stock calculation program updates the key figure safety stock (planned).
This key figure can be updated manually if required. Note that it is a prerequisite to maintain the
service level and the safety stock method fields prior to running the safety stock calculation
program.
The following equation summarizes the above explanations. It shows all parameters that influence
the derived safety stock figure:
Safety Stock = f (future demand, forecast error, safety horizon,
lead time deviation, safety factor)

3.4.5

Target Stock Level

The target stock level is an expression for the desired stock that should be in the warehouse at a
given point in time. It can, similar to the safety stock, be expressed as a quantity in the products
base unit of measure or in relation to demand. It works with deterministic, stochastic, and
optimization processes.
Such as the case is with the safety stock definitions, there are two groups of target stock level
calculation methods, the time independent and time dependent methods.

Time Independent Target Stock Level Method

Methods belonging to this group allow the definition of a target stock level that is constant
over time. Obviously the target stock level setting can be changed as and when required, but
the value is the same for all upcoming planning periods.

Time Dependent Target Stock Level Method

In this group we can find methods that allow the definition or calculation of a target stock
level that changes over time.
Target Stock Level settings, again similar to the safety stock settings, can be carried out in two
ways, expressed in a quantity or a demand related figure:

Quantity Based Target Stock Level Definition

A quantity based target stock level is expressed in the products base unit of measure and
stipulates a certain amount that represents the maximum stock that should be kept irrespective
of any other factor.

Demand Based Target Stock Level Definition

Understanding

178

Demand based target stock level definitions relate the target stock level to the products
demand and is expressed in time (usually days). If the expected demand goes up, so does the
planned target stock level.
Target stock level calculations and available functionality are only implemented in SNP Heuristics
planning and neither supported by the SNP Optimizer nor by PP/DS. The following section
provides an overview of how the concept of target stock levels is implemented.

3.4.5.1

Target Stock Level in SNP

The table below provides a first high-level overview of available target stock level methods for
SNP. The SNP Heuristics planning algorithm takes the target stock level definitions into account.
The SNP Optimizer does not recognize the target stock level definitions and is subsequently not
planning according to them. Consequently it also does not support the use of the VMI promotion
lead-time. Both are not required, as the SNP Optimizer calculates the cost optimum and does not
require these settings to achieve this.

Target Stock Level

Basic Methods
Time Independent

Time Dependent
No Target Stock Level
None
Table 46 Target Stock Level Methods
Note the following:

The demand based target stock level is always defined and displayed in calendar (not
working) days.

The generic term demand used in target stock level calculations refers to the same demand
that can be seen in the key figure Total Demand in the SNP Interactive Planning
transaction.

If the target stock level method is disabled (option 7), no safety stock (see separate section) is
maintained by the system at all.

When using a reorder point procedure (see separate section) the target stock level must be
defined, as it serves as the upper stock limit. If the target stock level is below the reorder
point,

Understanding

179

then during planning tasks the target stock level is set to the value of the reorder point. This
means that the system will suggest reorder quantities that maintain at least the reorder point if
no target stock level is defined.
The target stock level method and value can be defined for time independent target stock level
methods per product in the Lot Size tab. Defining a target stock level is optional and setting the
target stock level indicator to the value 7 indicates that no target stock level needs to be
maintained for the product. Time dependent target stock level methods require that the levels be
maintained in the SNP Interactive Planning transaction. The target stock level is calculated and
displayed in the SNP Interactive Planning transaction only if the target stock level method is
defined in the product master.
An inherent problem when calculating the target stock level based on the demand is its
dependency on not only the normal demand, but also on exceptional demand such as demand
caused by promotions. A requirement is to base the target stock level only on the normal (or base)
demand and not on exceptional (e.g. promotion) demand. To achieve this, the VMI promotion
Lead Time is used to calculate the target stock level at a VMI location for promotion demand only.
For normal demand, the target stock level is calculated according to the Target Days Supply
setting. All these calculations are very flexible as they are not coded in the programs directly but
are carried out in the SNP Interactive Planning by means of macros.
In the standard delivered APO system the VMI promotion lead-time is only displayed as a field in
the VMI Planning Book (but could obviously be added to any other planning book). The use of the
VMI promotion lead-time requires that normal and promotion demand be brought across from DP
in two different key figures! In the standard delivered system the normal demand is released into
orders with the category type FA and the VMI promotion demand is released into orders with
the category type FB. The order category FA is allocated to the category group DF1 and to
the key figure 9ADFCST. The order category FB is allocated to the category group DF2 and
to the key figure 9APFCST.

Basic Target Stock Level Methods Time Independent

All time independent target stock level methods require the data to be captured in the product
master. Note that for demand based target stock levels the demand for VMI promotions is
excluded if it was released to SNP in a separate key figure.
Target Stock Level Method 4
For method 4 the user defines, in the product master, the required target stock level in the
products base unit of measure. The same target stock level is applied to all periods.
Target Stock Level Method <blank>
For method <blank> the user defines, in the product master, the target days supply. Note
that the target days supply is always defined and displayed in calendar (not working)
days. If the demand is rising, the target stock level expressed in units rises and vice versa.
As the system uses calendar and not working days this leads automatically to changing
target stock levels (in units) as the result of demand-free weekends.
Target Stock Level Method 5
Using method 5, the system reads the target stock level setting from the product master as
it is the case with method 4 and compares it with the result of the demand based
calculation of method <blank>. It then applies the greater of the two values as the final
target stock level.
Target Stock Level Method 6

Understanding

180

Using method 6, the system reads the target stock level setting from the product master
as it is the case with method 4 and calculates as well the demand based target stock level
of method <blank>. It then applies the total of the two values as the final target stock
level.
Basic Target Stock Level Methods Time Dependent
Target Stock Level Method 1 (Target Days Supply TDS)
The target stock level method 2 requires that the target days supply be defined per period
in the SNP Interactive Planning transaction. The key figure to do so is called Target
Days Supply. Distribution functions can be used to facilitate the task of data capturing.
No further parameters are required or considered and the SNP Heuristics run
consequently considers the individual time dependent target stock values.
Target Stock Level Method 2 (Target Stock Level TSL)
For target stock level method 2 the user defines the required target stock per period in the
SNP Interactive Planning transaction. The key figure Target Stock Level is used to
capture the information. Distribution functions can be used to facilitate this task. No
further parameters are required or considered and the SNP Heuristics run consequently
considers the individual time dependent target stock values.
The time dependent target stock level methods 2 and 3 work with either workdays or
calendar days depending on the macro definition for workdays. Set the macro definition
for workdays to a seven-day calendar to plan with calendar days. Several workday
definitions could be used in the same planning book.
Target Stock Level Method 3
This method is again a combination of two other target stock level methods the method 1
and 2. As it is the case for those methods, it is also required for this method to define the
desired values per period. This can become rather laborious as for each period a target
stock level as well as the target days supply needs to be captured using the SNP
Interactive Planning transaction. Per period the target stock value is compared with the
result of the demand based calculation. The greater of the two values is finally used as
the target stock level. If only one of the two values is defined it is automatically used as
the greater.

In order to calculate the target stock levels, the key figures as listed below are used.

Key Figure
Name
Target Stock
Level (planned)
Target Days
Supply (planned)
Target Stock
Level (*1)

Target Stock
Understanding

Key Figure
Name
Level without

181

VMI Promotion
Target Stock
Level VMI
Promotion
Days Supply
(*2)

Table 47 Target Stock Level Key Figures

(*1) The target stock value that can be seen in the key figure LAGRZ also contains the safety
stock requirements as defined in the key figure SAFTY.
(*2) The Days Supply (coverage) is not derived from the Target Days Supply. It reflects rather
the actual planning situation of the product and should be the same or close to the target
stock level (expressed in days) after a Heuristics planning run.
The following flow chart provides an overview of the ways the different target stock level
methods derive the final required target stock per period.
Flow Charts exceed the available printing space and are only part of the on-line APO Knowledge
Bank.
Graphic 61 Target Stock Level Determination

3.4.6

Days Supply

The Days Supply is a generic term and describes the result derived from the comparison of
receipt and requirement elements. Receipt elements can be found in the ATP categories Stock
and Receipt and consist, for example, of stock and planned production or purchase orders.
Requirement elements are in the ATP category groups Requirement and Forecast and consist,
for example, of sales orders, the forecast values, and dependent requirements. When calculating
the days supply various receipt elements are added up and subsequently requirement elements are
subtracted. The selection of these elements obviously determines the result.
The Days Supply is a valuable figure enabling the planner to judge the planning situation of a
product. This is achieved through the calculation of the future number of periods for which the
currently known (planned) available supply should cover the currently known (planned) demand.
This figure is based on the assumption that the demand and supply situation does not change.

Understanding

182

Changing this demand and supply situation changes the days supply value immediately. The
Days Supply is defined as the number of calendar days that stock and planned receipts should last
to cover the planned requirements that exist at the time of planning. The Days Supply value
displayed in various transactions is not a target value but rather a reflection of the existing
planning situation. It goes hand in hand with the demand based Target Stock Level that can be
defined for a product. In a balanced situation the displayed days supply should be the same as the
target stock level. The target stock level can be defined in the product master lot size tab.

3.4.6.1

Days Supply in SNP

The projected Days Supply can be seen in the SNP Interactive Planning transaction. The system
calculates, via a macro, the days supply value per period. The days supply figure can never be
higher than the number of days left between the displayed date (period) and the end of the
planning period, as the calculating macro cannot see the demands outside the planning horizon.
Note the following definitions:
The opening stock is determined in accordance with the category group defined in the
location master field Stock of the SNP tab. If no specific category group is defined there,
the system uses the category group with the name ST1.

The supply used by the days supply calculating macro is the same supply as shown in the
Total Supply key figure displayed in the SNP Interactive Planning transaction.

The demand used by the days supply calculating macro is the same demand as shown in the
Total Demand key figure displayed in the SNP Interactive Planning transaction.

In the SNP Interactive Planning transaction the only real stock figure is the opening stock as
derived from the stock category definition. All other values are planned stock figures.
Consequently, the first days supply figure is an actual figure and all others are planned. The
days supply figure compares the total demand with the total supply including the planned (or
opening) stock. The displayed figure is independent of a potentially defined safety stock and target
days supply. The comparison of desired target days supply (which includes the safety stock
requirements) and the projected days supply provides the planner with the information required to
judge the actual planning situation.

3.4.7

Supply Chain Model and Planning Version

The supply chain model is the representation of the entire supply network that is planned for in
APO. The supply chain model consists of master data objects that are defined within APO. These
master data objects include:

Locations

Products

Resources

Production Process Models

Hierarchies

Transportation Lanes

Understanding

183

Quota Arrangements
All these master data objects (except transportation lanes and quota arrangements) are firstly
defined irrespective of any supply chain model and then in a second step allocated to one or
multiple supply chain models. Transportation lanes and quota arrangements are defined per supply
chain model and reside in the model rather than being attached to the model. For this reason it is
required to create and maintain transportation lanes and quota arrangements independently per
supply chain model.

The supply chain model can be seen as a pool of master data that is relevant for the planning
process. Based on a supply chain model are one or multiple planning versions. Planning versions
primarily represent the transactional data, which is based on a specific supply chain model. Some
master data can also be defined differently per planning version. This is referred to as planning
version dependent master data. It is used mainly for the purpose of What-If analyses. The
planning version specific master data object must always be part of the supply chain model, which
is used by the planning version(s).
Every planning version is linked to exactly one supply chain model from which it inherits the
master data objects that can be used in the respective planning version. It is therefore required to
make master data available to a supply chain model before the object can be used for planning
tasks. This can be done either in the respective master data maintenance transactions or in the
Supply Chain Engineer. Master data is linked to one or multiple supply chain models and during
this linking the master data is also copied into liveCache per planning version or independent of
the planning version depending on the master data object. Resources for example are always
copied dependent of the planning version. Products on the other hand need to be explicitly defined
per planning version, if this is required.
Multiple supply chain models can be defined in any APO system but only one supply chain model
can be the active model. The active model (on the standard delivered system defaulted to be the
supply chain model 000) is used to represent the real world model as opposed to the simulation
models. When transferring data from an R/3 system via the core interface all master data is made
part of the active model. In order to make this master data available to other supply chain models
it must be attached manually.
All APO modules use planning versions. There are no specific planning versions for DP and/or
SNP. Some of the SNP and PP/DS functionality is driven by settings per planning version. In order
to use a planning version within Demand Planning it is required to create time series objects. Once
that step has been carried out, the planning version can be used in connection with a specific DP
planning area (see The Planning Environment). Before a planning version can be used within
SNP, it has to be initialized. This task needs to be carried out per SNP planning area. These steps
enable the usage of a planning version per DP and/or SNP planning area. PP/DS does not require
such an initialization. An interesting aspect is that it necessary to create a supply chain model with
at least one corresponding planning version even for planning in DP. This is the case although DP
does not require the definition of a supply chain model, as it can work without APO defined
master like products or locations.
Within Demand Planning, the various planning versions are used to distinguish the various
product forecasts. The different forecast versions can then be brought across to SNP, where the
forecasts feasibility is determined using the supply chain model to which the planning version is
linked. This activity, referred to as the release of the forecast from DP to SNP can be carried out
within the
Understanding

same planning version of a given supply chain model or across different planning versions. In
order to carry out a What-If analysis based on one forecast and different supply chain models,

different supply chain models could be used. Various combinations of these base principles can be
set up.
There are no dependencies between supply chain model and planning version names. Those
reserved are for the active supply chain model 000 and the active planning version 000.
The following example gives an overview of some possible What-If scenarios around the active
supply chain model and planning version.

Path 0 is the active path (gray shaded blocks)

Path 1 is used for an alternate inactive forecast based on the active supply chain model.

Path 2 is used to test an alternate inactive supply chain model with its inactive planning
version based on the active forecast.

DP

P
Ve

P
Ve

Graphic 62 Active Planning and What-If Scenarios

3.4.8

Requirements Strategies

APO supports as standard four different Requirements Strategies. The APO requirements strategy
is the counterpart of the R/3 Planning Strategy. Both definitions must be synchronized.
Changing of the SAP defined requirements strategies is technically possible but not
recommended. It is better to rather add new requirements strategies if required. The way the
forecast consumption (see section Forecast Consumption) is carried out also depends on the
settings per requirements

Understanding

185

strategy. The real driver behind the different requirements strategies is a field called Planning
Segment. The planning segments in APO, as well as in R/3, are used to separate the planning
activities within the Make-To-Sock and Make-To-Order environments. A planning segment is thus
a logical structure in which demand is planned (in Demand Planning) and consumed (vie the sales
orders from R/3). Planning is carried out within one specific planning segment. Since there is no
rule without exception, we can also find a planning segment that permits the combination of the
Make-To-Order and Make-To-Stock planning principles.
Common to all planning segments is that the procurement of components can be carried out based
on the forecast from Demand Planning. This function is more obvious in a Make-to-Order
environment but is also frequently needed in a Make-to- Stock environment with long lead time
components.
The following planning segments exist.
Planning Segment 0 (or blank)
This planning segment supports a Make-to-Stock environment. Production is based solely on
the forecast from Demand Planning and carried out irrespective of the incoming sales orders.
For planning purposes, sales orders are ignored. Sales order demand is satisfied using
warehouse stock.

Planning Segment 1
This planning segment supports a Make-to-Order environment. Production is carried out as
and when sales orders are received. Existing warehouse stock is not taken into account for
production planning purposes, nor is it used to satisfy incoming sales orders.

Planning Segment 2
This planning segment supports a mix of Make-to-Order and Make-To-Stock principles.
Production is carried out as and when sales orders are received (Make-to-Order). Existing
warehouse stock is not taken into account for production planning purposes (Make-to-Order).
Sales order demand is satisfied using warehouse stock (Make-to-Stock).

Note that the planning segment definitions do not influence whether and how the forecast is
consumed by incoming requirements. The Assignment Mode determines this. Each
requirements strategy has a specific (forecast consumption) assignment mode. The following
assignment modes exist.

Assignment Mode blank No Assignment

Incoming sales orders do not consume any forecast.
Assignment Mode 1 Assignment of Customer Requirements: Planning with Assembly
Incoming sales orders consume the product forecast but do not trigger any production.
Assignment Mode 2 Assignment of Customer Requirements: Planning without Assembly
Incoming sales orders consume the product forecast and trigger the production process.

Assignment Mode 3 Assignment of Customer Requirements to Planning Product

With this assignment mode the incoming sales order does not consume its own forecast but
that of the planning product. In situations where multiple products are very similar they might
be forecasted as one planning product. The planning product combines all requirements of the
individual products. As and when sales orders arrive for any of the individual products, the
forecast of the planning product is consumed. This assignment mode is typically used in a
variant-rich Make-to-Order environment.

Understanding

186

Since we now know the two main ingredients for the requirements strategies, we can have a look
at those defined in the standard delivered system. Two of the three planning segments described
above are linked to the four assignments modes.

Requirements Strategy 10 Anonymous Make to Stock Production

Using this Make to Stock strategy, production is carried out irrespective of the incoming sales
orders and solely based on the forecast. For planning purposes, sales orders are ignored. This
is the requirements strategy typically used in mass production.
Planning Segment 0 Make-to-Stock; demand satisfied by warehouse stock and no
production triggered
Assignment Mode blank Incoming sales orders do not consume the forecast.

Requirements Strategy 20 Planning with Final Assembly

Production is planned according to the forecast as well as sales orders when using this Make
to Stock requirements strategy. The term with final assembly depicts that the products
demand is planned and the final production (assembly) is carried out. Thus the product is
available as warehouse stock. The forecast is usually the sole driver for the longer term
planning (as no sales orders exist yet) and a mix of forecast and sales orders are used for the
medium to short term planning.
Planning Segment 0 Make-to-Stock; demand satisfied by warehouse stock and no
production triggered
Assignment Mode 1 Incoming sales orders consume the products forecast.

Requirements Strategy 30 Planning without Final Assembly

Using this Make to Order strategy, production is carried out based only on incoming sales
orders. The term without final assembly depicts that the products demand is planned but
the final production (assembly) is not carried out. Thus the product is not available as
warehouse stock although a forecast exists. Requirements for the product are thus only
created at time of sales order receipt.
Planning Segment 1 Make-to-Order; demand satisfied by individually reserved stock
and production triggered
Assignment Mode 2 Incoming sales orders consume the products forecast.

Requirements Strategy 40 Planning Product

Using this Make to Order strategy, production is carried out based only on incoming sales
orders for the individual product. The planning products demand is planned for but the final
production of the individual product is not carried out until a sales order arises for the
individual product. Thus the individual product is not available as warehouse and the existing
forecast is for the planning product.
Planning Segment 1 Make-to-Order; demand satisfied by individually reserved stock
and production triggered
Assignment Mode 3 Incoming sales orders consume the planning products forecast.
There is a flag in the product master called Assembly Planning. If this flag is switched on the
forecast of the dependent demand can be consumed instead of that of the finished product. This
also works in conjunction with transportation requirements. In this case the sales order in location
A can consume the forecast of the product in location B from where the product is sourced. The
flag can be set in conjunction with any of the above requirement strategies. Only requirements
strategies 20, 30, and 40 of the standard delivered system trigger forecast consumption (see
section Forecast Consumption). In order for this forecast consumption to actually be carried out,
the product master needs to be set up accordingly. A prerequisite for the forecast consumption is
that an appropriate requirements strategy is defined in the product master demand tab.

Understanding

187

Where is the forecast stored?

The requirements strategies do not only define whether a forecast has to be consumed (see above),
they also define which order category (also called ATP category) the orders have in which the
forecast to be consumed is stored. The standard delivered system uses the order category FA. In
this setup the assumption is that the forecast released from DP is stored as independent
requirements in SNP using orders of the order category FA. Incoming orders (e.g. sales orders)
then consume the forecast values stored in these independent requirements.
Which orders trigger forecast consumption?
Even this can be defined individually per requirements strategy. Category Groups are groups of
order categories and are defined in customizing. The standard delivered system has a category
group K01 linked to all requirement strategies (even to the requirements strategy 10, which does
not trigger forecast consumption!). This category group contains the order category BM and
subsequently any order of category BM (sales order) can consume the product forecast in
accordance with the assignment mode setting. Besides this matching of the order type, the
assignment mode defined in the requirements strategy must match the assignment mode of the
order. For this process to work it is also required to have a valid requirements strategy defined in
the product master.
The matching, depicted in the graphic below, is using the following steps:
1. Find product master to determine requirements strategy
2. Find requirements strategy to determine assignment mode and category group
3. Match sales order and requirements strategy assignment modes they must match
4. Find category group and determine order category
5. Match sales order and category group (requirements strategy) order type they must match
6. Carry out forecast consumption using order category and planning version as defined
Understanding

Sales Order
Product Number

Assignment Mode

Order Category

Graphic 63 Assignment Mode Matching

With APO the same product can be used in conjunction with different requirements strategies.
This is required if the same product for example is sold in a Make-to-Order and in a Make-toStock environment. In this case the two requirement types would have to be forecasted separately
(one per requirements strategy). The forecasts could then be released into orders with different
order (ATP) categories and consumed separately with every incoming sales order.

3.4.9

Production Strategies

APO supports various production strategies. The planning processes for the supported production
strategies in APO most of the times do not differ too much from each other. A much bigger
impact of the production strategy can be seen in the production execution system (R/3).

Discrete Manufacturing
This strategy is characterized by the use of single production orders that reflect a certain
production quantity. The production process usually involves the use of several resources and
complex relations between resources might occur. The control object for the production and
the product costing is the production order. Production data in the R/3 system is stored
primarily in the Production Version (combination of Bill of Material and Routing), which are
converted to the APO PPM. Discrete manufacturing can be found in make-to-stock and
make-to-order environments (see requirements strategies).
Characteristics Dependent Planning and Batch Management are supported but not typically
used in this production environment.

Understanding

189

Process Manufacturing
Process manufacturing is not too different from the discrete manufacturing production
strategy. The main distinguishing factor is the use of the Recipe in R/3 instead of the BOM
and Routing. The recipe is used to create the APO PPM. Some special planning tools, which
are used specifically in a process-manufacturing environment, can be found in APO. They are
for example Campaign Planning and Campaign Optimization. Process manufacturing can
also be found in make-to-stock and make-to-order environments (see requirements strategies).
Both Characteristics Dependent Planning and Batch Management can often be found in
conjunction with this production environment.
Repetitive Manufacturing (1)
Option 1 of repetitive manufacturing supports the mass production of standardized products.
Its aim is a simplified planning and execution process. Simple production processes (from a
planning point of view), using very few resources during the production process, characterize
this manufacturing strategy. SAP also uses the expression Continuous Manufacturing to
describe this option of repetitive manufacturing. The control object for the production and the
product costing is not the production order but the product itself. Production data in the R/3
system is stored primarily in the Production Version (combination of Bill of Material and
Routing), which are converted to the APO PPM. Repetitive manufacturing (option 1) can
typically be found in make-to-stock environments (see requirements strategies).
Batch Management is often used in this production environment.
Repetitive Manufacturing (2)
Option 2 of repetitive manufacturing supports the mass production of highly configurable
products (e.g. cars). Its aim is to support an environment where complex requirement
explosions based on product characteristics need to be carried out frequently. In order to
support this manufacturing environment, APO uses special resources (the line resources) and
the iPPE (Integrated Product and Process Engineering) instead of the PPM. Option 2 of
repetitive manufacturing is not fully supported by R/3 and requires the use of other special
execution systems, which are referred to as Discrete Industries (DI) Systems. Repetitive
manufacturing (2) supports make-to-stock and make-to-order environments and uses
configurable products (Characteristics Dependent Planning).

The APO Knowledge Bank incorporates the first three options. Option 4 is only referred to as and
where applicable to point out differences.

3.4.10

Planning Levels

Planning in APO, except DP, is carried out, by default, per product and location. Levels below the
location, such as the sub location, version, or account assignment can possibly be seen but not
used as a planning level. The PP/DS Product View transaction for example displays all batches
(versions) of a product defined in R/3 alongside with the stock quantity but it could not plan on
this level. The same applies to the sub location, called storage location in R/3.

Planning on higher level

There are currently only very limited no possibilities to plan on aggregated levels such as
product groups or location groups. The SNP Optimizer is the only tool to offer some type of
aggregated planning. It permits for example the planning in time buckets other than days. This

Understanding

190

includes the possibility to plan in time buckets of various lengths within the same planning
run (telescopic time frame).
Planning on lower level
Planning on version and/or account assignment is not supported. In order to plan on storage
location level, the MRP Area definition can be used. The MRP area in APO is the
equivalent to the MRP area in R/3 and represents the combination of an R/3 plant with
exactly one R/3 storage location. This is a very interesting tool, as it permits the use of a
storage location as a planning level. Each MRP area in APO is represented by a location just
like any other R/3 plant. The data transfer via the core interface is fully supported and it is not
even required for the user of the attached R/3 system to be aware of the MRP area.

The possible data flow is depicted in the diagram further below. Note that any dataset that
contains the storage location information can be directed to and created in relation to the
appropriate MRP area defined in APO. Some data sets, such as the forecast, do not have a storage
location and are thus directed to the APO location that identifies the R/3 plant and not the MRP
area. The following graphic provides an overview.
The table underneath provides some examples how transactions from R/3 (sales order) or from
within APO (DP forecast) as well as stock levels are allocated to the different locations used in the
graphic above.

Document
Sales Order
Sales Order
Sales Order
Forecast
Stock
Stock
Stock
Stock
Table 48 Planning Level MRP Area
Understanding

R/3

M R P Ar e a X

DefaultMRP Planning Level

APO

Graphic 64 Planning Level MRP Area

Care needs to be taken in cases where forecast consumption is carried out in the APO system. As
the sales order is directed to different APO locations depending on the plant/storage location from
R/3, the forecast consumption might be too low or at an undesired location.

3.4.11

Priorities

While working with an APO system one quickly finds out that the word priority is used
frequently and not only in one context. The list below provides an overview of various priorities
used in the system and what they are used for.

Name
Location Priority

Product Priority
Mode Priority
Procurement Priority
(1)
Understanding

Name
Procurement Priority
(2)
Distribution Priority
Demand Priority
Alert Priority
Carrier Priority
Deployment Order
Priority

PP/DS Order
Priority
Sales Order Priority
Priority Rules in
Capacity Leveling
Hard Prioritization
Order Category
Priority
Table 49 Priority Definitions

Understanding

3.5

193

Resources and Capacity Consumption

Capacity planning can be described as the comparison of available with the required capacity. In
APO the available capacity is defined in the resource and the required capacity is derived from the
definitions in the production process model (PPM). The PPM represents a combination of Bill of
Material (BOM) and Routing. In situations where the R/3 Process Industry extension of the
Production Planning module (PP-PI) is used, the PPM is generated based on the Recipe rather than
the BOM and Routing. Amongst other definitions, the PPM depicts which resource is required for
a certain activity and how long (duration). It might also provide information about the resource
consumption. When scheduling an activity in APO, the two parameters, activity duration and
resource consumption need to be determined. This process depends on the type of resource used.
The resource consumption is also referred to as the capacity consumption.
The following sections provide an introduction into the different types of resources in APO, the
PPM, and finally the capacity consumption calculation.

3.5.1

Resources

An APO resource is characterized by having one or multiple capacity definitions. During the
various planning and optimization processes the resources will be loaded, thus displaying a
balance between available and used capacity. Resources are grouped into resource categories. The
resource category is not used as a functional grouping of resources; it is purely descriptive. There
are no planning activities that are limited to any specific resource category. The possible resource
categories in APO are listed below.

Category
P

Descrip
Produc

Storage

Storage

Transpo

Table 50 Resource Categories

Although some resource categories are predominately used by a certain APO module, resources of
any category are used by most of the modules. A PP/DS planning task will for example utilize
(load) a transportation resource during the creation of a purchase requisition if such a
transportation resource is linked to the transportation lane used. The main function of a resource is
that it has a capacity (or multiple capacities). These can be expressed in time (as it is the case for
an R/3 capacity, for example, 10 hours per workday for a production resource) or independent of
time (e.g. 100 pallets in a Storage Resource).

Understanding

194

APO uses the acronyms Bucket Resource and Time Continuous Resource to define the type
of resource. Time continuous resources are broken down further into Single and Multi Activity
Resources, Production Line Resources (all used by PP/DS), and Vehicle Resources (used by
TP/VS). The group of bucket resources comprises the Bucket Resource and the Transportation
Resource; they are primarily used in SNP including Deployment. Time-continuous resources are
used in PP/DS, TP/VS, and possibly for CTM based planning in SNP and PP/DS. All resource
types except line resources can be used in the PPM. The production line resource can only be used
in conjunction with Integrated Product and Process Engineering (iPPE).
Since release 2.0 it is possible to also create Mixed Resources. A Mixed Resource is a
combination of the two resource types, Bucket Resource and Time Continuous Resource. Mixed
resources can be defined as Single Mixed, Multi Mixed, and Line Mixed resources. Release 3.0 of
APO saw the introduction of some more functionality for resources. This included the
introduction of Production Line Resources that are used within PP/DS and Vehicle Resources for
use within TP/VS (see above). Furthermore, Multi Activity Resources can be flagged as Tank
Resources indicating the resources ability to store products.

Type
01

Description
Multi Activity Resource

02

Single Activity Resource

03

Bucket Resource

04

Single Mixed Resource

05

Multi Mixed Resource

06

Single Line Resource

07

Single Line Mixed Resource

08

Transport Resource

09

Vehicle Resource

Table 51 Resource Types

Most resource types are required to be allocated to a specific location before they can be used in a
planning process. Shipment and vehicle resources are exceptions, as they are not required to be
location specific. The use of Reference Resources simplifies the data maintenance in cases where
multiple Resources with the same parameters need to be maintained individually. Capacities can
be copied from R/3 to APO, where they are used to initially create resources.
The following graph gives an overview of APO resource types and their commonly allocated
categories.
Understanding

Mixed Resources
Graphic 65 Resource Overview
The following sections deal with all aspects of APO resource management. This includes detailed
descriptions of the following areas:

Bucket Resources

Time-Continuous Resources

Mixed Resources

Standard Capacity and Capacity Variants

Definitions
The sections following immediately after the current one will deal with bucket resources. Those
sections dealing with time-continuous resources will follow after that. The principles and
terminology of these two types of resources are different, although both have a very similar
structure. The sections dealing with Mixed Resources follow suit. Most of the tasks within the
APO resource management are very similar if not the same and independent of the resource type.
In this case one section simply covers all resource types.
R/3 can maintain, via the core interface, (CIF) time continuous resources and via a special user
exit mixed resources as well. A flag in the work center in R/3 drives the distinction between single
and multi activity resources. The flag is called Can be used by several operations and must be
off to create single activity resources (or on to create multi activity resources). The
maintenance of bucket resources from R/3 using the CIF is not possible.

Understanding

196

The header data of line resources can be created in the R/3 industry solution Automotive System
and transferred via the CIF.

3.5.1.1

Bucket Resources

A Bucket Resource has a capacity that can be planned down to a daily level without considering
sequencing constraints. It can have up to two different capacities (e.g. volume and weight for a
truck). Finite scheduling is not possible for a Bucket Resource and thus Bucket Resources cannot
be used by PP/DS. Both available capacities can be expressed as a quantity (e.g. 100 tons) or as a
rate (e.g. 100 kg/day). The time aspect in the rate definition of a bucket resource is always per
day. It is also possible to define available hours per day as the capacity (e.g. 10 working
hours/day).
Capacity requirements coming from planned orders are loaded onto the resource only considering
the available capacity within the time frame (day). This approach can possibly lead to a situation
where several planned orders are loaded onto the resource although they all require starting at the
same time. In this case finite scheduling, which will be carried out in PP/DS, detects an infeasible
solution and the production plan will have to be altered. The SNP Optimizer allows defining the
time aspect of a bucket resource. Either one day or a multiple of days can be seen as one bucket in
the Optimizer. Using multiple days improves the run time of the Optimizer but at the same time
increases the likelihood of Finite Scheduling violations later on in the process.
Bucket Resources can be used by the SNP Heuristic run, the SNP Optimizer, and by CTM. The
Transport Load Builder also uses them. The SNP Heuristic run only loads capacity requirements
onto the resource; it does not carry out any capacity feasibility checks. Please note that the SNP
Optimizer only uses capacity variant 1 and capacity variant 2. In a first attempt, the SNP
Optimizer uses the capacity variant with the lower capacity, and, if no sufficient capacity is
available, it will switch over to the other capacity variant. It therefore does not matter which of the
two capacity variants provides the higher or the lower capacity.
The maintenance of the resource master is simplified by the use of capacity variants and
definitions, both of which are maintained from within the resource master data transaction.

3.5.1.2

Time-Continuous Resources

Time Continuous Resources are broken down into the groups, Single Activity and Multi Activity
Resources. These types of resources can be used for finite scheduling down to the second.
Whenever a resource is loaded, which means a planned order requires capacity; the scheduling is
carried out considering sequence constraints. Time-continuous resources are broken down into the
single and multi activity resources.

Single Activity Resource

A Single Activity Resource is the same as an R/3 work center with one defined capacity. It
has one capacity, which is expressed in time. Single Activity Resources can only be used by
the CTM run and by PP/DS, not by the SNP Heuristics run or the SNP Optimizer.

Understanding

197

Multi Activity Resource

A Multi Activity Resource is the equivalent of an R/3 work center with multiple capacities
attached to it. Two options are available when defining the capacity of a Multi Activity
Resource.
The first option is used in the case where a resource consists of several identical machines,
each having the same type and amount of capacity. With this option exactly one production
order can be allocated to any of the machines within this resource at any given moment. An
example would be a Drilling Work Center where three drills are available. Each of them can
serve exactly one production order at a time and a production order will use only one of the
drills.
The second option allows defining a second capacity restriction for the Multi Activity
Resource. This capacity is expressed in relation to a unit of measure other than time. During
scheduling the system can allocate several production orders for the same point of time as
long as the total capacity (expressed in a unit of measure other than time) of all scheduled
orders is not exceeding the available capacity of the resource. An example would be a
Freezing Facility where the total weight based capacity is 100 kg and the total time capacity is
8 hours a day. The system can allocate multiple production orders to the resource at any point
in time as long as the total freezing capacity of 100 kg is not exceeded. The SNP Heuristics
run or the SNP Optimizer cannot use Multi Activity Resources; they can be used by the CTM
run and by PP/DS.
The parameter Synchronized Start can be applied to multi activity resources and ensures,
when applied, that all activities at all capacities of the resource start at the same time. This is
valid for both options.
While the single activity and multi activity resources are used in a discrete order environment,
another special time continuous resource exists for the repetitive manufacturing environment.

Production Line Resource

The production line resource is a time-continuous resource, which has two capacity related
definitions. The first one defines the working hours (like any other time-continuous resource),
and the second one defines a rate. This rate determines how much can be produced per time
period. An example would be a car manufacturers assembly line with a capacity of 10 cars
per hour. This type of rate is independent of a certain model. It just states that a certain
amount of cars can be manufactured per hour. Another option is to stipulate a product
dependent rate. In this case the definition relates the resource to its capability to produce a
certain product explicitly. In the example of the assembly line this might be 12 cars of a
specific model.
The term repetitive manufacturing is generally used by SAP in the context as described
above and not in cases of mass manufacturing of products on dedicated lines. This is mostly
described as continuous manufacturing, which does not require any specific resource types
as it is modeled using normal bucket and time-continuous resources.
Specifically for the usage with TP/VS, another time continuous resource can be found.

Vehicle Resource
The vehicle resource used for vehicle scheduling is a special type of single activity timecontinuous resource. Unlike other resources it does not need to be linked to a specific
location, thus allowing the modeling of external carrier vehicles that are not bound to any
specific location. The vehicle resource is not necessarily bound in reality to any existing
resource, as is the case with the other resources types. Vehicle resources that are dedicated to
a location are seen as part of an own fleet with the location being the depot of the vehicle.
There are also no mixed resources, as the vehicle resource relates to one vehicle with certain
limitations while the bucket type transportation resource depicts a total capacity that can be
used for example on

Understanding

198

a transportation method of a lane. Another important factor is that the vehicle resource can
have multiple capacity definitions at the same time (e.g. a weight and a cube capacity).
Time-continuous resources (except vehicle resources) can be used at any given point in time by:
Exactly one planned order (Single Activity Resource (Option 1)).
Part of a planned order in the case of operation split (Single Activity Resource (Option 2)).
Operation split, that is the distribution of a production order operation over various resources,
is initiated by a setting in the PPM. If operation split is enabled, an operation is distributed
over various resources of different modes.

As many planned orders as activities exist in the resource or in other words exactly one
planned order per capacity (Multi Activity Resource (Option 1) with time based capacity
defined only),

As many planned orders as possible according to the unit-based capacity (Multi Activity
Resource (Option 2) with time and unit based capacity defined).
The resource type Single Activity or Multi-Activity can be used in conjunction with the
resource category Production. The following graphic provides an overview of the possible
operation/activity allocation to resources.

Resource1
Resource2

C a p a c it y 1
C a p a c it y 2

Graphic 66 Time Continuous Resources

Understanding

199

Standard Capacity and Capacity Variants

The definition of available capacity is done either by setting up a standard capacity or by creating
one or multiple capacity variants. The use of standard capacity is a simple way of defining the
available capacity for a resource. It does not allow defining precise shifts or shift sequences, nor
does it allow defining breaks at predefined times. It is adequate for resources that are not a
bottleneck and where finite scheduling can be carried out on the shop floor. Furthermore only one
possible capacity, the standard capacity, can be defined.
The use of capacity variants allows a precise, down to the second, definition of working and nonworking time. This is achieved by means of precise shift and break times as well as efficiency
rates per shift. Various capacity variants can be defined allowing the parallel definition of several
scenarios. Any maintained capacity variant could be set to Active. The scheduler that is
accessed from the SNP Interactive Planning Screen uses the active capacity variant. Capacity
variants have a validity period thus allowing easy maintenance of capacity related data. Should no
capacity variant be defined (or valid), the system uses the standard capacity (see also the section
Finding the Valid Capacity). For Standard Capacities only the start time, end time and break
duration is maintained. They are available on all workdays according to the factory calendar.

3.5.1.3

Mixed Resources

The Mixed Resource, introduced to APO with release 2.0, is not another resource type but a
combination of a bucket resource with either a single-activity or multi-activity resource.
Consequently, there are three mixed resources namely the single-mixed, multi-mixed, and the linemixed resource. The introduction of the mixed resources greatly simplifies the maintenance of
resources as exactly the same resource master can be used for SNP, CTM, and PP/DS planning
purposes. In general, the mixed resources contain all fields of the bucket resource and the single or
multi-activity resource. This means that some of the information that can be found in the mixed
resource master applies only to SNP planning, while other is valid only during PP/DS planning.
The table below provides an overview of the relation between the bucket, time-continuous, and
mixed resources for selected resource categories.

Resource
Category
P
P
P
S
H
T
Understanding

Table 52 Resource Overview

200

Mixed resources gain more and more importance within the APO system, as some
functionality depends on the existence of such resources. A new feature starting with release 3.1 is
that two different horizons can be defined for the PP/DS and SNP production horizons. This
allows overlapping these two horizons and jointly plan a common period as long as mixed
resources are used.

3.5.1.4

Standard Capacity and Capacity Variants

One standard capacity can be defined per resource. This is done on the Standard Capacity tab.
There is no need to maintain any definitions in order to use standard capacities. Standard
capacities are defined by specifying the numeric value together with a unit of measure (bucket
resources) or a start and end time together with the break duration (time-continuous resources).
For time-continuous resources a resource utilization factor can be defined that adjusts the net
capacity. The standard capacity is only used if no capacity variants have been defined for the
resource and made active. The Optimizer does not use the standard capacity, as it requires the
capacity variants 1 and 2 to be maintained. In scheduling, the standard capacity is used if no
capacity variants are defined. The system does not enforce the maintenance of any capacity at all.
Obviously, in such a case the resource cannot be used at all. Also see the section Finding the
Valid Capacity.
While using capacity variants, the maintenance of the resource master is greatly simplified by the
use of definitions. The following types of definitions can be linked to a capacity variant and
resource.

Capacity Variants for Time-Continuous Resources

The capacity variant links the resource to a shift sequence. Shift sequences are defined using
shifts, breaks, and shift factors (see section "Definitions"). Various capacity variants can be
linked to the same resource, either for the same period or for different periods. Each capacity
variant has a validity period.

Capacity Variants for Bucket Resources

For bucket resources, the capacity variant links the resource to a quantity/rate definition (see
also the section "Definitions"). Various Quantity/Rates definitions can be linked to the same
resource either for the same period or for different periods. Each capacity variant has a
validity period. Additional Capacity Variant keys can only be defined when accessing the
resource master data maintenance from the PP/DS menu.

Capacity Variants for Mixed Resources

Mixed resources can be linked to two different definitions. One definition is of type shift
sequence and used when performing time-continuous scheduling tasks and the other is of
type quantity/rate and used when performing bucket related scheduling tasks.

Capacity Variants for Line Resources

Line resources can be linked to two different definitions. One definition is of type shift
sequence and used when performing time-continuous scheduling tasks. The second
definition is of the type rate definition or material dependent rate.

Capacity Variants for Line Mixed Resources

Understanding

201

Line mixed resources can be linked to three different definitions. One definition is of type
shift sequence and used when performing time-continuous scheduling tasks and the other is
of type quantity/rate and used when performing bucket related scheduling tasks. The third
definition is of the type rate definition or material dependent rate.
For resources without any defined capacity variants, a variant 0 can be seen on the overview
screen. Periods with no capacity can be defined by simply keeping gaps between the valid to and
valid from entries. It is also possible to specifically define shift definitions with Zero available
capacity. The definition of the capacity might be temporarily overwritten by times defined as
breakdown.
The following table provides an overview of the possible definitions allocation to capacity variants
per resource type.

Definition
Resource Type
Time-Continuous
Mixed
Production Line
Line Mixed
Bucket
Shipment
Vehicle
Table 53 Capacity Variants and Definitions

3.5.1.5

Definitions

Definitions are used to simplify the maintenance of resources. As the name suggests, they define
various parameters that are usually shared across multiple resources. One could also see them as
some type of profiles. Definitions are linked to a resource via the capacity variant. Any resource
can have no, one, or multiple capacity variants, each of these capacity variants being linked to a
specific definition. The definitions that can be linked to bucket, time-continuous, and line
resources are different.
The maintenance of definitions is part of the resource maintenance transaction. Following
definitions exist:

Shift Factors
Shift factors define the productivity; shift factors are linked to a shift.
Understanding

Breaks
Breaks define break times; breaks are linked to a shift.
Shifts
Shifts define the shift start and end time; shifts are linked to a shift sequences.
Shift Sequences

Shift sequences define the sequence of individually defined shifts. They are linked to
capacity variants.
Quantities/Rates
Quantities/Rates define the output as a quantity without time relation or as a rate. They are
linked to capacity variants.
Rate Definitions
Rate definitions define the output rate of a resource expressed in a material (product)
independent unit of measure (e.g. kg per hour). They are linked to capacity variants.
Material Dependent Rates
Material dependent rates describe the relation of a production line to a specific product. They
are linked to production line and line mixed resources.

S h if t 1
S h if t F a c to r
A

Graphic 67 Resource Definitions

It is possible to link the same shift factor and break pattern definition to various shift definitions.
The same shift definition can be linked to various shift sequences, and finally the same shift
sequence can be used with multiple capacity variants.
The following text provides an in-depth view on all definitions including their respective fields
and field usage.

Shift Factor
The Shift Factor defines the efficiency during working time.
The efficiency is expressed as a percentage and called resource utilization. The shift factor is
used together with the break time to calculate the available working time per shift. In the
case of multi activity resources the number of capacities with unit of measure (if appropriate)
are

Understanding

203

defined here as well. Shift factors have a mandatory Valid To date and, as an option, a
planner can be defined.
Break Patterns
Break Patterns define the non-working time.
They can be defined in two different ways. Option 1 is to specify a break start and end time,
which automatically calculates the break duration. Use this option if a break has to occur at
predefined times (e.g. the lunch break is at exactly 12.00). Option 2 allows defining the
amount of time between the shift start and the start of the break. Additionally the break
duration has to be defined. This option is used when it is required to ensure that a break
occurs at least after a predefined amount of time (e.g. a break must start after four hours of
work). It is advisable to use only one of the two options for a specific shift definition. Break
Patterns have an option to define a planner.
Shift Definition
The Shift Definition stipulates the net available working time.
In the Shift Definition, the shift start and end time is specified together with the break pattern
and shift factor. Note that no shift factors or break times are captured in the Shift Definition
but the respective definitions are linked to the shift definition. The same break pattern and
shift factor can be used several times thus tremendously reducing the amount of data
capturing time. The output is the so-called Productive Time, which is calculated as follows:
Productive Time =

(End of Shift Start of Shift Total Break Times) *

Resource Utilization / 100

Shift Definitions have a mandatory Valid To date and as an option a planner can be defined.

Shift Sequence
The Shift Sequence defines the sequences of shifts within a given period.
Per day, up to 9 shifts can be defined. In a typical weekly shift sequence one can find 7
entries, one per day, and each with the respective shifts per day. It is important to also define
the non-working days in such a definition. The shift sequence automatically restarts after the
last day of the sequence. In the shift sequence one can define whether or not shifts are allowed
to start or finish on non-working days. Shift sequences have a mandatory Valid To date and
as an option a planner can be defined. In an environment where exactly the same shifts occur
daily (number and type of shifts), it is sufficient to define a shift sequence where one day is
defined only. The definition is then valid for all working days.
Quantities/Rates
The Quantity/Rates Definition defines the bucket capacity.
It is the only definition used for Bucket Resources and is not used by Single/Multi Activity
Resources. The Quantities/Rates definition is used for SNP planning purposes. This planning
procedure can be compared to Rough Cut Capacity Planning in R/3. In this planning step, it is
adequate to plan not to the finest detail possible and ignore specific setup, tear down, and wait
times, as long these activities do not constitute an abnormal high portion of the entire
operation. Instead, it makes more sense to lower the available capacity of the bucket resource
by a certain amount. The difference between this lowered available capacity defined in the
Quantity/Rates definition and the real total capacity is then the buffer. It will not be used by
SNP, but can be used by PP/DS when finite scheduling is carried out if the time-continuous
resource is adequately defined. When working with separate bucket and time-continuous
resources, it is up to the planner to ensure that the master data is aligned appropriately. When
using mixed resources, the relation between these two capacities is defined using the Loss

Understanding

204

Factor. The loss factor percentage is the capacity portion that has to be taken off the timecontinuous capacity when calculating the bucket capacity. The following graphic depicts this
setup.

SNP

Graphic 68 Buffer Capacity

The buffer in the above graphic is also referred to as the Loss Factor. For more information
see the section regarding mixed resources.
Rate Definitions
The Rate Definition, which must not be mixed up with the quantity rates definition of the
bucket resource, describes the product independent output of a line resource measured in, for
example, a volume unit of measure. This capacity definition is in addition to the working
times defined for the line resource. Consequently, a line resource can be linked to both the
shift sequence (which determines the working time), and the rate definition (which determines
the output).
Material Dependent Rates
The Material Dependent Rates describes the output factor for a specific product. Material
dependent rates are defined without a relation to a specific line resource. The factor is used to
multiply the individual line resources output. The result of this multiplication is the material
dependent rate. The following example explains this.
Line Resource
Material Dependent Rate
Resulting Material Dependent Rate Product 1
Resulting Material Dependent Rate Product 2

Any material dependent rate can have several products allocated to it each having an own
factor. A resource is then linked to a material dependent rate and via the material dependent
rates the line resources material dependent
output is defined. The following graphic outlines the above example.
Understanding

Capacity
Variants

Product Independent Rate

Base Rate

Line Resource A
Model 1
Model 2

Graphic 69 Line Resource Definitions

3.5.1.6

Capacity Determination

The search for the valid capacity is dependent on the application area and can be a rather complex
task. Whereby the SNP or PP/DS Heuristics only uses the valid capacity, the SNP optimizer
checks for the capacity variants 1 and 2. The resource master maintenance transactions offers
various types of information, which help setting up a resource properly and understanding what
the valid capacity is. Note that in order to use a capacity variant and not the standard capacity, the
capacity variant must be defined for the resource and set as the active variant.

Capacity Button
One or two capacity check buttons can be found on each of the standard capacity tabs of the
resource master. When activated, the system finds the valid capacity according to the graphic
below and displays the result in table form. The table can be saved locally for further
processing using other PC programs. For mixed resources two pushbuttons are present, one
for the bucket capacity (see below), and the other for the time-continuous capacity.

Bucket Capacity Check Button

For bucket resources the Bucket Capacity button provides the same functionality as
described above.

Origin Capacity Button

Understanding

This function provides information about all defined capacity variants including the
standard capacity, as well which of the capacity definitions is the active one. This
information is also visible indirectly when using the capacity profile function. For mixed
resources this function provides information about both types of capacity.
Capacity Profile

The capacity profile displays all defined capacities for the selected resource (standard
capacity
and/or capacity variants). It also highlights the currently valid capacity definition. This
function is possible for all but vehicle resources.
Note that multi activity resources can have a secondary capacity that is defined in a unit of
measure other than time (see further down).
To facilitate easier capacity maintenance, it is possible to link a resource to another resource (the
reference resource) from which it will take over the capacity definitions under certain
conditions. The following flow chart graphically illustrates the search procedure. As can be seen
in the graphic, reference resources can also be cascaded. Whether this is advisable, is another
question.
Flow Charts exceed the available printing space and are only part of the on-line APO
Knowledge Bank.
Graphic 70 Capacity Selection
Depending on the type of resources, different capacity types with individual dimensions can be
defined. The capacity per working day is always the same for all days if the capacity data is
taken from the standard capacity screen. When using capacity variants, the capacity can be
different per day.

Bucket Resources
Bucket resources have a time or quantity-based dimension. When using a quantity-based
dimension, it is possible to leave it without time relation (quantity), or to relate the quantity
to the time (rate). Quantity definitions are used, for example, to describe the capacity of a
truck or a warehouse. A time capacity is always expressed in a per period approach. The
shipment resource is a bucket resource. The bucket capacity is one of the following:
Bucket Capacity per Period =
Bucket Capacity =

Single Activity Resources (Time-Continuous)

Single activity resources do not allow stipulating a dimension. The capacity is always
expressed in time per working day. The productive time is calculated as follows:
Productive Time =

The available capacity equals the productive time.

Understanding

Single Activity Mixed Resources

Single activity mixed resources provide the capacity figures for bucket and time-continuous
calculations. Usually the capacity for a production bucket resource can be defined in a time
unit or in other dimensions such as volume or mass for example. Single activity mixed
resources take the productive time (see above), which could be derived from the standard
capacity or active variant. This productive time is then reduced according to the loss factor
to give the available capacity for the bucket capacity of the single activity mixed resource.
In this case the resulting bucket capacity is in a time unit. The bucket capacity is calculated
as follows:

Bucket Capacity =

Productive Time * (1 Loss Factor / 100)

Alternatively, it is also possible to define a quantity or rate based bucket capacity for a
single activity mixed resource. The bucket capacity is then calculated the same way, as is
the case for bucket resources.

Multi Activity Resources (Time-Continuous)

Multi activity resources are used in cases where the same type of activity is available in
multiple units (e.g. three machines of the same type are one resource with the capacity
counter set to 3). Another possibility is that the same machine can be used by multiple
operations at the same time. In this case a total capacity in quantity is defined in the capacity
counter and a unit of measure with a dimension other than time is specified. For case one,
the calculation of available capacity is similar to this of single activity resources. The
formula for the productive time is as follows:
Productive Time =
Total available capacity of the resource is the productive time multiplied by the capacity
counter.
A further capacity restriction might be imposed on a Multi Activity Resource. This capacity,
referred to as the secondary capacity, is expressed in any unit of measure not equal to time.
The available capacity equals the productive time but is limited by another capacity
constraint.

Multi Activity Mixed Resources

Multi activity mixed resources provide the capacity figures for bucket and time-continuous
calculations. In the case of the multi activity mixed resources it is not possible to define an
alternate capacity (option 2, see above). Usually the capacity for a production bucket
resource can be defined in a time unit or in other dimensions such as volume or mass for
example. Multi activity mixed resources take the productive time (see above), which could
be derived from the standard capacity or active variant. This productive time is then reduced
according to the loss factor to give the available capacity for the bucket capacity of the multi
activity mixed resource. In this case the resulting bucket capacity is in a time unit. The
bucket capacity is calculated as follows:
Understanding

Bucket Capacity =

Productive Time * (1 Loss Factor / 100)

Alternatively, it is also possible to define a quantity or rate based bucket capacity for a multi
activity mixed resource. The bucket capacity is then calculated the same way, as it is the
case for bucket resources.

Production Line Resources

Production line resources describe machines primarily used in a repetitive manufacturing
environment. The term repetitive manufacturing, as used by SAP, does not apply to cases
of mass manufacturing of products on dedicated lines. This is described as continuous
manufacturing, which does not require any specific resource types, as it is modeled using
normal bucket and time-continuous resources. Production line resources might be part of a
production line. Production line definitions can influence the production line capacity
definitions. They are similar to multi activity resources, as they also have a time based
capacity and another non time-based capacity. These secondary capacities are called rates
and are expressed independent of a product (e.g. 10 cars per hour) or product dependent (12
cars of model A per hour). The formula for the productive time is as follows:

Productive Time =
The available capacity equals the productive time but is also limited by the rate definition.

Line Mixed Resources

Line mixed resources provide the capacity figures for bucket and time-continuous
calculations. Usually the capacity for a production bucket resource can be defined in a time
unit or in other dimensions such as volume or mass for example. Line mixed resources take
the productive time (see above), which could be derived from the standard capacity or an
active variant. This productive time is then reduced according to the loss factor to give the
available capacity for the bucket capacity of the line mixed resource. As a consequence of
this approach, it is only possible to define a time related bucket capacity for a line mixed
resource and no rate, as it is possible in a bucket resource. If the SNP planning must be
carried out using a unit other than time, it is required to define the bucket resource and the
time-continuous resource as separate entities.
Bucket Capacity =

Productive Time * (1 Loss Factor / 100)

Vehicle Resources
Vehicle resources describe vehicles (trucks) or any other discrete transportation unit. They
are also similar to multi activity resources, as they have a time based capacity and another
non time-based capacity. These secondary capacities are expressed in any unit of measure
not equal to time. Examples would be the maximum truck volume of 10 m 3 and a maximum
load of 10.000 kg. The formula for the productive time is as follows:
Productive Time =

Understanding

The available capacity equals the productive time but is limited by one or multiple other
capacity constraints.
The following table provides examples of possible capacity definitions for various types of
resources and capacities.
Resource Type
Capacity Type
Bucket
Bucket

Single Activity
Time Continuous

Single Activity Mixed

Time Continuous

Bucket
Multi Activity
Time Continuous

Time Continuous
Understanding

Resource Type
Capacity Type

Multi Activity Mixed

Time Continuous

Bucket

Production Line
Time Continuous

Line Mixed
Time Continuous

Understanding

211

Resource Type
Capacity Type
Bucket
Vehicle
Time Continuous

Table 54 Capacity Examples

(*1)
(*2)

(*3)
(*4)

3.5.2

The quantity/rate definition can be time dependent (e.g. 100kg/hour) or without relation
to time (e.g. 10 m3). The rate can also be an amount of time per time (8 hours/day).
The capacity of 100 kg must be seen as a further restriction of the multi activity
resource. It operates for 7.2 hours per day and copes with a maximum of 100 kg at any
time. The multi activity resource can handle in this case multiple operations as long as
their total load does not exceed 100 kg.
PIR depicts Product Independent Rate.
PDR depicts Product Dependent Rate. The product dependent rate is not allocated to a
capacity variant but to the resource directly.

Production Process Model

The Production Process Model (PPM) is the most complex master data object in APO. It
represents a combination of Bill of Material (BOM) and Routing. This method is very similar to
the Recipe known from the R/3 production planning for process industry (PP -PI) module. In
situations where the PP-PI module is used, the PPM is generated based on the Recipe and not the
BOM and Routing. The PPM provides all the information required for manufacturing a product.
This includes required components and resources with the respective usage as well as the output
product(s). It is therefore the key source of information for SNP and PP/DS when planning
component requirements and/or resource consumption. Within DP it is used to determine
component requirements when forecasting with bills of material is carried out. The PPM has

validity parameters for time and possible lot size. The application areas DP, SNP, CTM, and
PP/DS all use the PPM. The PPM used by the SNP Heuristics and the SNP Optimizer is of type S
(for SNP only)

Understanding

212

and contains less (and sometimes different) information than the PPM used by PP/DS, which is of
type P (for PP/DS only). CTM can use the PPM of type S or of type P. The PPM of type S can
only work in conjunction with bucket or mixed resources and any PPM of type P works with time
continuous or mixed resources. Thus mixed resources can be used for both PPM types, S and P.
Another PPM of type T is used specifically for the area of trim optimizing within PP/DS. Demand
Planning can use the PPM of type D or S to determine a forecast of dependent demands.
The following text refers to those PPM types used by SNP and PP/DS.
Unlike in a typical BOM, we do not find a rigid relation of components used in the process, and
finished products coming out of the process. Any product can be an Input if marked so, and any
could be an Output. If two output products are defined, it is possible to create a PPM for either of
the two or for both. In a situation where only one output product is used to create a PPM, it will be
the only one that can be picked up by, for example, the SNP planning run. The other output
product is then a joint product (also called by-product or co-product) that cannot be planned on its
own. There is no distinction between a by-product and a co-product as we can find it in R/3. The
real difference in R/3 between the two definitions is a costing issue. APO does not deal with
product costing and therefore does not need to distinguish.
On the top level and actually above the PPM, we find the Plan. The plan, which is not location
specific, is the equivalent of the R/3 Production Version. It contains one or several production
process models for all those products that are defined as output products somewhere in the plan.
Exactly one location specific PPM can exist in a plan per output product. The PPM can be named
and given a description as required and does therefore not necessarily carry the name of an output
product or the plan. The same plan can be used for one or multiple products depending on the
number of output products defined in the plan. The following graphic shows an example where the
two products A and B are output products of the same plan (they are joint products). The
various production process models within the plan are defined for different output products.

Understanding

213

Plan N um ber A B1
Structure of Plan
O p eratio n s

used in

PPM A 1
Product A
Location 1
Lot Size R ange 1
V alidity R ange 1

Graphic 71 Plan and PPM

It is required to create different plans if different production process models are required for the
same output product but for different locations, lot size ranges, or validity periods. Time
dependent use of input products (components) is modeled within the plan and does therefore not
require the creation of different plans. The plan defines all specifics of a production process such
as operations, activities, resources, and products/components. The PPM within a plan is a pointer
that utilizes the structure of a plan and links it to an output product of exactly one location, lot size
range, and validity period. As the PPM is merely a pointer and not a structure like the plan it
cannot be copied. A plan, on the other hand, can be copied as required. Note as well that the
location stipulated in the PPM defines for which locations it can be used if there is a requirement.
The location used in conjunction with the resource on activity level defines the physical location
of the resource. In our example above, all planned orders for requirements of product A in
location 1 would use the PPM A1.
The PPM is a highly structured set of master data. The difficulty is to set up the data consistently,
as the data is not only related in a top down approach within a branch of the PPM but also cross
branches. One must also keep in mind that the plan header information is information not for a
specific PPM but for any PPM within the plan. Each plan contains potentially more than one PPM
definition. The PPM in the plan can be made usable for any output product that is defined on
activity level.
The structure of the PPM is as depicted in the graphic below. The abbreviation TD stands for
Time Dependent, AL for Alternate Language.
Understanding

Plan

AL Description

Operation 1
AL Description

Operation 2

Graphic 72 PPM Structure

(

Characteristics can only be maintained for a PP/DS PPM.

In order to understand the plan and the PPM it is helpful to be familiar with the following terms
and definitions.

Operation and Activity

A plan has one or multiple operations. An operation groups activities that logically belong
together. Each operation contains one or several activities. All activities within a specific
operation must use the same primary resource. An activity has an activity type, which is
Setup, Produce, Tear Down, or Wait (Queue Time). Allocated to these activities are the input
and/or

Understanding

215

output products. Input products are components or semi finished products; output products are
semi finished products or finished products. Any plan must have at least one activity with a
defined output product. SNP planning is intended to be Rough Cut Capacity Planning. For
this reason it would not be adequate to plan within SNP for setup, tear down, and wait
activities separately. For infinite scheduling purposes, it is most of the time sufficient to plan
without these activities, as long they do not constitute an abnormal high portion of the entire
operation. Instead, it makes more sense to lower the available capacity of the bucket resource
by a certain percentage. This percentage is then the buffer that is not used by SNP, but can
be used by PP/DS to plan for setup times when finite scheduling is carried out.
The resources, their consumption, as well as the duration of the activities are defined on
activity level. One primary resource must be specified, and one or several secondary
resources can be specified. The duration of an activity can be specified as a linear function of
the output quantity or in a step function (PP/DS PPM only). The step function specifies the
resource consumption per output quantity not in a linear way but in intervals (steps). Per step
the duration is defined and the resource consumption during this step. Step functions are
useful in situations where the resource output is in multiples of the products unit of measure.
An example would be an extruder where per injection process 10 pieces are manufactured or
a chemical process where the output quantity is a multiple of 100 kg. All steps have the same
duration and consumption values. A Zero duration for the step depicts a linear function.
The identification number of operations and activities does not preempt a certain sequence. It
is necessary to explicitly define the exact sequence of activities. This allows a totally flexible
definition of any type of activity relation from simple line relations to highly complex
networks. Any activity of any operation can be linked to any one or multiple activities
irrespective of operations. This is done by means of building up relationships. The system
displays predecessors and successors per activity, and it is sufficient to define the relation only
once (either go to the predecessor activity and define the successor activity or vice versa).
Relations between activities can be of type Start-Start, Finish-Start, Finish-Finish, or StartFinish (see below). It is possible to define for each such relation minimum and maximum
deviations.

PPM Network
As we have seen in the graphic above, a PPM that consists of one or several operations, each
in turn has one to several activities. The number (or name) of the operation as well as the
activity has no impact on this network at all. One could define for example that activity 10
follows activity 20 and so on. Each activity has to be brought in relation to other activities.

PPM Network SNP specific

SNP PPM network definitions are very basic. All relations are of the type Finish-Start.

PPM Network PP/DS specific

The PP/DS PPM allows the definition of very flexible relations supporting any possibility
from simple sequences to highly complex networks. Each activity has at least one successor
or predecessor. Supported relations between activities include:

SS
SF
FS
Understanding

FF

Start Start
Start Finish
Finish Start

Finish Finish

Each of the relations can have a minimum and/or a maximum time constraint. Time
constraints define the minimum or maximum time that is allowed to pass between the
activities. These definitions are shown in the graphic below.

Start - Start

Activity 1

Min
Activity 2

Max

Start - Finish
Activity 1

Min
Activity 2

Max

Graphic 73 PPM Activity Relations

In a PPM the activities and not the operations are linked to each other. It is possible to link an
activity to more than one other activity to build up complex activity networks. Since each
activity belongs to exactly one operation the activity network determines the operation
network as well. An example for
such a network is shown in the graphic below.

Understanding

217

O p eratio n 10
S

FS

FS

FFFS

O p eratio n 20
S

FS

FS

FSSS

O p eratio n 30
S

FS

FS

Graphic 74 Activity Network

Modes PP/DS specific

To add some more flexibility, but also more complexity, the PP/DS PPM allows defining
various modes per activity. A mode represents a possible set of one primary and additionally
one or multiple secondary resource that are used in order to process an activity. Each mode
represents an alternative that can be selected in order to carry out the activity. Note that
secondary resources are used in APO to fulfill a requirement together with the primary
resource. They complement each other. In opposition to this, resources defined in the various
modes define various possible alternatives to fulfill the same capacity requirement. Scheduling
is carried out according to exactly one resource (primary or secondary) as defined in the
activity. The relation of various resource definitions is depicted in the graphic below.

PPM

Graphic 75 PPM Modes

Understanding

218

Each activity has at least one mode. Duration and mode priority are specified per mode. Each
mode has a user -defined priority that can be used in PP/DS to select the modes. Different
modes should be used in situations where a product can be manufactured in more than one
way but where the differences between the different ways are not too great. When describing
rather different ways of manufacturing the same product, it is advisable to rather create more
than one plan and PPM instead.

Time Consumption
The time consumption per resource and mode in a plan does not have to be specified in any
specific relation to an output quantity. The time defined must be seen in relation to the output
product and quantity specified in the plan. If the time consumption is defined as, for example,
1 hour and the output quantity is 1.800 pieces, then the time consumption per piece is 2
seconds. In cases where no output product is defined for an operation, the time consumption
specified in this particular operation has to be seen in conjunction with the output quantity of
the following operation. This can be repeated through to the last operation that must have an
output product. At the end, the plan describes the process of producing a product, and
therefore at least one product in the last operation must be specified. Care needs to be taken
when scrap factors are applied in operations without output products. The calculation
principles remain the same; it is just more difficult to understand the calculation and specify
the time consumption data correctly.

Time Dependent Parameters

Time dependent parameters allow the modeling of process parameters that change over time.
In cases where time dependent parameters are maintained, the system will check to find a
valid time interval. If the time dependent parameters do not apply to the time of the order, the
default value, if maintained, will be used. Not the time of the order explosion but that of the
scheduled order execution is the relevant time for the time dependent parameters. Any of the
Time Dependent Parameters can be defined globally without specifying a specific planning
version or per planning version.

Resource Coupling PP/DS specific

As we have seen above, it is possible to specify various alternative resources for each activity
within an operation. During the PP/DS Heuristic based scheduling or during the PP/DS
optimization, the appropriate resource according to various parameters (see also optimization
profiles definitions) is selected. In some cases it might be required to somehow limit the
selection possibilities. Within an operation, it is quite often the case that the different
activities describe the setup, production, and tear down for the operation. In this case it must
be ensured that all the three activities take place using the same mode and thus the same
resource. The PP/DS method to achieve this is called Mode Coupling. Another scenario
where resources need to be linked is if the PPM describes various process possibilities. In this
case, depending on the preceding resource, only one or multiple specific resources can be
used. An example would be in a filling activity where the filling machine used determines a
range of packing machines. Other than the specified packaging, machines cannot be used, as
they cannot be linked to the filling machine. Within PP/DS the Resource Network is used
to enable this functionality.
Mode Coupling is realized within an operation of the PPM through the linkage of resources
by mode number or primary resource name. The mode connection (mode linkage type) is set
in the activity relationships. Mode coupling links resources within a specific operation.

Understanding

219

Resource Networks are also defined in the operation relationships, but can only be defined on
the successor relation tab. They link modes across several operations. The resource network
flag must always be set manually, if required.

Mode Coupling PP/DS specific

Mode coupling is an option that ensures that, throughout all activities of a specific operation
within the PPM, only modes with the same number or primary resource are used. The
indicator for the mode linkage is called Mode Linkage Type. The following options are
available.
Type 2:Coupling by Primary Resource Name
With this type of coupling the system ensures that the same primary resource is used
throughout an operation even if it was allocated to different modes. The mode
number in this case is irrelevant. Only modes with the same primary resource name
are used (e.g. primary resource RES1 is used for all activities of all operations).
Mode coupling of type 2 is switched on automatically if various activities are
defined within an operation (e.g. setup and produce).
Type 3:Coupling by Mode Number
Only modes with the same mode number are used (e.g. mode 10 is used for all
operations). This type of mode coupling is used mainly to ensure that a certain
combination of resources is selected during scheduling. With this mode coupling
type, it is required that all activities have the same amount of mode definitions.
Type 0:No Mode Coupling
With mode coupling switched off, modes with different primary resources or
numbers can be used simultaneously (e.g. mode AB for activity 10 and mode CD for
activity 20).
Mode coupling must be switched on if the activities of an operation must be all performed on
exactly the same resource or on resources with the same mode number. An example where the
system enforces mode coupling of type 2 is shown below where the activities within the
operation describe the setup, production, and tear down activity, all of which must obviously
be carried out on exactly the same resource. The mode number in this example is totally
irrelevant, as the coupling is based on the primary resource name only.

Modes can be coupled according to the resource name as depicted in the graphic below.
Alternatively, the mode number can be used as the determining factor for mode coupling. The
mode number is also referred to as the mode name, as the mode field is alphanumeric. Mode
coupling by resource name is set automatically when using e.g. setup and produce type
activities within an operation.
Understanding

Operation/Activity 10
Mode 10
Resource A

Mode 30
Resource B

Mode 20
Resource C

Graphic 76 Mode Coupling

Resource Network PP/DS specific

A resource network is the definition of one or multiple possible sequences of used modes (and
not resources) in an order. A resource network is defined across operations in the relationship
successor tab. The resource network definition is part of the PPM. Using resource networks,
the mode used in the last activity of an operation determines the mode used for the first
activity of the succeeding operation.
Option 1:One-to-One Relation
For each preceding defined resource exactly one succeeding resource exists. When
changing from resource A to B in operation 10, the system will automatically change
from resource D to E in operation 20.
Option 2:One-to-Many Relation
For each preceding defined resource one or multiple succeeding resources exist.
When changing from resource A to B in operation 10, the system can select from a
range of resources for operation 20, for example resource E or F in operation 20.
Option 3:Many-to-One Relation
For multiple preceding resources, exactly one succeeding resource exists. When
changing from resource A to B in operation 10, the system does not need to change
the resource of operation 20 at all. It remains D.

Option 2 and 3 can be seen the same way; it just depends on whether the rescheduling is
carried out for the predecessor and successor. The following graphic depicts the three options.
Understanding

Action

O ption 1

Action

O ption 2

Action

O ption 3

Graphic 77 Resource Network

3.5.3

Capacity Consumption Calculation

When scheduling an activity in APO two different parameters, the activity duration and the
resource consumption, need to be determined. This process depends on the type of the used
resource. The Resource Consumption is also referred to as the Capacity Consumption. Before we
have a more detailed look at this process, it is required to define these two expressions precisely.
The Activity Duration on a resource describes the amount of time required to process the
activity to be scheduled.
The Resource Consumption of a resource describes the consumption of a capacity that is
possibly defined for a resource.
Understanding

Based on those two definitions, all activities, irrespective on which resource it will be carried out,
have an activity duration. For some activities it might be possible or required to define
additionally resource consumption. This depends on the type of planning (SNP bucket planning
or PP/DS time continuous planning) and on the resource type (single or multi activity resource).
The activity duration and resource consumption can graphically be displayed in an XY diagram
as shown below.

Activity Duration

Day
Graphic 78 Resource Diagram
The X coordinate depicts the time required for the activity or, in other words, the activity duration.
The Y coordinate depicts the consumption of a capacity at this resource. If we have a look at the
PPM we see that we need to define the activity duration and resource consumption depending on
the PPM type (SNP or PP/DS) and on the resource type (bucket or time-continuous). These possible
definitions for the various resources are listed below. The word specify depicts that an entry can
be made in the respective PPM.

Resource
Type
Single
(*1)
Understanding

Resource
Type
Single Mixed
(*1)
Multi
(Option 1)
Multi
(Option 2)

Multi Mixed

Table 55 Activity Duration and Resource Consumption in PP/DS PPM

(*1)
(*2)
(*3)

Single and single mixed activity resources always have a capacity of 1 although this is
not shown in the PPM field Fixed Capacity.
The specified capacity is without dimension and representing the number of machines
of the same type that are grouped in this resource (this is the same as the multi capacity
work center in R/3).
The specified capacity is with a dimension other than time.

(*4)

The variable capacity consumption can only be defined if the activity has a fixed
duration only.

Resource
Type
Bucket
(*1)
Single Mixed
(*2)
Multi Mixed
(*2)
Table 56 Activity Duration and Resource Consumption in SNP PPM
(*1)
The bucket resource capacity can be defined in time, as a rate, or quantities without
Understanding

periodicity.
A single and multi mixed resource capacity can be calculated based on the resources
start, end, and break times and therefore always given in a time unit. With this
option, the bucket capacity of a mixed resource is not captured explicitly, but rather
derived from the start, end, and break times. Rates and quantities without periodicity
can be captured directly in the mixed resource the same way done for the bucket
resource.

(*2)

Single Activity Resource

Capacity

Graphically displayed, a single activity resource has one capacity with a certain amount of hours
available. This is in the graphic depicted as 8 hours per working day, which is based on the start,
end, and break times (e.g. 08.00 to 17.00 with a 1-hour break.

Day
Graphic 79 Single Activity Resource

Multi Activity Resource

The multi activity resource allows to either; specify the number of machines (capacities) that are
reflected in this resource (option 1), or to specify a second capacity constraint (option 2).
Understanding

Capacity

Graphically displayed, a multi activity resource option 1 has two or more capacities with a
certain amount of hours available. The graphic depicts as an example a multi activity resource with
three capacities and 8 hours per working day, which is based on the start, end, and break times (e.g.
08.00 to 17.00 with a 1 hour break). A multi activity resource option 1 with one activity only is
the same as a single activity resource.

Day

12

1
Graphic 80 Multi Activity Resource
The second capacity constraint can also be defined with a unit of measure, e.g. tons. The same
graphic can be used to show this multi activity resource option 2. The difference is that the multi
activity resource shown has one machine with a capacity constraint of 3 tons (in this example).
Bucket Resource

Capacity

A bucket resource has a capacity that is defined in the unit of time, as a rate, or as a quantity without
periodicity. When specifying the bucket capacity in a time unit, a periodicity should be specified
(e.g. 8 hours per day). The bucket capacity (time or rate) is deemed to be available the whole day
whereby it is immaterial at which time it is available or required. The graphic below depicts a
bucket resource with a capacity of 3 per daily bucket. The 3 could be for example 3 hours per day
(time) or 3 tons per day (rate). A bucket resource without periodicity cannot be displayed in this
graphical form.

Graphic 81 Bucket Resource

Examples
The following examples help to understand the various methods of resource capacity consumption
and how they can be applied.

Single Activity Resource

1. Variable Duration
One lathe that can handle exactly one production order at any given time. The activity
duration is variable as it depends on the number of pieces that need to be turned.
2. Fixed Duration
As option 1 above, but the duration is fixed during the setup activity.

Multi Activity Resource

Option 1 Multiple activities counter with no dimension
1. Variable Duration Fixed Resource Consumption
Various machines, of exactly the same type are defined as one resource. Each
production order uses a predefined number of resources. The activity duration is
variable.
2. Variable Duration Variable Resource Consumption
This option, which is not possible, would be a dynamic operation split, where an
Understanding

operation is split according to resource availability over various possible resource

activities (machines). Depending on the number of machines used, the duration varies.
3. Fixed Duration Fixed Resource Consumption
As option 1 above, but the duration is fixed during the setup.
4. Fixed Duration Variable Resource Consumption
Mixing station consisting of 10 mixers (containers) that can be used for either the same
or up to 10 different products at any time. The mixing process always requires the
same time, e.g. 4 hours, and depending on the requirement quantity more or less
mixers are used simultaneously.
Option 2 Secondary capacity constraint
1. Variable Duration Fixed Resource Consumption
No feasible example exists for the combination of fixed resource consumption and
variable duration.
2. Variable Duration Variable Resource Consumption
No feasible example exists for the combination of variable resource consumption and
variable duration.
3. Fixed Duration Fixed Resource Consumption
No feasible example exists for the combination of fixed resource consumption and
fixed duration.
4. Fixed Duration Variable Resource Consumption
Freezing facility that can handle a volume of 500 kg at any given time. Various
production orders can share this capacity up to its limit during the defined working

hours (variable resource consumption). The freezing process always requires the same
amount of time (fixed activity duration).
Bucket Resource
1. Variable Resource Consumption Time
Drilling station with multiple drilling machines having a total capacity of 40 hours per
day.
2. Variable Resource Consumption Rate
Bottling line for a specific bottle type that can fill 6.000 bottles per day.
3. Variable Resource Consumption Without periodicity
Warehouse with a total capacity of 10.000 m3 at any given moment.
4. Fixed Resource Consumption
It is possible to define fixed resource consumption in connection with any of the
examples above. However, as SNP performs a rough cut capacity planning in daily
buckets it is questionable whether this should be done. The effort put into this task
might not be justifiable.

Shipment Resource
1. Variable Resource Consumption Without periodicity
Resource allocated to a transportation method of a transportation lane to depict the
load of a specific transportation lane and method load.
2. Variable Resource Consumption Without periodicity
Resource allocated to a transportation method to depict the overall load of a specific
transportation method (fleet requirement resource).
Understanding

3.6

Forecast Data Flow

The product forecasts that are released from Demand Planning are used by Supply Network
Planning to determine the medium to short term supply requirements. The quantities of this
unconstrained forecast are also referred to as independent requirements since these requirements
do not depend on any other orders in the system. Dependent requirements are for example the
component requirements of a production order, as they depend on the order for the finished
product. In most cases the DP forecast is carried out per week or month and while the forecast is
released to SNP, it is broken down into smaller daily buckets, as SNP requires planning in daily
time buckets. The following graphic depicts these relations.

Demand Planning
Unconstrained
Forecast
(e.g. Weekly)
Compare

Constrained
Forecast

Graphic 82 Forecast Data Flow

It is important to understand that the SNP forecast (independent requirements) is based on a
snapshot of the DP forecast at the time of the release to SNP. The forecast in DP can be maintained
at any time and is totally independent of the forecast used in SNP. The system also allows the
carrying out of various forecast releases from DP to SNP without duplicating any independent
requirements in SNP. This is even supported in situations where forecast consumption (see separate
section) is enabled for a product.
Independent requirements, like other demand elements are the same for SNP and PP/DS. There are
no specific independent requirements for SNP on the one side and PP/DS on the other. For this

Understanding

229

reason there is no need to transfer independent or dependent requirements from one module to
the other. Both modules also treat forecasts the same way and in accordance with their forecast
consumption setting.
Note that there is a difference in the way the forecast is displayed. Within SNP the forecast is not
shown individually for past periods. The Initial column of the SNP Interactive Planning
transaction displays the summarized consumed forecast (if forecast consumption is switched on)
or the original forecast (if forecast consumption is switched off). In the PP/DS Product View
transaction individual forecast values are displayed forever.
Past forecast values are part of the demand when using PP/DS (i.e. past forecast is shown and used
as demand). This is independent of the forecast horizon setting, which is only used by SNP for
products without forecast consumption. In order to overcome this undesired effect, forecasts in the
past need to be deleted. SNP does not consider the past forecast to be part of the demand.

3.6.1

Forecast Consumption

Usually within the short-term horizon more and more sales orders coming from R/3 appear in
APO and constitute a set of demands. The previously released forecast was a projection of the
anticipated sales orders and thus these sales orders replace the forecast. It is therefore required
to determine what the relation between those two demand elements should be. Forecast
consumption is not a mandatory function and needs to be seen in conjunction with the products
requirements strategy. APO offers two options that allow planning, taking forecast and sales orders
into account at the same time, without duplicating demand artificially.

Planning without Forecast Consumption

With this strategy the total demand of sales orders and forecasts (independent requirements) is
calculated differently, depending on whether the period for which it is calculated is within or
outside the forecast horizon. The forecast horizon is defined per location product on the
product master SNP2 tab.
Total Demand within Forecast Horizon
Within the forecast horizon the total independent requirements equal the total of all those
orders that are linked to the SNP key figure Sales. This figure can be greater or smaller
than the forecast (which is not used within the forecast horizon). The allocation of orders
is carried out via the orders categories, which are linked to ATP category groups. The
allocation of order categories to ATP category groups as well as the allocation of ATP
category groups to the key figure is customizable.
Total Demand outside Forecast Horizon
Outside the forecast horizon the total of the independent requirements equals the greater
of the two key figures, sales orders or forecast requirements. The term forecast
requirements refers to the forecast as it was released from DP. This forecast remains the
same as no forecast consumption takes place.
The forecast horizon therefore splits the future into two segments, and the figure defined in
the field marks the end of the first time segment and the start of the second. Irrespective of
this division, the forecasts stored in the system remain unchanged throughout the entire
planning period. Within the forecast horizon the forecast values are just not used to calculate
the total demand.

Understanding

230

The overall demand, of which the independent requirements are only a portion, is totaled up
by means of a macro. In both time segments the dependent and distribution demand is added
to the independent requirements to derive the overall product demand at the location.
Planning with Forecast Consumption
With this strategy the independent requirements per period are derived only from the original
forecast as released by Demand Planning. This is true as long as the sales orders over a
definable number of periods do not exceed the forecast. In all cases where the total sales
order quantity in a specific period exceeds the forecasted demand the total of all sales orders
determines the total of independent requirements. This logic is similar to Planning without
Forecast Consumption outside the forecast horizon. The main difference is that this method
compares the sales orders not only against the forecast of precisely the same period but also
against a number of periods before and/or after the sales order date. Every time an order is
received its quantity reduces the forecast of the same or adjoining periods by the same
amount. The system tracks a remaining forecast, which is the original forecast minus the total
sales orders that were used to reduce the forecast value. In cases where there is no forecast
left to consume, a shortage is shown. The shortage reveals by which amount the forecast
over a certain period was short compared to the received sales orders. Another expression
for the total sales orders is the consumed forecast. All four of these demand figures, the
original forecast (displayed as Planned Quantity), the remaining forecast (displayed as
Plan Remainder), the total sales orders (displayed as Allocated), and the forecast
shortage (displayed as Shortage) are stored separately and can be viewed using for example
the PP/DS Product View transaction.
The forecast consumption is initiated by any incoming sales order. This is a straightforward
process as long as the remaining forecast is not less than the new incoming sales order. For all
situations where a shortage occurs, the system uses the consumption mode setting together
with a defined number of periods and tries to consume the forecast of the other surrounding
periods. Four different consumption modes exist.
Backward Consumption only (Option 1)
With this setting the system consumes the forecast that lies before the sales order date in
all such cases where the forecast of the period in which the sales order occurs is not
sufficient. The system also consumes remaining forecast that is defined in the past.
Should the total remaining forecast of all preceding periods be smaller than the sales
order quantity then the balance of the sales order cannot be used for forecast
consumption. In this case the remaining sales order quantity is added to shortage quantity
in the period of the sales order date. If the backward consumption period is set to Zero,
all sales orders consume the forecast of the same period the sales order is in.
Backward/Forward Consumption (Option 2)
This is a combination of option 1 and 3. The system attempts to first consume into the
past and then into the future.
Forward Consumption only (Option 3)
With this setting the system consumes the forecast that lies after the sales order date in all
such cases where the forecast of the period in which the sales order occurs is not
sufficient. Should the total remaining forecast of all successive periods be smaller than
the sales order quantity then the balance of the sales order cannot be used for forecast
consumption. In this case the remaining sales order quantity is added to shortage quantity
in the period of the sales order date. If the forward consumption period is set to Zero, all
sales orders consume the forecast of the same period the sales order is in.
No Consumption Period (Option <blank>)

Understanding

231

Although a technically possible setting, leaving the consumption period field blank does
not switch off forecast consumption at all. Once forecast consumption is switched on via
the requirements strategy it is always carried out one way or another. Leaving the
consumption period field blank results in forecast consumption being carried out without
any backward or forward consumption logic. Thus the sales order can only consume the
forecast of the same period as the sales order itself.
During backward, forward, and backward/forward forecast consumption a sales order might
consume the forecast of more than one period if required. The number of periods can be
defined separately for backward and forward consumption. Common to all forecast
consumption methods is that the usually equally spread forecast from Demand Planning is
replaced by a more realistic up and down of requirements based on the incoming sales orders.
The total demand (independent requirements) can never be lower than the original forecast. It
can be higher though if the total of sales orders exceeds the forecast over a period of time.
Adding the dependent and distribution demand to the independent requirements provides the
overall demand of the product. The independent requirements are made up of the original
forecast plus any potential shortage quantity.
Up to now the assumption was that the forecast is consumed by sales orders. This is true but the
system even allows consuming forecast based on other demand elements. This possibility, which
is also referred to as consumption by dependent demands, permits carrying out the forecast
consumption based on other demand elements like dependent demands including transportation
orders. Once the order category of such dependent demands is linked to the category group that is
defined in the requirements strategy, the system carries out the forecast consumption based on the
dependent demand elements quantity. The following text refers generically to sales orders as the
orders that consume the forecast although the forecast consumption could also, as explained, be
carried out based on other demand elements.
During the forecast consumption independent requirements (representing the forecast in SNP) are
compared with the incoming sales orders. The independent requirements were created during the
release of the unconstrained forecast from DP to SNP. As a rule, per period one independent
requirement per product and location is created.
As of release 3.1 descriptive characteristics can be used, which allow for example the
creation of one independent requirement per product, location, and customer. If this function has
been used, the forecast consumption can be carried out on the same level (product, location, and
customer). If an incoming sales order is from a customer for whom a specific independent
requirement was created, the system will use this independent requirement. Otherwise an
independent requirement without customer specification is used. All other functionality works the
same way as described.
Sales orders are processed in APO in the active version (000) but can consume the forecast of
another planning version if this is defined in the requirements strategy. Forecasts are consumed in
such a way that the forecast value on the sales order date or on the date closest to the sales order
on the time axis is consumed first. With backward consumption the closest planned demand in the
past is used first, with forward consumption the closest planned demand is used in the future. As
another option, backward/forward consumption is possible. The three options are illustrated in the
following graph. On the top is the backward consumption mode, followed by the forward and
backward/forward consumption mode.

Graphic 83 Forecast Consumption

Note that it is not a requirement to use the forecast consumption logic when using the SNP
Heuristics or Optimizer. If forecast consumption is to be used for a product, it is required to define
a requirements strategy together with the consumption mode (product master demand tab) for each
product. The Planning without Forecast Consumption methodology is used by the SNP
Heuristics and Optimizer whenever the requirements strategy is not maintained accordingly.
Specifying a requirements strategy in the product master enables forecast consumption. It does not
need an ATP check mode to be defined, as this only a fallback value. Various sales orders with
different requirements classes can be transmitted to APO, each consuming the forecast (or not)
according to the settings of the defined ATP check modes, not according to the one specified in the
product master. The ATP check mode could even be left blank not the requirements strategy. If
no requirements strategy is defined no forecast consumption takes place at all even if all data
coming from R/3 is correct.
The category setting in the requirements strategy profile determines which forecast key figure is
shown in the Product View transaction (RRP3) and also which forecast key figure is consumed

Understanding

233

during the forecast consumption. This means that one forecast key figure per product and
requirements strategy can be consumed if the product is planned with multiple forecast strategies.
The definition which order type (e.g. BM) consumes the forecast is defined in the category group
setting (e.g. K01) that is linked to the requirements strategy profile.
In case of products with forecast consumption, the SNP Interactive Planning transaction shows the
original forecast and the PP/DS Product View transaction shows the remaining forecast (i.e. not
the original forecast).

3.6.2

Forecast Key Figures

Within the Demand Planning data environment, a minimum amount of key figures and time series
are required in order to carry out the Demand Planning (Forecasting) function. This is irrespective
of the data storage decision (i.e. InfoCube or liveCache) . The key figures used in forecasting are
those for the historical data and the forecast data. Other information is stored by the system in a
type of time series. There is no necessity to define those necessary time series, as they are used
automatically by the system depending on the forecasting method chosen. A time series for the
trend values is, for example, used only when using trend models.
The key figure relations are graphically illustrated in the data flow diagram underneath.

Ca
Co

Ca
Co

Graphic 84 Forecast Key Figures

Understanding

1.

Key Figure Historical Input (Orders History)

Defined in Univariate Forecast Profile together with the planning version.
Defined in MLR Forecast Profile together with the planning version.
Can be displayed in Interactive Planning.

2.

Key Figure Historical Data

Based on the key figure Historical Input

234

The key figure Historical Input is adjusted under the following conditions: o
Phase In or Phase Out profile maintained in the product master

o Material Forecast flag set in univariate profile or used in Interactive Planning

o Univariate forecast carried out
If all these conditions are met, the system recalculates the historical data figures before
displaying them.
Displayed in Interactive Planning.
2.

Promotion
Defined in Univariate Forecast Profile.
Always stored in absolute figures.
Displayed in Interactive Planning.
Can be used to calculate the Corrected History
Does not have to be necessarily the same key figure as that used for future promotions.

3.

Corrected History
Based on the key figure Historical Data

Automatically applied with no permanent storage or (optional)

Manually assigned to a liveCache based key figure per planning area

The key figure Historical Data is adjusted under the following conditions:
o Outlier Correction flag set in univariate profile or used in Interactive Planning
o Days in Period entry field maintained in univariate profile or used in Interactive
Planning (Workday Correction active) and historical data is used and not corrected
history.
If any of these conditions are met, the system calculates an adjusted history called
Corrected History.
Displayed in Interactive Planning.
Can be edited in Interactive Planning
Optionally stored as a key figure fur further reference (see first point).
The corrected history can be used (and updated) instead of the historical data for
subsequent forecasting tasks.
4.

Key Figure Original Forecast (Baseline Forecast)

Defined in Master Forecast Profile.
Only the Key Figure is defined here, but not the planning version. The planning version
depends on the used planning version in the Univariate or MLR profile.
The key figure Original Forecast will be adjusted in the following case: o
Phase In or Phase Out profile maintained in the product master

o Material Forecast flag set in univariate profile or used in Interactive Planning

o Univariate forecast carried out

Understanding

235

If all these conditions are met, the system recalculates the forecast figures before
displaying them.
Displayed in Interactive Planning
Can be edited in Interactive Planning
5.

Corrected Forecast
Based on the key figure Forecast

Automatically applied with no permanent storage or (optional)

Manually assigned to a liveCache based key figure per planning area

The Original Forecast key figure is adjusted under the following conditions:
o Days in Period entry field maintained in univariate profile or used in Interactive
Planning (Workday Correction active) and historical data is used and not corrected
history.
o If all these conditions are met, the system calculates an adjusted history called
Corrected History.
Displayed in Interactive Planning
Can be edited in Interactive Planning
Optionally stored as a key figure fur further reference (see first point).
6.

Ex Post Forecast
Based on the univariate forecast

Automatically applied with no permanent storage or (optional)

Manually assigned to a liveCache based key figure per planning area

Displayed in Interactive Planning

Can be edited in Interactive Planning
Optionally stored as a key figure fur further reference (see first point).
7.

Ex Post Forecast MLR

Based on the multiple linear regression

Automatically applied with no permanent storage or (optional)

Manually assigned to a liveCache based key figure per planning area

Displayed in Interactive Planning

Can be edited in Interactive Planning
Optionally stored as a key figure fur further reference (see first point).

Understanding

3.7

236

Optimization in APO

APO applies various optimizers in the area of SNP, PP/DS, and TP/VS. Although they are
different in terms of the problem, for which the optimized solution has to be found, they might
share some common optimization techniques. The optimizer has to go through a multitude of
possibilities to finally find the best solution. The optimal solution is found amongst all
investigated, but not necessarily possible solutions. The pool of possible solutions is referred to as
the Search Space, as the optimizer searches in this space for the optimum solution. The faster
the search space can be reduced, the faster a solution can be found. The practicability of an
optimizer can be judged by its ability to achieve a fast and efficient search space reduction. The
problem is that the same optimizer might be the most appropriate for one problem, but not for
another. For this reason, more than one technique is used in APO to solve the various optimization
problems. It must also be understood that the use of an Optimizer does not imply that the result is
the objective optimum. Searching for the objective optimum is extremely time-consuming. The
optimizers find, with a certain probability, a solution that is the optimum or close to the optimum.
The optimizers can be grouped into the following four categories:
1. Simplex Based Algorithm
The Primal and Dual Simplex Algorithm Methods belong to the group of Continuous
Optimization that uses continuous (and not discrete) variables. Continuous variables are
variables that have no specific possible values but instead a valid range of values. Let me give
an example. The quantity that can be moved using a specific transportation lane shall be
anything from (obviously) Zero to one thousand tons. We have a continuous variable as it can
continuously change from Zero to the maximum. Optimization using continuous variables
cannot work with lot sizing values, as these are discrete values.
The simplex-based optimization method is an algebraic procedure that is used to solve linear
problems based on continuous variables. It uses the principles of Linear Programming (LP).
SAP uses the ILOG library functions named CPLEX. This includes a specific simplex method
variation, called the Interior Point Method. The Interior Point Method can be used as an
option. The optimizer detects product flow problems within the network and solves them with
special algorithms.
During the optimization the corner points of the feasible solution space are determined and
the optimum solution is searched for within this space. It thereby reduces the search space.
2. Branch and Bound Method
The Branch and Bound Method belongs to the group of Discrete Optimization that uses discrete
variables. Discrete variables have predefined possible values and cannot just be set to any value. If
we pick up the example from above, on the transportation lane we can now move goods in
multiples of one hundred tons. We now have 11 possible values for the variable (Zero, 100, 200
1,000 tons). The required variables for the optimization process are usually not defined as discrete
values, but rather as linear (or step-linear) functions. It is therefore required to transform them into
discrete values at the start of the optimization run. This process is referred to as Discretization of
data. The usage of discrete values is by far more time consuming than that of linear functions. In
order to limit this negative effect it is not required to discretize all variables. The optimization
profile allows the individual flagging of variables that must be discretized. Optimization using
discrete variables can work with lot sizing values. The Branch and Bound method is a Divide and
Conquer strategy to solve optimization problems based on discrete variables. It uses the principles
of Mixed Integer Linear Programming (MILP). Branch and Bound methods covering all possible
combinations usually

Understanding

3.

4.

237

have very long run times. It is therefore important that the optimizer eliminates all nonsuccessful branches as early as possible. This is achieved by applying specialized filtering
techniques.
During the optimization the system uses a depth-first search strategy when evaluating the
search space. Any search path that does not provide a feasible solution or one that is worse
then the previous one is eliminated.
Constraint Based Propagation
Constraint Based Propagation techniques are said to be the most advanced optimization
techniques that are currently available. It is a combination of traditional program logic and
artificial intelligence. SAP uses the ILOG Solver and library for fast constraint propagation.
During the optimization existing constraints are used to deduce new constraints, which in turn
help to reduce the search space.
Genetic Algorithm
The Genetic Algorithm is based on the ILOG Dispatcher.

Module
SNP

PP/DS

TP/VS
ND
Table 57 Optimizer Overview
For all those cases where customer specific optimization routines are required, SAP has teamed up
with ILOG again, who developed the Optimization Development Framework (ODF). ODF is used
in conjunction with the APO Optimization Extension Workbench (APX). With the help of these
tools it is possible to integrate customer specific optimization routines in a seamless way. All
required data, standard or additional, is held in APO in the standard master data objects, which can
be extended, or in special newly created master data objects. The user impact is minimal, as even
these customer specific optimization routines are started from within the normal APO applications.
The optimization run aims to find the solution with the lowest cost. This general task is influenced
by various objectives that are all expressed in cost. Optimization is a reiterative process where the
variables are changed to achieve the objective while considering the constraints. The more
variables exist, the easier it will be for the optimization routine to find a result. At the same time,

Understanding

238

the number of variables is usually constrained by technical limitations of the optimization model.
This is depicted in the graphic below.

Objectives

Constraints

Variables

Constraints

Results

Graphic 85 Optimizer Process

Optimization can only be carried out according to exactly one objective. In the case of the SNP
Optimizer for example, the objective is to minimize the overall cost or to maximize the profit. This
general objective of the optimizer consists of various sub-objectives. The numerical relation of
these sub-objectives is defined in the SNP Cost and Optimizer profiles. This is possible as they are
all based on one common denominator, which is cost.
A note on the side to those who love to check whether a program is working properly and
returning the correct result. A very basic data setup in a test environment has most probably
already a few thousand if not a million possible scenarios. To follow them up manually is
absolutely impossible. In a typical live environment, the amount of data and resulting possibilities
is enormous. What is left for the user is to trust that the programming was done correctly.

Understanding

3.7.1

239

The SNP Optimizer

The Supply Network Planning (SNP) Optimizer is a planning tool that cannot be found even in a
similar approach anywhere in R/3. Whereby R/3 in its latest releases offers lots of functionality
similar and sometime identical to APO, nothing like the SNP Optimizer can be found there. It is
most probably the SNP Optimizer as the hub of an advanced Supply Chain Management system,
which will make companies add APO to their existing R/3 installation to enable an optimized
rough-cut planning. This does not mean that there are no other good features within SNP; but none
of them is as outstanding as the SNP Optimizer and, to a certain degree, the Deployment
Optimizer, which will be discussed later. While one usually refers to the SNP Optimizer, what is
meant is actually an optimization routine that is highly parameterized to the extent that one should
actually refer to it as the SNP Set of Optimizers. Depending on the settings in the optimization
profile the SNP Optimizer runs in a Continuous Optimization or in a Discrete Optimization
mode. The continuous optimization method can be run in a primal or dual simplex algorithm
method and it is also possible to activate an inner point method. The idea behind the provision of a
whole set of optimization tools is simply that no specific method automatically provides the
optimum solution. In complex real live scenarios, an optimizer can probably get close to the
optimum. The difference between the various methods is how close and how fast. There are
unfortunately only guidelines but no clear rules when to use which mode. It is therefore required
to run various tests to see for a specific environment which method provides the best results within
a given time frame.
The Optimizer is a network-orientated production, transportation, and purchasing planning tool. It
optimizes the network activities based on user-defined costs and penalties aiming for the overall
lowest cost. Demand due date and safety stock violations are taken into account via penalties
associated with these elements. Product source determination is not static according to the master
data setup but also follows the lowest cost principle. Dynamic multi-sourcing also provides the
ability to compare the cost implications of internal versus external procurement. Based on this
comparison, products are procured internally or externally even at the same time and dependent on
the overall lowest cost.
The SNP Optimizer is a true multilevel cost and penalty supply network optimization tool. The
planning result is a feasible supply network plan incorporating all required production,
transportation, and purchase orders. The generated orders are not only feasible but also optimized
based on a multilevel cost and penalty model. Let me give an example. The cost of a finished
product that is required at a distribution center but manufactured at another manufacturing location
is based on the transportation cost between the locations, the manufacturing cost, as well as all
component costs right through to the elementary raw materials. If there is a requirement to store
the product or any of its components in a warehouse the storage cost can be added as well.
Different costs for the used resources can be defined depending on whether they are used
according to normal or extended capacity. The SNP Optimizer not only has to calculate the costs
over various levels but also has to evaluate which branch of this cost tree is the most economic
while at the same time being feasible. This cost optimization is not carried out sequentially
product-by-product for all possible procurement (and cost) paths in the optimization run, but
simultaneously in order to evaluate interdependencies of capacities and costs.
Penalties are propagated down from the finished product to the first input.
Once the cost situation has been established, it is also required to establish the cost of not
supplying. The best solution is not always to satisfy any demand known in the system but to
satisfy only such demands where the anticipated benefit is greater than the anticipated cost. Each
demand

Understanding

240

therefore needs a penalty attached to it in the case it will not be satisfied. These penalties are
defined separately for sales order demand and forecast demand. These two demands are also
referred to as independent demands and are the main demand elements in a supply network. There
is also a penalty for not satisfying the safety stock demand. All other demands are dependent
demands and there is no need to apply penalties to them. Why is that? A transportation order for
example is a demand that depends on another requirement, lets say a sales requirement. This sales
requirement has a penalty attached and if the creation of a timely transportation order is not
possible the sales order will also fail and its penalty is applied to the solution. Thus there is no
need to define a penalty for the transportation order. In fact, doing so would duplicate the penalty
situation and lead to misleading optimization results.
Costs are propagated up from the first input to the finished product.
The optimum is defined as the planning result with the overall lowest cost. This overall lowest
cost is made up of the multilevel costs derived from the various sources of supply and internal
costs as well as the added multilevel penalties from all those demands that cannot be satisfied,
either entirely or not in time. Penalties are opportunity costs and express an imaginative loss as a
result of not satisfying a demand.
The SNP Optimizer searches for the most cost efficient solution. This can be done with the aim of
either cost minimization or profit maximization. The terminology and names of most of the cost
fields lean towards the cost minimization approach. In the case of profit maximization being
switched on in the optimizer profile the penalty cost for non-delivery is used as the lost-profit
value. When optimizing according to profit maximization, the location-dependent penalties
defined in the product master are used as the product turnover when delivering, instead of the
product penalty when not delivering. The overall profit of an optimization solution is calculated
using the following formula:

Total Profit = Total Product Turnover Total Product Cost

Total Product Turnover = Planned Product Quantity * Product Turnover

Total Product Cost = Considered Costs (e.g. Production or Transportation Costs)

The SNP optimization algorithms implemented in APO allow the definition of restrictions to break
the complexity of the problem into smaller pieces and thus improving the runtime. The following
options exist:

Time Decomposition
The optimum solution is always based on a certain time frame. If the start and/or end date of
the optimizer run is changed, the result changes as well. The longer the time span, the more
data has to be considered, and the longer the run will take. Time Decomposition offers the
possibility to break down the time span into smaller time buckets. The solution for each time
bucket takes over-proportional less time than the solution for the entire time span. If, for
example, a time span of four weeks is subdivided into four one-week buckets, the time to find
the optimal solution for each of the one-week buckets is much less than a fourth of what it
would take without Time Decomposition. With this method the buckets are optimized
sequentially. The result is not an overall optimum but various sub-optimums.
Time Decomposition is an option for continuous optimization methods only.

Product Decomposition
Understanding

The Product Decomposition method groups products and then finds an optimum solution for
one group of products after the other. The higher the number of product groups, the more the
result will deviate from the overall optimum.
Product Decomposition is an option for continuous and discrete optimization methods.
Priority Decomposition

With Priority Decomposition the optimizer works sequentially through the solution finding
process by grouping problems of the same priority. Priorities are defined per demand type
and not per product. The highest priority problem is solved first, followed by the next highest
and so on. The result is an optimal solution within each priority but not an overall optimum
solution.
Priority Decomposition is an option for continuous optimization methods only.
The following graphic provides an overview of the SNP Optimizer modes and options. Note the
following aspects:

The continuous optimization offers the use of the primal and duplex algorithm as well as the
optional use of the Inner Point Method. These options do not have any impact on the required
parameters.

The discrete optimization option partial search actually uses continuous optimization
techniques.

Continuous Optimization
Simplex
Optional any Combination of:
Inner Point Method
Hard Prioritization
Product Decomposition
Time Decomposition
(not with Hard Prioritization)

Graphic 86 SNP Optimizer Modes

The SNP Optimizer is a regenerative planning algorithm. This means that at the beginning of the
planning run all orders, in this case SNP planned orders, are deleted. In a second step new SNP
planned orders are created. The SNP Optimizer plans to a precision of one bucket with the bucket
usually being a day. This has an immediate effect on large quantity requirements, as lot sizes are

Understanding

242

also limited to one bucket. In cases where the requirements quantity exceeds the quantity that can
be produced during the bucket, the SNP Optimizer creates several orders, one each per day.
Furthermore, the SNP Optimizer schedules one setup activity per bucket although the actual setup
takes place only once. The same applies to the costs of the setup, which are applied several times,
once per bucket.
As of release 3.1 the SNP optimizer can also plan lot sizes that exceed those that can be
manufactured in a single bucket. The process is called Cross Period Lot Sizing but is only
supported by the SNP Optimizer when running in discrete mode.
With release 3.1 a new possibility is to overlap the planning periods and responsibility of
SNP and PP/DS. The SNP Optimizer supports this approach by taking into account the finite load
on mixed resources caused by PP/DS planned orders. Only the balance between the overall mixed
resource capacity and the already used finitely planned capacity is used by the SNP Optimizer.
Another interesting aspect is that the SNP Optimizer plans moving products, even to locations
without demand if this is cost-efficient. That might happen in cases with temporal warehouse
closures or when reaching a specific warehouses capacity.

3.7.1.1

The Decision Space

The first logical step in any optimization routine is to find at least one feasible solution or
determine an area of feasible solutions. Which way is chosen depends on the selected optimization
method. Specifically in planning situations with a multitude of constraints it might be difficult to
find a first feasible solution.
In these cases it makes sense to permit the SNP Optimizer to find the initial solution based
on a Heuristics. This option is available as of release 3.1 only. Note that this initial solution might
not be feasible, as it is Heuristic based.
In order to find a solution or solution area, the optimizer needs to be permitted to change some
parameters. These parameters or variables form the decision space. The SNP Optimizer can work
with the following decision variables:

Time
In order to find a solution the supply date might not match the requirement date precisely.
Early supply might attract additional storage cost and late delivery a penalty.

Non-Compliance
In tight situations the best or only feasible solution might be to not comply with a demand.
This attracts penalties in the form of non-delivery or safety stock penalties to name two.

Sourcing
The product source can be changed between production, transportation, and external
procurement. Various costs are attached to the different procurement methods.

Procurement Lot Sizes

The procurement lot sizes can be changed to achieve the cost optimum. Possibilities are for
example synchronous multi-sourcing (order split) or procurement in repeated smaller batches.

Resource Capacity Increase

Resource capacities can be used within the limits of the standard capacity variant. If this is
insufficient to accommodate higher demand the increased capacity variant can be used at a
higher cost. Note that no penalty can be defined for idle capacity.

Understanding

243

Note that any demand that is not part of the key figures used by the SNP Optimizer is not
considered during the optimization run. A demand is represented by an order with a specific order
category that is linked to a category group. Category groups are linked to key figures for SNP
planning and used by the SNP Optimizer. In the standard delivered system the order type for
reservations is, for example, not included in any of the category groups that are used by the SNP
Optimizer and thus not considered by the optimization run.

3.7.1.2

The Cost and Penalty Model

The SNP Optimizer uses a magnitude of cost and penalty settings to derive the optimal planning
result. Through the definition and fine-tuning of these settings the user determines the result of the
planning run. It is thus required for anybody responsible for setting up these costs to thoroughly
understand the implications of changing one or the other value.

Procurement
Transportation
Storage
Capacity

Costs

Non-Delivery
Late Delivery
Safety Stock

Penalties

Graphic 87 SNP Cost Model

Having so many costs and penalties is a great feature of the SNP Optimizer but can also be a huge
burden when considering how much thought and work goes into the maintenance of the data. This

Understanding

244

is not a system weakness at all. It is just a logical thing that if a sophisticated complex tool is used
it is also required to define all the input parameters, the costs and penalties, on the same level of
detail and sophistication. The cost parameters are the driving force behind the result of the
Optimizer. When implementing APO, it is necessary to carefully plan the cost parameters and run
a lot of test runs with different sets of parameters to understand their impact on the result. In this
section we shall have a look at the cost and penalty definitions used by the SNP Optimizer.

The Costs
Unlike the penalties that are applied in a potential non-supply situation, the costs are used to
determine the overall cost of a certain supply solution. Often various supply solutions can be
found. This might be for example internal and external procurement, various processes for
internal procurement, and/or various vendors for external procurement. The costs explained in
this section explain how the SNP Optimizer determines the cost per sourcing option.
Procurement Cost
The procurement can be carried out internally or externally, thus two and in actual fact
three different methods are used.
Internal Procurement
The manufacturing option for a product (internal procurement) uses the variable single
level cost defined in the plan header. The plan header cost is valid for any PPM created
within the plan. The cost is referred to as a single level cost as it only contains the cost of
the single level of transforming the input products to the output products. No component
(input product) costs are included, as the SNP Optimizer determines the cost of these
components in a separate step. Via a cost function, fixed and variable single level costs
can be modeled. The PPM also contains multi-level costs, which are used for the SNP
and PP/DS Heuristics, but not for the SNP Optimizer. More than one PPM might exist,
each pointing to a different production process with potentially different resources, input
products and possibly with different cost settings.
The single level internal procurement cost and the cost function are part of the plan
header data.
External Procurement
Products can be procured from vendors that are part of the supply chain model and those
that are not (anonymous vendor). In the latter case, the SNP Optimizer only determines a
requirement to purchase a product but does not stipulate the location from which it is
sourced. It is possible to define variable cost or, via the cost function, also a mix of fixed
and variable costs. The procurement cost represents the purchase price per base unit of
measure of the product. It is required to determine this procurement cost for all such
products that can be procured externally.
For all products that are procured from a vendor that is part of the supply chain model the
transportation and transportation method cost are used to determine the cost of the
procurement option. The transportation and transportation method cost must then reflect
either the total procurement cost or only the real transportation cost. In the latter case it is
required to define a procurement cost at the vendor location, as otherwise the total supply
chain cost is too low!
External procurement also refers to a situation where products are transferred from one
own location to another (e.g. from plant to distribution center). In this context the
transportation cost together with the cost of the product at the alternate location can be
compared with the production cost as well as with the cost to purchase a product.
The cost of external procurement is defined in the product master procurement tab.
Transportation and Transportation Method Cost

Understanding

245

Two different types of cost can be maintained for transportation. The first is called the
transportation cost. This is a unit and not distance-dependent cost. It can be used to
reflect certain base costs that are independent of the distance. Since the transportation
lane reflects a specific distance, they are nevertheless distance-dependent. The unit of
measure used for the transportation cost must be the products base unit of measure or
one of the products alternate units of measure. The other cost element is the
transportation method cost, which is defined using a unit of measure reflecting a distance.
The transportation cost and transportation method cost are added up to derive the overall
cost for transportation.
Transportation (and not transportation method) costs can be defined per transportation
method of a transportation lane (irrespective of the product) or on a lower level per
transportation lane, method and product. If product specific transportation methods are
defined, the global transportation method dependent transportation cost is not used
anymore and the product specific transportation cost is used instead (even if it is not
maintained and therefore Zero).
There is no need (and no possibility) to define transportation method costs on a perproduct level, as the distance described in the transportation method is the same for all
products.
Storage Cost
The storage cost represents the cost incurred by storing the product at a location. The
storage cost is defined in the products base unit of measure and per day. Note that there
is no cost attached to the usage of products stored in a location. If a new demand is
established for which no stock is available then the SNP Optimizer calculates the cost of
making the stock available via internal or external procurement. If a surplus stock is
available then the SNP Optimizer uses it without applying a cost to the usage. Safety
stock is not used in this way, as the safety stock level is interpreted as a demand and the
corresponding stock is therefore no surplus stock. Storage costs need to be defined
otherwise the SNP Optimizer suggests procurement earlier than required. This is correct
behavior, as with the storage costs being Zero it does not matter if products are procured
too early. The storage cost definitions can also be used to model preferred storage
locations with lower storage cost. In this way the storage cost can be used to guide the
product flow to preferred locations provided there is enough capacity.
The storage cost is defined on the product master G/R G/I tab.
Cost for Increasing Capacity
One of the variables for the optimizer is to increase the capacity if shortages occur.
Increasing of a capacity is usually only possible with additional costs over and above the
normal per unit cost. This cost is expressed separately for each production, transportation,
storage, and handling resource. The cost for increasing the capacity can also be seen as a
penalty if this freedom is being used. It is thus by definition between a cost of a solution
and a penalty. This aspect is rather academic, as costs and penalties are simply added up
to derive the final cost of the model.
The cost for using a certain capacity variant of a resource is defined in the resource
master transaction per capacity variant. The SNP Optimizer can use the capacity variants
1 and 2. It only uses the capacity variant cost when using the increased capacity.

The Penalties
Penalties are attached to all independent demands such as sales order, forecast, and calculated
safety stock demand. The aim of any supply network is to satisfy these demands and
consequently they are the sole driver on the penalty side. Whenever an established demand
cannot be timely satisfied or at all a certain penalty is added to the possible solution.

Understanding

246

The non-fulfillment of dependent demands does not carry any penalties. Dependent demands only
arise based on a need triggered by an independent demand. Should it not be possible to satisfy the
dependent demand (in time), then the independent demand can also not be satisfied (in time) . In
such cases the independent demand causes a penalty but not the dependent demand.
Penalty for Non-Delivery
The penalty for Non-Delivery determines the value that is attached to the solution if a certain
demand cannot be fulfilled at all. It is defined in the products base unit of measure. It is the
only mandatory penalty field, not from a data capturing point of view but rather from a logical
point of view. If no penalty is attached to non-delivery, the lowest-cost solution is always not
to deliver anything. Neglecting this fact will most probably result in the SNP Optimizer
returning a Zero-Cost and Zero-Activity supply network plan.
The penalty for non-delivery is defined in the product master SNP1 tab. This penalty can be
defined as a global location independent penalty or location dependent. If both are defined the
location dependent definition is used.
Penalty for Late Delivery
The Penalty for Late Delivery ensures that the Optimizer does not delay deliveries to customers
(sales order) or into stock (forecast) more than required. The penalty for late delivery is defined in
the products base unit of measure and applied per day of delay (late delivery). The maximum
permitted number of days for late delivery is defined separately. If the demand cannot be satisfied
within this period, the penalty for non-delivery is applied instead. The penalty for non-delivery
must not be smaller than the maximum penalty that can be applied for late delivery. Having
defined a penalty for non-delivery but not for late delivery results in the SNP Optimizer to find
random solutions where the day of delivery is not necessarily the closest possible to the original
demand. The only constraint is then really to deliver and to ensure that capacity is available in all
resources that are planned.

The penalty for late delivery as well as the maximum number of days is defined in the product
master SNP1 tab. These definitions can be carried out as globally location independent or
location dependent. If both levels are defined the location dependent definition is used.
Safety Stock Penalty
The decision to keep safety stock is strategic and will be adhered to by the SNP Optimizer as
far as possible. This safety stock penalty is used to ensure specified safety stock levels are
maintained. The definition of a safety stock penalty alone is not sufficient. It is also required
to maintain safety stock or safety days supply figures in either the product master (time
independent definition) or the appropriate key figure (time dependent definition). The penalty
for violating the safety stock level is defined in the products base unit of measure and applied
per day of safety stock violation. Only the shortfall in safety stock is used to determine the
penalty, not the entire safety stock requirement of the day.
Safety stock violations can be measured in absolute values (as described above) or
alternatively as a percentage. The safety stock penalties are applied accordingly. Furthermore,
it is possible to disable the use of safety stock penalties altogether in the optimization profile.
Safety stock requirements compete with the other requirements (sales orders and forecast).
They need to have a penalty that is higher (lower) than the penalty of these requirements if it
is more (less) important to maintain safety stock levels than satisfying these requirements.

Understanding

247

The safety stock definitions can be found in the product master lot size tab for all time
independent safety stock and Extended methods. Time dependent safety stock methods store
their data in key figures that can be maintained in the SNP Interactive Planning transaction.
The penalty for the safety stock violation, which is defined in the product master, is applied
in cases where the Optimizer does not suggest building up the safety stock level as
specified. It is also used when safety stock is used (temporarily) to satisfy a demand. This
can easily happen in a situation with very limited resource capacity and relatively low safety
stock penalties. In this case, the Optimizer plans to violate the safety stock requirements!
There is no specific master data object that carries the cost and penalty information. The data can be
found in various places. It can be maintained in each of the master data objects or in one central cost
maintenance tool (actually two), which simplifies this task. The SNP Optimizer model is based on a
dual capacity definition model. This allows the definition of two different sets of available capacity
for resources. The SNP optimizer compares the two capacity variants in terms of capacity and
associated costs, which can (and should) be defined differently per capacity variant. The cost
definitions that are used by the SNP Optimizer when applying capacity variant 1 (normal capacity)
and variant 2 (increased capacity) can be seen in the following table. It also provides an overview to
which master data object a certain cost or penalty belongs to.

Master Data Object

Product (Costs)

Plan (PPM)
Transportation Lane

Resource (Definition)

Product Global (Penalties)

Understanding

Master Data Object

Product Location Specific (Penalties)

Table 58 Cost Elements

(*1) Production, transportation, and storage costs are taken from the PPM, transportation lane,
and product master. As long as the capacity variant 1 is sufficient these are the only costs
associated to these activities. Should it be required to use capacity variant 2, the system adds
the incremental cost of using the capacity variant 2 to the base cost. The incremental cost of
using the capacity variant 2 is defined in the capacity variant that is linked to the resource.
(*2) Handling costs are only taken into account if it is required to use capacity variant 2. The
system then applies the cost of using this capacity variant.
In an effort to further enhance the flexibility (and complexity) of the SNP Optimizer it is possible
to change the cost and penalty cost factors (weights) within a range from Zero to 10 with 1 being
the default. The main objective of this tool is to support what-if scenarios. These factors can be
maintained in a profile and interactively while performing an optimization. Most of the cost and
penalty settings listed above can be influenced separately using these cost factors. There is a
common factor that is used for the global and location specific product master penalties.
What is the effect of all these cost and penalty setting possibilities? The following table provides an
overview of the impact the various cost and penalty settings. It must be remembered that they are
all very much interdependent and changing one setting marginally might result in a totally different
optimization result!

Cost / Penalty
External
Procurement
Storage

Production
Understanding

Cost / Penalty
Transportation
Resource Capacity
Expansion
Safety Stock
Late Delivery
Non Delivery
Table 59 Cost and Penalty Impact
The following flow diagram provides an overview of the cost determination used by the SNP
Optimizer.

Flow Charts exceed the available printing space and are only part of the on-line APO Knowledge
Bank.
Graphic 88 SNP Optimizer Cost Determination

3.7.1.3

Constraints and Feasibility

The optimization run uses various constraints some of which are hard constraints and others soft. A
constraint is defined, as a hard constraint if it cannot be violated at all. In this case there is also no
need to define any penalties. Time streams of a resource, for example, are hard constraints as they
define working and non-working times that must be adhered to The other group of constraints, the
soft constraints, may be violated if required, but at a cost. The cost of this violation is defined in the
SNP cost/penalty model. The required safety stock is such an example where the violation of this
soft constraint is possible but at the cost of the safety stock penalty.
Some demands can be switched over from being a hard constraint to a soft constraint with penalties
attached. These are the distribution demand and the dependent demand that originate outside the
optimization space. Let me give two examples.
A PP/DS controlled production order was created with subsequent PPM explosion. For one of the
components a demand was created outside the production horizon and is thus subject to SNP
optimization. Dependent demands can be set to hard constraint in which case the SNP optimizer
must satisfy this demand. Alternatively, such dependent demands that originate outside the
optimization space can be attached to a priority or to a penalty. The SNP optimizer can then satisfy
the dependent demand or not in which case the penalty is applied.
The second example is a distribution demand based on a requirement situated in a location outside
the optimization space. The same possibilities exist as above. This situation is depicted in the
graphic below.
Understanding

Optimization Space

Location
B

Location
A

Location
C

Distribution Demand

Location
D

Graphic 89 Hard Constraint Demand

The more hard constraints that are defined the less likely a feasible and/or optimized solution can be
found.
Note that it is not required at all to model a specific constraint. If for example the transportation
capacity is not limited, then either no resource should be attached to the transportation method or the
attached resource should be flagged as an infinite resource. In this way the SNP Optimizer loads
the resource as required but is not limited by the resources available capacity. In such a case the
resource might get overloaded. The result for the specific resource is then strictly seen as not feasible.
In an extreme case where all resources are set to infinite the SNP Optimizer provides a result
similar to that of the SNP Heuristics as long as some basic cost settings were carried out!
Optimization Bound Profile

Understanding

251

Another possibility to constrain the SNP Optimizer is the use of an optimization bound profile.
The optimization bound profile defines by how much a decision variable may change during an
optimization compared to a previous optimization run. This sounds more complicated than it is.
Example:
Based on an initial optimization run the quantity of a planned production order of a certain period
(the decision variable) shall be 100 pieces. We now define in the optimization bound profile that
the new optimization run result may deviate from the previous result by a maximum of 20%
upwards and 10% downwards. Thus we restrict the new optimization run to values from 90
through to 120 pieces for the planned production order in the same period.
In principle that is all, although there are a few further conditions and refinements.
The specified upper and lower boundaries apply to all decision variables
Decision variables include for example the planned production and transportation orders as
well as the purchase requisitions. The applied boundaries apply to all these decision variables
the same way.

Upper an lower boundaries can be defined independently

It is possible to define only upper or lower boundaries or both together. The defined
percentages are independent from each other.

Multiple upper an lower boundaries can be defined

Per periodicity an own set of upper and lower boundary can be defined. This applies only to
optimization runs that use telescoping planning buckets profiles. In a telescoping planning
buckets profile two or more periodicities are defined (e.g. days for the first two weeks and
then weeks for the rest of the planning horizon). The optimization bound profile upper and
lower limits can be defined independently per periodicity (e.g. lower upper and lower limits
for the periodicity day and higher limits for the periodicity week). In this way we can
give the Optimizer more freedom for buckets further away from the planning start while
maintaining more planning stability at the beginning of the planning horizon.

Any previous optimization run can be referred to

It is not required that the optimization bound profile refers to exactly the previous
optimization run. Any previous optimization run can be referred to, as long as its planning
result is still available to the system. The number of planning run results that need to be kept
can be defined in a system setting.

3.7.1.4

The Model Size

We have seen in the above sections how the SNP Optimizer works and which constraints are taken
into account. A fundamental principle of any optimization algorithm is to consider as many
constraints as possible at the same time and provide an optimal solution for the entire problem.
Some techniques exist to break this model down into smaller portions, if the optimization cannot
be achieved within a reasonable timeframe. All constraints need to be considered simultaneously
by the SNP Optimizer to provide the optimal solution. This set of constraints is referred to as the
Optimization Model. This model has a size, expressed in the number of constraints, which are
derived from the number of variables that need to be considered. The following elements that
directly impact the number of variables are the most significant.

Planning Periods

Understanding

252

The total number of planning periods is the total number of the different planning periods and
types. If the SNP Optimization is for example carried out using a telescoping approach with
14 days, 7 weeks, and 3 months, then the number of planning periods equals to roughly 24
(see Telescoping Planning Buckets Profiles).

Location Products
This comprises all products at all locations that are included in the SNP Optimization run. It
is irrelevant in this context whether stock, demand or supply elements exist for a product or
not.

Transportation Lane Products

The number of product procurement options is the driver for this variable. The number of
transportation methods is not included here.

Demand Elements
Any independent demand such as sales order, forecast demand, and safety stock requirement
contributes to this variable. This figure obviously increases with the number of planning
periods.

Permitted Average Lateness

This is the number of periods a demand may be satisfied late. It is defined in the SNP1 tab of
the product master.

Resources
Resources of any type (production, storage, handling, and transportation) are counted and
have the same impact.

PPM
Each SNP production process model for any of the defined location products is included here.
It should not come as a surprise that there are a maximum number of variables that can be handled
by the SNP Optimizer. This model size capability is not primarily dependent on the systems
memory and/or the liveCache size, but rather on the mathematical model and definitions used
within the optimization algorithms. This number of variables is, to use SNP Optimizer
terminology, a hard constraint and requires attention. The variables listed above do not necessarily
all have the same impact on the final number of variables. Exceeding the upper limit is simply not
feasible and it is required to reduce the number of some of the contributing variables. What is the
maximum number of variables? This is difficult to say without performing extensive tests or seek
advice from SAP directly. The maximum model size today might not apply anymore in a future
release and it is best to seek up-to-date information on this topic. The main issue is to understand
that the model size is of utmost importance and needs to be carefully considered.

3.7.1.5

Optimization at Aggregated Level

The SNP Optimizer can also plan at aggregated levels. The aggregated planning that can be
carried out is unfortunately not what one would really expect under this topic. Aggregation can be
carried out in two different modes, horizontal aggregation and vertical aggregation.
Vertical Aggregated Planning
The Process Steps
During the optimization planning run the SNP Optimizer carries out the following steps if the
aggregated planning flag(s) is (are) switched on:
Understanding

Demand Aggregation
Products are grouped using product hierarchies. The products can be defined in the same
or in different location. Locations are also linked in a location hierarchy. Before the

actual optimization takes place all demand of such products that are part of the
production hierarchy are aggregated to one demand against a product group. This
product group is modeled as another product in a specific location. This location is the
location where the demand can be satisfied (manufacturing or purchasing location). The
result of this aggregation is a demand per product group whereby the product group is
represented by a product. The SNP Optimizer applies the cost/penalty definitions of the
product group (as defined by the product) and not those of the subordinate products.
Determine Resource Requirements
It is required to define a PPM for the product group. The product group is modeled as a
product and there are no special requirements when creating the PPM for this product
group. Although one must keep in mind that this PPM is the PPM for a product group
and thus all products within it should be the same or identical in terms of PPM
definitions (e.g. same component and resource requirements). The PPM of the product
group must also be defined in the PPM hierarchy.
Find Optimal Quantity
This is the actual optimization process. The SNP Optimizer now works with a normal
product and PPM. It will optimize the planning situation including the product group
(represented by a product) together with all other products.
Distribute Supply
After the actual optimization has taken place using the product groups cost/penalty
definitions as well as its associated PPM, the optimized result (scheduled procurement
quantity) is distributed according to the demand proportions. The available supply is thus
distributed according to demand within the product group and not according to
cost/penalties within the product group.
The following graphic depicts a situation where the two products A and B can only be
procured with limitations due to resource constraints and component availability. Without
aggregation product A would be provided with the full supply as it has a higher penalty. With
aggregation the constrained capacity would be used to supply the products according to their
demand portion (one third compared to two thirds).

Understanding

254

Product A
D em and = 100
Penalty = 4
PPM

Product B
D em and = 200
Penalty = 3

PPM

Constraints

Product A
Supply = 100
Product A
Supply = 50

Graphic 90 Aggregated Planning

The Areas of Application

Optimization at the aggregated level is aimed at situations where products compete for limited
resources (components and/or machines) and where the individual allocation of resources
must not be based on the cost model. While aggregating various products into one product

group the products different cost/penalty settings are ignored and the user defines a new
combined cost/penalty setting for the product group. All products within the product group
now have the same weight during the optimization process and will not compete against each
other for the limited resources. Once an optimal solution has been found, all product group
members receive a supply allocation based on their demand portion (i.e. a product that has
20% of the product groups demand receives 20% of the available supply capacity).
Aggregation can thus be used in situations where products are competing for the same
resource or the same components.

The Limitations
Within APO, hierarchies with the node types location and product can be created. These
two hierarchies are used to create a generated hierarchy of the node type location-product.
The SNP Optimizer can use exactly one location-product hierarchy and thus the location

Understanding

255

hierarchy is the same for all products. It is not possible to define different location-product
hierarchies for different products (product groups).
The concept of using hierarchies implies that exactly one source location exists where the
required product is manufactured or purchased from. In situations where two sources of
supply exist the aggregated planning cannot deliver useful results.
Horizontal Aggregated Planning
Horizontal Aggregated Planning permits optimization of a portion of the selected supply chain
model through the limitation of products and/or locations.

3.7.1.6

Optimization Time Buckets

The SNP Optimizer plans to the granularity of time buckets (i.e. it does consider sequencing
constraints within the period). The time buckets can be defined in various widths (periods) such
as, for example, daily, weekly, or monthly. Within each time bucket the requirements are not
bucketed together but rather are still seen as individual entities with individual penalties. The
supply elements generated by the SNP Optimizer are bucketed per period. There might be, for
example, five sales orders on a certain day that the SNP Optimizer matches by exactly one
production or transportation order.
The time buckets used are defined in the planning buckets profile and do not have to have a
constant width within them. This principle, also called telescoping planning, allows defining, for
example, a bucket with 21 daily buckets, followed by 6 weekly buckets and 4 monthly buckets.
The whole planning horizon then covers approximately 6 months. The benefit is an improved
runtime while maintaining a reasonably fine granularity for the period close to the current date.

3.7.1.7

The SNP Optimizer Modes

As explained before, the SNP Optimizer offers various modes that can be used to achieve the
planning result. The question which one is best cannot be answered, as each has got advantages
and disadvantages and the speed and quality of the result depends also to a large degree on the
network defined in the supply chain model and not so much on the actual data. There is also a
difference if the main task is to find a feasible solution compared to a situation where the main
emphasis is in finding an optimal solution. All methods should be considered and tested for
suitability and performance. This is not an ongoing task, as the method that provides the bestsuited solution can then be used as a standard setting for the SNP Optimizer. Infrequent follow
up checks can validate a previously found best solution.

Solver Group and Method

Understanding

256

Solver Group and Method

Continuous

Discrete

Fu

Pa

Table 60 SNP Optimizer Modes

3.7.1.7.1

Continuous Optimization

The term Continuous Optimization refers to all such optimization methods where the
discretization options (full or partial) are switched off. This includes the primal and dual LP
Solver with or without IPM. It might include the usage of product and/or time decomposition as
well as hard prioritization.

3.7.1.7.1.1

Hard Prioritization

The SNP Optimizer offers the possibility to optimize in accordance with the demand priority. This
mode, referred to as Hard Prioritization, allows a sequential cost based optimization per demand
priority. Working with demand priorities is an option when using continuous optimization
methods (primal, dual, with and without IPM). The hard prioritization mode optimizes the supply
network, not according to the cost and penalty settings of all demands at the same time but rather
optimizes the network in steps, each step only using demands of a certain priority. The sequence is
according to priority, starting with the highest priority (1). A total of 6 demand priorities are
allocated to various types of demands.
By default the following demand priority allocations are used by the SNP Optimizer.
Demand Priority 1
Demand Priority 2
Demand Priority 3
Demand Priority 4
Understanding

257

Demand Priority 5
Demand Priority 6

The safety stock priority can be changed to any value from 1 to 6. Dependent demands and
distribution demands can be allocated any of the 6 priority settings or left as hard constraints. Hard
constraint demands do not have a priority, as they must be satisfied in order to achieve a feasible

solution. If hard prioritization is switched on and all demands have the same priority then the
result is the same as it would be without hard prioritization.
The penalties for the demand types Sales Order, Forecast Demand, and Corrected Forecast
Demand can be maintained in the product master SNP1 tab. These penalties are defined either
globally or per location (see section Product Master). Although not visible in the product master
SNP1 tab, there is a link between the demand type (e.g. sales order) and the priority (e.g. 1).
Another way of maintaining the SNP cost model is the Cost Maintenance transaction. In this
transaction it is required to define the respective priority together with the penalty. This is just
another view of the same data and this time the demand type is not shown but rather the demand
priority. It must also be mentioned that all data maintained in the cost maintenance transaction is
planning version dependent!

3.7.1.7.1.2

Product Decomposition

The Product Decomposition method groups products and then finds an optimum solution for one
group of products after the other. The number of product groups can be defined in the SNP
Optimizer profile. The higher the number of product groups, the more the result will deviate from
the overall optimum. Product Decomposition is an option for the continuous optimization (linear
solver) as well as with the discrete optimization.

3.7.1.7.1.3

Time Decomposition

The optimum solution is always based on a certain time frame. If the start and/or end date of the
optimizer run is changed, the result changes as well. The longer the time span, the more data has
to be considered, and the longer the run will take. Time Decomposition offers the possibility to
break down the time span into smaller time buckets. The solution finding process for each time
bucket takes much less time than the solution for the entire time span. If, for example, a time span
of four weeks is subdivided into four one-week buckets, the time to find the optimal solution for
each of the one-week buckets is much less than a fourth of what it would take without Time
Decomposition. With this method the buckets are optimized sequentially. The result is not an
overall optimum but various sub-optimums. Time Decomposition is an option for the continuous
optimization (linear solver) only.

3.7.1.7.2

Discrete Optimization

Understanding

258

The term Discrete Optimization refers to all such optimization methods where the discretization
options (full or partial) are switched on. Discrete optimization can be done in conjunction with the
product decomposition option.

Full Search
If discretization with the full search option is switched on, the system uses the branch and
bound methods as explained earlier. This method is a different mathematical approach
compared to the linear solver. The fact that another algorithm is used is transparent to the
user. The main advantage of discrete optimization is that it can adhere to lot sizes. The
disadvantage of discrete optimization is the by far longer run time compared to linear solvers.
Run time as well as number of iterations (improvements) can and should be limited.
A full search discretization optimization mode ensures that the provided result is the
objective optimum based on all specified constraints. This is true as long as the run time was
not limited.

Partial Search
The partial search approach tries to combine the advantages of discrete optimization (usage of
lot sizes) with the advantages of linear solvers (better run time behavior). Although called
discrete optimization, the system uses the linear solver to find an initial optimal solution. This
solution most probably violates the discrete constraints (e.g. lot sizes). In a subsequent step
the partial search discrete optimization finds solutions that are in accordance with the discrete
values and as close as possible to the original optimum solution, which was based on a linear
solver approach.
The preferred rounding limits for the production and transportation variables play an
important
role in the partial search discretization.
Discrete optimization has the main disadvantage of being in most cases by for more time
consuming than continuous optimization. It should therefore only be used if required. If any of the
functionality listed below (or combination thereof) is required then the use of the SNP Optimizer
in discrete mode is required.

Discrete Lot Sizes

If lot sizes need to be restricted to specific (discrete) values according to settings in the
product master or transportation lane.

Minimum Lot Sizes

If lot sizes need to be above a minimum values according to settings in the product master or
transportation lane.

Discrete Transportation Methods

If only specific transportation methods may be used.

Discrete Increase of Production Capacity

If capacity increases are in steps.

Piecewise Linear Cost Functions

If the cost per unit is not constant but depending on the quantity manufactured or transported.
Fixed PPM Resource or Material Consumption
If the PPM defines fixed (i.e. quantity independent) costs per order.
With release 3.1 a new option is available:
Cross Period Lot Sizing
If orders need to be planned cross periods (buckets).

Discretization of data can be carried out for the entire planning period or only for a specified
period of time. To define a specified date the flag Discretization until End Date/Detailed must
be set to End Date in the interactive optimization parameter maintenance screen (flag switched
off in

Understanding

259

profile maintenance). For the detailed definition it must be set to Detailed in the interactive
optimization parameter maintenance screen (flag switched on in profile maintenance).

Discretization until End Date

The time buckets profile used when starting the SNP Optimizer (interactive or batch) defines
the planning period length. The start date of the planning period is the current date. The
standard delivered time buckets profile is labeled 9ASNP and spans over 10 weeks and
thereby determines the end date of the planning period. Defining shorter periods for the
discretization of data improves the runtime of the SNP Optimizer in two ways. First of all the
time to discretize data is reduced and secondly the processing of linear, non-discretized, data
is faster. The end date for the discretization can be set to any date between the start and the
end date of the planning period. Note that the discretization end date is an absolute value that
does not change whereby the planning period is defined as a relative time period starting from
the current date. This means that the discretization end date, if used, needs to be checked (and
potentially changed) before each optimization run. The discretization end date can be
maintained directly in the profile or through the activation of the Maintain Discretization
End Date pushbutton in the interactive optimization parameter maintenance screen.
The partial search discretization optimization mode provides a reasonably good, but worse,
result compared to the full search mode. Its benefit is an improved run time.

Detailed Discretization
Data is discretized for the entire planning period.

3.7.1.7.2.1

Product Decomposition

The Product Decomposition method groups products and then finds an optimum solution for one
group of products after the other. The number of product groups can be defined in the SNP
Optimizer profile. The higher the number of product groups, the more the result will deviate from
the overall optimum. Product Decomposition is an option for the continuous optimization (linear
solver) as well as with the discrete optimization.

3.7.1.7.2.2

Cross Period Lot Sizing

This is new functionality available with release 3.1. Cross Period Lot Sizing is a process
where lot sizes may exceed those that can be manufactured in a single bucket. Using SNP
Heuristics or Optimization in continuous mode, it is only possible to plan lot sizes that do not
exceed the quantity that can be manufactured during a single bucket (day). The Cross Period Lot
Sizing planning process is only supported by the SNP Optimizer when running in discrete mode.
The described process is mainly thought to be part of the Campaign Planning process. Using the
SNP Optimizer, it is possible to perform a rough-cut campaign planning in SNP before the finite
scheduling is carried out in PP/DS.
The SNP Optimizer running in discrete mode takes into account the status of the used resource at
the end of the previous period (bucket) as long as the same Production Process Model (PPM) is
used to plan the production in all buckets. As a result, only one setup activity with the appropriate

Understanding

260

setup times and costs is scheduled in the first bucket but none in any consecutive buckets for the
duration of the lot. In order to plan cross periods, the setup status of the resource is used. The SNP
Optimizer also considers the setup status of existing PP/DS orders.

3.7.1.8

The Planning Run

The SNP Optimizer can be started from the SNP Interactive Planning screen. In this case the
planning version and the time frame defined on the initial screen are used as input parameters for
the SNP Optimizer run. When starting the SNP Optimizer, the SNP Optimizer and Cost profiles
have to be specified. The master data used is as defined in the supply chain model that is attached
to the planning version. Depending on the planning method, all or only a subset of the products
are used in the planning run. The SNP Optimizer can also be carried out as a background job.
During the SNP optimization, the system first reads all data that is required for the optimization
run and creates an internal interface file with this data. This interface file is given to the
optimization server for further processing the optimization. The user can view the interface file
in the form of the SNP Optimizer input log.
The data collected by the system and handed over to the SNP Optimizer is grouped into the
following areas and topics:

Optimization Control Parameters

ES_SUPER
Control Information for Supervisor
ES_CTRL
Model parameters, number of objects, and indicators
ET_INEXKEY
Conversion of GUID to External Key for all used master data objects
ET_BUCKDF
List of the time buckets related to dates
ET_MATERIAL
Time dependent list of used products (all products valid for whole bucket range)
Time Independent Master Data
ET_LOC
Handling
resource
ET_SUBLOC
Storage
resource
ET_LOCMA
T Product
ET_RESOURCE
Production
resource

ET_RESFAM
Production resource family
ET_FLEET
Transportation resource

Understanding

 ET_ARC
Transportation
lane

Time Dependent Data for Date Range

ET_ARCMAT
Transportation lane, method, and product flow information
ET_LOCC
Handling resource normal capacity
ET_LOCUC
Handling resource extended capacity
ET_SUBLOCC
Storage resource normal capacity
ET_SUBLOCUC
Storage resource extended capacity
ET_RESC
Production resource normal capacity
ET_RESFAMC
Production resource extended capacity
ET_FLEETC
Transportation resource normal capacity
ET_FLEETUC
Transportation resource extended capacity

Time Dependent Data for Bucket Range

ET_PROMO
PPM
Parameters
ET_PRORES
Resource consumption per PPM
ET_PROMAT
Product requirements per PPM

Time Dependent Data per Bucket

ET_LOCPROD
Location product flow information
ET_DEMCLTIM
Penalties per location and product and demand class (bucket-to is always the last bucket)
ET_DEMAND
Demand per location, product and demand class
ET_PROCBND
Procurement limits per location and product
ET_PRODBND
Production limits per location and product
ET_TRANBND
Transportation limits per location and product
ET_STCKBND
Storage limits per location and product
ET_DELIBND

Understanding

262

Delivery limits per location and product

Time Independent Cost Function Data

ET_TRANCOS
Transportation cost function per transportation lane and method
ET_PRODCOS
Production cost function per PPM
ET_PROCCOS
External procurement cost function per product

The output of the SNP Optimizer run is planned orders for production, transportation, and/or
purchasing. The orders are created in liveCache and are accessible for further processing. Alerts
can be created as and when required. They can be seen in the Supply Chain Cockpit and the SNP
Interactive Planning screen.

3.7.2

The Deployment Optimizer

The Deployment Optimizer is a derivative of the SNP Optimizer. It shares the vast majority of
settings with it and uses the same algorithm. The principle difference is that the Deployment
Optimizer plans the cost optimal deployment of all available stock elements but does not create
any SNP planned production orders in the case of product shortages. Subsequently, the
Deployment Optimizer does not use any cost parameters that reflect only production cost (e.g.
production cost defined in a PPM). It also cannot update procurement quota arrangements. The
Deployment Optimizer allows the definition of some parameters that are not available for the SNP
optimizer.

In case of product shortages, the deployment optimizer searches for the most cost efficient
solution. Alternatively a fair share rule can be applied in the case of shortages. The fair share
rules used in connection with the Deployment optimizer are not necessary identical to those
fair share rules defined in the product master.

In case of surpluses, push distribution principles can be applied. The definition of surplus
depends on the selected push rule.
The Deployment Optimizer is a regenerative planning algorithm. This means that at the beginning
of the planning run all orders, in this case SNP planned transportation orders, are deleted. In a
second step new Deployment planned transportation orders are created, if the supply situation
permits this. In cases where an SNP planned transportation order existed without supply elements
covering this demand, the Deployment Optimizer will delete the SNP planned transportation order
without a new Deployment transportation order being generated.

3.7.2.1

The Deployment Optimizer Parameters

The Deployment Optimizer permits the definition of some parameters that are not used by the
SNP Optimizer.

Fair Share Rule

Understanding

See above for more information on this optional setting. Fair share rules are also discussed
in the Deployment Rules section.
Push Distribution Rule

See above for more information on this optional setting. Push distribution rules are also
discussed in the Deployment Rules section.
Deployment Pull Horizon
The deployment optimizer does not use the deployment pull horizon that is defined in the
product master. All products in a deployment optimization have the same deployment pull
horizon. This mandatory setting must be carried out when starting the deployment
optimization run.
Deployment Push Horizon
The deployment optimizer does not use the deployment push horizon that is defined in the
product master. All products in a deployment optimization have the same deployment push
horizon. This mandatory setting must be carried out when starting the deployment
optimization run.
ATD Checking Horizon
The ATD checking horizon is an optional setting that permits the grouping and early
recognition of requirements. This ensures that the deployment optimizer does not use up the
available supply although another requirement might arise a short time later. The following
two tables show an example of the different ATD calculations where an ATD checking
horizon of 3 was used.

Bucket
1
2
3
Table 61 ATD Checking Horizon = 0

Bucket
1
2
3
Table 62 ATD Checking Horizon = 3
(

The ATD quantity depends on the ATR and ATI of the current and the future periods and can
thus not be determined without knowing the ATR/ATI situations in buckets 2 and 3.

Understanding

3.8

264

Document Flow

We have seen in previous sections that Supply Chain Planning is a multi-step process and it should
therefore be of no surprise that a multitude of documents are created throughout this process. The
word document in this context is not a paper document but rather an electronic document that
carries all required information. Within APO these documents are referred to as orders. In fact
orders are not only used to store transactional data but even the stock on hand at a location is
technically stored in an order. This statement is true for PP/DS and for SNP at least as long as no
time series based storage of information is used. Time series based storage of data is used in
conjunction with the Sales and Operations Planning (SOP) functionality. As the majority of
information is stored in orders, it is required to distinguish between the various types of orders,
such as transport orders, production orders, and sales orders. This distinguishing element is the
order category, also referred to as the ATP category. These order categories precisely determine
what the orders refer to. System-internally a lot of activities are dependent on the order category.
Orders can originate in APO (e.g. the SNP planned production order) or from a linked OLTP
system or R/3. This leads into another area that of data exchange with other systems, which is the
topic of another section. The forecast requirements generated in DP are also stored in orders once
released to SNP (again except when using SOP). The order types can be grouped in various ways,
a common one being according to their anticipated direction of product flow.

Requirements
The Requirements group comprises all those elements that represent a requirement. Examples
are the aforementioned sales orders or forecast requirements. Both are independent
requirements, as they do not depend (relate) on any other order (or document) in the system.
Within this group we also find dependent requirements, which are mostly the result of a
planning activity. Examples are the generated requirements of raw materials when exploding
a PPM or a stock transport request as a result of a requirement in a downstream location. The
key is that dependent demands can always be related to another document in the system.
Within PP/DS even the required safety stock can be modeled as an order.

Receipts
In the Receipts group are all those documents that refer to an anticipated receipt. These
anticipated receipts are from production or procurement. Procurement in this context refers to
purchasing activities as well as transportation receipts. These are of special interest in the
Transportation Planning environment and we shall see later that there is a multitude of orders
reflecting the various stages in Transportation Planning.

Stock
It might come as a surprise but there is no reason why stock cannot be handled just as any
other order on the system. The real difference is that the anticipated receipt time is always the
current time, as the receipt has taken place already. There are various order categories
reflecting different stock types such as unrestricted stock, quality inspection stock, and stock
held at a subcontractor to name a few.
All these order categories reflect orders on the APO system. There are documents such as a sales
order that have exactly one order category but there are also other orders that have two categories.
An example is the transport order, which is a receipt in one location and a requirement in another.
For this reason it is required that this document has two order categories depending on the
location viewed. A document with one order category is a one-leg order and a document with
two order categories is a two-leg order.

Understanding

265

For the user it is not required at all to know the technical names of the various order categories.
Indeed it is sometimes not easy to even see them. Each order category has a short and a long text
attached to it and these texts are mostly displayed in the transactions.
All those who really want to understand what is going on behind the scenes will need to have a
deeper look at these order categories. The following sections will provide helpful information and
should be read in conjunction with the sections that are dealing with the planning area and
planning book.

3.8.1

SNP Order Categories

The SNP module within APO is that which most probably changes the order categories the most
frequent. It also works with a multitude of order categories. The following list provides an
overview of the most common order categories used within SNP. Not all of the listed order
category types are in accordance with the settings of the APO system as delivered. The category
type allocation can be changed according to specific requirements and in some cases two options
are shown in the table below. The abbreviations used in the table as well as the short and long texts
are taken directly from APO.

Module
Location
SNP
Receiving

(alternative)
Sourcing

(alternative)

Deployment
Receiving

Sourcing

Understanding

266

Module
Location

TLB (*)
Receiving

(alternative)
Sourcing

(alternative)

Table 63 SNP Order Categories

(

TLB orders are potentially saved using different order categories before and after they were
transmitted to the R/3 system. The order categories used before saving can only be viewed
if TLB orders are not immediately transferred to R/3. The order categories used by TLB
after the R/3 system received the TLB order and confirmed its creation are the same as
those in the rows alternative.

A more technically orientated view on the topic order category can be found in the section The
Planning Environment. The graphic below is an overview flow diagram of the orders listed
above that also indicates some of the main transactions used to maintain the respective order
categories.

Understanding

267

D o cu m en t T ype s fo r V M I O rde rs
N ot p ossible fo r V M I O rd e rs

C rea te d D o cu m e n ts T ype s (A P O ) a n d M R P E lem e n ts (R /3)

T ra n s p o rta tio n O rder P rocess

E B (*1)
S N P R e le a se fo r
S tk T ran sfe r R eq .

S h ip p in g
ED
S N P V M I S a les
O rd er

BH
S tock T ran sp ort
R eq u isition

ED
S N P V M I S a les
O rd er

EG

U2
R ele ase for
P urch ase
R e q uisition

D ep loym e n t R e le a se fo r

P u rcha se R e q .

EH
D e plo ym e n t V M I S a le s O rde r

U2
R ele ase for
P urch ase
R e q uisition
D e plo ym en t R u n
H eu . R /T , o r O pt.

D ep loym e n t
O rd er E d iting

BE
O rd e r Item S che d
ule L in e

T P /V S

Graphic 91 Document Flow

(*1) Could also be order categories BH/AG (see above).
(*2) The Deployment planning step can create purchase requisitions or purchase orders in the
connected R/3 system. It is not possible to use TLB functionality based on Deployment
orders that were transferred to R/3 as purchase orders. This option is used when TP/VS is
used instead of TLB. In this case purchase order numbers are returned from R/3 to APO
after the order has been created in R/3.
The demand category types of the orders in APO are the same irrespective of the selected
option. The supply category types of the orders in APO are either EF when creating

Understanding

268

purchase requisitions (which is according to the deployment order setting) or BF when

creating purchase orders (which is according to the TLB order setting). Possibly the order
type is EI instead of BF depending on the planning area setting for TLB confirmed
receipt elements.
(*3) Could also be order categories BI/BF (see above).

3.8.2

Transportation Order Categories

Orders related to transportation activities are created at various planning steps. The type of order
created depends on the planning step and also on the creation mode. The creation of some of the
orders need to be enabled and can also be customized (path in IMG: APO > Supply Chain
Planning > Supply Network Planning > Basic Settings > Configure Transfer to OLTP Systems).
See the text below for further details. The following list provides an overview.

SNP
The output of the SNP planning step is reflected in R/3 as a purchase requisition. The creation
of these SNP orders in R/3 needs to be enabled,
SNP Planning Run
The SNP Heuristics and Optimizer consider the target location type and create orders
appropriately. Depending on the target location type, the system creates VMI or NonVMI orders. Uncovered demand within the stock transfer horizon is catered for by SNP
receipt elements scheduled on the first period after the end of the respective horizon. The
SNP Optimizer can be set to create transportation orders within the stock transfer
horizon.
SNP Manual Planning (SNP Interactive Planning)
Orders created in the SNP Interactive Planning transaction do not consider the target
location type. All created orders are Non-VMI orders. Thus, SNP VMI orders cannot be
created manually using the SNP Interactive Planning transaction. SNP transportation
orders can only be created beyond the stock transfer horizon, as the system respects the
stock transfer horizon.
The source location and/or the transportation method of SNP transportation orders (VMI
and non-VMI) can be changed in the SNP Interactive Planning transaction and the PP/DS
Product View.

Deployment
The output of deployment is also a purchase requisition in the R/3 system. This can be
changed in customizing so that the deployment output is reflected as a purchase order in R/3.
This is a requirement if TLB is not used and vehicle scheduling must pick up the results from
deployment.
Deployment Planning Run
The Deployment planning run only converts existing SNP created orders and does not
change any order details. Automatically converted orders have the correct category type
after the conversion. Depending on the target location, the system converts the orders to
either VMI or Non-VMI deployment orders.
Deployment Manual Planning

Understanding

269

Deployment orders cannot be created manually. The source location and/or the
transportation method of deployment orders (VMI and non -VMI) can be changed in the
SNP Interactive Planning transaction and the PP/DS Product View.

TLB
The output of TLB is also a purchase order in the R/3 system.
TLB Planning Run
The TLB run splits and combines existing deployment orders; it does not create any.
Consequently, the orders created in the TLB run have the correct category type.
Depending on the target location, the system converts the orders to either VMI or NonVMI TLB orders.
TLB Manual Planning (SNP Interactive Planning)
Manually created TLB orders are created with consideration of the target location type.
Depending on the target location type, the orders are either VMI or Non-VMI TLB
orders. TLB orders can be created within and beyond the stock transfer horizon. An
online availability check is carried out. A warning is displayed in the case of nonavailability.
The source location and/or the transportation method of TLB orders (VMI and non-VMI)
can be changed in the SNP Interactive Planning transaction and the PP/DS Product View.

PP/DS
The output of the PP/DS planning is reflected in R/3 as a purchase requisition. The category
of these orders can be customized in the global PP/DS settings.
PP/DS Planning Run
Demand within the production horizon is catered for by PP/DS receipt elements. The
system does not create VMI orders but standard purchase requisitions, even if run at a
location of type customer. For this reason PP/DS must not be run at a VMI location.
Demand beyond the production is not in the planning scope of PP/DS. A purchase
requisition number is allocated to the order. This also applies to the background planning
when the product is flagged for automatic planning.
PP/DS Manual Planning
Manually created orders do not consider the location type. All orders created are NonVMI orders. Thus, VMI orders cannot be created manually using PP/DS functionality.
PP/DS receipt elements can be created within and beyond the stock transfer horizon.
Manually created orders are firmed (fixed) automatically by the system but can be
unfixed.
The source location and/or the transportation method of PP/DS created transportation
orders can be changed in the PP/DS Product View.

3.8.3

Inter Module Data Flow

Since APO has got various modules the question is to which extent these modules use the same
data and where it is required to pass over information from one module to the next. It might appear
as a contradiction talking of an integrated system and at the same time about data that needs to be
passed over from one module to the next in a batch type manner. This is not the case, as the
following example reveals.

Understanding

270

In demand planning some DP planners are busy revising the forecast for the next month. At
the same time the SNP planners create a rough cut plan for the next six months. Surely they do
not want to see all the changes of next months revised forecast before they are final. As soon
as they are final the DP planner sends the revised forecast to the SNP planner for further
action.
One can also think of other scenarios that require a strict separation of plans and often using more
than one planning version even within one module accommodates this. It is therefore required to
separate data as far as possible to enable independent planning wherever required. There are not
only requirements for data transfer from module to module but also sometimes within modules.
The following graphic provides an overview.

R e le a s e S N P c o n firm e d F o re c a s t to D e m a n d P la n n in g
(in D P )

R e le a s e to S u p p ly N e tw o rk P la n n in g
(in D P )

R e le a s e to D e m a n d P la n n in g
(in S N P )

R e le a s e to S u p p ly N e tw o rk P la n n in g

SNP

- E x te n d e d (in D P )

R e le a s e to D e m a n d P la n n in g
(in S N P )

C o n v e rs io n o f S N P O rd e rs
in to P P /D S O rd e rs

P P /D S

O rd e r B a s e d
D a ta S to ra g e

Graphic 92 Inter Module Data Flow

For an overview of transactions that deal with this subject view the section Key Figure Release
and Order Conversion.

Understanding

3.9

271

Collaborative Planning

Performing planning activities in the supply chain environment should never be a stand-alone
function. This would directly contradict the approach of planning the chain rather than the
individual links of the supply chain. For this reason it appears to be a contradiction to specifically
address the topic of Collaborative Planning. The definition of Collaborative Planning is the
joint supply chain planning including internal and external business process members. I would like
to clarify this. The term Supply Chain Planning includes all planning activities within a given
organization (enterprise). Collaborative Planning goes one step further and includes external
partners for at least some of the processes (e.g. forecasting). Only when engaging in collaborative
planning, an organization performs real supply chain management. Collaborative planning is not a
system module but the description of a planning concept where several partners, internal and
external, engage in a joint planning activity. Examples for such planning tasks can be jointly
developed and agreed forecasts or automated replenishment agreements. A common practical
application of collaborative planning is Vendor Managed Inventory. But this is only one
example of many possible ones. The enabling technology for collaborative planning is the SCM
system and in most cases the Internet. The Internet is used to easily transfer data in batch mode or
to provide on-line access to remote users. The data transfer might be directly from one enterprise
system to the next or via special data exchange servers.
The concept of collaborative planning is implemented within APO using the term Supply Chain
Collaboration or Collaborative Planning (CLP). As the first real Internet driven component,
Collaborative Planning provides various planning functions used in the Demand Planning,
Transportation Planning, and Procurement areas. Supply Chain Collaboration is not a function that
can also be used via the Internet; in most cases it actually requires it.
Conceptually, two technical collaboration scenarios are offered within SAP APO.
Single-System Collaboration offering web enabled remote access to APO system
Collaboration with External Partner
One APO system is used in this scenario, which keeps all data. Simplified access is provided
to the user by means of special HTML based applications. The remote users do not need any
APO system or the SAP GUI. They can work using an Internet browser. Special planning
books need to be designed limiting the amount of data displayed for the remote user.
Simplified views enable easier understanding and faster processing over the Internet.
In order to follow this route APO requires the installation of the Internet Transaction Server
(ITS). This is required in order to generate and later publish the HTML pages. As the remote
user has to manually enter data, this option is preferred for scenarios with less data transfer
requirements.

Multi-System Collaboration linking various APO systems

Collaboration with APO Partner
In this scenario data between multiple APO systems is exchanged. This allows the data
synchronization of several APO systems. This can be used for example to send forecast
figures from one system to the other or to exchange purchase orders. It requires that the
design of planning areas and data structures of the forecast be aligned in the various APO
systems. They do not have to be the same but need to be compatible.
The initial effort to set up such a scenario is higher, but once implemented allows the efficient
transfer of large amounts of data. This is particularly important for collaboration tasks
between

Understanding

272

larger organizations. It is not an absolute requirement that both collaboration partners use
APO. The real requirement is that the data exchanged is consistent and interpretable by both
partners.
The technical possibilities to utilize the Internet for collaboration tasks are also described in the
section SCM and the Internet.

3.9.1

Collaborative Supply and Demand Planning

The functionality of Single-System Collaborative Demand Planning is identical to that of the

Demand Planning function, which is forecasting. The difference is that this planning is carried out
involving various partners that could be within the company or external. Specifically for the
external partners, the planning tools were simplified and web enabled. As a result of this effort,
easier to handle screens (HTML pages) are provided to the user who only needs an Internet
browser and not the SAP APO GUI on his or her PC.
Collaborative Planning is a joined planning effort of anticipated sales or, in other words, the sales
forecast. The forecast data is stored in the APO liveCache and can be accessed using the normal
non web-enabled transactions or the new web-enabled tools. It is important to understand that
collaborative planning is a planning approach and not an alternative forecast. Any data can be
maintained using the web-enabled or the non web-enabled tools. The Collaboration Engine, which
consists of the specific web-enabled functionality to support the Collaborative Planning, consists
of the following elements.

Planning Book Designer

The planning book designer is used to create the planning book used in the collaborative
planning process. At the end of the planning book definition, it generates the HTML pages
that can be accessed via the Internet. This planning book is usually a scaled down version of
the planning book used internally, offering the external planner only such information that is
applicable to him or her.

Planning Book
The planning book used in Collaborative Planning should be a streamlined version of the
normal internal planning book, concentrating on those tasks that need to be performed by an
exterior planning partner. Its appearance is similar to that of the normal planning book. The
selection of data is improved and only such selection IDs that are relevant to the specific
planner are displayed. The selection ID can also be used to predefine a certain set of activities
with the sequences in which they have to be carried out. As each activity has a status
precondition, even the inexperienced user cannot miss a single step.

Alert Monitor
The alert monitor provides the user with alerts related only to the data that is available for
planning. Alerts are grouped and can be filtered according to different parameters.

Enhanced Macros
Specific macro functions are added for the use in Collaborative Planning. Macros can be run
either automatically (e.g. after every update), or manually.
Multi-System Collaborative Demand Planning uses special system functionality to either send or
receive forecast relevant data to or from another APO system. The sending of data is actually a

Understanding

273

small batch job and requires the recipient to accept the data and update his or her own APO
system. Data is transferred in form of a Time Series. Received data is processed in the receiving
APO system as if it was own data. The main challenge with this approach is to synchronize the
activities across various (at least two) collaboration partners.
Within APO, both options explained above are referred to as Time Series Based Collaborative
Planning. The data captured or transferred is in the form of a time series. Per time period (e.g.
week 37/01) a discrete value (e.g. 100 pieces). Another option is the collaboration on discrete
orders, which is referred to as Order Series Based Collaborative Planning (see below). Again it
is assumed that both collaboration partners use APO although this is not an absolute requirement.
The real requirement is that the data exchanged is consistent and interpretable by both partners.
The collaboration process as described above can refer to the forecast or to specific promotions.
The latter is referred to as Collaborative Promotion Planning. The process as well as the
technical implementation is the same for the Collaborative Demand Planning and the
Collaborative Promotion Planning.
The task of Collaborative Supply Planning is the collaboration on anticipated demands, the
anticipated demand being a supply element for the requestor. Currently the exchange of the
Request for Quotation (RFQ) is supported. In this scenario selected RFQs can be sent or
received by the APO user.

3.9.2

Collaborative Transportation Planning

The collaboration in the transportation planning area is a follow-up on the Vehicle Scheduling task
performed in the APO TP/VS module. The data exchange is carried out using standardized EDI
messages or an Internet-based XML data transfer. In both cases the transportation planner at the
transport requestor initiates the sending of the appropriate data, the shipment request, to a specific
carrier. This happens after the carrier selection has been carried out in the VS planning run or
manually. A shipment request refers to one or multiple sales delivery documents, which in turn are
based on sales orders. The shipment request can be changed during this process and will, after the
final acceptance from both sites, be transferred to R/3 as a shipment order for execution.

3.9.3

Collaborative Procurement

Collaborative Procurement permits the creation and transmission of scheduling agreement releases
to a vendor. A scheduling agreement is a form of purchase order where the customer commits to
the purchase of a certain product in a specified quantity and time frame. What is not defined
upfront is the exact date on which the products have to be delivered by the vendor. Initially the
customer and vendor agree on a forecast (or planning) delivery schedule, which is not binding at
this moment. The exact schedule of deliveries is established later by means of individual operative
schedules (call-offs). Each call-off relates the said scheduling agreement and determines the exact
delivery date. Legally speaking, the scheduling agreement is the purchase order, not the individual

Understanding

274

call-off. It is common to re-transmit the forecast schedule with each operational schedule to
inform the vendor of possible changes of the intended future call-offs.
Using Collaborative Procurement, these individual call-offs can be created and monitored by the
planner and sent (together with the forecast schedule) to the vendor. Note that the APO
Collaborative Procurement is not a tool to collaborate on purchase orders.

3.9.4

Vendor Managed Inventory

Vendor Managed Inventory (VMI) is a supplier customer relation where the vendor monitors the
stocks at the customer and automatically replenishes these stocks at the customer, as and when
they fall below previously agreed levels. Stocks sent to the customer are mostly sold with
dispatch. The only difference to a normal sales order is that, in fact, the supplier decides when to
sell (replenish). For this construct to work, it is necessary that the supplier maintains and monitors
the customers stocks on his own system. R/3 did not have any standard tools to do so with APO
however, this is now possible. A VMI customer is set up just the same way as any other location;
the distinguishing factor is the location type. The starting point for the VMI planning is the sales
forecast of the VMI location. From a vendors point of view this is the customers forecast. It
could be generated by the customer and transmitted to the vendor or created at the vendor using
the Demand Planning functionality. In addition to this information, the vendor requires the
customers stockholding figures on a frequent (daily) basis. APO keeps track of the stock level at
the VMI customer and the VMI customer can therefore be easily included in the Supply Network
Planning activities. Based on the location product forecast, the actual stock levels, and the agreed
levels; the SNP planning run calculates the replenishment requirements. The result of this planning
step is suggested VMI sales orders.
VMI is becoming more and more common in the Consumer Packaged Goods (CPG) industry
sector. The VMI customer location modeled in APO represents, most of the time, a customer
distribution center. Forecasts are then an aggregated view of the requirements established at the
customers sales points (shops) that are replenished from this distribution center. In addition to the
logistical aspect described above, companies usually render into some type of risk sharing
agreement where the vendor is obliged to take back product stock from the customer if it cannot
be sold in time.
Furthermore, it is common practice to run areas within a shop as a type of profit center where the
vendor takes full responsibility for the profitability of the products sold down to the shop level.
This might include pricing decision as well as the maintenance of the dedicated product area. The
customer virtually rents out a portion of the shop to the vendor.
APO supports VMI by providing special but integrated planning for such customers. Within
Demand Planning, forecasting can be carried out per VMI customer if this is required. In SNP, a
VMI customer is set up as a location with transportation lanes pointing to the location as required.
In this way, DP integrates the VMI forecast, while SNP monitors the stocks at the VMI location
and suggest replenishment quantities. From a process point of view there is little difference
between an internal company transfer (e.g. manufacturing plant to distribution center) and the
VMI replenishment process.
Understanding

The VMI process is part of the Collaborative Planning approach. Collaborative Planning is
supported by several Internet enabled functions that allow sharing of information via specially
designed Internet enabled transactions. This area covers the on-line communication needs. The

batch transfer of data (e.g. stocks from the customer or VMI sales orders from the vendor) is
supported by various standard EDI interfaces. Two important EDI message types are; EDI 830 to
transmit forecasts and EDI 852, which is used to collaborate on product stock and movement
data. The data received by APO is processed by a BAPI. The BAPI is a program routine that picks
up the data from the interface and updates the APO internal tables accordingly. This ensures easy
implementation and data consistency within APO. The process flow is in principle the same,
irrespective of the choice of communication method, on-line or EDI.
A simplified VMI process flow is as follows:
Create Forecast in Demand Planning
Received from Customer (EDI)
Created with Customer (On-line Collaboration)
Release Forecast to Supply Network Planning
Creates Forecast Demand in Supply Network Planning
Define Safety Stock Levels (Basic or Advanced)
Define Target Stock Levels (if SNP Optimization is not used)
Define Reorder Point Procedures (if SNP Optimization is not used)
Update Customer Stock Level
Received from Customer (EDI)
Run Distribution Planning
Supply Network Planning (Heuristics or Optimization)
Deployment (Heuristics or Optimization)
Transport Load Builder (TLB)
Create VMI Sales Order in R/3 based on TLB order (automatic process)

3.9.4.1

Special VMI Functionality

This section deals with functions and definitions that enable specific functionality required by
VMI. Some of the described functions might also be of interest for non-VMI scenarios.
The document flow for the VMI scenario within APO is very similar to that of the normal
replenishment (non-VMI) flow of events. The following differences exist:

The VMI order type of the transportation order differs to that of the non-VMI order type at
the shipping location. The order types used are as follows.
ED for SNP VMI sales orders
EH for Deployment VMI sales orders
EK for TLB VMI sales orders

The SNP VMI sales order cannot be published to R/3.

The creation of VMI sales orders are initiated in APO. Either the Deployment or the TLB
VMI sales orders (or both) are used to create sales orders in R/3. This can be defined as part
of the APO customizing.

Understanding

276

The type of synchronization between Deployment and/or TLB VMI sales orders and their
counterpart in R/3 can be set independently from the non-VMI orders to synchronous, batch,
or on request.

Table /SAPAPO/SNP13 determines the R/3 order type used when creating the sales order in
R/3. There is no transaction in the IMG that allows the maintenance of this table. Use the
transaction SM30 to change settings if this is required.

The VMI location master must contain information regarding the Sold-to-Party as well as the
Sales Organization, Distribution Channel, and Division. All this information is on the VMI
Customer tab and is required to create the sales order in R/3.

The VMI sales order that is created in R/3 returns its order number back to APO, where it
updates the TLB VMI sales order.

VMI sales orders cannot be seen in the key figure Sales Order but in the key figure
Distribution Demand TLB Confirmed.

All safety stock methods, including the Extended methods, can be used at a VMI location.

Two forecasts can be released from DP to SNP. This is the base forecast, which is stored in
orders of category FA and the promotion forecast, which is stored in orders of category
FB. Order category FA is part of the category group DF1, which is linked to the key
figure 9ADFCST, and order category FB is part of the category group DF2, which is
linked to the key figure 9APFCST (all definitions as in the standard delivered system).

Forecast consumption should, although technically possible, not be activated at a VMI

location. The reason is that no sales orders are created at a VMI location. Sales orders are
only created at ship-from locations such as distribution centers but not at ship-to locations
such as a customer. Sales orders from a VMI location are controlled from the VMI customers
own OLTP system and reduce the forecast at the VMI location via the next forecast update
transmitted to the APO system.

Forecast consumption must not be activated for the requirement class (ATP check mode) used
by VMI sales orders. This is the case in the standard delivered system. VMI sales orders are
created by APO based on the VMI locations forecast but at another location (e.g. the
delivering distribution center). Thus the location where the VMI sales order is created does
not have any forecast that can be consumed.

The SNP Optimizer considers the VMI requirements at the VMI location the same way as any
other independent requirement at a distribution center. The forecast or corrected forecast
penalties apply, not the sales order penalties.

The VMI promotion lead-time (defined in the product master SNP2 tab) has a similar function
as the Target Days Supply field. It supports the calculation and building up of two separate
target stock levels, one based on normal demand and the other on promotion demand. The
VMI promotion Lead Time is used to stipulate the number of workdays for the calculation of
the target stock level required for all VMI promotion demand. The definition of the VMI
promotion lead-time ensures that enough stock is available to cover promotions at a VMI
customer. For normal demand, the target stock level is additionally calculated according to the
Target Days Supply setting. The SNP Optimizer does not support the use of the target days
supply and consequently neither the use of the VMI promotion lead-time.

A separate planning book for use in VMI environments is included in the standard delivered
APO system. One of the main differences compared to the standard planning book is that in
the VMI planning book uses a different approach for calculating the target stock level.
In a non-VMI environment the target stock level is based on the entire forecast demand,
which is released from DP into the order category FA. This order category is used in
conjunction with the product master defined target days supply to calculate a target stock
level in the

Understanding

277

products base unit of measure. The final target stock level is saved in the key figure with the
technical name LAGRZ.
In a VMI environment the base target stock level is calculated using the forecast demand
excluding VMI promotions. This forecast is released from DP into the order category FA.
This order category is used in conjunction with the product master defined target days supply
to calculate a base target stock level in the products base unit of measure. The base target
stock level is saved in the key figure with the technical name LAGRD.
A second forecast demand representing the VMI promotion demand is released from DP
into the order category FB. This order category is used in conjunction with the product
master defined VMI promotion lead time to calculate a VMI promotion target stock level
in the products base unit of measure. The promotion target stock level is saved in the key
figure with the technical name LAGRP.
These calculations are very flexible as they are not coded in the programs directly but are
carried out in the SNP Interactive Planning transaction by means of macros. The VMI
promotion Lead Time is displayed as a field in the VMI Planning Book only (but could
obviously be added to any other planning book).

The VMI purchasing group (defined in the product master SNP2 tab) is used to group
products according to criteria defined by the VMI customer. If deployment order priorities are
calculated the field can be used to sort deployment orders within a TLB order. This can for
example facilitate a grouped loading of products. In this case deployment VMI sales orders
are allocated to TLB VMI sales orders based on the following sequence:
1
Delivery Date
2
Priority
3
VMI Purchasing Group
This functionality could easily be used for non-VMI orders accordingly.

The customer material (defined in the product master SNP2 tab) supports customers using
their own product number and not the one used by the vendor. This definition can then be
used when exchanging EDI data with the VMI customer.
The field is always available for input and can also be used for example where the location
reflects a vendor that might use an own product number. Obviously it does not make sense
defining a customer product number if the location reflects for example an own
manufacturing plant or distribution center.

Understanding

3.10

278

Supply Chain Monitoring

In order to efficiently manage the supply chain network, it is required to use sophisticated tools
that monitor various aspects of the network.
The most important aspect is the principle of exception-based management whereby the system
generates messages alerts depending on predefined events and levels. The planner can then,
based on these alerts, react and drill down to the root of the problem. The Alert Monitor is the tool.
Another requirement is to provide information on all supply chain objects in an easy to read
format, which should include the use of graphical displays and drill down facilities. Hand-in-hand
with this requirement goes supply chain quality management based on company-defined
performance indicators. The Supply Chain Cockpit is the tool.
Planning results need to be continuously monitored and compared over time to ensure that no
quality creep develops. Company-specific quality standards for planning need to be maintained.
The Plan Monitor is the tool.
The supply chain has many participants and objects. Communication is vital. Justification of
decisions needs to be recorded as and where required. This is particularly true in the forecasting
area where manual changes might be applied. Notes Management is the tool.

3.10.1

Exception Based Management

Exception Based Management deals with the definition of situations that require attention, the
person who deals with these situations, and about possible actions to overcome the undesired
exception. It requires a tool that monitors these conditions either continuously or on request. Once
the user is notified, the problem is made visible together with other required information. Based
on this information, the appropriate business process can be initiated or a transaction can be called
to resolve the situation if possible. This is referred to as drilling down to the root of the problem.

Alert Types
The user is notified of the exception by means of an alert. APO offers various predefined alert
types for the alert application areas; Production Planning and Detailed Scheduling, Transport
Load Builder, Vehicle Scheduling, and Global ATP. These alert types are system predefined
and can be activated as required. No additional alert types can be defined for these application
areas. For Demand Planning (DP) and Supply Network Planning (SNP), also referred to as
Supply and Demand Planning (SDP) various alert types are delivered with the system. The
user can modify these alert types as required (assuming the authorization level allows this)
and even new alert types can be added. All delivered and custom written alert types use
macros, which are created and maintained in an interactive way without using a specific
program language. Although by far more complex, these macros can be compared with
macros that can be created for example in Microsoft Word or Excel. For further information
regarding the creation of macros refer to the section Advanced Macros.

Understanding

279

Alert Thresholds
Some alert types require the definition of thresholds while others do not. Let me give two
examples. In DP we can find an alert type that warns the planner that a forecast run could not
be carried out. No threshold value is required as this is either true (alert) or not (no alert). An
alert type that requires a threshold is the capacity over-utilization alert. The default value for
this threshold is 100%, meaning that any situation that leads to a capacity utilization of more
than 100% causes the generation of an alert. This might not always be desirable, and for this
reason up to three threshold values can be defined for this type of alert.
Threshold level 1 (e.g. set to +10%) leads to the least severe alert of type Information.
Threshold level 2 (e.g. set to +30%) leads to a medium severity alert of type Warning.
Threshold level 3 (e.g. set to +50%) leads to the most severe alert of type Error.
In this context the word error does not refer to the usual interpretation of this word, it
merely describes a highly undesirable situation. This fine-tuning of alert types is an option
and if no threshold values are maintained the system uses for each alert a predefined alert
severity level (1 to 3) whenever the alert condition is detected.

Alert Application Area

Alert types are logically grouped into alert application areas. Each of these areas represents a
certain area in the business and they generally coincide with the APO modules.
Forecast
Forecast alerts are created within Demand Planning and notify the user mainly of
situations where forecast error values (e.g. MAD) are outside of a defined range. These
alert types are Macro Alerts.
Supply and Demand Planning
Supply Network Planning creates the alerts in this application area. Excluded are alerts
from TLB and Deployment, which are in another application area as they are not macro
alert types. These alert types are Macro Alerts.
Transport Load Builder
In this group all alert types that refer to Transport Load Build or Deployment can be
found. This includes alert types that notify the user of situations where Fair Share Rules
where applied.
Production Planning and Detailed Scheduling
Any alerts that are generated during the finite scheduling of production orders are in this
group.
Vehicle Scheduling
The alerts in the Vehicle Scheduling group are generated with the TP/VS module of APO.
Global ATP
Alerts in this group refer to problems encountered during the availability check. These
alerts can, as an exception, only be generated in the active planning version (000).
In addition to these APO generated alerts it is possible to view the R/3 MRP messages, if this
function is enabled in the R/3 core interface (CIF).
R/3
Messages created in a linked R/3 system can be viewed in the APO alert monitor, if this
function is enabled in the R/3 interface and an R/3 alert profile is created. These alerts
(messages) can only be viewed in the alert monitor. R/3 alerts are always linked to the
active panning version (000).

Understanding

280

Alert Profile
Alert Profiles combine individual alert types of the same alert application area, they are userindependent. Multiple alert profiles can exist for the same alert application area but any alert
profile can only contain alert types of one alert application area. The alert profiles are
allocated in a separate step to specific transactions. Which alert profiles, with their inherited
alert application area, that can be allocated to a transaction depends on the transaction from
which the alert monitor is called. An exception is the possibility to call the alert monitor
directly from the menu tree structure or via the Supply Chain Cockpit. In both cases alert
profiles of all alert application areas can be allocated.
As part of the alert profile definition the selection of specific data objects can be carried out.
It is for example possible to define for which products the alert types of the alert application
area TLB should be created. This object selection restricts the generation of alerts to those
objects defined in the selection. The object selection is an option but must be carried out if the
Alert Monitor is called directly from the menu structure (see below).

Alert Monitor Settings

The alert monitor settings provide the alert monitor with all information required to generate
alerts. They are used only in cases where the alert monitor is called directly from the menu
structure and not from another transaction. In this case the calling transactions (e.g. the
Supply Chain Cockpit) cannot determine for which data objects (e.g. products) the alerts need
to be generated. The alert monitor uses the data object restrictions that can be defined in the
respective alert profiles. Should, for example, alerts be created for all products and viewed in
the Alert Monitor directly without going through another application, the product selection
should be defined in a way that it includes all products. Failing to do so results in a situation
where no alerts are generated whatsoever.
The same principle applies to the planning version for which alerts should be generated.
When accessing the alert monitor directly from the menu structure, it is required to define the
planning version in the alert monitor settings. When accessing the Alert Monitor from any
other transaction, the system uses the master data environment of the respective calling
transaction to determine for which alert objects (e.g. products) the alerts have to be shown.
The graphic below provides an overview of the relations between alert type, alert profile, alert
application area, and alert monitor settings.

Understanding

281

Ale rt M

onitor

Al e r t Ap p l i c a t i o n

Settings
Are a

Ale rt Ty pe
Threshold

Forecast
1

1 - Inform ation

Threshold

2 - W

Threshold
Ale rt Ty pe

arning

3 - Error
2

Al e r t Ap p l i c a t i o n

Are a

SDP

Al e r t Ap p l i c a t i o n

Are a

TLB

Al e r t Ap p l i c a t i o n
Al e r t Ap p l i c a t i o n
Al e r t Ap p l i c a t i o n
Al e r t Ap p l i c a t i o n

Are a
Are a
Are a
Are a

PP/ D S
VS
ATP
R/3

Graphic 93 Alert Structure

Alert Favorites
APO supports the definition of various combinations of alert settings. If a planner has for
example two different areas in which he or she works, it might be helpful to easily switch
between two or more settings combinations. All the setting IDs that a user can use is visible in
the Favorites drop-down list.
Each user has automatically got a favorite with the name blank (no name). This is a socalled private label, as it is only visible by the respective user. Each user has got such a
private label but they are different per user. Private labels do not have to be included into the
favorites; they are there by default. Alternatively public labels can be defined. A public label
is any setting with a name other than blank. Any user can use public labels irrespective of
who has initially created them.

Alert Object
The alert object is the data object that is monitored according to the alert type definition and
threshold. Alert objects can for example be products or resources.

Understanding

282

Alert Hierarchy
Hierarchies are used to display alert objects in a predefined structure and to stipulate the drill
down path. The system has a predefined hierarchy per view in the Alert Monitor. It is also
possible to define user specific hierarchies if required.

Alert Horizon
The system creates alerts based on the comparison of threshold values with the actual
situation of the alert objects as stored in the database (database alerts) or as seen in interactive
planning (dynamic alerts). It does so only for a specified time period. This time period
(interval) can be fixed, relative, or according to a planning profile (also called time bucket).
When calling the Alert Monitor directly from the menu tree structure only fixed or relative
time interval settings are possible.
Alerts should only be generated for such time periods that are of real interest to the planner.
This helps to have better response times when starting a transaction or refreshing alerts.

Required Settings
The following graphic provides an overview of the various Alert Monitor elements discussed
so far.

Alert Profiles

Alert

Application Area

Forecast
SDP
TLB
PP/DS
VS
ATP
R/3

Graphic 94 Alert Monitor Elements

As can be seen above, the allocation of the alert profiles is either carried out in the user
settings of the respective transaction or in the transaction specific settings for the Supply
Chain Cockpit and the Alert Monitor itself. The following table provides an overview of
transactions that can display alerts and the required settings to achieve this.
Understanding

Transaction
Definition
Alert Monitor
Settings
Alert Profile Application
Horizon
Object Selection
Planning Version
Supply Chain Cockpit
Settings
Alert Profile Application
Horizon
Object Selection
Planning Version
Interactive DP
Settings
Alert Profile Application
Horizon
Object Selection
Planning Version
Interactive SNP
Settings
Alert Profile Application
Horizon
Object Selection

Planning Version
Understanding

Transaction
Definition
Product View
Settings
Alert Profile Application
Horizon
Object Selection

Planning Version
Planning Board
Settings
Alert Profile Application
Horizon
Object Selection
Planning Version
Table 64 Alert Monitor Definitions

Generation of Alerts
Alerts are generated by several planning transactions with or without the user having to
initialize the alert creation. Often it is required to initiate the creation of macro alerts
individually but other non-macro alerts are created automatically. When using the SNP
standard delivered planning book it is required to run the macro that creates a macro based
alert. Macros are not created without a planning task being carried out. During the
production planning using the product view transaction, for example, the respective PP/DS
alert types are generated and displayed according to the user profile.
In order to view macro alerts it is required to run the macro and to also refresh the screen
while in the SNP interactive planning transaction. No duplication of macros occurs should an
alert-generating macro being run twice.
It is required to delete macros that relate to situations in the past, as this is not done
automatically. Alerts should be acknowledged rather than deleted. If an alert is deleted
although the situation that caused the alert generation has not changed it will be re-generated
again during the next planning activity. Acknowledging the alert marks the alert but does not
delete it. Filters can be set in the alert monitor so that acknowledged alerts are not displayed.

Display of Alerts
Within APO, various applications can display alerts. The Alert Monitor as well as the Supply
Chain Cockpit can display alerts of all application areas. The other applications display alerts
according to their primary usage. The actual alert situation is evaluated whenever a
transaction

Understanding

285

is called up. In order to see alerts that might have materialized as a result of planning
activities while being in the transaction, it is required to refresh the alert situation. This is a
task which requires manual activation from the user (e.g. press the Refresh pushbutton).

Alert Propagation
The alert monitor always checks for alert conditions of the object (e.g. a production order) as
specified in the alert profile. It is also possible to check all those objects that are pegged to
this object (e.g. the procurement order of a component needed in the production order). This
additional check is performed on all lower level objects that are pegged to the initially
checked object, irrespective of whether an alert exist on the higher level or not. In this way
the alert monitor might reveal that an order that appears to be problem free cannot be carried
out because of a problem on a lower subsequent level.
Alert propagation is a very resource intensive task and requires that orders be pegged with
each other (see the section Pegging). Pegging of orders is only done within PP/DS and
subsequently alerts can be propagated only within the PP/DS alert application area. It is still
an option and should only be switched on if required. Alert propagation can be activated
separately for receipt and requirement elements.
Without Alert Propagation
When viewing the finished product, no alerts can be seen as the finished products
demands are covered by its production orders. The fact that one of the production orders
cannot be carried out due to a shortage of a component is not immediately visible (no
alert on finished product level). This means that an alert-free product or production
order might still have alerts on a lower level such as a component or resource.
With Alert Propagation
The finished product will show an alert that is caused by the non-availability of a
component. In this way the planner immediately sees that a problem will occur with the
product. This means that an alert-free product or production is also alert-free
throughout all lower levels.

Dynamic and Database Alerts

Dynamic alerts are such alerts that are generated during a planning run that is not saved yet.
They are dynamically based on the current planning situation. If the plan is saved, the alerts
are saved with the plan and change to database alerts. There is no functional difference
between the two; the difference is what plan they refer to, the saved one or a temporarily
visible plan.
Dynamic alerts are automatically deleted if during the interactive planning a new data
selection is elected without saving the planning result or when exiting the planning
transaction without saving.

Automatic Messaging
The Automatic Messaging feature allows the sending of alerts to a specified user address. The
address could either be an individually defined e-mail address, the e-mail address as specified
in the user master record or the mailbox of SAP-Office.

Days Supply Alert

The Alert Monitor can create within the PP/DS alert application area an alert if the number of
days supply for a product is exceeded. The target days of supply for all products is defined in
a profile. In this profile all ATP categories are defined that need to be taken into consideration
when calculating the total supply. The Alert Monitor takes this default value if no other profile

Understanding

286

is defined here. The default days supply profile is displayed automatically in the alert profile.
Specify here another alternate days supply profile if the default profile should not be used.
Additionally a second and third days supply profile can be defined here. The principles and
setup are the same as explained above.

Excess Coverage Alert

The PP/DS Excess Coverage alert is the counterpart to the Days Supply alert that can be
displayed in the Alert Monitor. The PP/DS Excess Coverage is defined as a percentage. It
indicates the excess between the planned requirements and planned receipts (calculated per
day). It can be used to trigger push production when displayed in the alert monitor.

Alert Restrictions
It might not be desired that alerts be generated for all data objects like products or resources.
Various restrictions allow specifically including or excluding such data objects for which
alerts should be created or not. The possibilities for these restrictions are different per alert
application area. Imposing of restrictions generally is an option but is required when calling
the Alert Monitor directly from the menu structure. The table below depicts per alert
application area the possible restrictions.

Selection Group
Restriction Object
Product
Products
Locations
Production SNP Planner
ATP Category
Resource
Resources
Locations
Transportation Lane
Source Location
Target Location
Transportation Planner
Transportation Method
Transportation Method
InfoCube
Understanding

287

Selection Group
Restriction Object
InfoCube Characteristics

Planning Books
Time Buckets Profile
Allocation
Product Allocation Group
Table 65 Alert Restrictions

Alert Deletion
This is a function that can be carried out for example from the Alert Monitor Settings
transaction. The upcoming screen allows the deletion of all or selected alerts. Various
restrictions can be used to limit the scope of the alerts to be deleted. Restrictions can be for
example the alert type, the alert priority, or the time it was created.

Alert List
A list of alerts can be found in the Resolving section.

3.10.2

Supply Chain Information Retrieval

The graphical presentation of data has come a long way since SAP released their first R/3 system.
APO uses a very appealing environment for most of the daily monitoring and data retrieval tasks
to be performed. It is called Supply Chain Cockpit, and indeed out of this cockpit, a whole lot of
activities can be performed. The Supply Chain Cockpit guides the majority of tasks and offers
direct access to the most important planning tasks.
The Alert Monitor is also incorporated and provides the user with information regarding any
problem in the supply chain irrespective of a specific source. The upcoming alerts are grouped
according to the APO area (e.g. alerts for Demand Planning) and can further be filtered so that in a
multi-user environment only the responsible planner receives specific messages.
For more information regarding the Supply Chain Cockpit, refer to the section Supply Chain
Cockpit.

3.10.3

Notes Management

Understanding

288

In the APO interactive planning transactions that are used in Demand Planning and Supply
Network Planning it is possible to capture notes alongside any historical or forecast values. The
free-text-notes are edited using the SAP editor. Different notes can be captured per planning
version, time period and key figure. Additionally and specifically for Demand Planning, notes can
be kept at any level of aggregation. Let me give an example. The planner makes a note of the
forecast value of a certain product and locks the forecast value. Later, the product group, to which
this product belongs, is planned separately. The planner now adds a new note to the product group
and can at the same time quickly drill down to the note of the single product.
Maintenance of notes is carried out in the respective interactive planning screens only. A note can
be attached to cells that are open for editing. Once a note has been created for a certain cell, its
color changes to yellow, indicating the existence of a note. The note contains administrative
information that shows amongst other information the language and up to three titles as well as the
date, time and user ID when created and last updated.
Notes can be used as reminders for the planner or, with limitations, to communicate with other
planners. They can support the supply chain monitoring process.

Preparing

289

4 Preparing
In order to use any system, it must be set up in terms of system definitions and required data. After
this has been accomplished, the system can be used to fulfill its generic task which, for APO, is
planning and optimization of the Logistics Chain. Compared to an OLTP system such as R/3, the
emphasis on system definition, also called system customizing, has taken a step back and more
time is spent on data setup. The most challenging task when using highly sophisticated
optimization tools is to define the master data environment, namely penalties and costs, in such a
way that the result of the optimization is reliable and reflects a good approximation of the reality.
In any APO implementation it is therefore required to spend a considerable amount of time and
effort in the preparation of the data environment. This is also true for a live system and the word
master data has to be revisited, as in a proactive and dynamic planning system there is nothing
like master data that does not change at all or only infrequently.
The Preparing section is subdivided according to the following structure:
Planning Environment
Before any planning activity can be carried out in APO it is required to define the planning
environment. The planning environment differs between the APO modules and specifically
within the supply network planning area various possibilities exist, each of them specialized
to support a specific planning need.
This section also covers the areas of data storage principles, which is the same for all APO
master data but is at the same time vastly different for the transactional data depending on the
APO module the data is stored for.

System Environment
This section provides background information covering the technically orientated subjects
such as the setup of the graphical user interface and the data exchange with other systems.

Data Environment
While the planning environment section primarily dealt with transactional data, this section
concentrates on the setting up of master data required to carry out the respective planning
tasks in APO. An introduction to the maintenance of master data and profiles is given here
accompanied by various customizing settings that are required to run the system.

Transaction Environment
Besides needing to know how to operate and use transactions, it might also be required to
customize the appearance of some transactions. This is dealt with in this section.
Preparing

4.1

The Planning Environment

The planning environments used by the APO modules can be characterized according to their
data storage principles and to their graphical representation in the form of the transactions that
can be carried out.

The Data Storage

The data storage concepts used are the time series based storage used primarily in the
forecasting area and the order based storage of data used by production planning and
transportation planning. Within supply network planning a hybrid of both is used.

1.

With time series based data storage a single value can be stored per period. An example
is the product forecast for specific day (e.g. 100 pieces on the 19 th of February 2001).
Only one single value per period exists.

2.

The object for order based (or discrete) data storage is the individual order. An example
would be a production order for a specific product (e.g. 300 pieces of product A on the
4th of May 2001). With this concept multiple values (orders) for the same period can
exist.

3.

A hybrid of these methods is the storage on order level with subsequent accumulated
display on period level. Should for example two production orders for the same product
exist for the same period, the time series displays the total of both orders. The details of
this time series, the individual orders are nevertheless kept in the system and used for
processing.

The use of the data storage methods described above is detailed in the following table.

Process
Supply and
Demand
Planning

Preparing

Process

Manufacturing

Order
Fulfillment

Table 66 Module Specific Data Storage

(

Promotions are not stored as orders but with a unique key per promotion. Various
promotions can exist for the same period, as it is the case for example with
production orders.

The table above refers to the main concept of data storage for the respective APO modules.
In some specific cases it might well happen that some data is stored in a way other than
stipulated above. Hand-in-hand with the data storage concepts goes the systems capabilities
to link demand and supply orders. This is referred to as Pegging and dealt with in a
special section.

The Transactions
Having seen the various possibilities for data storage used within the SNP module of APO it
might be a surprise that the user interface for Demand Planning and Supply Network
Planning is the same despite the fact that not only different tasks are accomplished but also
different data storage methods are used. While working with APO, one will sooner or later
see the expression Supply and Demand Planning with the abbreviation SDP. This can a
bit confusing as there is not really any function with this name nor is there a clearly defined
module. The term supply and demand planning is used as a grouping for the demand
planning area (excluding promotion planning) and the supply network planning area
(excluding the transport load builder and capable-to-match functionalities). In this way SDP
combines all such areas of DP and SNP that use the data storage principles time series or
hybrid.
More important for the user, SDP uses a common user interface, which is the highly
customizable planning book with its freely definable data views.
The DP specific planning book can include a special view for promotion planning,
which has a SAP predefined layout that cannot be changed like the rest of the planning
book.
The same applies to the SNP specific planning book, which can be used to carry out
transport load builder functionality.
The capable-to-match functionality can be used within a planning book.
In all the above three cases, it is possible to display the result of the respective planning
steps in the planning book. The production planning and detailed scheduling module as well
as the transportation planning and vehicle scheduling module not only share rather long
names but also the way the data is stored. It is order based and the transactions used might
initially not appear to be similar but they are in some cases even the same. An example is
the finite

Preparing

292

scheduling of manufacturing resources in PP/DS and the finite scheduling of trucks in TP/VS.
The user interface is precisely the same.
While it always makes good sense to understand the entire system, it is not always
recommendable to change system settings even if this is possible. We will see this specifically
when discussing the topic Planning Area. The aim of the following sections is to provide a sound
understanding of the system and, where recommendable, how to customize the system according
to specific business needs. APO with its release 3.0 is in some type of transition process where
certain definitions can be done really flexible but at the same time the system will only allow very
specific settings. Flexibility is build in but not fully exploitable at the moment.

4.1.1

The SDP Planning Environment

The planning environment used in Supply and Demand Planning supports all planning functions
of Demand Planning as well as Supply Network Planning. Planning in DP is time series based and
that in SNP is order and/or time series based. Common tools enable an easy maintenance of both
areas. This includes, as will later be seen, a common user interface for both planning tasks. It is
called the Supply and Demand Planning Interactive Planning transaction. What drives the
difference between the two planning tasks are the settings per master planning object structure.
This master planning object structure in turn determines the usage of the planning areas it is
attached to. A planning area is characterized as being used for Demand Planning or Supply
Network Planning. The main difference for the user is the appearance of the planning book. The
planning functionality is dependent on the planning area it is based upon and some additional
settings.
The DP planning environment is made up of four main building blocks that enable the user to
perform the forecasting and promotion planning tasks. They can be described as follows:

Master Planning Object Structure and Planning Area

These are the main repositories of definitions for DP. They determine how data is stored (in
time streams) and which functionally is available.

LiveCache and InfoCube

LiveCache and InfoCube are used to store data. The use of an InfoCube for historical data is
optional, as the data could also be stored in liveCache. Data in an InfoCube can only be read
but not changed.

Forecast Profiles
The Profiles allow setting defaults that define how the standard forecasting tools are used
within the specific users environment. They provide standardized rules on how to use the
data provided by the system.

Planning Book
The Planning Book is the interface between the system and the user. It is configurable to
allow concentration on the data the user really needs. Custom specific rules (Macros) can be
defined here as well. It provides the definitions of what data is visible and which macros are
used.
All these definitions come together in the Supply and Demand Planning Interactive Planning
transaction. This is depicted in the picture below.

Preparing

293

Info
Cube

Time Bucket Macros

Selection ID

Visible
Time Stream

Used
Time Stream

Planning Book

Forecast Profiles

Planning Area
Available

Selected Data

Time Stream

Data
Tree Structure Planning Version
Characteristics & Key Figures

Work Environment

Model Environment

Data Environment

SDP Interactive Planning

Forecasting
Life Cycle Planning
Promotion Planning
Alert Processing
Graphic 95 DP Overview
In the following sections we shall go through all of these objects one by one and gain an
understanding on how they work together and what the interdependencies are.
The SNP planning environment is made up of three main building blocks that enable the user to
perform the rough-cut planning and deployment tasks. They can be described as follows:

Master Planning Object Structure and Planning Area

These are the main repositories of definitions for SNP. They determine how data is stored (as
discrete orders or in time streams) and which functionally is available. The order categories
and category groups also play a vital role as they link discrete orders together.

LiveCache
LiveCache is the only method to store data.

Planning Book
The Planning Book is the interface between the system and the user. It is configurable to allow
concentrating on the data the user really needs. Custom specific rules (Macros) can be defined
here as well. It provides the definitions of what data is visible and which macros are used.
Although it might appear that the SNP environment is less complex than the DP one, this is not
true. Fully understanding the SNP environment is a more difficult task than understanding the DP

Preparing

294

environment although the latter requires more activities upfront. There is also plenty of interaction
between the two modules and understanding both is a prerequisite for a successful implementation
and use of APO.

4.1.1.1

Order Categories

APO uses orders to store demand, supply, and even stock information. All these orders are stored
in liveCache and their distinguishing factor is the order category. The order category is also
frequently referred to as the ATP (Available-to-Promise) category. Order categories are not used
within Demand Planning. APO predefined tables and system constants determine the order
categories relation to the R/3 MRP elements and stock categories. These definitions are the main
enablers for the seamless integration of APO and R/3, as it is not required by the implementing
organization to develop the links of these elements across the systems.
Order Category
AG
BM
CB
CC
EA
FA

Description
PP/DS Purchase Requisition (Receipt)
Sales Order
Safety Stock
Unrestricted Use Stock
SNP Purchase Requisition (Receipt)
Product Forecast

The above examples show the categories of some commonly used order categories. The definition
of the order categories is system predefined and cannot be changed. What can be changed are their
names although this makes it difficult to read some APO help texts that refer to the order types by
their names.

4.1.1.2

Category Groups

A category group is a group of order categories that can be linked to a key figure. Order categories
are grouped into category groups to enable various system functions/calculations. Category groups
are not used within Demand Planning. The same order category could be part of several category
groups. Some category group names are explicitly defined in programs and must not be deleted
although they could be changed. The category group ST1 is an example of this. It is used to
define the stock that is used during SNP, Deployment, and TLB planning and also when
displaying the stock in the SNP interactive planning transaction. Other examples are the category
groups ATR and ATI all of which are linked to locations in the location master. Deployment
and TLB use these two category groups that determine which demand and supply elements are
considered when performing Deployment or TLB planning. The demand and supply elements are
again represented by order categories. As the category groups for deployment and TLB are linked
to the location master, different definitions can be used per location.
Category Group
ST1
Preparing

PS1

295

In the first example, the category group ST1 contains the two categories CB and CC. The
second example shows the category group PS1, which consists of the two categories AG and
EA. Note that purchase requisitions created by SNP and PP/DS are both of type AG in the
standard delivered system (default). They could be changed to EA for SNP.
All category groups required for a functional system are predefined and part of the standard
delivered system but could be changed to suit specific requirements.
The order category and category group definitions are not required when using time stream based
data storage. In this case data is stored directly per key figure and time period and not in discrete
orders that are identified by their order types. Time stream based data storage is used, for example,
in Demand Planning and in conjunction with the SOP planning approach.
Whether a key figure is defined for time stream based data storage or as an accumulator of
discrete orders is defined via the key figure semantics. The category group is the linking element
between the discrete order and the key figure. According to its settings, the system accumulates
orders to make up a key figure value. The key figure and not the category group is used in cases
where the planning transaction needs to create an order for a specific key figure. It then reads the
order type that is maintained in the key figure and uses this value to create an order. For this
reason it is mandatory to always link the same order type to a specific key figure if the category
group is maintained more than once in a planning area.

4.1.1.3

Planning Area Environment

The way APO uses planning areas and how they are structured is of vital interest to all those who
really want to see behind the curtains of the system. The built-in flexibility in this area is
enormous and requires a lot of effort and time from those who want or need to understand the
concepts. This section provides an introduction to the concept of the planning area and the main
elements that are used to create the planning area. The elements covered in this section are as
follows:

Planning Area

Key Figure

Characteristic

Master Planning Objects Structure

Navigational Attribute

Aggregate

Buckets Profiles

Planning Area and Planning Version

Planning Area and Supply Chain Model

I would like to stress that in my mind it is very useful for an APO implementer to understand the
relations that are explained in this and the following sections. There is certainly no need for the
average user to try and understand these subjects. At the same time I must also warn everybody
rushing to the system and trying to change settings. This is very close to the heart of the system
and a small mistake can have system wide implications that might require lots of work and time to

Preparing

296

rectify. It is not without reason that SAP has flagged several tables SAP Data or made them
Display Only. I mentioned before that SAP build with release 3.0 more flexibility into these
definitions but some changes that can be performed with ease have impacts on other areas in the
system that are not always easily visible if at all.
A detailed description how to create an own planning area together with a personalized planning
book is included in the My First Plan section.
Planning Area
Planning areas are used for demand planning and supply network planning. Both modules can
work with one or several planning areas. The impact of using more than one planning area is
different depending not only for which module this is done but also for which functional area
within the module. The planning area is a logical construct that defines in essence two things.

Characteristics according to which data can be stored

Key figures, which contain or represent the stored data

This is a very similar, and actually the same definition, as the one given for an InfoCube used in
Demand Planning. This obvious communality of demand planning and supply network planning
principles is a new feature that was introduced with release 3.0. Its main idea is to bring those
modules together in terms of technical realization as well as in terms of user guidance and the user
interface. The concept of planning areas is common to both modules and in this context
transportation planning with its area deployment is part of the supply network planning
definitions. As mentioned before, the planning area is a logical construct of characteristics and key
figures. Both elements can be stored for demand planning in an InfoCube or in liveCache
depending on specific business requirements. InfoCube storage is more suitable for large amounts
of data where the access time is not the primary focus. For this reason it is not possible for APO to
write directly into an InfoCube; it can only read data during a planning run. The liveCache
provides extremely fast read and write access, as it is stored in the servers memory (not on a hard
drive). It is therefore best suited for time critical applications such as read and write of
transactional or time stream data during the planning run. Any given planning area used for
Demand Planning can use both methods at the same time. Historical demand planning data is
primarily stored in an InfoCube. Supply network planning data is always stored in liveCache. In
addition to these storage possibilities some key figures are stored in tables. These key figures are
referred to as database key figures.
APO orders are not part of a specific planning area but they can rather be used in conjunction with
one or multiple planning areas. Various planning areas can exist, each possibly grouping the orders
in different ways. This is possible, as the SNP planning area is a set of rules how to combine
orders dynamically as and when needed. The orders as such are always stored individually.
Various planning areas could thus work with the same order at the same time. The orders that are
used in a planning area are stored in liveCache.

Key figures that represent time series based data (e.g. in DP) contain actual data. This
principle is used in demand planning and sales & operations planning.

Key figures that represent discrete orders (in SNP) contain no data but rather a set of rules,
which enables the system to dynamically accumulate the right discrete orders to derive the
total value. This principle is used in supply network planning (sales & operations planning).

Preparing

297

Category groups are linked in the planning area to key figures. This enables a summarized display
(output) of various orders according to their category.
Key Figure
9APSHIP
9ATSHIP
The first example shows the key figure for planned distribution receipts with the category group
linked to it. This in turn links the order categories EA and AG via the category group PS1 to
the key figure 9APSHIP. Whenever this key figure is displayed it will show all orders of both
order types. Temporarily stored key figures (e.g. the key figure Total Supply) are defined in the
planning book only and are not defined in the planning area.
Besides the category groups, single categories are also linked to key figures. A key figure thus
potentially has two links, one to a category group and another one to an order category. The link to
the order category enables the system to write or change orders of specific order types per
category group.
Key Figure
9APSHIP
9ATSHIP
In the first example we link the category EA to the key figure 9APSHIP. Whenever a new
distribution order is created within an SNP planning task the system sees that the newly created
order has to be of the specific order type EA (and e.g. not of type AG). Note that the standard
delivered system is set to AG, which is another feasible solution.
The graphic below depicts the relationships between SNP key figures, category groups and order
categories.
Preparing

Key Figures
9APSHIP

Category Groups
PS1

Graphic 96 Key Figure Relations

Although it is possible to use various planning areas simultaneously within SNP (except SOP) it is
required to understand the following two implications:

Database Key Figures

This type of key figure is stored per planning area and subsequently it cannot be viewed in
any other planning area but the one it was created in. This is the case for example for all time
dependent definitions of safety stock and/or target stock levels.

Link to PP/DS
The global settings for PP/DS require the definition of precisely one planning area. This
definition is used for example when reading time dependent safety stock levels stored in SNP
key figures but also used by PP/DS.
Using more than one planning area in DP (including SOP) results in having various independent
data streams. The result is similar to using one planning area and various planning versions.
Within Demand Planning, data described in the planning area can be stored in liveCache (as it is
the norm for SNP) or alternatively in a special construct called InfoCube. Data stored in an
InfoCube can only be read and APO cannot update an InfoCube while performing the planning
tasks. This means that historical data key figure could be in an InfoCube but not the forecast data
key figure. For more details see the section InfoCube. When creating a planning area to work
together with an InfoCube it is advisable that both have the same characteristics. The key figures
defined in the InfoCube are a subset of those defined in the planning area, as some key figures are
stored in liveCache. Periodicities are defined for an InfoCube by means of special time
characteristics. The planning area periodicities are defined using the storage buckets profile. Both
definitions must be aligned if an InfoCube is used to store some of the demand planning data.

Preparing

299

Key Figure
The key figure is one of four Info Objects, the others being the data, unit, and time
characteristics. In the planning area only such key figures are defined that are stored either in
liveCache or in an InfoCube. Key figures that are used temporarily when working in the
interactive SNP or DP planning transactions are defined in the planning book only. These
temporary key figures are defined together with the macros using the Macro Builder transaction.
Key figures that are stored in tables (database key figures) are also not defined in the planning area
but in the planning book. There are on the other hand usually several key figures that are not
displayed in a planning book although being part of the planning area. They are created and stored
to either serve specific macros or to speed up data retrieval.
All data in the key figures is related to the characteristics of the planning area. The combination of
characteristics is the key of the data record, the key figure is the actual data record related to that
key. The key figure is always related to a unit of measure, which is for example the products base
unit of measure or the planning areas base unit of measure.
Characteristics
Location/Product/Time
This is an example where in the SNP Interactive Planning transaction, the user selects a location
product in the data shuffler. By doing so the two characteristics location and product are
selected. The system then displays per characteristic time (e.g. per day) the key figure
Production with the appropriate quantity and unit of measure.
Key figures are definitions, referred to as data containers and not the data elements as such
whenever the discrete data storage method is used. When these key figure definitions are linked to
a planning area, they receive a meaning by defining various parameters. Amongst these definitions
is the key figure semantics. The key figure semantics identifies a key figure that represents
discrete orders or as a time stream based key figure. This information is vital for all read and write
operations. The key figure semantics attached to key figures of different planning object structures
may vary from one planning object structure to the next.
Key Figure
9APSHIP
9APSHIP
All key figures with a semantics value of 00 are time stream based key figures!
In situations where APO has to create new orders it also requires some information of the socalled order type. This order type identifies APO created orders for example as production or
external procurement orders. The key figure order type attached to key figures of different
planning object structures must not vary from one planning object structure to the next. The order
type 00 is the equivalent to not defined and can be found for the same key figure alongside
with a definition different to this setting 00.
Key Figure
9APSHIP
9APSHIP
Preparing

9APSHIP
Characteristic

300

9ASNPBAS

15

See the separate section Characteristics for more information.

Master Planning Object Structure
In order to simplify the creation of planning areas, characteristics are grouped in the master
planning object structure. This structure contains various characteristics and possibly
Navigational Attributes (see below). Currently, Supply Network Planning requires specific
characteristics to be in each planning area and subsequently these required characteristics are all
contained in a predefined master planning object structure that is used in the standard delivered
master planning object structure. From a technical point of view, each planning area must contain
at least one planning object structure, which is usually the master planning object structure.
The master planning object structure can be flagged to be relevant for several planning tasks
within APO. The flags determine which characteristics are copied automatically into the master
planning object structure when creating it.
Following planning tasks with their corresponding characteristics exist.

SNP Planning

9AMATNR
Product
9ALOCNO
Location
9ARNAME
Resource
9ATRNAME
Transportation Lane
9APPMNAME
PPM Name
9AACTNAME
Activity
Characteristics Based Forecasting
9AMV_PROF
CBF Profile
9AMV_TAB
CBF Table
9AMV_ROW
CBF Row
9AMATNR
Product
9ALOCNO
Location
DP BOM Relevant

9AMATNR
Product
9APPMNAME
PPM Name
The master planning object structure can only be flagged for either the SNP planning task or one
of the other planning tasks.
Planning areas are created based on exactly one master planning object structure. The master
planning object structure also incorporates other planning object structures (called aggregates) to
enable specific system functions/calculations. Aggregates contain a subset of the characteristics
defined in the master planning object structure. The master planning object structure does not
contain any key figures, as they are allocated to the planning area as required at the time of the
planning area creation.

Preparing

301

Planning Area
9ASNP02

The planning area 9ASNP02 contains all characteristics that are defined in the master planning
object structure 9ASNPBAS. Various other planning object structures of which only two are
shown in this example are also defined. The ones shown above need to be in the planning area in
order to link the respective programs (SNP Optimizer and Extended Safety Stock Calculation)
with the required categories and category groups.
Note that the master planning object structure does not contain any key figures. They are linked to
the planning area during its creation. Key figures definitions are used in one or multiple planning
areas. Any key figure that is added to a planning area is shown in the key figure detail view where
it is linked to one or multiple planning object structures.
Navigational Attribute
A navigational attribute is a special characteristic that is assigned to a standard base characteristic.
Navigational attributes allow data to be selected as if they were normal base characteristics. The
difference to a base characteristic is that the navigational attributes do not allow storing data on the
level of a navigational attribute. The usage of navigational attributes instead of normal
characteristics results in a smaller database and an optimized system performance.
Characteristic
9ATRNAME
9ATRNAME
9ATRNAME
The above shows the navigational attributes the characteristic with the technical name
9ATRNAME (Transportation Lane) as it is defined in the standard delivered system. This
definition enables an easy way of retrieving all transportation lanes of e.g. the same transportation
method or the same target location without defining the transportation method as a characteristic.
Note that the data is not stored at this level.
Aggregate
Another type of planning object structures besides the master planning object structure used in a
planning area is the aggregate. Aggregates are defined per master planning object structure and
enable specific key figure aggregations. The aggregated key figures are linked to another variable,
which is finally used by the application. This method of linking key figures is used in Supply
Network Planning. The SNP Optimizer for example uses the definitions of the aggregate
9AMALA and the Extended Safety Stock Planning uses the aggregate 9AMALO. The
interesting aspect is that the usage of these aggregates is not hard-coded in the respective programs
but defined in yet another table. The key figures are linked to variables in this table, which relates
the key figures finally to the applications. Any custom defined planning area should be set up with

Preparing

302

the same aggregates as the standard delivered planning area to ensure that all programs work
without problems.
Aggregates define a higher level of aggregation that is used to store data for the purpose of faster
access. Data attached to a lower level key (lower level characteristic) is aggregated on a higher
level. The key figure assignment (assignment of key figure to aggregate) determines which key
figures are aggregated. Each key figure that is assigned to an aggregate can be seen in the Key
Figure Detailed View together with the aggregate, which is displayed in the column Planning
Object Structure.
Aggregate
9ALORE
9ALORE
The above shows the aggregate with the technical name 9ALORE, as it is defined in the
standard delivered system. It is used to combine (aggregate) all data up to the level of location
name and resource. In order to understand the setup we also need to look at the key figures that are
used with this aggregate.
Key Figure
9ACACON
9ACASUP
9APSHIP
9ASSHIP

Name
Capacity Consumption
Capacity
Distribution Receipt (Planned)
Distribution Receipt (Total)

The four key figures listed above are stored together with all other data on the lowest level, which
is defined in the master planning object structure. In order to have a faster system response, the
four key figures for available and used capacities as well as for planned and total distribution
receipts are added up per location, resource, and (by default) per period. If it is required to retrieve
this information for example during interactive planning, it is much faster to read the accumulated
data than adding up all the data as and when required. Aggregates are a way of organized data
redundancy.
Transaction /SAPAPO/PBSTDOBJ maintains the table with the same name
(/SAPAPO/PBSTDOBJ). This table links per DP and SNP application/function (e.g.
SNP/Optimizer) internally used fields with the key figures as defined in the planning area. This
closes the link between the programs that need to write orders with a specific category. The
implication of this setup is that any key figure can be created and used (those that SAP has defined
and/or others) as long as all planning areas use them in the same way. This is because the table
/SAPAPO/PBSTDOBJ is not dependent on any planning area and a change made there applies to
all planning areas. Note that the table is flagged SAP Data do not change for good reason.
Storage Buckets Profiles
The Storage Buckets Profile defines the periodicity and number of periods used to store the DP or
SNP data. It is linked to a planning area. Typically the storage buckets profile for DP contains the
periods weeks and months and that for SNP days and weeks, which does not mean that other
settings are not possible. It is important to understand that the storage bucket profile determines
the

Preparing

303

way the data is stored in DP and because of that also has an impact on the release of data from DP
to SNP. Furthermore, the definitions in the storage buckets profile impact the aggregation and
disaggregation of data.
Planning Buckets Profiles
The Planning Buckets Profile defines the number and type of periods that can be viewed in DP or
SNP. This profile is linked to a planning book. The planning buckets profile is typically set up in a
way that multiple period types (e.g. days and weeks or weeks and months) can be viewed. The
further away the specific period is from the current day, the more condensed the data is displayed.
This method is also referred to as a telescoping profile. The planning buckets profile determines
the type and number of periods displayed and used by the planning run in SNP. In this instance,
reducing the number of displayed periods also affects the planning precision and the planning run
time.
Planning Area and Planning Version
What is the relation of the planning area to the planning version?
Planning versions are created without any reference to a specific planning area but need to be
initialized. This initialization has to be carried out per planning area the planning version is
intended to be used with. During this initialization process the transactional and master data used
in the planning version are linked to the planning area. The same planning version can be used in
one or multiple planning versions. Note that during the initialization process in DP all possibly
existing data is reset (wiped out). The same applies to all time series based data in SNP but not to
any data that is stored in discrete orders.
Refer to the section Planning Version for information regarding planning versions and their
usage within APO.
Planning Area and Supply Chain Model
What is the relation of the planning area to the supply chain model?
The planning version is linked to exactly one supply chain model. Any supply chain model can
have more than one planning version. The planning version has two legs. One leg is focused on
the transactional or forecasting data and relates the planning version to the planning area. The
other leg is master data focused and relates the planning version to the supply chain model. This
does not imply whatsoever that a certain supply chain model could be used in conjunction with
one planning area only.
The following graphic depicts the relation of planning areas, planning versions and supply chain
models as it is used in SNP. Within DP and SOP no orders are used and the transactional data is
the value of the key figure.
Preparing

P lan n in g V ersio n

Graphic 97 Planning Version Relations

Refer to the section Supply Chain Model for information regarding supply chain models and
their usage within APO.
Conclusion
The graphic below provides a comprehensive overview of the previously discussed elements. The
top of each column shows the element to be maintained and the bottom the tool that is used to
maintain the respective elements.
Preparing

In fo O b je c ts

C h ara c te ristic s C
atalo g

M a ste r P lan n in g
O b je c t S tru c tu re
C h aracteristics
N av ig atio n al
A ttrib u tes

S to ra g e B u ck e ts P
ro file

A g g reg ates
C h aracteristics

S to rag e B u ck et P
ro file

C h a ra c te r is tic s

N a v ig a tio n a l A
ttr ib u te s

S u p p ly a n d
D e m a n d P lan n in g A
d m in istratio n

K e y F ig u re
C atalo g
K e y F ig u res

A d m in istra to rs W o
rk b e n ch

P ro file
M ain te n a n c e

 A ssig n m en ts
S to rag e B u ck et P
ro file

K e y F ig u res
A g g reg ates

S u p p ly a n d
D e m a n d P la n n in g
A d m in istra tio n

Graphic 98 Planning Area Elements

The above overview refers to the objects in a basic planning environment. Depending on specific
requirements, some other settings might be required.

4.1.1.4

Characteristics

Characteristics are used in both Demand Planning and Supply Network Planning. Although the
concept is the same, there are important differences. Characteristics can be seen as field
definitions of a database access key. One or multiple characteristics make up the key of a data
record. The data record as such is the key figure (see below). Characteristics and key figures are
definitions that describe the layout of a logical database. The logical database is the planning area,
which in turn defines where and how the data is stored physically (liveCache and/or InfoCube).
Due to the fact that characteristics and key figures are definitions and not the data as such, they
can be used to describe multiple planning areas.

Preparing

306

The types of characteristics used are also different according to the module (DP or SNP) as well
data storage method (liveCache or InfoCube).

Demand Planning and InfoCube

The data characteristic is one of four Info Objects, the others being the unit characteristics,
the time characteristics and the key figures. The data characteristic, normally referred to
simply as the characteristic, is used to describe key fields such as for example product number
and location. The unit characteristic determines a unit of measure in all cases where a key
figure does not refer to the planning areas base unit of measure for units or currencies. The
time characteristic describes the type of period used (e.g. day or week).

Demand Planning and liveCache

With regards to the characteristics there is one main difference within Demand Planning
depending on the way the data is stored there is no need to define time characteristics when
storing data (key figures) in liveCache. The task of defining the periodicities is taken over by
the storage buckets profile. When storing data in liveCache and in an InfoCube the storage
bucket definitions and the time characteristics need to be aligned.

Supply Network Planning

There is only one option here since SNP data can only be stored in liveCache. The
characteristics are used to describe key fields such as for example location, product number,
or transportation lane. Unlike DP, where the characteristics can be freely defined, SNP
requires the existence of a particular set of characteristics. These characteristics can be
grouped as follows:
Base Characteristics
Two base characteristics exist, the product number and the location. During the release
from DP these two base characteristics must be defined to create the independent
requirements (usually of order type FA). It is for this reason mandatory that the DP
planning area contains the characteristic for the product number. The characteristic for
the location is also required and is in most cases also part of the DP planning area, but
could also be determined using the Location Split functionality (see further down).
There is no SNP relevant order stored in liveCache that does not contain those two
characteristics.
o Product Number
o Location

Descriptive Characteristics
This type of characteristic is used to further describe data that is sent from Demand
Planning to Supply Network Planning. A descriptive characteristic is an absolute normal

characteristic within DP (e.g. the customer number). During the release from DP to SNP
characteristics can be defined as descriptive by assigning them to a consumption
group. In the consumption group the DP characteristics that should be used as
descriptive
characteristics are linked to a field of the ATP catalog. The fields of the ATP catalog are
system defined, and consequently, the possible range of descriptive characteristics is
limited by the ATP field catalog. The ATP group is specified in various master data
objects and transactions enabling special functions based on the descriptive characteristics.

An example would be the forecast consumption not only on product and location level
but
also based on product, location and customer. In this scenario independent requirements
are created per product, location (both base characteristics), and customer (descriptive
characteristic).
o e.g. Customer Number
Generated Characteristics
Besides the independent requirements, there is a multitude of other orders stored in the
system. Depending on the order type some other characteristics are defined. A production

Preparing

307

order would for example contain information regarding the production resource, and a
transportation order such about the transportation lane. These characteristics are
generated as required or might be part of the information being transmitted from the
OLTP system.
o Transportation Lane
o Resource
o PPM Name
o Activity
Most of the orders have discrete values for some but not all of the characteristics. The
characteristics Transportation Lane for example is not defined in a production order.

Location Split
Demand Planning allows planning at any level of a freely definable hierarchy. This hierarchy
usually starts on a high level such as country, region or even worldwide and is consolidated or
broken down level-by-level using aggregation and disaggregation factors. Commonly, the lowest
level from a business feasibility point of view is the forecast per product and customer. As said
before, it is totally up to the individual business which levels are planned. See also the section
Planning Approach. In order to pass over these demands to Supply Network Planning where
they will be transformed to SNP forecasts (independent requirements) it is necessary to allocate
each demand to exactly one location of the type Plant or Distribution Center. The reason for
this is that SNP plans procurement and transport orders for locations of these types. A forecasted
demand, which is basically the same as an independent requirement in R/3, can only exist at such
location types. APO offers two different ways to accomplish the distribution of demand (Location
Split) over the locations.

Location defined as Characteristic Value

In this case a characteristic that represents the manufacturing plants and/or distribution centers
exists. While forecasting is carried out, the key figure for this characteristic is populated with
the demand per product and location. During the release to SNP, these key figures are
transferred to SNP.

Location not defined as Characteristic Value or not used

Should no key figure for a characteristics value per location exist or should the existing one
not be used, the location split is carried out according to pre-defined ratios. The location-split
definition can be per product or product range and can be time phased.

4.1.1.5

Planning Version

The DP planning version and the SNP planning version known to release 2.0 users are now one
and the same. It is just called Planning Version. The real novelty is the extended use of
characteristics and key figures in SNP. Note that this was not the case with release 2.0; it was just
less prominent and by far not as flexible and integrated with DP. The planning version represents
the transactional or forecast data that is stored in a structure as defined in the planning area and
such master data that can be defined planning version specific.
The planning area within SNP is merely a way to display and use data; it is not the data as such.
The same order for example can be viewed in different planning books, which are based on

Preparing

308

different planning areas. Master data can also be made planning version specific allowing the
definition of master data differently depending on which planning version is used. The planning
version used in SNP is not a subset of a planning area and can be used in conjunction with one or
multiple planning areas.
Planning versions are part of the key of every order and consequently transactional data is stored
per planning version. This allows independent simulation with different transactional data.
Planning versions need to be initialized per planning area. This allows that a certain planning
version can be viewed according to the settings of this planning area and with the help of the
planning books based on the planning area. This initialization does not copy the order into the
planning area. It simply makes it available for it. If an order is created or deleted in a certain
planning version it appears or disappears in all planning areas for which the planning version was
initialized. Planning versions are maintained as part of the master data activities.
The planning area used in DP and SOP consists of key figures of the type time stream. In this
case the data is stored in the key figure (and not in an order). Consequently, data that is
maintained in one planning area and planning version cannot be seen in any other planning area.

4.1.1.6

Planning Book and Data View

Planning books are based on precisely one planning area. Within a planning book several planning
(data) views exist. A planning view is simply that what should be seen on one screen. When
creating a planning book, macros are defined to perform various calculations with the data and
data structure as defined in the planning area on which the planning book is based. The data used
and displayed in a planning book is that of the planning area key figures or a subset of those. In
addition to this, several key figures that are stored directly in tables (and not via the planning area)
can be used in a planning book. They are referred to as database key figures. The third group of
key figures is the group of temporary key figures that are used by macros to store data temporarily
while working in a planning book.
Planning Book
9ASNP94

In this example, parts of the standard delivered SNP planning book are shown with some of the
key figures it uses. The key figure 9APSHIP is the previously described key figure that contains
the planned distribution receipts and is made up of the order types AG and EA, via the
definition of the category group PS1. The database stored key figure SAFETY is used to save
calculated or user defined time dependent safety stock levels. The temporary key figure SAFTY
is used to store the required safety stock and is passed, for example, to the SNP Optimizer as an
input (see below). There are other planning books (e.g. 9AVMI) based on the same planning areas
that use the same and/or other key figures of the same planning area. The fact that all key figures
that are part of the shown planning area (and used in this example) start with 9A must not be
seen as a rule. Key figures can have any name and be used in any planning area.

Preparing

309

Some SNP key figures can also be maintained via external data sources. In this case data in the
form of external time streams is mapped to the SNP key figure.

O rd er
P lan n in g A rea

P lan n in g B o o k /V iew

Graphic 99 Key Figure Types

In order to provide the data to the various programs in the appropriate way, another table is present
that links the required key figures to the respective programs. This table should be changed, if at
all, with the utmost care. It is for good reason labeled as SAP data do not change.
Function
SNP_OPT
These are just two examples where the SNP Optimizer program links the source code defined level
6 to the key figure Distribution Receipt (planned) and level 14 to the temporarily stored key
figure for safety stock.
In principle the same transaction is used for DP and SNP. When a planning area is created, it can
be flagged for use in DP or SNP and by doing so the TLB or Promotion Planning functionality can
be made available to the planning book when using the respective planning area. Unfortunately the
planning book is not completely flexible and there are (still) areas where the displayable
information is hard-coded. Examples are again the TLB view and the Promotion Planning screen,

Preparing

310

which cannot be seen nor customized using the planning book design functionality. They are
predefined and can be added in total to any planning book used in SNP (TLB) or DP (Promotion
Planning).

4.1.1.7

Advanced Macros

Within DP and SNP, macros read key figure data displayed in a planning book and its data view to
perform calculations based on the data. The results might be messages (alerts) or values that are
stored in other key figures. Macros can be run interactively or in the background. Even if they are
run in the background, it is required to define a planning book and data view. Macros do not refer
directly to the data stored in a planning area, but always to data as displayed in a planning book
and data view. Since each planning book and data view is linked to exactly one planning area, the
definition of a planning book and data view also determines the planning area.
Macros are also used within SNP to calculate the total demand by adding up the orders of certain
categories. This is a highly flexible approach that allows easy custom based definitions of demand
and supply by including or excluding certain order categories. It is important to understand that
macros are defined per data view of a planning book and not per planning area. This is the case
because the data view defines the actual key figures of a planning area used. A macro cannot use a
key figure that is defined in the planning area but not in the data view. Some macros are
absolutely required in order to have a working data view; others exist to enable specific
functionality or are defined to be run on the users request.
Planning Book
9ASNP94

In the above example, the SNP Interactive Planning transaction only works correctly if the first
two macros are defined. The next two macros enable the alert creation but are not required if this
function is not used. There are no macros in this standard delivered planning view that are
intended to be run on user request only.
Note that it is not possible to define or use macros for the TLB view or the Promotion Planning
screen although both functional areas are part of Supply and Demand Planning (SDP). Both
functional areas are based on a hard-coded planning view (screen) layout. They neither use the
planning book design functionality nor do they use macro technology for the generation of alerts.
TLB alerts are not macro-based.
Within DP, macros are used amongst other tasks in the following areas:
Aggregation and Distribution
APO predefined macros are used to apply proportional factors and do not need to be
developed.

Consensus Based Forecast

In a Consensus meeting commonly agreed macros could be defined which will subsequently
be applied to a whole range of products.

Preparing

311

General Forecasting
A macro could even be used to create an entire forecast in a case where none of the standard
models deliver the expected result.
Data Evaluation
Historical data or forecast results can be evaluated efficiently by setting up macros. The result
of such an evaluation could be an alert (see below) or the automatic update of such data based
on even complex conditions.

Macros are used within SNP to carry out for example the following tasks:
Safety Stock/Target Stock/Reorder Point Calculations
For these tasks special functions exist that read the product master parameters. Subsequently
the current demand elements are used to derive the required quantities.

Workday, and Stock Balance Calculations

Macros are also used to calculate the number of workdays as well as the opening stock and
the stock and backlog figures.

Macros are also used for alert processing. Unlike all other APO areas, there are no automatically
applied predefined alerts in Demand Planning or Supply Network Planning (except Deployment
and TLB). Alerts can be created using macros that are executed just like any other macro. See also
the section Alert Monitor.
The execution of macros is event driven. Possible events are:

Start
The macro runs every time the planning view is called up and shown on the screen. It will not
be executed again irrespective of activities performed during the planning session.

Level Change
Changing the planning level or, for example, selecting other data triggers the execution of this
type of alerts.

Default
Every time the planning view is called up (same as in Start), the <Enter> key is pressed, or
the planning data is saved (same as in Exit) the macro is run.

Exit
The macro runs every time the planning data is saved. The macro can be run repeatedly by
saving the planning table. Therefore the condition is actually not Exit but Save.
If multiple macros are defined, then they are executed in the sequence as they appear in the tree
structure of the planning screen. Any macro can also be executed interactively if not explicitly
excluded.
Macro Execution Space
Macros can be used to read data from any key figure, database key figure, and temporary data row.
Key figures can be of the type time stream where the data is stored directly in the key figure.
This storage principle is used within DP and SOP. It is also possible to read key figures that
represent the total of one or multiple discrete orders of the specific time bucket. This storage
principle is used within SNP. Database key figures are stored per planning area and represent time
stream type data. Temporary data rows are calculated during a planning session (interactive or
background) but never saved when exiting the transaction. For more information on this topic see
the section Planning Area Environment.

Preparing

312

Data Type
Key Figure
Key Figure
Key Figure
Key Figure
Database Key Figure
Temporary Data Row
During the macro execution the system automatically detects the type of data type and continues
with reading the data as required. A magnitude of operands and functions can be used to
manipulate the data and derive the result. The result of a macro can be stored in key figures,
database key figures, and temporary data rows. The following limitations exist.

Marcos cannot update data of the type key figure for discrete orders. In this case the macro
would have to update the underlying discrete orders that make up the total value shown in the
key figure. This is not possible.

Macros cannot update data of the type key figure for time streams if the key figure is stored in
an InfoCube. Data in DP can be read from an InfoCube but there is no possibility to write into
an InfoCube.
Macros read data of the specified planning book and data view and write the result back into the
same planning book and data view. Macros can also be viewed in the Alert Monitor.
Macro Execution Level
Macros can be run at specific levels. Levels determine the degree to which data is aggregated.
While in DP or SNP interactive planning, the macro is run on the same level that is visible to the
planner. It is important to remember this fact specifically when applying macros that update key
figure values by means of absolute numbers. While the macro calculation level varies and depends
on the selected data, the data read and write level is always the lowest level.
During the macro execution data is always read at the lowest level. Then, and only if a specific
aggregation level has been defined, data is aggregated using the aggregation rules as defined in the
planning area. While being in interactive planning, the visible aggregation level is automatically
used as the specified calculation level for the macro run. During DP background planning macros
are run at the lowest (most detailed) level if not specified otherwise; any other calculation level
can be defined as required. The macro calculation is then carried out. After the calculation, and
only if a specific aggregation level has been defined (either explicitly in DP background planning
or by implication in interactive planning), data is disaggregated using the disaggregation rules as
defined in the planning area. Then the result is stored at the lowest level.
As mentioned before, during DP background planning, macros are run at the lowest (most
detailed) level if not otherwise specified. Any other aggregated level can be defined as required.
This excludes time aggregation, as macros do not permit time aggregation as standard function. It
is possible though to create macros that add up data over various time buckets and write the result
into a specific time bucket.
The aggregation levels that can be defined here are independent of possible existing aggregates.
An aggregate defines a possible redundant storage of data on an aggregated level (see the section

Preparing

313

Planning Area Environment) . Should a macro be run on an aggregation level that corresponds
to an aggregate, then the reading of data can be accelerated as no lowest level (most detailed level)
reading of data with consequent aggregation is required. Instead the data of the aggregate can be
read, the calculation can be carried out immediately, and the result be written back to the
aggregate. It still has to be written on the lowest level, as data in aggregate must be consistent with
data on the lowest level.
The macro execution level within SNP is not too complicated. Planning is carried out on the level
product and location and no aggregation is permitted. This applies to interactive and background
planning the same way.

4.1.1.8

InfoCube

The use of an InfoCube to store historical data is an option. All data can be stored directly in
liveCache. This option might be prohibitive in large-scale installations, as the size of the liveCache
required might not be justifiable. InfoCube based storage is slower but cheaper and
technologically more stable.
Even if the intention is to store all data in liveCache, it is advisable to go through the section
dedicated to the InfoCube, as valuable information is contained in this section, which applies to
both data storage methods.
The InfoCube is the construct used to store historical data. It does not store any parameters,
profiles or the promotion catalog nor is it suited for fast access writing of forecast data. Promotion
plans are stored in tables and update the forecast data in liveCache. InfoCubes are also used in the
SAP Business Information Warehouse (BW), and APO is fully integrated not only with R/3 but
also with BW. Key Performance Indicators (KPI) are defined in BW and calculated using data in
BW. They were defined in collaboration with the Supply Chain Council and are based on Best
Practices. In order to achieve seamless integration APO uses the On Line Analytical Processor
(OLAP). OLAP is the tool, which allows the APO user to:

create and maintain InfoCubes, which are used to read historical,

set up communication rules between the OLTP system and the BW portion of APO, and

to write data directly to the InfoCube from sources such as a spreadsheet.

In essence the InfoCube contains all historical transaction data required to perform the forecast.
This data needs to be updated regularly in a time interval depending on the planning cycle. A
weekly update run is absolutely sufficient when forecasting is carried out on a weekly basis.
In order to use APO forecasting functionality; it is not required to have a BW system; every APO
system comes with its own small BW subset. It is not possible to create any InfoCube based
reports within APO. If this or the use of key performance indicators is a business requirement, it is
necessary to get a full BW system. APO uses BW technology for its data storage but does neither
share the data as such nor does it need a dedicated hardware to do so. Set up and maintenance of
the InfoCube is carried out using the Administrator Workbench.

Preparing

4.1.1.8.1

314

InfoCube Logical Structure

An InfoCube contains the data that is required to perform a forecast. Based on this definition, it is
required from the InfoCube to provide time-based historical demand data in a way that it is
possible to compare this data with the liveCache based forecast. The minimum level of detail for
quantity-based demand information is What & When, and additionally How Much. This is
the fundamental concept of any demand information system, irrespective of the technical
implementation. The What & When in the InfoCube is called Characteristics, and the How
Much is the Key Figure. A graphical way of showing this situation is by means of a table as done
below. The point where the What row crosses the When column is the How Much cell.

Dimension
Product with
Characteristic
Table 67 Basic InfoCube Example
We have in our example the dimension Product with the characteristic Product Number which
is defined per row. The dimension Time with its characteristic Month can be found per
column. It is totally immaterial which characteristic is put into the row and which into the column.
We could have also put all characteristics into the columns or rows. Why do we need dimensions
and characteristics, as they seem to have a one-to-one relation? The answer is that we do not really
need them here in our basic example, but in reality, an InfoCube will contain much more
information. Characteristics will then be grouped logically into Dimensions. Lets go further and
assume we want to know how much demand we had, not only per product, but also per product
group. We shall now break down the dimension Product into its two characteristics Product
Number and Product Group. The result is as follows:

Dimension
Product with
Characteristics
Table 68 Extended InfoCube Example
Please note that aggregated quantities per month and product group, the so-called Key figures, can
be calculated and that for the total of the subordinate products there is no need to store data. Every
time a read request on our small table above is carried out, we require the information product
group, product, month, and quantity. Care is required nevertheless if a product moves from one

Preparing

315

product group to another. This is an imminent problem to any information system, and there are
several approaches for such a case. The SAP Business Information Warehouse (BW) allows
setting up a hierarchy of Characteristics. This is not a required function for APO. We shall
therefore not further elaborate on this possibility. Within Demand Planning, data can be
automatically aggregated and distributed according to the Proportional Factors or Pro Rata. We
still have not defined what the relation is between dimensions and characteristics. Any
characteristic must be allocated to one, and exactly one dimension of an InfoCube. A dimension
can have several characteristics attached to it. There is no rule which characteristic has to be put
together with which other characteristic into a dimension. Also no rule exists how many
dimensions are needed. Four characteristics could be in four different dimensions or put all
together into the same dimension. It would have no impact on the planning process or on the level
of detail of planning.
Would it make sense to define a new characteristic Year within the dimension Time if we need
the demand figures per year? Certainly not, as there is a mathematical relation between month and
year. Twelve months make one year. As this is a constant relation, we do not need to have two
characteristics within the dimension Time. Just be careful when working with the time
expressions Week and Month, as there is no fixed relation between them. Week 5 in the year 2000
as an example is part of the months January and February. To cope with this problem, it is required
to define the two characteristics Week and Month.
Up to now our model has two dimensions, Product and Time which were shown in a two
dimensional table. We shall now add a third dimension, which we call Customer, and allocate
the Characteristic Customer Number to it. Our more sophisticated model now has three
dimensions, which is graphically represented by the cube shown below. Ever wondered where the
name InfoCube comes from?

Time
r

tome
s
u

Graphic 100 DP InfoCube

Preparing

316

It is obvious that this principle also works with more than 3 dimensions and 4 characteristics. The
limitations of the InfoCube are a maximum of 16 dimensions and 256 characteristics. There is no
additional constraint on the maximum number of characteristics per dimension (not necessarily
exactly 16 characteristics per dimension).
APO comes with a large amount of predefined Info Objects. The generic term Info Objects
describes Characteristics (which are grouped in Dimensions), Key Figures, Unit Characteristics,
and Time Characteristics. The same Info Objects can be used in an InfoCube and in liveCache.
Planning in DP is carried out by means of defining the Key Figure values. Before this can be
done, it is necessary to activate a certain combination of characteristics. They are also referred to
as Characteristic Value Combinations.
We have concentrated up to now on the definitions required for storing historical data. In our
example we always assumed one key figure, which was the sales quantity. In practice one would
most probably add other key figures such as turnover or average price. No key figures can be
added to store forecast data, as the writing of data to an InfoCube is not possible for the DP
planning transactions. Used key figures should not have any mathematical relation, as this would
result in data redundancy. But, as shown in the example below, there is no rule without exception.

Dimension
Product with
Characteristic
Table 69 Multi Key Figure InfoCube Example
In this example the Turnover key figure could have been easily calculated by multiplying the key
figure Sold Quantity with the key figure Average Price. The reason why this was not done is that
the planner wants to see, on an aggregated level, the average price per product group as a key
figure. Note that this average must not be weighted. In this example based on the aggregation rule
Average the result on the product group level is 1.10 and not 1.12, which would be the weighted
average. To get the weighted average per product group, it is useful to deploy the Macro
technique and calculate the figure where appropriate.
What is explained above is a very basic setup that obviously would not be sufficient in a realworld planning environment. In a typical live system, multiple key figures can be found. They are
listed below.
Stored in InfoCube or liveCache
Sales in Units (Historical)
Preparing

Sales Revenue (Historical)

Average Price (Historical)
Stored only in liveCache
Corrected History

as in the OLTP system

Sales Plan 1 (Statistical F/C)

model
Sales Plan 2 (Corrected F/C)
Sales Plan 3 (Consensus Based F/C)
Sales Plan 4 (Composite F/C)
Promotion Planning
Final Sales Plan
SNP Plan
The final determination of key figures to be used depends on the exact business requirements.
An InfoCube has exactly one quantity unit of measure (UoM) that is used for the storage of
quantity related planning data. This unit of measure must be the same as the unit of measure used
in the planning area that uses the InfoCube. It is advisable to define this unit of measure in
thousands of pieces or any other neutral unit. The use of units like pallets or boxes is rather risky,
as pallet or box sizes might change over time and are not the same for all products. In some cases
planning in weight or volume units is the better option. The selection of the planning unit of
measure is a fundamental task. Once defined and loaded with data, the InfoCube cannot be
changed anymore.
Key figures are displayed in the base unit of measure as defined in the planning area. Any other
unit of measure can be used as a display unit, provided it is defined in the product master. Units of
measure based on the International System of Units (SI) can be converted without explicit
definition in the product master. The SI system is based on seven different basic units from which
all other measurements are derived (e.g. 1000g = 1 kg) . It also links non-metric units like inches
and pounds to the base units. A unified unit of measure for all products is required to facilitate the
aggregation and distribution of key figures through all levels of the planning hierarchy.
Should the product ranges be too diverse to have the same base unit of measure in planning, a socalled planning unit needs to be introduced. This dimension free planning unit of measure will
have to be transferred into a product specific unit of measure when the DP plan is released to
SNP. The dimensionless planning unit of measure, as well as the product specific unit of measure
needs to be defined in the product master.
A special situation exists where the relation between units and weight or volume is not constant.
This is known as variable or catch weight, which is a function within the R/3 industry solution
Oil and Gas. In order to follow a consistent planning approach, it is advisable to use only one unit
of measure within APO that can be used by DP, SNP, and PP/DS.

4.1.1.8.2

InfoCube Technical Structure

Technically the InfoCube is a collection of two different types of tables, the Fact Tables and the
Dimension Tables. They are joined together in a Star Schema.
Preparing

Dimension Tables are made up of a key, a dimension number, and the characteristics within the
dimension. As there is a maximum of 16 dimensions, no more than 16 dimension tables can exist.
Dimension tables do not contain any key figures. The graphic below shows the dimension tables
for the example used in the previous section. The used key in this example is fictitious.
The Fact Table is made up of an access key and all the relevant key figures. The access key
represents a unique combination of characteristics. The combination of each of the (up to 16)
dimension tables forms the Fact Table access key. A graphic of a fact table based on our previous
example is shown below.

Key

Graphic 101 InfoCube Fact Table

Key
1 23
1 24
1 25

D im en sio n T im e
Key
223
224
225

Graphic 102 InfoCube Dimension Table

Preparing

Dimension and Fact Tables are joined together in a Star Schema. The (up to 16) points of the
star represents the dimension tables, and in the middle of the star, you can find the fact table. This
can be seen in the graphic below.

Dimension Product
Key

123
124
125

Key
123-223-323
124-223-323
125-223-323

Dimension Time
Key
223
224

2/99

225

3/99

Graphic 103 InfoCube Star Schema

4.1.1.8.3

InfoCube Setup and Maintenance

Setup and maintenance of the InfoCube is done primarily using the Administrator Workbench.
This is a powerful, highly graphical and intuitive, easy to learn application. Strictly speaking, it is
not

Preparing

320

really an APO application. Its origin is the Business Information Warehouse where it is used for
exactly the same purpose. The normal APO user will never use the Administrator Workbench, as
its task is solely the creation and the structural maintenance of the InfoCube as the main
repository for data required in DP. The following section will give a brief overview of the
Administrator Workbench functionality required for APO. For those interested in more details, I
suggest to get BW specific literature.
The Administrator Workbench is primarily used to maintain the following elements.
Info Objects
Characteristics, Key Figures, Unit-, and Time-Characteristics are the four object types, which
make the group of Info Objects. Info Objects can be grouped in Object Catalogues for easy
retrieval and logical grouping. APO comes standard with a large number of predefined Info
Objects, and often one of them can be used without further maintenance.

Info Areas
An Info Area is used to group various Info Cubes. This is with practical relevance for APO if
Vendor Managed Inventory (VMI) functionality is deployed. For each VMI customer, a
separate InfoCube has to be defined. It is also useful when using Product Allocations in
Global ATP, as each Product Allocation Group requires its own InfoCube.

Info Cubes
The InfoCube is the heart of Demand Planning. All historical data as well as all forecast data
is stored in an InfoCube. It is arranged in Dimensions, which in turn have one or multiple
Characteristics and Key Figures. The Administrator Workbench is used to define all these
relations. Multiple Info Cubes can share the same Info Objects.

Info Sources
Every InfoCube must be linked to an Info Source in order to be populated with data. Info
Sources define Transfer Structures, Transfer Rules, and Communication Structures. The
Source System is one of many Application Components.

Source Systems
The Source System, in combination with the Info Package, describes the layout of the data
provided by the data originating system (R/3, CSV type spread sheet, etc.). A Source System
is linked to an Info Source, which finally provides the InfoCube with data.
As said above, it is not really necessary to fully understand the technicalities of the InfoCube setup
and its surrounding environment. The setup is a once off activity and should be done by a BW
specialist. Some additional information required for each InfoCube has to be defined in the
separate transaction Configure InfoCube Parameters.

Info Objects
APO comes with a large amount of predefined Info Objects. The generic term Info Objects
describes Characteristics (which are grouped in Dimensions), Key Figures, Unit Characteristics,
and Time Characteristics. All these info objects can be used instead of creating new ones when
setting up the APO InfoCube. Info Objects can be grouped in Info Object Catalogues. Some of the
Info Objects are mandatory to define a meaningful InfoCube, or are required for logical reasons.
Once the InfoCube is populated, new Info Objects can only be added, or existing ones deleted
after the InfoCube is set to inactive. This will delete all data stored in the InfoCube!
The list below shows the predefined Info Objects and their respective usage.

Preparing

321

Dimension
Description
Time

Data Packet

Unit
Planning Version
Table 70 Info Objects
Note the following explanations:
1. The 3 predefined technical dimension names are made up of the InfoCube name followed by
1T and 1P for mandatory dimensions. The dimension ending with 1U is optional and only
visible if required in the InfoCube.
2. The 13 freely definable dimensions have the ending 11 through to 13 and must include
the dimension for the planning version.
3. The Dimension Time must have at least one characteristic. Some of the predefined time
dimensions are shown in the list; others that are used when using Fiscal Year Variants are also
available.
4. When viewing the technical structure of an InfoCube, the Unit dimension (if used) is not
displayed.
5. The Data Packet Dimension stores system-related data. It does not need to be set up.

Preparing

4.2

322

The Data Environment

What you put in is what you can get out. This means for APO that it is required to supply the
system with lots of information in order to have a highly sophisticated planning tool. The
optimization routines, as an example, can only provide a realistic result if all essential data is
provided. APO is not always easy to understand when it comes to all the data it uses, but it is
mandatory to understand what the impact of the data stored in the system is.
The system-stored data can be grouped into various groups according to its usage as such, and its
update frequency.

Profiles
Profiles are some kind of parameters that usually do not require frequent update. They can
drive applications and their behavior as well as the user interface.

General Master Data

The general master data section comprises all such master data that is used by more than one
APO module. The best examples are the location and the product master.

Module Specific Master Data

Unlike the general master data, the module specific master data is used for very specific
modules and functions. An example would be the setup group, which is used by PP/DS only.

Cost Data
The optimizers usually need cost data, and there are a few special transactions that allow an
easier maintenance of cost data. Although the cost data is stored in several master data objects
(general master data), it can be maintained in central maintenance transactions that update the
relevant master data objects in the background.

Alert Monitor Definitions

A special type of profile is used in conjunction with the alert monitor. They are not special in
terms of the way they have to be maintained, but in what they are used for.

Supply Chain Engineer

The supply chain engineer is a sophisticated tool to build and maintain the entire supply chain
model. It can also be used to create transportation lanes and quota arrangements.

Model and Version Management

The supply chain model and version management functionality is of special interest to all
those who work with simulations.

Macro Builder
Within the DP and SNP environment, the macro tool can be used to automate a lot of
functions. Even the standard delivered system comes with a set of macros that are absolutely
essential to operate the system. The macro builder is a very powerful tool but requires a
thorough system understanding before being used.

4.2.1

Profiles

Profiles are used at several places within APO. Although both carrying the same name profile
there are two distinctly different types of profiles.

Master Data Profiles

Preparing

323

Master data setup used within APO is greatly simplified by the usage of so-called Profiles.
While creating product master data, a profile can be linked to it, and any change performed on
the profile is pulled through the master data automatically (link of profile to master data).
Additionally, information of a profile can be used as a reference source when creating master
data, without consequent automatic update (copy of profile to master data). The profile
functionality is the same as the ones used in R/3 MRP (MRP and Forecast profiles).
Master data profiles do not have their own fields but are there to make life easier.

Definition Profiles
Definition profiles are used as a general source of information and are not linked to any
master data object (e.g. TLB profile). They serve the same purpose just as any other
customizing entry. Some of those profiles are not called profiles, but have similar principles
and might be found in the system as part of the grouping header profiles (e.g. requirements
strategy).
Definition profiles provide the respective data object or function with additional
information not contained in any other data object.

Settings Profiles
Settings profiles determine the appearance of applications or the data displayed by the
application. Most of the time they determine a specific environment for the user and thus
allow the personalization of the system. Other than that, they serve the same purpose just like
any other customization entry. Settings profiles greatly drive how the work is carried out
within PP/DS. Understanding these profiles means to a large degree understanding the
functionality of PP/DS.
Settings profiles allow the determination of a user specific appearance and functional preselection of data.
Profiles can be maintained at various places; usually the profile maintenance program can be
called from the menu tree structure. Some of them can be found in the respective master data
object maintenance transactions, and/or in the IMG. Below is an overview of profiles used in
APO. Note that this is a not a complete list of profiles, as there are a lot of other profiles in various
applications.

Master Data Profiles

SNP Demand
SNP Supply
Deployment
Demand
Lot Size

Table 71 Master Data Profiles

Preparing

Definition Profiles
Forecast

Master

Univariate

MLR

Composite
Like

Phase-In/Out

Requirements Strategies

Rounding

SNP Lot Size Profile

(Transportation Lanes)
TLB

SNP Optimization

SNP Optimization Bound

SNP Cost

VS Optimization

Carrier

Factory Calendar

Preparing

325

Definition Profiles
Time Steams

Table 72 Definition Profiles

Settings Profiles
Overall Profile

Strategy Profile

Work Area

Propagation Range

Time Profile

Planning Board Profile

Optimization Profile

Table 73 Settings Profiles

4.2.1.1

Forecasting Profiles

Demand Planning is using several profiles that are linked to a planning area. The main one is the
Master (Forecast) Profile. More than one Master Forecast Profile can be linked to any planning
Preparing

area. The user can pre-select the Master Forecast Profile, or select at run time, which one to use.
This is handy, as not all products that have to be forecasted will necessarily require exactly the
same forecast parameters. The profiles used for forecasting and their main parameters are dealt
with in the following sections.

Planning Area
Master Forecast
Profile

Graphic 104 Forecasting Profiles

The Master Forecast Profile is planning area dependent; this means a specific Master Forecast
Profile can only be used in conjunction with a specific planning area. In opposition to this, the
Univariate, MLR, and Composite Profiles are planning area independent. Therefore, when
dealing with several planning areas, the same Univariate, MLR, and Composite Profiles can be
used. The Composite Profile itself refers to one or multiple MLR and/or Composite Profiles. This
cascading of profiles allows a flexible mix and match of profiles and avoids unnecessary data
maintenance. In some cases there are links to profiles and other profile-like entries called time
series. The diagram above shows the profiles with their relationships.
Besides the forecast profiles discussed above, Life Cycle Management settings and profiles are
also linked to planning areas within Demand Planning. In fact, there is one common transaction
to define all these profiles, time series, and settings.
The Life Cycle Management Profile Structure
The three profiles for phase-in, phase-out and like-modeling are defined independent of any
planning area, and or characteristics combination. Independent of these profiles, the
characteristics combination to be used in Life Cycle Management, is defined per planning area.
Per planning area between one and six characteristics can be defined for this purpose. The Life
Cycle Management profiles are then attached to discrete values of the characteristics as defined
per planning area. The same profile can be attached to multiple characteristic combinations.
Preparing

The following graphic illustrates this relation.

Planning Area
Characteristic 1
Characteristic 2
...

Characteristic 6

Graphic 105 Life Cycle Management Profile Structure

The following example illustrates this relation.
In step 1 for the planning area, we define which characteristics we want to use for Life Cycle
Management. Since the life cycle of our products is different per location, we decide to use the
product and location to be our characteristics. In this example we work with the planning area that
was delivered with the system. We do not use the characteristics 3 through to 6 (i.e. leave the
definition fields blank).
Planning Area
Characteristic 1
Characteristic 2

9ADP01
9AMATNR

9ALOCNO

We then define the Like, Phase-In, and Phase-Out profiles. The Like profile relates a product to
another one, or multiple products, and the Phase-In profile is in fact a time series of percentages.
Since we have a new product (DEF) for the location (2000) no Phase-out profile is used in this
example. The location product we want to refer to is product DEF at location 2000. The Phase-In
profile has 3 period values (percentages).
Like Profile
Phase-In Profile

Since we now have the definition of which characteristics are used, which is the like product and
its location, and which are the percentages for the phase-in, we can put the puzzle together in the
Life Cycle Assignment table. Firstly we define the new product and location, and then the profiles
we refer to.
Preparing

Characteristic 1
(Product)
Characteristic 2
(Location)

4.2.1.1.1

Forecast Profile Maintenance

The majority of Demand Planning profiles and forecast settings can be maintained in one central
transaction called Maintain Forecast Profile. This section describes the usage of this
transaction, including all functionality. The majority of the forecast related parameters can also be
maintained in the DP Interactive Planning transaction.
The Profile Maintenance Transaction

Path:
Technical Name:
IMG:

Demand Planning > Environment > Maintain Forecast Profiles

/SAPAPO/MC96B

Yes

The transaction screen is divided into four tabs, one each per forecast profile type. Life Cycle
Management functions can be activated using pushbuttons or via the Goto option. The
pushbuttons on top change in accordance with the selected tab.
The functionality included in this section is as follows:
Master Profile
Univariate Profile
MLR Profile
Composite Profile
Assignment of Forecast Profiles
Consistency Check
Time Series Copy and Delete
Like Profile
Phase-In/Out Profiles

The Master Profile

The Master Profile, also referred to as the Forecast Profile, or Master Forecast Profile, defines
various forecasting method independent parameters such as the start and end date of the forecast,
or the number of periods to be forecasted. The Master Profile points to exactly one Multiple
Linear Regression Profile, one Univariate Profile, and one Composite Forecast Profile. Multiple
Master Profiles can be defined per planning area.
Pushbuttons Master Profile
Preparing

Delete Fields for New Entries

Pressing this pushbutton deletes all entries made in the master forecast
profile without any warning.
This is not a refresh option, as the icon might suggest!
Display Information on Creation Data

Displays administrative data.

Assign Forecast Profiles
Opens a pop-up window in which the master forecast profile is assigned
to a combination of planning area and some other parameters.
See Assignment of Forecast Profile further
down. Basic Life Cycle
Opens a pop-up window in which a characteristic for life cycle
management has to be assigned to the planning area.
See Life Cycle Definition further
down. Assign Life
Cycle
Permits the linking of the characteristic defined in the Life Cycle
Definition to Phase-In, Phase-Out, and Like profiles.

See Assign Life Cycle further down.

Fields Master Profile
Basic Settings
Planning Area
Defines the planning area of a forecast profile to be created. When
calling up an existing forecast profile, this field can be left blank since a
forecast profile is linked to one specific planning area only.
Master Profile Name
Defines the forecast profile to be created or
edited. Master Profile Description
Provides a forecast profile
name. Forecast Key Figure
Defines the key figure into which the forecast result (not the corrected
forecast) has to be written.
Additional Settings
Period Indicator
Specifies the period used for forecasting. This must be a periodicity that is

Preparing

330

compatible to those defined in the planning area via the storage buckets
profile.
Fiscal Year Variant
Specifies the Fiscal Year Variant when using the Period Indicator Posting
Period.
Material Forecast
Sets this flag if you want to use the Phase-In, Phase-Out, or Like
Modeling feature. All required product parameters for this functionality
are stored in the respective product master. It will only be applied if this
parameter is set.
Forecast Horizon
The horizon can be specified in two ways, fixed with a from and a to date,
or alternatively floating, depending on the system date. For the second
option, simply specify the number of periods to be forecasted, and do not
specify a date. In this case the forecast horizon starts by default after the
current period as per system date and lasts for the number of periods as
specified here. This is the normal setting in a live environment.
Alternatively specify a from and to date explicitly. The system will
automatically add the number of periods reflected by these dates. This
feature is useful for development and testing purposes where no live data
is available. Assuming you have loaded the InfoCube with some historical
data, it is possible to run all forecasts with a fixed start date.
Offset values can be defined for both periods using positive (shift into the
future) or negative (shift into the past) numbers.
History Horizon
The history horizon is specified the same way as the forecast horizon. It is
also possible to use fixed or floating dates as well as offset values.
Model Selection
The model selection links a Univariate, MLR, and Composite Profile to
the Master Forecast Profile.
The Univariate Profile
Here you find all parameters required for running a time-based forecast. Foremost, a defaultforecast strategy is defined (e.g. seasonal model) with all its relevant factors like Alpha, Beta,
Gamma, and Sigma Factor. It also defines the average number of workdays per planning period.
Refer to the section Workday Correction for more information. The last section of the Univariate
Profile flags the errors the system has to calculate in order to evaluate the forecast (e.g. MAD,
MSE). A default pushbutton for this profile populates the majority of fields with default values
according to best practices. The following list contains parameters that can be defined.
Preparing

Pushbuttons Univariate Profile

Copy

Use this pushbutton to link (not copy) the univariate profile to the master
forecast profile shown on the master profile tab.
Save Single Profile
Saves the univariate profile.
Show Default
Some of the forecast strategies require values for some parameters.
When defining the univariate forecast profile, the Default pushbutton
allows copying into the profile what is commonly accepted to be a good
proposition. The planner might want to alter them to achieve a more
acceptable result or just to see the impact on a change. Again it makes
sense to do this to get familiar with the APO forecasting capabilities and
to store the results in different planning versions for easy comparison of
results.
Some of the default values are used if no definition was made in the
univariate profile.
Delete Fields for New Entries
Pressing this pushbutton deletes all entries made in the univariate
forecast profile without any warning.
This is not a refresh option, as the icon might
suggest! Delete Assignment to
Master Profile
Use this pushbutton to reverse the linking carried out with the Copy
pushbutton explained above.
Fields Univariate Profile
Basic Settings
Univariate Profile Name
Specifies the univariate profile
name. Univariate Profile Description
Specifies the univariate profile description.
Read Historical Data
Key Figure
Defines the key figure where the univariate forecast has to be written to.
Version
Defines the planning version to be used for the univariate forecast. You
Preparing

can write the forecast into a planning version different to that where the
historical data is stored.
Read Corrected History
After calculating the corrected history it can be stored in a key figure. If
that has been done, the stored, corrected history can be used instead of
the historical data key figure.

This is only done if this flag is set.

Adjust Corrected History (Supplement Corrected History)

Set this flag if you want the corrected history to be replaced

(supplemented) by the historical data in situations where the corrected
history is Zero.
This flag is only active if above flag was set.
Model Parameters
Forecast Strategy
This is the forecast strategy used when carrying out the forecast. Select
one of the Univariate strategies or the MLR strategy!
Alpha, Beta, Gamma, Sigma Factors
As and where required, the factors defined here are used by the
respective models. Refer to the explanation of the strategies for further
information.
Some of the forecast strategies work with default values for these
required parameters if no values were defined! These default values are
the same as when using the Show Default pushbutton.
Number of Periods (Persmo)
This entry is used with forecast strategy 35 only, and has a default value
of 1. This means that each peak period is used individually when using
this strategy. Defining any other integer value (2, 3, etc.) causes the
system to use the average of the number of periods defined. In practical
terms it dampens the effect of seasonal peaks.
Season Periods
Indicates the number of periods per season, used for seasonal and trend
seasonal models. This is the number of periods for a full cycle of a
season. A yearly season for example might have a number of 12 (if
planned in months) or 52 (if planned in weeks). This number must be
seen in connection with the period indicator of the master profile!
Weighting Group
This profile-like entry is used for a Moving Average
model. Trend Dampening Profile
The Trend Dampening Profile is an optional parameter for the trend and
seasonal trend models.
Preparing

Historical Value Markings

Defines a time series for the Historical Value Markings if Outlier
Correction must not be carried out for all periods, but only for those that
are marked in the time series specified here. This time series does not
carry values, but rather an on/off switch per period.
Diagnosis Group
The diagnosis group is used to define upper and lower limits of control
parameters that are calculated when performing the univariate forecast.
Should a result fall out of any of the defined values, an alert can be
generated. In order to receive an alert it is required to create a macro and
activate it in the planning book.

Control Parameters
Without Leading Zero (Consumption)
Ignores initial periods without any consumption so that these periods do
not influence the forecast.
Outlier Correction
Corrects Outliers based on the Sigma Factor and the Mean Absolute
Deviation (MAD).
Days in Period
Defining a value in this field activates the Workday Correction feature. If
left blank, no Workday Correction takes place. When using this function
and planning in weeks (months) it makes sense to set the average to 5
(20) days. The factory calendar used for the workday correction is
defined in the time stream that is attached to the planning areas storage
bucket profile.
Forecast Errors
MAD, MSE, RMSE, Error Total, MAPE, MPE
APO can calculate various forecast error figures. Define here which one
should be calculated. As each calculation requires processing time, only
those should be activated that are used by the planner. In Interactive
Planning, the planner can also activate them temporarily if required.
For these error measurements, upper limits can be defined in a diagnosis
group. Exceeding the defined values in the diagnosis group can lead to
the creation of an alert (see above under Model Parameters). Forecast
Errors are dealt with in detail in the section Forecast Accuracy
Analysis.
Promotion
Key Figure
Defines the key figure in which past promotions are to be stored. This
does not have to be the same key figure as the active promotions.
Preparing

Select
Select this option to deduct promotion values defined in the key figure
above from the history, before the forecast is carried out, under the
following condition:
Only deduct the promotion value from the past for those periods where
the historical data is an Outlier (in other words only when the
promotion caused an excessive peak seen by Outlier Correction). This
option can be combined with the time series Historical Value
Markings.
Change Values
Select this option to deduct all promotion values defined in the key
figure above from the history before the forecast is carried out.
The MLR Profile

The main parameters defined here are the Diagnosis Groups that defines various MLR parameters
and the used independent variables. The alert monitor can be used to automatically inform the
planner, should any of the parameter values be out of the acceptable range.
Pushbuttons MLR Profile
Copy
Use this pushbutton to link (not copy) the MLR profile to the master
forecast profile shown on the master profile tab.
Save Single Profile
Saves the MLR profile.
Delete Assignment to Master Profile
Use this pushbutton to reverse the linking carried out with the Copy
pushbutton explained above.
Fields MLR Profile
Basic Settings
MLR Profile Name
Specifies the MLR profile
name. MLR Profile Description
Specifies the MLR profile description.
Model for MLR
Measured Value Error
Defines which of the methods are to be used for evaluating the usability
Preparing

(quality) of the MLR.

Sigma
Defines the Sigma value when selecting the NORMCONST measured
value error option.
Diagnosis Group
The diagnosis group is used to define some upper and lower limits of
control parameters that are calculated when performing an MLR-based
forecast. Should a result fall out of any of the defined values, an alert can
be generated.
History for Dependent Key Figure
Key Figure
Defines the key figure where the MLR results have to be written to.
Version
Defines the planning version to be used for the MLR results. You can
write the forecast into a planning version different to that where the
historical data is stored.
History and Future for Independent Variables
Independent Variable

Specify a key figure or time series here as an independent variable.

Using only one independent variable makes the Multi Linear Regression
a Single Linear Regression. It is possible to specify time series and/or
key figures.
Version
Defines the planning version of the key figure of the independent variable.
Conversion
This entry allows you to define a positive or negative lag (offset)
between the independent variable and the dependent variable. This is
used if the independent variable influences the dependent variable with a
certain delay or earliness and is expressed in periods according to the
period settings of the master profile.
Start
The start date needs to be specified only if a time series is used to
describe an independent variable. By specifying a start date, the system
can relate the first value of the time series to a period.
Selection
Select Key Figure
Press the Key Figure pushbutton to link a key figure to the profile.
Select Time Series
Preparing

Press the Time Series pushbutton to link a time series to the profile.
Before a time series can be used, it must be created using the Time
Series pushbutton.
Edit Time Series
The Time Series pop up window allows specifying the time series ID and
description as well as the number of periods for which data will be
entered. In the next step, the values per period have to be defined (press
Edit Time Series pushbutton) and define values as required.
The Composite Profile
The Multiple Linear Regression Profile(s) together with the Univariate Profile(s), to be used for
the creation of the composite forecast, are defined here. In this profile, you can also specify time
independent weighting factors, or a time dependent weighting group. The Composite Forecast
will return a result even if one of the input forecasts does not provide a result.
Let me give an example. We have specified a univariate and an MLR profile in the composite
profile, each with a weight of 50%. The univariate forecast returns a result of 1000 pieces in a
certain period. The MLR forecast is out of the tolerance as defined in the diagnosis group and
does not return a figure for the same period. The overall result for this period is therefore 1000
plus Zero pieces divided by two, which makes 500 pieces.
Pushbuttons Composite Forecast Profile
Copy
Use this pushbutton to link (not copy) the composite forecast profile to
the master forecast profile shown on the master profile tab.

Save Single Profile

Save the composite forecast profile.
Delete Assignment to Master Profile
Use this pushbutton to reverse the linking carried out with the Copy
pushbutton explained above.
Fields MLR Profile
Basic Settings
Composite Profile Name
Specify the composite profile
name. Composite Profile Description
Specify the composite profile description.
Profile Grouping

Preparing

337

Defines one or multiple univariate and/or MLR profiles that are used to
make up the composite forecast. Each profile referred to needs a
weighting. This weighting is independent of periods. The total of all
weights does not have to be 100.
Use the weighting profile to define period specific weightings.
Select and Edit Profiles
Select Univariate Profile
Press this pushbutton to copy the selected univariate profile into the
Profile Grouping list.
Select MLR Profile
Press this pushbutton to copy the selected MLR profile into the Profile
Grouping list.
Change Weighting Profile
Press this pushbutton to maintain weighting profiles.

Assignment of Forecast Profile

The forecast profile needs to be assigned to the combination of planning area, forecast key figure,
planning version, and forecast type. These settings are used when entering the DP forecasting
transactions and carrying out a forecast. During these forecasting tasks the used selection ID is
added to the assignment, if not manually done before hand. Planning activities also update the
forecast profile and add any new applied combinations to it, as new assignments.
Life Cycle Definition
In this setting the characteristics that are used for Life Cycle Management are defined per planning
area. These definitions must be done before the assignment of the life cycle profiles (see below).
Like Profile
Access the Like profile via Goto > Like Profile > Define

Like Profile ID and Name

Specify the Like Profile ID and Name. The Like Profile is a time series.
Referenced Product
Irrespective of the Life Cycle Definition (see above), the referenced object in a Like profile
is always a product. Define which product to use. Possible products are not those defined with
a product master but those used (loaded) to the planning area characteristic that contains the
products.
Action

Preparing

338

Use the action key when specifying more than one product in the Like profile. Use S to sum
up all historical data of the defined products, or A to average them.
Weighting Factor
When using several products and summing up their historical data (see Action), it is
required to specify a weighting factor or a weighting profile. All weights can be equal (no
weighting), and the total does not have to be 100. The weighting factor is period independent.
Weighting Profile
Define a period dependent weighting factor (see above).
Movement
Define a number of offset periods if the historical data of the Like product must be applied
with a time delay (positive or negative).

Phase-In/Out Profile Settings

Access via Goto > Phase-In/Out profiles > Settings
These settings determine whether the phase-in and phase-out profiles are related to historical or
future periods or to both (effective periods). The Initial Value is the default value the system
uses for any period that is not covered by the time series. If the forecast horizon is for example 52
weeks and we have defined 0nly 5 values in the phase-in profile, the initial value of 100% will be
used for all periods from 6 through to 52. The proposed default values should be kept.
Phase-In/Out Profiles
Access via Goto > Phase-In/Out profiles > Define

Like Profile ID and Name

Specify the Like Profile ID and Name. The Like Profile is a time series.
Start and End Date
The profile horizon needs to be specified with a fixed start and end date. Use the proposal
pushbutton to let the system propose dates.
Number of Periods
Define the number of periods to be maintained. Note that there is no consistency check
between these periods and the dates defined above. Maintaining for example 12 monthly
values for a period of half a year is permitted.
Period Indicator
The period indicator aligns the data of this profile with the periodicity of the forecast. They do
not have to be the same.
Before Start Date Factor
Use this option to supply default values for the period between the start of the planning period
and the validity start of the profile.
After End Date Factor
Use this option to supply default values for the period between the validity end of the profile
and the end of the planning period.
Edit Time Series
Press this pushbutton to finally maintain the time series values.

Preparing

339

Assign Life Cycle

The last step in the sequence of Life Cycle Management definitions is the assignment of
characteristics to profiles. This assignment is carried out using this option. Note that the layout of
this table depends on the settings above (Define Planning Area Characteristics).

4.2.1.2

Product Master Profiles

The product master profiles facilitate the maintenance of the product master by grouping several
fields that belong logically together into profiles. The profiles contain exactly the same fields as
the product master itself and there is no functional difference whether the information is stored in
a profile or in the product master directly. The profiles can be maintained either from the entry
screen of the product master maintenance, from the menu tree structure or the IMG.
The Profile Maintenance Transaction
The easiest way to maintain the product master profiles is from the entry screen of the product
master maintenance transaction.
Path:
Technical Name:
IMG (Path 1):
IMG (Path 2):
IMG (Path 3):

Master Data > Product

/SAPAPO/MAT1

Supply Network Planning > Environment > Current Settings >

Profiles > Define SNP Demand Profile
Supply Network Planning > Environment > Current Settings >
Profiles > Define SNP Supply Profile
Supply Network Planning > Environment > Current Settings >
Profiles > Define SNP Deployment Profile

Deletion
Profiles can be deleted at any time. In all product master records where a deleted profile is used,
the field contents remains the same but is then directly editable in the product master (i.e. it is not
write protected anymore).
Prerequisites for the Creation
None.
Maintained Fields
The list below shows all product master profiles with the fields they contain. Refer to the product
master section for further detailed information on the respective fields.

Preparing

340

SNP Demand Profile

The SNP Demand Profile is the driver that determines the calculation of demand at any
specific point in time.
Forecast Horizon
VMI Promotion Lead Time
Pull Deployment Horizon
Period Split for Time Based Demand Distribution

SNP Supply Profile

The SNP Supply Profile is used to determine the calculation of the available supply at any
specific point in time. It works in conjunction with the definition of Category Groups and
their allocation to SNP Key Figures.
Production Horizon
Stock Transfer Horizon
Push Deployment Horizon
Deployment Safety Stock Push Horizon
Fix Production
Fix Transports

Deployment Profile
The Deployment Profile links a Fair Share Rule and a Push Distribution Rule to a product.
Note that the Deployment Profile definitions are only used by the Heuristic Deployment run
and not by the Optimizing Deployment run. When using the Optimizing Deployment option,
the distribution is based on the minimal cost/penalty approach rather than on predefined rules.
Fair Share Rule
Push Distribution

Demand Profile
This is not a typing mistake. APO really has an SNP Demand Profile (as discussed above) and
a Demand Profile. The demand profile deals with several parameters that are used not only by
SNP but also by PP/DS.
Demand Profile ID
Demand Profile Name
Proposed Strategy
Always Collective Demand Button
RPM Time Bucket Profile
Possible Individual Customer Demand
Order Network
Consumption Mode
Backward Consumption Period
Forward Consumption Period
Pegging Strategy
Maximum Earliest Receipt ____ before Demand
Maximum Latest Receipt ____ after Demand
Alert if Receipt over ____ before Demand
Under Delivery Tolerance
Preparing

Over Delivery Tolerance

Use Total Order

Lot Size Profile

The Lot Size Profile, which is also sometimes referred to as the Production Lot Size Profile,
is used to calculate the lot size used when creating planned orders for production and
transportation. The following parameters, which are grouped into three segments, can be
defined:
Lot Size Profile ID
Lot Size Profile Name
Lot Size Unit
Lot Size Always pushbutton
Lot for Lot pushbutton
Fixed Lot Size Button
By Period Button
Reorder Point Procedure Button
Minimum Lot Size
Maximum Lot Size
Assembly Scrap
Rounding Value
Rounding Profile
Target Stock Level Method
Target Days Supply
Safety Days Supply
Availability Date Indicator
Period Factor

Other Functions
None.

4.2.1.3

Rounding Profile

The rounding profile is used to round up or down previously established demand. It can be linked
to the product master, the lot size profile, and to the lot size profile for transportation lanes.
The Profile Maintenance Transaction
Path:

Supply Network Planning > Environment > Current Settings >

Profiles > Define Rounding Profiles

Technical Name:
IMG:

/SAPAPO/S_AP9_75000141

Yes

Preparing

342

The user interface of the rounding profile maintenance transaction is in the form of a grid, which
allows easy maintenance of all data as required.
Deletion
Rounding profiles should only be deleted if they are not attached to any other objects they can be
linked to.
Prerequisites for the Creation
None.
Maintained Fields

Rounding Profile
Define a name for the rounding profile. Note that the combination of this field and the next
level is the key for the rounding profile record.
Level
Start with level 1 when creating a new rounding profile. Continue by incrementing this
value by 1 for each new level.
Threshold Value
Define the threshold value, which is the minimum quantity that needs to be reached before the
rounding value of the level is applied.
Rounding Value
Define the rounding value.

Other Functions
None.

4.2.1.4

SNP Lot Size Profile (Transportation Lanes)

The SNP lot size profile (transportation lanes) is linked to the transportation method of a
transportation lane.
The Profile Maintenance Transaction
Path:

Supply Network Planning > Environment > Current Settings >

Profiles > Define Supply Network Planning Lot Size Profiles
(Transportation Lanes)

Technical Name:
IMG:

/SAPAPO/S_AP9_75000095

Yes

Preparing

343

The user interface of the SNP lot size profile (transportation lanes) maintenance transaction is in
the form of a grid, which allows easy maintenance of all data as required.
Deletion
SNP lot size profile (transportation lanes) should only be deleted if they are not attached to any
transportation method.
Prerequisites for the Creation
None.
Maintained Fields
The following parameters can be defined:
Internal Number for Lot Size Profile
There is no need to define this field, as it is automatically generated from the contents of the
next field when the data record is saved.

External Number for Lot Size Profile

Define an identifier for the profile.

Profile Description
Define a description for the profile.
Minimum Lot Size
A minimum lot size can be maintained to ensure a minimum load. The suggested transport
quantity will be at least the quantity specified here. It must be less than the maximum lot size
quantity. The minimum lot size defined for a product must not exceed the maximum quantity
that can be transported on a transportation lane (as defined in the TLB profile).
Maximum Lot Size
A maximum lot size can be maintained to limit the quantity per order (not per load). The
minimum and maximum quantities per load are determined by the TLB profile. It must be
greater than the minimum lot size quantity. More than one transport load will be created if the
required transport quantity exceeds the maximum lot size value.
Rounding Value
A rounding value is used to ensure that transport order quantities are in multiples of this
number.
Rounding Profile
It is possible to branch into the rounding profile, should the rounding parameters offered in
this profile not provide the required level of sophistication. The result of the calculation based
on the rounding profile replaces all numerical settings in this profile.

Other Functions
None.

Preparing

4.2.1.5

344

TLB Profile

The TLB profile is used by TLB planning to optimize the filling of a transport media (e.g. truck).
This applies to both the planning run with the automatic creation of TLB orders, as well as the
manual creation process. Exactly one TLB profile can be linked to a transportation method of a
transportation lane. The TLB profile determines minimum and maximum values for the three
dimensions weight, volume and floor spots. A floor spot is an area onto which one pallet fits. This
determines, together with the stacking factor, how many pallets can be loaded. The profile also
determines the maximum number of days that may be used to pull in deployment orders in an
effort to fill the load.
The definition and linking of a TLB profile is an optional task. If no TLB profile is defined in the
transportation method, the TLB order creation will still work, but for example, no minimum and
maximum values can be adhered to. The TLB profile is also required to enable the graphical
display of load volumes and percentages.
The Profile Maintenance Transaction
Path:

Supply Network Planning > Environment > Current Settings >

Profiles > Define Transport Load Builder (TLB) Profiles

Technical Name:
IMG:

/SAPAPO/S_AP9_75000091

Yes

The user interface of the TLB profile maintenance transaction is in the form of a grid, which
allows easy maintenance of all data as required.
Deletion
TLB profiles can only be deleted if they are not attached to any transportation method.
Prerequisites for the Creation
There are no prerequisites for creating TLB profiles. It is advisable to check that the units of
measure to be used in the profile are existent and defined correctly.
Maintained Fields

Pull In Horizon
The TLB program combines single product deployment orders of a certain period and
transportation method into one or multiple transportation media. Should at the end of this
calculation, a transport media be used below its minimum weight, volume, or possible pallet

Preparing

345

amount (LTL), the TLB run pulls in deployment orders from future periods to achieve a full
truck load (FTL).
Volume Lower Limit
Define the minimum volume that must be achieved. Should the TLB planning run prevail that
there are not enough products, an informational message will be displayed and no TLB is
created.
Note that the system links the various minimum values with a logical OR. This means that
it is sufficient when only one minimum is reached. Do not use a Zero if a minimum
definition is not to be used. Leave it as Space, as this is interpreted as do not use this
minimum. It is displayed in the TLB I/P as a very high figure, and basically disables the
usage of the minimum definition. It can nevertheless have a maximum value that is then
smaller than the minimum value!
Volume Upper Limit
Define the maximum volume that can be loaded. Should the TLB planning run reach this
maximum, the TLB order is closed and a new one started.
Note that the system links the various maximum values with a logical OR. This makes
sense, because as soon as one maximum is reached, the TLB order is closed.
Volume UoM
Define the unit of measure used when determining the TLB profiles minimum and maximum
volume. This unit of measure must also be defined as a product unit of measure (base or
alternate) for all such products that are planned in conjunction with the transportation method
to which the TLB profile is linked.
Weight Lower Limit
See above Volume Lower Limit.
Weight Capacity
See above Volume Upper Limit.
UoM for Weight
See above Volume UoM.
Minimum Number of Floor Spots
A floor spot is a physical area in a transport media (e.g. truck) that can be occupied by one or
multiple pallets. The minimum number of floor spots determines therefore not the minimum
number of pallets to be loaded, but the minimum floor space utilization.
Pallet Positions Upper Limit
Define the maximum number of floor spots (called here pallet positions). The pallet position
(floor spot) number defines the number of stacks. Together with the products stacking factor
(see product master attributes tab), which defines the height of each stack, the total number of
pallets can be derived. A truck might have 33 floor spots (pallet positions) and the product, a
stacking factor of 2. This translates to a total capacity of 66 pallets in this truck.
Pallet Unit
See above Volume UoM.

Other Functions
None.

Preparing

4.2.1.6

346

SNP Optimization Profile

The SNP optimization profile, in conjunction with the SNP cost profile, provides the majority of
parameters required for the SNP and Deployment Optimizer runs. The SNP optimization profile
can be maintained in a very user-friendly way after starting the SNP Optimizer in the SNP
Interactive Planning transaction. Once the SNP Optimizer pop-up window appears, select the
Maintain Optimization Profile button to activate the Optimization Parameters pop-up window.
This is really a much better tool to define all the settings the SNP Optimizer requires. Once used,
one will never again use the customizing transaction where the same task can be carried out. An
introduction to the usage of this pop-up window is part of the introduction to the SDP Interactive
Planning transaction.
For the technically minded, who do not like this comfort, SAP still left the SNP optimization
profile maintenance transaction described here. Note that the fields that can be maintained are
obviously the same in both cases.
Note:

The Deployment Optimizer shares the optimization profile with the SNP Optimizer. Both
optimizers use these profiles.

The Profile Maintenance Transaction

Path:

Supply Network Planning > Environment > Current Settings >

Profiles > Define Supply Network Planning Cost Profiles

Technical Name:
IMG:

/SAPAPO/S_AP9_75000102

Supply Network Planning > Environment > Current Settings >

Profiles > Define Supply Network Planning: Define Optimization
Profile

The user interface of the SNP optimization profile maintenance transaction is in the form of a grid.
Deletion
SNP optimization profiles can be deleted anytime.
Prerequisites for the Creation
There are no prerequisites for creating SNP optimization profiles.
Maintained Fields
The listing of the fields is in line with the pop-up screen of the SNP Interactive Planning
transaction. The group headings are only visible in the SNP Interactive Planning transaction and
not in this transaction. Some fields have different descriptions in the profile maintenance
transaction compared to the interactive optimization parameter maintenance screen.

LP Solver

Preparing

347

Define the variant of the linear programming solver to be used for the continuous
optimization. This setting is only used if the discretization method is not activated. There is no
best setting for this field. The actual quality of the result, as well as the runtime behavior
depends on the data environment.
Primal Simplex Algorithm
Dual Simplex Algorithm
Both algorithms allow for a special feature, called Inner Point Method to be switched on.
The Inner Point Method is an ILOG developed extension that can be used together with the
LP Solver. This setting is only used if the discretization method is not activated.
Inner Point Method
Calculate Profit
Select to optimize according to cost minimization or profit maximization.
Profit Calculation
SNP Horizons
The SNP Optimizer adheres to the production and stock transfer horizons defined in the
product master. This means no orders are placed into these horizons. It might be desired that
the SNP Optimizer also plans in these horizons.
Production Horizon Active
If this flag is switched off, it is advisable to use mixed resources, as the SNP Optimizer
then only plans orders in such periods where the PP/DS finite scheduling planning has
left a gap. In this way no conflicts arise between SNP and PP/DS planning. It is
nevertheless required to convert the SNP generated orders before the next PP/DS
planning run, as PP/DS does not see the SNP generated bucket orientated orders.
Stock Transfer Horizon Active
The usage of this flag is less problematic, as no finite transportation resources are used by
Deployment and TLB. For this reason the double allocation or non-visibility explained
above cannot occur. Care is required nevertheless when using TP/VS, as then finite
resources are used and a similar conflict might arise.
Restrictions
Storage Allocation Quantity
Set this flag if you want the Optimizer to consider available product dependent storage
capacity that is defined in the product master lot size tab (field Product Storage
Capacity, also called Maximum Warehouse Capacity for Product). The definition of a
product dependent capacity overrides a possible defined product independent (location
specific) resource capacity. The Optimizer cannot increase product dependent storage
capacities!
Storage Capacity
Set this flag if you want the Optimizer to consider available product independent storage
capacity, as defined in the location master. All products in a location that do not have a
specific capacity restriction as defined above share the available storage capacity as
defined in the location master.
Handling Capacity
Set this flag if you want the Optimizer to consider available product independent
handling capacity. The handling resource is defined per location and is therefore product
independent. No product dependent handling resources can be defined.
Transport Capacity
Set this flag if you want the Optimizer to consider available product dependent or product
independent transportation capacities. The available transportation capacity is determined

Preparing

348

via the transportations lane transport resource assignment. If the resource is allocated to
the product specific transportation method then the allocation is product dependent; if
allocated to the transportation method it is product independent. In the first case the same
transportation resource can be allocated to several product specific transportation
methods making it again product independent.
Production Capacity
Set this flag if you want the Optimizer to consider the available product independent
production resource capacities.
(Minimum and) Maximum Transport Lot Size
The transport lot size is limited if this flag is set. If used with the Continuous
Optimization, then only the maximum is limited. If used with the Discretization Method
both the minimum and maximum are limited. The transport lot size is maintained in the
product procurement section of the transportation lane and called From Lot Size and
To Lot Size.
(Minimum and) Maximum PPM Lot Size
The PPM lot size is limited if this flag is set. If used with the Continuous Optimization,
then only the maximum is limited. If used with the Discretization Method both the
minimum and maximum are limited. The PPM lot size is maintained in the PPM
assignment of the plan and called Minimum Lot Size and Maximum Lot Size.
Discretization (left panel)
All parameters and flags in this section can only be maintained while the Discretization
Method (full or partial search) is enabled. The discretization of data is not only a resource
intensive task, but it is also more time consuming working with the discretized data. In some
cases it is sufficient to work with only some of the data being discretized, which improves the
runtime.
End Date
o Start Date
The start date is the current date and is not displayed in the profile maintenance
transaction.
o Discretization End Date
Define a discretization end date to limit the amount of data to be discretized. Select
the Maintain Discretization End Date button to change this date.
o End Date
The end date is the current date plus the planning period as defined in the time
buckets profile. It is not displayed in the profile maintenance transaction.
Detailed
Select the detailed option for discretization to reduce the amount of data to be discretized.
The limitation is achieved by reducing the number of elements to be discretized as well
as the duration/granularity of the discretization.
o Production Resource Increase
With this flag set, production capacities are increased in incremental
steps. o Fixed Consumption of Production Resource
o Transports
With this flag set, transportation capacities are increased in incremental
steps. o PPM
With this flag set, PPM lot sizes are increased in incremental
steps. o Transportation Lots
With this flag set, transportation lot sizes are increased in incremental steps.

Preparing

349

o Minimum PPM Lot Size

o Cost Function Transports
o Cost Function Production
o Cost Function External Procurement
Decomposition
Time Decomposition
Set this flag to enable Time Decomposition. Decreasing the time buckets (window size)
supports a better runtime, but also causes a poorer optimization quality. When using this
option, it is required to also define the Initial Window Size for Time Decomposition
(see below). This works only in conjunction with the Continuous Optimization.
Window Size (for Time Decomposition)
The Window Size defines the number of time buckets that are combined in the
Optimization run per time decomposition step. The time buckets in SNP are usually days,
and therefore the number of time buckets that can be defined for Time Decomposition is
the number of days combined in one optimization step. The Basic Solve considers all
days together as one big bucket. The SAP recommended value range is from 2 to 5.
Setting this value to 1 makes the quality of the result similar to this of the Basic Solve
(Simplex) Solution. Greater values improve run time, but lower the quality of the
solution. This works only in conjunction with the Continuous Optimization.
Product Decomposition
When using Product Decomposition, the total planning problem is broken down into
smaller groups of planned products. Decreasing the product partitions supports a better
runtime, but also causes a poorer optimization quality. When using this option, it is
required to also define the Partition for Product Decomposition (see below). Product
Decomposition can be used with the Continuous Optimization and the Discretization
Method.
Window Size (for Product Decomposition)
In this field define the percentage of products that should be considered in each
optimization group. In a sequential approach, each group of products is then optimized
separately. The SAP recommended value range for the partition is from 1 to 30%.
Smaller values improve run time but lower the quality of the solution. Product
Decomposition can be used with the Continuous Optimization and the Discretization
Method.
Prioritization
Cost Based
If hard (strict) prioritization is switched off (i.e. cost based optimization) the optimization
problem is solved in one step and in accordance with penalties that are defined per
priority.
Strict
If hard (strict) prioritization is switched on the optimization is carried out sequentially
per priority.
Priorities of various demand types can in both cases be predefined or can be changed for
some types of demand (see Assignment of Priorities).
Assignment of Priorities
The priority settings work in conjunction with the Continuous Optimization. They have no
direct impact on the run time or the quality of the output. The penalties in the SNP1 tab of the
product master define the penalties for the priorities 1 (customer demand), 5 (demand
forecast), and 6 (corrected demand forecast).
Priority of dependent Demand

Preparing

350

The priority value for the dependent demand can be changed from its default value (hard
constraint) to any priority from 1 to 6.
When using the interactive optimization parameter maintenance screen, only hard
constraint or priorities 1, 5, and 6 can be selected.
Priority of Distribution Demand
The priority value for the distribution demand can be changed from its default value
(hard constraint) to any priority from 1 to 6.
When using the interactive optimization parameter maintenance screen, only hard
constraint or priorities 1, 5, and 6 can be selected.
Priority of Safety Stock
The priority value for the safety stock priority can be changed from its default value 6
(lowest priority) to any other priority from 1 to 5.
When using the interactive optimization parameter maintenance screen, only priorities 1,
5, and 6 can be selected.
Prioritization
Cost Based
Cost based prioritization uses the cost and penalty settings to derive the optimum. This
option is the standard setting if not switched over to strict.
Strict
With strict (hard) prioritization switched on, the Optimizer strictly adheres to the demand
prioritization settings. This works only in conjunction with the Continuous Optimization.
Rounding Limit
Rounding Profile for Production Times
SNP planning is bucket-orientated in terms of available capacity and product availability.
The standard assumption is that within a bucket it does not matter when exactly an
operation has to take place, when the components are required, and when the finished
product can be expected. If the bucket is defined as a weekly bucket and based on the
assumption stipulated above, we do not know exactly what is happening within this
week. This approach, although sufficient for most SNP related planning, is not precise
enough when it comes to optimizing.
The Rounding Profile for Production Times allows the definition of a rounding limit,
which is used to determine whether the finished product availability is set to the
beginning of the current or the following bucket. The following example illustrates this
procedure.
Example:
The optimizer determines availability of the product to be on the 12 th of January 2000.
The bucket size is a week, and the question is now whether to set the availability to the
10th of January 2000 (beginning of the bucket) or to the 14 th of January 2000 (end of
bucket). The time period within the bucket is 5 days.
Case 1:Rounding Limit = 0.3
In this case the calculation of 0.3 * 5 days returns a value of 1.5 days. Our
expected receipt is on day 3. As 3 is greater than 1.5, the receipt is scheduled to
be at the end of the current bucket (which is the same as the beginning of the
next bucket).
Case 2:Rounding Limit = 0.7
In this case the calculation of 0.7 * 5 days returns a value of 3.5 days. Our
expected receipt is on day 3. As 3 is smaller than 3.5, the receipt is scheduled to
be at the beginning of the current bucket.
Rounding Profile for Transportation Times

Preparing

351

The Rounding Profile for Transportation Times follows the same logic as the Rounding
Profile for Production Times (see above).
Discretization (right panel)
Select one of the two available discretization methods as required, or set this field to None.
Discretization does not permit the selection of Time Decomposition or Hard
Prioritization.
None
No discretization sets the optimizer into the Continuous Optimization, which is either
primal or dual, as specified in the Variant of LP Solver field.
Full Search
A full search discretization optimization mode ensures that the provided result is the
objective optimum, based on all specified constraints. This is true as long as the run time
was not limited.
Partial Search
The partial search discretization optimization mode provides a reasonably good, but
worse result compared to the full search mode. Its benefit is an improved run time.
Aggregation
Product Hierarchy
Planning is carried out on an aggregated level per product group. In order to use this
functionality, product groups with corresponding PPM have to be created, as well as
product and PPM hierarchies. This approach is also referred to as vertical aggregated
planning.
Distribution Hierarchy
Set this flag to carry out the optimization only for a subset of the supply chain model.
This approach is also referred to as horizontal aggregated planning.
Search Limit
Maximum Number of Iterations
For full search Discretization Methods, the maximum number of iterations (also
referred to as the search limitations) limits the number of attempts to find an improved
solution. A greater number of permitted iterations increases the likelihood to find the
optimal solution.
Maximum Runtime
When using full search Discretization Methods, the maximum runtime in the format
<mm:ss> can be preset.
Preferred Rounding Limit
Transportation
The rounding limit (or rounding threshold) for transportation is used in conjunction with
the partial search Discretization Method, and is used to transform the continuous
transportation lot size values into integer values. The value range is from 1 through to 99.
Production
The rounding limit for production is used in conjunction with the partial search
Discretization Method, and is used to transform the continuous production lot size values
into integer values. The value range is from 1 through to 99.

The following table provides a quick overview of the SNP optimizer profile settings (parameters)
and their applicability to the SNP optimization methods. Dark gray shaded cells with an X
indicate that the option can be used with the optimization method.

Method
Parameter
Preparing

Method

Parameter
Variant of LP Solver
IPM
Optimizer Target (Cost/Profit)
Discretization Method
Hard (Strict) Prioritization
Priority of Dependent Demand
Priority of Distribution Demand
Safety Stock Priority
Time Decomposition
Initial Window Size for Time
Decomposition
Product Decomposition
Partition for Product
Decomposition
Storage Allocation Quantity
Handling Resources
Storage Capacity
Transport Capacity
Production Capacity
Minimum and Maximum Transport
Lot Size
Minimum and Maximum PPM Lot
Size
Rounding Profile for Production
Times
Rounding Profile for Transportation
Times
Discretization Details
Maximum Number of Iterations
Preparing

353

Method
Parameter
Maximum Runtime
Rounding Limit for Transportation
Variable
Rounding Limit for Production
Variable

Table 74 General Optimization Parameters

Parameter
Discretization End Date
Production Resource Increase
Fixed Consumption of Production Resource
Transports
PPM
Transportation Lot Sizes
Minimum PPM Lot Size
Cost Function Transports
Cost Function Production
Cost Function External Procurement
Table 75 Discretization Mode Parameters

Other Functions
None.
Important Note
In order to perform the optimization in discrete mode, some parameters need to be defined that are
not part of the optimization profile. To do so, use transaction /SAPAPO/COPT10 and add the
following entry:

Preparing

354

Parameter
Module
Identifier
Section
Name
Switch
Integer (*)
Table 76 Additional Discretization Parameters
(*) The integer is the number of periods and should not be lower than the number of time buckets
that the optimizer uses.

4.2.1.7

SNP Optimization Bound Profile

The Optimization Bound Profile can be applied as an optional definition. It does not replace any
other optimization profile or setting.
The Profile Maintenance Transaction
Path:

Supply Network Planning > Environment > Current Settings >

Profiles > Define Supply Network Planning Optimization Bound
Profiles

Technical Name:
IMG:

/SAPAPO/BOUND

Supply Network Planning > Environment > Current Settings >

Profiles > Define Supply Network Planning: Define Optimization
Bound Profile

The user interface of the SNP optimization bound profile maintenance transaction is in the form of
a grid.
Note:

The Deployment Optimizer shares the optimization bound profile with the SNP
Optimizer. Both optimizers use these profiles.

Deletion
The Optimization Bound Profile can be deleted at any time.

Preparing

355

Prerequisites for the Creation

There are no prerequisites for the creation of Optimization Bound Profiles.

Maintained Fields

Sequence
When using telescoping planning buckets profiles, multiple periodicities can be used. The one
closest to the planning start has the sequence number 1. Define the appropriate number.
Define 1 if no telescoping planning buckets profile is used.
Period
Define the periodicity linked to the sequence number (month, week, or day).
Number
Define the number of periods of the optimization bound profile sequence number.
Upper Limit Flag
Set this flag so that the defined upper deviation is applied.
Deviation (+%)
Define the maximum permitted positive deviation between previous and current optimization
run.
Lower Limit Flag
Set this flag so that the defined lower deviation is applied.
Deviation (-%)
Define the maximum permitted negative deviation between previous and current optimization
run.
Base Value
The base value is the value of the decision variable in the previous optimization run. This
value might be Zero. In this case the deviations would also be Zero and thus not permitting
any change. To avoid this deadlock, define how to derive an artificial base value if the real
base value was Zero. Possible settings are to calculate the base value as follows.
Average
Use the average of all buckets of the specified periodicity within the planning period.
Maximum
Use the bucket with the highest value of all buckets of the specified periodicity within the
planning period.
Minimum
Use the bucket with the lowest value of all buckets of the specified periodicity within the
planning period.

Other Functions
None.

Preparing

4.2.1.8

356

SNP Cost Profile

The SNP cost profile contains multipliers that are used by the SNP Optimizer to multiply the costs
and penalties specified in the resource and product master. When optimizing according to cost and
penalties, the SNP Optimizer can put different weights on the cost and penalty definitions, without
actually changing the stored values. This is particularly helpful when carrying out a What-If
analysis. It is recommendable to initially leave the settings at their default values, and only change
them when performing what-if analyses, or to fine-tune the optimization results.
The SNP cost profile can also easily be maintained, after starting the SNP Optimizer in the SNP
Interactive Planning transaction. Once the SNP Optimizer pop-up window appears, the factors
contained in this profile can be changed graphically by means of moving a sliding bar. The
changed factors can also be saved.
Note:

The Deployment optimizer shares the cost profile with the SNP optimizer. Both
optimizers use these profiles.

The Profile Maintenance Transaction

Path:
Technical Name:
IMG:
The user interface of the SNP cost profile maintenance transaction is in the form of a grid.
Deletion
SNP cost profiles can be deleted anytime.
Prerequisites for the Creation
There are no prerequisites for creating SNP cost profiles.
Maintained Fields

Profile ID
Define an identifier for the profile.
Profile Description
Define a name for the profile.
Production Process Model
In each Production Process Model (PPM) you define a (output quantity dependent) penalty.
The cost multiplier in this parameter picks up this cost and multiplies it accordingly. The
PPM dependent variable penalty does not include the cost of components used in the planned
order. This multiplier does not affect the variable cost for the usage of the resource either.

Preparing

357

Procurement
Multiplies the procurement cost of the product as defined in the product master GR/GI tab.
The procurement cost consists potentially of quantity dependent and independent elements.
The multiplier influences both.
Production Capacity Increase
Multiplies the penalty for additional use of resource as defined in the resource capacity
variant
2. It only comes into effect if the capacity defined in capacity variant 1 is not sufficient. There
is no multiplier for capacity variant 1.
Transport Capacity
Multiplies the penalty for use of a transportation resource. The cost is defined per
transportation method in the transportation lane.
Transport Capacity Increase
Multiplies the penalty for additional use of transportation resource as defined in the resource
header. This multiplier uses the settings of the resource capacity variant 2.
Storage Capacity
Multiplies the penalty for use of a storage resource. The storage cost is defined in the product
master.
Storage Capacity Increase
Multiplies the penalty for additional use of storage resource as defined in the resource header.
This multiplier uses the settings of the resource capacity variant 2.
Safety Stock Violation
Multiplies the penalty for violating the safety stock as defined in the product master
procurement tab.
Handling Capacity Increase
Multiplies the penalty for additional use of handling capacity as defined in the resource
variant
2. It comes only into effect if the capacity defined in capacity variant 1 is not sufficient. There
is no multiplier for capacity variant 1.
Delay
The product master allows on the SNP1 view the definition of penalties for Late and NonDelivery. These values are defined separately for Sales and Forecast requirements. In the case
of forecast requirements the term delivery refers to the time where the stock is posted on
hand. The delay penalty can be set to come only into effect after a certain (grace) period. With
the Cost Multiplier for Delivery Delay parameter, these penalties can be multiplied as
required. The penalty and this multiplier are per base unit of the product and day. It is applied
to both, the penalty for sales order and forecast demand.
The Penalty for Late (and Non) Delivery can be used to optimize on Profit. The higher the
anticipated product profit is, the higher the individual products penalty should be set up. If
this is the case, the SNP optimizer tries to ensure that demands for those products with high
penalty (profit) are satisfied first. This and the following cost multiplier can be used to
balance this profit-orientated optimization with other goals.
Non-Delivery
This parameter works the same as the one explained above. The only difference is that the
Cost Multiplier for Non Delivery comes into effect in situations of non-delivery. The penalty
and this multiplier are per base unit of the product and day. It is applied to both the penalty for
sales order and forecast demand.

Other Functions

Preparing

358

None.

4.2.1.9

Factory Calendar

In most cases, the factory calendars of the delivered system are sufficient and do not require any
changes.
The Profile Maintenance Transaction
Path:
Technical Name:
IMG:
IMG Path:

n/a
n/a

Yes (not via user menu)

General Settings > Maintain Calendar

Deletion
These settings should only be maintained and deleted with care. Deletion of used entries is not
possible.
Prerequisites for the Creation
None.
Maintained Fields

Public Holidays
A wide range of public holidays are predefined on the standard delivered system. New ones
can be added using various rules that cater for example for floating holidays. Public holidays
that are used in any calendar cannot be changed anymore.
Change existing, or add new public holidays as required.
Holiday Calendar
The system is delivered with a range of holiday calendars for various regions. The holiday
calendars exclude company specific non-working days.
Change existing, or add new holiday calendars as required.
Factory Calendar
The factory calendar combines the holiday calendar with company specific non-working
days. Various predefined calendars are delivered with the system.
Change existing, or add new factory calendars as required.

Other Functions

Preparing

359

None.

4.2.1.10

Time Stream

Time streams have a precision of second. They can be linked to factory calendar settings, which
have a daily precision. In this case the factory calendar information with its working day
definitions is combined with the time steam definition. The result is what is referred to as a time
stream or planning calendar. This time stream depicts for each second whether it is working or
non-working time. Time steams are used for example with locations where they are used to
determine e.g. shipping times.
The time stream is also referred to as planning calendar but must not be mixed up with the
factory calendar.
The Profile Maintenance Transaction
Path:
Technical Name:
IMG:

Supply Network Planning > Environment > Current Settings >

Maintain Planning Calendar (Time Steam)
/SAPAPO/CALENDAR
Yes

The time stream transaction has one main screen with three different tabs. The usage is not too
complicated but it must be kept in mind that after every change, the time stream must be
generated again. Simply saving information is not sufficient.
Deletion
Time streams can be deleted anytime even if they are used in a master data object like a location.
Prerequisites for the Creation
Factory calendars and time zones need to be defined or at least checked beforehand.
Maintained Fields

Header Tab
General Data
The time stream is generated for the period as defined in the next two settings. There is
no need to define a high amount of years into the past. A common setting is 1 year into
the past and 5 into the future.
o Years in Past
o Years in Future

Preparing

360

The definition of a time zone links the time stream to the time zone settings. This
includes the automatic switchover to and from daylight saving time if this is defined in
the time zone.
o Time Zone
Calculation
The fields here need to be read with care. The expressions factory calendar and period
calendar both refer to specific types of time streams (or planning calendars and not to
the previously discussed factory calendar. The expression calendar means factory
calendar as discussed previously.
o Factory Calendar (with gaps) should be Calendar with gaps
o Period Calendar (without gaps) should be Calendar without gaps
o Calendar should be Factory Calendar
The definition of a factory calendar links the time stream to the working days as defined
in this time stream (planning calendar). Time streams that are not linked to any factory
calendar show every day as a workday.
Calculation Rule Tab
First select the calculation rule pop-up window before generating the time stream.
Select Calculation Rule Pop-up Window
The calculation rule determines the pattern within which the definition of the working
times is repeated. The time generated time stream usually has a pattern (e.g. the same
working hours every week). By defining this pattern it is possible to reduce the number
of entries that have to be carried out manually. Selecting week for example returns a
screen where the working times can be defined for the seven days of the week. During
the generation process this weekly pattern will be copied into every week, adjusted
possibly by factory calendar and the time zone definition.
o Week (weekdays)
Provides a 7-day display enabling weekly repetition
o Month (weekdays)
Provides a 7-day display enabling monthly repetition
o Shifts
Provides a 7-day display with three shifts per day.
Entry Grid
The entry changes in accordance with the selected calculation rule. Define the required
start and end time per period.
Generate Periods Button
Once all definitions have been carried out, the time stream must be generated. Simply
saving the time stream is not sufficient!
Change Calculation Rule Button
The change calculation rule button opens the calculation rule pop-up window, permitting
the allocation of a new calculation rule.
Periods Tab
On this tab all time periods are displayed that were generated by the system in accordance
with the calculation rule. They can now be manually changed if required.
From Date
From Time
To Date
To Time
Note

Preparing

361

The notes field is used to display messages.

Fixed
Use the fix button to fix a value. In this case the defined date for the period will not be
changed by any consequent regeneration of periods.
Other Functions
None.

4.2.1.11

Transportation Method

The transportation method maintenance of existing transportation methods can be carried out in
the Supply Chain Engineer, or while maintaining the transportation lanes. The maintenance and
creation of transportation methods can only be carried in the IMG.
The Profile Maintenance Transaction
Path:
Technical Name:
IMG:
IMG Path:

n/a
n/a

Yes (not via user menu)

Advanced Planner and Optimizer > Alert Monitor > Maintain
Transportation Methods

The user interface of the transportation method maintenance transaction is in the form of a grid,
which allows easy maintenance of all data as required.
Deletion
Transportation methods can only be deleted using the IMG based maintenance option.
Prerequisites for the Creation
None.
Maintained Fields

Transportation Method
Display only, but new entries can be created when the transportation method is maintained
from the IMG.
Vehicle (Description)
Display only, except when maintained from the IMG

Preparing

362

Average Speed
The Average Speed is used to calculate transportation times based on the distance between
two locations when using the Generate Proposal button during the transportation lane based
transportation method maintenance.
Unit of Measure for Average Speed
This is a display only field, as defined in the Settings for Units of Measure.
Distance Factor
The distance factor is used by TP/VS to calculate real distances when using transportation
zones.
Resource
The resource that can be defined here is loaded with capacity requirements whenever a
transport takes place using this transportation method. Defining a resource here provides an
easy to manage overview of all transportation resource requirements for a specific
transportation method.
Setup Time
Fixed time segment applied when using the transportation method in hours and minutes.
Work Time
Average operational time when using the transportation method in hours and minutes per
workday.
Compatibility
The Compatibility indicator allows switching on the compatibility check for a specific
transportation method. Possible options include:
1. No Check
The transportation method can be used for products belonging to any transportation
group.
2. Compatible
The transportation method can be used only for those products belonging to the
transportation groups that are defined in the Vehicle/Transport Group Compatibility
table.
3. Incompatible
The transportation method cannot be used only for those products belonging to the
transportation groups that are defined in the Vehicle/Transport Group Compatibility
table. All products not belonging to any transport group defined in this table can be
transported using this transportation method, without restrictions.
In order for option 2 and 3 to work, it is required to maintain the Vehicle/Transport Group
Compatibility table. This can be done starting in the menu structure or in the IMG. After this
table has been maintained, the Compatibility flag described here must be set as required, as
otherwise the settings in the Vehicle/Transport Group Compatibility table are not used.
Transportation Mode
The Transportation Mode is used to group various Transportation Methods. It is used in the
TP/VS environment.
Flag for Own Transportation Method
Determines that the Transportation Method describes an own fleet.
Flag for Scheduled Transportation Method
Determines that the Transportation Method describes a scheduled service that operates at
predetermined times.

Other Functions

Preparing

363

None.

4.2.1.12

External Cost Function

Various master data objects permit the definition of procurement or procurement related costs that
are used by optimization routines (e.g. the SNP Optimizer) and/or for the determination of the
lowest cost supply in a heuristics approach. Procurement costs in this context include purchasing,
transportation, and production cost. Common to all these cost definitions is that they are defined
per unit, and without a fixed cost component, thus representing a linear cost function starting at
Zero. The cost functions permit the definition of several fixed and variable costs. Cost functions
are linked to the product master, the transportation lane and the plan where their definitions are
used instead of the single cost value.
The SNP Optimizer can use the external cost functions only with some limitations. The limitations
depend on the optimization mode and whether the cost function is linear or not (convex or
concave).
The Profile Maintenance Transaction
The maintenance of cost functions can be carried out from those master data transactions that use
cost functions. The maintenance of cost functions used for procurement costs can for example be
maintained while being in the product master maintenance (procurement tab). There is no
possibility to maintain the external cost functions directly from the tree structure. The user
interface of the external cost function transaction is in the form of a multi-line grid, which allows
the definition of as many lot size ranges as required.
Deletion
Cost Functions can be deleted at any time but this leads to a situation where the cost data is not
defined anymore in those master data objects, the external cost profile was attached to.
Prerequisites for the Creation
None.
Maintained Fields

Cost Function
The cost function ID can be any alphanumeric string. This ID is independent of the
procurement type for which the external cost function is defined.
Description
Define a name as required.
Procurement Type

Preparing

364

The procurement type indicators used here are T for transportation, F for external
procurement and P (not E!) for internal procurement/production.
Unit of Measure
The lot size range defined in the grid relates to the unit of measure defined here and not to the
products base unit of measure. It is nevertheless required that the unit of measure used in the
cost function relates to that used in the product master.
Grid Display
The grid display permits the definition of as many lot size ranges as required. The upper limit
is set automatically to the maximum value. For each lot size range the fixed and variable cost
can be defined.
From
To
Fixed Cost
Variable Cost

Other Functions
None.

4.2.1.13

Hierarchy Structure

The term hierarchy in APO refers to a technical structure that contains pointers to master data
objects. Hierarchies can be defined for locations, products, location products, resources, and for
the PPM. They are used in some Supply Network Planning activities such as for example the
vertical aggregated optimization. Before a hierarchy can be defined, it is required to define the
hierarchy structure. The hierarchy structure determines, amongst other information, which master
data objects the hierarchy is used for, and how many levels there are. The hierarchy structure is
depicted in the graphic below.

Preparing

365

G en eral D efin itio n s

H ie ra rch y S tru ctu re ID

H ie ra rch y S tru ctu re N a m e
N o d e T yp e
H ie ra rch y T yp e
O b je ct T a b le N a m e

S ch em a H ierarch y
D efin itio n s
H ie ra rch y S tru ctu re ID
L a n g u a g e ID
S ch e m a F ie ld
S e p a ra to r
G en erated H ierarch y
D efin itio n s
H ie ra rch y S tru ctu re ID
H ie ra rch y S tru ctu re ID (2 )
H ie ra rch y Ite m
H ierarch y S tru ctu re
L evel D efin itio n s
H ie ra rch y S tru ctu re ID
L e ve l ID
L e ve l N u m b e r

H ierarch y S tru ctu re L

evel T ext D efin itio n s
H ie ra rch y S tru ctu re ID
L e ve l ID
L a n g u a g e ID L
e ve l T e xt

G en erated H ierarch y L
evel D efin itio n s
H ie ra rch y S tru ctu re ID
L e ve l ID
H ie ra rch y S tru ctu re ID (2 ) L e
ve l ID (2 )

Graphic 106 Hierarchy Structure

Hierarchies can have levels that are identified by numbers from 1 upwards. In this case the
hierarchy structure level number depicts the level by means of this number. The top level is always
1. SAP calls these hierarchies simply Hierarchies. Alternatively, the hierarchy levels are
named. With this option each subordinate level must have more digits than the superior one (e.g.
level 1 has 2 digits, level 2 has 4 digits and so on). The hierarchy elements are automatically
linked to the hierarchy based on the defined levels. SAP calls these hierarchies Schema
Hierarchies.
Generated hierarchies are those that are based on two other hierarchies. Currently in APO there is
only one possible generated hierarchy structure, being the one for location products. Generated
hierarchies cannot, and do not need to be maintained. They are displayed based on the subordinate
hierarchies they are derived from. An entry in such a subordinate hierarchy can be seen in the
generated hierarchy without further actions. If for example both subordinate hierarchy structures

Preparing

366

have three levels, then the generated hierarchy structure can technically have any number of levels
between one and nine. Whether this makes logically sense depends on the master data objects and
information stored in the respective hierarchies. Some restrictions apply to the possible definitions
of generated hierarchies. The linking of levels from both subordinate hierarchy structures can be
understood easily when following the graphic below.

Product Hierarchy
Structure

Brand

Product Group

Product

Graphic 107 Permitted Level Combinations

The above example shows the two hierarchy structures for location and product. The location
hierarchy structure has three levels.

Region

Country

State
The product hierarchy structure also has three levels.

Brand

Product Group

Product
To determine the permitted level combinations, simply connect both hierarchy levels by lines,
which first of all must not cross, and secondly must have a specific direction (either top-down or
bottom up). Any violation of this rule is a non-permitted level combination. Two examples are
shown above. In the second example the generated level combination 4 is not possible.
The definition of the hierarchy structure is carried out in the IMG as one of the preparatory
customization tasks. The population of hierarchies is master data maintenance activity. After the
hierarchy structure has been defined, the hierarchy is created. Only then the master data
maintenance of the hierarchy can be carried out.
The Hierarchy Structure Maintenance Transaction

Preparing

Path:
Technical Name:
IMG

367

<Only in IMG>
<Only in IMG>
Yes

Information for the hierarchy structure can be found on several levels as shown in the graphic and
outlined below. To drill down to a lower level, select a line in the grid and double-click on the
lower level line.
The most confusing part when starting to maintain hierarchy structures and hierarchies, is the
multitude of names, and the fact that some of them are not used at all. Others are so similar that it
is easy to mix them up. The only way to solve this is to start defining own hierarchy structures and
hierarchies, and using improved (easier to distinguish) descriptions.
Maintained Fields

Hierarchy Structure ID
Define an ID for the hierarchy structure. This ID is used to uniquely identify the hierarchy
structure. It is displayed when creating a hierarchy.
Hierarchy Structure (Name)
Define a language independent technical name for the hierarchy structure. This name is
displayed on the initial and main hierarchy maintenance transaction screen.
Node Type
The node type determines which master data objects are part of the hierarchy (e.g. products).
Select one of the possible values.
Hierarchy Type
Select the hierarchy type (e.g. generated hierarchy).
Link Table
Select the appropriate table in accordance with the node type.
Hierarchy Structure Text
Define a language dependent name for the hierarchy structure. If no language dependent name
is defined, the system displays the Hierarchy Structure (Name) only.
Hierarchy Structure ID
Language
Select a possible language key.
Hierarchy Structure Text
Define a language dependent name for the hierarchy structure. This name is displayed on
the main hierarchy maintenance transaction screen.
Definition for Characteristics Schema Hierarchy Structure
Hierarchy Structure ID
Fieldname Character Schema
Define the technical field name of the field that should be used for building up the
hierarchy.
Separator for Character Schema
Define a separator that might be incorporated in the field that is used for building up the
hierarchy.
Definition for Generated Hierarchy Structure

Preparing

368

This section only requires maintenance for hierarchy structures of the type Generated
Hierarchy Structure. For all other hierarchy structures, keep it empty.
Hierarchy Structure ID
Hierarchy Structure ID (2)
Select the first hierarchy structure ID that is part of the generated hierarchy (the location),
and define the hierarchy item number 1. Then select the second hierarchy structure ID
that is part of the generated hierarchy (the product), and define the hierarchy item number
2.
Hierarchy
Item
See
above.

Hierarchy Structure Level Definition

Hierarchy Structure ID
Levels ID for Object Hierarchies
Define a level ID. A new level ID is created by simply typing the name of it. It will then
in future also appear when using the Possible Entries (F4) function. This ID is used to
uniquely identify the hierarchy structure level. It is not displayed in other transactions.
Level Number for Object Hierarchies
Define a level Number. This name is displayed on the grid of the main hierarchy
maintenance transaction screen.
Text for Levels of the Hierarchy
Structure o Hierarchy Structure ID
o Levels ID for Object Hierarchies
o Language
Select a possible language key.
o Text for Levels of the Hierarchy Structure
Define a language dependent name for the hierarchy level. This name is displayed on
the grid of the main hierarchy maintenance transaction screen.
Level Assignment for the Generated Hierarchy Structure
This section only requires maintenance for hierarchy structures of the type Generated
Hierarchy Structure. For all other hierarchy structures, keep it empty.
o Hierarchy Structure ID
o Levels ID for Object Hierarchies
o Hierarchy Structure ID (2)
Select the first combination of hierarchy structure ID and level ID that are part of the
generated hierarchy (the location), and allocate a new level ID. There are some
restrictions when creating the level assignments (see above).
o Levels ID for Object Hierarchies (2)
See above.

The Hierarchy Maintenance Transaction

The creation of a new hierarchy is certainly more straightforward than the creation of a hierarchy
structure. There is no need to define different hierarchy structures for each hierarchy. If the
hierarchy structures delivered in the standard system are sufficient, it is recommendable to just
copy them, and use the copies as a base for own hierarchies.
Path:

<Only in IMG>

Preparing

369

Technical Name:
IMG

<Only in IMG>
Yes

Hierarchy ID
Define an ID for the hierarchy. This ID is used to uniquely identify the hierarchy structure. It
is not displayed in other transactions.
Hierarchy Text
Define a language independent technical hierarchy description (text). It is not displayed in
other transactions.
Hierarchy Name
Define a language independent technical name for the hierarchy. This name is displayed on
the initial and main hierarchy maintenance transaction screen.
Hierarchy Structure ID
Select a hierarchy structure as defined in the previous step. The definitions of this hierarchy
structure determine the hierarchys functionality.
Hierarchy Text
Define a language dependent name for the hierarchy. If no language dependent name is
defined, the system displays the Hierarchy Name only.
Hierarchy ID
Language
Select a possible language key.
Hierarchy Text
Define a language dependent name for the hierarchy. This name is displayed on the main
hierarchy maintenance transaction screen.
Def. Generated Hierarchy
This section only requires maintenance for hierarchies of the type Generated Hierarchy
Structure. For all other hierarchies, keep it empty.
Hierarchy ID
Hierarchy ID (2)
Select the first hierarchy structure ID that is part of the generated hierarchy (the location),
and do not set the checkbox flag. Then select the second hierarchy structure ID that is
part of the generated hierarchy (the product), and set the checkbox flag. These settings
must be done in accordance with the hierarchy structure settings on which the hierarchy
is based.
Checkbox
See
above.

4.2.1.14

Requirements Strategy

The requirements strategy definitions are important as they determine the way a product is
planned, including the creation of independent requirements, and the consumption thereof
(forecast consumption). The various requirements strategies defined in this profile have the same
name as on an attached R/3 system. These predefined requirements strategies should only be
changed with care, or, better if required, new ones be created.
The Profile Maintenance Transaction

Preparing

370

Path:

Supply Network Planning > Environment > Current Settings >

Profiles > Define Supply Network Planning Requirements
Strategies

Technical Name:
IMG:

/SAPAPO/S_AP9_75000142

Yes

Deletion
Deletion is possible anytime but it is strongly recommended not to delete (or even change) the
standard delivered requirements strategies. The requirements strategy must not be deleted while
being used in products.
Prerequisites for the Creation
There are no prerequisites.
Maintained Fields

Planning Parameters
Category
The category determines the order type of the orders in which the forecast is stored. This
forecast value is then used during the forecast consumption (if activated). In the standard
delivered system, this is the category FA but other categories could be specified.
Changes need to be carried out with care, as illogic definitions might lead to data
corruption. The order type specified here is used for all such products that have the
requirement strategy defined as their Proposed Strategy in the product master. In a
situation where a product is planned (forecasted) according to several requirements
strategies, separate requirements strategies with different category groups need to be set
up. Forecasts from DP are then released separately and the independent requirements are
then created within SNP in accordance with the requirements strategy settings.
The order category defined in the products proposed strategy also determines the
forecast values shown in the PP/DS Product View transaction.
Planning Segment
Select one of the following segments.
o Segment 0: Make-to-Stock

Demand is satisfied using warehouse

stock o Segment 1: Make-to-Order
Demand is satisfied using stock reserved for individual sales
orders o Segment 2: Make-to-Order (planning strategy 52 in R/3)
This is used when a combination of planning without final assembly, and without
make-to-order is required. It is the equivalent of the planning strategy 52 in R/3.
Planning Version
Define the planning version in which the forecast consumption has to be carried out.
Leaving this field blank, results in the forecast consumption being carried out in the
active planning version (000). Sales orders are processed in the APO active version but
can

Preparing

371

consume the forecast of another planning version if defined in the requirements strategys
planning version field.
Assignment
Assignment Mode
Determines how sales orders consume the
forecast. Blank = No assignment
1 = Assignment of customer requirements: Planning with assembly
2 = Assignment of customer requirements: Planning without assembly
3 = Assignment of customer requirements to planning product
Note that the product master field check mode is irrelevant for the R/3 sales order
initiated forecast consumption. It is driven by the settings in this profile.
Category Group
Which order types consume the forecast is defined in the category group of the
requirements strategy profile. The category group combines all such demand elements
that trigger this forecast consumption. The requirements strategy might also define no
consumption in the field Assignment Mode (above) in which case the settings here are
irrelevant.
The standard delivered system uses category group K01 which has the order category
BM (sales order) attached to it. Other order categories can be added resulting in various
order categories triggering the forecast consumption.
This needs to be done if forecast consumption should be carried out, based on sales
orders and on, e.g. dependent demand or transportation demand.

Other Functions
None.

4.2.2

General Master Data

The majority of master data objects is jointly used by multiple, if not all modules of APO. This
type of master data is referred to as general master data. There are also some module specific,
master data objects that are dealt with separately.

Location

The following graphic provides a high level overview of the general master data objects within
APO, and their relation to each other.
Preparing

H ier a rc h ie s

Graphic 108 Master Data Overview

Most master data objects can be created independent of any supply chain model, but need then to
be allocated to a supply chain model, before they can be used within the specific model. The way
the system handles these allocations is different from one master data object to the next.

Location
The model independent location master record, and the location master record assigned to the
active model are one and the same. Planning version specific location master records can be
created, which are then used automatically instead of the model independent record.
Planning version specific location master records can only be created for such planning
versions that are linked to a supply chain model to which the location master record is
assigned.

Product
While the product master is allocated to the supply chain model as required, no additional
planning version specific record is created. Planning version specific product master records
can be created, which are then used automatically instead of the model independent record
when required. This includes the possibility to create a planning version dependent product
master record for the active planning version. Only the location dependent portion of the
product master record can be defined planning version specific; the location independent
portion always remains model independent.
Planning version specific product master records can only be created for such planning
versions that are linked to a supply chain model to which the product master record is
assigned.

Resource

Preparing

373

During the assignment of the resource master record to a supply chain model, the system
automatically copies the model independent definition and creates a new planning version
specific record per planning version that is defined for the supply chain model. This can easily
be overlooked, but is important to remember that all resource master data maintenance must
be carried out per planning version once the resource master is assigned to at least one supply
chain model.
Definitions
The definitions, which can be seen as a special extension of the resources, follow the same
principle as the resources. Whenever a resource is attached to a supply chain model, all the
definitions that are used with the resource are used to create a planning version dependent
copy of the definition.
Plan and PPM
The plan and the PPM are both not defined per planning version, although some time
dependent parameters of the plan can be defined per planning version of the supply chain
model that the plan is attached to.
Transportation Lane
The transportation lane can only be created within a supply chain model. It does therefore not
need to be specifically linked to any supply chain model. No planning version specific
transportation lanes can be created. Some of the data carried across from the R/3 system is
only available in the active planning version (000).
Quota Arrangement
The quota arrangement can also only be created within a supply chain model. It does therefore
not need to be specifically linked to any supply chain model. Planning version specific quota
arrangements can be created. The SNP Optimizer always creates planning version specific
quota arrangements if the Create Quota Arrangement option is enabled.
Classes and Characteristics
No planning version dependent characteristics and classes can be created.
Hierarchies
No planning version dependent hierarchies can be created.

4.2.2.1

Location

Within APO, locations represent physical or logical entities that can be linked to supply chain
models, and are used in the planning task. Various location types exist, distinguishing them
according to their usage and possible planning tasks that can be carried out. The currently possible
location types with their technical identifiers are:
Production Plant
Distribution Center
Transportation Zone
Stock Transfer Point
MRP Area
Customer
Supplier
Carrier (Logistics Service Provider)
Terminal (release 3.1 only)
Geographical Area (release 3.1 only)
Preparing
374

In general, a location is anything where products either come from, go to, or where they are
stored, handled or planned. Some of the location types represent logical units, rather than physical
places. The user allocates a location type to the location while creating the master record. This
allocation cannot be subsequently changed. Amongst other things like the icon used for the
location, the location type also influences the available information that is displayed in the

location master record on various tabs. There are fields as well as tabs that are only available for
specific location types.
Up to 5 additional fields can be defined in customizing to be displayed in the location master
maintenance transaction. They are not required to support any standard function within APO. The
names of these 5 fields are freely definable. The Additional tab (also called Extras tab) on
which these fields can be displayed and maintained is only displayed if this function was activated
during customizing.
The Master Data Maintenance Transaction
Path:
Technical Name:

Master Data > Location > Location

/SAPAPO/LOC3

The location master maintenance screen consists of various tabs, each dedicated to a specific
aspect. There are only very few fields that need to be maintained to get a location up and running
(e.g. the calendars), but there is lots that can be defined if required.
Two function buttons are placed on the top bar of the initial menu. The Set Planning Version
allows defining the planning version to which the location data refers. The default version used,
even it is not displayed, is 000. The Assign Model button is used to assign and de-assign the
location to Supply Chain Models. Both functions can also be performed via the menu option
Extras.
Whenever the location master transaction is started it unfortunately applies the same planning
version that was used in any planning transaction used previously. It is then required via the Set
Planning Version function to either select planning version 000, or leave the field blank. In
both cases the system brings up the location master with planning version 000, which is at the
same time the model independent version.
Deletion
The deletion of locations is a multi step process. Firstly, all other objects that use a location or
refer to it must be either changed or deleted. If for example a PPM exists for a location that needs
to be deleted, the PPM must either be changed so that it does not refer to the specific location, or it
must be deleted. The same applies to any location product and/or resource that is used. It is also
required to de-assign the location from any Supply Chain Model it is assigned to. Once all these
preparations are carried out, the location can be marked for deletion (option Location > Mark for
Deletion). Then, in a subsequent step, the actual deletion takes place (menu option Extras > Delete
Locations).
Preparing

While the location master record is deleted, its assignments to supply chain models cease as well.
There is no need to first detach a location from a supply chain model.
Prerequisites for the Creation
Location master records can be created without any technical prerequisites. It is advisable to
define the required time streams and attach them to the location. This will allow immediate
planning runs within APO.
Maintained Fields

The location master fields are combined in logical groups. Each group of data is situated on a
specific tab. On each tab the displayed fields are again grouped in various blocks. The tabs with
the corresponding fields are explained below.
General Tab
External Location
The external location shows the name of the location as defined in the R/3
system. It can be an R/3 plant, vendor, or customer depending on the location
type. It forms a key together with the business system group, which is the
logical name of the R/3 system. The APO defined location name does not have
to be identical with the R/3 defined name. The usage of the logical name and
the external name permits totally independent naming conventions in the
systems.
If a location master is created directly in APO without an R/3 link, the external
location name is identical to that used within APO.
o

External Location

Business System Group

Administrative Data
Administrative data is created automatically by the system and can only be
viewed. It displays the user ID used when creating (changing) the location and
is shown together with the date and time.
o

Created

Changed

Geographical Data
For display purposes in the Supply Chain Cockpit screen, it is necessary to
define the longitude and latitude for each location. Longitude and latitude
information does not need to be captured as it is automatically inserted by the
system. This happens while the location is placed on the map during the
attachment of the location to the supply chain model, using the drag and drop
functionality. In this case a popup screen appears, allowing confirming, or finetuning the longitude
Preparing

and latitude of the location. This task is performed in the Supply Chain Engineer.
The longitude and latitude of a location is also used to calculate their relative
distance to each other. This calculated distance could be used to automatically
populate the distance information in a transportation lane. Additionally the
required transportation time can be calculated with the help of this distance and
the average speed of the transportation method.
o

Longitude

Latitude

Time Zone
This field is populated automatically when specifying the country in the
Address tab, but can be changed as required. The time zone specified in the
location master field Time Zone may be UTC or any other time zone.
Precision
Part of Future Scope (used in Vehicle Scheduling).

 Priority
The priority is used by CTM during the demand prioritization process. In
TP/VS, locations are grouped via the priority, and subsequently given penalty
costs according to the priority.
o

Priority

ATP: Backorder Processing/Product Availability (Part of Future Scope)

o

Business Event

MRP Area: Plant/Storage Location

The fields in this block are only visible for location type 1007. Planning in APO
is mostly carried out on location level, whereby some of the data can be seen on
a lower level. Stocks for example can be displayed per sub- location (R/3:
storage location), version (R/3 batch), and/or account assignment. In order to
view data and plan on a lower level, a location with the type MRP Area can
be created. This is the equivalent of the R/3 MRP Area and represents the
combination of an R/3 plant and storage location.
o Planning Plant
o

This refers to the R/3 plant.

Sub-location
This refers to the R/3 storage location of the plant specified above.

Network Design: Cost Profile (Part of Future Scope)

o

Network Design Location Profile

o Button to
start o
Location New
Preparing

Average Number of operations per week

Partner (Part of Future Scope)

o

Collaborative (Business) Partner

Partner (Part of Future Scope)

o

Collaborative (Business) Partner

Vendor (Part of Future Scope, release 3.1 only)

o

Central Purchasing Block

Address Tab
The address tab contains all required communication information. It is broken
down into five blocks, each of which can be further expanded or collapsed
again. This is achieved by the usage of the More Fields / End More Fields
button. A comments field is situated at the bottom allowing any texts to be
captured.
Address
All fields are self-explanatory and the only required field is the Country
definition in the street address block.

Name

Search Terms

Street Address

P.O. Box Address

Communication

Calendar Tab
Block 1 (Calendars)
APO offers the possibility to define various calendars per location. This allows
a flexible definition of available hours, depending on the task to be performed.
The calendars defined here are not factory calendars, but time streams. The time
zones defined in the attached planning calendars must be set to UTC if the
location is to be used within SNP. Those specified in the location master field
Time Zone could be UTC or any other time zone. Press the Parameters
button to hot-jump to the time stream maintenance transaction. Once there, any
time stream can be maintained.
o Production Calendar
The production calendar is used when scheduling production activities. It is
not the calendar used by a production resource.
o Storage Location Calendar
The storage calendar is used when scheduling storage activities. It is not
the calendar used by a storage resource. The storage calendar must have a
24-hour work time definition, otherwise the SNP Optimizer assumes the
Preparing

warehouse cannot be used at certain times. In this case the SNP Optimizer
plans emptying the warehouse during non-working times.
o

Shipping Calendar
The shipping calendar is used when planning goods receipt (G/R) and
goods issue (G/I) transactions. It determines working and non-working
time with a second-precision. The shipping calendar is used during the
release of the DP unconstrained forecast to SNP. It must for technical
reasons start at 00.00:00.

TP/VS Tab (Part of Future Scope)

Compatibility: Vehicle/Location
o

Incompatible/Compatible Vehicles

Button to start

Transportation Zone
o

Transportation Zone

Customer Delivery
o

Customer Delivery

First Visit

Last Visit

Route

Goods Wait Time

Maximum Duration

Picking Lead Time (with UoM)

Transport Creation Time (with UoM)

Times

Resources Tab
TP/VS (Part of Future Scope)
The definitions in this block are optional and used only by TP/VS. If the
specification of resources or opening hours for a location is not required, the
None radio button must be activated.
o

Load/Unload
Resource

L/U

Resource

Inbound

Consumption (V/S)

Button to start
L/U Resource Outbound
Preparing

Consumption
(V/S) Button to
start
o Opening
Hours o Button
to start
o

None
Activate if no specification of resources or opening hours are required.

Handling Resources
Handling resources can be defined to plan the workload at the G/R and G/I
point of the warehouse. Any planned G/R and G/I activity loads the respective
handling resource according to the consumption settings in the product master.
The Optimizer uses and optimizes the handling resources usage if defined and
activated in the SNP Optimizer profile. The handling resources capacity can be
defined in different ways to accommodate the business requirements. Examples
are time based capacity or volume/cube based. The time based capacity could
be used when emphasizing on labor requirements; the volume/cube based to
show the product flow.
o

Resource Inbound
Define the name of the inbound handling resource. The Inbound Resource
must have the same capacity type as the products capacity consumption,
defined in the product master G/R G/I tab. It must also be part of the
supply chain model.

Resource Button
This button is a hot-jump into the resource maintenance transaction. The
resource maintenance is initiated for the same planning version as that
selected for the location. When starting the location master maintenance

transaction from planning version 000 (the active planning version), the
resource master maintenance is carried out model independent.
o

Resource Outbound
Define the name of the outbound handling resource. The Inbound Resource
must have the same capacity type as the products, capacity consumption,
defined in the product master G/R G/I tab. It must also be part of the
supply chain model.

Resource Button
See above for explanation.

Storage Resource
A product independent storage (warehouse) resource can be defined per
location. Any planned G/R and G/I activity loads or unloads the storage
resource according to the consumption settings in the product master. The
Optimizer uses the product independent storage (warehouse) resource, if
defined and activated in the SNP Optimizer profile. It is also possible to define
a product specific storage
Preparing

warehouse resource in the product master.

In order to view storage resource loads, it is required that the product has either
an alternate unit of measure that relates it to the base unit of measure of the
planning area, or the base unit of the product must be the same as that of the
planning area.
o

Storage Resource

Define the name of the storage resource. It must also be part of the supply
chain model.
o

Resource Button
See above for explanation.

SNP Tab
The SNP tab contains fields that are used within SNP, Deployment, and TLB.
Stock
The term stock in APO can be defined not only in a very flexible way, but is
also different from location to location.
o

Stock Category Group

The only field in this group, named stock category group, is used to
determine the stock elements that are included when calculating the
stock figure in various planning tasks. A category group consisting of
one or multiple ATP categories can be defined in this field. Possible
categories included in this category group are e.g. unrestricted stock
(category CC) or quality inspection stock (category CI). The allocation
of categories to category groups is carried out in the IMG.
The standard delivered system uses the definitions of the category group
ST1 to determine the stock figure in the case where no entry is made in the
stock category group field. For further information see also the section
Stock Definition.

Deployment

For Deployment and TLB purposes, ATP category groups (which in turn are
made up of one or several ATP categories) can be linked to locations. This
allows a user definable composition of used receipt and issue elements per
location. The ATD (Available to Deploy) quantity with its elements ATD
Receipts and ATD Issues can therefore be defined location specific.
The standard delivered system uses the definitions of the category groups ATR
for the ATD receipts, and ATI for the ATD issues, in the case where no entry is
made in the ATD receipts and/or ATD issue fields. For further information see
also the section ATD Calculation.
o

ATD Receipts
Define the Available-to-Deploy Receipt category group.

Preparing

ATD Issues
Define the Available-to-Deploy Issue category group.

Push not allowed

Products can be flagged on location product level for push deployment.
With this flag on, products are pushed from the source to the target
location, depending on the source locations stock situation. This can be
disabled per location by setting this flag. If this flag is set, no product will
be pushed into the location. This is specifically useful if the target location
is a VMI customer.

Additional (Extras) Tab

The Additional tab (also called Extras tab) is only displayed if this function
is activated during customizing. The content of the fields is stored languagedependent, which means that the information is displayed in accordance with
the logon language as the default. The user can select at any time to see the
field contents in other languages if they are maintained. The field names are
ATTLOxx (with xx ranging from 01 to 05), The table name in which these
fields are stored is /SAPAPO/ATTLOC.
Block 1
The only block on this tab contains up to 5 fields that can be activated in
customizing. The fields are not required by any standard APO functionality.
VMI Customer Tab
The fields in this block are only visible for location type 1010. Locations of the
type 1010 VMI Customer contain information that is specific to VMI
customers.
Locations
o

Location for Sold-to-Party

The sold-to-party (e.g. a retail company) and the sold-to-party (e.g. one of
many distribution centers of the retail company) can be represented in the
APO system by two different locations. Whereby APO plans according to
the ship-to-address, it might be required to see which location represents
the sold-to-party. This can be defined using the field location for sold-toparty. The same sold-to-party location is used potentially for many shipto-party locations. This field is mandatory when creating VMI sales orders
in APO.

External Location short text

This is the name of the location as defined by the VMI customer. This
information can be used when sending and receiving EDI data, where it is
required not to use the vendors, but the customers location name.

Organizational Data
Preparing

The fields in this segment refer to the locations allocation to the organizational
structure as defined in R/3. The three fields are mandatory when creating VMI
sales orders in APO.
o

Sales Organization

o Distribution
Channel o Division
TSP (Carrier) Tab (Part of Future Scope)
The fields in this block are only visible for location type 1020. Locations of the
type 1020 Carrier (Logistics Service Provider) are used by TP/VS.
Consequently all settings made in this tab effect functionality within the TP/VS
module.
SCAC
The SCAC number is a number that uniquely identifies a carrier in the USA. It
can be used for example during the data exchange via EDI to identify the
carrier.
Continuous Move
o

Continuous Move
If the Continuous Move indicator is set, the carrier can be used to unload a
shipment, and then immediately load another new shipment. This way, the
carrier is used continuously for two or more shipments in a row. This is
different to a multi-drop or multi-pick scenario, as the transport media (e.g.
a truck) is completely emptied before being filled again.

Break Duration
The Break Duration determines the maximum time (notation hh:mm) the
carrier is prepared to wait between an unloading and subsequent loading
activity, in a continuous move operation. The break duration definition is
only effective if the continuous move is permitted (the flag above must be
set).

Capacity Check
o

Product Allocation
The Product Allocation functionality is used in this context to determine
a business share per carrier. When allocating a carrier to a shipment, this
entry is used to determine the available share of the business that can be
allocated to the carrier.

Performance
o

Performance Percentage

TTL Tab (Part of Future Scope, release 3.1 only)

Preparing

383

The fields in this block are only visible for location types 1030 and 1031.
Stockholding Location
o

Stockholding Location
Defines that the location may keep stock.

Other Functions

Assign Model
The assign model function allows the product to be assigned to a supply chain model or to
remove an assignment. This way, there is no need to specifically open the supply chain
engineer and assign a newly created product. While this method allows an easy assignment to
a supply chain model, it obviously does not include it in any work area.
The Assign Model pushbutton can also be also used to detach objects from the supply chain
model.
Create Planning Version specific Product Master
To create a planning version specific location master data record, select from the initial screen
the Set Planning Version button, define the planning version to be used, and then select
Create. Planning version specific master records can only be created for such planning
versions that relate to supply chain models to which the location master is linked. Not all
fields of the location master can be defined planning version specific.
Set Planning Version
To display or change a planning version specific location master data record, select the Set
Planning Version button from the initial screen. Then define the planning version to be used,
and select Display or Change.

4.2.2.2

Product

The product master is a central data repository for virtually any transaction and planning task in
the system. The fields on the various tabs are used, most of the time, by more than one module,
although some fields contain information that is dedicated towards a specific module. An
exception is the Demand Planning module, where the existence of a product master is not always
required. The term product relates to any type of material from component to finished product. It
is not necessarily a tangible unit. Product master information can be grouped according to its
anticipated usage (e.g. procurement related data). Information is grouped logically based on this
principle and can be accessed easily by selecting the appropriate named tab.
Product master data is defined globally and per location. Global data refers to all information that
is valid for all locations. The other type of product data is defined as location specific. The term
location product is often used when referring to location specific products and product data. The
product master needs to be assigned to any supply chain model it is supposed to work with. This
can be done in the Supply Chain Engineer or directly in the product master maintenance screen.
Product master data can be made planning version specific. This allows the independent
maintenance of master data per planning version. None of the global fields are version specific,
most of the location dependent fields are.

Preparing

384

Products can also be defined on a planning version specific level. This is an optional task, which is
only required if products should have different parameters depending on the planning version. The
system uses the model independent product master data if no planning version specific data is
defined and thus available.
The Master Data Maintenance Transaction
Path:
Technical Name:

Master Data > Product

/SAPAPO/MAT1

The product master maintenance screen consists of various tabs, each dedicated to a specific aspect.
Few fields need to be maintained to make a product usable for planning purposes and the selection
of required fields depends on the module and task. While maintaining location-specific data it is
possible to maintain global data at the same time.
The graphic below displays a symbolic layout of the product master maintenance screen.

A p p licatio n B ar
G en eral In fo rm atio n
P ro d u ct M aster T ab s

G lo b al &

Preparing

Graphic 109 Product Master Maintenance Screen Layout

Various horizons are defined in the product master. Most often they refer to days, either calendar or
working, but they could also relate to other periods. If an horizon refers to days, then the setting 1
depicts today, 2 depicts today and tomorrow, and so on. The same applies accordingly to other
period indicators such as weeks or months.
The product master frequently allows the use of profiles. Once a profile has been created it can
easily be linked to a product, which makes data maintenance much easier.
The Application Bar
Functional Pushbuttons
Display <> Change
This is the only pushbutton in the application bar and serves as a toggle
key between the display and change mode.
Deletion
Products are created on a global (location independent) level and additionally per location.
Consequently, they can be deleted separately on location and on global level. In order to delete a
product on global level, no location dependent entry must exist anymore. It must also not be used in
other master data objects for example a PPM. Whether or not a product is used in a PPM can be
checked with a utility report (see the section Other Functions). The deletion on global and/or
location level is a two-step process. Both of them are carried out from the Initial Screen of the
transaction Product Master Data Maintenance.
Step 1:
Set the deletion flag (under the menu option Product) for a product on global, location, or
both levels. You can only delete the global level when all location dependent definitions are
either also marked or already deleted.
Step 2:
Delete the flagged products by starting a batch job. This batch job can be run either
immediately or at a predefined time. The idea is that this run deletes all flagged products
only if no other dependent master data is attached to them. This ensures that no unassigned
PPMs or other master data objects are left behind without reference after the product was
deleted.
As products can be defined on a planning version specific level there is also a possibility to delete
the planning version specific data. Refer to the section Other Functions.
While the product master record is deleted, its assignments to supply chain models cease as well.
There is no need to first detach a product from a supply chain model.
Prerequisites for the Creation
Preparing

Product master records on global level can be created without any technical prerequisites. For a
product to be created on location level, it must exist on global level. The creation of the global data
can be done together with the data for exactly one location. The adding of new locations is a
Create activity.
Maintained Fields

The following explanation deals with all elements per tab. All tabs have one of three possible icons
defining them as either global, location dependent, or both. Tabs dealing with global and location
specific data are part of the Global Product Master Data section.
The General Information
The following fields are visible during the maintenance of a product master.
General Information Fields
Product Number
The product number is the key to the data record and cannot be changed.
Base Unit of Measure
The base unit of measure is defined when creating the product and cannot be
changed. Alternate units of measure can be defined in the Units tab.
Product Description
The product description is a language dependent field and is displayed in the user
logon language. Alternate languages can be maintained only when logging on in
the respective language.
Location
The location is only displayed while maintaining location specific product master
data. It is followed by a pushbutton providing a hot-jump function into the
location maintenance of the displayed location.
Planning Version
The planning version field is only visible if the product master is maintained in a
specific planning version.
The Product Master Tabs

Global Product Master Data

Location Specific Product Master Data

Preparing

Other Functions
With Dedicated Pushbuttons
Mass Maintenance of Products
Another very useful tool is the mass maintenance of products. On the selection
screen, mass maintenance allows the definition of single discrete values of
product (and/or location) numbers, the definition of a product (and/or location)
number range, or the definition of multiple ranges. On the following screen,
virtually all product master fields are displayed allowing the graphic selection of
those that require the change. The last step is different for fields with restricted
possible entries and for those that carry numerical values. For fields with possible
entries, the new entry can be defined. Should the field be numerical, a new value
can be defined or alternatively a calculation rule can be used. Available
calculation rules are multiply, divide, add, or subtract. In this case the new value

is derived from the old value. The same mass maintenance functionality is also
available specifically for the penalties defined in the SNP1 tab. Additional data
fields cannot be maintained using the mass update function.
Assign Model
The assign model function allows the product to be assigned to a supply chain
model or to remove an assignment. This way, there is no need to specifically
open the supply chain engineer and assign a newly created product. While this
method allows an easy assignment to a supply chain model it obviously does not
include it in any work area. Note that only products that are defined in at least
one location can be attached to a supply chain model.
The Assign Model pushbutton can also be also used to detach objects from the
supply chain model.
Set Planning Version
To display or change a planning version specific product master data record
select from the initial screen the Set Planning Version button, define the
planning version to be used and select then Display or Change.
Delete Planning Version specific Product Master
To delete a planning version specific product master data record select from the
initial screen the Delete Planning Version button, define the planning version to
be used and select then Continue.
Without Dedicated Pushbuttons
Create Planning Version specific Product Master
To create a planning version specific product master data record select, from the
initial screen, the Set Planning Version button, define the planning version to
be used and then select Create. Planning version specific master records can
only be created for such planning versions that relate to supply chain models to
which the product master is linked. Not all fields of the product master can be
Preparing

defined as planning version specific. In general, location dependent product

master data can be defined as planning version specific whereas global product
master data cannot be defined as planning version specific. There is no need to
define planning version specific product master data as the system uses the model
independent product master data if no planning version specific data is defined
and thus available.
Product Memo
Product memos can be added and maintained from any view, allowing the
definition of any text. This is done using a basic text editor. Product memos can
also be viewed and edited from various SNP and PP/DS transactions.
Usage in PPM
This function activates a list report providing an overview of any PPM that is
linked to the product. This is specifically helpful when a product needs to be
deleted.
Profiles
Various tabs in the product master can be maintained by simply linking profile to
the product. In this case all data previously specified in the profile is copied into
the product master. All fields that are defined in the profile are grayed out and
cannot be edited anymore. To break the link between the product master and the
profile, simply delete the profile name in the product master. This will turn all

profile-related fields from display-only back to editable. If data copied from a

profile is edited in the product master as described above, the link to the profile is
broken and subsequent updates of the profile do not have any affect on the
product master. Changes of the profile are automatically carried through to the
product master only if the profile name was not deleted in the product master.
Profiles can only be deleted if they are not attached to any product master.
To create, change, delete or display a profile follow these steps:
o

On the initial product master maintenance screen select the respective radio
button in front of the profile to be edited or created.

o Type in the name of the profile to be edited or created.

o Specify all details as required on the upcoming screen.
o

Save the profile to get back to the initial product master maintenance screen.

Note that every time the product master maintenance transaction is exited, all
profiles that were used within the last edited product are displayed.
Fields that can be populated via profiles are marked with a (P).

4.2.2.2.1

Global Product Master Data

Attributes
Preparing

The Attributes tab (view) is subdivided into various segments. None of theses segments refers
to any predefined profile.
Segment External Product Number
The segment External Product Number displays the name of the External Product
Number, which is composed of the Business System Group and the Product
Number (these are display-only even in change mode).
Segment Created By
Created By
The Created By field displays the user ID of the person who created the
product master data on the global level.
Segment Changed By
Changed By
The Changed By field displays the user ID of the person who last changed
the product master data on the global level.
Segment Weight and Measures/EAN
In the second segment called Weights and Measures/EAN, the weight and volume with
their respective units of measure for the product are displayed. The weight and volume
refer to the product in its base unit of measure. The SNP Optimizer uses the weight and
volume definitions defined here only if no weight and/or volume are defined as one of
the units of measures. If weight and volume is defined as an attribute and as a unit of
measure then the units of measure definitions are used.
Gross Weight and UoM
Volume and UoM

 EAN
The EAN displayed on this tab is the same EAN as the one defined on the
Units of Measure tab for the base unit of measure. It can only be
maintained on the Units of Measure tab.
Segment General Data
Stacking Factor
The Stacking Factor determines whether a product can be stacked in
pallets and if so how many levels of pallets are permitted. This information
is used by TLB to determine the maximum number of pallets that can be
loaded.
Material Group
The Material Group is the same format as on an R/3 system and not used
by APO.
Transportation Group
Preparing

Products are grouped into Transportation Groups to ensure that those that
are incompatible do not get loaded together into the same transport media
(e.g. truck). This feature is only supported by TP/VS and not by TLB. In
TP/VS various compatibility/incompatibility matrices can be defined that
all use this field.
Segment Shelf Life
Part of Future Scope
Planning with Shelf Life Button
Shelf Life
Maturity
Required Minimum Shelf Life
Required Maximum Shelf Life
Segment SDP
SDP Relevance
SNP and DP work with the same products (as do all other modules of
APO). The field SDP relevance allows making specific products
invisible for SNP and/or DP. This allows that a certain product is used in
one but not the other application area or in none.
This flag must be set if a product that is defined in the PP/DS PPM should
be included in the SNP PPM during the SNP PPM Generation.
Segment Additional Data
Up to 10 attributes can be defined per product, 5 each on global and location level. The
activation of the global attributes adds 5 new fields to the Attributes tab. The attributes
are activated in the IMG (path APO > Master Data > Product > Freely Definable Names
for Attributes). This option allows to activate this function and to allocate names that
appear on the screen for all attributes. Additional data fields cannot be maintained using
the mass update function.

Units of Measure

The Unit of Measures tab displays at least the base unit of measure. Additionally it shows all
alternative units of measure that are defined for the product. Each alternate unit of measure has
a conversion factor that depicts the numeric relation to the base unit of measure. It is
furthermore possible to allocate an individual EAN (bar code number) to each unit of measure.
Existing alternate units of measure can be deleted using the Delete Line button.
In order to see storage resource loads it is necessary that the products base unit of measure is
the same as that of the planning area or that the product has an alternate unit of measure that
relates it to the planning areas unit of measure.
The SNP Optimizer requires the definition of weight and volume in some cases. The weight
and/or volume can be defined as units of measure and as attributes. If weight and volume is
defined as an attribute and as a unit of measure then the units of measure definitions are used.
Preparing

The weight and volume might also be considered during TLB planning. In this case if the
weight and volume is defined as an attribute and as a unit of measure, then the attributes are
used.

Classification
This tab is used to link the product to a class. Furthermore, it allows branching into the Rules
Maintenance screen. Classification of products is required if Characteristics Dependent
Planning is to be carried out. This functionality is used within PP/DS and is not supported by
SNP.

The following tabs provide both global and location dependent definitions.

SNP 1
The SNP1 view consists of two segments, which both deal with penalty costs required for SNP
optimization purposes. These penalties might get multiplied according to the settings in the
SNP Cost Profile.
The Penalty for Late and Non Delivery can be used as well to optimize on Profit. The higher
the anticipated product profit is, the higher the product penalty should be. If this is the case, the
optimizer tries to first and utmost ensure that demands for those products with high penalty
(profit) are satisfied first.
All fields in the segment Penalty Cost are valid for the product irrespective of the location.
Fields in the segment Location Dependent Penalty Cost are per product and location. If costs
and penalties are defined on both global and location level, then the location dependent ones
are applied.
Segment Penalty Cost
The first group of fields is used to define the penalty cost associated with customer
requirements. They are used for example when evaluating sales orders. A Delete
button exists that deletes all three entries in one step if utilized.
Penalty for Non-Delivery
The SNP Optimizer uses the Penalty for Non Delivery to determine the
opportunity cost associated with a non-delivery of a customer sales order.
It is applied in all cases where a sales order cannot be satisfied.
Delay Penalty
This entry determines the penalty cost per day for late delivery to a
customer. In the case of a late delivery to a customer the SNP Optimizer
calculates this penalty per day for all days after the Maximum Delay,
which is defined in the next field.
Maximum Delay

Any delay greater than the Maximum Delay does not lead to any Delay
Penalty calculation. In this case the Penalty for Non-Delivery penalty is
applied.
Preparing

The second (third) group of fields in this segment contains exactly the same fields as
described above. The difference is that the second group deals not with customer
requirements but with Forecast Requirements (Corrected Forecast Requirements).
Forecast requirements and corrected forecast requirements are released from Demand
Planning to SNP using the ATP categories FA and FB in the standard delivered
system.
Segment Location Dependent Penalty Cost
All fields in this segment are a replication of those explained above. They are valid for
the selected location and not global.

ATP Global and Location Dependent

The ATP tab contains global as well as location-specific data. The tab symbol and the fields
displayed change with the selection (global or location specific).
Segment Cross Location
In this segment all global (not location dependent) fields can be found.
Product Allocation
This field allows the input of the Location Independent Product Allocation
Procedure.
Procedure Sequence
Here the Location Independent Product Allocation Procedure Sequence is
defined.
Segment Location Dependent
In this segment all location dependent fields can be found.
Location Dep. Procedure
This field allows the input of the Location Dependent Product Allocation
Procedure.
Location Dep. Sequence
Here the Location Dependent Product Allocation Procedure Sequence is
defined.
Check Mode
The check mode, which is called Requirements Class in R/3, is one of
the parameters passed from R/3 to APO when a sales order is transmitted
or an ATP request is to be carried out. Should this information be missing,
then this fall back value is used. This is also helpful when linking a nonR/3 OLTP system to APO that might not have definitions similar to a
check mode. This field also enables a forecast consumption simulation if
populated with a suitable ATP Check Mode (like 053). The check mode is
also used in a multi-level ATP check where the check mode of a

Preparing

dependent demand product is not passed across to APO. It is not required

to enable the forecast consumption functionality.
Check Horizon
The check horizon determines the number of working days as specified in
the factory calendar after which all requirements can be confirmed (if the
ATP check rule uses this option). Should no check horizon calendar be
defined, then the number of days specified here are calendar days.
ATP Group
The ATP group, which is called Availability Check in R/3, is one of the
parameters used to determine how the availability check is carried out. The
definition here is also a fall back value in situations where this information
is not sent across from the OLTP system.
The Product View transaction only displays the ATP tab if an ATP
Group is defined.
Checking Horizon Calendar
This is the factory calendar used in conjunction with the check horizon. It
also provides access to the calendar maintenance transaction.
Display Unit of Measure
Defines the unit of measure used when displaying ATP results in APO.
This unit of measure must obviously be one of the units of measure
defined for the product.

4.2.2.2.2

Location Specific Product Master Data

Note that fields that can be populated via profiles are marked with a (P).

Administrative
The Administrative tab, unlike all other location dependent tabs is positioned left of the global
data views and can easily be overlooked. There is though very limited information available on
this tab.
Segment Created By
Created By
The Created By field displays the user ID of the person who created the product
master data on the global level.
Segment Changed By

Changed By
Preparing

The Changed By field displays the user ID of the person who last changed the
product master data on the global level.
Segment Planner
The main focus of this view is the display of IDs of the planners responsible for the
various planning tasks can be captured. If for example a specific SNP planner is defined
in this view, and this planner calls up a SNP planning job, he or she will only plan those

products where the planner ID in the product master matches. This setting does not
provide access control and must not be seen as an authorization check. It merely helps to
pre-select products in a planning run. The four planners that can be specified here are:
Production Planner (PP/DS)
Supply Network Planner (SNP)
Demand Planner (DP)
Transportation Planner (TP/VS)
The planner ID is also used as a selection criteria in the Alert Monitor. This provides a
valuable tool to easily select and display only such alerts that are applicable to a certain
planner.

Demand
The fields on the Demand tab define how the system deals with demand elements in SNP and
PP/DS. The majority of fields on this tab can be maintained by linking the Demand Profile to
the product. For further information regarding the use of profiles and the available fields in
this profile refer to the section Demand Profile. Fields that are part of this profile are marked
with a P.
Header Segment
Demand Profile
Define here the name of the demand profile that should be linked to the product.
Segment Demand Strategy
Proposed Strategy (P)
The proposed (requirements) strategy defines the products manufacturing
strategy. It also determines whether and how forecast consumption is carried out.
If this field is left blank the forecast tab in the PP/DS Product RRP3 showing the
forecast consumption is not displayed.
Segment Demand Strategy
Part of Future Scope
Always Collective Demand Button (P)

RPM Time Bucket Profile (P)

Preparing

Possible Individual Customer Demand (P)

Order Network (P)
Segment Forecast Consumption Mode
Consumption Mode (P)
Consumption of Forecast can be done backwards (consume forecast in period
prior to consumption or earlier), forwards (consume forecast in period after
consumption or later), or in forward/backward mode (combination of both). The
parameter here defines which mode has to be used.
Backward Consumption Period (P)
In case of backward consumption of forecast, the number in this flag defines the
number of working days allowed to go back. Should no unconsumed forecast

amount be available in these periods, no forecast consumption will take place. In

this case the requirement quantity that would have been used for forecast
consumption is added to the forecast of the requirements period.
Forward Consumption Period (P)
In case of forward consumption of forecast the number in this flag defines the
number of working days allowed to go forward. Should no unconsumed forecast
amount be available in these periods, no forecast consumption will take place. In
this case the requirement quantity that would have been used for forecast
consumption is added to the forecast of the requirements period.
Flag for Assembly Planning
As a rule the forecast of the product as specified in the demand element (e.g.
sales order) is consumed. With this flag set, the product forecast of the dependent
requirement is consumed instead. Dependent requirements include transportation
requirements.
This flag works independent of the products requirements strategy setting.
Segment Pegging Dynamic Pegging
Part of Future Scope
Pegging Strategy (P)
Maximum Earliest Receipt ____ before Demand (P)
Maximum Latest Receipt ____ after Demand (P)
Segment Pegging Schedule Alerts
Part of Future Scope
Alert if Receipt over ____ before Demand (P)
Alert if Receipt over ____ after Demand
Segment Pegging Delivery Tolerance
Preparing

Part of Future Scope

Segment Pegging Delivery Tolerance
Under Delivery Tolerance (P)
The under-delivery tolerance can also be defined in a sales order that is
transmitted from R/3 to APO. In this case the product master based tolerance is
not applied.
Over Delivery Tolerance (P)
The over-delivery tolerance can also be defined in a sales order that is transmitted
from R/3 to APO. In this case the product master based tolerance is not applied.
Segment Pegging Use Quantity
Part of Future Scope
Use Total Order (P)
Use Total Stock

Lot Size

The fields on the Lot Size tab determine the parameters for the reorder process. There is no
general rule which fields are used by SNP and/or PP/DS. The majority of fields on this tab can
be maintained by linking the Lot Size Profile to the product. For further information regarding
the use of profiles and the available fields in this profile refer to the section Lot Size Profile.
Fields that are part of this profile are marked with a P. Note that SNP uses the lot sizing
parameters of the requesting location and Deployment uses the lot sizing parameters of the
supplying location.
Header Segment
Lot Size Profile
Define the name of the lot size profile that should be linked to the product here.
Lot Size Unit (P)
The unit of measure used in the lot size definition tab can be different to the
products base unit of measure. If this is desired, the lot size unit of measure must
be defined as an alternate unit of measure in the Units of Measure tab. This
restriction applies only to units of measure without dimensions (e.g. pieces and
cases) and not units of measure with dimensions (e.g. kilogram or liter). These
rules also apply when attaching a lot size profile to the product that uses a unit of
measure different to the products base unit of measure.
Segment Processes
All settings in the segment processes do not have any impact on the SNP Optimizer. The
use of the SNP Optimizer can be seen as an entirely different process.
Although not visible on the product master screen, the system uses the following
Preparing

abbreviations for the four available lot size methods:

E

Lot-for-Lot Order Quantity

Fixed Lot Size

Periodic Lot Size

Lot Size at Reorder Point

Lot Size Always Button (P)

Lot size calculations always take place when manufacturing for an anonymous
market (make to stock production). If this flag is set a lot size calculation is also
carried out in a make to order environment.
Lot for Lot Button (P)
Lot Size Method E
If this option is activated, the order quantity will be exactly the demand quantity.
No manipulation of the demand quantity takes place.
Fixed Lot Size Button (P) Lot
Size Method F

Activates the process Fixed Lot Size.

o

Fixed Lot Size (P)

With this option the procurement order quantity will be always exactly the
same. Should the demand exceed this quantity multiple procurement
orders will be created.

By Period Button (P)

Lot Size Method P

Activates the process By Period. The Periodic Lot Sizing process accumulates
all demand of a certain number of periods as defined by the user and places one
replenishment order against these demands at the same time when the first
requirement arises (requirements date equals availability date).
o

Period ID (P)
Define the type of period to be used and referred to in the Number of
Periods field.

Planning Calendar (P)

Define the calendar that is used to determine the working periods on which
the number of periods is based.

Number of Periods (P)

Define the number of periods based on the period ID and planning
calendar.

Reorder Point Procedure Button (P)

Preparing

Lot Size Method R

Activates the process Reorder Point Procedure.
o

Reorder Point Procedure (P)

Define the reorder point procedure to be used when panning the product.
Various reorder point procedures, time dependent or time independent are
supported.

Reorder Days Supply (P)

Specify the required reorder days supply in the unit days. This
information is used when selecting a reorder point procedure that uses a
demand based reorder point. Within SNP planning algorithms the reorder
days supply is used in conjunction with the demand of the number of days
as specified here to derive the reorder point in the products base unit of
measure.

Segment Quantity Determination

The SNP Optimizer uses some settings in the segment quantity determination. If run in
discretization mode, the SNP Optimizer can use the rounding value and profile as well as
the minimum and maximum lot sizes. The field assembly scrap is always adhered to.
Minimum Lot Size (P)
A minimum lot size can be maintained to ensure a minimum procurement order
quantity. It must be less than the maximum lot size quantity.
Maximum Lot Size (P)
A maximum lot size can be maintained to limit the quantity per order. It must be
greater than the minimum lot size quantity. More than one order will be created if
the demand exceeds the maximum lot size value.
Assembly Scrap (P)
The Assembly Scrap defines the amount of scrap to be expected when the
product is manufactured. All components required during the assembly must
therefore be provided in a higher quantity. The system increases the requirements

quantity accordingly. The SNP Optimizer uses the assembly scrap setting in both
continuous and discretization mode.
Rounding Value (P)
Rounding of order quantities can be carried out by means of a rounding value
Rounding values are discrete values defined in the products base unit of
measure.
Rounding Profile (P)
In cases where the single level definition of the rounding value is not sufficient,
the multi level Rounding Profile can be used. The result of the rounding profile
based calculation is used instead of the rounding values if both are defined.
Target Stock Level Method (P)
Preparing

Specify the method for calculating the target stock level. Depending on the
setting of this field other fields in this tab are used or not used. The target stock
level is used by SNP planning algorithms. It is also used in reorder point
procedures to determine the upper stock level. Time dependent target stock level
methods require that the target levels be defined in the SNP Interactive Planning
transaction in specific key figures.
Target Days Supply (P)
Specify the target days supply in the unit days. This information is used when
selecting the target stock level methods <blank>, 5, and 6. Within SNP
planning algorithms the safety days supply is used in conjunction with the
demand of the number of days as specified here to derive a required target stock
in the products base unit of measure.
The Target Days Supply is also used by the Extended safety stock calculation.
For this calculation it is required to define a value, which determines the reaction
time.
Segment Scheduling
None of the settings in the segment scheduling have any impact on the SNP Optimizer.
Safety Days Supply (P)
Specify the required safety days supply in the unit days. This information is
used when selecting the safety stock methods SZ and SM. Within SNP
planning algorithms the safety days supply is used in conjunction with the
demand of the number of days as specified here to derive a required safety stock
in the products base unit of measure. It is therefore not really a scheduling
parameter. PP/DS shifts all demands backwards (uses an earlier demand date)
thus building up a safety buffer as required.
Availability Date Indicator (P)
The availability date indicator permits the switching on of the period factor
function, which is used only in conjunction with periodic reorder processes.
Period Factor (P)
If a periodic reorder process is used and the availability date indicator is switched
on then the period factor determines when the goods receipt for a periodic has to
be scheduled for. The value can be set between 0 (earliest) and 1 (latest).
Segment Stock Data
The SNP Optimizer uses all safety stock settings defined in this segment. The reorder
point and production storage capacity do not impact the SNP Optimizer.

 Safety Stock
Specify the target safety stock in the products base unit of measure. This
information is used when selecting the safety stock methods SB and SM.
Safety Stock Method
Preparing

Specify the method for calculating the safety stock. The safety stock method is
the key field to determine which method is used. Depending on the setting of this
field others in this tab are used or not used. The safety stock methods apply to
both SNP and PP/DS but might be applied with slight differences. Time
dependent safety stock methods require that the target safety stock levels be
defined in the SNP Interactive Planning transaction in specific key figures.
Reorder Point
The reorder point determines the lowest stock level allowed before a reorder
proposal is created during a planning run. When using the reorder point process,
the safety stock is automatically added to the reorder point figure that is
displayed and used in the SNP Interactive Planning transaction. The safety stock
(see above) must therefore not be included in the product master field or key
figure reorder point.
Service Level
The service level is an input parameter for all extended safety stock methods.
Specify any value between 0 and 99.9%. The higher this value, the higher the
proposed safety stock will be.
Production Storage Capacity
The production storage capacity also referred to as the production warehouse
capacity determines the maximum quantity of stock, of the specific product, that
could be held. This information is required for the target stock level methods 4, 5,
and 6 (see above). Note that the safety stock is included in this figure and thus the
production storage capacity must be at least as high as the required safety stock.
The limitation of the production storage capacity can also be used by the SNP
Optimizer to restrict the proposed quantity stored at any time.
Stock
The Stock field does not display the total stock on hand at the location but only
such stocks that belong to category CC, which is unrestricted use stock. Thus it
excludes, for example, quality inspection or blocked stock. This field is
duplicated in the Procurement tab. The display of the stock figure is planning
version dependent. If the product master is displayed with its planning version
specific information, the stock is also displayed for this specific planning version.
Otherwise it refers to the active planning version 000.

SNP 2
The SNP 2 tab is subdivided into four segments. The first three segments contain fields that
can be linked to the SNP Demand Profile, SNP Supply Profile, or the Deployment Profile. For
further information regarding the use of profiles and the fields available in this profile refer to
the respective sections. Fields that are part of this profile are marked with a P.

Segment SNP Demand Profile

Preparing

 SNP Demand Profile

Define the name of the SNP demand profile that should be linked to the product
here.
Forecast Horizon (P)
The forecast horizon setting is used only if no requirements strategy and forecast
consumption is used. In this case the total demand of independent requirements is
calculated differently by APO depending on whether the period is within or
outside the Forecast Horizon.
o

Total Demand within Forecast Horizon

Within the forecast horizon the total demand of independent requirements
equals the total demand of all those orders that are linked to the SNP key
figure Sales. The allocation of orders is carried out via the orders
categories, which are linked to ATP category groups. The allocation of order
categories to ATP category groups as well as the allocation of ATP category
groups to the key figure is customizable.

Total Demand outside Forecast Horizon

Outside the forecast horizon the total demand of independent requirements
equals the greater of the two key figures, sales orders or forecast
requirements. The term forecast requirements refers to the unconsumed
forecast released from DP. This unconsumed forecast remains the same.

The Forecast Horizon therefore splits the future into two segments, and the figure
defined in this field marks the end of the first time segment and the start of the
second. It is defined in calendar days and starts on the present day. In both time
segments, the dependent and distribution demand is added to derive the overall
product demand at the location.
The overall demand, of which the independent demand as discussed above is
only a portion, is added up by means of a macro. This macro, using the forecast
horizon logic described, could be changed when using a planning book other than
the standard delivered one. The standard delivered planning book can only be
changed by SAP.
Pull Deployment Horizon (P)
The field Pull Deployment Horizon specified at the sending location defines
the number of calendar days that are checked for distribution (SNP and PP/DS)
demands at the receiving location. No specific factory calendar can be used. Day
1 is the current day.
Setting this field to 14 days at the sending location will force the Deployment run
to check for any demand elements at the receiving location during the next 14
days. The deployment run time scope can be capped by setting the Deployment
Horizon in Days to a value smaller than the one defined in the product. If the
Deployment Horizon in Days is smaller than the Pull Deployment Horizon
the Deployment run will not suggest any deployment orders although it would be
appropriate according to the product master setting in the field Pull Deployment
Preparing

Horizon. Setting the Deployment Horizon in Days to a value greater than the
Pull Deployment Horizon has no effect on the result. In this case the
deployment log file repeats the last day considered, according to the Pull
Deployment Horizon, several times until it reaches the number of days as
specified in the Deployment Horizon in Days. The field Deployment Horizon
in Days is of specific interest when various products with different settings for

the Pull Deployment Horizon are deployed at the same time. In this case some
products might have a Pull Deployment Horizon that is greater than the
Deployment Horizon in Days, others not.
Any Pull Deployment Horizon value that is greater then the horizon defined in
the Time Buckets Profile for Demand Planning and Supply Network Planning
is capped to the value as defined in the Time Buckets Profile. This effects all
calculations performed. Therefore the demand elements considered by
Deployment could never be outside the horizon defined in the Time Buckets
Profile.
Pull Deployment Horizon versus Deployment Horizon versus Planning Horizon.
The rule is to take per location product the smallest of the three.
See also the notes for the field Stock Transfer Horizon.
This field is used by the Deployment Heuristics (including Real-time) but not by
the Deployment Optimizer.
Period Split (P)
This setting determines how demand is distributed over time when performing
the release of the unconstrained DP plan to SNP. The distribution of the
forecasted demand takes place by spreading it evenly over the periods. If for
example the forecast was 1000 pieces per month, and the month has 20 working
days (according to the respective location calendar), the forecast in SNP would be
50 pieces per day. This is standard functionality that does not require any specific
setting. The parameter here is specifically for situations where the forecast
release takes place into a period that already started. Three options are available:
o

Distribute the whole forecasted demand over the entire period even if part of
the horizon is already in the past.

Distribute a pro rata forecasted demand over the future period only. As a
result the total demand distributed over the period is less than the DP
forecasted demand.

o Distribute the whole forecasted demand over the remaining future period.
Example:
On September 1st, 1999 the forecast for the calendar week is released from DP.
Part of the week is in the past already. The forecasted demand for this week is
900.
Preparing

Period
Split
Blank
1
2
Table 77 Period Split Indicator Example
VMI promotion Lead Time (P)
The VMI Promotion lead-time has a similar function as the Target Days Supply
field. It supports the calculation and building up of two separate target stock
levels, one based on normal demand and the other on promotion demand. The
VMI promotion Lead Time is used to stipulate the number of workdays for the
calculation of the target stock level required for all VMI promotion demand. The

definition of the VMI promotion lead-time ensures that enough stock is available
to cover promotions at a VMI customer location. For normal demand, the target
stock level is calculated additionally according to the Target Days Supply
setting.
Segment SNP Supply Profile
SNP Supply Profile
Define the name of the SNP supply profile that should be linked to the product
here.
Production Horizon (P)
The field Production Horizon defines the number of calendar days into which
the SNP planning run is not allowed to put any planned production orders.
Planned production orders can be created by SNP only outside this period. They
are then converted into PP/DS orders in a batch job or individually. Within the
Production Horizon, which is also referred to as the PP/DS Horizon, planned
production orders are dealt with exclusively by PP/DS. For any unmatched
(open) requirement that the SNP run finds within the production horizon, a
planned order will be created just outside the production horizon. This is the
same logic as it is used by the R/3 MPS run. Situations, where during the
production horizon an imbalance between demand and supply exist, should only
happen for products where Automatic Planning Immediately (see product
master PP/DS tab) is switched off.
A planning version specific default value for the production horizon can be set in
the planning version maintenance transaction. This default value is used only in
cases where the Production Horizon in the product master is not maintained
(either as a direct input or via a profile).
A flag can be set in the SNP optimizer profile, which allows the SNP Optimizer
(if set) to create SNP planned orders within the production horizon. This setting
Preparing

has no impact on the SNP Heuristics.

The production horizon is made visible in the SNP Interactive Planning
transaction. All days that are within the production horizon have a background
color that is different to those days that are outside the production horizon.
Stock Transfer Horizon (P)
The field Stock Transfer Horizon defines the number of calendar days into
which the SNP planning run is not allowed to put any goods receipts based on
planned orders for stock transport (from own location or defined vendor) or
purchasing (vendor that is not part of the supply chain model). This applies only
to the receipt leg of the transportation order. The demand leg of the transportation
order can appear outside and inside of the stock transfer (and also production)
horizon. The stock transfer horizon has no impact on calculations carried out
during the Deployment run. Day 1 of this horizon is the current day. Note the
following relations:
o

For goods receipts based on transportation orders:

The earliest good receipt time of an order is based on the longer of the two
periods, stock transfer horizon and transportation time (defined in the
transportation lane/method).

For goods receipts based on purchase orders:

The earliest good receipt time of an order is based on the longer of the two
periods, stock transfer horizon and planned delivery time (defined in the
product master procurement tab).
When using Deployment Heuristics Real-Time the planning algorithm consists of
an SNP Heuristics and a subsequent Deployment Heuristics run. The initial SNP
planning deletes all existing SNP (not deployment) orders and recreates them
depending on the demand but then again after the end of the stock transfer
horizon! This happens with increased, decreased and unchanged demand. Using
this method, the pull deployment horizon must be set to at least the stock transfer
horizon plus one day. Otherwise the system will never come to the point of
creating a deployment order.
A flag can be set in the SNP optimizer profile, which allows the SNP Optimizer
(if set) to create SNP planned orders within the stock transfer horizon. This
setting has no impact on the SNP Heuristics.
The stock transfer horizon is made visible in the SNP Interactive Planning
transaction. All days that are within the stock transfer horizon have a background
color that is different to those days that are outside the stock transfer horizon.
Push Deployment Horizon (P)
The field Push Deployment Horizon is used at the sending location and defines
for how many calendar days into the future the system should take receipt
elements into account when planning the sending of products to the receiving
location. The word Push in the field name does not stipulate that the value
defined in it is used when applying a Push Deployment Strategy!
Preparing

Setting this field to 7 days at the sending location will force the Deployment run
to check for any supply elements at the sending location during the next 7 days.
The field Push Deployment Horizon can be left blank for all products at locations
that never send products during deployment runs (e.g. finished products at a
customer location or components at a manufacturing plant).
Any Push Deployment Horizon value that is greater then the horizon defined in
the Time Buckets Profile for Demand Planning and Supply Network Planning
is capped to the value as defined in the Time Buckets Profile. This affects all
performed calculations. Therefore the supply elements considered by
Deployment could never be outside the horizon defined in the Time Buckets
Profile.
This field is used by the Deployment Heuristics (including Real-time) but not by
the Deployment Optimizer
Deployment Push Horizon when using Safety Stock (P)
When using the push distribution set to option C the system pushes all but the
safety stock to the target locations. Should a target location have a deployment
requirement that cannot be satisfied from the normal (non safety stock) it will be
satisfied from the safety stock only if the requirement date resides within the
period stipulated in this field.
Fix Production (P)
If this flag is set all SNP planned production orders that are outside the planning
horizon are not deleted at the beginning of the planning run.
Fix Transportation (P)
If this flag is set all SNP planned transportation orders that are outside the
planning horizon are not deleted at the beginning of the planning run.

Segment Deployment Profile

Deployment Profile
Define the name of the deployment profile that should be linked to the product
here.
Fair Share Rule (P)
The field Fair Share Rule determines the type of fair share logic that is applied
to a specific location product whenever the ATD quantity is smaller than the total
requirements for a product. Leaving this field blank is a valid possible entry,
indicating that no fair share rules must be applied.
Push Distribution (P)
The field Push Distribution determines the type of push logic that is applied to
a specific location product whenever the ATD quantity exceeds the total
requirements for a product. Leaving this field blank is a valid possible entry,
indicating that no push rules must be applied and products are deployed using
pull principles only. Pushing of product quantities is carried out (if activated) for
Preparing

all supply elements that exceed the demand.

Segment Other Data
Customer Material
Customers might use their own product number and not the one used internally.
Should the location in which the product is defined reflect a customer this field
can be used to specify this customer specific product number. This definition can
then be used when sending and receiving VMI data via electronic data exchange.
The field is always available for input and can also be used for example where
the location reflects a vendor that might use an own product number. Obviously it
does not make sense defining a customer product number if the location reflects
for example an own manufacturing plant.
VMI Purchasing Group
The VMI Purchasing Group is used to group products according to criteria
defined by the VMI customer. The field can be used to sort deployment orders
within a TLB order. This can for example facilitate a grouped loading of
products. See the section TLB for further information on this feature.
Purchasing Group
Displays the Purchasing Group in the same format as in R/3. The field is not used
for any planning task.
Priority
The product priority can be used by PP/DS to determine the priority of the
production order. The use of order priorities needs to be activated per planning
version. The product priority is also displayed on PP/DS tab. The product priority
is also used within CTM planning to define the priority of a product. The priority
can also be defined in a sales order that is transmitted from R/3 to APO. This
sales order based priority determines in a Make-to-Order environment the priority
of the pegged production order created by PP/DS. In this case the product master
based product priority is not applied.

PP/DS

The PP/DS view is subdivided into five segments. None of theses segments refer to any
predefined profile.
Segment Automatic Planning for all Changes
Part of Future Scope
Automatic Planning Immediately
Automatic Planning in Planning Run
Manual Planning with Availability Check
Manual Planning without Availability Check
Preparing

Segment Heuristic
Part of Future Scope
Part of Package
Heuristics
Segment Horizons
Production
This is a copy of the Production Horizon maintained on the SNP2 tab. It is a
display-only field on this tab.
Fixing
The Fixing Horizon - also referred to as the Planning Time Fence- determines
the number of days starting from the current moment during which the system is
not permitted to change any receipt elements. The planner can nevertheless
manually change them. Note that orders within the fixing horizon do not have a
special (different) order category.
Opening
The Opening Horizon is an additional time period that is added to the overall
scheduling period of a production order. An opening horizon of two days
(according to the factory calendar) would for example change the opening date
from Thursday to the previous Tuesday but leave the start date unchanged.
The opening period can start in the past if an order is required to start
immediately. This period is a period used for production preparation only if there
is enough time.
Segment Explode Task List
Dependent requirements are created as a result of the BOM or PPM explosion. PP/DS
offers two possibilities, to explode the APO resident PPM or the BOM, which resides on
the connected R/3 system (if R/3 is the OLTP system). In customizing, a global setting
defines whether the PPM or BOM is used. In addition to this global setting, it is possible
to define individually per product whether the PPM or BOM is to be used. Note that the
BOM of the R/3 system can only be used within PP/DS and not with SNP. It is always
required to create a separate PPM for SNP purposes, irrespective of the BOM/PPM
explosion setting. A utility program can be used to create a basic SNP PPM based on a
PP/DS PPM.
Explode Task List
BOM Explosion Date

Segment Other
Priority
The Priority field is a display-only field on this tab. It can be maintained on the
SNP 2 tab.
Preparing

Procurement
The Procurement tab is subdivided into four segments. None of theses segments refer to any
predefined profile.
Segment Procurement
Procurement Type
The Procurement Type is the key driver for deciding whether a product is to be
manufactured or procured. SNP Heuristic and PP/DS use this field to determine
the valid mode of procurement. The SNP Optimizer decides on the procurement
type, depending on the cost situation. Please note that there is no Special
Procurement Type as is the case in an R/3 system. This is not required as the
pure existence of a transportation lane defines the possibility to source a product
from a location. This makes even more sense when thinking about the SNP
Optimizer. The decision to procure externally or internally is cost driven, as is the
selection of the location from where to procure the product. Any location that has
a transportation lane to the demanding location is considered.
The procurement type P means that if there is no receipt element (e.g. no
planned order) then there is no receipt availability at all. It does not mean
indefinite availability.
Planned Delivery Time
Determines the average lead-time between ordering and goods receipt. This field
is used for all external procurement orders that do not relate to any vendor
supplied in the supply chain model (anonymous vendor).
Segment Stock
Stock
The Stock segment displays the stock on hand at the location. This field is a
duplication of that shown in the Lot Size tab. Refer to the documentation of this
tab.
Segment Procurement Costs
The procurement cost function as well as the procurement cost are used by the SNP
Optimizer to determine the cost of procurement if the vendor is not defined as a location
and/or part of the supply chain model and has thus no transportation that points to the
vendor location. The procurement cost when moving products from one location to
another is determined using information defined in the transportation lane. The cost
refers to one unit of the products base unit of measure.
Cost Function
The procurement cost function allows specifying fixed and variable procurement
costs in lot size dependent intervals. To create or update existing cost functions,
specify the cost function name and select the Maintain button next to the field.
The procurement cost (see below) is not used if a cost function is specified.

Preparing

 Procurement Cost
If no procurement cost function is defined the procurement cost is used to
determine the lot size independent cost.
Segment Stock Costs
The storage cost and safety stock penalty are used by the SNP Optimizer to determine
the cost of stock keeping and/or violating the required safety stock quantity (undercoverage of safety stock).
Storage Cost
The storage cost is defined per calendar day and unit of the products base unit of
measure.
Safety Stock Penalty
The penalty is applied per calendar day and quantity with the quantity being
measured in the products base unit of measure.

GR/GI
The GR/GI view is subdivided into six segments. None of the GR/GI segments refer to any
predefined profile.
Segment Processing Times in Days
The times defined in this segment are in days and can also be defined with decimal
values. They represent time duration, which together with the locations calendar are
used to determine the time between the activity and the stock availability. All planning
algorithms that need to perform a GR or GI scheduling use these settings.
Goods Receipt Time
Define the goods receipt duration in days. The format is days with 4 digits plus
two decimals.
Example:
The G/R time is 0.25 days, which is equal to 6 hours. The calendar stipulates the
working time from 07.00 through to 17.00 every workday (Monday to Friday).
The G/R is scheduled at 15.00 on Friday afternoon. This results in a stock
availability on Monday morning at 11.00.
Goods Issue Time
Define the goods issue duration in days. The format is days with 4 digits plus two
decimals.
Example:
The G/I time is 0.25 days, which is equal to 6 hours. The calendar stipulates the
working time from 07.00 through to 17.00 every workday (Monday to Friday).
The requirement is for Monday morning at 11.00. The G/I is scheduled at 15.00

Preparing

on Friday afternoon
Segment Shipping
Part of Future Scope

 Loading Group
Segment Completion Confirmation
Part of Future Scope
Quantity Propagation
Completion Adjustment Confirmation
Remaining Net Quantity Adjustment
Segment Good Issue Posting
Part of Future Scope
Synchronized Posting GI
Segment Capacity Consumption
This segment deals with the consumption of storage and handling resources that are
applied when products are stored at the location or moved into or out. The figures are
entered together with the appropriate unit of measure. All transactions that deal with
goods movements use these settings and update the load of the respective resources. It is
also required to define the handling resource(s) and the storage resource in the location
master.
The Optimizer uses the storage (warehouse) and handling resource consumption and
associated cost of the resource if defined in the product and resource master and
activated in the SNP Optimizer profile.
Handling Capacity Consumption GR
The capacity of the inbound handling resource can be monitored and planned by
defining the consumption of its capacity per product with every good receipt. The
handling resource consumption could, for example, be defined in a time unit or in
a volume or weight unit depending on the business requirements.
The resource consumption defined in the product master and the available
capacity of the resource must be of the same type (e.g. volume). Additionally the
product master must have either a base unit of measure or an alternate unit of
measure, which is the same as the unit of measure used in the planning area. The
SNP Optimizer can use the handling capacity consumption in its planning run.
Handling Capacity Consumption GI
The explanations and restrictions of the Handling Capacity Consumption GR
apply as well for the handling capacity consumption GI.
Storage Consumption per Base UoM
The capacity of the warehouse can be monitored and planned by defining the
Preparing

consumption of its capacity per product and day. The resource consumption
defined in the product master and the available capacity of the resource must be
of the same type (e.g. volume). The SNP Optimizer can use the handling capacity
consumption in its planning run.
Storage resources should have a 7-day 24-hour calendar attached to them. If that
is not the case, the system might try to remove all stocks during all those times
that are not defined in the calendar as working times. The SNP Optimizer might
report this as a definition gap. When using the storage consumption in at least one
location, then it should be defined in all locations of the product. Otherwise the
cost and penalty situation used by the SNP Optimizer is not consistently
maintained.

Segment Network Design

Part of Future Scope
GR Costs
Costs Good Issue
Delivery Time Quota
Time in Warehouse/Days
Ano Production

Additional
Up to 10 attributes can be defined per product, 5 each on global and location level. The
Additional tab is an optional tab that carries up to 5 product attributes on the location level.
This tab requires activation carried out in customizing. Without this activation the tab remains
invisible. The attributes are activated in the IMG (path APO > Master Data > Product > Freely
Definable Names for Attributes). This option allows to activate this function and to allocate
names that appear on the screen for all attributes. Additional data fields cannot be maintained
using the mass update function.

4.2.2.3

Resource

The resource master transaction provides all required functionality to maintain resources of all
types and categories. It is furthermore used to maintain definitions and capacity variants. It is thus
not only the APO resource maintenance transaction but also the central tool that allows the
maintenance of resource related data. The relation of these elements is described in another section.
This section concentrates on the maintenance of the data. The possible resource types in APO are:

Bucket Resources
Resources of this type are the Bucket Resource and the Shipment Resource.

Time Continuous Resources

In this group we find the Single- and Multi-Activity Resource, the Production Line, and the
Vehicle Resource.

Mixed Resources

Preparing

412

As the name indicates the resources of this type are a mixture of time continuous resources
and bucket resources. A mixed resource can be found for each type of time continuous
resources except the vehicle resource.
The resource category is another important distinguishing factor and determines together with the
resource type its usage area. Resource categories that can be maintained include:

Production
The single, and single-mixed, multi, and multi-mixed resource, as well as production line and
line mixed resource are typically of this category.

Storage
This category is used normally in conjunction with a bucket resource.

Handling
The single, and single-mixed, multi, and multi-mixed resource are of this type when used as a
load or unload resource in TP/VS. Bucket resources can also be of this type when used as
handling resources.

Transportation
Both, the shipment and the vehicle resource are part of this category. It is also possible to
create a bucket resource with the category transportation without any difference in terms of
resource usability.
Note that resource categories cannot be changed once the resource has been created. The resource
type is the other distinguishing factor.
The Master Data Maintenance Transaction
Path:
Technical Name:

Master Data > Resource

/SAPAPO/RES01

When starting the resource master maintenance transaction, a screen is displayed that allows the
specification of one or multiple resources to be edited. In order to provide this useful functionality,
the initial resource master maintenance screen is more complex. Specifically when handling
resource ranges, a number of parameters can be defined that reduce the number of resources
displayed later in the main screen. None of these selection criteria have to be defined when using
the resource Create option. When changing or displaying existing resource data at least one of
the following selections must be defined:

Resource
Specify the resource to be edited.

Location
Note that the same resource name can be used for various resources as long as they are
allocated to different locations.

Planner
When creating a resource it is very helpful to define a planner. In this case resources allocated
to a specific planner can easily be called up again.
Specifying any combination of the following optional fields can impose further restrictions:

Resource Category
Select only resources of the specified category.

Planning Version
Display only resource masters that exist in the planning version(s) as specified. Setting this
option disables the display of planning version independent resource masters, which includes
resource masters that are not assigned to any supply chain model.

Preparing

413

Model Independent
Display resource masters that are not allocated to any supply chain model, this includes
resource masters that were created and attached to a supply chain model previously but have
not been used in any planning activity. This flag can be set together with the previous one,
displaying all possible permutations.

Grouping
Resources can be grouped according to their resource categories (types). In this way,
resources of one or multiple resources categories can be called up simultaneously.
The initial screen is identical for bucket and time-continuous resources. It also allows direct access
to the capacity variant definition screen, which can also be accessed from the main resource
master screen. In this case, the selection criteria described above have no impact.

The resource master maintenance screen provides on the upper half a table, which displays all
selected resources. It is empty in the case of creating new resources. On the lower half, different
tabs provide the same information in a different presentation. Most of the data that can be found in
the tabs is also displayed in the upper half of the screen. The tabs on the bottom part of the screen
can be switched on or off using the Details button in the toolbar. The following section deals
with the maintenance of all resources types. The maintenance of the different resources types is
very much the same, although some fields are specific to certain resource types. The planning
parameter and standard capacity tabs are different for the various resource types. The resource
master fields of these tabs are explained separately per resource type.

Vehicle Resource
The vehicle resource type differs a lot from the other resource types, as it does not allow the
definition of downtimes or characteristics. There are also other minor differences in the
general data tab. This is depicted in the text.

Production Line and Line Mixed Resources

The available capacity of a line and line mixed resource can only be defined by means of
capacity variants. For this reason none of the fields of the standard capacity tab can be
maintained for line and line mixed resources.

Mixed Resources
Mixed resources are not a special type of resource but the combination of a bucket resource
and a time continuous resource. Mixed resources are not available for all types of resources.
In the transportation area we have the bucket type shipment resource and the time-continuous
type vehicle resource but no mixed resource covering both. For multi mixed resources only
those of option 1 can be supported by the multi mixed resource. Multi mixed resources where
a secondary capacity constraint is defined (option 2) cannot be modeled. A few fields that can
be found in a bucket resource are not part of the corresponding mixed resource. Mixed
resources definitions are dealt with separately but refer to either the time-continuous or the
bucket resource where applicable.
Preparing

The graphic below displays a symbolic layout of the resource master maintenance screen.

A pp licatio n B ar
R eso u rce T yp e T ab s (G rid )

R esou rce T ab s

Graphic 110 Resource Master Maintenance Screen Layout

The Application Bar

Functional Pushbuttons
Display <> Change
This pushbutton serves as a toggle key between the display and change
mode.
Overview / Details
Toggle key to switch on/off the detailed bottom display.
Select All
Selects all resources of the currently visible tab.
Preparing

Deselect All
Deselects all resources.
Sort Ascending
Sorts all resources of the currently visible tab ascending.
Sort Descending
Sorts all resources of the currently visible tab descending.
Delete Resource
Deletes the selected resource(s). See further down for requirements that
must be fulfilled before a resource can be deleted.
Copy Resource

Copies one or multiple selected resources. This function can also be used
to generate a sequence of resources.
Where-Used-List
Shows to which models the resource is linked to and to which locations
or transportation lanes it is linked (check all possibilities).
Resource List
Lists selected resources in a similar way to the grid. List can be printed.
Model Assignments
The resource master needs to be assigned to any Supply Chain Model it
is supposed to work with. The assign model function allows the resource
to be assigned to a supply chain model or to remove an assignment. This
way, there is no need to specifically open the supply chain engineer and
assign a newly created resource. While this method allows an easy
assignment to a supply chain model it obviously does not include it in
any work area.
The Assign Model pushbutton can also be also used to detach objects
from the supply chain model.
Capacity Variants
Displays all capacity variants for the current resource type. Maintain
capacity variants from this screen.
Capacity Profile
The capacity profile displays all defined capacities for the selected
resource (standard capacity and/or capacity variants). It also highlights
the currently valid capacity definition. This function is not possible for
vehicle resources.

Preparing

416

Resource capacities can also be maintained using this capacity profile

function. The displayed capacity is generated based on the resource
capacity definitions. Changing any of the capacities changes the resource
capacity time series and not any of the resource capacity definitions. This
method is specifically helpful if some minor capacity changes have to be
carried out that are only valid for a short time.
Definitions
Displays all definitions. Maintain definitions from this screen.

Deletion
A resource can be deleted from the header data screen after it has been selected. In order to delete
a resource, it must not be used in any PPM or SNP model! Whenever an attempt is made to delete
a resource the Where Used List is brought up automatically. If there is any entry, the deletion
process cannot be carried out. To proceed in such a case, first change any PPM that might use the
resource, and then detach the resource from any supply chain model. The deletion is then possible.
No further warning is brought up and after the next <Save> the resource will be deleted.
Prerequisites for the Creation
In order to maintain a resource some minimum requirements have to be met. As part of this, the
factory calendars must be defined. The majority of resources require to be linked to a location,
which must exist as well.
Other optional requirements exist as well. With the help of definitions, the maintenance of the
available capacity is greatly simplified. Several resources can share the same definitions, which
can then be used instead of the standard capacity.
Maintained Fields
The resource, definitions, and capacity variants maintenance transaction is described in various
documents, which are grouped according to the resource maintenance transaction tab and the type
of the resource where applicable.
The Resource Master Tabs

Header

General Data

Planning Parameters

Standard Capacity
Preparing

Downtimes

Characteristics

Short Texts

The Definitions Tabs

Time Continuous Resource Definitions

Shift Factors
Breaks
Shifts
Shift Sequences

Bucket Resource Definitions

Quantities/Rates

Production Line Resource Definitions

Rate Definitions
Material Dependent Rates

The Capacity Variants Tabs

Resource Capacity Variants

Other Functions
From Entry Screen without Dedicated Pushbuttons
Resource Capacity Variants
Capacity variants can be maintained and named according to individual needs.
Note that the SNP optimizer works only with the resource capacity variants 1
and 2. This option allows the maintenance of the capacity variant names but
not their allocation to specific resources.
Resource Type Grouping
Resources can be grouped according to their resource categories (types).
Multiple resource groups can be created, each consisting of one or multiple
resource types. Define own resource type groups and allocate one or multiple
resource types to the group.
Copy Resources
The copy resource function allows the copying of resources from one planning
version to another.
Preparing

LiveCache Check
This utility is a check tool to check whether resources are properly created in
liveCache. It also allows the creation of missing resources in liveCache.

4.2.2.3.1

Resource Header

Maintained Fields All Resources Types

 Resource
Specify a technical name or number of the resource. This resource name is
language independent and is used in the various interactive transactions such as
the Supply Chain Cockpit and the Supply Chain Engineer.
Short Description
The short description is a language dependent field. This means that the
description can be maintained in various languages and is consequently
displayed in the language stipulated when logging onto the system.
Planning Version
The planning version field is only displayed when maintaining the planning
version specific resource master record. Note that while a resource is allocated
to a supply chain model, the model independent resource master record is
copied into a planning version specific record, which from then onwards is a
separate data record that needs to be maintained separately.

4.2.2.3.2

Resource General Data

Maintained Fields All Resources Types

Global Data Segment
Resource Category
In the resource master maintenance screen, an individual tab can be found for
the resource category Transportation. Should a new resource be created via
the transport tab, the resource category Transportation is automatically
applied, and the resource will consequently appear under the transport tab only.
When created via the bucket tab, the resource category has to be defined
manually and the resource will consequently appear under the bucket tab. Other
than that there are no differences.
Location
Location in which the resource can be found or which is the home depot of the
Preparing

vehicle resource (e.g. for trucks). Displayed is location ID and name.

Time Zone
Define the time zone of the location and thus the resource. The time zone is
automatically copied from the location master if the resource is linked to a
location.
Planner
A responsible planner for the resource can be stipulated in this field. Although
this information is not required for any planning function, it can be used to
group resources. A planner should allocate all of his or her resources to an
individual planner ID. It is then possible to call up the resource maintenance
program and just stipulate the planner ID on the initial screen to see all own
resources.
Vehicle (Vehicle Resource only)

The shipment method specified in this field is used to match the resource to
required shipments per transportation method. During the VS planning run
resources with the same shipment method as the requiring transportation
method can be used to cover the transportation demand.
Factory Calendar
Defines the Calendar that is used for this resource. Storage resources must have
a 7-day calendar attached to them, as otherwise the optimizer will have
problems (definitions gap).
Capacity Segment
Active Variant
The capacity of a resource can be defined as a standard capacity (see the
appropriate tab) or via capacity variants. Multiple resources can share the same
capacity variant. The SNP Optimizer works with up to two capacity variants,
one depicting the normal, the other the extended capacity. This means that
usually more than one capacity variant is defined. The SNP and PP/DS
Heuristics need to know which of the capacity variants must be used. The
capacity variant to be used is the active variant.
Reference Resource (Not for Vehicle Resource)
If no capacities are maintained for the resource, the system tries to use the
capacity defined in the reference resource (if defined here).
The use of a reference resource works the same way as the use of profiles in the
product master. If a reference resource is specified during the creation of a
resource, all fields of the reference resource are copied into the resource. As
long as the name of the reference resource is not deleted in the resource any
change in the reference resource is reflected in the resource.
Reference resources cannot be defined for vehicle resources!
Preparing

4.2.2.3.3

Resource Planning Parameters

Maintained Fields Time-Continuous and Bucket Resources

General Segment
Days and Days +
The available capacity of a resource is defined in liveCache as a time stream.
This time stream is automatically generated in the background without any user
intervention. In order to conserve liveCache space, the time stream is limited by
the two fields Days and Days +. Together they determine the length of the
time stream and the relative position compared to the current date. The time
stream pointing into the future must be at least of the same length as the
planning horizon. If for example SNP planning is carried out for a full year, the
Days + must be set to at least 365 days, as otherwise the capacity appears to
have no capacity.
Two default values (-30 and +180 days) are used by the system when creating
any resource. The default values are defined in table /SAPAPO/RESLCT but
cannot be changed.
Sort String
This field is used in capacity planning to sort resources according to values,
other than the resource name.

 Bottleneck Resource
Defines the resource as a bottleneck. This flag is used to classify the resource as
one that requires special attention. This flag is not linked to specific planning
tasks, but can be used in the PP/DS planning board for example to display
bottleneck resources in a different color. It might also be handy for online
reports or other selections.
Finite Scheduling
Defines that finite scheduling has to be carried out for this resource. This is a
contradiction in the context of bucket resources, as bucket resources do not
allow finite scheduling. The flag is not used for bucket resources.
Storage Characteristics (Multi activity resource only)
If this flag is activated, a whole new tab, the Storage Characteristics tab, is
opened. The quantities defined on this tab can be seen as further restrictions on
the resource. The tab permits the definition of the following parameters:
o

Storage Dimension
The storage characteristic can be defined in one of various dimensions. A
tank would for example have a dimension of volume.

Stock Unit
Determine the unit of measure that is used for the storage characteristic.
This unit of measure must be in accordance with the storage dimension
(e.g.

Preparing

volume and liters).

o

Minimum Production Quantity

This is the minimum quantity that must be stored in the resource at the
beginning of the production process. If the production order is for a smaller
quantity, it will not be scheduled on the resource. The production order
quantity will not be increased to reach the minimum for the resource.

Maximum Stock Level

The maximum level determines the maximum quantity that can be stored at
any time in the resource. The order quantity can be split into smaller
batches, should this be required.

Remaining Quantity Allowed

Determines the maximum amount that may be in the resource when
another receipt (of the same product) is planned into the resource. If the
resource has to be completely emptied before a refill may take place, enter
a Zero here.

Not SNP relevant (Bucket resource only)

All bucket and mixed resources are used by SNP as soon as they are defined
and made part of the supply chain model. By setting this flag the resource will
not be used by SNP, even if it has a valid capacity.
Resources flagged as not SNP relevant are also not used when generating an
SNP PPM based on a PP/DS PPM. Operations using such resources are
consequently not included in the SNP PPM.
Maintained Fields Time-Continuous Resources Only

Time Orientated Segment

Setup Matrix (Single activity and production line resources only)
The setup matrix used for this resource (if any). Setup matrices together with
the setup group are used to minimize the time and/or cost required between
operations. PP/DS Heuristics as well as the PP/DS Optimizer use this
information. See the PP/DS section for further information.
Synchronized Start (Multi activity resource only)
Flag, that if set, forces all operations that run in parallel to start at the same
time. Multi activity resources can accommodate more than one activity at the
same time. Should it be required that all activities start at the same time, then
this flag must be set. The longest operation of those started synchronously will
then determine when the resource is available for the next set of operations.
Time Buffer with UoM (Single / multi activity resources only)
The time buffer defined here is used when scheduling activities on to the
resource. It stipulates the minimum time between two activities on the resource.
The time buffer can be used (and thus be ignored) if this is defined in the
scheduling strategy and the product PPM (relationship tab). The usage of this
Preparing

field is only supported by PP/DS scheduling.

Maximum Overlap with UoM (Single / multi activity resources only)
Defines the amount of time that two scheduled activities can overlap (planned
order, one not yet finished, but planned order two already starting). The higher
this value, the easier it is for the PP/DS planning to find a time slot for an
activity. Alerts can be created if the overlap is greater than this permitted value.

Maintained Fields Bucket Resources Only

Bucket Orientated Segment
Overload %
The overload percentage is the maximum allowed overload for the resource.
Any load above this value is seen as a not permitted overload. The SNP
optimizer loads the resource up to the permitted overload percentage set here.
Minimum Load %
Defines a minimum load the resource should have, below which it is identified
as underutilized. The alert monitor uses the minimum load percentage as a level
for generating alerts.
Schedule on Grid
If this flag is set, activities can only start at the beginning of the bucket period.
This implies that only one activity per bucket period can be scheduled for a
resource.
Cross Period Activity
This field is also called Activity Overlap Periods. It permits that an activity in
this resource may start on one day and be continued on another. Switch this flag
on to allow activities defined in the PPM to span over more than one period.
Periods are defined as one day. Failing to do so results in the activity only being
loaded onto the first day, and not onto all as required.

Maintained Fields Mixed Resources

All bucket resource as well as time-continuous resource specific fields can also be found with
mixed resources. The following table provides a comprehensive overview of the planning
parameter tab fields. The table depicts the allocation of the available fields to the resource types.

Resource
Master
Tab
Segment
Preparing

Field Name
Planning Parameters
General
Days
Days +
Sort String
Finite Scheduling
Bottleneck Resource
Storage Characteristic
Not SNP Relevant
Time Orientated
Synchronized Start
Setup Matrix
Time Buffer
Unit of Measure
Maximum Overlap
Unit of Measure
Bucket Orientated
Overload %
Minimum Load %
Schedule on Grid
Cross Period Activity
Table 78 Planning Parameter Fields

4.2.2.3.4

Resource Standard Capacity

Maintained Fields Time-Continuous Resources

Start and End Time
Start and end time of resource on workdays as defined in factory calendar.
Preparing

Operations can be scheduled in this time interval.

Break Duration
Break duration of resource on workdays as defined in factory calendar. If a
break is defined, all operations are extended in their duration according to the
relation between break time and available time according to the start and end
time.
Resource Utilization %
Defines the effective time worked in the resource in form of a percentage of the
total working time as defined above. The resource utilization percentage is used
to extend all operations in their duration according to this percentage.
Productive Time in Hours
This value is calculated by the system and shows the productive time in the
resource, taking into account start, end, and break times as well as the resource
utilization.
Capacity Button
The capacity button activates a pop up window that displays the valid capacity.
The definition of the valid capacity depends on various factors. Please refer to
the section Capacity Determination.
Origin Capacity Button
This function provides information about all defined capacity variants including
the standard capacity. It also provides information about which capacity
definition is active. For mixed resources this function provides information
about both types of capacities.
Maintained Fields Multi Activity Resources only
Dimension
Multi activity resources have a second capacity definition, besides their time
capacity. This capacity can be without dimension in cases where the multi
activity resource is used to represent multiple machines of the same type.
Alternatively the second capacity can be defined with a dimension to depict a
secondary capacity constraint.
Capacity
Define the secondary capacity of the resource in contents with the dimension
defined above.
Unit of Measure
The unit of measure used to describe the secondary capacity must be valid
according to the dimension defined above (e.g. unit kg and dimension weight).
Maintained Fields Production Line Resources only
The following fields refer to line resources (and line mixed resources only). The
parameters defined here are specific for the usage in a repetitive manufacturing
Preparing

environment. Refer to the appropriate section for more detailed information on

repetitive manufacturing.
Number of Takts
The field displays the takt time, which is the reciprocal value of the resource
rate.
Base Rate and Unit of Measure
Determines the rate of the resources (e.g. 10 pieces)
Per and Unit of Measure
Determines the time aspect of the rate defined above (e.g. per hour).
Rate Independent Takt Time Flag
Set this flag if the takt time is independent of the rate defined above.
Product Dependent Rate
The resource can be linked to a product dependent rate (see the section
definitions). This assignment must be done before the resource is assigned to
any supply chain model. Changes are not permitted anymore once the resource
has been attached to any supply chain model.
Maintained Fields Bucket Resources
Dimension
Defines the dimension type (e.g. time) of the standard capacity defined on the
standard capacity tab. This type must be the same as the one used for the
Quantity/Rate definition.
Number of Periods
Capacities can be in relation to time (e.g. 100 kg per hour) or without a time
relation (e.g. 100m3). This field contains the number of periods that the defined
capacities refer to if the capacities are time related.
Period Type
Defines whether the capacity is time related (see above) or without any relation
to time.
Bucket Capacity and Unit of Measure
This is the standard capacity of the bucket resource expressed in a unit of
measure that must conform to the dimension of the standard capacity defined
above.
Utilization Rate Bucket
The utilization rate determines the usable portion of the capacity defined above.
The difference between the capacity and the available capacity, which is
corrected by the utilization rate, is used to cater for known downtimes of the
resource.

Preparing

426

 Bucket Capacity Button

The capacity button activates a pop up window that displays the valid bucket
capacity. The definition of the valid capacity depends on various factors. Please
refer to the section Finding the Valid Capacity.
Origin Capacity Button
This function provides information about all defined capacity variants including
the standard capacity. It also provides information about which capacity definition
is active. For mixed resources this function provides information about both types
of capacity.

Maintained Fields Mixed Resources

All bucket resources, as well as time-continuous resource specific fields can also be found with
mixed resources. The following table provides a comprehensive overview of the standard capacity
tab fields for all resource types. The table depicts the allocation of the available fields per resource
type.

Resource
Master
Tab
Segment
Field

Name

Standard Capacity
None
Dimension
Start
End
Break Duration
Resource Utilization %
Productive Time in Hours
Capacity
Unit of Measure
Dimension Table (*1)
Capacity Button
Origin Capacity Button

Bucket Capacity Button

Preparing

Resource
Master
Tab
Field
Define Buckets (*2)

Segment
Name

Loss Factor in % (*3)

Dimension Bucket (*4)
Number of Periods (*4)
Period Type (*4)
Bucket Capacity (*4)
Unit of Bucket Capacity (*4)
Utilization Bucket % (*4)
Size of Transport. Resource

Table 79 Standard Capacity Fields

(*1)

The dimension table

capacities at the same
For mixed resources
continuous type capa
flag is a toggle key en
Mixed resources with
practical terms actual
set, then for example
based orders and vice
also plan for the PP/D
Only visible if field
Only visible if field

(*2)

(*3)
(*4)

4.2.2.3.5

Resource Downtimes

Maintained Fields All Resource Types

For cases where resources are not operational for a limited time, it is possible to define
such downtimes on this tab. The advantage is that the downtime is defined with specific
start and end dates, while the standard basic definitions do not need to be changed.
Downtimes can be defined for all types of resources.
Preparing

Valid From and Downtime Start Defines

the start of the downtime.

Valid To and End of Downtime

Defines the end of the downtime.
Type of Downtime
Select either planned downtime, which is valid throughout all planning
versions or resource is inactive. The latter is also valid for all planning versions
but can be changed individually per planning version.
Delete Button
Use this button to delete a defined downtime. Simply deleting the time settings is
not possible.

4.2.2.3.6

Resource Characteristics

Maintained Fields All Resource Types

Resources need to be classified in order to use the Block Planning functionality. Block
planning is used in finite scheduling, and consequently the allocation of a class to a
resource is only meaningful for time-continuous or mixed resources, although this
function is also available for other resources. The classification can still be carried out
for such other resources, but there is no functionality within APO using this
classification.
Class Name
This field allows the allocation of a class to the resource. Classes need to be
maintained in a separate master data transaction before they can be used in
conjunction with a resource.
Detail Class Button
Displays the characteristics that belong to the class that is allocated to the
resource.
Delete Classification Button
Deletes the class allocation. Simply deleting the class name does not detach the
resource from the class.
Block Planning Button
Allows the definition of parameters used in Block Planning, which is PP/DS
planning function.
Preparing

4.2.2.3.7

Resource Short Texts

Maintained Fields All Resource Types

Descriptions for the resource can be maintained in various languages. The language
indicator for the description is the same as used when logging on to the APO system.
Multiple descriptions in various languages can be maintained in parallel. The
specification of a language indicator is only required if the short text is typed in on the
tab. When using the grid on top, the system defaults to the logon-language automatically.
Language
Short Description

4.2.2.3.8

Resource Definitions

Maintained Fields All Definition Types

The bottom of the definitions screen always displays the same type of information,
independent of the displayed definition.
Planning Version (not for Product Dependent Rate)
Definitions, like resources, are defined model independent and per planning
version. When a definition is created initially, it is planning version independent.
Once a definition is linked to a resource, and this resource is part of a supply
chain model, then the definitions are created automatically in all planning
versions of the supply chain model, the resource is part of. This field displays the
selected planning version or blank.
Language
Descriptions for all definitions can be maintained in various languages. The
language indicator for the description is the same as used when logging on to the
APO system.
Description
Multiple descriptions in various languages can be maintained in parallel. The
specification of a language indicator is only required if the short text is typed in
on the tab.
Definitions can be changed while being attached to a resource via the capacity variants.
If the attached resource is already used in a planning version, all changes of the
definition immediately change the capacity definitions of this resource.
Maintained Fields Time Continuous Resource Definitions
Shift Sequences
Shift Sequence
Preparing

The Shift Sequence defines the sequences of shifts within a given period.
This is the name of the shift sequence, which is used to link the definition to
capacity variants. The shift sequence can be linked to time-continuous resources
and to mixed resources.
Day Number

The day number field is used to define either daily or weekly (or actually any
other granularity) shift patterns. The shift sequence automatically restarts after
the last day of the sequence. For daily defined shift patterns set this field to 1,
and for weekly shift patterns to 7. It is important to also define the nonworking days in any definition with a day number greater than 1.
Valid To
Definitions only have a valid to date and thus are usable from the creation date
onwards. The default end date is 31.12.9999 and there is always one definition,
which covers the period to this last date. Other periods can be inserted as
required.
Planner
This is the code for the planner responsible for the definition. It merely serves as
a reference and has no impact on planning tasks.
Non-workdays
Shift sequences describe a repeating pattern of working time. Should for example
a non-workday (e.g. public holiday) occur during this pattern, any shift that falls
entirely into the non-working day is flagged non-working time. This flag
determines whether the system should schedule in such a way that the last shift
before (or first shift after) of the workday that reaches into the non-working day
is working time or non-working time.
Example:
The 1st of May 2001 is a public holiday. The night shift as defined in the shift
sequence runs from 22.00 through to 06.00. Set the Non-workdays flag to Can
finish on a non-workday to make the entire shift working time, or to Can only
start or finish on a workday to make the entire shift non-working time.
Shift1 through to 9
Up to nine different shifts can be combined in any shift sequence. Define in these
fields the shifts as required.
Shifts
Shift Name
The Shift Definition stipulates the net available working time.
This is the name of the shift, which is used to link the definition to the shift
sequence.
Preparing

Valid To
Definitions only have a valid to date and thus are usable from the creation date
onwards. The default end date is 31.12.9999 and there is always one definition,
which covers the period to this last date. Other periods can be inserted as
required.
Planner
This is the code for the planner responsible for the definition. It merely serves as
a reference and has no impact on planning tasks.
Start and End Time
Define the start and end time of the shift.
Break Pattern

Use break patterns to enable the definition of more than one break per shift and to
define break rules (e.g. first break 2 hours after shift start). This field links a
break pattern to the shift definition.
Break Duration
The break duration definition is the simplest definition. It merely stipulates the
break time without any reference, when during the shift this break occurs. The
break duration is used to extend all operations in their duration according to this
time. The break duration field is gray (display only) if the break pattern is
defined.
Shift Factor
This field links a shift factor to a shift definition. If no shift factor is linked, the
factor is 100%.
Breaks
Break Pattern
Break Patterns define the non-working time.
This is the name of the break pattern which is used to link the definition to the
shift definition.
Break Number
Several breaks can be defined in one break pattern. All or none of the breaks
distinguished by the break number are linked to a shift.
Planner
This is the code for the planner responsible for the definition. It merely serves as
a reference, and has no impact on planning tasks.
Start and End Time
Define the start and end time of the break with the number as defined above. In
this case multiple breaks with distinct start and end times can be defined per shift.
Preparing

Break after Hours

Use this field to define how many hours after the shift start, the break is starting.
The break duration is defined in the field below.
Break Duration
Define the break duration in conjunction with the field above. The break duration
is used to extend all operations in their duration according to this time. The break
duration field is gray (display only) if a break start and end times are defined.
Shift Factors
Shift Factor
The Shift Factor defines the efficiency during working time.
This is the name of the shift factor, which is used to link the definition to the shift
definition.
Valid To
Definitions only have a valid to date and thus are usable from the creation date
onwards. The default end date is 31.12.9999 and there is always one definition

which covers the period to this last date. Other periods can be inserted as
required.
Planner
This is the code for the planner responsible for the definition. It merely serves as
a reference, and has no impact on planning tasks.
Capacity and Unit of Measure (Multi activity resource only)
Define (for multi activity resources only) the capacity with the appropriate unit of
measure. The unit of measure is not defined if the multi activity resource
represents a number of the same type of machines.
Resource Utilization
Define the resource utilization (efficiency) for the shift factor. The resource
utilization percentage is used to extend all operations in their duration according
to this percentage.
Maintained Fields Bucket Resource Definitions
Quantity Rate
Quantity Rate
The Quantity/Rates Definition defines the bucket capacity.
This is the name of the quantity/rate definition, which is used to link the
definition to capacity variants. Quantity rate definitions can be linked to bucket
resources and to mixed resources if the Define Buckets flag is switched on.
Valid to
Preparing

Definitions only have a valid to date and thus are usable from the creation date
onwards. The default end date is 31.12.9999 and there is always one definition
which covers the period to this last date. Other periods can be inserted as
required.
Planner
This is the code for the planner responsible for the definition. It merely serves as
a reference and has no impact on planning tasks.
Number of Periods
Specify the number of periods (e.g. days) only if the definition is a rate (e.g.
100kg per day). Leave this field blank if the definition is a quantity without
period reference.
Period Type
The period indicator for the number of periods specified above. SNP only allows
for days as a period type (or none).
Bucket Capacity and Unit of Measure
Define the capacity with unit of measure in accordance with the two settings
above. Note that the quantity/rate definition must have the same dimension as the
resource it will be linked to.
Costs
Specify the cost of using this quantity/rate. The definition of this cost is of utmost
importance as the SNP Optimizer uses these cost figures to find the optimal

solution. The SNP optimizer only uses costs defined in a production resource
quantity/rate definition if the definition is linked to a capacity variant 2.
Maintained Fields Production Line Resource Definitions
This is part of the future scope and not included in this version.
Rate Definitions
Quantity Rate
Rate Definition
Valid To
Planner
Number of Units
Unit of Measure
Number of Time Units
Time Unit
Product Dependent Rate
Preparing

Line Resource
Product Dependent Rate
Product
Planner
Number of Units (only displayed if line resource is defined)
Unit of Measure (only displayed if line resource is defined)
Number of Time Units (only displayed if line resource is defined)
Time Unit (only displayed if line resource is defined)
Factor

4.2.2.3.9

Resource Capacity Variants

Maintained Fields Capacity Variants

The creation of capacity variants is very similar for time-continuous, bucket, and mixed
resources. In this context the vehicle resource works like a time-continuous resource. To
create a new capacity variants, simply define the following information.
Capacity Variant
Specify the numerical key of capacity variant. The SNP optimizer works with the
capacity variants 1 and 2 only.
Valid from and to
Define the validity start and end date. Capacity variant cannot overlap.
Shift Sequence

This field is exclusive to time-continuous resources. Stipulate the name of the

shift and the sequence used for this capacity variant.
Quantity/Rate Definition
This field is exclusive to bucket resources. It is the identifying number of the
quantity/rate definition used for this capacity variant.
First Day
Define the number of the day within the shift sequence that represents the first
day of the shift sequence. If for example the shift sequence is a weekly one, with
day one representing a Monday, and the valid from date is a Wednesday, this field
must be set to 3.
Workdays
This field is exclusive to time-continuous resources. It determines whether the

Preparing

435

days in the shift sequence are either workdays according to the factory calendar
of the resource, workdays, or non-workdays.

4.2.2.4

Production Process Model (PPM)

The PPM is a highly structured multi-level master data object. It combines products and resources
and is impacted by their settings. In the following sections we will go through all fields required to
set up a PPM for use in DP, SNP, and PP/DS. Although a lot of definitions are identical for all
types, it is advisable to understand the distinct differences between the usage types.

Usage Type
D
S
P
T
Table 80 PPM Usage Types

The Master Data Maintenance Transaction

Path:
Technical Name:
The plan/PPM master data maintenance screen is subdivided into three panels. The right one
displays the plan/PPM data and is the panel where the majority of data is captured and displayed.
On the left side two panels are displayed, the work area and the plan flow diagram. Both panels on
the right hand side can be switched off if desired.

The Plan/PPM Data Panel

The data panel is a multi-level screen structure that allows the maintenance of all relevant
plan/PPM data.
For more information see Plan/PPM Data Panel.

The Tree Structure

The plan/PPM master data maintenance incorporates the usage of user specific work areas.
These work areas are different to those used for example in the supply chain engineer. These
work areas for the plan, products, and resources provide an overview of the selected data and
can also be used to drill down onto a specific position in the plan/PPM data panel.
For more information see PPM Tree Structure.

The Plan Flow Diagram

The diagram provides a graphical overview of all elements of the plan and their
relationships. For more information see PPM Plan Flow Diagram.
The graphic below displays a symbolic layout of the SNP PPM Maintenance screen.
Preparing

A p plicatio n B ar

T ree
P anel

P lan /P P M D ata P an el
D P B O M D ata P an el
S N P P lan /P P M D ata P an el

P lan F low P
anel

P P /D S P lan /P P M D ata P an el
P P /D S T rim P lan /P P M D ata P an el

Graphic 111 PPM Maintenance screen layout

The plan/PPM master data maintenance transaction is made up of various screens that can be seen
in the data panel. Each screen has a header section and one or multiple lower-level sections. These
lower-level sections allow drilling down to the subordinate levels. At the end of these drill-down
paths, one can find one of the following elements:

Plan definitions

PPM definitions

Operation definitions

Activity definitions

Component definitions

Mode definitions

Resource definitions

Activity relationships

Multi-lingual descriptions

Hot-jump possibilities to other master data

Initially the PPM maintenance transaction appears to be very confusing, but working with it for a
while reveals that a lot of thought went into this transaction, and as the PPM is a complex master
data element, the maintenance is also rather complex.
When starting the plan/PPM master data maintenance transaction, the initial screen Choose Plan
is displayed. The following data can be maintained:

Plan
This section is used to define the plan number that should be opened for editing or creating.
All Plans
Define the plan number or select the pull-down menu to find the plan via the plan
number. Alternatively type in a plan number for a new plan.

Preparing

437

o Plan Number
Choose Plan through PPM
Define a product and/or location and press the change or display button. This opens a
pop-up window displaying all plans according to the selected product and/or location.
o Plan Number
o Product
o Location
Usage
The usage does not need to be defined but will automatically be displayed by the system,
if not specified. Note that a specific plan number can only be used in connection with one
usage type.

Display
Select a work area and/or logical view. The logical view with the name Default is used in
all cases where no other logical view has been defined. Work areas and logical views can be
maintained per plan within the plan/PPM master data maintenance transaction.
Work Area
Select a work area to determine which data is shown in the tree structure. The system
creates a new work area if a name is typed in that does not refer to an existing work area.
Logical View
o Logical View Entry Box
Select a logical view to determine how the plan/PPM elements are shown in the plan
flow diagram. Each plan has at least one view, called the Default view. Under this
view name the position of the plan flow diagram elements are stored automatically,
if no specific name was defined. A plan could have several views at the same time.
o Automatic Alignment Flag
Set this flag to automatically align all elements in the plan flow diagram. Elements
are then shown according to the automatic alignment settings, and not the way they
were
shown when the plan/PPM was last saved.
o Alignment Setting Pushbutton
Use this button to customize the automatic alignment settings.
The system creates a new logical view if a name is typed in that does not refer to an
existing logical view.

Options
Multiple Display
Set this flag to view plan elements (in the plan flow diagram) that are used in several
operations or activities multiple times (e.g. show a resource that is used twice in two
activities). If that flag is off, the element is shown once, irrespective of how often it is
used in the plan, but is still linked to the operations and activities as required (e.g. show
resource once but with two links to the activities).
Display Hierarchy
If this flag is set, the tree structure also displays the product and resource hierarchies in
the
tree structure.
This leads to the first screen, which shows some plan specific information together with the
operations of the plan. The screen names used in the following description are used to distinguish
between the various displayed elements. These names can also be seen in the plan/PPM
transaction.
The plan/PPM maintenance transaction uses an impressive range of pushbuttons. As a general
rule, the button on the left hand side is a Return to. button, which is the opposite of a drilldown
Preparing

function. Drilling-down can be achieved by double-clicking on a line in a grid display, or by

positioning the cursor in the respective line and pressing the button symbolized by a magnifying
glass. The Back button should not be used when maintaining a plan (PPM), as it does not bring
the user one step back, but completely out of the transaction.
More pushbuttons can be found on the application bar. One can distinguish between functional
pushbuttons that change PPM data, display mode pushbuttons that change the appearance of the
PPM master data transaction, and other functions without dedicated pushbuttons.
The Application Bar
Functional Pushbuttons
Check Plan
With all these possibilities when setting up a PPM, it is easily possible to
forget something or to define inconsistent production process models.
For this reason APO offers a check facility that verifies the logical
consistency of the PPM. This check is carried out automatically while
activating a PPM.
Activate
Activates the PPM if error free (see above). Only an active PPM can be
used in SNP planning. The system suggests the activation function when
saving a PPM.
Deactivate
Deactivates a PPM and makes it thus unavailable for SNP planning. This
is sometimes a helpful tool as it makes a PPM (temporarily) unavailable
for SNP planning. It does not need to be attached to the supply chain
model again after the renewed activation.
Display Mode Pushbuttons
Legend
Displays some of the symbols used in the various SNP PPM maintenance
screens. Double-click on an element in the tree structure to get out of this
screen.
Graphical Display
This button is a toggle key switching the tree structure and plan flow
diagram on and off.
Edit Work Area
Opens the work area and logical view edit screen. The work area
defines which PPMs, products, and resources are displayed in the tree
structure. See The Tree Structure for more details. The logical view
determines how the plan/PPM elements are shown in the plan flow

Preparing

439

diagram.
Detailed Display
Select any line in the tree structure or any element in the plan flow
diagram. Pressing this pushbutton then positions the plan/PPM data panel
accordingly. The same can be achieved by simply double-clicking on an
element.
Align with Grid
Button with apparently no attached function.
Arrange Automatically
Use this button to customize the automatic alignment settings and use
them at the same time for the plan currently displayed.
Individual Display
Activate this function to view plan elements in the plan flow diagram that
are used in multiple operations or activities once only. In this case the
element is still linked to the operations and activities as required (e.g.
show resource once but with two links to the activities).
Multiple Display
Activate this function to view plan elements in the plan flow diagram that
are used in multiple operations or activities multiple times (e.g. show a
resource that is used in two activities twice).
Deletion
Production process models can be deleted in a one step process. They should be deleted from any
supply chain model beforehand.
Prerequisites for the Creation
Plans which are on global (non location-specific) level, can be created and saved without any
technical prerequisites. For the production process models to be created (on location level), it is
required that the products and resources defined in the plan structure are defined on location level.
A PPM does not require a resource being linked to it, but it does require the definition of at least
one output product. Without that, the PPM can be saved, but not activated.
Maintained Fields
This section explains screen by screen the data that can be defined for a plan and production
process model in the plan/PPM data panel. These screens are linked in a hierarchical structure. An
explanation of the tree structure and the plan flow diagram follows after that.

Preparing

440

The tree structure and the plan flow diagram layout are the same for all PPM usages. The
plan/PPM data panel differs depending on the PPM usage.
The Plan/PPM Data Panel
The data panel is different according to the plans usage type. Refer to the different sections for
further information.

DP BOM Data Panel

The DP BOM data panel is a scaled down version of that used for the SNP PPM. The
difference is that no resource relevant information can be maintained and consequently the
Modes tab on activity level cannot be found with this PPM usage type.

SNP Plan/PPM Data Panel

PP/DS Plan/PPM Data Panel

PP/DS Trim Plan/PPM Data Panel

The Tree Structure

The tree structure displays various elements and master data objects used in the plan/PPM. It is
subdivided into three tabs.

Plan
View on this tab the plan with its operations, operation/activity relationships and PPMs.
Clicking on the plus symbol opens the tree structure lines. Double-clicking on any line
displays the element in the plan/PPM data panel.

Products
This tab displays all products that are used in the plan/PPM as input or output products.
If the Display Hierarchy flag was set on the initial screen, then all product hierarchies are
shown underneath. All products can be related to the hierarchies they belong to.

Resources
This tab displays all resources that are used in the plan/PPM as input or output products.
If the Display Hierarchy flag was set on the initial screen, then all resource hierarchies are
shown underneath. All resources can be related to the hierarchies they belong to.
The Plan Flow Diagram
The plan flow diagram displays the plan in a graphical layout. The elements of the plan flow
diagram (e.g. operations and activities) can be moved individually as required and saved in a
Logical View. Various logical views can be defined for a plan and applied to it. Alternatively,
the elements can be arranged automatically. But even these automatic settings can be customized.
Use the plan flow diagram as well to define the way the plan/PPM data panel displays the plan.
Simple Display
Preparing

With the simple display mode switched on, the plan/PPM data panel shows one element at a
time without any subordinates (e.g. the operation is shown without the table underneath that
lists all activities).

Extended Display
With the extended display mode switched on, the plan/PPM data panel shows one element at
a time with all directly related subordinates (e.g. the operation is shown with a table
underneath
that lists all activities).
To switch between simple to extended display, select an element in the plan flow diagram and
select the appropriate option.

Pushbuttons
Fit to Objects
Press this pushbutton to make all elements fit into the plan flow panel.
Zoom Out
Zoom out function.
Zoom In
Zoom in function.
Filter
Press this pushbutton to select which element types (e.g. operations or
activities) are shown in the plan flow panel.
Select
This is the default display mode. Use it for double-clicking on elements
so that the plan/PPM data panel displays the selected element.
Highlight
Switch this display mode on to highlight elements the cursor is
positioned on. Click on an element to view text information about the
element (click on the x to delete this text window).
Move
Switch this display mode on to move elements to other positions within
the plan flow panel. Doing so has no impact on the logical structure of
the plan.
Connect
Switch this display mode on to create predecessor / successor relations
within the plan. Doing so changes the logical structure of the plan.
Switch Connections

Preparing

442

Press this pushbutton to change the way the elements connections are
displayed. The pushbutton is a toggle key between connection direct lines
with angles as required, and connection lines that are exactly horizontal
and vertical.
Print / Save
Use this pushbutton to print or save the graphical display.

Other Functions

Work Area
A work area can be defined in a PPM, which determines the products and resources that are
shown in the tree structure.
If no work area is defined, the tree structure contains all products and resources that are
used in the plan.
If a work area is defined, the tree structure contains all products and resources as defined
in the work area. If those that are part of the plan are not defined in the work area, they
will also not be displayed in the tree structure.
When starting the plan/PPM master data maintenance transaction, the required work area can
be stipulated. For more information on defining and maintaining work areas, view the section
Work Area.
The work area used in the plan/PPM master data maintenance is for exclusive use within this
transaction, and is not shared with other transactions.

Logical View
A logical view can be defined in a PPM, which determines how the elements in the plan flow
diagram are displayed.
If no logical view is defined, the plan flow panel uses the Default view.
Various logical views can be defined per plan.
All views are automatically maintained when changing the positions of the elements in the
plan flow panel, and saved when leaving the transaction.
When starting the plan/PPM master data maintenance transaction, the required logical view
can be stipulated. For more information on defining and maintaining work areas, view the
section Logical View.
The logical view used in the plan/PPM master data maintenance is for exclusive use within
this transaction, and is not shared with other transactions.

Generation of SNP PPM

The SNP PPM has no counterpart within the R/3 system. The R/3 Production Version,
which is a combination of Bill of Material and Routing, is used to maintain the PP/DS PPM
in APO. The SNP PPM needs to be maintained manually within APO, as it cannot be
maintained in R/3 and transferred using the core interface (CIF).
It is possible though to generate an SNP PPM based on a PP/DS PPM. In order for this to
work, some assumptions and restrictions need to be understood.
Preparing

Only mixed resources must be used in the PP/DS PPM.

Only products that are flagged as relevant to SDP are included in the generation. The
flag can be set in the product master attributes tab (field SDP Relevance).

 Only resources that are flagged as relevant to SNP are included in the generation. The
flag can be set in the resource master planning parameters tab (field Not SNP
Relevant).
As a result of the above restrictions, the SNP PPM operation and activity structure is not
necessarily identical to that of the PP/DS PPM.

4.2.2.4.1

SNP Plan/PPM Data Panel

All references made in this section regarding the PPM relate to the PPM used in SNP even if this
is not explicitly mentioned. The following graphic provides a first high-level overview of the
plan/PPM data structure and its elements as used in the data panel.

Preparing

444

Model

Assignement

Model

Assignement

Pop-up Window: Model

Assignment

Graphic 112 PPM Screen Structure (SNP)

What can be seen in the above graphic is actually the maintenance of a plan and not only of a
single PPM. The plan, which contains one or multiple production process models is the real master
data object maintained in this transaction and not just a PPM. This difference, although not this
obvious, is important. Within APO references are usually made to a PPM even if a plan is meant.
It is required from the user to know what is meant where.
Preparing

Screen:

Header Section:
Type
Overview

Pushbuttons
Operations
Select this button to view all operations of the plan.
Product Plan Assignment

Select this button to define the PPMs of this plan. Not more than one
PPM can be defined per putout product.
Multilingual Text Maintenance Plan
Select this button to enable the language dependent maintenance of plan
descriptions.
Model Assignment (pop-up window)
Allows the allocation of the PPM (not plan) to one or multiple supply
chain models in a pop-up window. This function is not possible in
situations where more than one PPM is defined within the plan and not
all PPMs are assigned to the same model. The model assignment can
only then be carried out from the PPM screen.
The Assign Model pushbutton can also be also used to detach objects
from the supply chain model.
Maintenance
Activating this button, which is situated not on the top but next to the
cost profile field, allows the creation and editing of cost functions. The
used cost function is of type P.
Fields
Plan Number and Description
Displays the plan (not PPM) number and description. The plan number
and description are not visible in the supply chain engineer or cockpit.
Usage
Displays the usage of the plan. The usage is determined when creating
the plan and cannot be changed subsequently. The usage determines in
which application areas the PPM can be used. Specific usage types and
Preparing

corresponding PPM usage exist for the SNP and PP/DS planning tasks.
Unlike a mixed resource, no single PPM can be used for both areas.
Status
In order to use a PPM it must be not only saved but be activated before
the saving. Additionally it must be attached to the supply chain model.
The status field depicts whether the plan including any PPM created
within the plan is active or not. It does not depict whether the plan is
attached to any supply chain model.
Single Level Cost
The SNP optimizer uses the single level variable cost to select the most
cost efficient production option. It is not used by the SNP Heuristics.
This variable cost represents the cost associated with the activities as
described in the plan. It must not include component usage costs. The
variable cost defined here is only used as long as no cost function (see
further down) is defined.
o

Variable

Multi Level Cost

Multi-level costs are used by the SNP Heuristics to select the lowest-cost
procurement option. The multi level costs must include all cost when

using this PPM including used components. Cost can be defined quantity
independent (fixed) and quantity dependent (variable).
o Variable
o Fixed
Change Information
Change information data, also referred to as administrative data, is
created automatically by the system and can only be viewed. It displays
the user ID used when creating (changing) the plan/PPM and is shown
together with the create/change date.
o

Created By and Date

o Changed By and Date

Cost Profile and Maintenance Button
The SNP optimizer uses the cost function to select the most cost efficient
production option (see the field single level cost above).
PP/DS Plan
This field points to the PP/DS plan that corresponds to this SNP plan. It
is not a field with any function but provides a visible link. The field is
populated automatically when generating an SNP plan based on a PP/DS
plan.
Section:
Preparing

Operation

Type
Overview

Pushbuttons

Fields

Section:
Type
Overview

Pushbuttons

Preparing

Fields

Section:
Type
Overview

Fields
Language Key
Plan Description

Section:
Type
Overview
Preparing

Fields

Screen:

Header Section:
Type
Overview

Pushbuttons
Return to Plan
When selecting this button the plan maintenance returns to the plan level.
Multilingual Text Maintenance PPM
Select this button to enable the language dependent maintenance of PPM
descriptions.

Operations
Switches over to the Operations screen.
Model Assignment (pop-up window)
Allows the allocation of the PPM (not plan) to one or multiple supply
chain models in a pop-up window.
Location Product Parameter
Position the cursor in a field that displays a location (product) and
activate this button to hot-jump into the location (product) maintenance
of the selected location (product).
Fields
Preparing

Production Process Model and Description

The PPM and its description are defined in these two fields. They are
visible in the supply chain engineer (and not the plan name). Without the
definition of the PPM the plan remains an empty shell that cannot be
used for planning purposes.
Output Product
This is the product number of the output product that is described in the
plan and the PPM. More than one output product can be defined per plan
but only one PPM per output product can be defined.
From and To Date
Determines the validity date of the PPM. Only one validity period and/or
lot size range can be defined per PPM within a plan.
Location
The plan is not linked to any location. The resources used in a PPM are
linked to a specific location. If several resources are used in a plan it is
even possible that these resources point to different locations. The
location defined here determines for which location the PPM is valid.
Should a demand for an in-house manufactured product arise, the system
tries to find the appropriate PPM that is valid for the location by using
this location number.
Procurement Priority
The procurement priority is used by the SNP Heuristics planning
methods. If during a planning task a requirement for a product occurs
that could be sourced internally and externally (from one or several
locations), the system uses the procurement priority to derive the source
of supply. This also applies to manually created orders in SNP. The
procurement priority defined in the PPM is compared with the
procurement priority of the transportation lane to decide between internal
and external procurement. If no procurement priorities are defined for
the transportation lane and the PPM (or the priorities are the same), then
the system selects the cheapest of all available possibilities. To do so the
multi-level cost of the PPM (see above) is used.
Discretization Flag
Cost values in the PPM are defined as linear functions (e.g. cost per
case). The SNP Optimizer can use linear costs as long as it is run in the
linear mode. In the Discretization mode one or multiple linear functions

can be broken down into a number of single discrete values. If this

should be carried out for the PPM related data, a flag needs to be set in
the optimizer profile and in the corresponding PPM this flag needs to be
set.
Bucket Offset
The bucket offset is used when calculating the receipt time of a SNP
planned production order. Assuming a working time from 08.00 to 16.00
Preparing

(8 hours) and a bucket offset of 0.25 all planned receipts between

08.00 and 10.00 (25% of 8 hours) are deemed to be available at the
beginning of the bucket. All other planned receipts between 10.00 and
16.00 are deemed to be available at the end of the bucket, which is also
the start of the next bucket.
The bucket offset is the equivalent to the rounding transportation time,
which is defined in the transportation lane.
Minimum and Maximum Lot Size
As an optional entry, lot size ranges can be defined to further restrict the
validity of a PPM. Define the lower limit (if any) here. Defining a lower
or upper limit only can also set a lot size range. Only one validity period
and/or lot size range can be defined per PPM within a plan. These
settings can be used by the SNP Optimizer to define a minimum lot size
when discretizing the lot size range.
Screen: Model Assignment
Type
Overview
Fields
Assignment Check Box
Click the assignment check box to assign a PPM to a supply chain
model. The same PPM can be assigned to one or several supply chain
models. To break the assignment click on the assignment check box
again. Select the <save> function to close the pop-up window and save
the assignment definitions. Multiple assignments can be done at the same
time.
Model and Model Description

Screen:

Header Section:
Type
Overview

Preparing

Basis
Pushbuttons

Fields
Operation and Description
Displays the selected operation ID and description. Note that the
operation number as such does not depict any specific operational
sequence within the plan. The sequence of operations is determined via
the relationships (e.g. operation 0020 could be after operation 0060).

Section:Activity
Type
Overview
Pushbuttons

Preparing

Fields

Section:

Type
Fields

Section:

Type
Fields

Screen:

Header Section:
Type
Overview

Preparing

Basis

Pushbuttons

Fields
Activity and Description
Displays the selected activity ID and description. Note that the activity
number as such does not depict any specific activity sequence within the
plan and operation. The sequence of activities within operations is
determined via the relationships (e.g. activity 300 could be after activity
700).
Activity Type and Description
This definition determines whether the activity is, for example, of type
production or setup.
Scrap %
Define a time independent scrap percentage. How scrap values are
calculated is dealt with in the section Scrap Calculation.
Preparing

Time Dependent Data Flag

Time dependent parameters can be defined per activity by selecting the
appropriate activity line and pressing the Time Dependent Parameters
button. This flag is set automatically whenever time dependent
parameters are defined.

Section:
Type
Overview

Pushbuttons

Fields

Section:Components/Modes
Type

Two-Tab Multi-Line Grid

Overview
They

This section is split into two tabs, the components and the modes tab.
feature different fields and different sets of pushbuttons on top of the tabs.

Components Tab
Pushbuttons
Close
Preparing

Selecting this button closes the activity relationship section and leaves
the lower section of the screen empty. Select the appropriate button in
the activity section to open the activities or another view again.
Select Row
Drilling-down onto an alternative component can be achieved by doubleclicking on a line in the grid display or by positioning the cursor in the
respective line and pressing this button.
Delete Line
Select a line in the grid display by positioning the cursor in the
respective line and press this button to delete a predecessor/successor
relation.
Product Parameter

Position the cursor in a field that displays a product and activate this
button to hot-jump into the product maintenance of the selected product.
TD Parameters Alternative Components
Select this button to enable the time dependent maintenance of
alternative components.
Fields
For an explanation of all fields see Screen: Alternative Components.
Modes Tab
Pushbuttons
Close
Selecting this button closes the activity relationship section and leaves
the lower section of the screen empty. Select the appropriate button in
the activity section to open the activities or another view again.
Select Row
On the Modes Screen only the primary resource can be maintained.
Double click on the primary resource line or press this pushbutton to drill
down to the secondary resources level.
Delete Line
Select a line in the grid display by positioning the cursor in the
respective line and press this button to delete a mode definition.
Resource and Location Parameter
Position the cursor in a field that displays a resource (location) and
activate this button to hot-jump into the resource (location) maintenance
of
Preparing

Fields

Section:
Type
Fields

Section:
Type

Fields

Section:

Type
Overview

Pushbuttons

Preparing

Deselect All
Deselects all selected lines.
Scrap <> Yield
This pushbutton is a toggle key, and pressing it changes the display of
the field Scrap (%) / Yield Percentage (see below) from scrap to yield
or yield to scrap.
Fields
Planning Version
The time dependent parameters can be limited for use with one planning
version only. It is also possible to define different time dependent
parameters for several planning versions. To do so, select the appropriate
planning version and define all values. Then select another planning
version and define the new set of values.
Valid To
Define the valid to date. If there are periods in-between where the default
scrap value, as defined above, should be used simply specify these
periods here again and do not set the Scrap / Yield Indicator.
Scrap / Yield Indicator

Set this indicator so that the defined scrap value in this time dependent
parameter is applied. The time dependent parameters will not be used
unless this indicator is set.
Scrap (%) / Yield Percentage
Define a scrap percentage. How scrap values are calculated is dealt with
in the section Scrap Calculation.
Screen:

Header Section:
Type
Overview

Basis

Preparing

Activity and Description

Pushbuttons
Return to Activity
When selecting this button the plan maintenance returns to the activity
level.
Activity Relationships
To drill-down onto an activity relationship position the cursor in the
respective line and press this button.
Product Plan Assignment
Select this button to define the PPMs of this plan. Not more than one
PPM can be defined per putout product.
TD Parameters Alternative Components
Select this button to enable the time dependent maintenance of
alternative components parameters.
Product Parameter
Position the cursor in a field that displays a product and activate this
button to hot-jump into the product maintenance of the selected product.
Fields
Prevention of Product Explosion

Set this flag if the component must not be used during the PPM
explosion. In this case no requirements are created during the PPM
explosion. The component consumption can still be posted after the
manufacturing has taken place; it is just not planned in a deterministic
way.
From and To Date
The validity start date permits the time dependent definition of input and
output products. During the order generation the PPM is exploded and
the product validities are used in accordance with the planned production
date as anticipated in the planned order. The same component can be
defined for different non-overlapping periods.
Product and Description
Define the product number of the input our output product. Any plan
must have at least on output product but does not need to have any input
products. For each output product a PPM can be generated. To model a
process with co-products or by-products simply define multiple output
products.
It is not permitted to define within the same plan the same product as an
output product in one operation and in a subsequent operation as an input
Preparing

product. If semi- finished products need to be modeled then it is required

to define two plans with separate input and output products.
Variable Consumption
Define the variable consumption or output quantity of the product. This
is measured in the products base unit of measure. The quantity will be
required or available in accordance with the consumption mode
indicator.
Unit of Measure
Any unit of measure defined for the component can be used. If no unit of
measure is defined, the system automatically uses the products base unit
of measure.
Input/Output Indicator
Specify whether the product is an input (I) or output (O) in this plan (see
field product above).
Consumption Type
Select one of the consumption modes S, E, or C (for consumption being
at the start, the end, or continuously). The consumption mode is
important for the material requirements planning as it drives the
requirement date for the input component and the availability date for the
finished product.
Time Dependent Parameters Flag
Time dependent parameters can be defined per component by selecting
the appropriate component line and pressing the Time Dependent
Parameters button. This flag is set automatically whenever time
dependent parameters are defined.

Section:
Type

Overview

Pushbuttons

Preparing

Select All
This button can be used to select all lines and delete them.
Deselect All
Deselects all selected lines.
Fields
Valid To
Define the valid to date. If there are periods in-between where the default
consumption values, as defined above, should be used simply specify
these periods here again and do not set the Variable Parameter and/or
Cost Indicator.
Variable Parameter
Set this indicator so that the defined material consumption value in this
time-dependent parameter is applied. The time dependent parameters
will not be used unless this indicator is set.
Material Consumption

Screen:

Header Section:
Type
Overview

Basis

Pushbuttons
Return to Activity
When selecting this button the plan maintenance returns to the activity
level.
Activity Relationships
Preparing

To drill-down onto an activity relationship, position the cursor in the

respective line and press this button.
Resources
To drill-down onto a resource, position the cursor in the respective line
and press this button.
Product Plan Assignment
Select this button to define the PPMs of this plan. Not more than one
PPM can be defined per putout product.
Time Dependent Parameters Mode
Select this button to enable the time dependent maintenance of mode
parameters.
Resource and Location Parameter
Position the cursor in a field that displays a resource (location) and
activate this button to hot-jump into the resource (location) maintenance
of the selected resource (location).
Fields
Mode
Within SNP only one mode per activity can be defined. The mode name
is not important but the same mode name should be used for all
activities.
Primary Resource
Select the primary resource for this activity. An operation must have
exactly one primary resource but may have one or multiple secondary
resources. Only the primary resource is used for scheduling. The
maintenance of the primary resource needs to be continued on the screen
with the secondary resources (see below).
Location
Specify the location of the resource used above. This is required as only
the combination of resource and location name is unique.
Fixed Duration
Define the fixed duration as 1 for SNP.
Unit of Measure

Select the time unit for Day as SNP requires planning in daily
buckets. Break not Allowed Flag
Switch this flag on if activities must not be interrupted by breaks. This
flag can pose problems if an order needs to be created that runs longer
than one day. In this case there is no possibility to find any slot for
scheduling that
Preparing

is long enough to enable a break free

operation. Break without Interruption

If breaks are permitted but only up to certain maximum length,

then define this maximum length in this field. The format is
hhhhhh:mm.
Time Dependent Parameters Flag
Time dependent parameters can be defined per mode by selecting the
appropriate mode line and pressing the Time Dependent Parameters
button. This flag is set automatically whenever time dependent
parameters are defined.

Section:Resources
Type
Overview
Pushbuttons

Fields

Section:

Time Dependent Parameters Mode

Preparing

Type
Overview
Pushbuttons

Fields
Valid To

Bucket Variable Parameter

Set this indicator so that the defined material consumption value in this
time dependent parameter is applied.
Resource Consumption (Bucket Variable)
Define the fixed time resource consumption in the base unit of
measure. Duration Time Unit
Define the unit of measure used above for specifying the resource
consumption.
Bucket Fixed Parameter
Set this indicator so that the defined material consumption value in this
time dependent parameter is applied.
Resource Consumption (Bucket Fix)
Preparing

Define the fixed time resource consumption in the base unit of

measure. Duration Time Unit

Define the unit of measure used above for specifying the resource
consumption.
Screen:

Header Section:
Type
Overview

Basis

Pushbuttons
Return to Mode
When selecting this button the plan maintenance returns to the mode level.
Activity Relationships
To drill-down onto an activity relationship position the cursor in the
respective line and press this button.
Product Plan Assignment
Select this button to define the PPMs of this plan. Not more than one
PPM can be defined per putout product.
Time Dependent Parameters Resources
Select this button to enable the time dependent maintenance of resource
parameters.
Resource and Location Parameter
Position the cursor in a field that displays a resource (location) and
activate this button to hot-jump into the resource (location) maintenance
of the selected resource (location).
Preparing

Fields
Resource
Define one or multiple secondary resources. Secondary resources are
loaded with the required capacity but not seen as a constraint for
scheduling. Scheduling is carried out based on the primary resource only.
Secondary resources can always be overloaded. The first line
automatically displays the primary resource as a reference.
Location

Specify the location of the secondary resource. The first line

automatically shows the location of the primary resource.
Multi Activity Resource
The Multi Activity flag is a display only field and if switched on it
shows that the selected resource is a multi-activity mixed resource.
Calendar Resource
Mark exactly one resource per activity (primary or secondary) as a
calendar resource. The calendar attached to the resource that is flagged in
this way is used to determine working and non-working times.
Scheduling is always carried out according to the primary resource.
Secondary resources can always be overloaded irrespective of whether
they are calendar resources or not.
Unit
Define the unit of measure used when specifying the resource
consumption (see below).
Variable Bucket Consumption
Specify the variable resource consumption in the unit of measure as
defined above.
Fixed Bucket Consumption
Specify the fixed resource consumption in the unit of measure as defined
above.
Time Dependent
Time dependent parameters can be defined per product by selecting the
appropriate line and pressing the Time Dependent Planning Parameters
button underneath the table.

Section:
Type
Overview

Preparing

pushbuttons displayed on the screen.

Pushbuttons
Version
Press this pushbutton and select a planning version to enable definition
of this time dependent parameter per planning version.
Insert Period
Press this button to insert a new period between existing ones.
Delete Line
Select a line in the grid display by positioning the cursor in the
respective line and press this button to delete a time dependent
parameter.
Select All

This button can be used to select all lines and delete them.
Deselect All
Deselects all selected lines.
Fields
Valid Until
Define the valid until date. If there are periods in-between where the
default consumption values, as defined above, should be used simply
specify these periods here again and do not set the Variable Parameter
Indicator.
Bucket Variable Parameter
Set this indicator so that the defined resource consumption value in this
time dependent parameter is applied.
Resource Consumption (variable)
Define the variable resource consumption in the unit of measure, as
defined below. For further explanation regarding the calculation of the
resource consumption, refer to Resource Consumption Calculation
further above.
Unit of Measure
Define the unit of measure used when specifying the variable resource
consumption.
Bucket Fixed Parameter
Set this indicator so that the defined resource consumption value in this
time dependent parameter is applied.
Resource Consumption (fixed)
Preparing

Define the fixed resource consumption in the unit of measure as defined

below. For further explanation regarding the calculation of the resource
consumption, refer to Resource Consumption Calculation further
above.
Unit of Measure
Define the unit of measure used when specifying the fixed resource
consumption.
Screen:

Header Section:
Type
Overview

Basis
Pushbuttons
Return to Activity

When selecting this button the plan maintenance returns to the activity
level.
Product Plan Assignment
Select this button to define the PPMs of this plan. Not more than one
PPM can be defined per putout product.
Fields
Predecessor Tab
Operation/Activity
Depicts the operation/activity that is carried out prior to the
operation/activity displayed in the header section of the screen.
Successor Tab
Operation/Activity
Depicts the operation/activity that is carried out after the
operation/activity displayed in the header section of the screen.

Preparing

4.2.2.5

469

Transportation Lane

Transportation lanes represent the connection between two locations. They are direction
dependent, which means that two transportation lanes have to be defined if goods movements
should take place in both directions. Several transportation methods can be defined for a single
transportation lane and, if required, on a per product level basis. Transportation lanes are master
data objects that are Supply Chain Model dependent (transportation lanes need to be defined
separately in every supply chain model), but version independent (transportation lanes are the
same for all planning versions). As a consequence of these dependencies, it is required to create
transportation lanes separately for each Supply Chain Model. This can be done either from out of
the Supply Chain Engineer or from the menu tree structure. In both cases the Supply Chain Model
is specified when starting the transaction, thus ensuring that the Supply Chain Model is part of the
key. Irrespective of the chosen path, the maintenance task and graphical user interface of the
transportation lane is identical. It must be noted that transportation lanes are direction dependent,
and in a case where products have to be moved in both directions, it is required to define two
transportation lanes between the two locations in question. A transportation lane can have several
validity periods.
The information contained in the transportation lane can be broken down into the following areas:
1. Procurement Options
The procurement options define (for either specific products or for all products of the
requiring location) where the products can be sourced. Possible sources of supply can be
locations defined in the supply chain model. These procurement options have a similar effect
as the procurement and special procurement keys in an R/3 system. If no transportation lanes
are defined for an externally procured product, the system creates a planned order for
purchasing with no reference to a specific location (vendor). Procurement (not transportation)
costs are defined in the procurement options as well. This allows the definition of
procurement costs per sourcing location that are used by Heuristics planning processes in
SNP and PP/DS, but not by the SNP Optimizer. Several procurement options can be defined
for the same product, but for different validity periods.
2. Transportation Methods
The transportation methods define the various possibilities, how either a specific, or all
products can be moved on the transportation lane. This includes transportation durations and
transportation cost. The transportation and transportation method costs are used by the
optimization routines in SNP and Deployment. Transportation costs are also used within SNP
and PP/DS Heuristics. Several transportation methods can be defined for the same
transportation method, but for different validity periods.
3. Carrier Details
The carrier details are defined as a further refinement of the transportation methods. Per such
transportation method, one or multiple carriers can be defined, representing such carriers that
can provide the transportation service for the specific transportation lane and method. These
carrier details are optional, but required for an accurate vehicle scheduling as part of the
TP/VS functionality.
4. Product Specific Procurement and Transportation Methods
The optional definition of product specific procurement and transportation methods allows
specifying precise resource requirements for the given product and transportation method.
This definition is carrier independent.
5. Procurement and Transportation Overview
The system automatically generates a list that can be displayed in table form. This table
displays all possible transportation methods per product. One line is displayed per
combination

Preparing

470

of product, transportation method, (and carrier?). The number of lines is equivalent to the
number of products multiplied with the number of transportation methods (multiplied with the
number of carriers?).
The product master data must be defined on location level in both the source and target location.
This, as a consequence, requires the appropriate setup of the locations. Both master data objects
must also be assigned to the supply chain model in which the transportation lanes are to be
created.
The Master Data Maintenance Transaction
Path:
Technical Name:

Master Data > Transportation Lanes

/SAPAPO/SCC_TL1

Transportation Lanes can be maintained in a dedicated master data maintenance transaction and
directly in the Supply Chain Engineer. Note that in both cases the transportation lane is model
specific data and cannot be shared by (or allocated to) various supply chain models. While being
in the Supply Chain Engineer, the creation of transportation lanes takes place in a graphical way
where the user connects two locations to setup the transportation lane. When entering the
dedicated master data maintenance transaction, it is required to stipulate the supply chain model
together with the source and target locations. The screen that is displayed consequently is the
same in both cases. The <Save> function is only available, and required, when maintaining the
transportation lane using the dedicated master data maintenance transaction. In order to save
transportation lane changes performed in the Supply Chain Engineer, it is required to save the
model before leaving the Supply Chain Engineer.
The transportation lane maintenance screen is subdivided into 3 horizontal blocks with a column
on the right hand side, opening whenever an entry is created or changed in one of the three blocks.
The third block displays either product - transportation method specific or product transportation method - carrier specific information. All these blocks allow the information that is
contained in the various cells to be edited directly from the overview screen. A fourth block can be
opened which combines the information of block 1, 2, and 3. This block can easily be identified as
a display-only information block.
The user can change the number and sequence of the fields displayed in all blocks as required (use
the appropriate Change Layout button). Other options include sorting, finding, and filtering of
data.
In order to create, change, or display a product specific transportation method, follow one of the
following two possible paths:
Path 1: Create one or multiple transportation methods per product procurement
Ensure the third block displays Product Specific Transportation Method, and not
Carrier. Change to the correct mode, if required, using the Product Specific
Transportation Methods button on top of the screen after selecting a transportation
method.
Select in the Product Procurement block a product line (click on the block left of the
product number) and click on the Product specific Assignment of Transportation
Method button, which is the most right button within this block.
Preparing

Then go down to the Product Specific Transportation Method block and click on the
Creation of a New Entry button. This will open a column on the right hand side of the
screen where all required data is captured.

 As you have predefined the product in the second step, it is now required to select a
transportation method that will be linked to this product. Do this by clicking on the
Selection button on the far right of the Transportation Method section of the column.
Select a transportation method and continue with capturing all data as required. Once all
data is defined, select the Copy and Close button. The Copy button can be used
instead. In this case all newly created data (the new product specific transportation
method) is copied into the third block and it is then possible to immediately define other
transportation methods for the same product.
Path 2: Create one or multiple product procurements per transportation method
Ensure the third block displays Product Specific Transportation Method, and not
Carrier. Change to the correct mode, if required, using the Product Specific
Transportation Methods button on top of the screen.
Select in the Transportation Method block a transportation method line (click on the
block left of the transportation method) and click on the Product specific Assignment of
Transportation Method button, which is the second most right button within this block.
Then go down to the Product Specific Transportation Method block and click on the
Creation of a New Entry button. This will open a column on the right hand side of the
screen where all required data is captured.
As you have predefined the vehicle (transportation method) in the second step, it is now
required to select a product that will be linked to this vehicle (transportation method). Do
this by clicking on the Selection button on the far right of the Product Procurement
section of the column.
Select a product and continue with capturing all data as required. Once all data is
defined, select the Copy and Close button. The Copy button can be used instead. In
this case all newly created data (the new product specific transportation method) is
copied into the third block and it is then possible to immediately define other products
for the same transportation method.
The Header Data button opens a block on the right hand side allowing the definition of some
general data. You must define a transportation planner here in order to run the Transport Load
Builder.
While maintaining the transportation lane outside the Supply Chain Engineer, the entire Supply
Chain Model is locked for other users to maintain. In this case the Supply Chain Model is set to
display only in the Supply Chain Engineer. Also, while maintaining the Supply Chain Model, it is
not possible to change transportation lanes.
The Carrier button switches over the third display block to provide information per
combination of Transportation Method and Carrier. Using the Product Specific Transportation
Method button, the system can be set back to display the product specific transportation method
information.
Deletion

Preparing

472

Transportation Lanes can be easily deleted in the Supply Chain Engineer. In order to delete a
transportation lane in the standalone Transportation Lane maintenance transaction, all definitions
(Procurement, Transportation Method, etc.) within the transportation lane have to be deleted first.
Once the transportation lane is an empty shell, it is automatically deleted when exiting the
maintenance transaction.
Prerequisites for the Creation
In order to maintain a transportation lane some minimum requirements have to be met. The
transportation lane is based on locations and thus these master data objects have to be set up and
assigned to the supply chain model. The minimum requirements are as follows:

Source and target location are defined and are part of the same supply chain model as the
transportation lane
Other optional requirements exist. In order to assign specific products to a transportation lane, the
product master data objects have to be set up and assigned to the supply chain model.
Additionally, some other master data objects might be used. The optional requirements are as
follows:

Product is defined at source and target location and the product is part of the same supply
chain model as the transportation lane

Transportation Calendar to enable precise scheduling

Transportation Resource to control capacity consumption

Carrier is defined as location of type Logistics Service Provider. In this case, the Carrier
must be part of the same supply chain model as the transportation lane
Maintained Fields

Header Data
Activating the Header Data button allows the definition of the following data:
Responsible Planner
The planner ID is used as a selection criteria in the Alert Monitor. This provides a
valuable tool to easily select and display only such alerts that are applicable to a certain
planner. A planner must be defined in order to run the Transport Load Builder.
Description
Allows the definition of a name for the transportation lane

Product Procurement
The Product Procurement block defines possible procurement methods that can be used
between the locations the transportation lane connects. At least one product procurement
definition must exist in order to use the transportation lane. The key for a product
procurement option comprises the three parameters, Product Number (or range), Start Date,
and End Date. The Product Procurement block comprises the following fields:
Product
Selection
o
Product
Allows the definition of one product only. This is a static selection, which defines
precisely one product for use in conjunction with the product procurement. Should a
product be deleted after it has been allocated to a procurement method in the
transportation lane, the procurement method is deleted automatically as well.

Preparing

473

All Products Flag

This option is a flag indicating that all products that are defined in the Supply Chain
Model for which the transportation lane was created can be procured via this
transportation lane. When this flag is set, even such products that are added to the Supply
Chain Model after the creation of the product procurement can be procured using this
product procurement definition. This selection is a dynamic selection that
changes automatically whenever a new product is added to (or deleted from) the Supply
Chain Model.
o Mass Selection Flag
Allows the definition of selected products or product ranges via a selection window. This
selection potentially is also dynamic in situations where product ranges are
defined and products are added to (or deleted from) the Supply Chain Model that fall
within an existing range.
The All Products Flag as well as the Mass Selection Flag must be used with care. If for
example two locations are linked with two (direction dependent) transportation lanes, and the
same product can be transported in both directions and is procured externally, the product
planning cannot find a solution. In this case a perfect loop has been set up, one location
procuring from the other.
Validity
The validity dates, with the valid product number(s), together form the key for the product
procurement block.
o Start Date
Define the start date of the validity period. o
End Date
Define the end date of the validity period.
Several procurement options can be defined for the same product, but for different validity
periods. This allows a time-phased definition. Overlapping validity dates are not permitted.
Parameters
o From Lot Size
As an optional entry, lot size ranges can be defined to further restrict the validity of a
product procurement option. Define the lower limit (if any) here. Defining a lower or
upper limit only can also set a lot size range.
This setting can be used by the SNP Optimizer to define a minimum lot size when
discretizing the lot size range.
o To Lot Size
Optionally, define an upper lot size limit here.
This setting can be used by the SNP Optimizer to define a maximum lot size when
discretizing the lot size range. The SNP Optimizer can also use this definition as a
maximum lot size when using the linear solver.
o Product Procurement Cost
The Product Procurement Cost can be defined manually, or via a cost function (see
below). It is used by the SNP and PP/DS Heuristics planning methods. Should a
requirement for a product occur that could be sourced from several locations, during an
SNP or PP/DS planning task, the system uses the Product Procurement Cost together with
the transportation method dependent transportation cost (not transportation method cost)
to derive the lowest cost transportation method for the location that was selected
according to the procurement priority (see below). This also applies to products planned
automatically. The total cost of procurement used in SNP
o

Preparing

474

and PP/DS Heuristics are made up of the product procurement cost and the transportation
cost.
When creating an order manually, a pop up window displays all relevant information
sorted in the sequence of priority and cost.
o Procurement Priority
The Procurement Priority is used by the SNP and PP/DS Heuristics planning methods. If
during a planning task a requirement for a product occurs that could be sourced internally
and externally (from one or several locations), the system uses the Procurement Priority
to derive the source location. This also applies to products planned automatically in
PP/DS and manually created orders in SNP and PP/DS. The procurement priority defined
in the transportation lane is compared with the procurement priority of the PPM to decide
between internal and external procurement. If no procurement priorities are defined for
the transportation lane and the PPM (or the priorities are the same), then the system
selects the cheapest of all available possibilities. To do so the various total cost (see
above) and the PPM cost are compared.
When creating an order manually, a pop up window displays all relevant information
sorted in the sequence of priority and cost.
o Distribution Priority
The Distribution Priority is used by the Deployment Fair Share rule D, which
distributes the available stock at the source location according to the priority of the
outgoing transportation lane.
o Cost Function
The Product Procurement Cost can be defined individually (also referred to as manual,
see above) or via a cost function. The supported functionality remains the
same.
o Lock Indicator
Setting this indicator locks (disables) the usage of this product procurement option. This
comes in handy, if a certain combination should be locked for the moment, but might be
used again in the future. This indicator is used by SNP, Deployment, and PP/DS.
Form of Procurement
The Form of Procurement further refines the type of external procurement of the product. The
settings here can be compared to the R/3 systems Special Procurement indicator.
o Standard
Select this option for standard ordering methods, where products are ordered from the
supplier and received into stock physically and financially upon arrival.
o Subcontracting
With a subcontracting procurement procedure, goods are ordered from a vendor, which in
turn manufactures them based on this order, using one or several
components from the ordering company. In this case, two goods movements take place,
one for the provided components to the vendor, and one for the finished products from
the vendor.
o Consignment
Select this option for consignment stock ordering methods, where products are ordered
from the supplier and received into stock physically upon arrival. Goods are paid only on
consumption and remain in the ownership of the vendor up to the point of consumption.
External Procurement Relationship

Preparing

475

For external procurement relationships it is possible to link the transportation lane to

documents such as vendor contracts stored on the R/3 system. The documents described
here can only be maintained in the linked R/3 system and are brought across via the core
interface. They are master data objects that can be used in APO, but not changed. The
fields in this section of the product procurement block are for this reason only available
when maintaining the active model.
o Source Type
The source type stipulates the type of contract with the vendor. Contractual
information is held on the R/3 system (if linked), and used by the APO quota
arrangement. Possible source types are scheduling agreements (call-off contracts,
type 1), general value or quantity based contracts (type 2), or info records
(purchasing
conditions, type 3).
o Purchasing Document Number
The Purchasing Document Number links the product procurement information to a
document kept on the R/3 system.
o Purchasing Document Item
The Purchasing Document Item is a line of the above-mentioned purchasing
document.
o Purchasing Organization
A Purchasing Organization is an entity in the R/3 organizational structure and part of
a purchasing document.
o Planned Delivery Time
Stipulates the planned delivery time agreed upon with the vendor when using the
described source (procurement) type.

Transportation Method
The Transportation Method block defines the various methods of transportation that exist
between the locations, the transportation lane connects. At least one transportation method
must be defined in order to use the transportation lane. The key for a transportation method
option comprises the three parameters Transportation Method, Start Date, and End Date. The
Transportation Method block comprises the following fields:
Validity
o Transportation Method
Select a transportation method from a range that can be maintained (see next field
described below).
o Parameters button
Activating this button allows jumping into the transportation method maintenance
window where all existing transportation methods can be maintained. See the
explanations for Maintaining the Transportation Method further down.
o Start Date
Define the start date of the validity period.
o End Date
Define the end date of the validity period.
Several transportation method intervals can be defined for the same transportation
method, but for different validity periods. This allows a time-phased definition.
Overlapping validity dates are not permitted.
Control Flags
o Valid for all Products

Preparing

476

Set this product to ensure that all products that are defined under the procurement
section can be transported using this method. An optionally defined product specific
procurement method overrides the settings in this (general) transportation method
definition. If this flag is not set, only such products can be transported for which
product specific transportation methods have been defined.
o
Aggregated Planning
Set this flag to make this transportation method available in SNP and ND.
o
Detailed Planning
Set this flag to make this transportation method available in TP/VS and PP/DS.
o
Fix Transportation Duration
The system can calculate the distance between the source and the target location
based on the locations geographical coordinates. The transportation duration is then
calculated based on the calculated distance and the average speed defined for the
transportation method.
Switch this flag on to disable this automatic calculation.
o Fix Transportation Distance
The system can calculate the distance between the source and the target location based
on the locations geographical coordinates (see above).
Switch this flag on to disable this automatic calculation.
o Discretize Transportation Method
Cost values in the transportation lane are defined as linear functions (e.g. cost per km).
The SNP Optimizer can use linear costs as long as it is run in the linear mode. In the
Discretization mode one or multiple linear functions can be broken down into a number
of single discrete values. If this should be carried out for transportation lane related data,
a flag needs to be set in the optimizer profile, and in the corresponding transportation
lane this flag needs to be set.
Parameters
o Transportation Calendar
The transportation calendar is a time stream that defines the possible times where the
transport using this transportation lane can take place. The entry is optional, and if no
transportation calendar is defined, the system schedules based on 7 day 24 hour
availability.
The Transportation Calendar is used by SNP and Deployment, but not by TP/VS.
Scheduling in TP/VS uses the available times as defined in the vehicle resource,
instead of the Transportation Calendar.
o Transportation Duration
This duration defines the time that is required between shipment and receipt, and is
defined in the notation hh:mm. When the Optimizer schedules transportation orders,
their expected receipt time is defined precisely down to the minute. The SNP Optimizer
then applies the Rounding Transportation Time factor (see below) to check whether the
expected receipt should be planned for the beginning or the end of the time bucket in
which the receipt falls.
The duration defined here is used by SNP, Deployment, and TP/VS optimization
routines.
o Button Generate Proposal
The system calculates the transportation distance and transportation duration based on
the following formula:
Transportation Duration = Transportation Distance / Average Speed

Preparing

477

The transportation distance is based on the geographical coordinates defined in the location
master records. The average speed is taken from the transportation method parameters. If no
average speed is maintained for the transportation method, then the transportation distance is
still calculated, but no transportation duration. The use of this function is optional.
Additional Retention Period
The Additional Retention Period (Time Lag) is used to identify any times that are required on
top of the pure goods movement times between locations. The entry is optional. It can be used
to identify for example loading and unloading times.
Transportation Distance (with UoM as defined in Settings)

The transportation distance is defined using a uniform unit of measure that is used for all
transportation lanes. The unit of measure can be defined using the path Settings Units and
is always valid for all transportation lanes.
o

Transportation Cost

Although positioned directly after the trip distance, this field does not stipulate the cost per
distance, but rather a product quantity dependent transportation (not procurement) cost. It is
required that the unit of measure used here can be related to the products base unit of
measure, or to one of the alternate units defined in the product master. If for example the unit
used in the Transportation Cost field is tons, the product master must stipulate what the
weight of the product is (in tons, kilograms, pounds, etc.).
o

UoM

Defines the unit of measure the transportation cost relates to (see above). o
Cost Function
Used to calculate the transportation cost instead of the above two fields, Transportation Cost
and Unit of Measure. The Cost Function used here is of type T and permits the definition of
product quantity dependent cost (this is the equivalent of the transportation cost described
above)
o Resource
If a resource is defined, products that are moved using this transportation method must have
the same dimension (type) of capacity definition as the resource. If for example the resource
has a volume capacity of 100 m 3, then the product master must stipulate the volume of the
product in m3, or any other volume related measurement (e.g. liter or cubic feet). Additionally,
the product must have either an alternate unit of measure that relates it to the base unit of
measure of the planning area, or the base unit of the product must be the same as that of the
planning area.
The transportation resource linked to a transportation lane is shown in the Product
Planning View transaction for all transportation orders.
o Transportation Method Cost
The Transportation Method Cost defines the cost per distance unit as described above
in the field Trip Distance.
o UoM (Display-only Field)
Situated directly behind the Transportation Method Cost is the unit of measure used for
measuring the distance. This is a display only field taken off the Unit Settings. Trip distances
are defined using a uniform unit of measure that is used for all transportation lanes. The unit
of measure can be defined using the path Settings
Units and is always valid for all transportation lanes. o
TLB Profile

Preparing

478

The optional entry of a TLB profile allows the definition of minimum and maximum
volumes, weights, and pallet numbers that can fit into a single transport medium (e.g.
a truck) that is used on this transportation lane. A TLB profile does not stipulate the
overall capacity. This is done using the resource field. The TLB profile is used
during TLB planning.
o Rounding Transportation Time
The rounding transportation time is used when calculating the receipt time of a
transportation order. Assuming a working time from 08.00 to 16.00 (8 hours), and a
rounding transportation time of 0.25, all planned receipts between 08.00 and 10.00
(25% of 8 hours) are deemed to be available at the beginning of the bucket. All other
planned receipts between 10.00 and 16.00 are deemed to be available at the end of
the bucket, which is also the start of the next bucket.
The rounding transportation time is the equivalent to the bucket offset, which is
defined in the PPM. It is used by the SNP Heuristics and Optimization.
Short Text of Transportation Assignment Method
o Description
Allows the definition of a name for the combination of transportation lane and
transportation method.

Product Specific Transportation Method

The Product Specific Transportation Method block displays information that is based on the
combination of a specific product procurement option and transportation method. The display
on this block can be switched over to the Carrier block by pressing the Carrier button.
The definition of product specific transportation methods is optional. The key of the Product
Specific Transportation Method is the selected product procurement and transportation
method together with the time based validity. Note that product specific transportation
methods are not used by TP/VS. When this block is switched to Product Specific
Transportation Method the following fields are displayed:
Product Procurement
o Product
Displays the selected product of the product procurement
o Start Date
The Start Date displayed here is a copy of the Product Procurement Start Date. It
cannot be changed.
o End Date
The End Date displayed here is a copy of the Product Procurement End Date. It
cannot be changed.
Transportation Method
o Transportation Method
Displays the selected transportation method
o Start Date
The Start Date displayed here is a copy of the Transportation Method Start Date. It
cannot be changed.
o End Date
The End Date displayed here is a copy of the Transportation Method End Date. It
cannot be changed.
Validity

Preparing

479

Several product specific transportation method intervals can be defined for the same product
specific transportation method, but for different validity periods. This allows a time-phased
definition. Overlapping validity dates are not permitted.
o Start Date
The Product Specific Transportation Method Start Date is a calculated field that cannot
be changed. It is equal to the later Start Date of the two Start Dates from the
Product Procurement and Transportation Method.
o End Date
The Product Specific Transportation Method End Date is a calculated field that
cannot be changed. It is equal to the earlier End Date of the two End Dates from the
Product Procurement and Transportation Method.
o Prohibition
Setting this indicator prohibits (disables) the usage of this product specific transportation
method option. This comes in handy, if a certain combination should be disabled for the
moment, but might be used again in the future.
Parameters
o Transportation Cost
This field stipulates the distance independent transportation cost. Unlike the
transportation cost defined in the Transportation Method block, which is product
independent (see further above), the cost defined here always relates to the products base
unit of measure (see below). Note that product specific transportation methods are not
used by TP/VS, and thus TP/VS uses the transportation cost defined on the higher
transportation method (product independent) level only.
o UoM (Display-only Field)
Situated directly behind the Transportation Cost is the products base unit of measure.
This is a display only field taken off the product master.
o Consumption
The Consumption field, together with the Unit of Measure (see below), defines how
much of the resources capacity is consumed per base unit of measure of the product,
whenever the product is transported on this transportation lane and method. This allows a
finer degree of capacity consumption calculation compared to that on
transportation method level.
o UoM
This is the Unit of Measure used to describe the resource consumption.
o Lot Size Profile
The lots size profile allows the definition of minimum and maximum order quantities, as
well as rounding values that are used when creating an order, utilizing a specific
transportation lane. The Lot Size Profile can also point to a Rounding Profile. These
rounding profiles are the same as the ones attached to a product in the product master (lot
size tab). The definition in the product specific transportation method is only used
when creating transportation orders.
o Stacking Factor
In the TLB profile, the minimum/maximum number of pallet positions, not of pallets, that
fit into one transportation medium (e.g. truck) is defined. The minimum/maximum
number of pallet positions multiplied with the stacking factor result in the permitted
minimum/maximum number of pallets. The stacking factor can be defined in the product
master (attributes tab), or in the product specific transportation method. The definition in
the product specific transportation method overrides the product master definition.
Leaving this field blank is interpreted as 1,

Preparing

480

which means the number of pallet positions is equal to the number of pallets. The
stacking factor is used by TLB.

Carrier (part of future scope)

The Carrier block displays information that is based on the combination of a specific
product procurement option and carrier. The display on this block can be switched over to the
Product Specific Transportation Method block by pressing the Product Specific
Transportation Method button. The definition of carriers is optional. When this block is
switched to Carrier, the following fields are displayed:
Section 1
o Carrier (this is a location of type Logistics Service Provider)
Validity
o Start Date
o End Date
o Vehicle (Transportation Method)
Parameters
o Transportation Cost
o UoM
o Cost of Carrier
o Per Display only, as defined in the Settings
o Priority
o Share of Business

Total Procurement and Transport of Products

This list display is activated by selecting the Entire Procurement / Transport button. It
provides an overview of all possible combinations of product procurements, and
transportation methods that are defined for the transportation lane. The rows are color-coded
indicating the origin of the information.
Green shaded block
This is the key for the product procurement section of the transportation lane. For the
same product, multiple validity periods are permitted.
Blue shaded block
In this block the product procurement data for the key as specified in the green block is
displayed.
White shaded block
All permitted transportation methods per product procurement option are listed here. If
no restrictions apply (see field Valid for all Products), the number of lines here is the
number of product procurement options multiplied by the number of transportation
methods.
Lilac shaded block
If product specific transportation methods are defined for the combination of product
procurement and transportation method, the relevant data is shown here.

Other Functions

Checking the Transportation Lane Consistency

Preparing

481

This option provides an easy way to perform a transportation lane consistency check. Part of
this check is for example whether products that are used in the product procurement option
are defined in both the source and target location.

Setting for Units of Measure

From any screen select Settings Units, which can be found on the transportation lane
menu bar. From there the following two settings can be performed:
UoM for Distance
The distance setting is used in the transportation lane based product specific
transportation method definition and is the same for all transportation lanes.
UoM for Speed Limit
The speed limit setting is used in the general transportation method definition and is the
same for all transportation lanes.

Maintaining the Transportation Method

The transportation methods profile can be maintained directly out of the transportation lane
maintenance transaction. This can be done using two different paths.
Path 1:
While defining a possible transportation method for the transportation lane, a
parameter button is displayed next to the transportation method field. No specific
transportation method needs to be selected before invoking this function, as it always
displays all possible Transportation Methods.
Path 2:
From any screen select Go to Transportation Method, which can be found on the
transportation lane menu bar.
Activating this function in either way allows jumping into the transportation method
maintenance window where all existing transportation methods can be maintained. The
Transportation Method Maintenance of existing transportation methods can be carried out
while maintaining the transportation lanes and in the Supply Chain Engineer. The
maintenance and creation of transportation methods can only be carried out in the IMG (path:
Advanced Planner and Optimizer (APO) > Supply Chain Engineer (SCE) > Maintain
Transport method).

4.2.2.6

Transportation Lane Mass Maintenance

The transportation lane is a rather complex master data object that requires a lot of definitions to
be carried out. At the same time there is usually a high number of transportation lanes that need to
be maintained. In most cases a high number of transportation lanes have identical definitions,
leaning themselves to be maintained via mass maintenance functions.
APO offers the creation as well as the change and deletion of transportation lanes as a mass
maintenance function. In both cases a template transportation lane is used and all its parameters
are used to create (or update) new (or existing) transportation lanes.
The user guidance is not very good. There is no test run option or any feedback which
transportation lanes were created. Once the generation is started it can be stopped before the final
saving of data is committed but there is no way to see what is going to be saved.

Preparing

482

The Master Data Maintenance Transaction

Path:
Technical Name:

Master Data > Mass Creation of Transportation Lanes

/SAPAPO/TR_TLANE_MAINT

The transportation lane mass maintenance screen is subdivided into 5 blocks. Various selection
criteria permit the restriction of transportation lanes to be created.
Deletion
Refer to the explanations for the transportation lane.
Prerequisites for the Creation
Refer to the explanations for the transportation lane.
Maintained Fields
Selection Screen
Selection Parameters
Supply Chain Model
o Model Name
Define the supply chain model from which the template transportation lane is read
and in which the new transportation lanes have to be created.
Copy From
The transportation lane that is identified here is used as a template for the creation (or
update) of all transportation lanes as restricted by the upcoming parameters.
o Source Location
Define the source location of the template transportation lane.
o Target Location
Define the target location of the template transportation lane.
Creation of Transportation Lanes between Locations
o Source Location Range
Restrict the locations from which the transportation lane starts explicitly by location
number(s).
o Target Location Range
Restrict the locations to where the transportation lane ends explicitly by location
number(s).
Further Selection Criteria
The stipulation of a source (target) location type range enables the creation of only such
transportation lanes that start (finish) at a location of the specified location type.
o Source Location Type Range
o Target Location Type Range

Preparing

483

Specifying a minimum (maximum) distance ensures that only such transportation lanes
are created that link locations that are further away from (closer to) each other than the
specified distance. The distance is derived from the geographical coordinates of the
location.
o Minimum Distance
o Maximum Distance
Update Parameters
Existing Transportation Lanes
If the system detects that according to the specified selection criteria a transportation lane
already exists, it can either skip this transportation lane (and leave as is) or replace it with
a new transportation lane.
o Existing Transportation Lanes are not overwritten
o Existing Transportation Lanes are overwritten
Transport Durations and Distances
Durations and distances can either be calculated by the system or taken over from the
template transportation lane. The way the system calculates the transportation distance
and transportation duration is explained in the section transportation lane maintenance.
o Calculate Transport Durations and Distances
o Adopt Transport Duration and Distance from Template

Other Functions
A more advanced master data mass maintenance is available with release 3.1.

4.2.2.7

Quota Arrangement

Quota Arrangements define how a given requirement is split over various sources (inbound) or
how a given supply is distributed over various locations (outbound). Quota arrangements are
always linked to at least one location and can be grouped according to their direction validity,
namely inbound and outbound quota arrangements. Quota arrangements are also referred to as
quotations at various places. This appears to be a bad and misleading translation, as they
definitely do not refer to anything like a vendors quotation.
Inbound quota arrangements only need to be defined if more than one source of supply exists and
a split according to certain rules has to take place. Only the SNP heuristic run uses the quota
arrangement as a mandatory rule and adheres to it. The SNP optimizer can calculate them based
on the cost optimum solution. Quota arrangements determine the quantity flow between known
locations within a supply chain model. This implies that the locations in question are defined in
the supply chain model and that a transportation lane exists between the locations defined in the
quota arrangement. Consequently, when creating a quota arrangement, only such locations can be
selected that are linked to the location for which the quota arrangement is being created by means
of a transportation lane.
The creation of quota arrangements is an optional step. If more than one source of supply exists
for a given requirement, the SNP Heuristics will pick the lowest cost location if no quota
arrangement

Preparing

484

is defined. In cases where only one source of supply exists, the creation of a quota arrangement is
not required. All demand will then be placed on this source of supply. While using the SNP
Optimizer, the quota arrangement definitions can be generated. The SNP Optimizer generated
quota arrangements are always planning version specific. They are saved in the same planning
version as the planning version the Optimizer ran in.
As explained above, the quota arrangement is closely linked to the existence of a transportation
lane. Unlike the transportation lane, the quota arrangement can be defined as both planning
version independent and planning version dependent. The latter is the only option when using the
SNP Optimizer to create quota arrangements.
Inbound Quota Arrangements
The inbound quota arrangement, defined as direction type 1, determines how a given demand is
satisfied. The possible options are listed below.

In-house Procurement (Production)

The requirement is satisfied by means of production in the location where the demand arises.
This can be accomplished at any location of type production plant. In this case a production
process model (PPM) and production resources as required need to be set up.

External Procurement from Partner Location

In this case the requirement is satisfied by other locations, so called partner locations. Partner
locations can be other production plants, distribution centers, or suppliers. Partner locations
are defined in the supply chain model. These locations can in turn manufacture the product in
demand or procure it externally as well (cascaded external procurement). Partner locations
can also be subcontracting partners. A transportation lane must exist for the required product
between the requesting and supplying location.

External Procurement from External Source

This option allows the usage of vendor contracts (call-off contracts, general value or quantity
based contracts, or info records) that are defined in an attached OLTP system. APO can then
use the conditions stipulated in the respective contract.
Requirements can also be split, distributed, using not only various locations, but also various
methods of supply. This enables procurement options such as dual sourcing and mixed
procurement. Any given demand can be split over one or multiple partner locations, and/or one or
multiple external sources, and manufactured in-house, all at the same time.
Requirements can be split in two different ways:
Per Demand
In this mode each demand is split over the sources of supply as defined in the quota
arrangement. Assuming a demand for 100 exists and two sources of supply with equal share
are defined, the system will create a demand for 50 at each of the sources. As said before,
these sources could be for example in-house production for a quantity of 50 and external
purchase order for another quantity of 50. The key is that every demand is split accordingly.
A lower limit can be set so that requirements are not split if the resulting individual quantities
would be too low.

Over Time
Using the quota arrangement in this mode ensures that no demand is broken down into
smaller quantities, but the system rather maintains the quotas as defined in the quota
arrangement over time. Based on the above example, the system would allocate, for example,
the whole quantity

Preparing

485

of 100 to in-house production. The next demand of another 100 (or more) would then be
allocated to the external vendor. The system tracks the allocated quotas, thus ensuring a
distribution as requested.
Inbound quota arrangements can usually be found at all types of demanding locations (e.g.
manufacturing plants for components or distribution centers for finished products). The definition
of a base value allows that new locations can be easily added to existing quota arrangements that
are already in use.
Outbound Quota Arrangements
The outbound quota arrangement, defined as direction type 2, determines how a given supply is
distributed. Effectively, this is only used in the case of pushing products in the supply chain, for
example, from a manufacturing plant to the distribution centers. By nature, the outbound quota
arrangement can only define how a given supply is distributed within the supply chain model
(network) to the known partner locations. Thus no options, as is the case with the inbound quota
arrangements, exist. Outbound quota arrangements can usually only be found at supplying
locations (e.g. manufacturing plants), although this is not a technical system constraint.
The Master Data Maintenance Transaction
Path:
Technical Name:

Master Data > Quota Arrangements

/SAPAPO/SCC_TQ1

Quota arrangements can be maintained in a dedicated master data maintenance transaction and
directly in the Supply Chain Engineer. Note that in both cases the quota arrangements is model
specific data and cannot be shared by (or allocated to) various supply chain models. Whilst in the
Supply Chain Engineer the creation of quota arrangements takes place by activating the context
sensitive menu on a location in the location tab. When entering the dedicated master data
maintenance transaction, it is required to stipulate the supply chain model together with the
location and the quota arrangement direction (inbound or outbound). The stipulation of a planning
version is optional. The screen that is displayed consequently is the same in both cases. The
<Save> function is only available, and required, when maintaining the quota arrangement using
the dedicated master data maintenance transaction. In order to save quota arrangement changes
performed in the Supply Chain Engineer it is required to save the model before leaving the Supply
Chain Engineer.
The screen is initially subdivided into 2 horizontal blocks with a column on the right hand side
opening whenever a quota arrangement is created. The top lock displays the selected supply chain
model, location, quota arrangement direction, and planning version. The planning version name
Default depicts that no specific planning version is used. The second block displays the quota
arrangement(s) per product or product selection. Selecting any of the quota arrangements in this
block and selecting the Display Quota Arrangements Position opens the third block displaying
the quota arrangement items for the selected quota arrangement. A new column on the right hand
side is opened whenever an entry is created or changed in one of the two blocks quota
arrangement or quota arrangement item. All these blocks allow the information that is contained in
the various cells to be edited directly from the overview screen. However, the data captured this
way is not saved at all. Pressing the <Total Quota Arrangements> button opens a third block titled
Total Quota Arrangements. This closes the quota arrangement items block and displays all valid
quota arrangements as per selection (supply chain model, location, direction, and planning
version).

Preparing

486

The user can change the number and sequence of the fields displayed in all blocks as required (use
the appropriate Change Layout button). Other options include sorting, finding, and filtering of
data.
While maintaining the quota arrangement outside the Supply Chain Engineer the entire Supply
Chain Model is locked for other users to maintain. In this case the Supply Chain Model is set to
display only in the Supply Chain Engineer. Also, while maintaining the Supply Chain Model, it is
not possible to change quota arrangements.
Deletion
Quota arrangements and quota arrangement items can be deleted in the Supply Chain Engineer
and in the standalone quota arrangement transaction. In order to delete a quota arrangement
including all quota arrangement items simply use the <Delete> button. Quota arrangement items
can also be deleted individually.
Prerequisites for the Creation
In order to maintain a quota arrangement some minimum requirements have to be met. The quota
arrangement is based primarily on locations, products, and transportation lanes and thus these
master data objects have to be set up and assigned to the supply chain model. The minimum
requirements are as follows:

Source and target location are defined

Transportation lanes exist from supplying to demanding locations for a demand in the
demanding location and an inbound quota arrangement

Transportation lanes exist from supplying to demanding locations for a supply in the
supplying location and an outbound quota arrangement

Source and target location as well as the transportation lane are part of the same supply chain
model as the quota arrangement
Other optional requirements exist. Quota arrangements can be set up for all products or for
specific products. In the first case no product master records need to exist during the quota
arrangement creation. The optional requirements are as follows:

Product is defined at source and target location and is part of the same supply chain model as
the quota arrangement
Maintained Fields

Quota Arrangements
The quota arrangement block defines for the quota arrangement the validity in terms of
covered products and dates as well as some control parameters.
Product
Selection
o
Product
Allows the definition of one product only. This is a static selection, which defines
precisely one product for use in conjunction with the quota arrangement.
o All Products Flag

Preparing

487

This option is a flag indicating that all products that are defined in the Supply Chain
Model and which are created in the respective location are controlled by this quota
arrangement. When this flag is set, even such products that are added to the location
and Supply Chain Model after the creation of the quota arrangement are governed by
the quota arrangement. This selection is a dynamic selection that changes
automatically whenever a new product is added to (or deleted from) the Supply
Chain Model.
o Mass Selection Flag
Allows the definition of selected products or product ranges via a selection window.
This selection potentially is also dynamic in situations where product ranges are
defined and products are added to (or deleted from) the Supply Chain Model that fall
within an existing range.
Validity
The validity dates form together with the valid product number(s) the key for the quota
arrangement block.
o Start Date
Define the start date of the validity period.
o End Date
Define the end date of the validity period.
Parameters
o Allow Requirement Splitting
This flag needs to be set if individual orders should be split according to the defined
quotas. This enables the Per Demand split. If this flag is not set, the Over Time
split method is applied.
o Requirements Grouping
The Requirements Grouping allows combining various requirements (e.g. sales
orders) over a period of time before they are split according to the quota
arrangement. This reduces the number of orders that are placed on the source
location. Possible
accumulators are day, week, and month.
o Minimum Quantity Requirement Split
In order to avoid to small requirements quantities after a potential split of a
requirement in accordance to a quota arrangement, it is possible to define a minimum
quantity per individual requirement. If for example the requirement is for 100 pieces
and two sources of supply are identified with a quota of 50% each, the system would
create two demands with 50 pieces each. Setting the Minimum Quantity
Requirement Split to 60 pieces would leave the requirement in one block of 100
pieces placed only on one of the locations.
o UoM
This is the unit of measure used for the Minimum Quantity Requirement Split. The
unit of measure used here must be defined in the product master record(s) as the base
or an alternate unit of measure.

Quota Arrangement Items

The quota arrangement items block defines the respective quotas within the quota
arrangement that are applied per procurement option. The quota arrangement can distribute
requirements over one or multiple locations, PPM, and/or external procurement relationships
(vendor contracts, scheduling agreements, or info records). The type location (LOK) is the
only one available for outbound quota arrangements. For inbound quota arrangements this
type is

Preparing

488

possible and additionally the types external procurement (FB) and in house production (EF).
Quota Arrangement for Location o
Location
Determines the location from which the requirements are to be satisfied (inbound quota
arrangement) or to which supply is distributed (outbound quota arrangement).
Quota Arrangement for External Procurement Relationship
This option is only applicable to inbound quota arrangements. For external procurement
relationships it is possible to link the quota arrangement to documents such as vendor
contracts stored on the R/3 system. The documents described here can only be maintained in
the linked R/3 system and are brought across via the core interface. They are master data
objects that can be used in APO but not changed. The fields in this section of the product
procurement block are, for this reason, only available when maintaining the active model.
o Location
Determines the vendor location from which the requirements are to be satisfied. o
Start Date
Define the validity start date of the vendor relation (see source type). o
End Date
Define the validity end date of the vendor relation (see source type). o
Source Type
The source type stipulates the type of contract with the vendor. Contractual information is
held on the R/3 system (if linked) and used by the APO quota arrangement. Possible
source types are scheduling agreements (call-off contracts, type 1), general value or
quantity based contracts (type 2), or info records (purchasing conditions, type 3).
o Purchasing Document Number
The Purchasing Document Number links the quota arrangement to a document kept on
the R/3 system.
o Purchasing Document Item
The Purchasing Document Item is a line of the above-mentioned purchasing document.
o Purchasing Organization
A Purchasing Organization is an entity in the R/3 organizational structure and part of a
purchasing document.
Quota Arrangement for In-house Production
This option is only applicable to inbound quota arrangements. o
Name of Source of Supply
The Source of Supply is a PPM. Note that a requirement could be split over more than
one PPM. This, for example, would ensure that a product is manufactured using several
resources and/or manufacturing processes.
Parameters
This data block is displayed for inbound and outbound quota arrangements. o
Quota Arrangement
The field Quota Arrangement contains the actual quota allocated to the source of supply.
It is not defined as a percentage but rather as a relative number. Having two sources of
supply and giving setting a value of 50 each provides the same result as setting both
values to e.g. 300. Adding a new (taking away an existing) source of

Preparing

489

supply with its own value obviously reduces (increases) the relative portion of the
other already existing (remaining) sources of supply.
o Heuristic
Used by PP/DS only when carrying out a planning run (also applies to automatic
planning).
o Quota Base
When creating a new source of supply a Quota Base can be defined to ensure that the
new source of supply does not take away all requirements initially and up to the
moment where the new source of supply has the same Allocated Quantity (see
below) as the other sources of supply.
Block with no name
This data block is only displayed when entering the transaction in Change or Display
mode and not during the creation of quota arrangement item.
o Allocated Quantity
The Allocated Quantity depicts the total quantity that has been allocated to the
source of supply since the creation of the quota arrangement. This can be used for
follow-up purposes and when adding new sources of supply (see Quota Base
above).
o UoM
This is the base unit of measure of the product.
Other Functions
Activating the Total Quota Arrangements button displays an overview of all quota arrangements
for the selected location and direction (inbound or outbound) irrespective of the planning version.
The term Default Version represents quota arrangements that are not specific to any planning
version (planning version independent). The Total Quota Arrangements block is displayed in place
of the Quota Arrangements Items block.

4.2.2.8

Hierarchy

The term hierarchy in APO refers to a technical structure that contains master data objects.
Hierarchies can be defined for locations, products, location products, resources, and for the PPM.
They are used in some Supply Network Planning activities such as the vertical aggregated
optimization. SNP Heuristics and Optimization can be restricted to only use location products that
are of a specific level ID or lower when being started in background. Before a hierarchy can be
defined it is required to define the hierarchy structure. Furthermore, the hierarchy as such must be
defined in customizing. Once a hierarchy has been created based on a hierarchy structure, it can be
maintained as part of the master data maintenance activities as described here.
Hierarchies must also be assigned to the supply chain model. Generated hierarchies can only be
viewed but not maintained, as they are based on other individually maintained hierarchies.
Generated Hierarchies (hierarchy type 01) are based on at least two other hierarchies of type 01
(Hierarchy) or 03 (Character Procedure Hierarchy).
Preparing

The Master Data Maintenance Transaction

Path:
Technical Name:

The Initial Screen

On the initial screen, define an existing hierarchy to be maintained. The system automatically
displays the selected hierarchys hierarchy structure, the object type (e.g. Location Product) and
the hierarchy structure type (e.g. Generated Hierarchy). Changing these values is possible but
does not have impact. Use the <Display> or <Change> pushbuttons to reach the next screen, or
use the <Delete> pushbutton to delete the hierarchy.
The Main Screen
Once on the main screen, the maintenance of the selected hierarchy can start. Choose any of the
following functions or pushbuttons.
Pushbuttons
Display
Switch over to Display mode
Change
Switch over to Change mode
Adjust Columns
Changes the column width so that all texts can be properly read.
Find
Opens a pop-up window, which enables the search for specific objects in
the hierarchy.
Copy
Copies the entire hierarchy with all its objects.
Delete
Deletes the entire hierarchy with all its objects (not the master data as
such).
Update
Refreshes the screen
Models

Preparing

491

Assigns (removes) a hierarchy to (from) supply chain models.

Perform the following activities to maintain the hierarchy:
Context sensitive menu on folder level
Switch over from Display to Change mode and vice versa
Open Object Search window to search for specific objects with the hierarchy
Save the current hierarchy (Change mode only)

Context sensitive menu on hierarchy level

Add (attach) new objects to the hierarchy (Change mode only)
Delete all objects from the hierarchy (Change mode only)

Context sensitive menu on object level(s)

Display the master data object (this option switches over to the master data maintenance
transaction)
Change the master data object (this option switches over to the master data maintenance
transaction)
Attach a new Object to the Hierarchy using a selection window (Change mode only, not
available on lowest level). This is only possible if the function is activated on a level that is
not the lowest defined hierarchy level.
Delete selected Object from the Hierarchy (Change mode only). This will delete the
selected object and all objects below the current level.
Delete Objects below the selected Hierarchy level (Change mode only, not available on
lowest level). This will delete all objects below the current level.

4.2.3

Cost Data Maintenance

The word cost can be found in connection with a lot of fields and functions in the APO system.
The problem is that it is not always clear by which planning algorithm a certain cost definition is
used. Cost fields are used most often by optimization routines, but some of them are also used by a
Heuristic and some of them are solely used by a Heuristic. Specifically for the maintenance of costs
that are used by the SNP Optimizer, a special Table Based Cost Maintenance transaction can be used
to maintain all required cost data. A similar function exists for the VS Optimizer.
The table below provides an overview of cost data defined in the various master data objects and
where they are used. For further explanation regarding the listed fields, refer to the respective
master data objects or to the sections dealing with optimization cost parameters maintenance. The
column tab relates to the table based SNP cost maintenance transaction.

Master Data Object

Tab

Product
Preparing

Master Data Object

Tab

7
T/L
Product Procurement
Preparing

Master Data Object

Tab

No
No
T/L
Transportation Method
3
3

No
T/L Product Specific
Transportation Method
4
Resource
8 and 9
Plan
2
2
No
No
Table 81 Cost Related APO Data in SNP and PP/DS

Preparing

494

Index to Cost Type

FC
Fixed Cost
VC
Variable Cost
F (F)
Cost Function of Type F (External Procurement)
F (P)
Cost Function of Type P (Production)
F (T)
Cost Function of Type T (Transportation)

Continuous optimization uses the variable costs to define a linear relation between cost and
quantity. The minimum cost and quantity when using the variable cost is always Zero but
maximum transportation (T/L) and production (PPM) lot sizes are permitted. The cost functions
can also be used for continuous optimization but in cases where step linear cost functions are
modeled, the cost of the first step (interval) is applied to all steps.
Up to now, we have gone over various master data objects, and the majority had some fields that
were dealing with some cost (or penalty) settings. All these cost settings must be maintained
accurately if the optimizers are to produce a meaningful result. This can be a rather laborious task
with lots of master data object accesses depending on the type of cost that has to be defined. The
Cost Maintenance transactions greatly help reducing the amount of thinking regarding where
which cost definition is stored. This central cost-related maintenance program that updates the
respective master data objects. It is sorted by cost type (e.g. production cost) rather than master
data object (e.g. product master). This is a really sensitive approach and makes the cost definition
task easier. As said above, this transaction does not maintain a new master data object. It merely
updates already existing master data objects. It is for example required to define the capacity
(supply) variants of a resource in order to maintain its cost with this transaction.

4.2.3.1

SNP Cost Maintenance (Directory)

The SNP Cost Maintenance (Directory) transaction is one of two tools that simplify the
maintenance of all SNP related cost parameters that are stored in various master data objects.
Using this transaction, cost parameters can be changed in the respective master data objects. This
change is not carried out immediately when changing the data, but rather when leaving the
transaction.
Another transaction, called SNP Cost Maintenance (Table), provides similar functionality while
using a different user interface.
Note:

The Deployment optimizer shares the cost definitions with the SNP optimizer. Both
optimizers use these cost definitions.

The Cost Maintenance Transaction

Path:

Master Data > Supply Network Planning Master Data > Maintain
Costs (Directory)

Technical Name:

/SAPAPO/SNP113

The user interface of the rounding profile maintenance transaction is in the form of an interactive
table with tree structures on various tabs. It is required to drill down to the object that contains the

Preparing

495

cost data. In some cases cost data is also available on a higher than the lowest level. While this
transaction is in update mode various corresponding master data objects are blocked and vice
versa.
Deletion
Cost definitions can be set to the value Zero. Since this transaction only updates already existing
master data objects, it cannot delete any such objects.
Prerequisites for the Creation
Note that the SNP cost maintenance (directory) transaction can only be used on master data
objects that are existing already and are maintained on the right level. Cost data on location
product level for example can only be maintained once the product has been created for the
location.
Maintained Fields
All data entered is for the planning version as specified on the initial screen. The following table
provides an overview of the fields that can be maintained using the SNP cost maintenance
(directory) transaction. For further information on the fields check the respective master data
object.
Tab
Cost
Drill Down Step
Production
Production
PPM (SNP)

Bucket Resource
Category P
Location

Handling
Handling
Bucket Resource
Category H
Location
Storage
Stock-Keeping
Bucket Resource
Preparing

496

Tab
Cost

Drill Down Step

Category S
Location
Product
Transport
Transportation
Bucket Resource
Category T
Transportation
Lane
Others
Procurement
Product
Delay / No Delivery
Product
Product

4.2.3.2

SNP Cost Maintenance

The SNP Cost Maintenance transaction is a central tool that simplifies the maintenance of all SNP
related cost parameters that are stored in various master data objects. Using this transaction, cost
parameters can be changed directly in the respective master data objects. This change is not
carried out immediately but when leaving the transaction.
Fields are generally shown with their planning version specific values if a planning version
specific product master record is created and planning version specific values exist. If no planning
version dependent data exists or no planning version dependent master record is created the
transaction shows planning version independent data!
Another transaction, called SNP Cost Maintenance (Directory), provides similar functionality
while using a different user interface.
Note:

The Deployment Optimizer shares the cost definitions with the SNP Optimizer. Both
optimizers use these cost definitions.

Preparing

497

The Cost Maintenance Transaction

Path:
Technical Name:

Master Data > Supply Network Planning Master Data > Maintain
Costs (Table)
/SAPAPO/CSNP

The Table Based Cost Maintenance transaction is designed to primarily maintain the cost for the
optimizer for a given planning version. No planning version independent definitions can be made
although this is possible in most cases directly in the respective master data maintenance
transaction.
The Change column is set automatically by the system and identifies the status of the data
record displayed in the row. Icons exist to indicate e.g. that the record is blocked by another
application, or that the record has to be updated according to the changes in the table based cost
maintenance. They are all display only.
Deletion
Cost definitions can be set to the value Zero.
Prerequisites for the Creation
Note that the SNP cost maintenance transaction can only be used on master data objects that are
existing already and are maintained to the right level. Cost data on location product level for
example can only be maintained once the product has been created for the location.
Maintained Fields
All data entered is for the planning version as specified on the initial screen. The maintained fields
are all explained in the respective master data definitions. For this reason, the explanations that
can be found here only refer to such details that are different or in addition to the master data
definitions.
External Procurement
This tab displays planning version dependent data.
Procurement Cost
Relates to the product master procurement tab procurement cost.
External Cost Function
Relates to the product master procurement tab procurement cost function. The external
cost function is planning version independent but different external cost functions can be
linked to the same location product (one per planning version).

Production

Preparing

498

This entry is planning version independent. No planning version dependent setting can be
maintained, as the plan cannot carry planning version specific data on header level.
Variable Cost (updates Plan Header Single Level Cost)
Relates to the plan header single level cost.
External Cost Function
Relates to the plan header cost function.

Transportation Method
Transportation lanes are supply chain model specific, but planning version independent data.
Subsequently, the definitions based on the transportation lanes are independent of any planning version.
All fields relate to the transportation method definitions of the transportation lane.

Transportation Cost (per unit of measure)

Unit of Measure (e.g. per case)
External Cost Function
Transportation Method Cost (per unit of distance)
Flag for Discretization of Transportation Method
Product Specific Transportation Method
See notes for transportation method cost above.
Transportation Cost (per product base unit of measure)
Relates to the transportation lane / product specific transportation method transportation
cost.

Location Specific Penalties for Delay and Non-Delivery

This tab shows the planning version specific definitions only. If no planning version specific data
is maintained, it will show no entries. All fields, besides the key location and product relate to
the product master SNP1 tab location specific definitions.
Product
Location
Demand Priority
Relates to the product master SNP1 tab location specific definitions
In the product master the penalties can be defined per demand (requirement) type. In this
transaction the penalties are defined per demand priority. The following link exists
between these definitions:
Demand
Sales Order
Corrected Forecast
Forecast
Demand Penalty
Maximum Delay
Penalty for Non-Delivery

Global Penalties for Delay and Non-Delivery

This entry is always planning version independent. No planning version dependent setting can be
maintained, as these penalties are global definitions (not location specific) and the product master
does not allow the definition of planning version specific master data. All fields, besides the key
location and product relate to the product master SNP1 tab location independent definitions.
Product
Demand Priority

Preparing

499

Relates to the product master SNP1 tab location independent definitions. In the product
master the penalties can be defined per type requirement. In this transaction the penalties
are defined per demand priority. The following link exists between these definitions:
Demand
Sales Order
Corrected Forecast
Forecast
Demand Penalty
Maximum Delay
Penalty
for
NonDelivery Storage
See notes for external procurement cost above.
Product Storage Cost
Relates to the product master procurement tab product storage cost.
Safety Stock Penalty
Relates to the product master procurement tab safety stock penalty.

Allocation of Resource to Quantity/Rate

This tab shows the planning version specific definitions only. On this tab only the capacity
variant 2 of the planning version specific resource master data can be maintained. The
allocation of the quantity rate definition for capacity variant 2 can be changed in this
transaction. Costs of the capacity variant 1 cannot be maintained using this transaction. The
display and maintenance of the Quantity/Rate definitions is independent of whether they are
the active or inactive ones.
Quantity Rate Definition
Quantity/Rate Cost

This tab shows the planning version specific definitions only. Displayed on this tab are only
those quantity/rate definitions that are allocated to resources as a capacity variant in the
resource master maintenance transaction. This includes quantity rate definitions used as
capacity variants 1 and 2.
Costs

External Cost Function Definition

External Functions are supply chain model and planning version independent and this tab
subsequently displays all External Cost Functions defined in the system. Other than the
procurement type, all fields can be maintained.
Cost Function
Procurement Type
Lot Size Lower Boundary
Fixed Costs
Variable Costs
Other Functions
It is possible to jump from this transaction directly into the VS Cost Maintenance or the ND Cost
Maintenance transaction.
Preparing

4.2.4

Alert Monitor Definitions

The majority of alert monitor definitions can be found in the central alert monitor settings
transaction. The settings maintenance screen can be accessed through the menu tree structure or
alternatively while being in the alert monitor transaction. The automatic messaging function as

well as the alert type prioritization can be carried out using dedicated transactions or the alert
monitor settings. Alert profiles can be allocated in a central transaction or in the respective
interactive transactions (e.g. the forecast profile in the interactive demand planning transaction).
Within the supply chain cockpit some special alert monitor functions can be used, which are set
up in the supply chain cockpit user profile.
The following graphic provides an overview of alert monitor specific definition tasks that need to
be carried out.

Review/Change

Alert Types

Adjust Alert Type

Priorities

Add Alert Types

Add Macros

Graphic 113 Alert Monitor Definitions

Preparing

4.2.4.1

501

Settings

The settings maintenance screen is the initial screen for the majority of customization settings that
are required for the alert monitor. It can be started from the menu structure or also via some
applications (e.g. the alert monitor). A magnitude of fields can be maintained in this and all
subordinate screens.
The Maintenance Transaction
Path:
Technical Name:

Supply Chain Monitoring > Current Settings > Set Alert Monitor
/SAPAPO/AMON_SETTING

Deletion
Settings can easily be deleted without any reference to whether they are used or not. The same
applies to the information in the subordinate screens.
Prerequisites for the Creation
The only prerequisite is the existence of a supply chain model and planning version to which the
alert settings can refer.
Maintained Fields Display Alerts Settings Screen

Settings ID and Description

Note that the description and not the ID is used in the favorites selection.
Version Dependent Alert Selection
Planning Version
The planning version must be defined only if the alert monitor is to be started directly
from the menu structure.
Forecast Alert Profile
Select a profile as
required.
SDP Alert Profile
Select a profile as required.
TLB Alert Profile
Select a profile as required.
PP/DS Alert Profile
Select a profile as required.
VS Alert Profile
Select a profile as required.
ATP Alerts
ATP Alert Profile
Select a profile as required. ATP alerts always refer to the active planning version (000).
This cannot be changed.
Horizon

Preparing

502

Alerts should be generated for a period that is as short as possible to avoid unnecessary
system load. The alert time stamp is that of the event that causes the alert. The horizon can be
defined relative or in absolute terms.
Relative Time Interval
Define the alert horizon as a relative period starting either immediately or after a certain
period (offset) only. Defining a time interval of 7 days has the same effect as defining 1
week.
o Months and Offset
o Weeks and Offset
o Days and Offset
o Hours and Offset
Absolute Time Interval
Determine a fixed start and end date for the alert horizon. Note that these dates do not
change automatically and consequently the alert settings will not be used anymore after
the end date/time of the horizon.
o From Date and Time
o To Date and Time
R/3 Alert Profile
Select an R/3 alert profile if required. This option requires the prior appropriate setup of the
R/3 Core Interface (CIF).

Maintained Fields Change Profile Screen

The grid section is the same for all forecast alert profile application areas. The task to be carried
out is the selection of such alert types that need to be used and the allocation of threshold values if
possible and desired. This is an optional step, as the system has predefined alert priorities that are
used if no specific alert thresholds and priority levels were allocated.

Alert Type Selection Indicator

Alert Type Description

Standard Priority

Threshold Description

Comparison Operator

Threshold Level 1 Information

Threshold Level 2 Warning

Threshold Level 3 Error

Maintained Fields Display Alerts Settings Screen for Forecast

Alert Grid
Choose required alert types and customize their threshold values as needed.
Planning Book
The planning book can be used as a restriction for the generation of the alerts if stipulated
here. This is an optional entry and if no planning book is defined here, alerts are generated by
the forecasting run irrespective of the planning book that was used.
Selection Description
Optionally define a selection to restrict the creation of alerts to such objects (e.g. products)
that are contained in the selection.

Preparing

503

Different Text for Mini Applications

Customize the appearance of mini applications, which can be called from the SAP workplace
environment.
Message Class
Message

Maintained Fields Display Alerts Settings Screen for SDP

Alert Grid
Choose required alert types and customize their threshold values as needed.
Different Text for Mini Applications
Customize the appearance of mini applications, which can be called from the SAP workplace
environment.
Message Class
Message
Object Selection
Planning Book
The planning book must be defined, as the alert monitor checks for macro alerts in the
planning book as stipulated here. If no planning book is defined here, no macros can be
found to generate macro based SDP alerts.
Data Base Alerts
Optionally restrict the alert profile to a specific planning book view and data selection
within the planning book defined above.
o Data View
o Characteristics Selection
Dynamic Alerts
This setting is mandatory to see dynamic alerts. First, create a new row using the
Append Row function. Then select the data view (i.e. data view 1 or 2) followed by a
selection ID. The selection ID determines for which master data objects the dynamic
alerts have to be generated. The grouping function permits the display of alerts on an
aggregated level. This is an optional setting.
o Data View and Characteristics Selection
o Grouping and Aggregation of Characteristics

Maintained Fields Display Alerts Settings Screen for TLB

Alert Grid
Choose required alert types and customize their threshold values as needed.

Product Selection for Deployment Alerts

Products
Select for which products deployment alerts should be generated. Define a wildcard if
alerts should be generated for all products; do not leave this field blank.

Transportation Lane Selection for TLB and Deployment Alerts

Optionally further restrict the generation of TLB and deployment alerts by source location,
target location, or transportation planner. This is an option.
Source Locations
Preparing

Target Locations
Transportation Planner
Transportation Method Selection for TLB Alerts

 Transportation Method
Select for which transportation methods TLB alerts should be generated. Define a
wildcard if alerts should be generated for all transportation methods; do not leave this
field blank.
Maintained Fields Change Profile Screen for PP/DS

Alert Grid
Choose required alert types and customize their threshold values as needed.
Propagation
The alert monitor does not propagate alerts from a lower level to a higher level. It is
nevertheless possible to set the two indicators below so that the alert monitor checks for all
orders that are pegged to the selected (supply or demand) orders according to the alert
profile.
Display Demand with Problems in Order Network
Display Receipts with Problems in Order Network
Product Selection
Products
Restrict the validity of the PP/DS alert profile to one or multiple products. Define a
wildcard if alerts should be generated for all products; do not leave this field blank.
Locations
Restrict the validity of the PP/DS alert profile to one or multiple location products.
Production Planner
Restrict the validity of the PP/DS alert profile to one or multiple production planners.
ATP Categories
Restrict the validity of the PP/DS alert profile by order category (e.g. only planned
orders of category AI).
Days Supply
The alert monitor can create an alert if the number of days supply for a product is
exceeded. The 3 different target days of supply definitions for all products are defined
in profiles called SAP1 through to SAP3. In these profiles all ATP categories are
defined that need to be taken into consideration when calculating the total supply. The
alert monitor takes these default values if no other profiles are defined and linked to the
alert settings here. The default days supply profiles are used automatically in the alert
profile. Specify here other alternate days supply profiles if the default profiles must not
be used.
o Days Supply Type 1
o Days Supply Type 2
o Days Supply Type 3
The days supply types 1 through to 3 displayed in the right area of the screen are those
defined in the customizing (path Advanced Planner and Optimizer > Supply chain
Planning > Production Planning and Detailed Scheduling > Order View > Maintain
Days Supply Types). They are used as a default for all PP/DS alert profiles as long as
no specific ones are defined here. Note that if a user uses a PP/DS alert profile in a
PP/DS transaction that points to different days supply definitions compared to those
defined in

Preparing

505

customizing the system will display those days supply definitions from the alert profile
(and not those from customizing anymore).
Orders in Past
Alerts are generally created for horizons into the future. This setting allows alerts to be
created for past events. It extends the horizon setting into the past for the number of days
stipulated here.
Planned Delivery Date in Case of Shortage
Alerts can be suppressed for all such product shortages that are outside of the products
lead-time. This makes sense, as the product, if identified as being short, can still be
ordered and received in time for the requirement.
Resource Selection
Resources
Restrict the validity of the PP/DS alert profile to one or multiple resources. Define a
wildcard if alerts should be generated for all resources; do not leave this field blank.
Locations
Restrict the validity of the PP/DS alert profile to one or multiple resource locations.
Average
Resource
Load o RPM Time
Buckets
Used with the rapid planning matrix
only. o Low Load Alerts From (%)
Alerts can be generated if the average load of the resource during the planning
horizon is lower than the value specified here.
o Overload Alerts (%)
Alerts can be generated if the average load of the resource during the planning
horizon is higher than the value specified here.

Maintained Fields Favorite Settings Screen

Activating this function opens a pop-up window on which all public label alert settings are
displayed on the right hand side list. Mark those required and press the Select button to move
them across. They are then part of the users favorites. This function must be performed while
logged on using the appropriate user ID.
Maintained Fields Database Alert Types for SDP Screen
The changes performed here are valid for all users!
Alert Type
Select an alert type or create a new alert type. Own alert types must be within the permitted
namespace (8000 through to 9999).

Priority
Change the alert priority of an existing alert type or define the alert priority for new alert
types.

Alert Text
Change or create the alert text.

Threshold Text
Change or create the threshold text. Should the alert type not permit the usage of a threshold
then this definition is not required.

Preparing

506

Comparison Operator
Change or select the comparison operator.

Maintained Fields Dynamic Alert Types for SDP Screen

The maintenance of the Dynamic Alert Types for SDP is identical to that of the maintenance of the
Database Alert Types for SDP.
Maintained Fields Personal Display Hierarchy Screen
The changes performed here are valid for all users and not as the name might suggest only for the
user logged onto the system. If there are no entries in this table then the system uses the SAP
predefined hierarchy.

View
Several SAP predefined views are available. They are used to group alerts in the alert view
box. The alert monitor displays in the alert object box per alert view the respective alert
objects (products, resources, etc.). Select one of the views for which the SAP predefined
display hierarchy should be changed.

View Name
This is a display only field of the view selected above.

Hierarchy
Allocate a hierarchy level from 1 to 9 to each field of the selected view. The available fields
differ from one view to the next. Their precise definition, origin, and usage are not
documented but a bit of experimenting provides the required results.

Field Name
Select the field for the hierarchy level as required.
Other Functions
None.

4.2.4.2

Automatic Messaging

The definition of these settings is carried out in the Automatic Messaging Profile, which can
also be accessed, for example, from the Alert Monitor Settings transaction. It works in conjunction
with the ID for all Alert Monitor Settings. The settings carried out here are also used when sending
alerts form one user to another.
The Maintenance Transaction
Path:
Technical Name:

Supply Chain Monitoring > Current Settings > Set Sending of Alerts
/SAPAPO/ AMONMSG

Preparing

507

Deletion
Automatic messaging user settings can be deleted anytime.
Prerequisites for the Creation
None.
Maintained Fields

User
Define the user name (logon ID) of the user that is supposed to receive alerts via the
messaging facility.
Select Settings
Settings
Select the alert settings that are used by the system to check whether alerts exist that need
to be sent to the user as specified above. If no settings are defined, no alerts can be sent
automatically.
Specify Address
Select to either; send the alert to the SAP Office Inbox or to a specified e-mail address.
Mail in SAP Office
E-mail Address
The e-mail address of the user can either be taken from the user profile (central user
administration) or defined directly here.
o Central User Administration
o Direct Entry
Activate Messaging
This flag switches on the automatic messaging function. If it is not set, the system uses the
mail definitions whenever an alert is manually sent from one user to another, but it will not
send any alerts automatically.
Activate Messaging

Other Functions
None.

4.2.4.3

Alert Type Prioritization

All alert types have an SAP predefined default alert priority. This default priority can be changed
for all non-macro alerts using the transaction described here. The alert priority for macro alerts can
be changed from within the alert settings maintenance transaction. The default alert priority is not
directly visible in the alert priority table that can be maintained with this transaction. In this table

Preparing

508

one can only find entries for such alerts that have a priority that is different to the SAP defined
default priority.
The Maintenance Transaction
Path:
Technical Name:
IMG:
IMG Path:

n/a
n/a

Yes (not via user menu)

Advanced Planner and Optimizer > Alert Monitor > Maintain
Prioritization of Alerts

The maintenance of this table is very simple. Just use the New Entries button to add records as
required or delete them.
Deletion
Deleting an alert priority in this table results in the system using the default SAP defined alert
priority.
Prerequisites for the Creation
None.
Maintained Fields

Alert Object Type

Select the alert object type and alert type from the possible entries.
Alert Type
Select the alert object type and alert type from the possible entries.
Priority
Select the desired priority.

Other Functions
None.

4.2.4.4

Alert Profile Allocation

Alert profiles are allocated to the alert settings. This allocation is used when starting the alert
monitor directly form the menu tree structure. Whenever the alert monitor is started from an
interactive planning transaction, own transaction specific alert profile allocations are used.

Preparing

509

The transaction described here is used to allocate alert profiles to the SNP and DP Interactive
Planning transactions. The PP/DS alert profile is linked to the PP/DS master profile, the VS alert
profile to the VS optimization profile.
The Maintenance Transaction
Path:
Technical Name:

Supply Network Planning > Environment > Current Settings > Assign
Planners to Alert Profiles
/SAPAPO/ SDPALPR

The user interface of the alert profile allocation transaction is in the form of a grid, which allows
easy maintenance of all data as required.
Deletion
Allocations can be deleted anytime.
Prerequisites for the Creation
The alert profiles need to be created beforehand.
Maintained Fields
Maintain per user (planner) and planning area the forecast, SDP, and TLB profile to be used.
Planner
Planning Area
Forecast Profile
SDP Profile
TLB Profile

Other Functions
None.

4.2.5

Module Specific Master Data

Some data objects in APO are used only within specific modules. These module specific master
data objects support special functions of the respective module or even only an area within the
module. This type of data obviously only needs to be maintained if the specific module and
functionality is used.

Preparing

4.2.5.1

510

Characteristic Value Combinations

Characteristic Value Combinations can be seen as the access key to data that is stored in the DP
planning area irrespective of whether the data is stored in liveCache or in an InfoCube. This
transaction picks up all existing historical permutations of characteristic values existing in the
planning area. It then generates a characteristic value combination for each of those combinations.
Alternatively, or in addition to this process step, characteristic value combinations can be created
manually.
The Profile Maintenance Transaction
Path:
Technical Name:
IMG:

Master Data > Demand Planning Master Data > Maintain

Characteristic Value
/SAPAPO/MC62
No

The user interface of the characteristic value combinations maintenance transaction provides four
different functions.

Create characteristic value combinations

Use this option to manually create characteristic value combinations

Generate characteristic value combinations

Use this option to generate characteristic value combinations based on existing characteristic
values

Delete characteristic value combinations

Delete any characteristic value combinations irrespective of whether characteristic values
exist or not

Display characteristic value combinations

Provides an overview of existing characteristic value combinations
Create Characteristic Value Combinations

Define the Master Planning Object Structure.

Select the Create Characteristic Combinations pushbutton.
Type in the value for all characteristics.
None must be left blank. The Possible Entries F4 function displays all existing
characteristic values as well as previously used values even if they do not exist anymore.
Set the flag Create Time Series Object.

Generate Characteristic Value Combinations

Define the Master Planning Object Structure.

Select the Generate Characteristic Combinations pushbutton.
Specify the InfoCube and planning version in which the characteristic values are stored.

Preparing

511

Specify a date range that should be used.

Choosing a large date range ensures that all possible characteristic value combinations are
created but might also create characteristic value combinations for such combinations that are
not needed anymore (e.g. for discontinued products).
Set the flag Create Time Series Object.

Delete Characteristic Value Combinations

Define the Master Planning Object Structure.

Select the Delete Characteristic Combinations pushbutton.
Type in the value for all characteristics.
None must be left blank. The Possible Entries F4 function displays all existing
characteristic values as well as previously used values even if they do not exist anymore.
Set the flag Create Time Series Object.

Display Characteristic Value Combinations

Define the Master Planning Object Structure.

Select the Display Characteristic Combinations pushbutton.
Use the Selection Condition and/or grouping Condition pushbuttons to restrict the data to
be displayed.
Set the Display Technical Filed Names and List in Dialog Box if required.

Other Functions
Should the master planning object structure on which the planning area is based, support the
creation of dependent demands, then an additional option is available. It is used to create specific
DP-BOM characteristic value combinations.

4.2.6

Model and Version Management

The initial creation of a supply chain model is a rather simple task. The art is to build it up and
allocate all master data objects to it. The creation and maintenance of planning versions offers a
few more options but it is still a rather simple task. Note that a planning version also needs to be
initialized per planning area it is supposed to work with. We can find in APO a rather simple
transaction to carry out these tasks of creating supply chain models and panning versions. It is
dealt with further down.
Master data is created outside a supply chain model and then allocated to one or multiple supply
chain models. Exceptions are the transportation lane and the quota arrangement. Both are created
per supply chain model. Master data is not copied across planning versions, nevertheless, some
master data can be made planning version specific. This can be done in the respective master data
maintenance programs. Note that version-specific master data is not updated when the non-version

Preparing

512

specific master record is updated. Planning version-specific master data can be deleted using the
Version Management function.
The maintenance of the supply chain model is carried out primarily using the Supply Chain
Engineer. Please refer to the separate section dealing with the Supply Chain Engineer.
Note:

In the standard delivered system the active planning version is 000, the active supply
chain model is 000 as well. Transactional data is version dependent and as default only
the active version 000 contains the transactional data from the OLTP system. With the
current APO release 3.0, only one planning version can be set to be active.

The Master Data Maintenance Transaction

Path:
Technical Name:

Master Data > Planning Version Management > Model and Version
Management
/SAPAPO/MVM

The supply chain model and its planning version(s) are created in one transaction. This transaction
provides an excellent overview of all supply chain models and their allocated planning versions.
Models and planning versions can also be deleted or marked for deletion in this transaction.
Furthermore, models and planning versions can be copied. When copying planning versions,
version-specific master data is always copied across, and transactional data can be copied
additionally. If transactional data is also copied, the new planning version will be totally
independent of the active planning version.
The model and planning version management transaction can also be called from the Supply
Chain Engineer.
Deletion

Supply Chain Model

The deletion of the supply chain model can be scheduled or carried out immediately. The
deletion of the supply chain model also deletes all planning versions based on the supply
chain model.
Planning Version
The planning version deletion can be carried out with two options.
Delete all transaction data
Delete all transaction data and planning version specific master data
Both options can be scheduled or carried out immediately in foreground and background.

Prerequisites for the Creation

There are no prerequisites for the creation of a supply chain model. In order to create a planning
version, the supply chain model must exist.

Preparing

513

Maintained Fields
Supply Chain Model
That is really all! A name and a description is the only information required.
Name
Description

Planning Version
SNP: Change Planning Active
Set this flag to ensure that any changes that are relevant for the SNP planning activities
are recorded by SNP. This concept is similar to that of the planning file entry in R/3.
PP/DS: Change Planning Active
Set this flag to ensure that any changes that are relevant for the PP/DS planning activities
are recorded by PP/DS. This concept is similar to that of the planning file entry in R/3.
PP/DS: Automatic Planning Active
Enables the usage of automatic planning if switched on for the respective location
product. This setting here is not a default value but rather a switch that is required to be
on if any product should be planned automatically in PP/DS. The function is resource
intensive and should only be switched on if required for the planning version.
PP/DS: No Order without Source of Supply
This flag, if set, ensures that PP/DS can only create orders if the source of supply is
defined. The following options exist:
E
PP/DS planning activitie
supply (valid PPM) for in-house production
F
PP/DS planning activitie
supply (vendor with transportation lane) for external procurement
X
PP/DS planning activitie
supply for in-house production or external procurement
Blank
PP/DS planning activitie
PP/DS: Standard Planning Horizon
This is the default production horizon used for all products for which no production
horizon has been maintained in the product master PP/DS tab. It can be different per
planning version but is always superceded by a product master definition.
PP/DS: Determine Priority
Option blank: when Make-to-Order from S/O, else form product master
Option 1 is always from requirement. If requirements have different priorities then the
order has highest priority of all
Option 2 is always from product. Works even if requirements have different priorities
within or compared to product.
See product master SNP 2 tab.
PP/DS: Take Safety Stock into Account
This option needs to be activated in order for PP/DS to maintain safety stock levels as
defined in the product master (time independent safety stock) or in a key figure (time
dependent safety stock).
Update of ATP Timer Series
This flag determines whether the ATP time series is updated while performing relevant
transactions in APO or an attached R/3 system. The flag must be set if Global ATP

Preparing

514

functionality is to be used in APO. Global ATP works only in planning version 000 and
consequently this flag can only be set in this planning version and only during its
creation.
Other Functions

Compare Master Data

With this option it is possible to compare planning version specific master data of exactly two
planning versions of the same supply chain model. This does not include the comparison of
planning version specific data against model independent master data. The comparison can be
carried out for locations, location products, resources, and the PPM.

4.2.6.1

Supply Chain Engineer

The Supply Chain Engineer is a modeling tool used to link data objects such as locations,
products, resources, and production process models to the supply chain model. It is a common
misconception that the supply chain engineer is used to model the supply chain cockpit. This is
wrong, as the supply chain engineer is the tool to define the supply chain model. It has an impact
on the data that can be viewed in the supply chain cockpit, as in the supply chain cockpit a certain
planning version with its associated supply chain model is displayed. Nevertheless, the appearance
of the supply chain cockpit is defined separately and independently of that of the supply chain
engineer.
Before a supply chain model can be used in the supply chain engineer it needs to be created. This
can be done together with the planning version in one transaction. See Model and Version
Management for more information.
If using the supply chain engineer to allocate master data objects (except transportation lanes and
quota arrangements) to a model, they must first be made part of the work area and by doing so
they become visible in the supply chain engineer. Master data objects can alternatively also be
linked to a supply chain model while in the respective master data maintenance transaction. This
is depicted in the graphic below.

Preparing

515

M aster D ata M aintenance

C reate, U pdate

A dd to M odel

A dd to W ork A rea

A dd to M odel

Supply C hain
Engineer

Graphic 114 Definition of the Supply Chain Model

The Master Data Maintenance Transaction

Path:
Technical Name:

Master Data > Supply Chain Engineer > Maintain Model

/SAPAPO/SCE01

When opening the Supply Chain Engineer the last used supply chain model and work area are
prompted for use. The work area, which defines the master data objects that can be seen and used,
is maintained in the Supply Chain Engineer.
In order to allocate master data objects (except transportation lanes and quota arrangements) to a
model using the supply chain engineer, they must first be made part of the work area and by doing
so they become visible in the supply chain engineer. Adding data objects, which are shown in the
tree structure, to the work area is the first step of making master data objects part of a supply chain
model when using the supply chain engineer. In a second step the data objects can be made part of
the supply chain model.
Note that Hierarchies cannot be allocated to the supply chain model in the supply chain engineer.
This can only be done in the hierarchy maintenance transaction.
Preparing

The graphic below displays a symbolic layout of the Supply Chain Engineer screen.

A p p lic a tio n B a r
V ie w S e c tio n
S u p p ly C h a in S e c tio n

Structures

W o r k A r e a O b j e c ts S e c tio n

Object

Tree

M a p S e c tio n

Graphic 115 Supply Chain Engineer Screen layout

The Application Bar

Application Bar Pushbuttons
Change / Display
Use these pushbuttons to switch between the change and display
mode.
Model and Planning Version Management
Opens the transaction with the same name. See Model and Version
Management for more information.
Objects in Model
Pressing this pushbutton opens a pop-up window listing all objects (e.g.
products and locations) that are part of the selected supply chain model
and not those that are part of the work area. In this window the pushbutton
labeled Include Objects in Work Area is very helpful to add all objects
Preparing

of a model to the selected work area. Add

Object to Model

This function allows the adding of one or multiple products, locations,

resources, and production process models to the supply chain model.
Delete Object from Model
Use this pushbutton to remove (delete) selected objects from the supply
chain model.
Add Dependent Objects to Model
Use this pushbutton to add objects that are dependent on other already
included objects to the supply chain model.
Reset Display
Resets the display to show the map in the map section again.
User Settings
Press this pushbutton to open the User Settings window. User settings
can also be maintained directly from the menu tree structure in which
case more options are available.
See Supply Chain Engineer User Settings for more
details. Graphical Display Show/Hide
Switches the map section and the object tree structures of the screen on
and off.
The Supply Chain Section
The supply chain section displays the currently selected supply chain model. Other models can be
selected by typing the appropriate model name into the supply chain model entry field.
Supply Chain Section Pushbuttons
Save Model
Saves the currently selected and displayed supply chain model.
Model Header
Provides administrative information about the currently selected and
displayed supply chain model.
The Work Area Objects Section
Preparing

The supply chain cockpit work area defines the master data objects that are visible and available
in the supply chain engineer working session. The supply chain engineer and supply chain
cockpit share the same work areas.
For more information view Supply Chain Engineer Work Area.
The View Section

In the view section the user can switch between a geographical and a logical view. The
geographical view uses maps and displays the locations according to their geographical
coordinates, as defined in the location master. Logical views display the locations where the user
places them irrespective of their geographical coordinates. Several logical views can be defined
without interfering with the geographical coordinates saved in the location master. The
pushbuttons in this section are only active while a logical view is selected.
For more information see the section Logical View.
The Map Section
Map Section Pushbuttons
Fit to Objects
Press this pushbutton to let the system zoom in to a degree that all
elements fit into the display.
Zoom Out and Zoom In
Zoom out and in function.
Zoom to World
Displays the entire world in the map display.
Overview
Opens a map overview pop-up window. There a red box indicates the
selected area of the main map.
Show Layer Dialog
Opens a pop-up window, which can be used to change color, line and
other graphical settings of the map display.
Filter
Press this pushbutton to select which element types (i.e. which location
types) are shown in the plan flow panel.

Preparing

519

Select
This is the default display mode. Use it to select elements without being
able to move them. This mode ensures that the time intensive unwanted
movement of objects does not happen.
Highlight
Switch this display mode on to highlight elements the cursor is positioned
on. Click on an element to view text information about the element (click
on the x to delete this text window).
Move
Switch this display mode on to move locations to other positions on the
map. This changes the geographical coordinates of the location.
Connect
Switch this display mode on to create transportation lanes.
Switch Connections
Press this pushbutton to change the way the elements connections are
displayed. The pushbutton is a toggle key between connection direct lines
with angles as required, and connection lines that are exactly horizontal
and vertical.
Print / Save
Use this pushbutton to print or save the graphical display.
Brightness
Use the brightness slider to change the map display brightness.

How To Work with the Supply Chain Engineer

Many tasks can be carried out using the supply chain engineer but the main ones are the adding of
master data objects to both the work area and the supply chain model. These tasks are explained
below in detail. Note that it is also possible to add most master data objects directly in the
respective transaction. An exception is the handling of transportation lanes and quota
arrangements, which are both created within a supply chain model. Transportation lanes and quota
arrangements can also not be allocated to work areas, as they are always displayed when the
supply chain model they are created in, is called up.
The following text explains a possible way of carrying out certain tasks. Quite often there is more
than one possibility to achieve the desired result, but the described option is seen to be the most
appropriate.

Preparing

520

Work Area Maintenance

Refer to Work Area for a detailed explanation how to add and delete objects from the work
area. Note that the supply chain engineer and cockpit share the same work areas.

Supply Chain Model Maintenance

Adding of one or multiple objects of different
types o Select the Add Objects to Model
pushbutton.
o On the upcoming screen define the basic quantity (pool of objects) as either such of
the work area or all objects. Then press the Multiple Selection pushbutton for all
object types to be included.
o Fine-tune the objects (deselect some if required) on the next screen, select Okay
and Execute.
Adding of one or multiple objects of the same type
Use the following procedure for objects of the type product, resource, PPM, or iPPE. Use
it only for such locations that have already correctly maintained geographical coordinates
in the location master. Locations without explicitly defined geographical coordinates are
placed somewhere in the middle of the country that is defined in the location master.
o Select any object in the tree structure (e.g. a specific product).
o Activate the context sensitive menu on the object and select Add to Model.
Depending on the object type a further selection (e.g. Location Product) might be
required.
o On the upcoming screen define the basic quantity (pool of objects) as either such of
the work area or all objects. Then press the Multiple Selection pushbutton.
o Define a single object number or an object number range and select Execute.
o Fine-tune the objects (deselect some if required) on the next screen, select Okay
and Execute.
o A confirmation is displayed and the objects are added to the work area immediately.
Use the following procedure for objects of the type location if the location does not have
yet correctly maintained geographical coordinates in the location master.
o Select the location in the tree structure.
o Drag the location symbol from the objects tree structure to the map and position it
where required.
o Confirm or change the geographical coordinates in the upcoming window.
Deletion of one or multiple objects of different types
o Select the Delete Objects from Model pushbutton.
o On the upcoming screen define the basic quantity (pool of objects) as either such of
the work area or all objects. Then press the Multiple Selection pushbutton for all
objects types to be included.
o Fine-tune the objects (deselect some if required) on the next screen, select Okay
and Execute.
Deletion of individual objects
o Select any object in the tree structure (e.g. a specific product).
o Activate the context sensitive menu on the object and select Delete from Model.
o The object is immediately taken off the supply chain model.
Creation of transportation lanes
o Press the Connect pushbutton
o Click on the source location and drag a line from the source location to the target
location. Depress the mouse button.

Preparing

521

The transportation lane maintenance window appears. View Transportation Lane

for more information.
Deletion of transportation lanes
o Select the transportation lane in the tree structure or on the map.
o Activate the context sensitive menu on the transportation lane and select Delete.
o The transportation lane will be taken off the supply chain model after confirmation.
Creation or Deletion of quota arrangements
o Select a location in the tree structure on the map.
o Activate the context sensitive menu on the location and select Quota Arrangement
and Change Incoming Quotas or Change Outgoing Quotas.
o The quota arrangement maintenance window appears. View Quota Arrangement
for more information.
o Create or delete quota arrangements as required.
o

Other Functions
A multitude of additional functions can be invoked from the start menu. Most of them are selfexplanatory and certainly worthwhile exploring. Two important ones are the possibility to jump
into the model and planning version management transaction and the model consistency check (as
of release 3.1).
The model consistency check provides the functionality to check the entire supply chain
model with its linked planning versions for data consistency. This is particularly helpful after
setting up a new supply chain model or after mass data maintenance has been carried out.

4.2.6.1.1

Supply Chain Engineer Work Area

The work area defines the master data objects that are visible and available in the supply chain
engineer working session. Transportation lanes and quota arrangements are not part of the
definable work area as they are defined per supply chain model and automatically shown when
opening the supply chain engineer for a certain supply chain model. This means that all
transportation lanes and quota arrangements of a certain supply chain model are shown at any
time.
Preparing

Location
Master
Product
Master
Resource
Master
Production

Process Model
Supply Chain Engineer
Add to
Work Area

Add to
Work Area

Graphic 116 Supply Chain Master Data

Although not stipulated in the graphic above, master data objects can be part of the supply chain
model but not of the work area. This can be due to the following reasons:

Master data objects are assigned to a supply chain model directly in the master data
maintenance transaction and not in the supply chain engineer.

Master data objects were deleted from the work area after being assigned to a supply chain
model.
Once the master data object is part of the supply chain model it can be used in the planning tasks.
The iPPE as well as hierarchies can also be made part of the supply chain model.
Work areas are not dependent on the supply chain model. Using the same work area name in
conjunction with two supply chain models is therefore possible. This includes private labels. The
work area is what one sees, and not what is part of the supply chain model.
The same public label work area definition is used for both, the supply chain engineer and the
supply chain cockpit. Thus definitions made in the supply chain engineer are valid for the supply
chain cockpit and vice versa. This excludes the private label work area blank. The work area
definition that is defined in the PPM maintenance is independent of that used in the supply chain
engineer and cockpit.
The relation between public and private labels for the supply chain engineer (SCE) and supply
chain cockpit (SCC) is depicted in the graphic below.

Preparing

523

W ork A rea

Identical for PublicLabel

L o ca tio n
M a ste r

W ork A rea

T ransportation
L ane
R eso u rc e
M a ster

P ro d u ctio n
Process M odel

P la n n in g

S u p p ly

V ersio n

C h a in
M o d el

Graphic 117 Work Areas in SCE and SCC

For more information on defining and maintaining work areas view the section Work Area.

4.2.6.1.2

Supply Chain Engineer User Settings

The user can define his or her individual working environment using the supply chain engineer
user profile. In the user profile, various defaults can be set. Maintenance of the user profile is also
possible outside of the supply chain engineer from the menu structure. When maintaining the
profile starting from the menu structure, more options are available.
These additional options mainly deal with the graphical representation of the supply chain
engineer. Those settings dealing with color definitions are omitted in this list.
Preparing

General Tab

Settings for Objects Text

Changes the label that is used for displayed elements such as locations or
products (select either ID or description) and the screen tip, which is
coming up when the cursor is above the object.
Setting only possible from outside the Supply Chain
Engineer. Display Resource Long Texts
This flag does not appear and has no apparent effect on the supply chain
engineer display.
Highlight Objects not contained in the Model
Select whether objects that are part of the work area but not part of the
model should be highlighted in the tree structure. Objects that meet this
condition are displayed with a special symbol. Using the highlight
function further improves the visibility.
Use Work Area as Filter for Graphical Display
Select whether locations that are part of the model but not of the work
area should be displayed on the map. Even if this flag is set, the locations
in the model that are not part of the work area are still shown in the tree
structure.
Display Hierarchies
Switch this flag on to view location, product, resource, and PPM
hierarchy structures. The hierarchies are shown just below the tree
structure of the corresponding object (i.e. the product hierarchies below
the products).
Setting only possible from outside the Supply Chain
Engineer. Use Work Area as Filter for Displaying Hierarchy Objects
Switch this flag on to exclude all such hierarchy objects in the hierarchy
display that are not part of the work area.
Setting only possible from outside the Supply Chain
Engineer. Display Location Products: Locations left, Products right
Switch this flag on to view location products in the hierarchy with the
location on the left.
Setting only possible from outside the Supply Chain Engineer.
Model Maintenance Tab
Assign Dependent Objects to Model
Set this flag to ensure that data objects the assigned object depends on
are assigned to the supply chain model automatically.
This function primarily relates to the assignment of a PPM. In a situation
Preparing

where a PPM is assigned to the supply chain model, the system also
assigns all objects the PPM is depending on to the model. These are the
resources and products.
Note that this function does not assign dependent objects but such the
new data object depends on.
Include Dependent Location Products when assigning Location

Set this flag to assign all location products to the supply chain model
automatically when the location is added.
Include Dependent Resources when assigning Location
Set this flag to assign all resources of the location to the supply chain
model automatically when the location is added.
Include Dependent PPMs when assigning Location
Set this flag to assign all PPMs of the location to the supply chain model
automatically when the location is added.
Maintain Geographical Coordinates
When adding a location to the first supply chain model using the drag
and drop functionality the geographical coordinates might not be
maintained in the location master. In this instance a pop-up window
appears if this flag is set allowing the user to confirm or change the
geographical coordinates.
Locations can be moved irrespective of whether this flag is set or not.
Query Tab
Relative / Fixed Time Interval
Select either fixed or relative time interval to be used for queries. When
carrying out the query, this setting is used to propose a time interval. It
still can be changed as required.
Relative Time Interval
If you have selected to use relative time intervals, specify the time
interval duration and period type here.
Fixed Time Interval
If you have selected to use a fixed time, specify the start and end date
and time here.
Use Selection Dialog Box
When starting a query, a selection dialog can be shown, which allows
refining the query parameters (e.g. interval). This flag defines whether
this selection dialog box is suppressed (option 2) and if not which one is
used.
Transportation Tab
Location Assignment Check of a Product of Transportation Lane
Preparing

Select whether an error message must be created when assigning a

product to a transportation lane that is not maintained in both, the source
and the target location. This flag setting is also used by the transportation
lane maintenance transaction.

4.2.6.2

Work Area

APO supports the definition of various work areas. If a planner has for example two different
areas of responsibility in which he or she works, it might be helpful to easily switch between two
or more work areas. Each user has automatically got a work area with the name blank (no
name). This work area blank is also called user dependent work area and is different per user

logon ID. The combination of user ID and work area blank is unique, not the work area blank
on its own. This is a so-called private label, as it is only visible by the respective user. Each user
has got such a private label but they are different per user.
All other (named) work areas are not user dependent and display identical information
irrespective of user ID used when logging onto the system. They are unique on their own and
referred to as a public label. A public label is any work area with a name other than blank. Any
user can use public labels irrespective of who has created them initially.
No special create function exists. Typing a new work area name creates the work area.
Pushbuttons
Empty Work Area
Deletes all object assignments within the work area and leaves back an
empty work area.
Load Work Area
Loads the selected work area.
Save Work Area
Saves the selected work area.
Delete Work Area
Deletes the work area with all its object assignments.
Redefine Work Area
Allows adding of new work area objects.

It is important to understand that during a session new master data objects can be added to the
work area without necessarily changing the work area definition. A changed work area needs to
be saved

Preparing

527

separately. When leaving the respective application, a pop-up window reminds of this fact and
offers to save the work area.

Work Area Maintenance

Objects are added to the work area to make them visible in the supply chain engineer and
cockpit. There is no technical prerequisite for an object (location, product, resource, PPM, or
iPPE) to be part of a work area in order to be part of a supply chain model. If objects
previously deleted from the work area are made part of the work area again they are
automatically seen as part of the model again. That is obvious, as they were always part of the
model (but not visible).
Deleting data objects from the work area does not automatically take them off the supply
chain model.
Adding of one or multiple objects of different types
o Select the Redefine Work Area pushbutton.

4.2.6.3

o On the upcoming screen define per object type a single object number, an object
number range, or a previously defined selection. Double-click on the respective lines
in the left tree structure to change from one object type to the next. Ensure that none
of the characteristics lines are left blank, as this might be seen as a include all
instruction. Then select Copy.
Adding of one or multiple objects of the same type
o Select any grouping symbol in the tree structure (e.g. Location or Plants).
o Activate the context sensitive menu on the grouping symbol and select Add Objects
to Work Area.
o Define a single object number, an object number range, or a previously defined
selection and select Copy.
o The objects are added to the work area immediately.
Deletion of all objects of all object types
o Select the Empty Work Area pushbutton.
o The work area is emptied entirely.
Deletion of all objects of a specific object type
o Select any grouping symbol in the tree structure (e.g. Location or Plants).
Selecting e.g. Location takes all locations off the work area, selecting Plants
only location of the type Plants.
o Activate the context sensitive menu on the grouping symbol and select Delete
Objects from Work Area.
o The objects of the object group are immediately taken off the work area.
Deletion of individual objects
o Select an individual object in the tree structure.
o Activate the context sensitive menu on the grouping symbol and select Delete
Objects from Work Area.
o The object is immediately taken off the work area.

Logical View

No special create function exists. Typing a new view name creates the view.
Preparing

View Section Pushbuttons

Assign Automatically (only PPM)

Rearranges the objects automatically. The function, although called

differently, is the same as described below and used in the supply chain
engineer and cockpit.
Set Positions to Default (only SCC and SCE)
Repositions all objects in the logical view according to some principles
(not to the last saved view layout).
Load View
Loads all objects as defined in the view and positions them at the same
place, as they were when the view was saved last.
Save View
Saves the current view.
Delete View
Deletes the currently selected view.
Characteristics / Customize View
This pushbutton opens a pop-up window permitting some graphical
settings like e.g. background pictures and colors.

Preparing

4.3

529

The Transaction Environment

The first time APO-user will see that there are numerous and rather complex looking transactions
within the various modules. But once a transaction is started one realizes that various of them look
very similar. Sometimes it might not even be clear immediately what the difference is between
them. This initial confusion can be overcome easily and what is left is a transaction environment
with so many common features that it is easy to transition from one to the next. The transactions
within APO can be grouped as follows:

Time Bucket Based Transactions

Used predominantly within DP and SNP, these transactions focus on the display of data per
time bucket (e.g. weekly forecast or planned production orders of a day). Since release 3.0
these two modules have a common user interface despite their different tasks. Although data
is shown predominately per time bucket, the display per order is supported where applicable
via a type of drill-down function. The transactions used in DP and SNP are highly
customizable.
Order Based Transactions
Orders are the domain of PP/DS and TP/VS. The order based transactions are well suited to
display single orders in a list format and offer extensive drill-down functions through to the
operations and activities. They are though less customizable than those mentioned above.
Operation Based Transactions
The operations based transactions are used within PP/DS to schedule operations and activities
of production orders. The main transaction is the Detailed Scheduling Planning Board, which
is extremely flexible in terms of its customization possibilities and it appears that the only
thing one cannot do is making the transaction beep.

All transaction groups are explained in more detail below, and also in the section Performing.
A related and special role in the transaction environment have the Supply Chain Engineer and the
Supply Chain Cockpit. Both are transactions, but do not process transactions in the strict
terminology of information systems. The supply chain engineer is a master data maintenance
transaction and thus not part of this section. The supply chain cockpit is used to get an overall
view of the supply chain model and the planning situation. But again it is not a transaction to
perform the core planning task. The supply chain cockpit can be used as a central tool from which
the planner can access the main APO transactions. This is depicted in the graphics below.
Preparing

Planning Screen
Graphic 118 The Hub Supply Chain Cockpit

4.3.1

Time Bucket Based Transactions

Time bucket based transactions are used predominately in DP and to a certain extent in SNP. The
main transaction is the SDP Interactive Planning transaction. This transaction is a container that
gets to live through the design of planning books. Planning books define what the user can see
when starting this transaction. Various sample planning books are delivered with the standard APO
system. They can be used as examples but in a live environment own planning books are usually
created. The tool to do this is the Design Planning Books transaction. Hand in hand with the
usage of planning books goes the usage of macros. Macros, also referred to as Advanced Macros,
are small pieces of program code that carry out various functions and calculations. Macros are
defined per planning book and data view and thus need to be looked at as well. The transaction to
do so is the Macro Builder.

Preparing

4.3.2

531

Order Based Transactions

Order based transactions are used in SNP, PP/DS, and TP/VS. The main transaction for SNP is the
SDP Interactive Planning transaction. See the explanation in Time Bucket Based Transaction.
Within PP/DS, two transactions are mainly used to carry out the planning tasks. They are the
described below.

Product View
The domain of this transaction is the product planning task. The emphasis is clearly on the
product and not on e.g. the used resources. The product view can also be called from the SDP
Interactive Planning transaction. The information displayed at any time is per single product
and location.

Product Planning Table

This transaction contains a lot of information and functionality provided also in the product
view. It goes further and links product related information with that of the resources in
production. It can also be used in the external procurement (purchasing) area. The product
planning table can display information for several products, locations, and/or resources.
Both are extremely modularized and, in fact, often use the same modules. Though they are not as
adaptable as the SDP Interactive Planning transaction, they still provide more customization
possibilities than usually required. The customization is carried out per user in the respective
setting window through accessing the User Settings. There are two related transaction which are
in fact subsets of the product view.

Receipt View

Requirements View
They receipts and requirements view are similar to the product view but can display data for
multiple products and locations.
The central transaction for TP/VS is the Interactive Vehicle Scheduling. The transactions
is driven by various profiles (like all other APO transactions) but does not really allow to be
customized to the same extent as the other transactions discussed before.

4.3.3

Operation Based Transactions

Orders have operations and the task of Detailed Scheduling is to manage these operations. Within
the Detailed Scheduling environment, four transactions can be found. They are the Detailed
Scheduling Planning Board Variable View and the Detailed Scheduling Planning Board View1, -2, and -3. In all cases the same program, the PP/DS Planning Board, is called. The
Detailed Scheduling Planning Board Variable View uses a profile, as specified in the transaction
itself. When starting the transactions Detailed Scheduling Planning Board View-1, -2, or -3, the
program is started with a profile as defined in the Own Data of the User Profile.
The Detailed Scheduling Planning Board is a graphical, highly configurable screen that displays
orders, operations, activities, resources, products, and their relationships. It also offers various
interactive functions such as scheduling and optimization. Although it can be found as part of the
PP/DS environment, it can display not only PP/DS related objects and transactions but also those
of

Preparing

532

SNP. The Detailed Scheduling Planning Board is also referred to as the Planning Situation for
Product.
The Product View as well as the Product Planning Table can be switched over to display operation
based information. In this case a subset of the Detailed Scheduling Planning Board is displayed.
The same screens are also used in the TP/VS environment where the operations of a shipment
order (e.g. load or unload) are displayed.
Performing

5 Performing
APO offers by far less transactions when being compared to R/3. There are two reasons for this.
Firstly, the functional diversity of APO is smaller than that of R/3 and secondly the APO
transactions are very rich in functionality. They usually offer not just a certain single function but
a whole range of functions within the given transaction. This is a main reason why traditional
transaction based help tools cannot provide the necessary support to the user.
The term transactions, used as a grouping terminology, comprises four different transaction
modes that are explained in the following sections.

Interactive Transactions
This group, also referred to as online processing, consists of all those transactions where the
user interacts with the system. The user types in a product number and location and is then in
turn presented with the planning situation. He or she can then do some manual updates or
start a planning run. Interactive processing is usually characterized by a situation where the
user selects a set of data, views it, and performs activities with this data. An example would
be the update of time dependent safety stock levels in the SNP Interactive Planning
transaction.

Interactive Batch Transactions

With interactive batch transactions, the user starts the processing of a whole batch of data out
of the interactive transaction. He or she will then have to wait for the results to be displayed
and during this processing time, the session in which the user works is blocked for any other
activity. An example for this is the starting of the SNP Optimizer while being in the SNP
Interactive Planning transaction. Interactive Transactions and Interactive Batch Transactions
are often one and the same transaction and referred to generically as Interactive
Transactions.

Background Batch Transactions

Batch transactions are frequently performed in the background. The data that is used in a
batch job is defined upfront. The definition of this data can be saved in a variant. This
provides the advantage that the required data does not have to be selected in an interactive
manner every time a certain planning run has to be performed. During a background batch
transaction, the session in which the user works is blocked for any other activity. The
majority of background batch transactions can also be performed as interactive batch
transactions.

Scheduled Background Batch Transactions

Background batch transactions can also be started at predefined times and/or conditions. In
this case some resource-intensive transactions can be scheduled to run for example over night
or on the weekend. It is also possible to define sequences that ensure that a given planning
run is only executed after the successful end of a predecessor job. Scheduled background
batch transactions, once started, run in the background and do not block the users session
from which they were started. They can also be started immediately. Background Batch

Transactions and Scheduled Background Batch Transactions are the same. They only differ
in terms of timing and user autonomy.
The following table provides an overview of the various transactions modes.

Task
Supply Network Planning
Performing

Task
Heuristics
Supply Network Planning
Optimization
Deployment Heuristics
Deployment Optimization
Transport Load Builder
Extended Safety Stock
Planning
Table 83 Transaction Modes
Interactive and interactive batch transactions are dealt with together in the section Interactive
Transactions.
Another type of transactions are the Common Utility Pop-Up (CUP) windows that are used to
support the same or very similar functions in various transactions. They are not standalone
transactions but rather support functions for tasks that are common to multiple transactions. The
CUP is used in various types of transactions and across APO modules.

Performing

535

5.1

Interactive Transactions

As mentioned at other places, APO has by far less transactions than a typical OLTP system such as
R/3. Quite often there is even more than one transaction that can be used for the same task and
handle the same type of order. The difference is the speed and effectiveness with which the order
can be maintained, as the various transactions focus on different areas of the supply chain
management task.
The following list (the daily task cheat sheet) provides an overview of possible interactive
transactions per order type. This list is neither meant to be a complete listing, nor does it imply
that other transactions not listed could not be used for a certain task. It is based on experience and
must be seen as a suggestion. The orders can also be created in dedicated batch planning runs.

Order Type
SNP Planned Production Order

SNP Planned Distribution Order

SNP Confirmed Distribution Order

(Deployment Order)
TLB Confirmed Distribution Order

PP/DS Planned Orders

Table 84 The Daily Task Cheat Sheet

(*) SNP IP
TLB
TLB
Performing

PV

536

PP/DS Product View

Global ATP is an auxiliary tool for various transactions and thus does not have own business
transactions.

5.1.1

SDP Interactive Planning

The SDP Interactive Planning transaction is the main transaction for DP, SNP, Deployment, TLB,
and Promotion Planning. It is a very flexible and powerful tool that provides the planner with all
essential tools to perform the day-to-day tasks. There are several interactive transactions within
Demand Planning and Supply Network Planning, and they all share the same basic layout and
functionality. What distinguishes them is primarily the displayed data and the way it is presented.
The layouts of the DP and SNP interactive planning screens are user definable and based on the
planning book definitions with its data views. The other related SNP transactions, which are
discussed separately, are as follows:

Sales and Operations Planning (SOP)

Distribution Requirements Planning (DRP)

Vendor Managed Inventory (VMI)

These transactions are dealt with in separate sections but are at the same time cross-referenced in
the documents to avoid duplication of information with regards to shared functionality. This
section, called SDP Interactive Planning also provides all the basic information required to
understand the other sections mentioned above.
The Transaction
Path:

Supply Network Planning > Planning > Interactive Supply Network

Planning

Technical Name:

/SAPAPO/SNP94

/SAPAPO/SDP94 (*)
(

As mentioned above, there are several interactive transactions within the DP and SNP
module. The DP Interactive Planning transaction and the SNP Interactive Planning transaction
are virtually identical but have one big difference. The DP transaction allows using several
planning books, all shown in the data view (see below) at the same time. The SNP transaction
displays only two planning books at any given time. There is no disadvantage in using the
more flexible DP transaction as well in SNP.
The application bar (see below) displayed in the planning transaction is different for DP and
SNP planning. The different layout is not driven by the transaction code, but by the type of
planning area that is displayed in the planning book. Each planning area is linked to a master
planning object structure, which in turn defines the usage (DP or SNP), and with that the
buttons of the application bar.

The appearance of the SDP Interactive Planning transaction can differ widely depending on which
planning book and data views it is based on. It is even possible to switch over from one planning

Performing

537

book to the other while being in the transaction, which potentially changes the displayed fields and
pushbuttons entirely. The SDP Interactive Planning transaction that is described here refers to the
standard delivered transactions.
The term SNP Interactive Planning transaction refers to
the transaction when working with an SNP planning
area.
The term DP Interactive Planning transaction refers to
the transaction when working with a DP planning area.
The DP Interactive Planning transaction focuses on the DP data and planning functionality.
Starting from the DP Interactive Planning transaction, various forecasting and planning activities
can be initiated.

Univariate Forecast

Multiple Linear Regression

Composite Forecast

Promotion Planning
The SNP Interactive Planning transaction provides all tools to manually update relevant SNP data.
This includes for example the possibility to maintain time dependent safety stock levels or reorder
points. It can also be used to manually create SNP planned production or transportation orders.
The TLB functionality is available in a special screen. Starting from the SNP Interactive Planning
transaction various planning activities can be initiated.

SNP Heuristics

SNP Capacity Leveling

SNP Optimization

Deployment Heuristics

Transport Load Builder

The SDP Interactive Planning screen is subdivided into various areas. The application bar housing
some pushbuttons can be found on top of the screen. The left side of the screen shows the socalled selector views; on the right side the planning table views with the actual working data are
visible.

Application Bar
The application bar layout depends on the selected planning area (and book).
For DP based planning areas the application bar pushbuttons start the various forecasting
methods with their specific sub screens.
For SNP based planning areas the application bar pushbutton permits a switch over to the
TLB view.
Some common buttons are displayed in both cases.

Selector Views
The selector views remain the same throughout all views.
Info Objects Area
The info objects area is used to select the data used for the planning task. The upper area
displays single master data objects, the lower area the selection profiles (if defined). The
displayed data objects are also referred to as the hit list.
Performing

Data Views

The data view lists all planning books and data views that can be used in the interactive
planning transaction. Changing the planning book always requires a new data selection.
Components
The macros defined for the planning book and data view are shown in the components
area. Macros are applied automatically based on defined events (e.g. at start or exit) or
activated by the user (e.g. the macro alerts).
The relative vertical size of the 3 selector views can be changed using the click and drag
principal. The same applies to the width of the entire selector view area, which changes the
size of the planning table view. The selector view can also be closed entirely to enlarge the
planning table view.
Planning Table Views
Switching between the views changes the grid display on the right hand side and makes
available some planning table dependent pushbuttons (e.g. SNP Optimizer or Capacity
Leveling).
Data View 1 Products (SNP)
Data View 2 Resources (SNP)
TLB View (SNP)
The standard delivered DP planning book incorporates only one planning table view. The
planning table views can incorporate graphical display sections of the displayed data. The
graphics can be switched on and off as required. At the bottom of the planning views two
other areas can be switched on and off as and when required.
Alert Monitor
Notes Management
Once a forecast with a specific forecast technique has been started (e.g. a univariate forecast)
the display changes to predefined screens that are different depending on the forecast
technique. These screens are not customizable.

The graphic below displays a symbolic layout of the SNP Interactive Planning screen.
Performing

A p p lic a tio n B a r

In fo O b je c ts A r e a

D a ta
V iew

C o m p o n e n ts V iew

Header

P la n n in g T a b le V ie w s

S N P V iew 1

S N P V iew 2

T L B V iew

D e ta ils / P r o d u c t V ie w

Graphic 119 SDP Interactive Planning Screen Layout

The header area is not visible in the TLB view. The details area can only be activated from the
data view 1. The following text explains the various elements of the SDP Interactive Planning
screen. It firstly provides an introduction to the functionality of the pushbuttons that can be found
on the screen and then in a second step the displayed data elements.
The Application Bar
Application Bar Pushbuttons
Switch Shutter On/Off
Select this pushbutton to entirely close the selector view, in order to
maximize the planning table view. Press this pushbutton again to display
both the planning table and the selector view.
Change / Display
When entering the SNP Interactive Planning transaction it is in display
mode. Use these pushbuttons to get into <change> and if required
<display> mode again.
Transport Load Builder (SNP only)
The TLB view is a special view dedicated to the application area of the
transport load builder. The TLB view cannot be customized as the other
data views and is an option available in all planning books based on SNP
Performing

planning areas.

In order to return from the TLB view to any other data view the Back
pushbutton must be pressed.
Statistical (Univariate) Forecast (DP only)
Opens a sub-screen used to carry out the statistical forecasting.
Multiple Linear Regression (DP only)
Opens a sub-screen used to carry out the multiple linear regression.
Composite Forecast (DP only)
Opens a sub-screen used to carry out the composite forecasting.
Promotion Planning (DP only)
Switches over to the Promotion view, which can also be called directly
from the menu structure.
The Promotion view is a special view dedicated to the application area of
the promotion planning. This view cannot be customized as the other
data views and is an option available in all planning books based on DP
planning areas.
Header On/Off
This is a toggle key to switch the header information on and off. The
information displayed in the header can be customized once the header is
switched on. In order to leave the header off once it was switched on all
selections of the header layout table must be deleted. The header
function (and pushbutton) is not applicable to the TLB view.
See The Header for more information.

The Selector Views

Pushbuttons (Info Objects Area)
Views Selection
Allows the switching on of any specific selector view or all selector
views at the same time. The Selector views Data Views and
Components can be switched off separately with dedicated <close>
pushbuttons located in the respective selector view areas.
Selection Window
The Selection window, also referred to as the data shuffler, is used to
determine the type of master data object that is shown in the info objects
area. The offered selections displayed in the Show field are mainly
Performing

based on the characteristics that are defined in the planning area. An

exception to this is, for example, the possibility to select promotions.
See Selection Window for more information.
Display Dependent
Objects

Display of Objects that Depend on the Current Selection

This function is only visible in connection with planning books based on

SNP planning areas.
Drill Down
The drill down function is only visible in connection with planning
books based on DP planning areas.
Select All
Select all data objects displayed in the info objects area. Use this
function to select data before a planning run. After all data objects are
selected, deselect specific data objects by pressing the <shift> key and
clicking on them.
Deselect All
Deselect all selected data objects in the info object area (hit list).
Previous Selection
Allows the navigation to the previous selection. This function becomes
available only if a new selection is chosen in the selection profile and not
if a new data element in the data info objects area (hit list) was chosen.
The pushbutton is a two-function pushbutton. If pressed on the right side
it displays all previous selections used in the working session of which
one can be selected.
If pressed on the left side the system jumps to the last used selection. The
non-availability of the function is depicted by a faded color scheme.
Next Selection
Allows the navigation to the previous selections (see the explanations
above).
Choose Selection Fields
Press this pushbutton to open the field selection pop-up window, which
allows the definition of fields that are displayed in the info object area
(hit list).
See Field Selection Window for more information.
Performing

Display Current Selection

Displays in a pop-up window the selection table, which displays the rule
defined in the selection window or that of the selection profile used.
Help for the Selector
Displays and explains a variety of pushbuttons and functions of this
transaction.
Selection Profiles
Double-click onto this pushbutton to open the selection profile
maintenance pop-up window. This pop-up window is the same as the one
used in the Selection Maintenance transaction. Refer there for further
information.

Fields (Info Objects Area)

The possible selection of fields displayed in the info objects area (hit list)
depends on the type of data selected in the data shuffler (e.g. products or
resources). Based on the possible selection of fields per data type it is
possible to further restrict the displayed fields.
See Field Selection Window for more information.
Pushbuttons (Data View)
Views Selection
Allows the switching on of any specific selector view or all selector
views at the same time. The Selector views Data Views and
Components can be switched off separately with dedicated <close>
pushbuttons located in the respective selector view areas.
Filter Data Views
The data views displayed in this view can be limited based on various
criteria. Press this pushbutton to define such restrictions.
Own Data Views
Activate this pushbutton to view only own planning books. This option
displays all such planning books that are created by the same person who
logs onto the system (author).
Remove Filer
Removes the data view filters explained above.
Period Structure Settings
Period structure settings determine the planning start data, a possible
offset, and the granularity of the planning periods. All these values are
Performing

defined in the data view but can be changed for the working
session. Refer to Period Structure Settings for more
information.

Close
Use this pushbutton to switch off the data views. Click on the horizontal
bar at the bottom of the selector views and drag it upwards to open this
view again.
Fields (Data View)
The data view shows a tree structure containing planning book names.
The tree structure can be opened to display the data view names and
descriptions of a certain planning book. When entering the SNP
Interactive Planning transaction the last used planning book/data view
combination is opened again.
Open the tree structure and double-click on other data views as required.
Pushbuttons (Components View)
Views Selection

Allows the switching on of any specific selector view or all selector

views at the same time. The Selector views Data Views and
Components can be switched off separately with dedicated <close>
pushbuttons located in the respective selector view areas.
Close
Use this pushbutton to switch off the data views. Click on the horizontal
bar at the bottom of the selector views and drag it upwards to open this
view again.
Fields (Components View)
The components view shows all active macros that are defined for the
opened data view. Macros are grouped into three segments.

Directly Executable
Macros in this group (e.g. macro alerts) can be executed manually
by double-clicking on the macro name.

Default
Macros in this group cannot be executed manually and are only
displayed for reference.

Level Change
Macros in this group cannot be executed manually and are only
displayed for reference.

Start
Macros in this group cannot be executed manually and are only

Performing

displayed for reference.

The Header
The header is displayed with the planning table data views 1 and 2 but not with the TLB view.
Pushbuttons (Header)
Header Information Settings
The header information settings are used to define which data elements
should be shown in the header work area.
See Header Window for more information.
Header Data Pushbutton (Example: Product)
The label of the header data pushbutton depends on the selected data
elements. This is an informative pushbutton and not a functional one.
One or multiple header data pushbuttons exist, each representing one
chosen data element.
Previous / Next Value
These pushbuttons allow scrolling through the work area.
One or multiple sets of these pushbuttons exist, each related to one
chosen data element.

Total / Detail
Use this pushbutton to toggle between the following display options:
Total
Displays the total of all selected data records.
Details (all)
Displays the details of all selected data records and the total. To do
so every key figure is split up into several lines, each line
representing one characteristic (e.g. product) plus one line for the
total.
Single Value
Displays the values of one single characteristic.

The Planning Table Views

The majority of pushbuttons available on top of the planning table views are identical for both the
SNP planning table data view 1 and data view 2. The TLB view has a totally different layout and

Performing

545

an own set of pushbuttons. The DP planning table data view has a reduced set of pushbuttons. The
layout and functionality of the data views as well as the TLB view and the Promotion Planning
view are described separately.

DP Data View

Promotion Planning

SNP Data Views

TLB View
The Alert Monitor Area
Alerts can be displayed by pressing the alert pushbutton. This opens the alert monitor sub screen.
The alert monitor functionality is explained in SDP Alert Monitor.
The Notes Management Area
Activating the context sensitive menu on any cell in the data views and selecting the <Display
Notes> option opens the notes management sub screen. The notes management functionality is
explained in SDP Notes Management.
The Pop-up Windows
Pressing the appropriate pushbuttons can activate a multitude of utility function pop-up windows.
Their respective function is explained in this section.

Header Window
In the header window all such characteristics can be defined that should be visible in the
header work area. Any characteristic of the planning area can be selected. The display type
can be set to be either the characteristic ID or the description.
The functionality behind the definition of a header allows loading not only one data record
(e.g. a product for allocation) but instead a whole range of records (e.g. several products in
several locations). This is also referred to as loading a work area but must not be mistaken
for a work area as used, for example, in the supply chain engineer. After the initial data load,
the various pushbuttons in the header section are used to navigate through the work area.
Single records of the work area as well as totals can be viewed.

Example:
The following is an example to include all products of all locations in the work area
individually, together, or totaled. This task is carried out in the data view 1.
Switch the header on (pushbutton Header On/Off).
Define what should be shown in the header (pushbutton Header Information Settings).
Select location and product as the two characteristics and close the window using the
Adopt pushbutton. The header pushbuttons are visible.
Use the Selection Window pushbutton and select Location Product of a planning
version. Close the window using the Adopt pushbutton.
Use the Select All pushbutton to mark all displayed location products.
Performing

Use the Load Data pushbutton, which loads all selected location products. The grid of
the data view 1 shows the totals of all selected products and locations.
You can now freely navigate in the work area using the Previous Value and Next
Value as well as the Total/Detail pushbuttons in the header section.

Selection Window
In the selection window, also referred to as the data shuffler, the user can select the data that
should be displayed in the info object area (hit list). Selections can also be saved for later use
in selection profiles (see below). In order to select data to be displayed follow these steps:
Select the data object to show in the Show field. Based on which field was selected the
system automatically fills the field that meet the following conditions with all
mandatory condition criteria. This is, at least in most cases, the planning version.
Define one or multiple mandatory condition criteria for the selected data object as
required.
Add own non-mandatory condition criteria if desired. Non-mandatory condition criteria
can be deleted if they are not required/desired anymore. Use the multiple selection
functionality if needed.
Select either Save to save and use the selection or Adopt to just use the selection.
Pushbuttons Selection Window
Save
Save the current selection with a name of free choice. The saved
selection can be used in selection profiles (see below).
Load Selection
Loads a previously defined selection profile so that it can be edited and
possibly saved under the same or new name.
Delete Current Selection
Clears screen
Selection Screen Help
Very basic help on the pushbutton functionality
Adopt
Return to SNP Interactive Planning and load the data in accordance with
details as specified in the selection window.
Cancel
Return to SNP Interactive Planning without selecting any data.
Check Entry
Use this pushbutton to perform a data consistency check.

Performing

Field Selection Window

The field selection pop-up window allows the maintenance of the fields that are displayed in
the info objects area. The available fields differ per selected data object (e.g. product or
resource) and are system predefined. The standard delivered planning book usually displays
all possible fields. Select all such fields that should be displayed by clicking in the box left of
the short text and press the Adopt pushbutton to return to the interactive planning screen.

Period Structure Settings

In this pop-up window the user can change the planning start date and an offset time. The
period structure settings are per data view of a planning book. The planning start date
determines the start date of the time display in the data views and the start of the planning
horizon for the various planning runs (e.g. Heuristics or Optimization). The offset time is the

difference between the displayed start date and the planning start date. In this way the
planning run can start later (further in the future) than the displayed date. The offset time
does not shift the entire planning period but rather cuts the planning period by the number of
periods defined in the Offset field. As a third option a time bucket profile different to the
standard planning book time bucket profile can be selected.
The default period and date settings of the planning book data view are also displayed as a
display-only reference.

Distribution Window
The distribution window permits the distribution of values in the DP and SNP Interactive
Planning transaction. Any field that is open for input can be maintained. Three different
options are available.
Discrete Values
Specify a new discrete value, which is copied into every cell of the key figure.
Operand
Specify an operand (e.g. add or multiply), which is used to manipulate the existing data
in every cell of the key figure.
Distribution Functions
Specify a distribution function (also called time series), which is used to update every
cell of the key figure.
Pushbuttons Distribution Window
Distribute
Closes the distribution window and copies the specified values into the
key figure(s).
Cancel
Closes the distribution window without copying any
data.

Edit Distribution Function

Opens another window that permits the maintenance of distribution
function values and parameters.

Performing

See Distribution Function Maintenance for more information regarding the maintenance of
distribution functions.

5.1.1.1

SDP Interactive Planning SNP Data View

The domain of the SNP Interactive Planning table data views 1 and 2 is the SNP planning task
and the creation of Deployment orders. The graphic below shows a symbolic portion of the SNP
Interactive Planning screen with the data views 1 and 2.

Top Pushbuttons
Data View 1

Data View 2
Details

Product View

Graphic 120 SNP Data Views

The following list explains the pushbuttons placed on top of the data views and the rows of the
SNP Interactive Planning table data views 1 and 2, which provide product related demand and
supply information as well as resource load information. From these views the SNP and
Deployment heuristics planning runs and the SNP Optimizer as well as the capacity leveling are
started.
The Top Pushbuttons
Pushbuttons Planning Table Data Views
Load Data
Load the planning table with data according to the selection in the info
object area (hit list).
Performing

If more than one data object was selected in the info objects area the
system displays the accumulated data of those data objects. In this case
no planning tasks can be carried out nor is a detailed display of cells
possible.
Design Mode
The layout of the planning book and its data views is highly
customizable. Authorization assumed, it is possible to jump directly from
the live planning book into the planning book design and back into the
live planning transaction.
Some of the pushbuttons work in the live and the design mode. The
Save Graphic Setting push button is for use within the Design mode.
Switch Table/Graphic
These pushbuttons are used to switch over the display from table grid to
graphic and back.
Save Graphic Setting
Saves the graphics settings carried out while being in design mode.
Distribute
The activation of this pushbutton opens a pop-up window, which allows
the mass maintenance of all such key figures that permit editing.
See Distribution Window for more
information. Save Locally

Planning results can be locally stored in (Excel) spreadsheets. Select this

pushbutton and specify the target filename on the local PC.
Send
The planning results can easily be sent to other interested parties by
selecting this pushbutton and specifying a SAP Office or any other email address.
Display/Refresh Alerts
This pushbutton is a dual function pushbutton. If pressed on the right
side it allows one to select the areas for which alerts should be displayed
in the alert monitor area.

Alerts for current planning book

Alerts for current version

Alerts for current selection

If pressed on the left side the alert situation is refreshed and alerts are
shown in the alert monitor. For detailed information see SDP Interactive
Planning Alert Monitor.
Alert Monitor Off
Performing

Switches off the alert monitor and the notes management editor sub
screens. Both sub screens can also be switched off individually using the
Close pushbutton located within the respective sub screen.
Display Note (Graphic Selection)
Permits the display of captured notes while being in the graphics mode.
Absolute <=> Percentage
Switch display over from absolute to percentage display and vice versa
Percentage Values (Copy)
The non-availability of the function is depicted by a faded color scheme.
Percentage Values (Paste)
The non-availability of the function is depicted by a faded color scheme.
Key Figure Selection
Allows the switching on of any specific key figure or all key figures at
the same time.
Macro Builder
Macros of the planning book and its data views can be executed in live
mode using this pushbutton (or alternatively from the component view).
Authorization assumed, it also is possible to jump directly from the
planning book (while in design mode) into the macro design and back
into the live planning transaction.
Location Heuristics (view 1 only)
Start the location heuristics planning run. See SNP Heuristics for more
information.
Network Heuristics (view 1 only)

Start the network heuristics planning run. See SNP Heuristics for more
information.
Multi-Level Heuristics (view 1 only)
Start the multi-level heuristics planning run. See SNP Heuristics for
more information.
SNP Optimization (view 1 only)
Start the SNP optimization planning run. See SNP Optimization for
more information.
Deployment Heuristics (view 1 only)
Performing

The Data View 1

The data view 1 provides information per location product. A planning table data view is
composed of one or multiple containers of information. Each of these containers is made up of
a number of key figures. The planning table data view 1 consists of one container only, called the
SNP Plan. The time axis of this view is determined by the planning buckets profile. To view the
start and end dates of any specific period in the data view double-click with the right mouse
button on the column header.
Planning Table Data View (1)
SNP Plan
Provides an overview of the product planning situation. Data is
accumulated according to the time buckets profile. Individual elements
can be view by opening the context sensitive menu on a cell and
selecting the Display Details function.
Forecast
The forecast key figure contains the products forecast key figure as it
was released from Demand Planning. The forecast does not change over
time even if forecast consumption is enabled for the product. The
Forecast key figure is part of the Total Demand key figure.
Sales Order
The sales key figure represents the sales orders and sales order delivery
documents, and other sales related documents. For products without
forecast consumption and within the forecast horizon the Total
Demand equals all those orders that are linked to this key figure.

For products using forecast consumption the sales orders together with
the (remaining) forecast make up the total demand.
Distribution Demand (Planned)
Planned distribution demand is made up of SNP or PP/DS planned
Performing

purchase requisitions.
Distribution Demand (Confirmed)
Confirmed distribution demand is made up of purchase requisitions
confirmed by the Deployment planning step.
Distribution Demand (TLB Confirmed)
TLB confirmed distribution demand is made up of stock transport orders.
Dependent Demand
Dependent demand is all such demand that was created as a result of a
PPM explosion (e.g. for components of a finished product).
Total Demand (summarized display)
The total demand adds up the six demand related key figures listed above
and displays this total quantity. This key figure is not stored data but
dynamically calculated while in the SNP Interactive Planning
transaction.
Total Demand (detailed display)
Double clicking on this key figure name opens the total demand group of
key figures (those described above) and the magnifying glass symbol
changes.
Distribution Receipt (Planned)
Planned distribution receipts are made up of SNP or PP/DS planned
purchase requisitions.
The color change of the key figure cells depicts the end of the products
transportation horizon. The SNP heuristics cannot create orders in this
horizon; the SNP Optimizer can do so if permitted via a user setting.
SNP planned transportation orders can be created by typing in the order
quantity into the appropriate cell (outside the transportation horizon). If
multiple sources are available a pop-up window appears giving the user
the possibility to decide which procurement alternative to use. The
preferred alternative is on top of the list.
Distribution Receipt (Confirmed)
Confirmed distribution receipts are made up of purchase requisitions
confirmed by the Deployment planning step.
Distribution Receipt (TLB Confirmed)
TLB confirmed distribution receipts are made up of stock transport orders.
In Transit
The in-transit key figure shows all those stocks that were issued in the
Performing

issuing plant but not yet received in the receiving plant. This key figure
is only maintained in the case of internal stock transport orders where the
issuing and receiving location are defined in APO.
Production (Planned)
Planned production orders are the SNP or PP/DS planned production
orders before their release.
The color change of the key figure cells depicts the end of the products
production horizon. The SNP heuristics cannot create orders in this
horizon; the SNP Optimizer can do so if permitted via a user setting.
SNP planned production orders can be created by typing in the order
quantity into the appropriate cell (outside the production horizon). If
multiple sources (PPMs) are available a pop-up window appears giving
the user the possibility to decide which PPM to use. The preferred PPM
is on top of the list.
Production (Confirmed)
Confirmed production orders are released production orders including all
those orders currently in process.
Joint Production
In this key figure all such quantities can be seen that refer to co-products
or by-products of released production orders.
Total Demand (summarized display)
The total receipts figure adds up the above seven receipt related key
figures and displays this total quantity. This key figure is not stored data
but dynamically calculated while in the SNP Interactive Planning
transaction.
Total Receipts (detailed display)
Double clicking on this key figure name opens the total demand group of
key figures (those described above) and the magnifying glass symbol
changes.
Stock on Hand
Displays the projected stock on hand at the end of the day.
Backlog
Displays the projected accumulated not satisfied demand from the
current and previous periods. These demands can even be in the past
(before the current date).
The backlog figure does not include any unsatisfied safety stock or target
stock level requirements.
Performing

Safety Days Supply (planned)

This key figure is used to capture and display time dependent safety
days supply values. In order for this function to be carried out, the
product master safety stock method must be set to MZ or MM.

This key figure can usually not be found in the standard delivered
planning book.
Safety Stock (planned)
This key figure is used to capture and display time independent safety
stock values. In order for this function to be carried out, the product
master safety stock method must be set to MB or MM.
Safety Stock
The display of the safety stock depends on the products safety stock
method.
<b>

No safety stock definition exists; no values displayed.

SB

Safety stock as defined in product master (constant over time). The

field is populated automatically based on the product master
definition.

SZ

Calculated based on safety days supply as defined in the product

master and existing demand (variable over time). The field is
populated automatically based on the product master definition
and
the demand.

SM

Displays the greater of the two above (SB or SZ).

MB

Time dependent safety stock as defined in the safety stock

(planned) key figure.

MZ Time dependent safety stock based on the user defined safety

days
supply and the demand.
MM

Displays the greater of the two above (MB or MZ).

AT

Time dependent safety stock values are calculated in the extended

safety stock calculation. This program copies the calculation
results into the key figure safety stock (planned). From there it is
copied across to this key figure.

AS

See above.

BT

See above.

BS

See above.
Reorder Point

The display of the reorder point depends on the products reorder point
procedure.
Performing

Reorder point as defined in product master (constant over time).

The field is populated automatically based on the product master
definition.

Calculated based on reorder days supply as defined in the

product master and existing demand (variable over time). The
field is populated automatically based on the product master
definition and the demand.

Displays the greater of the two above (1 or 2).

Time dependent reorder point.

Time dependent reorder days supply based on the user defined

reorder days supply and the demand.

Displays the greater of the two above (5 or 6).

Options 5 and 6 are not supported in the standard delivered system and
require the definition of an additional key figure.
Target Days Supply
This key figure is used to capture and display time dependent target
days supply values. In order for this function to be carried out, the
product master target stock method must be set to 1 or 3.
Target Stock Level (planned)
This key figure is used to capture and display time independent target
stock values. In order for this function to be carried out, the product
master target stock method must be set to 2 or 3.
This key figure can usually not be found in the standard delivered
planning book.
Target Stock Level
The display of the target stock level depends on the products target
stock level method.
<_> Calculated based on target days supply as defined in the product
master and existing demand (variable over time). The field is
populated automatically based on the product master definition
and the demand.
1

Time dependent target stock based on the user defined target

days supply and the demand.

Time dependent target stock as defined in the target stock

(planned) key figure.

Displays the greater of the two above (1 or 2).

Displayed is the Product Storage Capacity as defined in the

product master (constant over time). The field is populated

Performing

556

automatically based on the product master definition and the

demand.
5

Maximum of options <b> and 4.

Sum of options <b> and 4.

No target stock level definition exists; no values displayed.

Days Supply

The days supply figure displays the number of days before running out of
stock. The days supply figure can never be higher than the number of
days left between the displayed date and the end of the planning period,
as the system does not see the demands outside the planning horizon. The
last day of the planning horizon always has a days supply of Zero,
although it might be higher (not lower). When displaying in weekly
columns, the days supply figure refers to the last day of the week. The
days supply figure is always displayed irrespective of whether the target
stock level method is used or not.
The days supply is always displayed irrespective of whether the target
days supply method is used or not.
ATD Receipts
Displays the sum of all receipts that are relevant to Deployment/TLB.
Various ATP categories are grouped in a category group, which in turn is
linked to a location master as the ATR setting. The category group
ATR is also used if no specific category group is defined in the location
master.
ATD Issues
Displays the sum of all requirements that are relevant to
Deployment/TLB. Various ATP categories are grouped in a category
group, which in turn is linked to a location master as the ATI setting.
The category group ATI is also used if no specific category group is
defined in the location master.
Open the context sensitive menu on any demand or supply key figure element (e.g. a planned
distribution receipt order quantity at a specific date) and select one of the available options.

Fix Cell
The fix cell option is only applicable to data stored in time streams and not to order based
data storage as used in SNP. This option is thus not functional.

Unfix
This option is not functional (see above).

Display Note
Opens the notes management sub screen at the bottom of the planning table. Close this sub
screen within the notes management sub screen or using a pushbutton on top of the planning
table.

Display Details
Obtain information of the orders that make up the total order quantity displayed in the cell.
Performing

The Graphics in the Data View 1

Key figures displayed in the data view 1 can also be displayed in graphical format. Which key
figures are displayed in the graphic is defined as part of the planning book design. The user can
further reduce (but not increase) the number of key figures in the graphic.
The features and functionalities of graphical displays as used in the data view 1 are explained in
Advanced Graphical Display.
The Data View 2
The data view 1 provides information per resource. A planning table data view is composed of
one or multiple containers of information. Each of these containers is made up of a number of
key figures. The planning table data view 2 consists of two containers, called the Capacity Plan
and the Quantity View. The time axis of this view is determined by the planning buckets profile.
To view the start and end dates of any specific period in the data view double-click with the right
mouse button on the column header.
Planning Table Data View (2)
Capacity Plan
Provides an overview of the resource-loading (capacity) situation.
Capacity load data is accumulated according to the time buckets profile.
The resource capacity and respective load is shown in the resources
capacity unit of measure.
Capacity (summarized display)
The capacity displayed here is the resources valid capacity in the
respective periods. The valid capacity can be the standard capacity or
one of the capacity variants. This key figure is not stored data but
dynamically calculated while in the SNP Interactive Planning
transaction.
Capacity (detailed display)
Double clicking on the key figure name displays the available capacity
separately for the resource variant 1 and 2 (described below) and the
magnifying glass symbol changes. If the available capacity of the
resource is not equal to one of the displayed capacity variants displayed
below then the standard capacity is the valid capacity.
Available Capacity of Variant 1
Displays the available capacity of the resource as defined in the capacity
variant 1.
Available Capacity of Variant 2
Performing

Displays the available capacity of the resource as defined in the capacity

variant 2.
Capacity Consumption
Displays the total consumed capacity of the resources valid capacity (as
shown in the key figure capacity) of the period.
Resource Load

The resulting resource load is the ratio between the capacity

consumption and the available capacity. Red cells indicate loads of 100%
or more in the period.
Quantity View
Provides a quantity-based overview of the resource-loading (capacity)
situation. Data is accumulated according to the time buckets profile. This
display uses the planning area unit of measure.
The key figures described below are displayed depending on their
resource category.
Production Quantity (Total)
This key figure accumulates all production orders, such confirmed
(released) and such only planned.
This key figure is only visible for resources with the resource category
P for production.
Production Quantity (Planned)
This key figure accumulates all such production orders that are SNP or
PP/DS planned but not released yet. This refers to the orders displayed in
the key figure planned production of the data view 1.
This key figure is only visible for resources with the resource category
P for production.
Distribution Receipt Quantity (Total)
This key figure accumulates all distribution orders, such that are already
transportation orders (after TLB run) and such that are still SNP or
Deployment planned requisitions.
This key figure is only visible for resources with the resource category
T for transportation.
Distribution Receipt Quantity (Planned)
This key figure accumulates all such distribution orders that are SNP or
Deployment planned but not picked up by TLB yet. This refers to the
orders displayed in the key figures distribution demand planned and
Performing

distribution demand confirmed of the data view 1.

This key figure is only visible for resources with the resource category
T for transportation.
Handling Quantity
This key figure accumulates handling requirements of all such orders
that require a goods receipt or issue. In the product master different
resources can be defined for the handling requirements of goods issue
and goods receipt.
This key figure is only visible for resources with the resource category
H for handling.
Storage Quantity

This key figure displays the load of the storage resource at the end of the
period. It is a carried forward balance of initial load plus goods receipts
minus goods issues.
This key figure is only visible for resources with the resource category
S for storage.
The Graphics in the Data View 2
Key figures displayed in the data view 2 can also be displayed in graphical format. The graphic
can be generated per data container (i.e. one for the capacity plan and one for the quantity view).
Which key figures are displayed in the graphics is defined as part of the planning book design.
The user can further reduce (but not increase) the number of key figures per graphic.
The features and functionalities of graphical displays as used in the data view 1 are explained in
Advanced Graphical Display.
The Details Area
The details area is only used with the planning table data view 1. In this area details of the
selected cell are displayed. If the cell is, for example. displaying the planned production orders of
a day, the details area displays all planned production orders that make up the total as displayed in
the cell. The quantities displayed in the details area can be changed. This changes the order
quantity.
Pushbuttons (Details Area)
Close
Use this pushbutton to close the details area screen.
Fields (Details Area)
Order Number

Performing

560

Displays the order number of the displayed element. The order number
displayed for SNP orders is created by the R/3 system and corresponds to
the R/3 planned order.
Quantity
The order quantity in the products base unit of measure.
Category
The (technical) order category of the order.
Location
The location from which the product is sourced. This is the selected
location products for production orders or another location in the case of
transportation orders.
Date and Time
The order receipt date and time.
Fixed and Stat
Technical information relating to the order.

The Product View

The Product View transaction can be started and displayed in the same place as the Detail Area.
Only one of the two can be displayed at any given time. To open the Product View activate the
context sensitive menu on a product line in the Info Objects Area and select the appropriate
function. See Product View for more information.
How To Work with the Data View
Carry out these easy to follow steps in order to perform SNP planning tasks.

Select SNP (Transportation or Production) Orders

Double click on a location product as required. Once the information regarding a specific
location product is displayed in the planning table, select one of the following options.

Create SNP (Transportation or Production)

Orders Choose one of the following procedures:
Create SNP Orders automatically
SNP orders can be created automatically using the various heuristics procedures or the
SNP optimizer. Select the appropriate method.
Create SNP Transportation Orders manually without reference
SNP planned transportation orders can be created manually by typing in the desired
quantity into the cell of the required period of the planned transportation order key figure.
This will open a pop-up window, which allows selecting a source of supply and

Performing

561

transportation method, if multiple options exist. Source of supply and transportation

method is added automatically if no choice exists.
Create SNP Production Orders manually without reference
SNP planned production orders can be created manually by typing in the desired quantity
into the cell of the required period of the planned production order key figure. This will
open a pop-up window, which allows selecting a source of supply (PPM) if multiple
options exist. The source of supply is added automatically if no choice exists.
If an order already exists for the day (i.e. a quantity is visible in the cell), it will be deleted
and replaced by the new order for the total quantity. This means that it is not possible to
manually add a second SNP planned order. The quantities can also be captured or updated in
the Details Area.

Change SNP (Transportation or Production) Orders

Only the quantity of an SNP order can be changed.

Change SNP Order

Select the cell containing the order to be changed and overwrite the quantity as required.
If several orders exist and should be kept separate (i.e. the orders have different sources
of supply) then the change must be carried out in the Details Area.

Delete SNP (Transportation or Production) Orders

Delete SNP Order
Select the cell containing the order to be deleted and overwrite the quantity with Zero (do
not just delete the quantity and do not use the <Space> bar).
If several orders exist and must not all be deleted, then open the Details Area and delete
selectively.

Other Functions
Select from the options bar one of the following:

Edit
Macro
Displays all macros that can be run interactively by the user and allows them to be
carried out.

Settings
Forecast Profile
This is a DP specific function.
Historical Key Figure
This is a DP specific function.
Forecast Key Figure
This is a DP specific function.
Header Information
Provides the same information as the pushbutton with the same name.
Assign Alert Profile
Use this option to assign a forecast, supply and demand planning, and/or TLB profile to
the own user ID.
Row Totals

Performing

562

This function enables the display of an additional column, which shows per row the total
of all periods. This function although working within SNP and DP is more meaningful in
DP where it can be used to add up, for example, the forecast figures over the planning
period.
Go To
Initial Information
Provides some administrative information (selected planning area, planning object
structure, planning book, and data view.
Lock Entries
Displays locked data objects (lock entries) and users locking the data.
Key Figure Overview
Shows for a selected key figure all values per planning period in a list headed by the total
for the key figure over the period.
Forecast Comparison
This is a DP specific function.

5.1.1.2

SDP Interactive Planning TLB Data View

The SNP Interactive Planning table TLB view has a distinctly different layout compared to the SNP
Interactive Planning table data views 1 and 2. Besides the fact that it looks different, using it is also
different and the screen is not as flexible in terms of the customization possibilities. The domain of the
SNP Interactive Planning table TLB view is in the area of TLB and Deployment. The graphic below
shows a symbolic portion of the SNP Interactive Planning screen with the TLB views.

The TLB view uses the selection IDs based on the planning area that was used when switching
over to the TLB view. The selection IDs in the selection profile are planning area dependent.
Other than that the TLB view is independent of any planning area.

Top Pushbuttons
TLB View

Graphic 121 TLB Data View

The following list explains the rows of the SNP Interactive Planning table TLB view, which is
providing transportation lane related Deployment and TLB order information. From this view the
TLB planning run is started.
Performing

The Top Pushbuttons

Pushbuttons TLB View

Refresh Orders
Refreshes the display of orders. In order to see any alerts based on a
changed planning situation it is required to save the planning result. A
refresh alone is not sufficient.
Display Attributes
Two groups of attributes can be set per user ID.

Highlight
Important Orders (Priority <= 10)
Set this flag to display all such transportation orders with a
deployment order priority of 10 or lower. This option is only
meaningful if deployment order prioritization is used. Do not
set it in other situations, as all orders will be highlighted.
Overload
Set this flag to highlight overload situations. An overload
condition is detected when the quantity of the transport order
exceeds any upper limit of the TLB profile.
Overload situations can be highlighted
corresponding alert type is not activated.

even

if

the

Underload
Set this flag to highlight situations with less than desired
capacity load. An underload condition is detected when the
quantity of the transport order exceeds all lower limits of the
TLB profile.
Underload situations can be highlighted
corresponding alert type is not activated.

even

if

the

Invalid Scheduling
Set this flag to highlight situations where an invalid scheduling
was carried out.
Invalid scheduling situations can be highlighted even if the
corresponding alert type is not activated.

Alerts
TLB Alert profile
Displays the user allocated TLB alert profile. Define the alert

Performing

profile using the Settings function.

Alert of Transportation Lane Flag
Switch this flag on to view alerts in the alert monitor area at the
bottom of the screen.
TLB Parameters
In the TLB parameter window the planning start and end dates are
displayed and can be changed. The TLB profile, which is attached to the

selected transportation lane is also displayed. It can be changed in the

transportation lane master data maintenance transaction.
Start TLB
Starts the interactive TLB run for the planning period as defined above.
See TLB Heuristics for more information.
Create TLB Shipment
Creates new transportation orders without referring to existing
transportation recommendations, by selecting this pushbutton in the
transportation order panel.
Delete TLB Shipment
Deletes the TLB shipment that is selected in the transportation order
panel.
Send Order Directly to OLTP System
Transmits the TLB shipment that is selected in the transportation order
panel directly to the connected OLTP system if the system is configured
to transmit TLB shipments periodically (i.e. not immediately).
The button is only visible if the system is set to transmit TLB shipments
periodically, and the selected planning version is the active planning
version (000).
Display Graphic
Use this pushbutton to generate a standard graphic for the displayed
transportation orders. The graphic displays the absolute and percentage
load in terms of volume, weight, and number of pallets per order. This
function requires that a TLB profile be attached to the used
transportation method.
Graphical displays as used in the TLB view are explained in Standard
Graphical Display.
Create Transfer Order Item
Select this pushbutton in the order item panel to create new
transportation order items for existing transportation orders, without
referring to existing transportation recommendations.

Performing

565

The TLB View

The TLB view provides information per transportation method of a transportation lane. It is
divided into three panels, which can be resized relatively to each other in vertical and horizontal
directions. The panels provide different types of information and functionality. The use of the
context sensitive menus also depends on the respective panel from where they are activated.

Transport Recommendations
Displays the transportation recommendations (deployment orders) for the selected
transportation lane and method. Open the context sensitive menu anywhere on a
transportation recommendation (deployment order), and select one of the available options.
To Transportation Orders (entire quantity)
Select this option to manually pick up a transportation recommendation and convert it to
a transportation order.
To Transportation Orders (partial quantity)
Select this option to manually pick up a transportation recommendation and convert a
partial quantity of it into a transportation order.
Change Source/Means of Transport
Select this option to manually change the source location and/or transportation method of
a transportation recommendation.

Transportation Orders
Displays the transportation orders (TLB orders) for the selected transportation lane and
method. Open the context sensitive menu anywhere on a transportation order (TLB order) and
select one of the available options.
To Recommendations
Select this option to manually pick up an entire transportation order and convert it (back)
to a transportation recommendation(s).
Delete Transportation Order
Select this option to manually delete an entire transportation order.
Double click on any of the transportation order lines to view the transportation order items in
the bottom panel.

Order Items
Displays the transportation order items of the selected transportation order. Open the context
sensitive menu anywhere on a transportation order item and select one of the available
options.
To Recommendations
Select this option to manually pick up a transportation order item and convert it (back) to
a transportation recommendation.
Delete Item
Select this option to manually delete a transportation order item.
Each of these panels contains various fields in a grid format. Use the standard list display tools to
customize these lists as required. See List Display Tools for further information.
Other Functions
Settings:
Assign Alert Profile

Performing

566

Use this option to assign a forecast, supply and demand planning, and/or TLB profile to the
own user ID.
Display Attributes
Provides the same functionality as the pushbutton with the same name (see above).
TLB Parameters
Provides the same functionality as the pushbutton with the same name (see above).

How To Work with the TLB View

Carry out these easy to follow steps in order to perform TLB planning tasks.

Select TLB (Transportation) Orders

Double click on a transportation lane selection ID as required. Transportation lanes are then
displayed in the top left section of the screen, based on the conditions specified when saving
the selection ID.
Once transportation lanes are displayed in the data shuffler (with a separate line per
transportation method), select the one for detailed display in the grid.
Double click on one transportation lane/method line and all transportation orders are
displayed in the upper left section of the planning table. The transportation
recommendations appear in the grid on the upper far right hand side of the screen.
Double click on a specific transportation order, and all transportation order items for the
selected transportation order are displayed on the lower right hand side of the screen.

Create TLB (Transport) Orders

Note that it is possible to have more than one line per TLB (transport) order. Choose one of
the following procedures:
Create TLB Orders automatically
TLB orders can be created automatically for all displayed transportation
recommendations by pressing the <Start TLB> pushbutton. The process then creates TLB
orders with subordinate order items considering all relevant settings (e.g. the TLB
profile)
Create TLB orders manually based on a Deployment Order
Choose a transportation recommendation and activate the context sensitive menu on it.
Then select either <To Transport Order (Entire Quantity)> or <To Transport Order
(Partial Quantity)>.
Include all Parent Reels or Finished Products that were deleted previously. Note that the
TLB run does not attempt to utilize partially loaded transport builds. It will therefore
never try to combine new and existing loads.
Create TLB orders manually without reference to a Deployment Order
TLB orders can be created manually by pressing the <Create Transfer Order>
pushbutton. The process then displays a pop-up window allowing the specification of
product, quantity, and delivery date/time. A manually created TLB order consists
(initially) of exactly one order item.

Change TLB (Transport) Orders

The source of supply as well as the transportation method of a TLB order can be changed.
Change Source of Supply

Performing

567

Select a transportation order and activate the context sensitive menu on it. Then select
<Change Source/Means of Transport>.
Change Transportation Method
Select a transportation order and activate the context sensitive menu on it. Then select
<Change Source/Means of Transport>.

Delete TLB (Transport) Orders

While deleting TLB orders, they can either be completely deleted or sent back (converted) to
Transport recommendations (Deployment Orders). Choose one of the following procedures:
Delete TLB Order without generating a Deployment Order
Select a transportation order and activate the context sensitive menu on it. Then select
<Delete Transport Order>.
Delete TLB Order while generating a Deployment Order
Select a transportation order and activate the context sensitive menu on it. Then select
<To Recommendations>. In this case the TLB order is deleted, but one or multiple
deployment orders are created with the same details as the deleted TLB order. One
deployment order is created per TLB order item.

Create TLB (Transport) Order Items

This process can only be performed once a TLB order with at least one order item exists.
Choose one of the following procedures:
Create TLB order item manually
TLB order items can be created manually by pressing the <Create Item> pushbutton. The
process then displays a pop-up window allowing the specification of product and
quantity.

Delete TLB (Transport) Order Items

While deleting TLB order items they can either be completely deleted or sent back
(converted) to Transport recommendations (Deployment Orders). Once all items of a TLB
order are deleted, the TLB order is deleted automatically by the system. Choose one of the
following procedures:
Delete TLB Order Item without generating a Deployment Order
Select a transportation order item and activate the context sensitive menu on it. Then
select <Delete Item>.
Delete TLB Order Item while generating a Deployment Order
Select a transportation order item and activate the context sensitive menu on it. Then
select <To Recommendations>. In this case the TLB order item is deleted but exactly one
deployment order is created with the same details as the deleted TLB order.

5.1.1.3

SDP Interactive Planning Alert Monitor

The alert monitor area is a sub screen of various interactive transactions in the DP and SNP
application areas. This sub screen is identical to the alert list panel of the alert monitor transaction.
See Alert Monitor for more information.
Performing

5.1.1.4

SDP Interactive Planning Notes Management

The notes management area is a sub screen of various interactive transactions in the DP and SNP
application areas. Notes are managed in the notes editor. They are created and attached to a cell in
the interactive planning screen. Each cell is related to a key figure and a certain period.
Notes Creation Procedure
Follow the steps below to create or edit a note while being in the DP or SNP Interactive Planning
screen.

Select any cell that is open for editing and activate the context sensitive menu, then choose
Display Note.

The notes management sub screen will be opened. In this sub screen the system
automatically displays the key figure and the period to which the cell belongs (e.g. 9ASHIP
on 02.01.01). This information can be overtyped.

Capture the notes text and press the Save Note pushbutton.

Close the notes management sub screen. Any cell to which a note was attached is colorcoded and displays a symbol on the left side.
Pushbuttons
Close
Use this pushbutton to close the notes management sub screen.
Save Note
Saves the note without closing the notes editor.
Delete Note
Deletes the note without closing the notes editor. The system
automatically displays the key figure again and the period to which the
cell belongs.
View
With this pushbutton the status line and/or toolbar of the notes editor can
be switched on and off.
Display Note Hierarchy
This pushbutton opens another sub screen next to the notes management
sub screen, which displays the note hierarchy. Select any notes in the
note hierarchy tree structure as required and display/edit it.
Display Note Info
This pushbutton opens a pop-up window, which allows the capturing of a
title for the note.

Performing

569

Load Local File

Notes can also be captured by means of uploading local files from a PC.
Those files should only contain text information, as the notes editor stores
data as text only.
Save as Local File
Opens the Save As window with which the note can be saved locally as
a file.

5.1.1.5

SDP Interactive Planning Heuristics

The SNP Heuristics can be run in an interactive mode using the SNP Interactive Planning
transaction and in batch mode. In both cases the planning run is a regenerative run, which first of
all deletes all orders in the planning horizon, and then creates new ones where required. When
running the SNP heuristics in batch mode it can also be set to the net change mode where only
such products are re-planned that are flagged for re-planning. The re-planning flag is set
automatically by the system when required.
SNP Heuristics Run
Follow the steps below to carry out an SNP heuristics run.
Select the location product(s) for which the SNP run should be carried out. This is done in the
info objects area. In order to view location products in the info objects area, either use the
Selection Window pushbutton or select a predefined selection profile.

Select one of the following pushbuttons:

Location
This option plans a product at the selected location only. If the product is required from
another location via a transportation order, this order will be created but not planned for
at the sourcing location. Should a PPM explosion be carried out during the creation of a
planned production order the dependent demands are created but not planned for.
Network
This option plans the selected product at all locations where it is defined, irrespective of
which location is selected in the info objects area. Should a PPM explosion be carried out
during the creation of a planned production order at any location, the dependent demands
are created but not planned for.
Multi-Level
This option plans the selected product at all locations where it is defined, irrespective of
which location is selected in the info objects area. Should a PPM explosion be carried out
during the creation of a planned production order at any location, the dependent demands
are created and also planned for.

A message on the bottom of the screen appears at the end of the planning run providing
information about how many location-products were planned. This figure is always 1 with the
Location option.

Performing

5.1.1.6

570

SDP Interactive Planning Capacity Leveling

Capacity leveling is an interactive activity that is usually carried out as a follow-up task of the
SNP heuristics planning run. This is required, as the heuristics run assumes indefinite capacities.
After the completion of the heuristics run, the planner must level the capacity to make the plan
feasible. In case of a capacity overload situation, an alert can be generated, warning the planner.
No further support is provided from the heuristics run for capacity leveling purposes. Capacity
leveling can be achieved by shifting orders backward or forward, to overcome usage peaks and
better usage of resource idling time. Alternatively the available capacity can be adjusted in the
resource master. The graphic below provides an overview of the possibilities and work steps.

L e v e lin g M e th o d

Graphic 122 Capacity Leveling Work Steps

Capacity Leveling Procedure
Follow the steps below to carry out the capacity leveling.
Select the resource for which the capacity leveling has to be carried out in the SNP Interactive
Planning data view 2. This is done in the info objects area. In order to view resources in the
info objects area either use the Selection Window pushbutton or select a predefined
selection profile.

Press the Capacity Leveling pushbutton.

On the upcoming screen select one of the options

1. Capacity Leveling by Backward Scheduling

Performing

571

With this capacity-leveling variant, the system tries to satisfy high priority demand by
shifting it to an earlier date. This obviously does not constitute an order due date
violation.
2. Capacity Leveling by Forward Scheduling
Low priority demand can probably be shifted further into the future, thus causing a due
date violation.
3. Capacity Leveling by Backward/Forward Scheduling
This is a combination of the two variants as described above.
4. Capacity Leveling by Capacity Adjustment
The system switches over to the resource maintenance screen. Note that the maintenance
is carried out in the planning version according to the SNP Interactive Planning screen.
The next pop-up window is displayed when one of the options 1 through to 3 above was
selected.
Decreasing (Increasing) Order Quantity
Level such planned production orders first that have the highest (lowest) order
quantity. Decreasing (Increasing) Coverage (Days Supply)
Level such planned production orders first that have the highest (lowest)
coverage. Decreasing (Increasing) Product Priority
Level such planned production orders first that have the highest (lowest) product priority.
The product priority is defined in the product master per location.
Without Capacity Leveling Rule
If no priority rule is defined, the sequence is by random.
The last pop-up window determines the
following: Maximum Load as a Percentage
The maximum load for the resource can be specified in the form of a percentage. In
situations where the resource consumption is fluctuating very much over time but mostly
below the capacity limits, set the maximum load to lower than 100%. This will smooth
the capacity usage.
Ignore Firmed Quantities
Set this flag only if capacity leveling is allowed to move firmed planned production
orders.
Firm Resulting Quantities
Set this flag if the planned production orders should be firmed after capacity leveling
took place.

Note that while the capacity leveling shifts orders as specified by the user, dependent demands are
shifted accordingly. Orders of dependent demands are not shifted accordingly, and require manual
attention.

5.1.1.7

SDP Interactive Planning Optimization

The SNP Optimization can be run in an interactive mode using the SNP Interactive Planning
transaction and in batch. In both cases the planning run is a regenerative run, which first of all
deletes all orders in the planning horizon, and then creates new ones where required.
SNP Optimization Run
Performing

Follow the steps below to carry out an SNP Optimization run.

Select the location product(s) for which the SNP optimization should be carried out. This is
done in the info objects area. In order to view location products in the info objects area,
either use the Selection Window pushbutton or select a predefined selection profile.
Select the SNP Optimizer pushbutton.
The SNP Optimizer pop-up window is displayed. The layout of this window is described
further down.
Select the Execute pushbutton.
View the progress of the optimization run as messages appear in the top message box.
View the results of the optimization run in the bottom message box.
Each message in this box can be viewed individually in detail after selecting it.
The last message in the bottom box is the All Messages line. Select this message to
open the Display Logs transaction.
View the graphical and grid display of the optimization run.
Select the Back pushbutton to update the planning situation in the SNP Interactive
Planning table or Cancel to return to it without updating.
After returning to the SNP Interactive Planning transaction it is required to save the planning
result before leaving the transaction or choosing another selection.

The SNP Optimizer Pop-up Window

The SNP Optimizer pop-up window has a common message area and two tabs, which are the
Configuration tab and the Solution tab. The pushbuttons, which are visible at the bottom of the
window work from either tab.

Progress Message Box Area

The system writes progress messages into this box while carrying out the optimization run.

Results Message Box Area

The system writes messages at the end of the optimization run into this area. Click on any
message to see more detailed information.
Pushbuttons Optimizer Pop-up Window
Back to SNP Interactive Planning
Return to the SNP Interactive Planning transaction while transferring the
results of the optimization run to the planning table.
Execute Optimization
Start the optimization run.
View Selected Products
Displays the selected location products in a pop-up window.
View Solutions
Activate this pushbutton to restrict the displayed selections visible on the
Solutions tab.

Performing

573

Delete Selections
Opens the Optimization Resulting Cost transaction.
Display Log File
Opens the Optimizer Log File transaction.
Cancel Optimization
Return to the SNP Interactive Planning table without saving the results of
the optimization run.
Save Optimization Profile
The Save action changes the parameters of the optimization profile so
that they can be used in subsequent optimization runs.
Maintain Optimization Profile
Permits changing of the optimization profile parameters. The changed
parameters are used during the optimization run whether they are saved
or not.
Save Cost Profile
The Save action changes the parameters of the cost profile so that they
can be used in subsequent optimization runs. The cost profile parameters
are changed in a graphical way by using the cost parameter sliders.
Maintain Optimization Bound Profile
Permits changing of the optimization bound profile parameters. The
changed parameters are used during the optimization run. They can be
saved directly in the optimization bound profile maintenance transaction.
The Configuration Tab
On the configuration tab all controls can be found that influence the way the optimization run will
be performed. The tab is grouped into various areas.

Parameter Settings
In the parameter settings area the optimization, cost, and optimization bound profile that are
used for the optimization run, are displayed. The usage of an optimization bound profile is not
mandatory. The optimization profile and the optimization bound profile can be changed by
pressing the respective maintain profile pushbutton. Moving the cost sliders in the cost
multiplier adjustment area up or down changes the cost parameters.

Cost Multipliers Overview

This area is an information display area. Select any of the cost multipliers to receive more
information about it. Cost multipliers are numbered from P1 through to P11 and refer to
optimization costs C1 through to C11.

Cost Multipliers Adjustment

Performing

574

Change the cost multipliers by moving the cost sliders up and down. This changes the relative
importance of the cost multipliers towards each other. Changing all cost multipliers from 1 to
2 would for example not change the impact on the optimization run at all. The relative
importance is depicted in the circle above the sliders.
The Solutions Tab
Various information about the last (or any other previous) optimization run is displayed on the
solution tab. The tab is grouped into various areas.

Parameter Overview
In this area some background information for the selected optimization run is given. The
Scale Cost function changes the scale of the graphical cost display.

Graphical Results
The cost elements are numbered C1 through to C11 and refer to the cost multipliers P1
through to P11.

Tabular Results
The tabular result area displays the overall cost of the optimization run as well as all cost
components that make up the overall cost. The table is sorted from cost parameter 1 on the
left to 11 on the right.
Use the View Selections pushbutton to display another set of optimization resulting costs in the
grid and graphic.

5.1.1.8

SDP Interactive Planning Deployment Heuristics

The Deployment Heuristics can be run in an interactive mode using the SNP Interactive Planning
transaction and in batch mode. The Deployment Optimizer can only be started in background
mode.
Deployment Heuristics Run
Follow the steps below to carry out a deployment heuristics run.
Select the location product(s) for which the deployment run should be carried out. This is
done in the info objects area. In order to view location products in the info objects area, either
use the Selection Window pushbutton or select a predefined selection profile. Note that the
deployment run requires that the location from which the deployment takes place needs to be
defined (source location), and not the target location.

Verify the deployment settings

Press the Deployment Settings pushbutton to open a pop-up window allowing the
maintenance of the following settings:
Deployment Horizon
The Deployment Horizon is defined in calendar days. Any Deployment Horizon value
that is greater then the horizon defined in the Time Buckets Profile for Demand
Planning and Supply Network Planning is capped to the value as defined in the Time
Buckets Profile. The Time Buckets Profile for Demand Planning and Supply Network
Planning

Performing

575

determines the number of periods displayed in the SNP Interactive Planning screen. This
setting affects the display as well as all performed calculations. Demand and Supply
elements outside the Time Buckets Profile for Demand Planning and Supply Network
Planning cannot be taken into account by the Deployment calculations.
Procedure
This switch allows setting the Deployment mode to either Real time or to Refer to last
SNP run. The Real time option uses requirements at the target location at the time of the
Deployment run, and not the existing SNP planned order(s). The real demand might be
higher or lower than the SNP planned order demand(s). If the option Refer to last SNP
run is chosen, the system only checks for existing SNP planned orders for distribution,
and converts those orders to deployment orders that are within the deployment horizon.
Run Deployment
Pressing the Deployment pushbutton starts the deployment heuristics for the selected
location product.

5.1.1.9

SDP Interactive Planning Transport Load Builder

The Transport Load Builder (TLB), which is a heuristic planning tool, can be run in an interactive
mode using the SDP Interactive Planning transaction or in batch.
Transport Load Builder Run
Follow the steps below to carry out a TLB run.
Select the transportation lane and method for which the TLB run should be carried out for.
This is done in the info objects area. In order to view transportation lane/method
combinations in the info objects area either use the Selection Window pushbutton or select
a predefined selection profile. Note that the TLB run is carried out per transportation method
of a transportation lane. The allocation of source location and/or transportation method can be
changed manually but not automatically by the TLB run.

Verify the TLB parameters

Press the TLB Parameters pushbutton to open a pop-up window allowing the monitoring
and maintenance of the following parameters:

Planning Start and End Date

Review the start and end date.

TLB Profile Limits

The TLB profile, which is attached to the selected transportation lane is displayed only. It
can be changed in the transportation lane master data maintenance transaction only.
Run TLB
Pressing the TLB pushbutton starts the TLB run for the selected transportation lane and
method.

5.1.1.10

SDP Interactive Planning DP Data View

Performing

576

The domain of the DP Interactive Planning table is to support the forecasting task and related
activities like promotion planning. Unlike the SNP Interactive Planning table, which is in most
cases very similar for all APO installations, the DP Interactive Planning table is usually created
specifically according to the business requirements. The DP Interactive Planning table displays the
key figures that are required to carry out the forecasting tasks in accordance with the enterprises
very specific requirements. This includes not only the displayed key figures, but also the time axis
display (time granularity). This section describes the SAP delivered planning book
9ADP_BASIC as an example of a possible layout. The functional pushbuttons are usually the
same for all installations nevertheless, but with an individual installation some pushbuttons might
not be visible.
The fact whether data is stored in liveCache or in an InfoCube is transparent to the user. Any key
figures stored in an InfoCube can be displayed, but neither be created or updated. The key figures
of the planning area as well as any calculated rows that are visible in the planning book can also
be displayed graphically.
The graphic below shows a symbolic portion of the DP Interactive Planning screen with the table
view.

Top Pushbuttons
Data View
Graphics

Graphic 123 DP Data View

This screen appears to be rather simple and indeed there is not too much to it when it comes to
everyday planning (forecasting). The real planners workbench is the view that opens when
starting one of the forecasting runs interactively. The system then switches over to a completely
new view providing an array of information. The provided information depends on the selected
forecast method. These views are explained in separate sections.
The following list explains the pushbuttons placed on top of the data views and the rows of the DP
Interactive Planning table data view.
The Top Pushbuttons
Performing

Pushbuttons Planning Table Data View

Load Data

Load the planning table with data according to the selection in the info
object area (hit list).
If more than one data object was selected in the info objects area, the
system display the accumulated data of those data objects. In this case no
planning tasks can be carried out nor is a detailed display of cells
possible.
Design Mode
The layout of the planning book and its data views is highly
customizable. Authorization assumed, it is possible to jump directly from
the live planning book into the planning book design and back into the
live planning transaction.
Some of the pushbuttons are working in the live and the design mode.
The Save Graphic Setting push button is for use within the Design
mode.
Switch Table/Graphic
These pushbuttons are used to switch over the display from table grid to
graphic and back. Depending on the planning book design, it is also
possible to view graphic and table information simultaneously.
Save Graphic Setting
Saves the graphics settings carried out while being in design mode.
Distribute
The activation of this pushbutton opens a pop-up window, which allows
the mass maintenance of all such key figures that permit editing.
See Distribution Window for more
information. Save Locally
Planning results can be locally stored in (Excel) spreadsheets. Select this
pushbutton and specify the target filename on the local PC.
Send
The planning results can be easily sent to other interested parties by
selecting this pushbutton and specifying a SAP Office or any other email address.
Display/Refresh Alerts
This pushbutton is a two-function pushbutton. If pressed on the right side
it allows selecting the areas for which alerts should be displayed in the
alert monitor area.

Performing

578

Alerts for current planning book

Alerts for current planning version
Alerts for current data selection

If pressed on the left side the alert situation is refreshed and alerts
are shown in the alert monitor. For detailed information see SDP
Interactive Planning Alert Monitor.
Alert Monitor Off
Switches off the alert monitor and the notes management editor sub
screens. Both sub screens can also be switched off individually using the
Close pushbutton located within the respective sub screen.
Display Note (Graphic Selection)
Permits the display of captured notes while being in the graphics mode.
Absolute <=> Percentage
Switch display over from absolute to percentage display and vice versa
Percentage Values (Copy)
The non-availability of the function is depicted by a faded color scheme.
Percentage Values (Paste)
The non-availability of the function is depicted by a faded color scheme.
Key Figure Selection
Allows the switching on of any specific key figure or all key figures at the
same time.
Macro Builder
Macros of the planning book and its data views can be executed in live
mode using this pushbutton (or alternatively from the component view).
Authorization assumed, it also is possible to jump directly from the
planning book (while in design mode) into the macro design and back into
the live planning transaction.
The Data View
The data view provides information per characteristic value combination. The definition of these
characteristic value combinations as well as the associated key figures depends on the individual
installation. This section describes the SAP delivered planning book 9ADP_ BASIC as an
example of a possible layout. In order to understand the rational behind each button it is required
to examine the underlying planning area definitions as well as the forecast profiles associated with
it. The example delivered by SAP does not show any key figures for historical data. The time axis
of
Performing

this view is determined by the planning buckets profile. To view the start and end dates of any
specific period in the data view double-click with the right mouse button on the column header.
Planning Table Data View

Forecast (Stat 1)
Contains the base forecast that was derived from historical data. As
mentioned before the SAP delivered planning book does not display any
historical data key figure. Besides this, the forecast data key figure flow
from this point onwards is consistently visible.
Promotion 1
Used to sore the actual promotions as defined in the Promotion View.
Manual Correction
Permits the planer to adjust the plan by capturing positive values
(increase forecast) or negative values (decrease forecast.
Total Forecast
The Total Forecast is a summarization key figure of the three key figures
described above. Summarization is carried out by means of a user
defined macro.
VMI Demand
Defines the total demand of all VMI customers. These key figures could
for example be captured directly here, be derived from other planning
book key figures, or transmitted from an external source,
VMI Promotions
The same as above for the VMI promotion demand.
Dependent Demand
There might be known dependent demand from production that is shown
in this key figure. Dependent demand can be calculated using the DPBOM functionality.
Total Demand Plan
The total demand plan is again a summarization key figure adding up the
total forecast and the key figures above. Summarization is carried out by
means of a user defined macro.
Planned Price
This is the planned selling price per unit.
Sales Forecast
This is the estimated turnover based on the total demand and the planned
price. It is calculated by means of a user defined macro.

Performing

580

Forecast (Stat 2)
This key figure could be used for example to hold a second system
generated forecast.
Promotion 2
As above for a promotion.
Open the context sensitive menu on any key figure element (e.g. a Total Forecast quantity at a
specific period) and select one of the available options.

Fix Cell
The fix cell option allows the fixing of a value. Fixed values are not changed during
disaggregation of data.

Unfix
Reverse the above action.

Display Note
Opens the notes management sub screen at the bottom of the planning table. Close this sub
screen within the notes management sub screen or using a pushbutton on top of the planning
table.

Display Details
The display details option is only applicable to discreetly stored data (i.e. orders in SNP). This
option is thus not functional.
The Graphical View
Key figures displayed in the data view can also be displayed in graphical format. Which key
figures are displayed in the graphic is defined as part of the planning book design. The user can
further reduce (but not increase) the number of key figures in the graphic compared to those being
defined in the planning book.
The features and functionalities of graphical displays, as used in the data view, are explained in
Advanced Graphical Display.
The graphical display appears to be distorted when using telescopic time buckets profiles. With
telescopic time bucket profiles more than periodicity is used (e.g. month and week). In such a case
the graphical display shows data per month and per week using the same axis, which then distorts
the key figures appearance. Let me give an example. The historical data is shown in months for
the months 24 through to month 13 and than in weeks from the month 12 through to month 1.
Assuming a constant history (sales) of 1,700 per month the graphical display will show for the 12
months further away sales of this 1,700. Then in the middle of the graph, the values are per week
and consequently the graph drops to about 400 per week (1700 divided by approximately 4.25). It
appears that sales have dropped but they have not.
Forecast Comparison
A common task in interactive forecasting is the repeated run of the forecast with different
parameters. In order to judge the quality of the various forecast versions, it is required to have an
Performing

easy to read comparison list. This is implemented in APO by means of the Compare Versions
(or also called Forecast Comparison) transaction. This transaction can be called from the main

DP data view or from any one of the forecast views (e.g. the univariate view). In all cases a new
session is opened and the Compare Versions transaction started.
The term Version or Forecast Version relates to a specific version of a forecast and not to the
planning version. Within the same planning version several forecast might have been run for the
same (characteristics) selection. Each of them represents an own version. The data of the forecast
versions are stored even if the forecast result was not saved. The reason for that is that the
forecast version data represents the forecast parameters, error values, and some administrative
data but not the forecast values as such. Once the forecast version with the best results was
determined, the planner should run the forecast again (with the appropriate parameters) and
finally save the forecast values.
Note that the forecast version with the highest number is the most recent!
The transaction displays three tabs, which are explained in detail.
Pushbuttons Forecast Comparison
Delete Versions
Switches over to a new screen that permits the deletion of forecast
versions. Use this function with utmost care, as it deletes maybe more
than wanted and without warning.
Create Profile
Select a row representing a specific forecast version and press this
pushbutton. Then specify a profile name on the upcoming pop-up
window to create a new master profile. This master profile will inherit all
parameters of this specific forecast version.
All Compare Versions Tabs
Planning Area
Specify the planning area
Key Figure
Specify the key figure into which the forecast is written.
Version
Specify the planning version
Selection
Specify the selection criteria
Forecast Error Tab
Performing

Maximum Number of Versions

APO standard is to save 10 versions of a forecast. Change this value if required
and save.
Forecast Error
Always press this pushbutton first after all data has been defined in the
header section and before any of the other pushbuttons on top of the grid.

As a result all known forecast version are displayed with the list sorted
by forecast version ascending.
Selection ID
Select a row and press this pushbutton to obtain information about the
used selection ID.
MAPE
Press this pushbutton to highlight the MAPE column and sort it ascending.
All other forecast error pushbuttons work accordingly!
Parameter Tab
Parameter
Always press this pushbutton first after all data has been defined in the
header section.
The parameter tab shows close to all parameters that are used in
forecasting.
No functions other than displaying the parameters are available.
Changes Tab
Changes
Always press this pushbutton first after all data has been defined in the
header section.
The changes tab shows administrative information regarding the forecast
runs. This is the same information that is displayed for example on top of
the forecast grid after an interactive forecast run.
No functions other than displaying the parameters are available.

Other Functions
Select from the options bar one of the following:
Edit
Performing

Execute Macro
Displays all macros that can be run interactively by the user and allows them to be
carried out.
Settings
Forecast Profile
Forecast (master) profiles are allocated to planning areas or to the combination of
planning area and selection ID. Use this function to view and possibly change this
assignment. The assignments can also be maintained in the Maintain Forecast Profile
transaction.
Historical Key Figure
Display and possibly change the allocated key figure for historical data as specified in
the respective forecast profile. Use this function to temporarily read data from another
key figure.
Forecast Key Figure

Display and possibly change the allocated key figure for forecast data as specified in the
respective forecast profile. Use this function to temporarily write data to another key
figure.
Header Information
Provides the same information as the pushbutton with the same name.
Assign Alert Profile
Use this option to assign a forecast, supply and demand planning, and/or TLB profile to
the own user ID.
Row Totals
This function enables the display of an additional column, which shows per row the total
of all periods. It can be used to add up for example the historical data or forecast values
over the entire planning period.
Goto
Initial Information
Provides some administrative information (selected planning area, planning object
structure, planning book, and data view).
Lock Entries
Displays locked data objects (lock entries) and which users are locking the data.
Key Figure Overview
Shows for a selected key figure all values per planning period in a list headed by the
total for the key figure over the period.

5.1.1.10.1

SDP Interactive Planning DP Univariate View

When starting an interactive forecasting run, the system switches over to one of three views
depending on the chosen method. The univariate view is explained here.
The Univariate View is activated by selecting the Univariate Forecast Stat pushbutton. The
view is divided into an upper half that displays data in either table or graphical format, and a
lower half with various tabs displaying forecasting parameters and/or alerts. The display of
parameters and alerts in the lower part can be switched off.
The graphic below shows a symbolic portion of the Univariate View.
Performing

TopPushbuttons
DataView

Al erts

Graphic 124 Univariate View

Pushbuttons Univariate View
Switch Shutter On/Off
Select this pushbutton to entirely close the selector view in order to
maximize the planning table view. Press this pushbutton again to display
both the planning table and the selector view.
Run Univariate Forecast
Carries out a univariate forecast.
Forecast Comparison
Opens another transaction in a new window that is used to compare
various forecasts. See the separate section Compare Versions for more
detailed information.
The same transaction can be called by using Goto > Forecast
Comparison (Ctrl+F2).
Limits
Displays the defined error limits of the diagnosis group attached to the
used univariate profile (if any is attached).
Show Hide Table
This pushbutton is a toggle key to switch over from table to graphical
display and vice versa.
Performing

Alerts On/Off
This pushbutton is a toggle key to switch the alert display on and off. For
detailed information see SDP Interactive Planning Alert Monitor.
Parameters On/Off
This pushbutton is a toggle key to switch the parameter tabs on and off.
Phase-In/Out
Opens a pop-up window that allows linking and/or editing a phase-in and
a phase-out profile to the current selection. This button does not appear if
the basic life cycle settings were not carried out for the planning area
(see Forecast Profiles).
Extreme Left, First Column
Positions the grid display to the first column of the available data (the
first period of the historical data).
Column Left, Previous Year
Positions the grid display to the first column of the previous year
(historical or forecast data).
Column Right, Next Year
Positions the grid display to the first column of the next year (historical
or forecast data).
Extreme Right, Last Column

Positions the grid display to the last column of the available data (the last
period of the forecast data).
The grid layout of the univariate view depends to some extent on customization settings.
Examples are the display of the corrected history and forecast that might be active or not. The
following description refers to a typical layout, but not to the only one possible.
Grid Univariate View
Forecast
Displays the baseline forecast prior to possible workday correction.
Historical Data
Displays the historical data, which is already a variation of the original
historical data (called historical input) in cases where life cycle
management corrections are applied.
Corrected History
Displays the corrected history. The corrected history is based on the
Performing

historical data, but possibly adjusted by outlier and workday

correction.

Ex-Post Forecast
Displays the ex-post forecast
Corrected Forecast
Displays the corrected forecast. The corrected forecast is abased on the
forecast but possibly adjusted by workday correction.
Season
Displays the seasonal indices (factors) per period. For non-seasonal
models this value defaults to 1.
Trend
Displays the trend value or is left blank for models without a defined
trend value.
Basic Value
Displays the basic value or is left blank for models without a defined
basic value.
<Time Series>
Other time series data can be displayed in the grid by double-clicking on
the time series name in the Time Series tab.

Univariate View Tab Profile

Forecast Profiles
Displays the profiles that were used when carrying out the forecast. Note that it
is possible to change virtually all parameters that are defined in the forecast
profiles during the interactive planning.
The profile names displayed here refer to the profiles and their
settings/parameters that were used for the initial forecast.
Master Profile

 Univariate Profile
MLR Profile
Composite

Forecast

Profile Profile Transactions

Save Master Profile
Updates the selected master and other forecast profiles in accordance
with the settings/parameters defined in the Interactive Planning
transaction.
Delete Master Profile
Performing

Deletes the selected master forecast profile.

Univariate View Tab Model
Type of Forecast Model
Displays the applied forecast model. Depending on the selected forecast group
and/or model, the parameters tab displays different fields that are used to
further refine the model
Constant Models
Group 10 (Forecast Model 11, 12, 13, or 14)
Croston Method
Group 80 (Forecast Model 80)
Auto Mode Selection 1
Group 50 (Forecast Model 51, 52, 53, 54, or 55)
Auto Mode Selection 2
Group 50 (Forecast Model 56)
Trend Models
Group 20 (Forecast Model 21, 22, or 23)
Linear Regression
Group 94 (Forecast Model 94)
Seasonal Trend Model
Group 40 (Forecast Model 40 or 41)
Season + Linear Regression
Group 30 (Forecast Model 35)
Seasonal Models
Group 30 (Forecast Model 31)
Manual Forecasting
Group 70 (Forecast Model 70)
History

Group 60 (Forecast Model 60)

External Forecast
Group 99 (Forecast Model 99)
Run Univariate Forecast
Performing

Carries out a univariate forecast.

Univariate View Tab Horizon
Periodicity: Period
The phrase Period is replaced in a live planning environment by the period
that is defined in the master forecast profile. It represents the granularity of the
forecasting calculation.
Select either intervals defined using a from and to date, or the number of
periods to be used.
Period Intervals
Select the intervals, and the system calculates the respective number of periods.
Do not capture any values for the Offset figures.
Forecast From and To
Historical Data From and
To Number of Periods
Define the number of periods, and the system automatically calculates the dates
starting with the current period as the first forecast period. Offset values can be
defined for both periods using positive (shift into the future) or negative (shift
into the past) numbers.
Forecast Periods and Offset
Historical Periods and Offset
Univariate View Tab Parameters
You have chosen the .. model
The chosen model determines the parameters that are displayed on this tab.
Refer to the univariate forecast profile for further information on the displayed
fields and flags.
Univariate View Tab Forecast Errors
Choose Forecast Errors
Displays the names of the selected forecast errors, and allows further additional
selections or de-selections.
Display Forecast Errors
Displays the forecast errors values. A warning triangle is displayed behind each
value if the forecast errors exceed the limits defined in the diagnosis group.
Univariate View Tab Settings
Performing

Various Sub Titles

Displays various settings mainly taken from the univariate forecast profile.
Change as and when required.
Univariate View Tab Messages
Forecast Messages
Provides various messages with variable degrees of usefulness.
When running an automatic selection model, this tab displays the forecast
model that was determined to be the best fit.
Univariate View Tab Time Series
On this tab all existing time series possibly applicable to univariate forecasts are listed.
Double-clicking on any will show their values in the grid displayed on the upper half of
the screen. Activate the context sensitive menu on any time series name to edit or
delete the time series.

5.1.1.10.2

SDP Interactive Planning DP MLR View

When starting an interactive forecasting run, the system switches over to one of three views
depending on the chosen method. The Multiple linear Regression (MLR) view is explained here.
The MLR View is activated by selecting the MLR pushbutton. The view is initially presented as
one large grid that displays data in either table or graphical format. As an option, the forecasting
alerts can be displayed on the bottom of the screen.
The graphic below shows a symbolic portion of the MLR View.
Performing

Graphic 125 MLR View

Pushbuttons MLR View
Switch Shutter On/Off
Select this pushbutton to entirely close the selector view in order to
maximize the planning table view. Press this pushbutton again to display
both the planning table and the selector view.
Run MLR Forecast
Carries out a Multiple Linear regression based forecast.
Forecast Comparison
Opens another transaction in a new window that is used to compare
various forecasts. See the separate section Compare Versions for more
detailed information.
The same transaction can be called by using Goto > Forecast
Comparison (Ctrl+F2).
Limits

Displays the defined limits of the MLR diagnosis group attached to the
used MLR profile (if any is attached). Limits of the diagnosis group can
be changed temporarily or permanently (by saving the group).
Information
Displays the forecast messages of the last MLR based forecast run.
Profile
Displays the used MLR profile. Other profiles can be selected without
this having an impact of the MLR profile that is attached to the master
forecast profile.
Show Hide Table
This pushbutton is a toggle key to switch over from table to graphical
display and vice versa.
Alerts On/Off
This pushbutton is a toggle key to switch the alert display on and off. For
detailed information see SDP Interactive Planning Alert Monitor.
Parameters On/Off
This pushbutton is a toggle key to switch the MLR parameter
information cells on and off. The MLR parameters are displayed in the
top left section of the grid shifting the other time related information to
the side. Parameters that exceed the limits defined in the MLR Diagnosis
Group are
Performing

displayed with an alert symbol next to it. See also Limits above.
The grid layout of the MLR view depends to some extent on customization settings. The grid also
contains some additional pushbuttons. The following description refers to a typical layout but not
to the only one possible.
Pushbuttons MLR Grid
Key Figure

Display Dummy Variable

Edit Dummy Variable
Data
Initialize
Carries out a Multiple Linear regression based forecast.

5.1.1.10.3

SDP Interactive Planning DP Composite View

When starting an interactive forecasting run, the system switches over to one of three views
depending on the chosen method. The Composite view is explained here.
The Composite View is activated by selecting the Composite pushbutton. The view is initially
presented as one large grid that displays data in either table or graphical format. As an option, the
forecasting alerts can be displayed on the bottom of the screen.
The graphic below shows a symbolic portion of the Composite View.
Performing

Graphic 126 Composite View

Pushbuttons Composite View
Switch Shutter On/Off
Select this pushbutton to entirely close the selector view in order to
maximize the planning table view. Press this pushbutton again to display
both the planning table and the selector view.
Run Composite Forecast
Carries out a univariate forecast.
Forecast Comparison
Opens another transaction in a new window that is used to compare
various forecasts. See the separate section Compare Versions for more
detailed information.
The same transaction can be called by using Goto > Forecast
Comparison (Ctrl+F2).
Information
Displays the forecast messages of the last Composite based forecast run.
Profile
Displays the used Composite profile. Other profiles can be selected
without this having an impact on the Composite profile that is attached to
the master forecast profile.
Show Hide Table

This pushbutton is a toggle key to switch over from table to graphical

display and vice versa.
Performing

Alerts On/Off
This pushbutton is a toggle key to switch the alert display on and off. For
detailed information see SDP Interactive Planning Alert Monitor.
The grid layout of the Composite view depends to some extent on customization settings. The
following description refers to a typical layout, but not to the only one possible.
Grid Composite View
Forecast
Displays the calculated Composite forecast based on the Univariate
and/or MLR forecast defined in the Composite profile.
Composite Ex-Post
Displays the ex-post forecast based on the composite forecast result.
Univariate Forecast Result
The Composite forecast is made up of one or multiple Univariate and or
MLR forecasts. The univariate forecast is based on a specific univariate
profile, which is linked to the composite forecast profile. The name(s) of
the used univariate forecast profile(s) is displayed here with the
corresponding forecast result.
None, one, or multiple univariate forecast based results can be displayed.
Each row carries the name of the used univariate profile.
The shown label is an example using the profile name
up01 MLR Forecast Result
See above, but for MLR based forecast.
The shown label is an example using the profile name mlr01

5.1.1.11

SDP Interactive Planning Promotion View

The SDP Interactive Planning Promotion View has a distinctly different layout compared to the
SDP Interactive Planning DP View. Besides the fact that it looks different, using it is also different
and the screen is not as flexible in terms of the customization possibilities. The domain of the
SDP Interactive Planning Promotion View is in the area of the Promotion Planning. The graphic
below shows a symbolic portion of the SDP Interactive Planning Promotion View.
Performing

Top Pushbuttons

Grid

Graphic 127 SDP Interactive Planning Promotion View

The following list explains the functionality of the SDP Interactive Planning Promotion View.
The Top Pushbuttons
Some of the buttons explained below are only (or not) visible when switching the Object View
to the Analyze History mode.
Pushbuttons Promotion Planning View
Switch Shutter On/Off
Select this pushbutton to entirely close the selector view in order to
maximize the planning table view. Press this pushbutton again to display
both the planning table and the selector view.
Interactive Planning
Press this pushbutton to return form the Promotion view to the main DP
view. Do not use the Back button, as this will throw you out of
transaction.
Assign Objects
Load objects of the appropriate characteristic (as defined in the
promotion level setting) into the data shuffler and press this pushbutton.
This will assign the objects (e.g. products) to the promotion.
Performing

To reverse an assignment use the Exclude Characteristics Values

pushbutton.

Delete Promotion
Select a promotion in the Info Object Area (Data Shuffler) and use this
pushbutton to delete an entire promotion.
Create Promotion
Use this pushbutton to create a new promotion. Once the creation
process was started, there is no other way to abort it but leaving the
transaction.

Finish the creation activity by saving the

data. Promotion
Use this pushbutton to switch over from one promotion to the other or to
view a summarized display of all promotions.
Object
Use this pushbutton to switch between promotion object views. See
Object Views for more information.
Change Status
Change the status of a promotion. The status of the promotion also
changes the traffic light indicator in the data shuffler. Following options
exist:
D

Draft (yellow)

Offered to Customer (yellow)

C Confirmed by Customer (yellow) R

Rejected by Customer (yellow) A Active
in Current Period (green) P Planned in
the Future (green)
F

Expired in the Past (green)

The current status of the promotion is indicated in the drop down list of
this button (gray shaded).
Exclude Characteristics Values
Deletes the assignment of a characteristic (object) to a promotion. At
least one object must be left assigned to a promotion.
Copy Promotion
Copies entire promotions.
Distribution Function

Performing

596

The activation of this pushbutton opens a pop-up window, which allows

the mass maintenance of all such key figures that permit editing. It can
also be used to copy data from a promotion pattern time series.
Save Grid/Graphics Setting
Saves the graphics settings carried out while being in design mode.
Switch Parameters On/Off
This pushbutton is a toggle key to switch the parameter tabs on and off.
Save Locally
Planning results can be locally stored in (Excel) spreadsheets. Select this
pushbutton and specify the target filename on the local PC.
Send Messages
The planning results can be easily sent to other interested parties by
selecting this pushbutton and specifying a SAP Office or any other e-mail
address.
Pattern (only Analyze History)
In step one, select one or multiple columns and then Calculate
Promotion Pattern.
Then in the second step select one promotion pattern row and then Save
as a Pattern. This opens a time series pop-up window in which the time
series can be named (and adjusted).
Use Change Analysis Period to define a period.
Analysis Method (only Analyze History)
The default algorithm for calculating the promotion pattern is the Linear
Regression. Use this pushbutton to switch over to a Linear Regression
plus Seasons and define the number of periods in a season.
Do not forget to recalculate the pattern after this!

Object Views
The objects displayed in the promotion planning data grid depend on the selected view. The active
view is depicted by the view name that is gray shaded. Be aware that gray shading also means that
a specific view is not available for the selected promotion. The following object views exist.

Promotion Data
Displays the promotion quantity per promoted product and period as well as the promotion
totals per period and overall. All data is in absolute figures. This view is only available for
promotions that are defined in absolute figures (i.e. not as percentages).

Planning Data
Performing

Displays the baseline forecast and promotion key figures for each product included in the
promotion as well as the totals per period and overall. The Increase in Percentage is the
only field open for editing. The captured percentage per period is applied to all products of
the promotion. Percentages cannot be defined individually per product.

Pre-Evaluation
The Pre-Evaluation view provides various fields used to carry out a rough valuation of the
promotion. For a detailed explanation of the used key figure refer to the section Promotion
Planning.
Post-Evaluation
Provides the same functionality as the Pre-Evaluation view but can only be selected for an
expired promotion (status F).
Analyze History
When activating this view, it is required to define the start of the period that should be
analyzed. The end date of the analysis period is automatically set to the current date. The
view provides information about the baseline forecast and the ex-post forecast estimation.
This ex-post forecast estimation is calculated whenever switching over to this view. The
assumption is that any difference between this ex-post forecast estimation and the baseline
forecast can be contributed to the promotion and thus the difference is copied into the
Promotion Pattern. The promotion pattern can be recalculated and saved in a time stream.

Fields Promotion Planning Promotion Tab

Name (Display only)
Define a Promotion Name.
No changes possible after initial creation.
Description
Define a Promotion
Description Status (Display only)
Displays the status of the promotion.
Only promotions with a status of P (planned, in future) and A
(active) are visible in the DP planning environment. As long as a
promotion has any other status its promotion values are not copied into
the Promotion Key Figure (see below), even if they are visible during
promotion planning. Setting the promotion is done by means of a
dedicated pushbutton (see above).
Type (Display only)
Select whether the promotion is defined in absolute values or as a
percentage. This determines also whether the promotion key figure is
ready for input and the Increase in Percentage row display only or vice
versa.
No changes possible after initial
creation. Unit (Display only)
Performing

The base unit of measure of the planning

area. Check Cannibalization Group (Display only)
Link a cannibalization group to the promotion if
required. No changes possible after initial creation.
Changes only by Author
Set this flag to ensure that only the author, who is displayed behind the
flag, can change the promotion.

Fields Promotion Planning Period Tab

Periodicity
Select the periodicity of the promotion. Only such periodicities that are
defined for the planning area in the storage buckets profile are shown
and can be selected.
Number of Periods
Define the number of promotion periods in accordance with the
periodicity setting above.
Also determine the promotion start date. The system potentially adjusts
the start date (e.g. weekly periodicity and data is not reflecting a
Monday). The end date is then calculated automatically.
In-Depot Period
The optional definition of the In-Depot Period breaks the overall
promotion period as defined above into two periods, the In-Depot Period
and the In-Store Period. The In-Store Period is the remaining number of
periods after the In-Depot Period has been subtracted from the overall
number of promotion periods.
Buy-In Period
The optional definition of the Buy-In Period breaks the overall
promotion period as defined above into two periods, the Buy-In Period
and the In-Store Period. The In-Store Period is the remaining number of
periods after the Buy-In Period has been subtracted from the overall
number of promotion periods.
In-Store Period
See above for further explanation. The definition of these figures has no
implications on the promotion functionality and calculations.
If both fields, the In-Depot Period and Buy-In Period are maintained,
then the In-Store Period is the amount of periods left after subtracting the
In-Depot Period and Buy-In Period from the overall number of
promotion periods.
Performing

If neither are maintained the In-Store Period is displayed as Zero.

Fields Promotion Planning Attributes Tab
Type
Up to 10 attribute types can be defined per system (transaction Maintain
Promotion Attributes). All defined attribute types are displayed here.
Value
For each promotion and attribute type a value can be allocated. Each new
value for an attribute type is automatically included in subsequent
Possible Entries F4 queries.
Fields Promotion Planning Notes Tab
See the section SDP Interactive Planning Notes Management
Fields Promotion Planning Planning Area Tab

Planning Area (Display only)

Displays the planning area the planning book is based
on. Planning Version (Display only)
Displays the planning version that was selected when retrieving the data
in the data shuffler.
Promotion Key Figure
Select the key figure into which the promotion values have to be written
into. The field defaults to a setting carried out in the Maintain
Promotion Level transaction.
Changing this key figure is possible but might overwrite data that is
already in the key figure be careful!
Planning Key Figure
Define the key figure that contains the base forecast before adding the
promotion values. Changing this key figure has an immediate effect
when maintaining promotions that are defined as an percentage increase
(i.e. not absolute).
Promotion Level (Display only)
Select the characteristics that determines the promotion level. This is the
level on which promotion values are saved.
The field shows the setting as defined in the Maintain Promotion Level
transaction.
Post-Promotion Key Figure

Performing

600

Other Functions

Settings > Unit of Measure

Set the units of measure to that of the planning area, the products base unit of measure, or
one freely defined.
Settings > Number of Decimals
Set the number of decimals from any value between 0 (default) and 9.

5.1.2

Promotion Planning Interactive Planning

Calling the Promotion Planning transaction via the menu structure is another way of starting the
SDP Interactive Planning transaction. It provides the same functionality but permits the user to
directly access the Promotion Planning view. From there it is possible to switch forward and
backward to the SDP Interactive Planning and Promotion Planning screens.
The Promotion Planning view uses the selection IDs based on the planning area used when
starting the Promotion Planning transaction. The selection IDs in the selection profile are
planning area dependent.
When opening the Promotion Planning transaction directly from the tree structure, the system uses
the planning area 9ADP01, which subsequently cannot be changed. Subsequently the user is
locked into this planning area with its specific selection IDs. Using the Assign User to Planning
Book transaction, it is possible to link the Promotion Planning transaction to any other default
planning area (but only one at any time per user). To do so add an entry with the appropriate user
ID and the transaction code /SAPAPO/MP34. Then allocate a planning book and data view that
is attached to the planning area that should be used when starting the Promotion Planning
transaction. The defined planning book and adapt view will also be used when switching over to
the SDP Interactive Planning screen. The flag settings in the profile are of no significance for this
definition.
The Transaction
Path:
Technical Name:

Demand Planning > Planning > Promotion >Promotion Planning

/SAPAPO/MP34

For further information select SDP Interactive Planning and SDP Interactive Planning
Promotion View.

5.1.3

TLB Interactive Planning

Performing

601

The Transport Load Builder transaction is a limited functionality SDP Interactive Planning
transaction. It provides similar functionality but is limited to the TLB view of the SDP Interactive
Planning transaction.
The TLB view uses the selection IDs based on the planning area used when switching over to the
TLB screen. The selection IDs in the selection profile are planning area dependent. Other than
that the TLB screen is independent of any specific planning area.
When opening the TLB transaction directly from the tree structure, the system uses the planning
area 9ASNP94, which cannot be changed once in the transaction. Subsequently the user is locked
into this planning area with its specific selection IDs. Using the Assign User to Planning Book
transaction, it is possible to link the TLB transaction to any other default planning area (but only
one at any time per user). To do so add an entry with the appropriate user ID and the transaction
code /SAPAPO/SNPTLB. Then allocate a planning book and data view that is attached to the
planning area that should be used when starting the TLB Interactive Planning. The flag settings are
of no significance for this definition.
The Transaction
Path:

Supply Network Planning > Planning > Transport Load Builder

(TLB)

Technical Name:

/SAPAPO/SNPTLB

In order to perform a task in the Transport Load Builder transaction it is required to select the data
environment. The data environment defines the individual data objects (transportation lanes and
methods).
For further information select SDP Interactive Planning and SDP Interactive Planning Table
TLB View.
Performing

5.2

Background Transactions

The majority of background transactions require the same data environment as the interactive
transactions. The definition of these data environments can be based on the same selection ID as
used in the accompanying interactive planning transaction. Background transactions can also be
scheduled to run at predefined times or events.
Some functionality can only be used in background transactions (e.g. the extended safety stock
calculation). There are also some transactions that are required to enable certain functions (e.g.
release of the unconstrained forecast to SNP).

5.2.1

SNP Heuristics

The SNP Heuristic can be run in an interactive mode using the SNP Interactive Planning
transaction and in batch.

The Transaction
Path:

Supply Network Planning > Planning > Supply Network Planning in

the Background > Supply Network Planning in the Background

Technical Name:

/SAPAPO/SNP01

The initial screen requires the definition of various parameters, mandatory and optional ones.
This needs to be done every time the transaction is called. In order to reuse the same set of
parameters various times, it is possible to save a set of data (after defining it once) in a variant. In
consecutive calls of the same transaction, this saved set of data can be called up again, and altered
if required. After data has been changed the variant can be updated if required to reflect the
changed data. See Variant Maintenance for more information.
A batch run can be executed immediately or scheduled to be run at certain predefined times and
intervals. View the section SNP Scheduled Background Transactions.
Application Bar Pushbuttons
Execute
Executes the planning run.
Variant
Selects a previously saved variant to populate all required input fields for
the batch run.
Save
Performing

Saves captured data in a variant (see Variant Maintenance).

Input Fields and Flags
Planning Version
Stipulate the planning version as required (000 is the active planning
version).
Product
Define one or multiple products. Products can be defined individually or
as ranges. The normal selection features are available. See Multiple
Selections for more information.
Level ID
The level ID is an optional entry and serves as a filter as to which
products are planned. First maintain the location product hierarchy and
assign a level ID to each hierarchy level. The planning run will then only
pick up location products in the planning run of the defined level or
lower.
Planning Book
Stipulate the planning book as required (9ASNP94 in standard delivered
system).
Data View
Stipulate the data view of the planning book as required (SNP94(1) in
standard delivered system).
Horizon in Days

Define the planning horizon in days starting on the current

day. Multi-Level (Heuristic) Flag
With this option set, the system plans the selected product at all locations
where it is defined irrespective which location is selected in the info
objects area. Should a PPM explosion be carried out during the creation
of a planned production order at any location the dependent demands are
created and also planned for.
Network (Heuristic) Flag
With this option set, the system plans the selected product at all locations
where it is defined irrespective which location is selected in the info
objects area. Should a PPM explosion be carried out during the creation
of a planned production order at any location the dependent demands are
created but not planned for separately.
Location (Heuristic) Flag
With this option set, the system plans a product at the selected location
only. If the product is required from another location via a transportation
order this order will be created but not planned for at the sourcing
location. Should a PPM explosion be carried out during the creation of a
planned

Performing

604

production order the dependent demands are created but not planned for
separately.
Location
Define the location(s) included in the planning run. The definition of a
location is only required when running the location heuristics. The
network and multi-level heuristics always plan in all locations of a
product.
Products can be defined individually or as ranges. The normal selection
features are available. See Multiple Selections for more information.
Net Change Flag
The SNP Heuristics is a regenerative planning algorithm. This means that
at the beginning of the planning run all orders, in this case SNP planned
orders, are deleted. In a second step new SNP planned orders are created.
If only a net-change planning run is required the Net Change flag must
be switched on. In this case only such products that are required to be replanned are part of the planning run. The system keeps track of all
products that require re-planning by means of a planning file entry.
Various programs update this planning file whenever a change to a
product was carried out that potentially requires re-planning. Such
changes include for example changes in demand or supply but also some
master data updates.
Log Flag
The log file provides an overview of all created SNP orders.

5.2.2

SNP Optimization

The SNP Optimizer can be run in an interactive mode using the SNP Interactive Planning
transaction and in batch.
The Transaction
Path:

Supply Network Planning > Planning > Supply Network Planning in

the Background > Supply Network Optimization

Technical Name:

/SAPAPO/SNPOP

The initial screen requires the definition of various parameters, mandatory and optional ones. This
needs to be done every time the transaction is called. In order to reuse the same set of parameters
various times, it is possible to save a set of data (after defining it once) in a variant. In consecutive
calls of the same transaction, this saved set of data can be called up again, and altered if required.
After data has been changed the variant can be updated if required to reflect the changed data. See
Variant Maintenance for more information.
Performing

A batch run can be executed immediately or scheduled to be run at certain predefined times and
intervals. View the section SNP Scheduled Background Transactions.

Application Bar Pushbuttons

Execute
Executes the planning run.
Variant
Selects a previously saved variant to populate all required input fields for
the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags
Planning Book
Stipulate the planning book as required (9ASNP94 in the standard
delivered system).
Data View
Stipulate the data view of the planning book as required (SNP94(1) in
the standard delivered system).
Selection Profile Flag
Activate the Selection Profile flag and define a selection profile.
The data environment for the SNP optimization can be defined via a
selection ID or manually. The selection profiles that can be used here are
the same as those defined in the SNP Interactive Planning transaction.
These selections are unique per planning area. A display button shows
the selection definition if required.
Manual Selection Flag
Activate the Manual Selection flag and define the four upcoming fields.

Planning Version

Level ID

Product Range

Location Range
Planning Start and End Date
When using the SNP Optimizer the planning start date does not have to
be the current date. Define here the required planning start and end date.
Profiles
Select an SNP optimization, cost, and optionally an optimization bound
Performing

profile.

Optimizer Profile

Cost Profile

Optimization Bound Profile

The definition of the optimization bound profile is optional.
Modify Quota Arrangements
The SNP optimizer can create/update the quota arrangements per period
based on the found optimized solution. These quota arrangements could
be used for example for consequent heuristics planning runs in the same
period.

Quotas are created for all such periods where demand and supply
elements where present during the optimization run. They are updated
with every run and have the same granularity as the planning profile. If
the granularity is e.g. week then the same quota is applied to all days of
the week. A week without any demand would not have any quota on any
day.
Note that the created/updated quota arrangements are planning version
specific and created for the same planning version in which the
optimization was carried out.

5.2.3

Deployment Heuristics

The Deployment Heuristic can be run in an interactive mode using the SNP Interactive Planning
transaction and in batch. The Real-Time Deployment can only be started in batch.
The Transaction
Path:

Supply Network Planning > Planning > Supply Network Planning in

the Background > Deployment

Technical Name:

/SAPAPO/SNP02

The initial screen requires the definition of various parameters, mandatory and optional ones.
This needs to be done every time the transaction is called. In order to reuse the same set of
parameters various times, it is possible to save a set of data (after defining it once) in a variant. In
consecutive calls of the same transaction, this saved set of data can be called up again, and altered
if required. After data has been changed the variant can be updated if required to reflect the
changed data. See Variant Maintenance for more information.
A batch run can be executed immediately or scheduled to be run at certain predefined times and
intervals. View the section SNP Scheduled Background Transactions.
Application Bar Pushbuttons
Execute
Performing

Executes the planning run.

Variant
Selects a previously saved variant to populate all required input fields for
the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags
Planning Version
Stipulate the planning version as required (000 is the active planning
version).
Planning Book
Stipulate the planning book as required (9ASNP94 in the standard
delivered system).

Data View
Stipulate the data view of the planning book as required (SNP94(1) in
the standard delivered system).
Location
Define the Deploy from Location. The entry of a Deploy from
Location is mandatory if the Real Time Deployment flag is not set.
Real Time Deployment can also be run for a specific target location and
thus does not necessarily require a source location.
Product
Define one or multiple products to deploy. Products can be defined
individually or as ranges. The normal selection features are available.
Deployment Horizon
The Deployment Horizon (part of Deployment Settings in Interactive
Planning) is defined in calendar days although only working days are
displayed. Any Deployment Horizon value that is greater then the
horizon defined in the Time Buckets Profile for Demand Planning and
Supply Network Planning is capped to the value as defined in the Time
Buckets Profile. This affects the display as well as all performed
calculations.
Target Locations
Define one or multiple Deploy to Locations. The definition of a
Deploy to Location is optional. Leaving these fields blank, results in
deployment planning to all locations.
Orders
Select one of the following options:

Performing

608

Delete
Delete original demand element (SNP planned order) independent on
whether the Deployment run can satisfy the demand or not.

Do not change
Leave original demand element (SNP planned order) and do not
create a Deployment order. Use this option for simulation runs only.
The result of the simulation can be viewed in the log file (if flag is
switched on).

Reduce
Reduce original demand element (SNP planned order) according to
the quantity of the Deployment order that is created. The reduction
can be down to Zero.
Real-Time Deployment

This option (part of Deployment Settings in Interactive Planning) defines

that the requirements of target location at time of Deployment run has to
be used and not the existing SNP planned order. Real demand might be
higher or lower than SNP planned order demand. If this option is set all
demands (inside and outside the deployment horizon) will be satisfied by
either deployment or SNP orders.
Deployment Target Location
When running Real Time Deployment it is possible to stipulate one
Deploy to Location. This is an option and switches the system over
from the standard deploy from to an optional deploy to mode.
Log Flag
Create interactive report at the end of the Deployment run. If the
Deployment Heuristics is run in background and this flag is on, the log
file will be printed out automatically! This might not be a good idea, as
this log file tends to be rather big.

5.2.4

Deployment Optimization

The Deployment Optimizer can only be run in batch and not by means of using the SNP
Interactive Planning transaction. The Deployment Optimizer has the same parameters as the SNP
Optimizer. They are complemented by some deployment specific settings.
The Transaction
Path:

Supply Network Planning > Planning > Supply Network Planning in

the Background > Deployment Optimization

Technical Name:

/SAPAPO/SNP03

The initial screen requires the definition of various parameters, mandatory and optional ones. This
needs to be done every time the transaction is called. In order to reuse the same set of parameters
Performing

various times, it is possible to save a set of data (after defining it once) in a variant. In consecutive
calls of the same transaction, this saved set of data can be called up again, and altered if required.

After data has been changed the variant can be updated if required to reflect the changed data. See
Variant Maintenance for more information.
A batch run can be executed immediately or scheduled to be run at certain predefined times and
intervals. View the section SNP Scheduled Background Transactions.
Application Bar Pushbuttons
Execute
Executes the planning run.
Variant
Selects a previously saved variant and populates all required input fields
for the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags
Planning Book
Stipulate the planning book as required (9ASNP94 in the standard
delivered system).
Data View
Stipulate the data view of the planning book as required (SNP94(1) in
the standard delivered system).
Selection Profile Flag
Activate the Selection Profile flag and define a selection profile.
The data environment for the Deployment optimization can be defined
via a selection ID or manually. The selection profiles that can be used in
here are the same as those defined in the SNP Interactive Planning
transaction. These selections are unique per planning area. A display
button shows the selection definition if required.
Manual Selection Flag
Activate the Manual Selection flag and define the four upcoming fields.

Planning Version

Level ID

Product Range

Location Range
Planning Start and End Date
When using the Deployment Optimizer the planning start date does not
Performing

have to be the current date. Define here the required planning start and
end date.
Profiles
Select a SNP optimization, cost, and optimization bound profile.

Optimizer Profile

Cost Profile

Optimization Bound Profile / for

The definition of the optimization bound profile is optional.

Push Distribution (optional)

In case of surpluses, the Push Distribution setting is applied. The
definition of surplus depends on the selected Push Rule.
Fair Share Rule (optional)
In case of shortages, the cost optimum solution is determined.
Alternatively, Fair Share Rules can be applied in the case of shortages.
Pull Deployment Horizon (mandatory)
This field defines the number of calendar days that are checked for (SNP
and PP/DS) distribution demands at the receiving location. No specific
factory calendar can be used. Day 1 is the current day.
The Deployment Optimizer does not use the Pull Deployment Horizon
definition of the product master SNP2 tab!
Set this value to at least 1 to indicate that all demands for the actual
and coming day should be considered when calculating deployment
requirements.
The Pull and Push Deployment Horizons are also used to determine the
period in which possibly existing SNP orders are deleted (regenerative
planning!).
Deployment Push Horizon (mandatory)
This field defines for how many calendar days into the future the system
should take receipt elements into account when planning the sending of
products to the receiving location. The word Push in the field name
does not stipulate that the value defined in it is used when applying a
Push Deployment Strategy!
The Deployment Optimizer does not use the Deployment Push
Horizon definition of the product master SNP2 tab!
Set this value to at least 1 to indicate that stocks and all receipts for the
actual and coming day should be considered when calculating
deployment supplies.
ATP Checking Horizon (optional)
Define an ATD checking horizon to enable an early detection and
consideration of demands in future time buckets.
Performing

5.2.5

Transport Load Builder

The Transport Load Builder can be run in an interactive mode using the SNP Interactive Planning
transaction and in batch.
The Transaction
Path:

Supply Network Planning > Supply Network Planning In The

Background > Transport Load Builder (TLB)

Technical Name:

/SAPAPO/SNP04

The initial screen requires the definition of various parameters, mandatory and optional ones. This
needs to be done every time the transaction is called. In order to reuse the same set of parameters
various times, it is possible to save a set of data (after defining it once) in a variant. In consecutive
calls of the same transaction, this saved set of data can be called up again, and altered if required.
After data has been changed the variant can be updated if required to reflect the changed data. See
Variant Maintenance for more information.
A batch run can be executed immediately or scheduled to be run at certain predefined times and
intervals. View the section SNP Scheduled Background Transactions.
Application Bar Pushbuttons
Execute
Executes the planning run.
Variant
Selects a previously saved variant and populates all required input fields
for the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags
Planner
Define a planner to filter transportation lanes that match the planner. The
planner is defined in the transportation lane header.
Planning Version
Stipulate the planning version as required (000 is the active planning
version).
Performing

Planning Book

Data View

Begin of Planning Period

Define the beginning of the planning period. This is an optional entry
and if no date is defined the current date is used as the planning period
start.
Planning Horizon
Set the number of days for the planning run.
Delete Flag
Set this flag to delete all remaining not satisfied deployment orders
(recommendations) for which no TLB orders (transport orders) could be
created. During the next SNP planning run the system will then create
new SNP planned orders if required.
Transportation Lanes Source Location

Restrict the use of transportation lanes for the TLB planning run by
defining source locations. This is an optional entry.
Locations can be defined individually or as ranges. The normal selection
features are available. See Multiple Selections for more information.
Transportation Lanes Target Location
Restrict the use of transportation lanes for the TLB planning run by
defining target locations. This is an optional entry.
Locations can be defined individually or as ranges. The normal selection
features are available. See Multiple Selections for more information.
Transportation Lanes Transportation Method
Restrict the use of transportation lanes for the TLB planning run by
defining transportation methods. This is an optional entry.
Transportation methods can be defined individually or as ranges. The
normal selection features are available. See Multiple Selections for
more information.
Log Flag
The log file provides an overview of all created TLB orders.
Performing

5.2.6

Extended Safety Stock Calculation

The Extended Safety Stock Calculation creates safety stock values for selected location products
in a specific planning area. The result of this calculation is stored in a database key figure, which
is planning area specific. This means that for the same location product and even within the same
planning version different safety stock values could exist. Which safety stock value is used during
the subsequent SNP planning runs depends on which planning area is used. PP/DS uses a safety
stock key figure as specified in customizing.
The Transaction
Path:
Technical Name:

Supply Network Planning > Planning > Safety Stock Planning

/SAPAPO/MSDP_SB

The initial screen of this background program is subdivided into two sections, followed by a
single flag. Once the program is started, it calculates the safety stock as specified and updates the
specified key figure. The results of this planning job are then used as an input parameter for SNP
as well as for PP/DS planning.
Application Bar Pushbuttons
Execute
Executes the planning run.
Variant
Selects a previously saved variant and populates all required input fields
for the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags

Safety Stock Planning

The Safety Stock Planning section is subdivided into various segments.
The fields in this segment refer to data stored in the SNP environment.
Segment Planning Area
Planning Area
The planning area and the planning object structure (see below)
determine the key figures that are used to determine the future demand
situation. The appropriate planning area of the standard delivered system
that should be used here is called 9ASNP02.
Planning Object Structure
Performing

This field is set to 9AMALO and cannot be changed to any other value
at present. This planning object structure is part of the planning area
9ASNP02. It must also be part of any other custom planning area with
exactly this name if custom planning areas are used.
Planning Version
The planning version determines together with the demand forecast
key figure which demand values are taken into account. For the same
location product different demand elements could exist per planning
version.
The planning version is linked to exactly one supply chain model and by
specifying a specific planning version the system also determines the
supply chain model. This is required to, for example, read the
appropriate transportation lanes, as they are defined per supply chain
model.
Segment Safety Stock Planning for
Product
One or multiple location products can be included in the extended safety
stock planning run. Any product included in this selection must have an
extended safety stock method defined in the product master in all
locations. The same applies to the service level and the target days
supply. Both values must not be Zero.
Location
Determines together with the product selection (above) the range of the
products included in the extended safety stock planning.
Planning Buckets Profile
This profile determines the number of periods for which the safety stock
is calculated and the granularity of calculated data. The start date is
always the current day. If, for example, the profile has a bucket size of
week, the system populates the daily safety stock figure with identical
values during the seven-day period. The planning buckets profile can
have mixed buckets (e.g. days and weeks). The standard delivered
planning buckets profile 9ASNP, which is used in SNP Interactive
Planning can also be used here.
Segment Key Figure for Safety Stock
Safety Stock

The safety stock key figure defaults to SAFETY. This is the key
figure, which is used in the standard delivered system to store the safety
stock. It can be changed to any other valid key figure.
Leave this field blank to carry out a simulation run. The system then
calculates the safety stock values and displays them in the log without
saving the results.
Segment Key Figure for Forecast
Performing

Note that for all periods where the demand (forecast) is Zero, the safety
stock is also set to Zero.
Demand Forecast
The demand forecast key figure is used to read the future demand
(forecast) of the product per location. This key figure must be part of the
planning area defined above. In the standard delivered system the key
figure 9ADFCST contains this information.
Demand Forecast Level
Determines the percentage of the forecast that should be used when
calculating the safety stock. The forecast is read from the demand
forecast key figure as defined above. If this level is set to e.g. 70%, the
forecast on which the safety stock calculation is based will be reduced to
70% of the original value. It does not mean that the safety stock is
reduced to 70% of the value. This level can also be set to above 100% to
plan safety stock values that can cope with more than the forecasted
demand.
Procurement Forecast Level
Change this level to values other than 100% if it is anticipated that the
forecasted procurement lead-time goes up (>100%) or down (<100%).
Unlike the forecasted demand that is read from the demand forecast key
figure, the procurement forecast of the lead-time is derived from master
data objects (e.g. product master or transportation lane). The lead-times
stipulated in these master data objects are adjusted according to this
level. This level changes the anticipated procurement lead-times and not
directly the safety stock values.
Uncertainty of Forecast
The Uncertainty of Forecast section is subdivided into various segments.
The fields in this segment refer to data stored in the DP environment.
Segment Planning Area
Planning Area
The planning area in this segment is the one in which the historical data
is stored. It does not need to be, and usually is not, the same planning
area as the one defined above. In the standard delivered system the
planning area 9ADP01 is set up as an example. In most cases, own
custom planning areas are used within DP. The planning area determines
the key figures that can be used to read the required data (e.g. the
historical forecast).
Planning Object Structure
The planning object structure that needs to be defined here is the master
planning object structure of the planning area defined above.
Planning Version

The planning version determines together with the various key figures
Performing

defined below which data is taken into account.

Segment Key Figures for the Uncertainty of the Demand Side
The extended safety stock calculation requires that either the key figure
for the uncertainty of the demand side and/or the key figures for the
uncertainty of the procurement side are defined. Note that if both sets of
key figures are not defined, the safety stock is also set to Zero
independent of the demand situation.
Realized Demand
This is the key figure where the actual historical sales are stored. It must
be defined per product and location in order to be used for the extended
safety stock planning algorithm.
Planned Demand
The planned demand key figure contains the historical forecast. The
system calculates the forecast deviation based on this and the above key
figure.
Start and End Date
The extended safety stock algorithm calculates one demand forecast
error value for the entire horizon as defined in the start and end date.
Changing this horizon to include or exclude periods with higher (or
lower) demand forecast errors than normal has an immediate effect on
the calculated safety stock values.
Forecast Error Level
If the demand forecast error is expected to be higher (or lower) in the
future than it was in the period as defined by the start and end date, then
this level can be set to the appropriate percentage. This level changes the
demand forecast error level and not directly the safety stock values.
Segment Key Figures for the Uncertainty of the Procurement Side
Realized Delivery Time
This is the key figure where the actual (realized) delivery times are
stored. This information has to be obtained from the OLTP system and
stored in a key figure. It must also be defined per product and location in
order to be used for the extended safety stock planning algorithm.
Planned Delivery Time
The planned delivery time key figure contains the historical estimation of
the delivery time. The system calculates the delivery (lead) time
deviation based on this and the above key figure.
Start and End Date
The extended safety stock algorithm calculates one procurement lead
-time error value for the entire horizon as defined in the start and end
date. Changing this horizon to include or exclude periods with higher (or
lower)
Performing

procurement lead-time errors than normal has an immediate effect on the

calculated safety stock values.
Forecast Error Level
If the procurement lead-time error is expected to be higher (or lower) in
the future than it was in the period as defined by the start and end date,
then this level can be set to the appropriate percentage. This level
changes the procurement lead-time error level and not directly the safety
stock values.
<Without Label>
Flag for Results Log
Switch this flag on to view a comprehensive list of lead -time, demand,
and forecast errors as well as the calculated safety stock per period.

5.2.7

Key Figure Release and Order Conversion

Transactional information in APO is stored either in time streams or in discrete orders. How data
is stored depends on the type of information and the module within APO that is using the data.

Demand Planning stores the forecast data in time streams. The time stream granularity is user
definable (e.g. weeks) and the quantity information is stored accordingly (e.g. a forecast of
100 for a specific week). The information is stored directly in key figures. Demand Planning
stores primarily forecast related data, which is demand data. Supply data can be made
available from SNP and is then also stored in time streams.

Supply Network Planning, with the exception of Sales & Operations Planning (SOP), stores
data primarily in discrete orders (e.g. a production order at a certain day and time). Orders
are related to key figures, which do not contain the information, but are used to accumulate
the information per day (e.g. all production orders of a certain day). This method of data
storage applies to both demand and supply data. A forecast from DP is for example used to
create a forecast order which in turn is related to a forecast key figure in SNP. Sales &
Operations Planning (SOP) uses time stream based data storage (see above).

Production Planning and Detailed Scheduling uses the same principles in terms of data
storage as SNP does. It sometimes uses different order types for supply elements but shares
the demand elements with SNP.

Based on the different ways in which data is stored, it is required to transfer and convert data
between the modules. Read the section Inter Module Data Flow to obtain more background
information about these and other data transfer activities.
The topic of data flow maintenance is a bit confusing, as there is no central maintenance tool to
carry out these tasks. The transactions used to perform these tasks are scattered around the system
Performing

in various places and the user interfaces of the transactions lack clarity. The tables below provides
an overview of available transactions with their respective data source and destination.

From
To
DP (LC)
SOP

SNP
PP/DS

Table 85 Data Flow Overview

The letters in the cells refer to the options used below.
Option A
Transaction
Name
Data
Description

Option B
Transaction
Name
Data
Description

Option C
Transaction
Name
Data
Description

Option D
Transaction
Name
Data
Description
Performing

Option E
Transaction
Name
Data
Description

Option F
Transaction
Name
Data

Description

Option G
Transaction
Name
Data
Description

Option H
Transaction
Name
Data
Description

Option I
Transaction
Name
Data
Description
Performing

5.2.7.1

Forecast Release to SNP

The release of the unconstrained sales forecast from DP to SNP is usually performed at
predefined intervals (e.g. weekly or monthly). During this process the forecast that was finally
approved by the sales forecasting team is handed over to SNP. Within SNP this unconstrained
forecast is checked against the real world constraints, such as component and resource
availability. The result of this SNP rough cut plan is a constrained forecast that balances demand
and supply. The release is performed in batch mode and can be repeated without the danger of
duplication of forecast data within SNP. The released forecast from DP is also used for the
forecast consumption (if required) according to the products requirements strategy.
The Transaction
Path:
Technical Name:

Demand Planning > Environment > Release to Supply Network

Planning
/SAPAPO/MC90

The initial screen requires the definition of various parameters, mandatory and optional ones.
This needs to be done every time the transaction is called. In order to reuse the same set of
parameters various times, it is possible to save a set of data (after defining it once) in a variant. In
consecutive calls of the same transaction, this saved set of data can be called up again, and altered
if required. After data has been changed the variant can be updated if required to reflect the
changed data. See Variant Maintenance for more information.

The same transaction is used to release the unconstrained forecast from DP and for the release of
time-series based data (e.g. from Sales & Operations Planning) to SNP. The target is in both cases
SNP where the data is used to create discrete orders.
The description in this section refers to the forecast release from DP to SNP. The batch run can be
executed independently or as part of a DP mass-processing job. View the section DP Mass
Processing.
Application Bar Pushbuttons
Execute
Executes the conversion run.
Variant
Selects a previously saved variant and populates all required input fields
for the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags
Release: Extended (Pushbutton)
Performing

Leave this flag off to release the unconstrained forecast from DP to SNP.
Refer to Time Series Transfer for the available options if this flag is on.
Data Source
Planning Area
Define the DP source planning area in which the forecast key figure is
defined.
Planning Version
Define the source planning version used in conjunction with the planning
area above, which holds the data of the key figure.
Key Figure
Define the forecast key figure name.
Target
Planning Version
Define the SNP target planning version into which the independent
requirements (forecast) values have to be written (the active planning
version is 000).
The independent requirements can be released to any (or several)
planning version(s) as long as the planning version was initialized for the
planning area.
Category
Define the order category used to store the independent requirements in
SNP.
If this field is left blank, the system will check the requirements strategy
per product (defined in Proposed Strategy) and the corresponding

category setting in requirements strategy used during the release. If no

valid order category can be found, the default value FA is used.
Add Data Flag
With this flag set the system creates new independent requirements for
all forecast elements found in DP irrespective of probably already
existing independent requirements. Set this option to improve system
performance but only when transferring data the first time for the given
period; otherwise a duplication of orders is likely to occur! Never set this
flag when transferring an updated demand plan to SNP.
Horizon
From and To Date
Define the start and end date for the transfer of independent requirements
from DP to SNP.
Periodicity
Performing

Planning Buckets Profile

Specify the planning (time) bucket profile that is used to create the
independent requirements in SNP. This time bucket must be in daily
buckets.
Daily Period Split
Define this indicator as a default value for all such products where the
Period Split indicator is not defined. See the product master SNP2 tab
for more information.
Object Selection
Product
Restrict the release to certain products by specifying them here. If no
products are defined, the forecast values of all products are released.
Location
Restrict the release to certain products of certain locations by specifying
the locations here. If no locations are defined, the forecast values of all
locations per product are released.
Extended (Pushbutton)
Activate this button only if an assignment change of product or location
characteristics definitions is required.
Characteristic: Product
Change the default DP characteristic for the product if
required. Characteristic: Location
Change the default DP characteristic for the location if required.
<Without Label>
Log
Set this flag to view a status report.

5.2.7.2

Time Series Transfer

The release of the constrained supply and demand plan from SNP to DP is an optional activity.
By doing so, the result of the SNP rough cut plan can be easily seen in the DP environment.
The Transaction
Path:

Supply Network Planning > Environment > Release to Demand

Planning

Performing

Technical Name:
The initial screen requires the definition of various parameters, mandatory and optional ones. This
needs to be done every time the transaction is called. In order to reuse the same set of parameters
various times, it is possible to save a set of data (after defining it once) in a variant. In consecutive
calls of the same transaction, this saved set of data can be called up again, and altered if required.
After data has been changed the variant can be updated if required to reflect the changed data. See
Variant Maintenance for more information.
Application Bar Pushbuttons
Execute
Executes the conversion run.
Variant
Selects a previously saved variant and populates all required input fields
for the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags
Source Version
Planning Version
Define the source planning version in SNP.
Target Version
Planning Area
Define the DP target planning area into which the constrained forecast is
to be written.
Planning Version
Define the DP target planning version into which the constrained forecast
has to be written (the active planning version is 000).
Horizon
From and To Date
Define the start and end date for the transfer from SNP to
DP. Planning Buckets Profile
Specify the planning (time) bucket profile to be used.
Object Selection

Product
Performing

Restrict the release to certain products by specifying them here. If no

products are defined, the constrained forecast values of all products are
released.
Location
Restrict the release to certain products of certain locations by specifying
the locations here. If no locations are defined, the constrained forecast
values of all locations per product are released.
Resource
Leave blank for the release from SNP to DP.
Extended (Pushbutton)
Activate this button only if an assignment change of product or location
characteristics definitions is required.
Characteristic: Product
Change the default DP characteristic for the product if
required. Characteristic: Location
Change the default DP characteristic for the location if required.
Key Figure Assignment
Key Figure Assignment (Pushbutton)
Press this pushbutton and specify on the upcoming screen the SNP type
of source (Key Figure), the category group (e.g. PP1), and the
semantics (Confirmed). Then select the target key figure in DP.
Press the <back> button to then start the release.
<Without Label>
Log
Set this flag to view a status report.

5.2.7.3

Conversion of SNP Orders

The SNP rough-cut planning (optimization or heuristics) creates orders with a specific order
category. The SNP planned production order for example is of category EE. Purchase
requisitions can also be of a special SNP order category (EA), or the same as those used by
PP/DS (AG). Naturally the SNP created orders roll into the production horizon at some time.
PP/DS does not pick up these orders automatically. They rather need to be converted from SNP to
PP/DS, which allows hand-over of these orders between these two planning steps. The
conversion can be done by means of a batch job, as described here or in an interactive transaction
like the Product View.
Performing

The Transaction
Path:

Production Planning > Environment > Current Settings > Conversion

of Supply Network Planning -> Production Planning

/SAPAPO/SNP2PP

Technical Name:

The initial screen requires the definition of various parameters, mandatory and optional ones. This
needs to be done every time the transaction is called. In order to reuse the same set of parameters
various times, it is possible to save a set of data (after defining it once) in a variant. In consecutive
calls of the same transaction, this saved set of data can be called up again, and altered if required.

Application Bar Pushbuttons

Execute
Executes the conversion run.
Variant
Selects a previously saved variant and populates all required input fields
for the batch run.
Save
Saves captured data in a variant (see Variant Maintenance).
Input Fields and Flags
Location Product
Planning Version
Determines the planning version from which the SNP orders will be
read. The PP/DS orders are created in the same planning version.
Location (from and to)
Select the location(s) for which the SNP order conversion should be
carried out. Use the Multiple Selection function if required.
Product (from and to)
Select the product(s) for which the SNP order conversion should be
carried out. Use the Multiple Selection function if required.
Conversion of SNP Receipt Categories
ATP Category (from and to)
Select the ATP category (or categories) for which the SNP order
conversion should be carried out. The ATP category determines the type
of order (e.g. EE is an SNP planned production order). Use the
Multiple Selection function if required.
Performing

Conversion Horizon
Increase Production Horizon
By default this conversion program converts all SNP orders according to
the selection parameters stipulated above within the products production
horizon as defined in the product master SNP2 tab.
By specifying a time (in calendar days) the individual products
production horizon is increased or decreased for this conversion run.
Control Parameters
Firm Newly Created Orders Flag

Set this flag to automatically firm all newly created PP/DS orders. A
firmed order has the status output firmed, which means it can only be
changed manually but not by the system.
Use SNP Sources of Supply Flag
During the SNP planning the source of supply is determined using rules
that can be different from those used by PP/DS. If during the release a
new source determination should be carried out then set this flag.
Lot-Size Calculation
Set this flag to calculate the lot sizes during the conversion in accordance
with the settings in the location product master lot size tab. This will
have a big impact when the SNP Optimizer was used, as it does not have
to adhere to lot size definitions. Not setting the flag creates PP/DS orders
with the same quantities as those in the SNP orders.
Conversion Mode
The conversion mode determines how the system handles the reexplosion of the PPM during the order conversion. The options include
re-planning of all components, only those not planned by SNP, and no replanning at all.
CTM
Convert Time-Continuous CTM Orders Flag
Include CTM created production orders, which can be based on timecontinuous resources. Set this flag only if CTM is used as the rough-cut
planning tool and uses time-continuous resources.

Performing

5.3

627

Scheduled Background Transactions

The aim of scheduling background transactions is to enable the processing of time and resource
consuming planning runs during off-peak hours. Once scheduled, the scheduled background
transaction is carried out in exactly the same way as if it was running as a background or an
interactive transaction.
The tools to define and maintain the schedules are unfortunately not consistent within APO and
differ greatly from one module to the next. It is therefore required to investigate the possibilities
separately per module.

5.3.1

DP Scheduled Background Transactions

A Demand Planning background job consist of one or multiple activities, which in turn have each
one or multiple actions attached to it. These actions are tasks that could also be carried out
interactively. They include;

Forecast

Macro Execution

Release to SNP

Transfer to R/3
Activities with their actions need to be defined prior to creating jobs using the transaction Define
Activity for Mass Processing. After the activities have been created, they can be used in one or
multiple background jobs. Background jobs can be run immediately or at predefined times or
linked to other events (jobs). Activities can consist of several steps, each carrying out specific
actions. The activities are defined dependent on a specific planning book and data view (and thus
depending on a specific planning area), but irrespective of the selected data. Which data has to be
processed is defined in the background job only. Although technically possible it would not make
sense to define two actions that both carry out a forecast. Since actions are processed sequentially
and for the same data selection, the second action would just overwrite the results of the first. On
the other hand, the processing of several macros in a sequential mode males sense. To do so,
define multiple actions, each carrying out a specific macro. This could be done before or after the
forecasting run. In general, there is no rule about a specific sequence of actions. The forecast could
even be released to SNP straightaway as the last action.
The graphic below depicts the structure of the DP background job.
Performing

Forecast

Graphic 128 DP Background Job Structure

Activities
The Activity Maintenance Transaction
Path:

Demand Planning > Environment > Current Settings > Define

Activity for Mass Processing

Technical Name:
IMG:

/SAPAPO/MCST

Yes

Maintained Fields
Header
The definitions in the header must be defined before any action settings. It is not possible to
change any header settings once actions have been defined. The <Copy Action> pushbutton
is located top of the header area.
Planning Activity and Description
Define a name and description for the planning activity.
Planning Book and Data View
It makes sense to define special planning books and data views for background
processing. These planning books should contain only such key figures that are
absolutely essential for the processing steps defined in the actions. This will reduce the
processing time tremendously! In some cases processing might be faster when using two
different background jobs with two different planning books in cases where forecasts are
carried out together with macros. Before using a background job productively check
these options and compare runtimes!
Planning Area
The planning area is displayed automatically once the planning book was selected.
Action Counter
Action counter 1 is displayed initially. Use the action pushbutton <Go to next action>
to create new actions.
Performing

Action Buttons
Use the <Go to next action> and <Go to previous action> pushbuttons to navigate
through the actions. Using these pushbuttons changes the grid and the tab display.
Grid
The grid displays the actions in list form. A small, but important pushbutton is situated right
on top of it. Select a line in the grid and press the <Delete Line> pushbutton to delete an
action.
Counter
Displays all defined actions. The chosen action is depicted in the grid by a red arrow, the
non-chosen ones are marked with a green point.

Action and Description

Both fields have texts that are generated by the system based on settings made in the
tabs. They are all display only.
Forecast Tab
Master Forecast Profile
Select a master forecast profile to be used with this background job. See explanation for
the flag Always use Job Profile further down.
Profile Radio Buttons
Select one of the forecast profiles that is linked to the master forecast profile.
Always use Job Profile
Each selection ID is linked to a specific master forecast profile. This can be done
manually or is carried out by the system automatically. This means that latest after the
first forecast run (interactive or batch), a selection ID is linked to a specific master
forecast profile (see also Forecast Profile Maintenance). This profile is used for all
subsequent forecasts including such forecasts carried out in a background job.
In order to use the master forecast profile as defined in the activity and not the one
linked to the selection ID it is required to set this flag.
Delete Alerts at Job Start
Set this flag to delete all alerts for the same selection ID at the start of the forecast run.
The selection ID will only be defined in the DP background job definition.
Generate Alerts
Set this flag to generate alerts during the forecast run.
Macro Tab
Macro Radio Buttons
Background jobs allow the execution of any start, default, exit, or level change event
type macro. The event types of a macro are defined in the macro builder transaction.
Note that even macros of event type Level Change can be selected when specifying
macros individually (see below). This might in some cases not make sense, as in a
background job data is processes for a specific data selection ID and consequently no
level changes can occur.
o Macro and Name Box
Select any one specific macro to be executed in this action. The macro can be of any
event type and must be specified in the entry box.
o Initial Start
Select all macros of the event type Start to be executed in this
action. o Differential Default
Select all macros of the event type Default to be executed in this
action. o Final Exit
Select all macros of the event type Exit to be executed in this action.

Performing

630

Release Profile Tab

The <Change> pushbutton starts the Release Profile maintenance transaction from where
release profiles can be created and maintained.
Release Profile
Select a release profile. All fields displayed on this tab are from the selected release
profile and cannot be edited.
Transfer Tab
The <Change> pushbutton starts the Transfer Profile maintenance transaction from where
transfer profiles can be created and maintained.
Transfer Profile
Select a release profile. All fields displayed on this tab are from the selected transfer
profile and cannot be edited.

Other Functions
None.
DP background jobs are maintained using several system transactions, one each for the creation,
change, deletion, and copy. For the management another set of transactions is available, which
provides functionality to check and schedule background jobs as well as monitoring them while
running or after completion.

DP Background Job Maintenance

The Job Maintenance Transactions
Path:

Demand Planning > Demand Planning in the Background > Create

(Change, Delete, Copy) Demand Planning in the Background

Technical Name:
IMG:

/SAPAPO/MC8D (E, F, J)

No

Maintained Fields

Job Number and Name

Define any job number and name.
Planning Book and Data View
Select a planning book and data view for the background job. This automatically determines
the planning area and restricts the choice of activities to those defined for the planning book
and data view.
Planning Version
Define the planning version of the background job
Planning Area
The planning area is displayed automatically once the planning book was selected.
Activity

Performing

631

Select any existing activity that exists for the planning book for use with this background job.
Generate Log
Set this flag to enable the generation of a log file (report).
Selection ID
One
Use this to define one specific selection ID of the planning area. The <Display>
pushbutton can be used to display the chosen selection ID.
Several
Use this to define more than one selection ID of the planning area. The <Choose Detail>
pushbutton is used to choose selection IDs or display the chosen selection IDs.
All
Use this to include all selection IDs (all data) of the planning area.
Aggregation Level
Select the aggregation level on which the macro must run. If not specified otherwise, the
macro is run at the lowest (most detailed) level. Define a different aggregation level if
required. This might have potentially a big impact on the result. During the macro execution
data is always read at the lowest level. Then, and only if a specific aggregation level has been
defined, data is aggregated using the aggregation rules as defined in the planning area. Then
the macro calculation is carried out. After the calculation, and only if a specific aggregation
level has been defined, data is disaggregated using the disaggregation rules as defined in the
planning area. Then the result is stored at the lowest level.
The default level is the most aggregated, which means all characteristics are marked in the
preceding tick box. If we have for example a characteristics for products (which is most
likely the case) and we want to aggregate over all products, then the tick box for the
characteristic Product must be on.
The level of aggregation that can be defined here is independent of possibly existing
aggregates.

Other Functions
None.

DP Background Job Scheduling

Various transactions are available to monitor DP background jobs. They are self explanatory.
Check Demand Planning in the Background (/SAPAPO/MC8I)
Use this transaction to gain information on any background job, whether scheduled or not.

Schedule Demand Planning in the Background (/SAPAPO/MC8G)

Use this transaction to schedule background jobs.

Job Overview of Demand Planning in the Background

(/SAPAPO/SM37) Use this transaction to gain information on scheduled
background jobs.

Job Overview of Demand Planning in the Background (/SAPAPO/ MC8K)

Use this transaction to manage log files that can optionally be created during the background
job.
Performing

5.3.2

SNP Scheduled Background Transactions

Scheduled background processing can be performed for all SNP and Deployment/TLB
background transactions including the extended safety stock calculation. Within SNP,

Deployment, and TLB one common transaction (user interface) is used to define the schedule of
background transactions. The SNP scheduled background job consists of three elements.

Report Type
The report type determines the type of SNP planning to be carried out. It does not refer to
any specific data or planning area.

Variant Assignment
The variant assignment determines the planning book and data view and indirectly the used
planning area as well as the data to be processed.

Job Information
The job information is the element responsible for the scheduling of the background job. It is
identical to the tool used for example in DP.
The Transaction
Path:

Supply Network Planning > Planning > Supply Network Planning in

the Background > Schedule Supply Network Planning in the
Background

Technical Name:

/SAPAPO/SNPMVAP

The initial screen is subdivided into the two sections report type and planning information. From
there various sub-screens can be called.
Report Type
Select one of the radio pushbuttons to determine which type of
background job is called.

SNP Planning (Heuristics)

SNP Optimizer

SNP Deployment (Heuristics)

SNP Deployment Optimizer

SNP Transport Load Builder

SNP Safety Stock Building

Job Overview
Activating this pushbutton activates the job overview transaction SM37,
which provides information about scheduled jobs (past, present, and
future).
Planning Information
Define Job
Define the background scheduling job by giving it a job ID and
description.

Job Name

Performing

633

Description
Some administrative information is displayed per background scheduling job
once it is created and/or modified.

Creation Date, Time, and Author

Changed on (date), by (author), and Time

Create Job

Use this pushbutton to create a new scheduled background job. New jobs can
only be saved after a variant has been assigned.
Delete Job
Use this pushbutton to delete an existing scheduled background job.
Change Job
Use this pushbutton to update an existing scheduled background job.
Variant Assignment
Define a variant for the background scheduling job by giving it a variant ID and
description.

Variant Name

Description
Create Variant
Use this pushbutton to create a new variant for the scheduled background job.
Define all parameters for the planning run. The upcoming screens are the initial
SNP background job screens. Capture all data, save, and return.
Change Variant
Use this pushbutton to update an existing variant for the scheduled background
job.
Delete Variant
Use this pushbutton to delete an existing variant for the scheduled background
job.
Start Date
Select this pushbutton to open a pop-up window. Select one of the buttons to
define the appropriate scheduling information.

Immediate

Date/Time

After Job

After Event

At Operation Mode

>>
Performing

5.4

Common Utility Pop-Up Windows

Common Utility Pop-Up Windows (CUPs) are utilities that are aimed to support the same or
very similar functions in various transactions. The table below provides an overview of
commonly used CUPs.

CUP
Multiple Selection

Table Settings

Choose Variants

Table 86 Common Utility Pop-Up Windows

5.4.1

Multiple Selections

The multiple-selection screen permits the definition of single values and/or value ranges. Single
values as well as value ranges can be defined as inclusive values or as exclusive values.
Inclusive values are all those values that are explicitly included. The multiple-selection screen is
called from several transactions for various types of data. Multiple operands, referred to as
selection options (see below) can be defined. The default operand is single value. If only one
single selection value or one single selection range is defined then this value (or these values) is
(are) displayed in the from (and to) fields of the calling transaction.
The Calling Transaction
In the calling transaction of the multiple-selection CUP either of the two symbols shown below
can be seen.
Calling Transaction Pushbutton
The initial color depicts that no selection other than
that visible in the calling transaction exists.
Performing

Depicts that multiple selections that are not visible in

the calling transaction exist.
If the multiple-selection CUP is used to define only one single selection value or one single
selection range then this value (or these values) are displayed in the from and to fields of the
calling transaction and the pushbutton explained above remains in the initial color.
The Transaction
The multiple-selection screen has four tabs each allowing the definition of one or multiple values
or value ranges. A selection of pushbuttons is used to activate various other functions.
Tabs

Include Single Values

This tab contains all single values that should be contained in the
selection.
Include Ranges
This tab contains all value ranges that should be contained in the
selection.
Exclude Single Values
This tab contains all single values that should be excluded from the
selection.
Exclude Ranges
This tab contains all value ranges that should be excluded from the
selection.
Common Pushbuttons
Copy
Checks all entries for consistency and closes the pop-up window.
Carries over the selections to the calling transaction.
Check Entries (Enter)
Checks all entries for consistency.
Selection Options
Allows changing the operand used for the defined value or value range
(see below) in a new pop-up window.
Insert Line
Performing

Inserts a new line before that of the current cursor position. New entries
can also be made just at the end of the table.
Delete Line
Deletes the line of the current cursor position.
Delete Entire Selection
Deletes all selections in one step.
Help on Screen
It is not possible to use the normal help functions while being in a popup window. For this reason a dedicated pushbutton activates the help
function.
Cancel
Closes the pop-up window without carrying over the selections to the
calling transaction.
The default operand (selection option) is single value. No specific symbol is used to depict this.
Other operands can be selected by double-clicking on the appropriate line, or by positioning the

cursor on the line and choosing the Selection Options pushbutton. Following operands are
available.
Operands
Single Value
A blank gray pushbutton or the pushbutton with the equal symbol
depicts the single value.
Greater than or Equal to
Less than or Equal to
Greater than
Less than
Not Equal to
The operands pushbutton shown above are the ones used in conjunction with inclusive selections.
The pushbuttons used for exclusive selections are in principle the same but on a red instead of the
green background. The usage of the following wildcards is supported.
*
The asterisk depicts a string of any length including spaces.
+
The plus symbol depicts exactly one character including space.
Performing

Other Considerations
If no values are defined at all, all data objects will be selected.
Values defined in any selection can be easily deleted by typing in the symbol ! at the
beginning of the selection field.

Selections can also be defined against the value Zero or blank.

5.4.2

Table Settings

The table setting function can be found in nearly all screens with a grid (table display). This
applies to master data maintenance, profile, and interactive transactions. The table settings
transaction permits the individual definition of column width and position. The column width is
defined by dragging the column borders. The position is changed using the drag and drop feature.
It is not a tool to switch the display of certain columns on and off. APO transactions have a
default layout, which is labeled "Basic Setting". This layout is used as long as no other setting is
defined. One or multiple other settings can be defined and one of them can be defined as the
default setting for the own user ID. Some transactions, such as the Product View, permit as part of
the user settings the definition of which columns should be displayed,
The table settings can be saved per user ID but a user could have several table setting IDs to
choose from.
The Calling Transaction
In the calling transaction of the table setting the symbol shown below can be seen.
Calling Transaction Pushbutton
Table Settings

The Transaction
The transaction provides the functionality to create (and update) several layout settings in
variants. One of those defined variants or the transaction specific Basic Setting variant can be
saved as the user default table layout when using the transaction (accessing the table). The default
setting applies from the next time the transaction is called.
The table setting window has four tabs each allowing the definition of one or multiple values or
value ranges and a selection of pushbuttons used to activate various functions.
Entry Fields and Flags
Choose Variants
Current Setting
Performing

View in this field the currently used setting. This can be a previously
defined user setting or the transactions default definition labeled "Basic
Setting".
Standard Setting
Select any setting as the future setting when starting the interactive
transaction.
Maintain Variants
Variant (upper)
Define a name for a variant in this field and press the <Create>
pushbutton to create and update user settings.
Variant (lower)
Select a user variant in this field and press the <Delete> pushbutton to
delete the user setting.
Use as Standard Setting Flag
Select this flag to define the setting as the future default setting when
starting the interactive transaction.
Pushbuttons
Create
This pushbutton creates or updates a table setting variant with the details
of the currently displayed table when calling up the table settings pop-up
window. To update a table setting variant also use this pushbutton and
confirm the message.
Creating of a variant allows its continuous
use. Delete
Use this pushbutton to delete any variants except the Basic Setting.
Close (Enter)
Closes the pop-up window without applying the variant selection.
Save

The function of this pushbutton is to save the variant selection and to use
it in the calling transaction.
Saving of the settings enables the continuous use of a created
variant. Information
Provides information about the table settings maintenance.
Cancel
Cancel the table setting maintenance without using the chosen variant in
Performing

the calling transaction.

5.4.3

Choose Variants

Variants are used in batch transactions to facilitate the saving and calling up of parameters for a
batch run. The parameters that can be saved in a variant depend on the transaction and the screen,
which is used to capture the transactions parameters.
The Calling Transaction
In the calling transaction of the choose variant CUP the symbols shown below can be seen.
Calling Transaction Pushbutton
Get Variant
Select a previously saved variant to populate all required input fields for
the batch run.
Save
Save captured data in a variant.

The Transaction
In order to save a variant, define all data as required by the transaction and press the <Save>
button. This opens the save variant screen in which the variant needs to be named for future
usage.
To save a variant simply define a variant name and description. Use the same procedure to change
an existing variant.

Performing

5.5

640

Utility Transactions

Utility transactions permit the maintenance of specific data objects, which are supporting activities
on the system but do not constitute master data objects. An example for this is the maintenance of
selection profiles, which are used to facilitate the selection of master data objects.

5.5.1

Selection Maintenance

The selection maintenance transaction is used to create and maintain user and master selection
profiles for usage in the SDP Interactive Planning transactions. Selection profiles combine several
selection IDs and help to retrieve data faster in the aforementioned transactions. Each user
(planner) has exactly one user selection profile, which contains one or several selection IDs. The
selection IDs have a name that is unique within the planning area. To maintain a selection profile,
a user can use his or her own selection IDs, any other selection ID, or selection IDs belonging to
the master selection profile. The master selection profile needs to be created using this transaction
and should contain selection IDs for common usage. Using master selection profiles is an option.
The Transaction
Path:
Technical Name:

Demand Planning > Environment > Selection Organization >

Maintain Selection Assignments
/SAPAPO/MC77

The selection maintenance transaction can only be found in the Demand Planning environment
although it is used to define selection IDs used in Demand Planning and in Supply Network
Planning. Once the transaction is started and the planning book is defined, it immediately shows a
pop-up window in which all activities take place. The same pop-up window is also shown when
accessing the selection maintenance directly from the DP or SNP Interactive Planning transaction.
Deletion
Selection IDs are deleted in a separate transaction (Demand Planning > Environment > Selection
Organization > Delete Selection).
Prerequisites for the Creation
The selection IDs that are allocated to user IDs or the master selection must be created prior to
this activity in the DP or SNP Interactive Planning transaction.
The Process
Performing

In the selection profile window the user can organize saved selections in a tree structure.
Selections can be saved in the selection window (see above). To better organize the selection
profiles, folders and subfolders with a name of choice can be created. Saved selections are then

assigned to these folders. After a saved selection has been selected, its data objects are displayed
in the info objects area of the SDP Interactive Planning transaction and can be displayed (loaded)
in the panning table view via context menu functions. Alternatively, double-clicking on the data
object also performs a selection.
To organize user selection profiles follow these steps:
Start the selection maintenance transaction or double-click on the Selection Profile bar of
the SDP Interactive Planning transaction.

The upcoming window shows two tree structures. The left tree structure shows all saved
selections for the current user or is left blank initially. In this case choose a user ID or the
Master Selection Profile. The right tree structure displays one of the three selection ID
groups:
All selection IDs
This selection shows all selection IDs created by any user for the planning area to which
the current planning book belongs (elect the group in the reference drop-down menu).
Selections of current planning book
This selection shows all selection IDs created by any user for the current planning book.
Master selections
With this option (used only when maintaining user selection profiles), the system shows
the selection IDs of the master selection profile only.

Drag any selection ID from the right to the left tree structure and drop it where required. The
displayed sequence of the left tree structure is the one that is also visible in the interactive
planning transaction.

Pushbuttons (Bottom)
Copy
Uses the selection profiles and returns to the DP or SNP Interactive
Planning transaction or ends the transaction.
Save
Saves the selection profiles.
Cancel
Cancels maintenance and returns to the DP or SNP Interactive Planning
transaction or ends the transaction.
Pushbuttons (Left Tree Structure)
Create
Creates a new profile (user or master selection). This option is not
available when opening the selection maintenance window from the DP
or SNP Interactive Planning transaction.
Performing

Create Folder
Creates a new folder within a selection profile. The folder is created on
the line where the cursor is positioned.
Display Selection
Displays in a pop -up window the selection table, which displays the
defined rule for the user or master selection profile.
Delete Entry

Deletes the selection ID from the user or master selection profile but not
the selection ID itself.
Move Entry Up
Selection IDs are not displayed in ascending or descending sequence but
depending on where they were positioned in this maintenance window.
Use this button to move a selection ID up within the selection profile.
Move Entry Down
Use this button to move a selection ID down within the selection profile..
Pushbuttons (Right Tree Structure)
Display Selection
Displays in a pop -up window the selection table, which displays the
defined rule for the selection profile.
Rename Selection
Renames the selection ID (in both tree structures).
Delete Selection
Deletes the selection ID (from both tree structures).
Find Selection
Opens a pop-up window allowing the search for specific selection IDs.
Find Next
Performs a search next function.

Other Functions
None.

Evaluating

643

6 Evaluating
APO is an online planning system geared towards a time and resource efficient management of
demand and supply. Reduced stock holdings and lead-times require a fast response to changing
planning situations. The planning cycles in state-of-the-art planning environments are extremely
short and do not allow the creation of huge lists that are worked through sequentially. Problems
are revealed by the supply chain cockpit and the alert monitor and not through the study of lists.
Lists generated by APO are therefore the exception and are used primarily to verify that the
planning run was carried out without (technical) errors. Specifically within the PP/DS
environment, some predefined lists can be found.
The central APO tool for evaluating the planning result is the Supply Chain Cockpit with its
integrated Alert Monitor. The Alert Monitor is discussed a separate section.

Evaluating

6.1

644

Interactive Evaluating

The evaluation of the planning result is carried out in the respective interactive planning
transaction where the results of the planning can be viewed immediately. There, it is also possible
to see alerts based on the saved planning results (database alerts) or based on the current unsaved
planning situation (dynamic alerts). See the respective section for an introduction to alerts. When
carrying out the planning in the background, the display of dynamic alerts is not feasible and the
results can be viewed only in various log files. In both cases it is possible to view and evaluate the
planning situation in the Supply Chain Cockpit and the Alert Monitor.
The Alert Monitor is discussed together with the Plan Monitor and the Global ATP Tools in the
section Resolving.

6.1.1

Supply Chain Cockpit

The Supply Chain Cockpit and the Supply Chain Engineer, although very similar in appearance
have very different tasks. The supply chain engineer is the graphical tool used to define the supply
chain network with all locations and its dependencies. The task of the supply chain cockpit is to
monitor the supply chain network. Another function integrated into the supply chain cockpit is the
alert monitor, which provides information regarding any problem in the supply chain irrespective
of a specific source.
Using the supply chain cockpit, planning version specific information is displayed. The planning
version that is displayed in the supply chain cockpit is linked to exactly one supply chain model
and for this reason it is not required to stipulate a supply chain model together with the planning
version. On the other hand, each supply chain model can work in conjunction with several
planning versions.
The Transaction
Path:
Technical Name:

Supply Chain Monitoring > Supply Chain Cockpit

/SAPAPO/SCC01

When opening the Supply Chain Cockpit the last used planning version and work area are
prompted for use. The work area, which defines the data objects that can be seen and monitored,
is maintained within the Supply Chain Cockpit.
The graphic below displays a symbolic layout of the Supply Chain Cockpit.
Evaluating

Supply Chain Section

Work Area Objects Section

Structures

Application Bar

View Section

Tree

Time Period Section

Object

Map Section

Alert Monitor Launch Section

Graphic 129 Supply Chain Cockpit Screen Layout

The Application Bar

Application Bar Pushbuttons
Refresh Alerts / Key Figures
Use this button to refresh the alert and key figure situation.
Alert Monitor
Switches the alert monitor display on. Depending on the user settings, the
alert monitor window is displayed in a separate transaction or instead of
the map/plan monitor.
Plan Monitor
Switches the plan monitor display on. Depending on the user settings, the
Evaluating

plan monitor window is displayed in a separate transaction or instead of

the map/alert monitor.
Objects in Model
Pressing this pushbutton opens a pop-up window listing all objects (e.g.
products and locations) that are part of the selected supply chain model
and not those that are part of the work area. In this window the
pushbutton labeled Include Objects in Work Area is very helpful to add
objects of a model to the selected work area.
User Settings

Press this pushbutton to open the User Settings window. User settings
can also be maintained directly from the menu tree structure in which
case more options are available.
See Supply Chain Cockpit User Settings for more
details. Reset Display
Resets the display to show the map in the map section again (e.g. after
switching over to the alert or plan monitor).

Some data elements like transportation lanes have time dependent

parameters. The Map option allows limiting the time validity of the
map to view for example only such transportation lanes that are valid in
a period as specified.
Graphical Display Show/Hide
Switches all graphical elements (map, tree structure, and alert buttons) of
the screen on and off.
The Supply Chain Section
The supply chain section displays the currently selected planning version and supply chain model
that the planning version is based on. Other planning versions can be selected by typing the
appropriate planning version name into the entry field. A change of the planning version might
also lead to a change of the underlying supply chain model.
Supply Chain Section Pushbuttons
Model Header
Provides administrative information about the currently selected and
displayed supply chain model.

Evaluating

647

The Work Area Objects Section

The supply chain cockpit work area defines the master data objects that are visible and available in
the supply chain cockpit working session. The supply chain cockpit and supply chain engineer
share the same work areas.
For more information view the section Work Area.
The View Section
In the view section the user can switch between a geographical and a logical view. The
geographical view uses maps and displays the locations according to their geographical
coordinates, as defined in the location master. Logical views display the locations where the user
places them irrespective of their geographical coordinates. Several logical views can be defined
without interfering with the geographical coordinates saved in the location master. The
pushbuttons in this section are only active while a logical view is selected.
For more information view the section Logical View.
The Time Period Section
In this section the validity dates are displayed based on the user specific settings. These settings
can be defined either from within the supply chain cockpit or directly from the menu tree
structure. The validity can be defined using absolute time settings or relative ones.

Absolute Time Setting

The period is defined independent of the current date and does not change (e.g. 01.01.2001 to
12.12.2001). The defined date is shown without changes in the period section from and to
fields.

Relative Time Setting

The period is defined dependent on the current date and moves with it (e.g. 28 days). This
would be the normal setting in a live environment, as the user always sees information that is
valid a certain amount of time into the future. The time period defined in the profile is
interpreted by the system to calculate the period section from and to fields. The from is
set to be the current date and the to is calculated based on the relative period.

Time Steam Setting

Another way of relative time definition is the usage of a time stream. Instead of defining a
certain number of periods, a time stream is defined. The time stream then determines the
number of periods.
Irrespective of the used time setting principle, it is always possible to change the date and time in
the from and to fields. These changes are only valid for the current working session and are
lost immediately when leaving the supply chain cockpit. This is even the case after using the
Save button. In order to change date settings permanently, the user settings need to be changed.
The period settings are used to check for alerts and for the display of other time dependent
information (e.g. the validity of transportation lanes). Long periods should be avoided, as this
slows the system down significantly due to the time required to check for alert situations.
Evaluating

The Map Section

Map Section Pushbuttons

Fit to Objects
Press this pushbutton to let the system zoom in to a degree that all
elements fit into the display.
Zoom Out and Zoom In
Zoom out and in function.
Zoom to World
Displays the entire world in the map display.
Overview
Opens a map overview pop-up window. There, a red box indicates the
selected area of the main map.
Show Layer Dialog
Opens a pop-up window, which can be used to change color, line and
other graphical settings of the graphical display.
Filter
Press this pushbutton to select which element types (i.e. which location
types) are shown in the graphical display.
Select
This is the default display mode. Double-clicking on the location opens
the alert monitor and displays all alerts related to the location.
Highlight
Switch this display mode on to highlight elements the cursor is
positioned on. Click on an element to view text information about the
element (click on the x to delete this text window). Double-clicking on
the location opens the alert monitor and displays all alerts related to the
location.
Move
This button is not active in the Supply Chain Cockpit.
Connect
This button is not active in the Supply Chain Cockpit.
Evaluating

Switch Connections
Press this pushbutton to change the way the elements connections are
displayed. The pushbutton is a toggle key between connection direct
lines with angles as required, and connection lines that are exactly
horizontal and vertical.
Print
Use this pushbutton to print or save the graphical display.
Brightness

Use the brightness slider to change the graphical display brightness.

The Alert Monitor Launch Section

Alert Monitor Launch Section Pushbuttons
Application Bar
Press this pushbutton to open the Application Bar pop-up window. From
there the alert monitor launch pushbuttons can be dragged to the alert
monitor launch section and dropped.
Resize Alert Monitor Pushbuttons
This is a toggle key to minimize or maximize the alert monitor launch
pushbuttons. Unfortunately, this function has to be activated every time
the supply chain cockpit is started.
Forecast Alerts according to the DP Alert Profile
The symbol shown indicates that no alerts exist.

Supply and Demand Planning Alerts according to

the SDP Alert Profile
The symbol shown indicates that no alerts exist

Evaluating

650

Production Planning and Detailed Scheduling Alerts

according to the PP/DS Alert Profile
The symbol shown indicates that alerts of priority 1
(Error) and 2 (Warning) exist.

Transportation Alerts according to the TLB Alert

Profile
The symbol shown indicates that no alerts exist

Key Performance Indicators (KPI) can be obtained

using the Business Information Warehouse
pushbutton.
The symbol shown indicates that no alerts exist

Global ATP Alerts according to the ATP Alert

Profile
The symbol shown indicates that no alerts exist

Vehicle Scheduling Alerts are currently not depicted

by any symbol.
How To Work with the Supply Chain Cockpit

Work Area Maintenance

Refer to Work Area for a detailed explanation how to add and delete objects to and from the
work area. Note that the supply chain cockpit and engineer share the same work areas.

Evaluating

Other Functions
A multitude of additional functions can be invoked from the start menu. Most of them are selfexplanatory and certainly worthwhile exploring.

651

Evaluating

6.2

652

Reports and Log Files

Reports and log files are particularly important when running a batch job in either interactive or
batch mode. In both cases it is required to have some form of detailed and/or summarized
information to either perform some spot checks or to use these reports as a list to work through.
Some of the reports described are also of importance when carrying out simulation runs. In this
case they offer a quick overview and lead the planner into the right direction.
Some of the reports, specifically in the SNP Optimization area, are very technical and are geared
more towards helping a system specialist to find out why certain planning results appeared (or did
not appear).

6.2.1

SNP Optimizer Log

The SNP Optimizer log is a rather technical report aimed more towards problem solving in case of
SNP optimization problems than to the everyday SNP planner. It is likely that in a normal working
environment the SNP planner does not use this report at all.
The SNP Optimizer log is actually a collection of reports all aimed at providing more detailed
technical information about the SNP optimization run. It is used to analyze both SNP Optimization
and Deployment Optimization runs. The following text generically refers to SNP Optimization
only.
The Transaction
Path:
Technical Name:

Supply Network Planning > Reporting > Optimizer Log Data

/SAPAPO/SNPOPLOG

After the transaction is started, an initial selection screen is displayed allowing the selection of one
of several reports. The following information can be displayed:

Input Selection
The provided information is similar to that shown in the SNP Interactive Planning transaction
when starting the SNP Optimizer. This includes an overview of the planning environment
(e.g. planning version and profiles) as well as the selected location products.

Input Log
This is the report for really technically interested user. Should anything go wrong with the
SNP Optimization run or should the results not be as expected, then this is the place to start
searching for reasons. The provided information is not only enormous but also difficult to
read and understand.
Set the flag Display Internal Name to also see the GUID (Global Unique Identifier) with
some of the displayed data. The GUID is used in APO as a key for internal objects such as
master data and orders.

Results in Text File

Evaluating

The results in text file log provides a good overview of the SNP optimization run results.
The display is an easy to read list layout and complements the input selection described
above.
Results

With this option, the results are displayed in a very sophisticated easy to use and understand
way. It initially appears to be rather complex but because of its good selection tools it is
suited for any user who wants to get a first impression of the SNP Optimization results.

Message Log
The message log is identical to the display that is shown at the end of a background
optimization. From a contents point of view the same information is also shown at the end of
the online optimization. The massages are not always this clear and require some experience.
The provided information is not always clearly pointing to the cause of the message.
All logs refer to exactly one optimization run, which needs to be selected upfront. The system
proposes the last 10 optimization runs carried out under the same user-ID as used when starting
the log transaction.

6.2.2

SNP Optimization Resulting Cost

This transaction provides an overview of the cost and penalty situation as a result of an SNP
optimization run. This report provides an excellent overview and help when running various
simulation runs.
The Transaction
Path:
Technical Name:

Supply Network Planning > Reporting > Optimization Resulting Cost

/SAPAPO/SNP106

This transaction shows immediately after being started up a table providing information about the
SNP optimization runs. Initially displayed are all those optimization run results that were
performed by the user who is calling up this transaction. Results are available irrespective of
whether the optimization was carried out in batch or interactive.
The Application Bar
Application Bar Pushbuttons
Delete
Results that are not required anymore can be selected and deleted
(highlight the appropriate box of a certain row and press this pushbutton.
Note that results must be deleted manually, as otherwise they stay
forever. Select Solutions

The Table
The sequence of the columns in the table can be changed as required. Simply drag a column and
move it to the place where desired. Use the table settings function to save a personalized layout.

The report is grouped into several sections referring each to a specific capacity and or cost aspect.
The list below is not necessarily identical to the one that can be seen in the standard delivered
system, as it is sorted according to logical requirements.
Displayed Fields Administrative
User
The user ID of the user that ran the SNP optimization is displayed in this
field. This is also true in cases where the optimization was carried out in
a scheduled background job.
Current Date and Time
This is the date and time the optimization run was carried out and not the
current date.
Displayed Fields Settings
Planning Version
Depicts the planning version in which the optimization was carried out.
The planning version also determines the supply chain model.
Optimizer Profiles
The optimizer, cost, and optimization bound profiles are displayed in
these fields. The usage of an optimization bound profile is optional and
thus the field might be left blank.
Displayed Fields Total Result
SNP Profit / Total Costs
The SNP Optimizer can be run in either Profit Maximization or Cost
Minimization mode. This is defined in the SNP optimizer profile.
The SNP profit is displayed only if the optimizer is run in profit
maximization mode.
The Total Cost is displayed only if the optimizer is run in cost
minimization mode.
Displayed Fields Individual Results
Evaluating

Production Costs
The total manufacturing cost for products procured internally. This cost
is based on the PPM single level cost or the cost function used in the
PPM.
The usage of a production resource is not part of this cost. Production
resource costs are only applied if the capacity variant 2 (extended
capacity) needs to be used to satisfy the demand.
Procurement Costs
The total purchasing cost for products procured externally from vendors
that are not part of the supply chain model. This cost is based on the
procurement cost or the cost function defined in the product master
procurement tab.
Transportation Costs
The total purchasing cost for products procured from locations that are
part of the supply chain model. These locations could be vendors or own

locations. This cost is based on the transportation cost or the cost

function defined in the transportation method of the transportation lane.
Storage Costs
The total storage cost during the optimization period. This cost is based
on the storage cost defined in the product master procurement tab.
Production Resource Expansion
The total cost caused by using the capacity variant 2 instead of the
variant 1. The production resource capacity variant 2 is only used if
demand cannot be satisfied otherwise more economically.
This cost is based on the quantity/rate cost definition that is attached to
the capacity variant 2 of the production resource.
The resource consumption is based on the PPM resource consumption
definition per activity.
Transport Capacity Expansion
The total cost caused by using the capacity variant 2 instead of the
variant 1. The transportation resource capacity variant 2 is only used if
demand cannot be satisfied otherwise more economically.
This cost is based on the quantity/rate cost definition that is attached to
the capacity variant 2 of the transportation resource defined in the
transportation method of the transportation lane.
The resource consumption is based on the products volume or weight
definition on the attributes tab.
Costs of Resource Expansion
The total cost caused by using the storage resource capacity variant 2
instead of the variant 1. The capacity variant 2 is only used if demand

Evaluating

656

cannot be satisfied otherwise more economically.

This cost is based on the quantity/rate cost definition that is attached to
the capacity variant 2 of the storage resource defined in the location
master resources tab.
The resource consumption is based on the products volume or weight
definition on the attributes tab.
Handling Capacity Expansion
The total cost caused by using the capacity variant 2 instead of the variant
1. The capacity variant 2 is only used if demand cannot be satisfied
otherwise more economically.
This cost is based on the quantity/rate cost definition that is attached to
the capacity variant 2 of the handling resource defined in the location
master resources tab.
The resource consumption is defined in the product master GR/GI
tab. Penalty Costs Safety Stock
The total penalty caused by not maintaining the required safety stock
levels. The penalty is defined in the product master procurement tab.
Delay Penalty
The total penalty caused by late delivery. The penalty is defined in the
product master SNP1 tab.
Shortfall Penalty
The total penalty caused by not delivering at all. The penalty is defined in
the product master SNP1 tab.
A more logical approach to grouping the resulting costs is shown in the list below:

Costs and Penalty Costs

Overview of all costs as calculated by the SNP optimizer. These are the same costs as shown
by the Optimization Resulting Cost transaction. The expanded costs are those costs that
are applied due to the usage of the capacity variant 2 (increased capacity).
Production
Based on the single level cost defined in the PPM
External Procurement
Based on the procurement cost defined in the Product Master procurement tab
Storage
Based on the storage cost defined in the Product Master procurement tab
Expand Storage
Based on the storage resource cost defined in the Resource Master capacity variant 2.
This requires that the storage resource consumption is defined in the Product Master
GR/GI tab and that a storage resource is linked to the Location Master resource tab.
Safety Stock

Evaluating

657

Based on the safety stock penalty defined in the Product Master procurement tab
Transport
Based on the transportation cost defined in the Transportation Lane transportation
method.
Expand Handling
Based on the handling resource cost defined in the Resource Master capacity variant 2.
This requires that the handling resource consumptions for GR and/or GI are defined in
the Product Master GR/GI tab and that handling resources are linked to the Location
Master resource tab.
Expand Transport
Based on the transportation resource cost defined in the Resource Master capacity variant
2. This requires that a transportation resource is linked to the Transportation Lane
transportation method. The transportation resource capacity must be defined in one of the
products (base or alternate) units of measure.
Expand Production
Based on the production resource cost defined in the Resource Master capacity variant 2
of the resources used in the PPM.
Delay
Based on the late-delivery penalties defined in the Product Master SNP1 tab
Shortfall
Based on the non-delivery penalties defined in the Product Master SNP1 tab

Handling Capacity
Consumption, shadow price, and available capacity
Available capacity as defined in handling capacity variant 1. Cost is always Zero when
using variant 1 only, thus the field shadow price is always Zero.
Additional consumption, reduced cost, and additional supply
Additional capacity and cost as defined in handling capacity variant 2. Will only be used
if handling resource is defined as a constraint in SNP Optimizer profile, otherwise variant
1 is loaded indefinitely.

Storage Allocation for Product

Number and shadow price
Quantity of base units stored per product. No available capacity is shown here. Shadow
price is always Zero.
Additional quantity and reduced cost
Number of base units stored per product. No available capacity is shown here.

Safety Stock and Handling Capacity

Safety stock shortfall and shadow price
This is the difference between actual planned safety stock level (in product base units of
measure) and safety stock level. Shadow price is always Zero.
Capacity consumption
Capacity consumption of handling capacity

Storage Capacity
The storage consumption is a cumulative figure adding all receipts and subtracting all issues
of the day. It shows the balance at the end of the day.
Consumption, reduced cost, and available capacity

Evaluating

658

Available capacity as defined in storage capacity variant 1. Cost is always Zero when
using variant 1 only, thus the field reduced cost is always Zero.
Additional consumption, shadow price, and additional supply
Additional capacity and price as defined in storage capacity variant 2. Will only be used
if storage resource is defined as a constraint in SNP Optimizer profile, otherwise variant
1 is loaded indefinitely.

Production Capacity
Always empty if Deployment Optimizer was used.
Consumption, shadow price, and available capacity
Additional Production Capacity
Always empty if Deployment Optimizer was used.
Additional consumption, reduced cost, and additional supply
Transport Capacity
Consumption, shadow price, and available capacity
Available capacity as defined in transportation capacity variant 1. Cost is always Zero
when using variant 1 only, thus the field shadow price is always Zero.
Additional Transport Capacity
Additional consumption, reduced cost, and additional supply
Additional capacity and cost as defined in storage capacity variant 2. Will only be used if
storage resource is defined as a constraint in SNP Optimizer profile, otherwise variant 1
is loaded indefinitely.
Planned Transport
Start and end time of all transportation orders together with quantity and reduced cost
incurred by the orders. Includes source and target location (transportation lane) as well
transportation method and product.
Planned Production
Start and end time of all production orders together with quantity and reduced cost
incurred by order. Includes location and PPM.
Planned External Procurement
Receipt time of all external procurement orders together with quantity and reduced cost
incurred by order. Includes location and product.

Customer demand satisfied (with delay)

Priority and number of days of delay (if any) for all satisfied demands together with
quantity, reduced cost, and shadow price incurred by supply. Includes location and
product.

Customer demand not satisfied

Priority for all unsatisfied demands together with quantity, reduced cost, and shadow
price incurred by non-supply. Includes location and product.

Time = Bucket Number

No = Quantity

Evaluating

6.2.3

659

Deployment Report

The deployment report is not a report that can be called up on its own, it is rather a log that can
only be viewed at the end of a deployment heuristics run in background. When running the
deployment heuristics as a scheduled job, it is possible to specify a printer on which this report
will be printed. No log file is displayed when running heuristics deployment online. The log file is
an interactive list that allows drilling down on some information.
The report is sorted by product and source location and provides information per target location.
The following fields are displayed.

Source Location Header Information

Planning Area Unit
Displays the planning areas base unit of measure.
Product
The deployed product.
Deployment Strategy
The deployment strategy (Push Distribution setting in the product master).
Fair Share Rule
The fair share
rule.

Target Location Header Information

Location
Target
Location

Transportation Type
Transportation Method used for this segment of the report.
Delivery Time
Time as specified in the transportation lane and method in days. The time specified in the
transportation lane and method is in hours and minutes and is adjusted according to the
transportation calendar. A 24-hour transportation time combined with a transportation
calendar that determines a 12-hour work time results in a delivery time of 2 days. A 7 by
24 calendar is assumed if none is specified in the transportation lane method.
Target Days Supply
As defined in the product master of the target location.
Safety Stock
As defined in the product master of the target location.

Location Demand Information

Date
Planning bucket (day)
ATD Quantity
The quantity available to deploy in accordance with the settings of the source location
deployment settings on the SNP tab.
Demand
The new demand of the day.
Confirmed
The total of the demand that can be satisfied. The difference between the demand and the
confirmed demand appears in the roll forward figure.
Evaluating

Roll Forward

The total of new and previous roll forward demand that cannot be satisfied on the day.
Location Supply Information
From
The source location
To
The target location
Date
The shipping date
Date
The shipment quantity

Some other information might also be displayed depending on system settings and
demand/supply situation. If deployment prioritization is switched on, the report displays the
individual deployment orders priority. In case of fair share rules or push deployment being
applied, the report also contains symbols indicating this.

Evaluating

661

6.3

Graphical Display

Many APO transactions offer data to be displayed in a graphical format. Two formats are available
the standard and advanced graphical display. Which one is used depends on the selected transaction
and the choice is not up to the user.

6.3.1

Standard Graphical Display

Some of the transactions in APO allow the representation of the displayed data in a very basic
graphical format, dubbed the standard graphical display. Examples for this are the TLB view where
the load on a transportation lane is displayed using the standard graphical display.
There are no interactive user features on these graphics.

6.3.2

Advanced Graphical Display

The term Time Series Data used for this section refers to any data that is related to time and not
only to an APO Time Series. This generically defined time series can be found in the SDP
Interactive Planning transactions.
APO supports for all advanced graphics the Print and Copy functions. The print job is directly
spooled into the local PC and does not require that any SAP printer is defined. The usual Windows
and printer-supported print functions are fully available. Open the context sensitive menu in the
graphics area and select Print. A multitude of settings can be done for these graphical elements.
The pop-up windows that allow the settings to be carried out are very similar to those that can be
found in several Windows applications like for example Excel.
In some instances it is also possible to activate the context sensitive menu by double clicking on the
respective entity. Double clicking on a data series for example opens the menu Format Data
Series.
The Context Sensitive Menu changes its possible options depending on where the cursor was
situated when it was opened. The following table provides an overview of context sensitive menu
options.

Cursor in or on
Tab
Chart Area
Pattern
Evaluating

Cursor in or on
Tab
Plot Area

Pattern

Line
Quadrants

Grid Line

The formatting of the horizontal and vertical grid

independently.
Line
Scale

X-Axis or Y-Axis
The formatting of a possibly activated secondary Y-Axis (see the option
Format Data Series Axis) can be carried out totally independent of the
Evaluating

Cursor in or on

Tab
formatting applied to the primary Y-Axis. In th
inserts a second X-Axis on top that can be form
the bottom X-Axis.
Line

Scale

Font
Number
Alignment
Pattern

X-Axis or Y-Axis
The Add Value Range is an additional option that is only available when
opening the context sensitive menu on an X-Axis or Y-Axis. The available
options are identical to those explained under Format Value Range.
Value Range
A value range specified for the X-Axis (Y-Axis) looks like a vertical
(horizontal) band that stretches across the entire graphic.
A Delete option allows the deletion of the additional Value Range.
Value Range

Pattern

Line
Evaluating

Cursor in or on
Tab
Data Series
Line
Axes

X Error Bars

Y Error Bars
Data Labels

Options
Data Series
The Add Trend Line is an additional option that is only available when
opening the context sensitive menu on a Data Series. The available options
are identical to those explained under Format Trend Line.
Data Point

A specific Data Point of a Data Series can be selec

most the options are similar to those described in t
must be kept in mind that they only apply to a sing
Line
Data Labels
Options
Value
Trend Line
The trend line is based on the data of the data series that was selected when
using the Add Trend Line option.
A Delete option allows the deletion of the Trend Line.
Evaluating

Cursor in or on
Tab
Trend Line
Line
Error Bar
Line
X Error Bars

Y Error Bars
Value Range Data Label
Pattern
Font
Number
Alignment
Trend Line Label

Pattern
Font
Number
Alignment
Table 87 Graphic Formatting 1

Cursor in or on
Tab
(anywhere)
This is the same as the above Format Data Series option.

Evaluating

666

Cursor in or on
Tab
(anywhere)
Select this option to copy the graphic into the clipboard. Once the graphic is
copied, it can be pasted into other applications on the local PC. It is
required in various programs to use the Paste Special command and
specify e.g. Bitmap or Picture.
(anywhere)
Chart Type
(anywhere)
Title

Axes
Gridlines

Legend
Data Labels

Options
(anywhere)
Opens Local Printer parameter window.
(anywhere)
Once the system is displaying the Print Preview screen, the activation of the
context sensitive menu permits the following actions.
Close
Preview

Print

Page Setup
Evaluating

667

Cursor in or on
Tab

Print
Undo Format
()
Table 88 Graphic Formatting 2
Data values can be changed not only in the table, but also in the graphical display. This technique
of dragging values can be applied to all those data series, which can be changed. If, for example,
the history is flagged to unchangeable, it can neither be changed in the table, nor in the graphical
display. Value ranges that can be added to the graphical display without being visible in the table,
can also be changed this way.
Evaluating

6.4

List Maintenance

Several transactions in APO use a list layout to show the selected data. Examples are the
transportation lane master data maintenance transaction. the alert monitor, and the TLB view of
the SDP Interactive Planning screen. These transactions fall back onto the same basic list
maintenance functionality that is described here. One of the views of the generated list is Print
Preview, which is not only another way of displaying the data but also offers an array of
additional functionality. Some of the available functionality requires the installation of specific
software on the local PC.
A collection of pushbuttons can be found above the list that have the same functionality
irrespective of the transaction the list is residing in. The sequence of the buttons sometimes
differs from one transaction to the next.
Common Pushbuttons
Sort Ascending (Descending)
Sorts the list in ascending (descending) order based on the selected
column. If no column was selected prior to activating this pushbutton,
the Define Sort Order pop-up window is displayed.
Columns on which the sort order is based are marked by a small red
triangle on the top pointing up or down depicting ascending or
descending order for the column.
Find
Tool to find a string of characters in the list.
This function may not be available in all transactions.
Set Filter
The Set Filter pushbutton has two functions. If pressed on the right it
allows setting or removing of a defined filter. If pressed on the left, it is
used to define a filter.
Columns for which a filter is active are marked by a small black triangle
on the bottom.
These functions may not be available in all
transactions. Print

Prints the list and also provides a print preview option

Views
Use this pushbutton to switch the display to one of the following options:

Print Preview

Evaluating

669

This option provides all data in a list format from further processing
can be started (e.g. download to Microsoft Word or Excel).

Grid (the standard view)

This is the standard view providing all functionality as described.

Excel In-place
Opens Microsoft Excel, which needs to be installed on the local PC.
If the software is not installed, the option is still available but will be
ignored if used.

Crystal Reports Preview

Opens Seagate Software Crystal Reports, which needs to be installed
on the local PC. If the software is not installed, the option is still
available but will be ignored if used.

The selected option is the one that appears gray

shaded. Export
Allows exporting the list data to external files such as for example
spreadsheets, text documents, or HTML documents. The Export
function also allows switching over into an ABC analysis tool or to send
information to other users. This function is an extremely powerful tool
worthwhile investigating in all depth and width.
Select Layout
The Select Layout pushbutton has two functions. If pressed on the right
it opens the options to select, change, save, or manage layouts. If pressed
on the left, it is used to select an existing layout.
The Define Sort Order Pop-up Window
This window allows using any combination of columns to be defined as sort criteria. Even the sort
direction (ascending or descending) can be defined per column.

Resolving

Resolving

Path:
Technical Name:

673

Supply Chain Monitoring > Alert Monitor

/SAPAPO/AMON1

Irrespective of how the Alert Monitor was started it always appears the same way. The screen is
divided into three panels that appear in tree and list structure.
The View Panel
The view panel on the top left side of the screen provides an indication in which areas alerts exist.
Selecting any of the lines under the Views header displays in the Alert Objects panel the
objects that cause alerts. The following possible entries for the Views header exist:

01Location Product View

02Resource View

03Supply and Demand Planning

06Order View

10R/3 MRP Alerts

15ATP Product Allocation View

20Transport View

25Vehicle Scheduling Messages View

26Vehicle Scheduling Transport View

27Vehicle Scheduling Units View

28Tendering Alerts

30Demand Planning

35Forecast View DP
Under the Alert Views header one line per alert type is displayed. If there are for example alerts
that belong to 4 different alert types, the system displays the 4 respective alert type descriptions.
Selecting any of the lines under the Alert View header displays in the Alert Object Box the
objects that cause alerts. To see the alert objects of a certain view, simply click (dont doubleclick) on the respective line in the view box.
The Alert Objects Panel
The alert objects are the master data objects that cause the alert. These are for example products,
resources, and orders. The way the alert objects are displayed depends on the selected view in the
view box. To see the alerts of an alert object, simply click on the box in front of the respective
alert object in the alert objects box. Clicking on the name of the alert object drills down one level
in the alert objects hierarchy. The alert objects hierarchy is predefined but can be customized.
The Alert List Panel
The alert list panel provides the planner with detailed information of any alert that was selected in
the alert objects view. The display is subdivided into segments, each segment showing alerts of a
specific alert object type. The alert list panel is an interactive list with drill-down capabilities. The
fields displayed in the alert list panel depend on the selected alert objects. Amongst other
functions, the list can be sorted as required, totaled, and printed. Activating the context sensitive
menu on any
Resolving

alert provides the user with a selection of applications that can be started right away from the
alert monitor. The object that is related to the alert is then shown in the used transaction.

Pushbuttons Alert List Panel

Sort Ascending (Descending)
Sorts the list in ascending (descending) order based on the selected
column. If no column was selected prior to activating this pushbutton,
the Define Sort Order pop-up window is displayed.
Columns on which the sort order is based are marked by a small red
triangle on the top pointing up or down depicting ascending or
descending order for the column.
Print
Prints the list and also provides a print preview option
Views
Use this pushbutton to switch over the display to Print Preview (which
opens a new screen), to Grid (the standard view) or Excel In-place.
Export
Allows exporting the list data to external files such as for example
spreadsheets, text documents, or HTML documents. The Export
function also allows switching over into an ABC analysis tool or to send
information to other users. This function is an extremely powerful tool
worthwhile investigating in all depth and width.
Select Layout
The Select Layout pushbutton has two functions. If pressed on the
right it opens the options to select, change, save, or manage layouts. If
pressed on the left, it is used to select an existing layout.
Hide Alerts
Select this button to hide the selected alert(s). Select alerts by
highlighting the corresponding line(s). Use Shift and Control for multiple
selections.
Show Alerts
Opens a pop-up window that permits hidden alerts to be displayed again.
This pushbutton is only visible if hidden alerts exist.
Acknowledge Alerts
Acknowledges selected alerts. Select alerts by highlighting the
corresponding line(s). Use Shift and Control for multiple selections.
Undo Acknowledge Alerts

Resolving

675

Undo the acknowledgement.

Delete Alerts
Delete the selected alert(s). Select alerts by highlighting the
corresponding line(s). Use Shift and Control for multiple selections.
Forward Alerts
Forward an alert to another user via SAP Office.
Freeze Alerts
Freeze the selected alert. Select alerts by highlighting the corresponding
line(s). Use Shift and Control for multiple selections.
Undo Freeze Alerts
Undo the freeze. This pushbutton is only visible if frozen alerts exist.
The fields of the alert list panel depend on various factors such as the alert type and the planning
area they were generated for. For Demand Planning alerts, all characteristics of the planning area
are listed as separate columns. They either show a discrete value (e.g. a product number) or they
are left blank. Blank values occur when the data was selected on an aggregated level (e.g. product
group) and the alert relates to the aggregate.
Other Functions

Alert Deletion
Alerts in general are not automatically deleted by the system once they refer to situations that
are then in the past. Alerts should be dealt with while there is time to react. After the planner
has attended to the situation, he or she can manually delete specific alerts or ranges of alerts.
If this is done although the alert condition is still true, then the system might re-create the alert
with the next planning activity. In such a case, where the cause of the alert cannot be changed,
the alert should rather be acknowledged.
Specifying one or multiple of the following selection options allows the selective deletion of
alerts:
Alert Application Area
e.g. application area Supply and Demand Planning
Planning Version
e.g. the active planning version 000
Alert Object Type
e.g. SDP Data Base Macro Alerts
Alert Type
e.g. Backlog (DB Alert)
Priority
e.g. Warning
Time Horizon
e.g. Date/Time of Creation on or before 03.03.01 11:00.00
or Number of Days in the Past equal to 2 (or more)

Resolving

676

Dynamic alerts do not need to be deleted, as they only exist during the SDP planning activity.
They are not stored and lost when leaving the transaction.

7.1.1

Alert List

Alert Application Area

Alert Object Type Number Description
Forecast (Demand Planning)
4500 Demand Planning Forecast Alerts
SDP (SNP without TLB / Deployment)
4000 SDP Database Macro Alerts
4200 SDP Dynamic Macro Alerts
TLB / Deployment
1000 Deployment Product Alerts
1500 Transportation Alerts Utilization
Table 89 Alert List

7.1.1.1

Forecast Alerts

Alert Object Type 4500 Demand Planning Forecast Alerts

Alert Type
0411
Description
Cause
Display
Solution
Alert Type
0420
Description
Resolving

Alert Type
0420
Cause

Background

Display
Solution
Alert Type
0421
Description
Cause
Background

Display
Solution
Alert Type
0422
Description
Cause
Background
Resolving

Alert Type
0422

Display
Solution
Alert Type

0423
Description
Cause
Background

Display
Solution
Alert Type
0424
Description
Cause
Background

Resolving

Alert Type
0424
Display
Solution
Alert Type
0425
Description
Cause
Background

Display
Solution

Alert Type
0440
Description
Cause

Background

Display
Solution

Alert Type
0441
Resolving

Alert Type
0441
Description
Cause

Background

Display
Solution

Alert Type
0442
Description

Cause

Background
Display
Solution

Alert Type
0443
Description
Cause
Resolving

Alert Type
0443

Background

Display
Solution

Alert Type
0444
Description
Cause

Background

Display
Solution

Alert Type
0445
Resolving

Alert Type
0445
Description
Cause

Background

Display
Solution

Alert Type
0446
Description
Cause
Background

Display
Solution
Alert Type
0447
Description
Cause
Background

Resolving

Alert Type
0447

Display
Solution
Table 90 Forecast Alerts

7.1.1.2

SDP Alerts

Alert Object Type 4000 SDP Database Macro Alerts

Alert Type
0100
Description
Cause

Display
Solution

Alert Type
0101
Description
Cause

Display
Resolving

Alert Type

0101
Solution

Alert Type
0102
Description
Cause

Display
Solution

Alert Type
0103
Description
Cause

Display
Solution

Alert Type
1000
Description
Cause

Resolving

Alert Type
1000
Display
Solution

Alert Type

1001
Description
Cause
Display
Solution

Alert Type
1002
Description
Cause

Display
Solution

Alert Type
4100
Description
Cause

Resolving

Alert Type
4100
Display
Solution

Alert Type
4101
Description
Cause

Display

Solution

Alert Object Type 4200 SDP Dynamic Macro Alerts

Alert Type
0100
Description
Cause

Display
Solution

Alert Type
0101
Description
Cause
Resolving

Alert Type
0101

Display
Solution

Alert Type
0102
Description
Cause

Display
Solution

Alert Type
0103
Description
Cause

Display
Solution

Alert Type
1000
Description
Resolving

Alert Type
1000
Cause

Display
Solution

Alert Type
1001
Description
Cause
Display
Solution

Alert Type
1002
Description
Cause

Display
Solution

Table 91 SDP Alerts

Resolving

7.1.1.3

TLB Alerts

Alert Object Type 1000 Deployment Product Alerts

Alert Type
2200
Description
Cause

Display
Solution

Alert Type
2201
Description
Cause

Display
Solution

Alert Object Type 1500 Transportation Alerts Utilization

Alert Type
2100
Description
Cause

Resolving

Alert Type
2100

Display
Solution

Alert Type
2101
Description
Cause

Display
Solution

Alert Type
2102
Description
Cause

Display
Solution
Resolving

Table 92 TLB Alerts