You are on page 1of 721

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