SPP Springer Book - Second Edition PDF

Management for Professionals
Jörg T. Dickersbach
Michael F. Passon
Service Parts
Planning with
SAP SCM™
Processes, Structures, and Functions
Second Edition
pradeep.kumar1@gmail.com
More information about this series at
http://www.springer.com/series/10101
Jörg Thomas Dickersbach • Michael F. Passon
Service Parts Planning

TM
with SAP SCM
Processes, Structures, and Functions
Second Edition
Jörg Thomas Dickersbach Michael F. Passon
Landau, Germany Heidelberg, Germany
ISSN 2192-8096 ISSN 2192-810X (electronic)

ISBN 978-3-662-45432-9 ISBN 978-3-662-45433-6 (eBook)
DOI 10.1007/978-3-662-45433-6
Library of Congress Control Number: 2015937186
Springer Heidelberg New York Dordrecht London

# Springer-Verlag Berlin Heidelberg 2015
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or
information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt
from the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book
are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, express or implied, with respect to the material contained herein or for any errors
or omissions that may have been made.
Printed on acid-free paper
Springer-Verlag GmbH Berlin Heidelberg is part of Springer Science+Business Media

(www.springer.com)
Preface
The first edition of this book in 2006 was also the first edition of the SAP Service
Parts Planning solution, and there was little experience of using the solution in
practice. Meanwhile, there is a broad adoption of the solution, mainly in the
automotive and mechanical engineering industry, especially the renewable energy
sector, and in the aircraft industry. A typical trait seems to be the global rollout to all
organizations of a company, and due to the large number of organizations involved,
the projects might take some time—currently there are projects running with a
planned timeline until 2019.
Also the solution itself has become more mature with the latest releases—up to
now release SAP SCM 7.0 EHP3—and has both extended its functional scope—
especially in the areas of DRP, deployment, and forecasting—and improved its user
experience. For the latter, the planner’s worklist is the most significant improve-
ment. The reality check in the implementations also showed that the originally
intended “full-blown” system architecture for Service Parts Management
containing SAP CRM, SAP SNC, and SAP EWM was seldom used—in most
cases, it was only SAP SPP and SAP ERP, which can be implemented much faster
than the “full-blown” system architecture.
We were fortunate to have Michael F. Passon as the co-writer who has both the
experience from numerous projects as of course the up-to-date detailed functional
knowledge to update and significantly extend the first edition. This edition contains
a lot of changes and extensions; however, we have not updated all screenshots but
only those that contain significant differences to the previous version.
Much of the credit for this second edition goes to Michael Krenbauer, the
product owner for SPP. Without him this book literally would have not been
possible. He did not only provide us generously with advice and information but
even took the initiative to convince us to update this book. We would also like to
thank Mikael Tängemo, Gerhard Gschwender, Christian Werner, Andreas
Leinenbach, Zoltan Zavodi, Gabor Nagy, Zsolt Csoka, Sandor Miklos, and Tibor
Paulinusz for their help and comments.
Jörg Thomas Dickersbach and Michael F. Passon

Landau and Heidelberg/Germany, August 2014
ThiS is a FM Blank Page
Contents
1 Service Parts Planning Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Supply Chain Management for Service Parts . . . . . . . . . . . . . 1
1.2 Overview on Systems and Processes for Service
Parts Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Processes for Service Parts Planning . . . . . . . . . . . . . . . . . . . 5
1.3.1 Scope and Limitations of This Book . . . . . . . . . . . . . 12
2 Master Data, Services and Basis Functions . . . . . . . . . . . . . . . . . . . 13
2.1 Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Bill of Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Virtual Location for Consolidated Ordering . . . . . . . . 18
2.1.3 Contract Packager . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.4 Product and Product Group . . . . . . . . . . . . . . . . . . . . 23
2.1.5 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.6 Rounding Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3 Planning Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Transactional Data Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 Capture and Manage Demand History . . . . . . . . . . . . . . . . . . . . . . 49
3.1 Process and Data Flow Overview . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Capture Demand History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1 Data Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.2 Processing of the Demand History . . . . . . . . . . . . . . 54
3.3 Manage Demand History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4 Stocking Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1 Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2 Replenishment Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Rules and Decision Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4 Stocking and De-Stocking Service and Approval . . . . . . . . . . 77
vii
viii Contents
5 Forecasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Planning Book, Forecast Profile and Forecast Service . . . . . . . 84
5.2.1 Planning Book for Forecasting . . . . . . . . . . . . . . . . . 84
5.2.2 Forecast Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.3 Forecast Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.3 Model Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.3.1 Historical Forecast . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.3.2 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.3 Tripping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.4 Model Selection and Parameter Tuning . . . . . . . . . . . . . . . . . 107
5.4.1 Model Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.4.2 Parameter Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.5 Calculation of the Forecast . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.5.1 Forecast Horizons . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.5.2 Forecast Model Overview . . . . . . . . . . . . . . . . . . . . . 111
5.5.3 Standard Deviation . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.5.4 Outlier Correction . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.6 Forecast Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.7 Life Cycle Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.7.1 Phase-In Forecasting . . . . . . . . . . . . . . . . . . . . . . . . 125
5.7.2 Phase-Out Forecasting . . . . . . . . . . . . . . . . . . . . . . . 127
5.8 Leading Indicator Based Forecasting . . . . . . . . . . . . . . . . . . . 129
5.8.1 Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.8.2 Basic Settings and Prerequisites . . . . . . . . . . . . . . . . 131
5.8.3 Determination of the History of the Leading
Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.8.4 Determination of the Forecast of the Leading
Indicator and the Relevant Service Parts . . . . . . . . . . 136
6 Economic Order Quantity and Safety Stock . . . . . . . . . . . . . . . . . . 139
6.2 Economic Order Quantity and Safety Stock . . . . . . . . . . . . . . 140
6.2.1 Economic Order Quantity . . . . . . . . . . . . . . . . . . . . . 140
6.2.2 Safety Stock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.2.3 Interdependency of EOQ, Safety Stock and TSL . . . . 145
6.2.4 EOQ and Safety Stock Planning Service . . . . . . . . . . 147
6.3 Planning Book for Inventory Planning . . . . . . . . . . . . . . . . . . 151
6.4 Additional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.4.1 Deployment Indicator Determination . . . . . . . . . . . . . 153
6.4.2 ABC Classification . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Contents ix
7 Surplus and Obsolescence Planning . . . . . . . . . . . . . . . . . . . . . . . . 155

7.2 Surplus Quantity Determination . . . . . . . . . . . . . . . . . . . . . . . 157
7.2.1 Overview and Common Steps . . . . . . . . . . . . . . . . . . 157
7.2.2 Surplus Quantity Determination for Current
Model Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.2.3 Surplus Quantity Determination for Past
Model Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.3 Surplus Disaggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
7.4 Surplus Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.5 Obsolescence Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8 Distribution Requirements Planning . . . . . . . . . . . . . . . . . . . . . . . . 171
8.2 DRP Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.2.1 DRP Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.2.2 Forecast Versus Customer Requirements . . . . . . . . . . 181
8.2.3 Rounding to Days of Supply . . . . . . . . . . . . . . . . . . . 183
8.2.4 Fixed Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.3 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
8.4 Horizons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.5 Stability Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
8.6 DRP Features for Seasonality . . . . . . . . . . . . . . . . . . . . . . . . 204
8.6.1 Anticipated Demand Coverage . . . . . . . . . . . . . . . . . 204
8.6.2 Pre-season Safety Stock Shift . . . . . . . . . . . . . . . . . . 207
8.7 Procurement Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.7.1 Sourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.7.2 Product Group Procurement . . . . . . . . . . . . . . . . . . . 210
8.7.3 Supplier Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . 214
8.8 DRP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
8.9 Repair or Buy Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
8.9.1 Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
8.9.2 Repair or Buy Planning Logic . . . . . . . . . . . . . . . . . . 223
8.10 Kit to Stock Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.10.2 Kit to Stock Planning Logic and Parameters
(Determinants) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
8.11 Reorder Point-Based Planning . . . . . . . . . . . . . . . . . . . . . . . . 240
9 Procurement Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
9.2 Approval Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
9.3 Procurement Approval Service . . . . . . . . . . . . . . . . . . . . . . . 253
9.4 Mass Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
9.5 Interactive Approval in the Schedule Board . . . . . . . . . . . . . . 256
9.6 Release Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
9.7 Procurement Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
x Contents
10 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
10.2 Pull Deployment and Push Deployment . . . . . . . . . . . . . . . . . 267
10.2.1 Difference Between Pull and Push Deployment . . . . . 267
10.2.2 Event Driven Quantity Assignment . . . . . . . . . . . . . . 270
10.3 Available Quantity and Demands for Deployment . . . . . . . . . 272
10.4 Priority Tiers, Fair Share and Sequence Rules . . . . . . . . . . . . 277
10.5 Push Deployment from Supplier . . . . . . . . . . . . . . . . . . . . . . 284
10.6 Multi-level-Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
10.6.1 Multi-level Push Deployment . . . . . . . . . . . . . . . . . . 295
10.6.2 Multi-level Tier Processing . . . . . . . . . . . . . . . . . . . . 302
10.7 Express Shipments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
10.8 Deployment Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
10.9 Stock Transfer Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
10.10 Stock Transfer Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
10.11 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
11 Inventory Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
11.2 Inventory Balancing Area . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
11.3 Excess and Need Determination . . . . . . . . . . . . . . . . . . . . . . . 330
11.4 Cost and Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
11.4.1 Cost and Benefit Analysis Overview . . . . . . . . . . . . . 333
11.4.2 Inventory Savings . . . . . . . . . . . . . . . . . . . . . . . . . . 334
11.4.3 Warehouse Space Savings . . . . . . . . . . . . . . . . . . . . 335
11.4.4 Service Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
11.4.5 Move Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
11.5 Inventory Balancing Services . . . . . . . . . . . . . . . . . . . . . . . . 340
11.6 Inventory Balancing Stock Transfer Approval . . . . . . . . . . . . 341
12 Interchangeability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
12.1 Process Overview of Supersession . . . . . . . . . . . . . . . . . . . . . 343
12.2 Interchangeability Master . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
12.3 Supersession Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
12.4 Realignment for Supersession . . . . . . . . . . . . . . . . . . . . . . . . 364
12.5 Stocking/De-Stocking with Supersession . . . . . . . . . . . . . . . . 365
12.6 DRP with Supersession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
12.7 Deployment with Supersession . . . . . . . . . . . . . . . . . . . . . . . 368
12.8 Inventory Balancing with Supersession . . . . . . . . . . . . . . . . . 370
12.9 Interchangeability with FFF-Classes . . . . . . . . . . . . . . . . . . . 370
13 Sales Order Fulfilment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
13.2 Sales Order Taking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
13.2.1 Basic Sales Configuration for SAP CRM™ . . . . . . . . 378
13.2.2 Sales Order Taking in SAP CRM™ . . . . . . . . . . . . . 380
Contents xi
13.3 ATP Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

13.4 Processing of Unchecked Deliveries . . . . . . . . . . . . . . . . . . . . 385
13.5 Goods Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
14 Monitoring and Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
14.1 Monitoring and Reporting Overview . . . . . . . . . . . . . . . . . . . 391
14.2 Planner’s and Customer’s Worklist . . . . . . . . . . . . . . . . . . . . 392
14.2.1 Overview of Planner’s and Customer’s Worklist . . . . 392
14.2.2 Action Required Queries in Planner’s Worklist . . . . . 394
14.2.3 Alert Queries in Planner’s Worklist . . . . . . . . . . . . . . 396
14.2.4 Monitoring Queries in Planner’s Worklist . . . . . . . . . 398
14.2.5 Customer’s Worklist and its Queries . . . . . . . . . . . . . 400
14.2.6 Configuration of Worklists . . . . . . . . . . . . . . . . . . . . 402
14.3 Shortage Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
14.4 Alert Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
14.5 SPP Cockpit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
14.6 Product Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
14.7 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
15 Original Equipment Manufacturer Managed Inventory . . . . . . . . . 427
15.1 OEM MI Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
15.2 Master Data for OEM MI . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
15.3 Capture and Manage Demand for OEM MI . . . . . . . . . . . . . . 432
15.4 Inventory Planning for OEM MI . . . . . . . . . . . . . . . . . . . . . . 437
15.5 Forecasting for OEM MI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
15.6 DRP for OEM MI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
15.7 Deployment and Inventory Balancing for OEM MI . . . . . . . . . 440
15.8 Supersession for OEM MI . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
16 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
16.1 Current and Future Improvements: “Customer Connection”
Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
16.2 SPP on HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
16.3 SPP and EIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
OSS Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Service Parts Planning Overview
1
1.1 Supply Chain Management for Service Parts
Supply chain management is the process of planning, implementing, and

controlling the operations of the supply chain with the purpose to satisfy customer
requirements as efficiently as possible. SCOR structures the supply chain manage-
ment processes into plan, source, make, deliver and return (SCOR 2006). Another
way to structure the processes is to differentiate between goods movements within
the company and goods movements to the external customer resulting in a structure
as demand planning, order fulfilment, distribution, production and procurement
(Dickersbach 2008). These structures fit for most of the companies—at least we are
not aware of any counter-example—even though the supply chain and the supply
chain management might look very different from company to company—
especially across different industries. From this point of view, the same approach
fits for service parts as well. Nevertheless there are several specific features for
service parts planning which have justified SAP AG in alliance with Caterpillar
Logistics Services, Inc. and Ford Motor Company to build a completely new
solution for Service Parts Management (SPM). According to the nature of the
development partners, the primary industry focus within the SPM solution is
engineering, construction and automotive.
High Number of Service Parts

Supply chain management for service parts deals usually with a very high number
of SKUs. This becomes plausible when comparing the number of finished products
of an automotive or an engineering company with the number of service parts for
their primary products. Differing from the production, the service parts have to be
available at several warehouses in order to ensure a fast delivery. This leads to a
multiplication of SKUs.
Another factor is that service parts have to be available for quite a long time after
the production of the primary product has ended. There are legal retention periods
for service parts but many companies keep service parts available even longer.
# Springer-Verlag Berlin Heidelberg 2015 1

J.T. Dickersbach, M.F. Passon, Service Parts Planning with SAP SCM™,
Management for Professionals, DOI 10.1007/978-3-662-45433-6_1
2 1 Service Parts Planning Overview
Mercedes-Benz e.g. guarantees an availability of 10 years after the production end

date (Arnold et al. 2002).
Authorized Stocking List

Service parts logistics combines a high number of service parts with a high number
of warehouses. At the same time many of the service parts are slow movers.
Therefore the decision whether to keep a service part on stock at the different
warehouses is more significant than for normal logistics. These stocking decisions
are combined in the authorized stocking list.
Sporadic Demand
One of the most distinct characteristics for service parts is the high portion of
products with sporadic demand. Most of the service parts are required if there is a
failure in the primary product—due to wear, accident or other. These failures are
hardly predictable, and there is a multitude of possibilities for failure. Therefore the
failures which relate to a specific service part are usually comparatively seldom,
which results in a sporadic demand. Naturally there are also fast movers among the
service parts.
Availability and Safety Stock

If a vital or an essential part of the primary product fails, an immediate substitution
(and repair) is required. The costs associated with the downtime of the primary
product might be very high—in the case of a bottleneck machine up to the
production downtime a complete factory, in the case of an automotive this might
lead to a significant loss of customer satisfaction. Therefore the availability of the
service part on stock is of high importance in SPM. Taking into consideration that
there is a high portion of sporadic demand (which is difficult to predict) and that the
service part has to be on stock in case of need, the importance of safety stock
planning becomes obvious.
Preventive Maintenance
Preventive maintenance based on the operating time or the mileage (which is
essential e.g. for aerospace) is not the focus of this solution. Naturally some service
parts are requested for preventive maintenance as well—e.g. gear belts for
automotives—but in the current release of SAP SCM™ 7.0 there is no link to
derive the demand from the installed base.
Service Parts Production

Most companies have a separation between their main business—the production of
the primary goods—and their service parts business. Often the service parts are
produced in the manufacturing plant like the components of the primary product,
but sales and distribution of the service parts belongs in most cases to a separate
organization (Arnold et al. 2002). In line with this organizational structure, the SPM
solution focuses on the distribution and the availability of the service part at the
1.2 Overview on Systems and Processes for Service Parts Planning 3
warehouses within the supply chain. All service parts are considered as externally
procured—either via scheduling agreements or via contracts.
Repair/Remanufacturing
Depending on the value of the service part, repairing and overhauling is an
alternative to new procurement. This is especially the case in the aerospace and
automotive industry. A common concept is to have remanufactured parts—e.g.
engines—in a stocking and repair cycle. The planned availability of the
remanufactured service part depends on the number of ‘old’ parts, the repairability
and the repair capacity.
Profitability
Another reason that justifies a new solution especially for service parts is the high
profitability of the service parts business.
1.2 Overview on Systems and Processes for Service Parts

Planning
The purpose of service parts planning is to determine and to ensure the required
inventory levels at the distribution centers of the supply network in order to meet
the target service levels and to plan the procurement of the service parts from
external suppliers and their replenishment within the supply network. In-house
production is not considered in this solution—if the company produces the service
parts itself, the production has to be modelled like an external supplier. Service
parts planning is however only one part of the SPM solution. Besides service parts
planning, the SPM solution covers additionally the following areas:
• sales, claims and returns, and entitlement management

• procurement execution
• stock transfer execution
• warehouse management
• monitoring and reporting of the service parts supply chain
The functions for the SPM processes are available based on the system landscape
containing SAP ERP™ 6.0, SAP CRM™ 7.0 (Customer Relationship Manage-
ment), SAP APO™ (Advanced Planner and Optimizer), SAP SNC™ (Supplier
Network Collaboration) and SAP EWM™ (Extended Warehouse Management)
within SAP SCM™ 7.0 and SAP Netweaver™ 7.4 including SAP PI™ and SAP
BI™ (Business Information Warehouse).
Figure 1.1 provides the overview of the systems for the full scope of SPM.
Service parts planning—which is the focus of this book—is entirely within SAP
APO™. Monitoring—e.g. the alert monitor—is done in SAP SNC™ based on
common tables within SAP SCM™. SAP BI™ offers reports for the measurement
of the supply chain performance towards the customer, within the supply chain and
from the supplier based also on the data within these common tables.
Fig. 1.1 System landscape for full scope service parts management
However, the experience from the SPM project shows that most customers
prefer to use a more simple landscape over the full blown functionality. The most
frequently applied system landscape contains only SAP ERP™ for execution, SAP
APO™ for service parts planning and optionally an external SAP BI™ for
reporting. Figure 1.2 shows this simplified system landscape.
Fig. 1.2 Most frequently used system landscape for service parts management
1.3 Processes for Service Parts Planning 5
1.3 Processes for Service Parts Planning
Service Parts Execution

Sales order taking, claims and returns and entitlement management is based on SAP
CRM™. Other parts of the order fulfilment process are the ATP check in SAP
APO™, the processing of the delivery in SAP ERP™ and the goods issue in SAP
EWM™. The order fulfilment processes include sales from stock and sales from a
third party vendor to the customer as triangular business. Chapter 13 provides a
brief overview of the sales from stock process.
Procurement execution starts with the releases for scheduling agreements or the
purchase requisitions for contracts and involves SAP ICH™ (where the supplier
creates ASNs), SAP ERP™ for the validation of the ASN and SAP EWM™ for the
goods receipt. The procurement execution is sketched in Sect. 9.7 subsequently to
the procurement approval and the release creation.
The execution of stock transfers is based on stock transfer orders that are created
by service parts planning (in deployment or in inventory balancing). The stock
transfer orders are sent from SAP APO™ to SAP ERP™. Goods issue at the source
location and goods receipt at the target location are performed in SAP EWM™.
Section 10.8 gives a short description about the stock transfer execution.
Service Parts Planning Within SAP APO™

The focus of this book is the service parts planning processes which are entirely
within SAP APO™. Though service parts planning covers similar processes as
Demand Planning and Supply Network Planning in SAP APO™, it relies on
completely new functions. Therefore there is no process interface with the ‘normal’
SAP APO™ functions. Apart from that mixing service parts planning with the SAP
APO™ modules DP, SNP or PP/DS for the same location product is not intended
and might lead to inconsistencies.
Service parts planning does however use the same master data objects for
location, product, transportation lane and procurement relationship—though in
most cases separate fields. All these master data objects are enhanced with new
fields. The integration of service parts planning with SAP ERP™ is done via CIF
like for ‘normal’ SAP APO™. Compared to DP and SNP in SAP APO™, service
parts planning offers some additional functions, but is also missing some
functions—e.g. aggregated planning and macros in forecasting—and uses a differ-
ent logic for similar functions.
SAP APO™ can be used as an add-on of SAP-ERP. The installation of a separate
SCM server can be avoided then. However, if the service parts planning functions is
deployed then a separate SCM server installation is necessary.
Service Parts Planning Overview

Service parts planning is concerned with the forecasting, inventory planning,
procurement and distribution of the service parts to the customer facing locations
in order to keep the target service levels. The planning functions and processes for
service parts planning are shown in Fig. 1.3 and range from the capturing and
managing of the demand to the planning of the procurement and the stock transfers.
Tactical Planning Operative Planning
Capture Demand
DRP
History
Stocking & Procurement

De-Stocking Approval
Monitoring & Reporting
Manage Demand Procurement

History Execution
Forecasting Deployment
EOQ & Safety Stock Inventory Balancing
Surplus & Stock Transfer

Obsolescence Planning Execution
Service Parts Planning Service Parts Execution
Fig. 1.3 Overview of service parts planning processes
The processes for the tactical planning scenario span the medium- to long-term
range and are based on time buckets of months, fiscal year periods or even weeks.
The processes starting from the capturing of historical demand to the stocking
decision, the adjustment of the demand history, the forecasting and the determina-
tion of the economic order quantity and the safety stock levels (and optionally
surplus and obsolescence planning) are considered as tactical. The results of the
tactical planning are
• decision about stocking or de-stocking

• forecast based on the demand history
• safety stock and economic order quantity
for each location product and—optionally—the scrapping of surplus quantity.

This information is used by the operational planning processes which are based
on daily buckets. DRP (distribution requirements planning) determines the required
procurement quantity depending on the stock and order situation in the network.
The procurement proposals are checked in the procurement approval process and
released. Sending the releases to the supplier, receiving ASNs from the supplier and
posting goods receipt are parts of the procurement execution. Based on the received
inventory the service parts are replenished to the warehouses in the deployment
process. In case that lateral stock transfers between warehouses are required,
inventory balancing is used. In both cases stock transfers are created and sent to
SAP ERP™ for execution. The result of service parts planning is that the stocked
customer facing warehouses have sufficient inventory to fulfil the customer

requirements. Each of these processes is described in the following chapters.
Chapter 12 explains how supersession—i.e. the replacement of one service part
with one or more other service parts—is applied for service parts planning.
Service parts planning is almost entirely based on forecast, and sales order
fulfilment is not part of service parts planning. Nevertheless Chap. 13 gives a
brief overview of the order fulfilment process for sales from stock. Monitoring
and reporting finally are sketched in Chap. 14.
Business Scenarios and Business Processes Available in SPP

The SPP processes as described above can be combined into different end-to-end
scenarios. The designed end-to-end scenarios are applied at most of the existing
SPP-using service parts companies.
Among others the main business scenarios and business processes supported by
SPP are the following:
Table 1.1 Overview on 1. Inbound Planning Scenario

the main planning streams
1.1. Procure to stock process
and the most relevant
processes 1.2. Kit to stock process
1.3. Repair/remanufacture to stock process
2. Outbound Planning Scenario
2.1. Sell from stock process
2.2. Internal Outbound of stock process
2.3. Bypass process
2.4. OEM-managed inventory process
3. Tactical Inventory Planning Scenario
3.1. Stocking-decision making process
3.2. Safety stock and lot-size determination process
4. Life Cycle Planning Scenario
4.1. Interchangeability planning Process
4.2. Phase-in and Phase-out Forecasting Process
5. Monitoring and Exception Management Scenario
5.1. Alert monitoring process
5.2. Short supply management process
Figure 1.4 gives an idea of where these processes flow through the company’s
network and the surrounding elements. It shows that the organizational units
involved are locations within the planning-network (i.e. bill of distribution
(BOD)) as well as external partners like product suppliers and suppliers of
subcontracting services like repair or kitting. Other external suppliers are contract
packagers. Contract packagers could also be internal departments of the respective
service parts company. The green arrows show the different material flows between
the different units that are planned by SPP.
Fig. 1.4 Overview on the main material flows planned by SPP
The process “procure to stock” is mainly represented by the services and

functions around DRP. DRP generates the procurement plan based on scheduling
agreements (which are represented by external procurement relationships). The
outcome is schedule lines exclusively towards external suppliers, i.e. supplying
locations which are situated outside the BOD, as shown with the number 1.1 in
Fig. 1.5.
Subsequently the creation of the releases is executed as well as their issues.
Further steps like ASN creation, validation and goods receipts are covered by the
respective functions in SAP ERP. The receiving location is the entry location that
originally ordered the product. If a contract packager is organizationally attached to
the entry location then the delivery is received at this contract packager-location.
Fig. 1.5 SPP-processes in inbound planning stream
The process “kit-to-stock” is indicated with the number 1.2 in Fig. 1.5. In
contrast to the process “procure to stock”, several products are involved in the
procurement process. One is the header product, whose independent requirement
has to be fulfilled. The header product is the kit that consists of several other parts.
This fact is represented by a BOM (in SPP: production data structure (PDS)). The
replenishment of the kit takes place via planning and creating work orders, if
in-house kitting is applied. The dependent requirements for the parts of the BOM
are usually procured externally (via the process “procure to stock”). The process
“kit to stock” can have two variants. In-house and external kit to stock. In the latter
also the kit is procured externally but not with a “normal” purchasing process but
with a kind of subcontracting process. The master data involved there are PDSs for
exploding the BOM at the subcontractor side and purchase info records of type
subcontracting in order to plan the procurement of the kit via DRP. Figure 1.5
illustrates the external kitting with the green big circles (number 1.2) on the level of
the entry location. The small green circle illustrates the in-house kitting process.
However the in-house kitting process can also be modelled at a location below the
entry location, whereas the external procurement in case of the “kit-to-stock” as
well as in the “procure-to-stock” takes always place on entry location level.
The process “repair to-stock” is very similar to the “kit to stock”-process. It deals
with products which need to be repaired or remanufactured in order re-sell them and
change their status during repair from ‘unserviceable’ to ‘serviceable’. The repair
can be executed also in-house or externally at subcontracting partners. In both cases

BOMs are needed as master data, where the unserviceable part is the
BOM-component of the serviceable part (which is repaired and re-newed part).
This process can be combined in SPP with repair-or buy decisions where SPP might
decide to apply a procure-to stock process (and order a new part) instead of the
default repair-to-stock process.
The second stream in SPP is about outbound planning, as shown in Fig. 1.6. The
process “sell from stock” (process number 2.1) deals with business relations to
external customers (that are represented by locations that are not part of the BOD
and also outside the legal company code of the service parts company). This process
requires some features that are not entirely covered by SPP but offered as part of
full-scope in SPM.
Fig. 1.6 SPP-processes in the outbound planning stream
The process “Internal outbound of stock” (process number 2.2) is mainly

covered by the SPP-service deployment as described in Chap. 10 in this book.
Based on demand and supply within the company’s network, stock transfers are
created between the corresponding locations involved as result. This happens only
downstream the BOD, whereas the receiving location can be considered as internal
customer. The last internal customer is the customer facing location, from where on
the process “sell from stock” (number 2.1.) continues within this scenario.
The process bypass (number 2.3) has the most variants. There are BOD-internal
bypasses. Under normal circumstances deployment supplies locations from
locations of immediately previous levels. Under certain circumstances it is neces-

sary to leave the standard path of delivering internally and to skip some steps in the
supply chain down to the customer. This process is covered in the function multi-
level-deployment and can skip as many levels of location as necessary.
Another variant of the bypass process is focused on skipping the replenishment
of the entry location, even though the entry location was the ordering unit. In this
case the external supplier supplies directly to one of the internal customers, i.e. any
demand-carrying location below the entry-location level. Even though effectively
this process combines an inbound feature with outbound features, it is subsumed
under the outbound planning stream since the main focus is on the distribution.
Another reason is that in SPP this process is supported by the deployment type
“Push Deployment from Supplier” that is used to fulfil the respective demand on
different child locations. The planning results are nevertheless schedule lines
coming directly from the external suppliers.
Another variant of the bypass process is a direct delivery from a contract
packager—no matter whether it is in an external or an internal contract pack-
ager—to one of the demand carrying child locations within the BOD. The contract
packager is modeled as a location (derived from an MRP type in SAP ERP) which is
attached to its master location in the BOD. The contract packager itself is not part of
the BOD in any case. Under normal circumstances the contract packager would
supply only to his master location where he is attached to. If the contract packager’s
master location does not have an own demand the supplying the master location can
be skipped and a bypass takes place directly to the child location. This bypass is
supported by the SPP service “Push deployment from contract packager”
(described in Chap. 2 in this book). The result of this planning service are stock
transfers. The further processing of this stock transfers including outbound
deliveries and inbound deliveries as well as goods movements are done in
SAP ERP.
The fourth variant of the bypass process is “third party order processing”
(TPOP). This process circumvents the whole BOD—physically as well as
planning-wise. Even though for this process—like in the case of “sell from
stock”—SPP is only partly responsible, nevertheless e.g. the demand history of
products that are always delivered directly to the customer are captured and
managed in SPP. There are TPOP-specific SPP- forecast services which are dealing
with these specially indicated products. This forecast is then published to the
external supplier via collaboration, so that their target service can be reached also
if the delivery does not come directly from the service parts company.
The process “original equipment manufacturer managed inventory” (OEMMI) is
based on an extension of the BOD as shown as number 2.4 in Fig. 1.6. External
customers—e.g. if they are service provider—are integrated and participate in most
of the planning services and functions as so-called OEMMI-locations. Demand
history is captured and managed directly in the OEMMI-location, which acts
technically like the customer facing location. Like for any customer facing location,
forecast is calculated, DRP plans replenishment and deployment plans the delivery
to this customer location. In this process the external customer acts as internal
customer in the SPP-System and the planning result consequently are stock
transfers with the customer location as receiving location. Since the customer
location is modelled in SAP ERP as an external customer and corresponding
business partner, in one of the next steps within this process the stock transfers
are converted into sales orders in SAP ERP.
The third planning scenario as shown in the Table 1.1. is the tactical inventory
planning. As already described in the section earlier in this chapter this is comprised
of decisions, which are focused on more aggregated time horizons—like weeks or
months. These activities and planning steps are also made on a weekly or monthly
recurring basis. In this manner the process of stocking decision for every SKU takes
place. Once this decision is made for e.g. stocking, a stability period is applied to
stabilize this decision. If the stocking process has decided to stock a certain SKU
then the following process is to determine the figures for the safety stock that should
be kept stable as well as the lot size—either network-internally from the parent
location or network-externally from the external product supplier.
The fourth scenario supports the introduction as well as the end of life of a
service part from the planning point of view. Supersession as a type of interchange-
ability controls the use up of products which are phased-out and complementarily
the planning start of a succeeding new product right in time in order to ensure the
overall target service level. In addition there are processes like phase-in forecasting
and phase-out-forecasting, which are responsible to safeguard smooth ramp-up of
new products in respect to forecast and replenishment planning. Vice versa phase-
out planning can be applied for the corresponding discontinuing product.
1.3.1 Scope and Limitations of This Book
Not all functions of the SPM solution are described in this book—even not all
functions for service parts planning. The focus of this book lies on the planning
functions, therefore monitoring and reporting is not explained in their due depth—
apart from the so-called planner’s worklist. Even within planning some topics as
virtual locations for consolidated ordering and contract packagers are explained
only very briefly. Planning with future BODs, remanufacturing and push deploy-
ment from the supplier are skipped altogether. For a complete picture of the service
parts planning functionality please have a look into the SAP online documentation
for service parts planning.
Master Data, Services and Basis Functions
2
2.1 Master Data
2.1.1 Bill of Distribution
One of the specifics of the service parts solution is that the supply chain network has
a tree-like structure with one or more entry location—this is where the supplier
delivers to—and for each entry location (optionally) one or more child locations.
Looking from the demand side, there is a strict single sourcing. This fix and
hierarchical distribution structure is modelled as a bill of distribution (BOD). The
BOD is used throughout the whole service parts planning solution—from capture
demand to inventory balancing.
Virtual Child Location

Another characteristic of the BOD is that there is a functional separation between
locations that deliver to the customer (also called customer facing locations) and
locations that deliver to other locations (also called parent locations). If one location
does both, a virtual child location is created for this location. All customer related
data—e.g. forecast, safety stock, customer orders—are assigned to the virtual child
location, and the location keeps only the transactional data for its role as a parent
location. This implies that a stock transfer is modelled from the location to its own
virtual child location in order to cover the customer related demand.
Example for a Bill of Distribution

The modelling of the supply chain with the BOD is clarified with the example of a
supply chain as shown in Fig. 2.1.

14 2 Master Data, Services and Basis Functions
London Köln Berlin
Lyon Lille Frankfurt
Stuttgart
Vendor
Fig. 2.1 Example for a supply chain
Each of the distribution centres—except Frankfurt—sell service parts to

customers. Figure 2.2 shows the BOD to model this structure.
Entry Location
Stuttgart
Virtual Child
Location
Lyon Lille Frankfurt Stuttgart
Virtual Child
Location
London Lille Köln Berlin
Fig. 2.2 Bill of distribution for the example
In this case Stuttgart is the entry location of the BOD, and all locations except
Frankfurt are customer locations. The locations Stuttgart, Lille and Frankfurt are
parent locations because they deliver to other locations within the network.
Stuttgart and Lille have virtual child locations in order to separate their role as a
parent and their role as a customer facing location. All locations except the entry
location Stuttgart are child locations to their parent.
Restrictions in the modelling of the BOD are that the tree structure must be
respected and that a location can only be used once within one BOD. It is however
possible to have multiple entry locations within one BOD—e.g. to model different
supply networks in Europe and America. Figure 2.3 shows some alternatives for the
modelling of a BOD.
2.1 Master Data 15
BOD 1 BOD 2 BOD 3
BOD 4
Fig. 2.3 BOD modelling alternatives
Hierarchy Structure
The BOD is a kind of location hierarchy and is therefore based on the hierarchy
structure. The hierarchy structure is defined with the customising path APO !
Master Data ! Hierarchy ! Define Hierarchy Structure, Fig. 2.4.
Fig. 2.4 Hierarchy structure for the BOD
Note that the edge table name has to be /SAPAPO/RELDHBOD or else it is not
possible to set the flag for virtual child locations. The hierarchy structure is linked to
the transaction for creating the BOD by an entry in the customising setting as shown
in Fig. 2.5 (customising path APO ! Master Data ! Product ! Maintain
Product-Relevant Hierarchies and Hierarchy Structures).
Fig. 2.5 Product-relevant hierarchy structures
BOD Maintenance
The BOD is maintained with the transaction /SAPAPO/BOD001. With this trans-
action the hierarchy structure is selected automatically, Fig. 2.6.
Indicator for Virtual Child Location

© SAP AG
© SAP AG
Fig. 2.6 BOD maintenance
The tree structure of the locations is maintained in the bottom part of the screen.
If a location has a virtual child location, the according indicator is set in the top right
area. To display the location in this area, its parent has to be selected in the bottom
2.1 Master Data 17
area. When saving the BOD, it is checked whether transportation lanes exist. After
saving, the BOD must be assigned to the active model 000 in the same transaction.
There is no integration of the BOD from SAP ERP™, but usually there are just a
few BODs per company.
Product Assignment to the BOD

The BOD is defined independent of the products. The assignment of the products to
the BOD is performed with the transaction /SAPAPO/PROD2BOD_M as shown in
Fig. 2.7. A product can be assigned to one BOD only.
Fig. 2.7 Product assignment to BOD
The validity date of the assignment must not be in the past. The assignment of
products to BODs is displayed with the transaction /SAPAPO/PROD_DISP
(products for BOD) or /SAPAPO/PROD2BODDISP (BOD for a product).
Flexible BOD
In SPP exists the possibility to choose between two BOD types: static BOD and
flexible BOD.
The main characteristic of a static BOD is that the product assigned to a BOD
must have existing location product per every location of this BOD.
If one or more corresponding location products were missing the assignment to a
BOD would not be possible at all. If a necessary location product would be deleted
after the assignment of the product to BOD, an error would occur and a
corresponding message would be logged. In case of e.g. a DRP planning, the
whole planning of the respective product would be ceased.
The activation of either static or flexible BOD—as shown in Fig. 2.8—is made
and valid for the whole SPP-system, i.e. for all BOD’s and all products involved.
Fig. 2.8 Setting of BOD type in customizing
The customizing setting can be accessed via APO ! Master Data ! Product !
Product Group ! Define Product Group Type.
2.1.2 Virtual Location for Consolidated Ordering
Virtual locations for consolidated ordering (VLCO) are used to group locations
which are geographically close and have only a small demand. This way the virtual
consolidation location is considered like one location in DRP planning and all
transactional data—stock, demand and fixed receipts—is aggregated to the pre-
ferred location. The preferred location is the location with the longest lead time and
determines also the calendar, the deployment indicator and the rounding rules. As a
consequence, netting is performed within the locations of the virtual consolidation
location and only orders for the net demand are created.
The distribution to the real locations is done in deployment and inventory
balancing. If a virtual consolidation location has registered a net demand, deploy-
ment delivers to the locations according to the demand of the individual locations.
Using virtual consolidation locations has the benefit that netting is performed
within these locations and that the data basis for planning is aggregated.
Regional Pattern Virtual locations for consolidated ordering are defined using a
regional pattern. The prerequisite for defining the virtual locations for consolidated
ordering is that all locations have the same parent. The regional pattern is a
hierarchy structure like the BOD but has a different edge table (/SAPAPO/
RELDHRGP), Fig. 2.9.
2.1 Master Data 19
Fig. 2.9 Hierarchy structure for regional pattern
The hierarchy structure is linked to the transaction for creating the regional
pattern by an entry in the customising setting as shown in Fig. 2.10 (customising
path APO ! Master Data ! Product ! Maintain Product-Relevant Hierarchies
and Hierarchy Structures).
Fig. 2.10 Product-relevant hierarchy structures for regional pattern
The regional pattern is created with the transaction /SAPAPO/RGPAT01.

Figure 2.11 shows a regional pattern containing the locations PLSPG2@Q4L400
and PLSPB1@Q4L400.
Analogous to the BOD, the products are assigned to the regional pattern with the
transaction /SAPAPO/PROD2RGP_M. The assignment is displayed with the trans-
action /SAPAPO/PROD2RGPDISP.
© SAP AG Indicator for Preferred Location
© SAP AG
Fig. 2.11 Regional pattern
Whether consolidated ordering is actually used for a service part is defined by

the parameter ‘consolidated ordering’ in the ‘SPP DRP’-view of the product master,
Fig. 2.12.
Fig. 2.12 Switch for consolidated ordering in the product master
2.1 Master Data 21
2.1.3 Contract Packager
Contract packagers are subcontractors who perform packaging and re-packaging

steps for the warehouses within the BOD. These packaging steps might be required
for any location within the BOD. A contract packager is assigned to one location
within BOD.
The subcontracting process has the downside that the information about the
goods movements at the subcontractor’s warehouse is not visible. Therefore the
contract packagers are modelled as a special type of MRP area within the location
that they are assigned to. The contract packager is obliged to perform his goods
receipts and goods issues with the SAP EWM™ system, and therefore the inventory
and the goods movements of the contract packager are integrated into service parts
planning.
Contract Packager Master Data

The MRP area for the contract packager is defined in SAP ERP™ with the
customising path Production ! Material Requirements Planning ! Master Data
! MRP Areas ! Define MRP Areas as for normal MRP areas. However, to transfer
the MRP area as contract packager to SAP APO™, it is necessary to assign the
business type ‘1’ to the MRP area in SAP ERP™ with the customising path
Logistics Execution ! Service Parts Management ! Contract Packager Inbound
(SPM) ! MRP Area with Business Type, Fig. 2.13.
Fig. 2.13 Assign business type to MRP area in SAP ERP™
This way the MRP area is transferred to APO as a contract packager with the
location type ‘1007’ and the business type ‘1’, Fig. 2.14.
Fig. 2.14 Location for contract packager in SAP APO™
The contract packagers are not part of the BOD. If the contract packager is
assigned to the entry location, the storage location for the contract packager has to
be maintained in the scheduling agreement or the contract. For other locations info
records are required.
Planning with Contract Packagers

The material flow differs when contract packagers are used, because the service
parts are first sent to the contract packagers before they are sent to the location that
they are assigned to. The material flow depends on the deployment indicator which
controls whether pull deployment or push deployment is assumed for planning (see
Sect. 10.2). The speciality of push deployment is that a goods receipt triggers the
deployment run. Figure 2.15 shows the planned material flow—which DRP uses—
depending on the deployment indicator and on how many contract packagers are
used.
2.1 Master Data 23
Supplier Supplier Supplier Supplier
Contract Contract Contract

Contract
Packager Packager Packager
Packager
Entry Loc. Entry Loc. Entry Loc.

Entry Loc.
Contract Contract
Packager
Packager
Child Location Child Location Child Location Child Location

Pull / Plan to Pull Pull / Plan to Pull Plan to Push Plan to Push
Fig. 2.15 Material flow including Contract Packager used by DRP depending on the deployment
indicator
If the deployment to a location is planned as push deployment, the planned

material flow might even skip the entry location.
However, if there is a current need at a location, deployment might alter this
planned material flow. Figure 2.16 shows two examples for a differing material
flow during deployment.
Supplier Supplier
Contract Contract
Packager Packager
Entry Loc.
Push Entry Loc.

Deployment Pull Deployment
Contract
Packager
Child Location Child Location

Plan to Pull Plan to Push
Fig. 2.16 Alternative material flow by deployment
2.1.4 Product and Product Group
The product master has been enhanced for service parts management by approxi-
mately 150 new fields and the following product views:
• Properties of SPP
• Packaging data (used for SAP EWM™)
• Storage (used for SAP EWM™)
• SPP inventory planning
• SPP DRP
• SPP deployment
• SPP inventory balancing/surplus
The location master has been enhanced as well with an ‘SPP’ view. These views
and fields are activated during the system installation with the report /SAPAPO/
SWITCH_ON_SPP_MD_FLD.
Product Group
The product group is used in service parts planning as a criterion e.g. for the
stocking decision, for the exclusion from the stocking decision (see Chap. 4), the
phase-in forecast (see Sect. 5.7), the product group procurement (see Sect. 8.7.2)
and for the determination of the deployment indicator (see Sects. 6.4 and 10.2).
This product group is a new entity and has nothing to do with the product group
used in SAP ERP™. One or more product groups are defined for a product group
type in customising. The customising path for the product group type is APO !
Master Data ! Product ! Product Groups ! Define Product Group Types,
Fig. 2.17.
Fig. 2.17 Product group and product group type
The product group itself is defined with the customising path APO ! Master
Data ! Product ! Product Group ! Define Product Groups. The product group
and the product group type are assigned to the product master as shown in Fig. 2.18.
2.1 Master Data 25
Fig. 2.18 Product group assignment in the product master
The restriction for the use of product groups is that only one product group is
possible per product group type.
2.1.5 Location
The location master has been enhanced for service parts planning with the ‘SPP’-view.
This view contains the profiles for stocking and de-stocking that are used by the
services for the stocking decision and the warehouse space savings profile for inven-
tory balancing. Other entries are the threshold values for surplus planning and the
target service level for monitoring.
In the ‘calendar’-view of the location a new calendar is included—the planning
calendar for service parts planning. This calendar can be used (if defined in
customising) for the scaling of the demand history (see Sect. 3.2) and for the
scheduling of planned stock transfers (see Sect. 8.3). Figure 2.19 shows the
maintenance for the planning calendar for SPP in the location master.
Fig. 2.19 Calendars in the location master
2.1.6 Rounding Profile
The rounding profile is based on the packaging specification and is used in inven-
tory planning, DRP, deployment and in inventory planning. Since the packaging
specification is used also for SAP EWM™ it contains more information than
actually required for service parts planning. Figure 2.20 gives a simplified overview
of the objects within the rounding profile—only those objects are mentioned that
cannot be avoided from a service parts planning perspective.
Packaging
Rounding Profile
Specification
Packaging
Specification Group
Level Type Level Set Number Range
Fig. 2.20 Entities for the rounding profile
The rounding profile is assigned to the service profiles for EOQ and safety stock
calculation, DRP, deployment and inventory balancing. Using the rounding profile
is however optional.
Level Type and Level Set

The packaging specification can have several levels—for example spark plugs are
packed into a box, several boxes are packed into a carton and several cartons are
packed to a pallet. The level type defines e.g. whether this level is relevant for
kitting or rounding, and the level set defines which and how many level types are
used for the packaging specification group.
Level type and level set are maintained with the customising path Extended
Warehouse Management ! Master Data ! Packaging Specification ! Maintain
Structure of Packaging Specification ! Define Level Type respectively ! Define
Level Set, Fig. 2.21.
2.1 Master Data 27
Fig. 2.21 Level type and level set
Packaging Specification Group

The packaging specification group is required for grouping only but nevertheless
necessary in order to create a packaging specification. It is defined with the
customising path EWM ! Master Data ! Packaging Specification ! Define
Packaging Specification Group, Fig. 2.22.
Fig. 2.22 Packaging specification group
Packaging Specification
The packaging specification itself is a master data and maintained with the trans-
action /SCWM/PACKSPEC. Fig. 2.23 shows the maintenance of the packaging
specification SPP0002 which was assigned to the packaging specification group
SPP.
Fig. 2.23 Packaging specification overview
This packaging specification contains two levels (as defined in the level set), the
first level rounds to full quantities only, the second level to 10 pieces. Figure 2.24
shows the packaging specification with the upper and lower rounding limits of 20 %
and the target quantities of the rounding levels (1 piece for first level, 10 pieces for
the second level).
Fig. 2.24 Packaging specification
The target quantity of each level defines how many units of the previous level are
rounded. Therefore the target quantities of each level are multiplied—i.e. in case of
a third level with a target quantity of 20 pieces the smallest quantity at the third
level would be 200 pieces (and not 20 pieces).
Rounding Profile
The packaging specification is assigned to the rounding profile with the customising
path APO ! Supply Chain Planning ! SPP ! Basic Settings ! Define Rounding
Profile, Fig. 2.25.
2.1 Master Data 29
Fig. 2.25 Rounding profile
It is possible to test the rounding behaviour of the rounding profile with the
transaction /SAPAPO/AC12. Figure 2.26 shows the test result for a simulation from
8 to 15.
Fig. 2.26 Test of the rounding profile
Due to the upper and lower rounding limit of 20 % quantities which are less than
20 % from the rounding value are rounded up (in this case from 9 pieces to
10 pieces), and quantities which are not more than 20 % above the rounding
quantity are rounded down (in this case 11 pieces and 12 pieces to 10 pieces).
2.2 Planner
For service parts planning the planner (transaction /SAPAPO/PLANNER) has

additional areas of responsibility as shown in Fig. 2.27.
Fig. 2.27 Responsibility areas for SPP planners
These areas correspond with the assignment in the product master. In service
parts planning the planner is not only used for selection but partially for
authorisation as well. Therefore the user has to be assigned to a planner with the
transaction /SAPAPO/USRPLN, Fig. 2.28.
2.3 Planning Service Manager 31
Fig. 2.28 Assignment of user to planner
A user is only allowed to plan the products which have the same planner
assigned.
2.3 Planning Service Manager
Most of the planning steps for service parts planning are done in the background.
Background planning—whether as a background job or performed at the planner’s
request—uses the planning service manager. The planning service manager
executes the algorithms that are defined in the planning service, configured in the
planning service profile and bundled with other control data in the planning profile.
Figure 2.29 shows the relationship of these objects.
Planning Service Manager Planning Profile
Read/Write
Service Profile
Planning Service
(per Planning Service)
Transactional Data Layer
Fig. 2.29 Planning service manager
The planning service manager accesses the transactional data via the transac-
tional data layer (TDL, see also Sect. 2.4).
Planning Service
The planning services contain the planning algorithms and are configured by the
planning service profiles. Table 2.1 lists some of planning services which are
described together with the corresponding planning service profile at the respective
process chapters.
Table 2.1 Planning services

Service description Service
Realignment (Stocking) SPP_PDEM_STOCKING_RLG
Realignment (Supersession) SPP_PDEM_SUPERSESSION_RLG
Realignment for BOD change SPP_PDEM_BOD_VALID
Forecast SPP_FCS_SERVICE
Forecast disaggregation SPP_FCST_DISAGGREGATION
Forecast: standard deviation SPP_FCS_SERVICE_MSE
Recalculation of forecast in past SPP_FCSTHIST_CALC
Forecast approval SPP_FCST_RELEASE
Phase-In planning service SPP_PHASE_IN
Forecast service (TPOP Selection) SPP_FCS_SERVICE_MSE_TPOP
Forecast service (StdDev. for TPOP) SPP_FCS_SERVICE_TPOP
Forecast approval service (TPOP) SPP_SPP_LFI_SERVICE
Recalc of FCST in past (TPOP) SPP_FCSTHIST_CALC_TPOP
Prep. service for LI-based forecast SPP_LFI_SERVICE
Calculate historical forecast SPP_RECALC_HISTFCST
Forecast profile copy service SPP_FCST_PRF_COPY_SRV
Stocking decision SPP_INVP_STOCKING
De-Stocking decision SPP_INVP_DESTOCKING
EOQ and safety stock SPP_EOQSFT_SERVICE
ABC classification SPP_INVP_ABCCLASS
DRP planning SPP_DRP
Determine of DRP planning mode SPP_DRP_PLANNING_MODE
SPP: DRP release creation SPP_DRP_RELEASE_CREATE
Anticipated demand coverage SPP_PFR
Procurement approval SPP_DRP_APPROVAL
Deployment SPP_DEPL
Push deployment from supplier SPP_DEPL_FROM_SUPPLIER
Inventory balancing SPP_INVENTORY_BALANCING
Inventory balancing w. Unsrv. stock SPP_INVBAL_UNSERVICEABLE
Supersession SPP_SUPERSESSION
Surplus planning SPP_SOS_SURPLUS_DETERMINATION
Obsolescence planning SPP_SOS_OBSOLESCENCE_CHECK
Shortage analysis SPP_SHORTAGE_MONITOR
Planning Profile
All the information that the planning service manager requires is maintained in the
planning profile. The planning profile contains one or more process blocks, and
each process block contains one or more planning services with their planning
service profiles.
Selection Planning Profile

Process Block 10
Planning Service
Version Service List – Sequence 1
Service Profile
(Planning Service Specific)
Process Profile Service List – Sequence N
Trigger Group
Process Block N
Service List – Sequence 1
Fig. 2.30 Planning profile structure
The selection of the products, the planning version, the technical settings in the
process profile and the trigger group are maintained per process block—this way it
is possible to group services into one planning profile that require e.g. different
process profiles. Figure 2.30 provides an overview about the entities which are
required for planning with the planning service manager.
The planning profile is maintained with the transaction /SAPAPO/PE_CFG.
Figure 2.31 shows an example of a planning profile for deployment which contains
one process block with one planning sequence—several planning sequences would
make sense e.g. for forecasting.
Fig. 2.31 Planning profile
Table 2.2 Selection types and planning services

Selection type location product Selection type product
Realignment (for Stocking) Realignment (for
Forecast (Forecasting, disaggregation, standard deviation and Supersession)
approval) Surplus planning
Calculate historical FC Obsolescence check
Stocking and de-stocking decision Shortage analysis
EOQ and safety stock
DRP planning
Anticipated demand coverage
Procurement approval
Deployment and inventory balancing
Supersession
Selection Profile
The selection profile defines the scope of the planning. There are different types of
selection, but for service parts planning either the selection type location product or
the selection type product is used. Table 2.2 lists the services which require one or
the other.
Figure 2.32 shows the WEB-UI-based selection profile of the type location
product. The selection profiles are defined and accessed with transaction
/SAPAPO/PE_SEL.
Fig. 2.32 Selection profile
Process Profile
The process profile contains the method of the package creation in the service and
controls the detail of the logs. The process profile is maintained with the
customising path SCM Basis ! Planning Service Manager ! Define Process
Profile as shown in Fig. 2.33.
Fig. 2.33 Process profile
The package creation method for most of the services in service parts planning is
LOCATIONPRODUCT_PRODUCT. If the service is not location product but
product oriented, the methods PRODUCT_SIMPLE, PRODUCT_INCMD or
PRODUCT_SOR_SRPL_DET are e.g. used as well. Table 2.3 lists the package
creation methods and the services that require them.
Table 2.3 Package creation methods

Package creation method Service
LOCATIONPRODUCT_PRODUCT Realignment (Stocking)
Forecast (incl. Disaggregation, Standard Deviation and
Approval)
Stocking and de-stocking
EOQ and safety stock
DRP (incl. anticipated demand coverage and
procurement approval)
Supersession
PRODUCT_SIMPLE Obsolescence planning
Shortage analysis
PRODUCT_INCMD Realignment (Supersession)
PRODUCT_SOR_SRPL_DET Surplus planning
SPP_LOCPROD_FCSTRECALC Recalculation of historical forecast
SIMPLE_GENERIC_METHOD Version copy
The method LOCATIONPRODUCT_PRODUCT_INCFC is another example,

which is necessary to be used in cases where interchangeability like supersession is
involved. Then services e.g. for stocking or de-stocking. inventory balancing for
unserviceable stock and DRP—as shown in Fig. 2.34—require this package crea-
tion method.
Fig. 2.34 Example of a package creation profile used in regard to FFF-classes
Planning with the Service Manager

The planning service manager is called with the transaction /SAPAPO/PE_RUN
and the reference to the planning profile. To run the planning service manager as a
background job (transaction SM36) the report /SAPAPO/PE_EXEC is used.
Log
The logs are displayed either with the transaction /SAPAPO/PE_LOG_DISP or
with the transaction SLG1. In the latter case the object /SAPAPO/PE contains all
logs that are created by the planning service manager (the object /SAPAPO/PDEM
creates the logs for the data staging via SAP BI™ as used for the capturing of
historical demand).
Trigger
In order to reduce the volume for planning not all products within the selection are
planned but only those who have planning relevant changes. The concept of net
change planning is realised in service parts planning using triggers. Differing from
planning file entries, many different types of triggers exist—depending on the
action that caused their creation. Triggers are displayed, set and changed with the
transaction /SAPAPO/TRIGGER, Fig. 2.35.
Fig. 2.35 Trigger
Table 2.4 lists the different types of triggers and the planning services that they
affect. This follows the concept of publish and subscribe: the use of the triggers can
be restricted by trigger profiles with the customising path SCM Basis ! Planning
Service Manager ! Triggers (For Planning File Entry)! Define Trigger Groups
and Attributes.
Table 2.4 Trigger types and services

Trigger Service
SPP_BOD_CHANGE_INCMD A supersession chain is changed after BOD change
SPP_BOD_DELETE BOD assignment Is deleted
SPP_CLD_CHG SPP: calendar period change
SPP_DESTOCKING Destocking decision
SPP_ENTRY_POINT_APPR SA release(s) approved
SPP_ENTRY_POINT_VOID SA schedule lines/PRs/POs rejected/deleted
SPP_EXPEDITE_FIRMHOR Additional demand within limited freeze horizon
SPP_EXTPROC_CP_CHG SPP Ext.Proc. CP Change
SPP_FACILITY_REDUCED Reduction of storage space at a location
SPP_FCSTMDL_CHG_TPOP Forecast model change (TPOP)
SPP_FCSTMODEL_CHANGE Forecast model change
SPP_FCST_CHANGE Successful change of forecast
SPP_FCST_CHG_PLNMODE Fcst Chnge for Loc.Prod. for Which Plng Mode Is Aut.
Defined
SPP_FR_CHANGED Change to fixed demands, receipts
SPP_INC_CHANGED Change to master data for product interchangeability
SPP_INV_BALANCING Inventory balancing
SPP_INV_PL_CHANGES Changed results of inventory planning
SPP_INV_PL_MD_CHANGE Change of inventory planning relevant master data
SPP_LEADTIME_CHANGED Master data change: Procurement lead time
SPP_MANUAL_TRIGGER Manual trigger
SPP_MASS_APPR DRP mass approval
SPP_NEW_BOD_ASSIGN New BOD assignment
SPP_NEW_PRODUCT New product indicator set
SPP_NEW_REGION_ASSIG Changed assignment of a product to a region
SPP_NON_ST_DEMAND Demand at non-stocked location
SPP_NON_TPOP Change to no TPOP
SPP_OVERDELIVERY Overdelivery
SPP_PHASE_IN_CALC Phase-in forecast calculated
SPP_PICK_DENIAL Pick denial
SPP_PULL_DEPLOYMENT Pull deployment trigger
SPP_PULL_DEPL_NOSUCC Incomplete demand fulfillment for pull-deployment
SPP_REPAIR_COMPONENT Dependent demand
SPP_REPL_INDI_CHANGE Replenishment indicator changed
SPP_RLG_DONE Data realignment of demand history executed
SPP_RLG_DONE_BOD Data realignment of demand history performed (BOD)
SPP_SALES_ORDER Sales order
SPP_SCHEDULE_CHANGED Scheduling Agmt lines/Purchase Req./PO Not created by
DRP
SPP_SDPR_ASNMOD ASN modification/cancellation after new release issued.
SPP_SDPR_OVRDLV_CANC Overdelivery cancelled
SPP_SEASONAL_PROD Anticipated demand coverage for seasonal product
SPP_STK_EXC_RULE_CHG SPP: Location exclusion rules changes
(continued)
Table 2.4 (continued)

Trigger Service
SPP_STOCK_ADJUSTMENT Stock change
SPP_SUPERSESSION Supersession
SPP_SUPPLIER_CHANGED Master data change: Supplier
SPP_TPOP Change to TPOP
SPP_UNSRV_INSUFF Not enough unserviceable stock
SPP_UNSRV_STO_CRTD STO with unserviceable stock created
SPP_UNSRV_STO_NO_CAP STO creation with Unserv. stock failed (Cap. Constraints)
SPP_USEUPFLG_CHANGED Use-up strategy was changed
SPP_WAREHOUSE_RESTR Location product locked by storage
These triggers are activated with the transaction /SAPAPO/SPP_TG_ACT using

the selection ‘SPP*’ for all service parts planning services.
2.4 Transactional Data Layer
With the transactional data layer (TDL) a new entity is introduced to control the
source of the data storage for service parts planning. The general idea is the
de-coupling of the business objects from the storage technique in order to gain
more flexibility. The planning service manager accesses the transactional data layer
using semantics Fig. 2.36 shows how the planning service manager accesses the
TDL as an abstract data storage for time series, orders or inventory. Within the TDL
customising the real storage for the data is defined.
Planning Service Manager
TDL
Business Object Interface
Time Series Orders Inventory
Planning Area
Time Series Order

Info Provider TSDM ODM LIME
Live Cache Live Cache
© SAP AG
Fig. 2.36 Transactional data layer (#SAP AG)
2.4 Transactional Data Layer 41
Semantics
The business objects are represented by semantics. The mapping between semantics
and the storage technique is done either via a time series type, an info provider or a
planning area. The info providers are only used for the reading of data. Figure 2.37
shows an example for the assignment of the semantic TS_DRP_RESULT (which is
used for DRP) and the time series type DRP with the transaction /SCMB/
TDL_SEMANTIC.
Fig. 2.37 Semantics definition
A semantic might as well be a key figure—in this case the info object type is ‘key
figure’ and the info cube and the info object (i.e. the key figure of the info cube) are
defined. Figure 2.38 shows an example for the key figure NET_DEMAND_VALUE
which is used for DRP as well.
Fig. 2.38 Semantics definition for key figures
This definition is done with the same transaction as above. Other object types are
characteristic, time characteristic and unit.
Time Series Type

The data storage is either defined via planning area, info provider or via a time
series type (as in Fig. 2.35). The configuration of the time series types is done with
the transaction /SCA/TSDMCFG, Fig. 2.39.
Time Series Type
© SAP AG
Time Series Data Area

© SAP AG
Time Series Data Type
© SAP AG
© SAP AG
Time Profile Key Figures
Fiscal Year
Variant
© SAP AG
Fig. 2.39 Configuration of time series types
The OSS note 913863 contains additional information about the TDL. A helpful
transaction when dealing with the TDL is /SCMB/TDL_TOOLS because it
contains the link to most of the customizing steps and the transactional data
management.
Definition of Number Ranges and Activation

One prerequisite for working with the TDL is that the number ranges for the TDL
orders are defined. This definition is done with the transaction /SCMB/
TDL_ORDERGUIDS as shown in Fig. 2.40.
2.4 Transactional Data Layer 43
Fig. 2.40 Number range for TDL orders
Another prerequisite is the activation of the TDL data areas with the transaction
/SCMB/TDL_TOOLS as shown in Fig. 2.41.
Fig. 2.41 TDL data area activation
TDL Data Access

The TDL contains (or links to) time series, orders and inventory. It is possible to
access the TDL data via the semantics.
Fig. 2.42 Data access to the TDL time series
For the data access the following transactions are used:
• transaction /SAPAPO/TDL_TS_TEST for time series

• transaction /SAPAPO/TDL_ORD_TEST for orders
• transaction /SAPAPO/TDL_INV_TEST for inventory
Figure 2.42 shows the access to the time series with the semantics
ORDER_FCST.
2.5 Simulation
Simulation is part of service parts planning as it is in ‘normal’ SAP APO™. The

transactional data is stored in versions. The active version—the version that
communicates with SAP ERP™—is version ‘000’. It is however possible to copy
the data from the active version to an inactive version and perform simulations.
2.5 Simulation 45
These simulations are analysed with the same tools as the operative data. It is
however not possible to transfer the data from the inactive version to the active
version because in the meantime the data basis might have changed. To transfer the
information form the inactive simulation to the operative version, the planning
steps have to be repeated in the active version.
In order to perform a simulation, first an inactive simulation version with a copy
of the current operative data has to be created. The simulation version is created
with the transaction /SAPAPO/SPPSIM as shown in Fig. 2.43. In order to avoid
unnecessary data and to keep the performance high, it is possible to restrict the
data—either by a selection profile or by products directly. Another option to restrict
the data is by application, i.e. whether the data is required for a simulation of
forecasting, stocking decision, EOQ and safety stock planning, DRP or pull
deployment. The new simulation version is also displayed in the model and version
maintenance with the transaction /SAPAPO/MVM.
Fig. 2.43 Create simulation version
Fig. 2.44 Version profile
Simulation versions should be created only with this transaction (and not with
the version copy /SAPAPO/VERCOP) in order to ensure that all the data of the
TDL is copied. For the copying of the TDL data however a version profile is
required. This version profile is created with the customising path APO ! Supply
Chain Planning ! SPP ! Basic Settings ! Simulation ! Define Version Pro-
file—Fig. 2.44 shows an example. Note that two process profiles are assigned to the
version profile—one for copying and one for deleting the transactional data. These
process profiles require a package creation method of the type
SIMPLE_GENERIC_METHOD.
2.5 Simulation 47
Fig. 2.45 Simulation of forecasting
In the second step planning is performed in the inactive simulation version. With
the same transaction /SAPAPO/SPPSIM it is possible to execute planning with the
service profiles without having to create new planning profiles for the simulation
version. Figure 2.45 shows how to set up forecasting for the simulation version.
It is also possible to use the tools for interactive planning for the simulation
version.
Snapshot
The idea of the snapshot is to save a copy of the current planning situation into a
simulation version in order to perform a simulation with this data at a later point in
time. For example, the planning situation of the first of April is copied as a snap
shot. Two months later, at the first of June, this snapshot is used and different
planning steps are performed. The speciality of the snapshot is that the planning
Fig. 2.46 Create snapshots
applications pretend that the point in time for the planning is the creation date of the
snapshot. This way it is possible to analyse what the effect of a different planning
decision would have been.
A snapshot is created with the transaction /SAPAPO/SNAPSHOT as shown in
Fig. 2.46. The snapshot is not restricted by products or applications but contains the
complete active version.
The first four characters are ! Simulation ! General Settings for Simulation.
The other characters are set by the system—in this case as the date of the snapshot—
defined with the customising path APO ! Supply Chain Planning ! SPP ! Basic
Settings.
Capture and Manage Demand History
3
3.1 Process and Data Flow Overview
The demand history is the basis for forecasting and the stocking decision. Therefore
the capturing of the demand history is the first step for service parts planning. The
sales history is usually loaded from either SAP CRM™, SAP ERP or from Dealer
Management System (DMS) (or for test purposes from a flat file) using the SAP
BI™ data staging process. There is one exception: In the course of the OEMMI
scenario, the data is loaded from XML messages received via SAP PI (since the
demand history at the OEM’s customer is used). During the upload the data is
processed in order to fit the specifics of service parts planning—e.g. an aggregation
along the Bill of Distribution (BOD) is performed and other steps which are
explained in Sect. 3.2.2. The demand history is stored both on item level (in the
Data Store Object (DSO) 9ARAWDAT) and on aggregated level (in the info cube
9ADEMAND).
For several reasons it might be required to adjust the demand history. Examples
are realignments due to a change in the stocking decision (see Chap. 4), superses-
sion (see Chap. 12) or to separate demand caused by promotions. In total nine
planning services trigger realignment, Fig. 3.1 shows only two examples. Another
example for demand adjustment is removing demand that is caused by a unique and
exceptional occurrence—e.g. the replacement of exhaust pipes due to a legal
change. This increase in the demand is not representative and should therefore
not be the basis for future forecasting.

50 3 Capture and Manage Demand History
Fig. 3.1 Capture and manage demand process overview
Managing historical demand contains the realignment and the interactive

demand adjustment and writes the changes to the DSO 9ARAWCRT for order
items respectively 9ADEMCRT for aggregated demand history per period. The
final demand history that is used by the applications forecasting, stocking and
de-stocking is the sum of the captured demand history and the changed demand
history. The technical realization is done using the multi-cubes 9ARAWMUL for
order items and 9ADEMMUL for aggregated demand history per period. Figure 3.1
shows the process overview of capture and manage demand history.
3.2 Capture Demand History
3.2.1 Data Flow Overview
The demand history is loaded from SAP CRM™, SAP ERP or from an external
DMS via SAP PI (or for test purposes from a flat file) using the standard SAP BI™
data staging functionality. Nevertheless there are many service parts planning
specific functions in the update rules, and the service parts planning application
requires a defined format of the info providers. The SAP BI™ business content for
the data upload from SAP CRM™, from SAP ERP, from an external DMS and from
a flat file is part of the service parts planning solution and has to be activated before
loading data. The SAP BI™ content is also required for the data processing of the
service parts planning applications because the transactional data layer accesses
SAP BI™ objects as well (see Sect. 2.4). Figure 3.2 shows the data staging structure
3.2 Capture Demand History 51
Fig. 3.2 Upload structure for the demand history from CRM and from flat file
and some of the SAP BI™ objects for the upload of the demand history from CRM
(and from CSV simulating the data from a CRM-system).
The source for demand history might also be SAP ERP, normally sales orders
from ERP-SD. In some cases the demand history might be represented by stock
transfer orders (STO’s), e.g. if the sales order management is not part of SAP ERP.
Though the general upload structure is the same, some data sources, update rules
etc. will be different as shown in Fig. 3.3 for the upload from ERP-SD.
Figure 3.4 shows the upload structure for ERP-MM as the source of demand
history.
Table 3.1 shows an overview of all the BI objects (along the upload stream
upwards, which are used specifically for the different source systems CRM,
ERP-SD ERP-MM and DMS.
The upload structure for demand history from a DMS is described in Chap. 15—
OEM MI in more detail.
For the activation of the SAP BI™ business content the replication of data
sources should be selected as ‘3.x datasource’ (and not as ‘datasource’).
Fig. 3.3 Upload structure for the demand history from ERP SD and from corresponding flat file
Fig. 3.4 Upload structure for the demand history from ERP MM and from corresponding flat file
3.2
Capture Demand History
Table 3.1 Overview on the relevant BI-objects in the process per source system
Source system
BI-object for data capture CRM ERP-SD ERP-MM DMS
Data source 0CRM_SALES_ORDER_I 2LIS_11_VASCL 2LIS_02_SCL 9A_ACP_OEMMISO_XML_DATA
DSO 0CRM_SALO 9ASDDAT 9APURDAT 9AOEMMIS
Info source 80CRM_SALO 89ASDDAT 89PUR_DAT 89OEMMIS
Update rule to DSO 9ARAWDAT 80CRM_SALO 89ASDDAT 89PUR_DAT 89OEMMIS
Update rule to InfoCube 9ADEMAND 80CRM_SALO 89ASDDAT 89PUR_DAT 89OEMMIS
53
3.2.2 Processing of the Demand History
During the upload of the demand history the data is already processed for the
service parts planning applications. Mainly the following processing steps are
performed:
• demand category determination

• determination of future dated orders
• determination of the facing and the first stockholding location
• aggregation per period
• scaling of the demand history
• aggregation along the BOD
The reason and the details of these processing steps are explained in the
following.
Determination of the Demand Category

To each order item a demand category is assigned which determines whether the
item is relevant for forecasting or not. The default demand category is NONE which
is relevant for forecasting. The reason for demand categories is to treat certain
customer orders differently.
Service parts planning is mainly a make-to-stock (respectively procure-to-stock)
scenario which implies that individual customer orders are not considered in
planning. There are however exceptions, e.g. if a big customer places an order of
considerable quantity some time in advance. The demand category for customer
orders is introduced to separate these kinds of customer orders. The demand
categories (NONE, FDO_DEM, ADJ_DEM, PROMO_DEM, . . .) are modelled
with the info object 9ADEM_CAT as shown in (transaction RSDMD). These
demand categories are predefined and activated as business content (info source
9ADEM_CAT). It is not recommended to change these categories. Figure 3.5
shows that the demand category FDO_DEM for future dated orders is not relevant
for forecasting. The info object for the forecast relevance is 9AFCSTABLE.
Fig. 3.5 Master data for info object 9ADEM_CAT
Though there exists also a table for the customizing of the demand categories
(transaction /SAPAPO/PDEMCUST) those settings have no impact.
Determination of Future Dated Orders

Future dated orders are determined either based on the order type or based on the
difference between the creation date and the requested delivery date. If this time
difference exceeds the defined horizon of the order item a demand is classified as
future dated order (FDO) with the demand category FDO_DEM. This classification
is done based on the customizing settings defined with the path APO ! Supply
Chain Planning ! SPP ! Basic Settings ! Make Settings for Customer Demand
as shown in Fig. 3.6. In this example the requested date must be at least 90 days in
the future at the time the order is created.
Determine Future Dated Orders

based on Order Type
based on Horizon
© SAP AG
Fig. 3.6 Definition of future dated orders
The implication of excluding future dated orders from forecast is that they will
not contribute to the demand history. Therefore no forecasting is done for this kind
of orders. To procure the requested service parts nevertheless for these orders, DRP
considers the demand of the future dated orders additionally to the forecast.
Customer Facing and First Stockholding Location

In the service parts planning solution the customer facing location and the first
stockholding location are distinguished in order to keep the demand history consis-
tent throughout changes of the stocking decision. The customer facing location is
the first location which is checked. The customer facing location might however not
be able to confirm the customer request—either because it was decided that the
service part should not be stored at this location or because it has simply run out of
stock. Since rules-based ATP is used for the SPM solution, other locations are
checked and the sales order will probably be confirmed in one or more of these
other locations. The locations which confirm the customer request are the ship-from
locations. The first stockholding location however is the first location in the check
sequence which is defined as stocked (i.e. the replenishment indicator is set to
‘stocked’) and therefore should be able to confirm the customer request—indepen-
dent of which location actually confirms the request.
The demand history for service parts planning is based on the first stockholding
location. A first stockholding location could never be identified if the product is a
MAO (make as ordered), i.e. the replenishment indicator is “NN” (not stocked).
If the customer facing location and the first stockholding location differ, it is
checked during upload whether an ATP rule with a location substitution procedure
for both locations exists. There are cases of demand capture where the uploaded
sales order items do not provide the information about the customer facing and the
first stockholding location. Reason could be that these sales orders are 3–5 years
old, most of them already fulfilled, and from legacy systems and are loaded as the
starting point of the implementation of a SPP solution. A common way to provide
these sales orders with the information for customer facing and first stockholding
location is using the ATP check. For this the BAdI /SAPAPO/
PDEM_ATP_CHECK_IF can be used which triggers an ATP check during upload
(during the update rule between InfoSource 2LIS_11_VASCL and InfoProvider
9ASDDAT—in case the sales order items are from ERP) in order to come up with a
first stockholding location for each demand item.
In other cases there are implementations which do not contain GATP at all and
therefore the identification of the right first stockholding location is also not
possible. Then also the BAdI /SAPAPO/PDEM_ATP_CHECK_IF can be applied
as a substitute for determination the right stocking location.
The BADI is also called in cases where the respective product, whose demands
are captured, is member of an active supersession chain.
There are three alternative methods in the course of this BADI how to determine
the customer facing and first stockholding location:
– Bypassing: In this case instead of the regular ATP check an own logic with own
rules and maybe own field is applied in order to determine a project-specific list
of locations. The top of the list then represents the facing location. The first
location in the list with a replenishment indicator for stocking in the
corresponding location product master represents the first stockholding location.
– Simulation: If the sales order data is not appropriate enough to perform a regular
ATP check, the appropriate fields (e. g. for determining the ATP rules) can be
added or existing fields can be modified. Afterwards the regular ATP check is
performed
– Execute ATP check: In case that a sales order item contains a product that is part
of an active supersession chain and the Successor Product Planning Date (SPPD)
has already been reached then the product needs to be replaced by its successor.
For this product the ATP check is performed. Afterwards realignment is
executed right in the course of the process of data capture.
As a prerequisite that the BAdI /SAPAPO/PDEM_ATP_CHECK_IF is called

during the historical data capture in any case the OSS note 1592280 has to be
implemented. Then the general customizing settings of demand history within
transaction /SAPAPO/PDEMCUST are extended in the way as shown in Fig. 3.7.
Fig. 3.7 General activation for BAdI /SAPAPO/PDEM_ATP_CHECK_IF and particularly for
data capture process
Once the BADI is implemented it, its actual usage still needs to be switched on
by setting the corresponding parameter in the general setting of demand history as it
is shown in Fig. 3.7 in the dotted-lined box.
Base Unit of Measure

If the sales unit of measure differs from the base unit of measure, the demand
quantity is adjusted to the base unit of measure.
Periodicity and Aggregation for Forecasting and Inventory Planning

The relevant date of the customer order item is the requested date. During the data
upload, the order items are aggregated into weekly, monthly and posting period
respectively fiscal year period buckets. Both the order quantity (info object
9ADEM_QTY) and the number of order items (info object 9AORD_LINE) are
aggregated. In the info cube 9ADEMAND the date of the demand element is not
stored but only the week (info object 0CALWEEK), the month (info object
0CALMONTH) and the fiscal year period (info object 0FISCPER) with the fiscal
year variant (info object 0FISCVARNT). All the three periodicities are calculated
and stored—independent of which periodicity is used.
The definition of the periodicity for forecasting and inventory planning is
done with the customizing path APO ! Supply Chain Planning ! SPP ! Basic
Settings ! Determine Forecast Periodicity, Fig. 3.8.
Fig. 3.8 Periodicity for forecasting
Forecasting and inventory planning is performed either in time periods of weeks,

months or posting periods (using fiscal year variants).
Mandatory Fiscal Year Variant

Though the fiscal year variant is only used in the case that the periodicity is set to
‘periods’, due to the data staging content it is required that a fiscal year variant is
assigned in the general settings for the demand history with the customizing path
APO ! Supply Chain Planning ! SPP ! Forecasting ! Make General Settings
for Demand History as shown in Fig. 3.9. As a default the fiscal year variant ‘K3’
is used.
Fig. 3.9 Assignment of the fiscal year variant
The fiscal year variant is created with the transaction OB29 in SAP APO™. If
the same fiscal year variant should be used as in SAP ERP™, it is possible to upload
the fiscal year variant from SAP ERP™ with the transaction RSA1 (or RSA1OLD)
using the SAP BI™ functionality for the transfer of global settings, Fig. 3.10.
In this case the upload is triggered in SAP APO™ using the source system for
SAP ERP™.
Fig. 3.10 Upload fiscal year variants from SAP ERP™
Scaling of the Demand History

All three kinds of periods—weeks, months and posting periods—can contain
different numbers of working days. In order to eliminate this impact, the aggregated
demand is scaled to a constant number of working days. Figure 3.11 shows the
Data in 9ADEMAND
Calendar Week of Order Date Week
Order Quantity * WD(W) / SF(W)
No. of Order Items * WD(W) / SF(W)

Data in Source
Order Date Month of Order Date Month
Order Quantity Order Quantity * WD(M) / SF(M)
No. of Order Items No. of Order Items * WD(M) / SF(M)
Period of Order Date Period
Order Quantity * WD(P) / SF(P)
No. of Order Items * WD(P) / SF(P)
WD (W, M, P): No. of Work Days per Week, Month or Period

SF (W, M, P): Scaling Factor for Week, Month or Period
Fig. 3.11 Scaling of the demand history during data load
scaling of the demand with the ratio of the number of working days (as determined
using the calendar) and the number of working days maintained in the scaling
factor.
The scaling factors and the calendar are defined with the customizing path
APO ! Supply Chain Planning ! SPP ! Forecasting ! Make General Settings
for Demand History, Fig. 3.12. As a default 21 days are used for the scaling of
the months and the fiscal year periods and 5 days for the scaling of weeks. These
values should not be changed unless there are reasons to do so.
Fig. 3.12 Scaling factor and calendar for demand aggregation
Three alternatives exist for the calendar for scaling—the planning calendar, the
receiving calendar or the shipping calendar. All the three calendars are maintained
in the location master (see Sect. 2.1.5).
Aggregation Along the Bill of Distribution

For forecasting not only the demand at the customer facing location is used but also
an aggregated demand along the bill of distribution (BOD). The purpose of this
aggregation is to perform a forecast based on a bigger data base (see Chap. 5). The
result of this aggregation is that the customer order items and the order item
quantities are stored both for the first stockholding location—where they actually
belong to—and for the parent location, Fig. 3.13.
3.3 Manage Demand History 61
Bill of Distribution
SPG1
Data in 9ADEMAND
SPG2 SPB1
Data in Source Order Quantity
Location SPG1
Order Quantity
Location SPG2
Order Quantity
Location SPG2
Fig. 3.13 Aggregation along the BOD
As an example, if the location SPG2 has a customer demand of 10 pieces and

SPB1 of 20 pieces, at the parent location SPG1 additionally 30 pieces are stored—
though the parent location does not have any customer demand by definition.
The implication of this aggregation is that the service part must be assigned to a
BOD before loading demand history. Therefore a missing BOD assignment causes
an error.
3.3 Manage Demand History
The purpose of the management of the demand history is to adjust—i.e. change—

the demand history either by realignment (due to a change in the stocking decision,
supersession, in order to separate promotion demand or other) or by interactive
adjustment. These changes are stored via SAP BI™ real time data staging in data
store object (DSO), 9ADEMCRT for the aggregated demand and 9ARAWCRT for
the order items). The history for service parts planning is taken from a multi-cube
which adds the original history and the changes to the final history. Figure 3.14
shows the data flow for the aggregated demand.
Fig. 3.14 Data structure overview for manage demand history (originally from CRM)
Interactive Adjustment of the Demand History

The interactive adjustment of the aggregated demand history is performed per
location product with the transaction /SAPAPO/SPPDMDH. Figure 3.15 shows
the maintenance in the key figure ‘demand: adjusted history’. The demand his-
tory—as uploaded into the info cube 9ADEMAND—is displayed as well but
cannot be changed. For both key figures—original and adjusted demand—the
scaled values are also calculated and displayed.
Fig. 3.15 Manual adjustment of the demand history
Another feature in this UI is to call directly SAP BI™ reports to analyze the
history (with the drop-down menu ‘history’). Also the definition of promotion
demand is performed in this transaction by maintaining the value ‘1’ in the key
figure ‘promotion’ (not displayed in Fig. 3.15) for periods with promotions. In this
case the realignment service for promotion determines the difference between the
demand and the historical forecast and changes the demand category for this
difference to the non-forecasting relevant category PROMO_DEM. This applies
only if the demand is higher than the historical forecast.
Analogously it is possible to adjust the demand history for the order items with
the transaction /SAPAPO/SPPDMRD.
Realignment
Realignment is performed e.g. after a change in the stocking decision, after
supersession or in order to separate the historical demand due to promotions. For
realignment the information of the order item GUID, the product number, the order
item type (e.g. TAN) and the customer is required, because a rule evaluation within
rules-based ATP is performed in order to determine the customer facing location
and the first stockholding location (an ATP check is not performed). This implies
that the demand history on order item level is required for realignment.
Realignment After a Stocking Decision

As an example for realignment the realignment after a stocking decision is explained
(realignment after supersession is explained in Sect. 12.3). If the replenishment
indicator changes from stocked to non-stocked, the demand history of this location
has to be transferred to the new first stockholding location. In the opposite case, if the
replenishment indicator changes from non-stocked to stocked, the demand history of
the old first stockholding location is transferred to the newly stocked location—in the
case that the location substitution procedure determines that this location would have
been the first stockholding location for the order items. The planning service for this
realignment is SPP_PDEM_STOCKING_RLG, and the service profile is defined with
the customizing path APO ! Supply Chain Planning ! SPP ! Forecasting ! Define
Service Profile for Reorganization of Demand History as shown in Fig. 3.16.
Fig. 3.16 Manual adjustment of the demand history
Roll-back of Realignment
There are situations where realignment needs to be revised and rolled back. An
example is where realignment was performed as part of a new product introduction
via supersession chains (see Chap. 13 about interchangeability) but business
decided to switch to a different successor product instead.
As a consequence the demand data realignment is not valid anymore and
restoring the previous situation would be required in order to be able to perform
the “right” realignment. SAP does not offer standard functionality for that.
Depending on the complexity of the supersessions two workarounds proved to
be successful. For simple cases dummy supersession chains including dummy
realignment steps—that transfer the demand history from the “wrong” successor
to the “right” successor—will do. In more complex cases dummy supersessions
might just create too much confusion and therefore the CRT records (i. e. the result
of the realignment step) need to be deleted. These records are stored in the DSO
9ARAWCRT and the cube 9ADEMCRT—respectively in the DB-tables /BI0/
9AARAWCRT00 and /BI0/9AADEMCRT00). The challenge is to identify the
right records since they do not contain the information which realignment run
they were created with.
The complexity in this regard increases in situations where the supersession to
be deleted is already integrated in more than one supersession chain, where the
successor product planning dates (SPPD) are different and the various realignment
steps have already taken place during different points in time.
Adjustment of Customer Facing and First Stockholding Location After

Realignment
For the adjustment of the customer facing and first stockholding location after
realignment (after stocking or destocking decisions, after the change of promotion
decision, after the change of TPOP decision or after regular supersession run) the
BADI /SAPAPO/PDEM_ATP_CHECK_IF can be used as described in the section
about customer facing and first stockholding location.
Simulation of Realignment of Demand History

In order to determine and validate the settings which should be used for the various
PSM realignment services, there is simulation functionality for that purpose in SPP.
This simulation always takes place in an inactive version—in contrast to the
active version 000. As prerequisite an inactive version has to be created as simula-
tion version in transaction /SAPAPO/MVM—as shown in Fig. 3.17.
The simulation of a specific realignment process is executed by applying a
separate PSM planning profile with the respective realignment service profile
inside. The PSM planning service must be assigned in the simulation-specific
simulation version—in the example in Fig. 3.18 the version “SPP”.
A prerequisite of using the simulation for realignment purposes is the usage of
specific BI content, which differs from the one used for operative purposes. This BI
Content for the simulation is different to the regular BI Content since the
InfoSources and InfoProviders contain the Version (9AVERSION) characteristic.
Fig. 3.17 Creation of simulation version in transaction /SAPAPO/MVM
Fig. 3.18 Assignment a realignment service profile to a simulation version
This characteristic allows to create and maintain the demand history based on the
version.
The InfoProviders for the simulation are located in the InfoAreas
9ADEMAND_SIMULATION, 9ADEMAND_RAW_DATA_SIMULATION and
9ADEMAND_HISTORY_SIMULATION.
Additionally the corresponding data Store Objects, Info Cubes and
MultiProvider need to be assigned in SPP Simulation transaction /SAPAPO/
SPPSIM as shown in Fig. 3.19.
Fig. 3.19 Specifying the simulation-specific InfoProviders in transaction /sapapo/sspsim
Stocking Decision
4
4.1 Process Overview
One characteristic of service parts planning is the huge number of products and
locations. In order to reduce inventory and warehouse costs not all products are kept
in all locations. The decision whether a product is stored in a location depends on
the demand and on the costs for the products. The decision is recorded in the
authorised stocking list (ASL). The function of the ASL is modelled in APO by the
replenishment indicator, see next section. There is however no standard report to
display the replenishment indicator for multiple products.
The decision to stock or de-stock a service part at a warehouse is based on the
demand history of the product. Figure 4.1 shows this process.
Demand
Capture Demand History
Decision Table Decision Table

(Stocking)
Stocking Exclusion Table De-Stocking (De-Stocking)
Replenishment
Forecasting
Indicator
EOQ &
Safety Stock
DRP
Deployment
Inventory
Balancing
Fig. 4.1 Stocking decision process overview

68 4 Stocking Decision
The thresholds for the stocking and the de-stocking decision depend on the cost
of the service part and are based on the demand quantity, on the number of order
items, the product group or a combination of these.
4.2 Replenishment Indicator
The replenishment indicator controls whether a service part should be stocked at a

location or not. It is a prerequisite for most of the planning functions that the
replenishment indicator allows stocking. If the replenishment indicator of a service
part is set to ‘not stocked’ at a location,
• no forecasting is performed
• no EOQ and safety stock planning is performed
• DRP ignores forecasts and safety stocks.
The customising path for the replenishment indicator is APO ! Master

Data ! Product ! Define Replenishment Indicator. Though it is possible to create
own values for the replenishment indicator, the stocking and de-stocking service
consider only the standard ones. The replenishment indicator is assigned to the
location product, Fig. 4.2.
Fig. 4.2 Replenishment indicator
4.2 Replenishment Indicator 69
The replenishment indicator is set by the stocking service and the de-stocking
service. Figure 4.3 shows the cycle for the replenishment indicator.
Stocking Service Goods Receipt
NS SN ST
Not Stocked Stocked (New) Stocked
De-Stocking Service
ST Last Facing No NS
Stocked Location? Not Stocked
Yes
No Procure-to- Yes PO
Order
Procure-to-Order
Allowed?
Fig. 4.3 Cycle for the replenishment indicator
If the stocking service decides to stock a previously not stocked service part, the
replenishment indicator is set first to ‘stocked (new)’. Only after goods receipt—i.e.
when the service part is really stocked—the replenishment indicator is changed to
‘stocked’. The threshold for the change of the replenishment indicator is defined
with the customising path APO ! Supply Chain Planning ! SPP ! Inventory
Planning ! Define Limit Value for Replenishment Indicator, Fig. 4.4.
© SAP AG
Processed Stock for Conversion from Stocked (New) to Stocked
Fig. 4.4 Threshold for change of the replenishment indicator
The percentage relates to the demand within the replenishment lead time—i.e.
the demand which is due immediately. In this case, after a goods receipt of 50 %
percent of the demand quantity, the replenishment indicator is set from ‘stocked
(new)’ to ‘stocked’.
In the other case, if the de-stocking service decides that a previously stocked
location should not be stocked anymore, the replenishment indicator is set to ‘not
stocked’—unless it is the last facing location below the entry location. If the setting
in the product master allows it, the replenishment indicator is set to ‘procure-to-
order’. The implications are that the safety stock is set to zero and the economic
order quantity (EOQ) to one—if a customer places an order for this product, the
order quantity is procured from the supplier and distributed along the BOD to the
facing location.
It is possible to inhibit an immediate automatic change of the replenishment
indicator by activation the approval flag in the service profile for stocking decision
or (or and) for the de-stocking service. Then in any case—independent from the
previous replenishment indicator or any limit—the planner has to approve
interactively.
Via the transaction /SAPAPO/SPPINVAPPR the approval screen can be
accessed, as shown in Fig. 4.5.
Fig. 4.5 Approval screen for new the replenishment indicator
There for a certain product all relevant location products of a respective BOD are
shown with their previous and the future replenishment indicators. Line by line the
planner can select whether to approve or to reject. When it is approved the location
product master is updated immediately.
It is also possible to inhibit an automatic change of the replenishment indicator at
all by using the replenishment indicators NL (not stocked, blocked, sales relevant)
or NN (not stocked, blocked, non-sales relevant) for non-stocked and SL (stocked
and blocked) for stocked. These replenishment indicators have to be set and
changed interactively.
4.3 Rules and Decision Tables 71
4.3 Rules and Decision Tables
Depending on the demand and the cost, the stocking and the de-stocking services
change the replenishment indicator. The threshold for the decision depends on the
demand quantity or the number of order items and the procurement cost. The axis
and the thresholds are defined in the decision table, and one or more decision tables
are combined to a profile. One profile for stocking and one profile for de-stocking is
assigned to the location. Figure 4.6 shows the interdependencies of the objects for
the decision tables.
X-Axis Y-Axis
Table 1 Table N
Stocking
Profile 1
Location
Profile 2
De-Stocking
Fig. 4.6 Interdependencies of the objects for the decision tables
Decision Tables
The maintenance of the decision tables starts with the definition of their axis—both
the dimension and the values. This is done with the customising path
APO ! Supply Chain Planning ! SPP ! Inventory Planning ! Set Up Decision
Tables for Stocking/De-Stocking as shown Fig. 4.7.
Fig. 4.7 Definition of the decision table
Possible dimensions for the axis are demand quantity (DEMAND_PIECES),

number of demand items (DEMAND_ENTRIES), product group and procurement
costs. Normally for the x-axis the demand quantity, the number of demand items or
the product group is used. An example for the use of product groups is to model the
ABC-indicator as product groups. If product groups are used as x-axis, only single
values for the names of the product groups are maintained (the ‘to’-field remains
empty).The y-axis is usually the procurement costs which are defined in the
‘procurement’-view of the product master.
In the next step it has to be defined for which combination of demand quantity
and procurement cost respectively number of demand items and procurement cost a
decision needs to be taken. This is done by setting a flag for the appropriate
combination.
Figure 4.8 shows the maintenance of the decision tables with the transaction
/SAPAPO/SPPINVPDEC. By setting flags for the combinations it is defined where
stocking respectively de-stocking should take place. Figure 4.9 shows an example
of a stocking and a de-stocking table.
© SAP AG
© SAP AG
© SAP AG
Fig. 4.8 Maintenance of the decision tables
Decison Table for Stocking Decison Table for De-Stocking
© SAP AG
© SAP AG
Fig. 4.9 Example for decision tables
In this case the product should be stocked at a location if the monthly demand is
above 10—unless the cost for the product is above 100, then the demand has to be
above 100 to stock the location. In the other case a product with a value below 10 is
only de-stocked if the demand drops below 2, if the value is between 10 and 100 the
product is de-stocked if the demand is below 10, and if the value is above 100, a
demand below 50 will lead to a de-stocking decision.
The decision for stocking and de-stocking is based on the demand history of the
customer facing location (unless product groups are used as x-axis). Taking e.g. the
number of picks (demand entries), it has to be known that the service is not taking
the absolute figure, but an average over a certain period. This is due to the fact that
weighting factors are used depending whether the period are nearer to today’s date
or not. Additionally a scaling factors (depending to the working calendar) is
considered by planning service when making the stocking or de-stocking decision
The weighted demand history of the previous 6 months is used, where the most
recent 3 months are weighted with 60 % and the earlier three periods with 40 %.
Figure 4.10 visualises the rules as defined in the decision tables shown in Fig. 4.9.
De-Stocking of
Previously Stocked Locations
Procurement
Cost
100
Stocking of Previously Non-Stocked Locations

10
2 10 50 100 Demand Quantity
Fig. 4.10 Visualisation of the example for decision tables
The areas for stocking and de-stocking do not have to cover the all
combinations—e.g. in the case of a demand for five pieces and procurement costs
below ten no decision is taken and the replenishment indicator remains unchanged.
The forecast for the service parts has no impact on the stocking and de-stocking
decisions.
Decision Profiles and Rules

The decision profiles are defined based on the decision tables with the customising
path APO ! Supply Chain Planning ! SPP ! Inventory Planning ! Set Up Deci-
sion Tables for Stocking / De-Stocking—the same as for the definition of the
decision tables. Figure 4.11 shows the maintenance of the decision profiles.
Fig. 4.11 Decision profile maintenance
The logic for the decisions might require the combination of decision tables—
e.g. that both the demand quantity and the number of demand items have to be
below their threshold to change the stocking. For combining the decision tables the
BAdI /SAPAPO/PINV_STDEC has to be implemented.
The decision profiles are assigned to the location with the transaction /SAPAPO/
LOC3 in the view ‘SPP’ as shown in Fig. 4.12.
Fig. 4.12 Assignment of the stocking and de-stocking rules to the location
Exclusion Tables
In some cases the stocking decision for a service part does not only depend on the
demand and the cost but also on other criteria like legal regulations. Some hazard-
ous goods for example might not be stored in certain countries. For this case it is
possible to exclude product groups from the stocking or de-stocking service using
exclusion tables. Figure 4.13 shows how to maintain them with the transaction /
SAPAPO/PINV_EX_MAIN.
Exclusion Rule
© SAP AG © SAP AG
Exclusion Reasons Product Group Combination (Exclusion)
© SAP AG © SAP AG
Product Group Entries
(Exclusion)
© SAP AG
Fig. 4.13 Exclusion table
The exclusion reason is used for descriptive purposes and defined with
the customising path APO ! Supply Chain Planning ! SPP ! Inventory
Planning ! Define Exclusion Reason for Location. If a location product is excluded
due to an exclusion reason, the de-stocking service
• sets the replenishment indicator to ‘non-stocked, blocked’,

• sets the policy lock indicator in the location product master in order to indicate
the exclusion reason and
• displays the exclusion reason is displayed in the location product master.
Regional Stocking
If regional patterns are used to pool the demand of several nearby locations with
comparatively low demand (see Sect. 2.1.2 about virtual locations for consolidated
ordering), these regions are treated like an individual location by the stocking and
the de-stocking service. The stocking indicator is set for the preferred location. The
preferred location is either defined in the regional pattern or selected as the location
with the highest demand.
Stability Periods
To prevent an oscillation of the stocking decisions from stocked to non-stocked, it is
possible define a stability period in the product master as shown in Fig. 4.14.
Fig. 4.14 Set dates stability periods for stocking and de-stocking decisions
The last change of the replenishment indicator is recorded in the product master
as the ‘set date’. In this example the replenishment indicator of the location product
will not change to non-stocked for 20 days (1440 h) counting from the date of the
last change (10.07.2014 18:08:58).
Another date which is recorded in the location product master is the date on
which the product was initially stocked. This date is set when location product is set
as relevant for planning the first time—either automatically of manually. This date
is used in the following situation. Assuming the replenishment indicator for a
location product was already set to ST and then after while was set back to NS. If
then the same location is stocked again by the stocking service, the replenishment
indicator “ST” is set again—and not NS as in the standard case or an initial case.
This function is called re-stocking, which is activated in the general customizing for
inventory planning as shown in Fig. 4.15.
Fig. 4.15 Restocking: activation flag in general inventory planning customizing
4.4 Stocking and De-Stocking Service and Approval 77
This can be accessed via the path Advanced Planning and Optimiza-
tion ! Supply Chain Planning ! Service Parts Planning (SPP) ! Inventory
Planning ! Make General Settings for Inventory Planning
4.4 Stocking and De-Stocking Service and Approval
For stocking the planning service SPP_INVP_STOCKING exists, for de-stocking

the service SPP_INVP_DESTOCKING. Both service profiles contain the key
figure for the demand history (TSID_HIST), from which the historical data is
taken from, Fig. 4.16. How many figures per location products (i.e. number of
past periods) the service is considering is specified with the parameter “Number of
Historical Periods for Stocking/ De-Stocking”. As a default are six periods are
taken.
Fig. 4.16 Service profiles for stocking and de-stocking
If the approval flag is set active, an approval of a new decision has to be taken
always either as shown above in Fig. 4.5 or in the planner’s worklist as shown in
Fig. 4.17.
4.4 Stocking and De-Stocking Service and Approval 79
Fig. 4.17 Stocking/de-stocking approval in the planner’s worklist
The service profiles are defined with the customising paths Advanced Planning
and Optimization ! Supply Chain Planning ! Service Parts Planning (SPP) !
Inventory Planning ! Define Service Profile for Stocking Decisions and Advanced
Planning and Optimization ! Supply Chain Planning ! Service Parts Planning
(SPP) ! Inventory Planning ! Define Service Profile for De-Stocking Decisions.
Forecasting
5
Since service parts planning is mainly a make-to-stock respectively a procure-to-

stock process, planning is almost entirely based on the forecast. The forecast drives
the procurement and replenishment of service parts either directly or indirectly as
an input for the safety stock determination. The basis for forecasting is the
aggregated demand history (including realignment and interactive changes).
Depending on the forecast strategy, not only the demand quantity but also the
number of order items and the average demand quantity per order item might be
used as an input (per forecast strategy only two out of the three).
The forecast is calculated by using a statistical forecast model. This forecast
model and its parameters are defined in the forecast profile. Figure 5.1 shows an
overview of the forecasting process.
Capture Demand Manage Demand
Forecast
Profile Demand History
Forecasting
Model Evaluation Model Selection Parameter Tuning Forecasting
Forecast Forecast Error
EOQ &
DRP Deployment
Safety Stock
Fig. 5.1 Forecasting process overview

82 5 Forecasting
The forecast model and its parameters have a significant impact on the quality of
the forecast. Since service parts planning deals usually with a huge quantity of
service parts it is also important to offer functions to monitor and adjust the forecast
model automatically. This is done in the process steps ‘model evaluation’, ‘model
selection’ and ‘parameter tuning’. The forecast model and its parameters are stored
in the forecast profile. If the performance of the forecast model (measured by
Trigg’s tracking) exceeds the defined thresholds and the stability rules in the
forecast profile allow to change the forecast strategy, an automatic model selection
is performed and the forecast parameters are tuned. The new forecast strategy and
the new parameters are saved in the forecast profile. With these parameters
forecasting is performed. The combination of these four process steps—model
evaluation, model selection, parameter tuning and forecasting—is called composite
forecast. All planning steps are performed with the same planning service.
Figure 5.2 shows the process steps within forecasting.
Model No Yes
Change Automatic Model
Model Evaluation Performance
Allowed? Selection
o.k.?
Yes No
Parameter Tuning
Forecast
Composite Forecast
Disaggregation
Standard Deviation
Calculation
Release
Fig. 5.2 Process steps within forecasting
For the forecast strategies which contain forecast models with smoothing
parameters additionally tripping is used in order to measure the whether the
smoothing parameters are still appropriate. If this is not the case a new initialization
of the forecast model is performed.
The next process steps within forecasting are the disaggregation, the calculation
of the standard deviation and the release of the forecast.
5.1 Process Overview 83
Aggregated and Disaggregated Forecast

The forecast is calculated on two levels, on detailed level (at the child locations)
and additionally on aggregated level (at the parent locations). In service parts
planning the forecast on aggregated level relates to an aggregation along the
BOD (and not to an aggregation along products—which is not possible in service
parts planning). The reason for the aggregation along the BOD is that the forecast is
less sporadic and that the forecast is usually the more accurate the bigger the data
basis is. Therefore the forecast on aggregated level is usually more accurate than the
forecast on detailed location product level. In the next step the forecast on
aggregated level is disaggregated according to the detailed forecasts of the individ-
ual child locations. Figure 5.3 visualizes this procedure.
1b
Aggregated History / Forecast 100 110 120 130 140 150
Parent
Child 1 Child 2
2 2
84 93 Disaggregated Forecast 56 57
1a 1a
50 40 68 72 78 86 Detailed History / Forecast 50 70 52 38 52 52
Fig. 5.3 Forecast on detailed and aggregated level
The forecast is first performed on the detailed level for each location product
based on the demand history (1a). Within the same forecasting service the forecast
is also performed on aggregated level at the parent (1b). This is done based on the
aggregated history along the BOD. In a second step the aggregated forecast is
disaggregated according to the values of the detailed forecast (2).
Forecast Error and Release

The forecast error is calculated as a standard deviation between the forecast and the
demand history. Differing from Demand Planning in SAP APO™, forecasting in
service parts planning does not use the ex-post forecast but the forecast history.
The forecast is released automatically as long as the deviation of the new
forecast to the previous forecast does not exceed the threshold defined in the
forecast profile. Else an interactive forecast release is required. Order for the
forecast are only created with the release, and only these are used by DRP.
84 5 Forecasting
The result of forecasting is the forecasted demand (demand quantity, number of

order items and average demand per order item) and the forecast error—measured
by the standard deviation. The forecast and the forecast error are inputs for EOQ
and inventory planning in order to determine the safety stock (see Chap. 6). The
forecast is used directly for procurement and replenishment by DRP and
deployment.
5.2 Planning Book, Forecast Profile and Forecast Service
5.2.1 Planning Book for Forecasting
The planning book for forecasting is called with the transaction /SAPAPO/
SPPFCST. Accessing planning books in SPP differs from other SAP APO™
handling. The picture at the top of Fig. 5.4 shows the selection screen for planning
books in SPP (not only for forecasting but also for inventory planning, DRP,
procurement approval and deployment).
Fig. 5.4 Enter a planning book in service parts planning
The product and the version are mandatory selection criteria, the location is
optional. After entering the selection criteria, with the button ‘go’ the selected
location products are displayed as shown in the picture at the bottom of Fig. 5.4. If
no location is selected, all the locations of the BOD are displayed.
The transactional data for a product location is displayed by double click on the
location—in Fig. 5.4 on the virtual child location of DCSPB1@QU6715. The
planning book itself is displayed as a third element within the screen below the
selection and locations as shown in Fig. 5.5.
5.2 Planning Book, Forecast Profile and Forecast Service 85
Fig. 5.5 Planning book for forecasting
In the header of the planning book the product, the location and the virtual child
indicator are shown—this is helpful to make sure that the right location was
selected. In this example posting periods are used—months or weeks would also
be possible.
Key Figures
The planning book contains a set of key figures for the demand history, the forecast,
the standard deviation and others. For the demand history, the forecast and the
standard deviation there are separate key figures for the demand quantity
(‘demand’), the number of order items (‘item’) and the average demand quantity
per order item (‘demand/item’).
Because the forecast is calculated on detailed and on aggregated level, there are
different key figures for the detailed forecast (‘forecast’) and the disaggregated
forecast. At the entry location the key figure for the disaggregated forecast is empty.
In forecasting it is possible to overwrite the system proposal interactively in the
key figure ‘manual forecast’. A manual forecast at the child location is not
aggregated along the BOD, but a manual forecast at a parent location is
disaggregated to the children (key figure ‘manual disaggregated forecast’). The
final forecast finally contains the released forecast. Table 5.1 gives an overview
about some of the available key figures.
86 5 Forecasting
Table 5.1 Key figure in the planning book

Key figure Demand Item Demand per item
Final history X X X
Forecast X X X
Ex-post forecast X X X
Disaggregated forecast X X X
Manual forecast X X X
Manual disaggregated forecast X X X
Final forecast X X X
Standard deviation forecast X X X
Standard dev. disaggr. forecast X X X
Standard deviation final forecast X X X
MAD X X X
Basic value X
Trend X
Season indices X
Tracking X
AMS Forecast X
AMS RMSE X
The ex-post forecast is only displayed when performing an interactive

forecasting run. This key figure is not saved.
Planning Book Configuration

Compared to Demand Planning in SAP APO™ there are less possibilities to
configure the planning book (e.g. no macros are possible for service parts planning).
The main tool to configure planning books in service parts planning is the use of the
key figure view, which allows to de-select key figures and to change the sequence of
key figures. Figure 5.6 shows the customizing of the key figure view.
Key Figure View
© SAP AG
Selection & Sequence of Key Figures
© SAP AG
© SAP AG
© SAP AG
Semantic
© SAP AG
Fig. 5.6 Key figure view
The customizing path for the key figure view is APO ! Supply Chain
Planning ! SPP ! Basic Settings ! Settings for User Interfaces ! Assign Key
Figures. Figure 5.7 shows how to switch between key figure views in the planning
book. In this case the change from the view “*” to “PASSON View” causes a
change in the order of the three demand history key figures.
Fig. 5.7 Switching between key figure views
88 5 Forecasting
It is possible to use additional key figures with the BAdI /SAPAPO/

SPPFCST_KF. However, first the key figure has to be created in the TDL with
the transaction /SAPAPO/TDL_APO_SEM with a semantic (see Sect. 2.4).
Interactive Forecasting in the Planning Book

The planning book for forecasting offers the most functionality for interactive
planning in service parts planning. After pressing the ‘change’-button, it is possible
to change the forecast profile and perform an interactive forecast run, to run the
automatic model selection and the parameter tuning and to save the values—either
just the changes in the forecast profile or both the changes in the forecast profile and
the forecast. Alternatively the result of the forecasting run is undone with the
‘reset’-button. Another possibility is the interactive maintenance of forecast values
in the key figure ‘manual forecast’—these values are then used as final forecast.
Figure 5.8 shows the options for interactive forecasting in the planning book.
Fig. 5.8 Functions in the forecasting planning book
Another feature of the planning book is the graphical display of selected key
figures. Figure 5.9 shows the graphic for the demand history and the forecast for a
seasonal forecast model. Always the complete planning horizon is displayed.
Fig. 5.9 Chart for the key figures ‘Demand: Final History’ and ‘Demand: Forecast’
5.2.2 Forecast Profile
The forecast profile contains all parameters for the general proceeding of the
forecast run, the forecast model, the forecast model parameters, the model evalua-
tion, the model selection and the model initialization. Some of the parameters can
be maintained per product but most are maintained product location specifically.
The forecast profile is maintained with the transaction /SAPAPO/SPPFCSTPRF,
Fig. 5.10. The forecast profile is also changed in interactive forecasting or by the
planning steps ‘model selection’ and ‘parameter tuning’.
90 5 Forecasting
© SAP AG
Forecast Model 2
© SAP AG
Fig. 5.10 Forecast profile
Probably the most significant parameter is the forecast strategy. The other
parameters of the forecast profile are grouped in views. Figure 5.11 shows the
structure of the forecast profile.
Forecast Profile
Forecast Model
General Model Model Model Test Test Initialisation

Parameters Selection Evaluation DMA
Seasonal Coefficients Smoothing Factor Set
Fig. 5.11 Forecast profile—structure
Some of the forecast parameters are only displayed if they are applicable to the
forecast strategy. The parameters for the forecast model and the initialization are
described in Sect. 5.5, the parameters for the model selection in Sect. 5.4 and the
parameters for the model evaluation in Sect. 5.3.
General Parameters
The general parameters contain—among others—the definition of the number of
periods for the demand history and the forecast (see also Sect. 5.5.1), the threshold
value for the forecast release (see Sect. 5.7), the switch whether to use the forecast
on the detailed level or the disaggregated forecast and whether outlier correction
should be applied or not (see Sect. 5.5.3). Figure 5.12 shows an extract of the
general parameters of the forecast profile.
Lock Parameters
© SAP AG
X – Detailed Forecast on Location Level

‘ ’ – Disaggregated Forecast
Fig. 5.12 General parameters in the forecast profile (Extract)
Locking an entry in the forecast profile prevents a change of the parameter by

inheritance. Automatic model selection or parameter tuning will change these
parameters even if the lock is set.
The parameter ‘offset forecast creation’ is explained in Sect. 5.3.1 about the
historical forecast and the parameter ‘indicator: automatic outlier correction’ in
Sect. 5.5.4 about outlier correction.
Forecast on Detailed Level vs. Disaggregated Forecast

Whether the forecast at the location product or the disaggregated forecast is used as
final forecast depends on the setting ‘use statistical forecast’ in the forecast profile.
This parameter is set at the parent location and refers to the child locations. The
default setting is to use the disaggregated forecast since it usually provides better
results.
Inheritance of the Forecast Profile

The virtual child location uses the forecast profile of its parent—as long as no
settings are maintained in the forecast profile on virtual child level.
92 5 Forecasting
Creation and Copy of Forecast Profile

The creation of the forecast profile can be done by mass upload from a flat file via
the BAPI BAPISPP0007_TEST_PR7_CHANGE.
Alternatively a manual creation is also possible Forecast planning UI for either
the selected location product or the product individually. If a forecast PSM service
runs the first time, this also can create forecast profiles.
The most usual way to create forecast profiles is the copy of a reference forecast
profile. The reference profile could be of real product or a dummy product. The
copy process can be executed via the transaction /SAPAPO/SPPFCSTPRF as
shown in Fig. 5.13.
Fig. 5.13 Copy function for forecast profiles in the forecast profile maintenance screen
The copy target here is always the forecast profile of location products. The copy
source is either the forecast profile of products or of location products. If a product,
product group, or a product group type is defined as the copy target, the system
copies the forecast profile of the specified copy source to all location products of
this product, product group, or product group type.
For mass copying forecast profiles from one reference source to many other
product or/and location products a PSM service can be applied which uses the
planning service SPP_FCST_PRF_COPY_SRV. Figure 5.14 shows the
corresponding service profile, where especially the source of the forecast profile
to be copied is defined. In this example the location product
IS1_HALB_0001@QU6715 in DCSPB1@QU6715 is the reference location
product.
Fig. 5.14 Service profile for copying forecast profiles
The example also shows that the type of the target forecast profile is location
product.
Which are the target location product specifically is defined in the selection
profile (7 FC 1) of the corresponding PSM profile as shown in Fig. 5.15. That means
all location products being part of this selection are assigned to the reference
forecast profile. There is no restriction on the selection type as well as the package
creation method. This can be seen in figure by the blank field of the process profile.
94 5 Forecasting
Fig. 5.15 PSM planning profile for forecast profile copy service
5.2.3 Forecast Service
Forecasting requires—unlike other planning processes—more than one planning

service and accordingly more than one service profile. As shown in Fig. 5.2, four
planning services are required for a forecasting run:
• Forecasting or composite forecasting

• Disaggregation
• Calculation of the standard deviation
• Forecast release.
For each planning service a separate service profile exists. All the four service
profiles reference a fifth profile for the general forecasting data. The general data is
also used for phase-in and phase-out forecasting, see Sect. 5.8. For a calculation of
the historical forecast a separate service profile is used which contains the first four
profiles from forecasting to release. Figure 5.16 shows the relationship of these
service profiles.
Recalculation of
Forecast in the Past
Disaggregation
Forecast Header Data Forecast (Std. Dev.) Forecast Approval
Disaggregation
Key Figure
Phase-In
Forecasting
General Data
Phase-Out
Forecasting
Fig. 5.16 Service profiles for forecasting
All these service profiles for forecasting are defined with the customizing path
APO ! Supply Chain Planning ! SPP ! Forecasting ! Define Forecast Service
Profile. Figure 5.17 shows the profile for the general forecasting data which contains
the selection type, the number of periods for the demand history and the forecast, the
threshold (in workdays) whether a forecast should be performed for the current month
(see Sect. 5.5.1) and the definition of the key figures for historical data and forecast.
Fig. 5.17 Forecast service profiles—general data
96 5 Forecasting
Only the selection type ‘entire BOD’ includes all locations of the BOD into the
forecast run. The selection type ‘selection’ e.g. does not include virtual child
locations.
Fig. 5.18 Forecast service profile
Since most of the data is defined in the ‘general data’-profile, the forecast service
profile contains only the reference to the ‘general data’-profile and whether com-
posite forecasting should be executed or just a single function of composite
forecasting. Composite forecasting would be the common choice, but for test
purposes any other function can be selected as well, Fig. 5.18. It is only allowed
to select one function.
The service profile for the disaggregation contains—besides the reference to the
‘general data’-profile—the key figures for the disaggregation of the demand quan-
tity (PC), the number of order items (EN) and the average demand per order item
(PP), Fig. 5.19.
Fig. 5.19 Forecast service profiles—disaggregation
The names of the planning services for all forecasting are listed in Table 5.2.
5.3 Model Evaluation 97
Table 5.2 Services for forecasting

Service profile Service
Forecast SPP_FCS_SERVICE
Disaggregation SPP_FCST_DISAGGREGATION
Forecast (standard deviation) SPP_FCS_SERVICE_MSE
Forecast approval SPP_FCST_RELEASE
Recalculation of the forecast in the past SPP_RECALC_HISTFCST
Phase-in forecasting SPP_PHASE_IN
Phase-out forecasting SPP_PHASE_OUT
Preparation service for leading indicator SPP_LFT_SERVICE
Copy profile SPP_FCST_PRF_SRV
Forecast profile copy SPP_FCST_PRF_COPY_SRV
All the services require a selection profile and a package creation method of the
type location product (LOCATIONPRODUCT_PRODUCT)—except for the recal-
culation of the forecast which requires a packaging method of the type
SPP_LOCPROD_FCSTRECALC.
The planning profile for forecasting contains the four services for forecasting
itself, disaggregation, calculation of the standard deviation and forecast release,
Fig. 5.20.
Fig. 5.20 Planning profile for forecasting
5.3 Model Evaluation
5.3.1 Historical Forecast
The model evaluation, the calculation of the standard deviation and the outlier
correction are based on the historical forecast. The historical forecast is usually the
forecast for the next period—but calculated at a point in time in the past. For each
98 5 Forecasting
period the forecast is saved, and the forecast values of the respectively next periods
compose the historical forecast. As Fig. 5.21 shows, this historical forecast is
displayed with the transaction /SAPAPO/SPPFCSTTRACK. The forecast values
which compose the historical forecast are highlighted.
The number of past periods that are displayed for the historical forecast depends
on the forecast strategy and the required number of periods for the standard
deviation (this parameter is set in the ‘model parameter’-view of the forecast
profile). If no historical forecast exists (or if the forecast model changes) the
historical forecast is recalculated by performing a forecast run for each past
period—pretending that the forecasting date is in the past.
Fig. 5.21 Historical forecast
In order to recalculate the historical forecast sufficient periods for the demand
history are required. The recalculation of the historical forecast starts with the first
period of the demand history which is not zero. Depending on the forecast model, a
couple of demand periods are required for the initialization of the forecast model.
There should be at least sufficient demand history to recalculate the forecast history
for the number of periods for the calculation of the standard deviation.
Offset for Forecast Creation

Per default the forecast history is calculated using the forecast values for the
respectively next period as Fig. 5.21 shows. For example, the historical forecast
for May 2014 is the value that was calculated in May 2014. The idea is that the
reliability of the forecast decreases the further it looks into the future. However,
using the parameter ‘offset forecast creation’ in the ‘general’-view of the forecast
profile it is possible to compose the historical forecast e.g. by the respective forecast
values for the third period into the future with an offset of ‘3’. In this case the
historical forecast for May 2014 is a value that was calculated in March 2014.
Figure 5.22 shows the difference in the historical forecast depending on the offset
for forecast creation. As indicated by highlighting, the values for the historical
forecast differ, and it becomes clear that the values are shifted to the right (within
the same row) or upward (within the same column) by increasing the offset.
Fig. 5.22 Impact of the offset for forecast creation in the historical forecast
The Offset for Forecast Creation is one of the input parameters for forecast error
calculation in order to control that the right forecast values are used. Therefore this
parameter also influences the safety stock determination.
The value of the field Offset for Forecast Creation can be set manually in the
forecast profile as shown in Fig. 5.23. This value should reflect the supplier’s lead
time taking into consideration the forecast planning periodicity. E.g. if the lead time
is 3 weeks and the planning buckets are months, then the offset should be 1. If
e.g. the lead time is 8.5 weeks, then the offset should be 3.
100 5 Forecasting
Fig. 5.23 Offset forecast creation parameter in the forecast profile
If the lead time changes then this parameter is not updated automatically unless a
certain planning service is applied. This planning service is called
SPP_FCST_OFFSET_RECALC. At least up to SCM 7.12 this needs to be
configured explicitly in an implementation project according to OSS note 1610427.
Figure 5.24 shows the planning service SPP_FCST_OFFSET_RECALC as it is
configured in the customizing and assigned to the relevant package creation
methods “Locationproduct_Product”, “Locationproduct_Product _INCFC”,
Locationproduct_Simple. The figure shows furthermore that the service is assigned
Fig. 5.24 SPP_FCST_OFFSET_RECALC planning service for determination of offset forecast

creation parameter
to the trigger SPP_SUPPLIER_CHANGED. That means as soon as the supplier for

a certain product or the corresponding lead time of the supplier changes it triggers
the re-determination of the parameter Offset for Forecast Creation. Eventually the
service stores the resulting value persistently into the database
Planning Service for the Recalculation of the Forecast History

The recalculation of the forecast history is done with the planning service
SPP_RECALC_HISTFCST. Figure 5.25 shows the service profile (customizing
path APO ! Supply Chain Planning ! SPP ! Forecasting ! Define Forecast
Service Profile) which contains the four service profiles for forecasting, disaggre-
gation, calculation of the standard deviation and forecast release.
Fig. 5.25 Service profile for the calculation of historical forecast
The relevant trigger for calculation of the historical forecast is SPP_FCSTMO-

DEL_CHANGE, and the trigger profile is ignored.
5.3.2 Tracking
Tracking is the function to determine whether the forecast model is appropriate or

not. The basic idea of tracking is to check whether the deviation of the forecasted
values always tends towards one direction. If this is the case, it is likely that the
forecast model is not appropriate and automatic model selection is triggered.
Tracking signals are set for a period, if the ratio of the smoothed average
deviation (SAD) and the mean average deviation (MAD) exceeds a threshold
102 5 Forecasting
value. The smoothed average deviation SAD (t) is calculated as described in

formula 5.1:
SAD ðtÞ ¼ α ½Demand ðtÞ Forecast ðtÞ þ ð1 αÞ SAD ðt 1Þ ð5:1Þ
The mean average deviation is calculated similarly, only that the sign of the
difference between demand and forecast is ignored, formula (5.2).
MAD ðtÞ ¼ α ½jDemand ðtÞ Forecast ðtÞj þ ð1 αÞ MAD ðt 1Þ ð5:2Þ
If the deviations are in both directions—i.e. sometimes the real customer demand is
higher and sometimes lower than the forecast—the SAD will be much smaller than
the MAD. Therefore the ratio of SAD and MAD is a good measure whether this is
actually the case.
To calculate the tracking signal, one period is required for initialization—when
the previous values of SAD and MAD are zero, the ratio of |SAD/MAD| is one.
Table 5.3 shows an example for the calculation of |SAD/MAD| for a tracking
smoothing factor α of 0.2.
5.3
Model Evaluation
Table 5.3 Example for tracking

Period 1 2 3 4 5 6 7 8 9 10
Demand 95 102 98 104 102 105 103 102 100 98
Forecast 100 100 100 100 100 100 100 100 100 100
SAD 0.2 0.24 0.21 0.63 0.9 1.72 1.98 1.98 1.58
MAD 1.8 1.84 1.87 2.3 2.24 2.79 2.83 2.66 2.13 2.1
|SAD/MAD| 0.11 0.13 0.11 0.27 0.4 0.62 0.7 0.74 0.74 0.41
Threshold 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6
Tracking 0 0 0 0 0 1 2 3 4 4
103
104 5 Forecasting
The ratio of |SAD/MAD| rises as soon as the deviation of the actual demand
tends toward one side—in this example above the forecast values—from period 5 to
8. As soon as the deviation changes its direction—in period 10 the actual demand is
below the forecast—the ratio of |SAD/MAD| decreases. In this example the thresh-
old for tracking is 0.6, and the tracking horizon is 10 periods. If the number of
tracking signals within the tracking horizon—in this case 4—exceeds a certain
limit, a tracking exception is raised.
The values for the tracking smoothing factor, the tracking horizon, the tracking
threshold and the number of tracking signals within the tracking horizon are defined
in the forecast profile. Figure 5.26 shows these entries on the ‘model
evaluation’-view.
Fig. 5.26 Parameters for tracking in the forecast profile
To perform tracking, the forecast planning service SPP_FCS_SERVICE

is used. In the service profile (customizing path APO ! Supply Chain
Planning ! SPP ! Forecasting ! Define Forecast Service Profile) either tracking
or composite forecast has to be selected, Fig. 5.27. Tracking is only performed for
the demand quantities and not for the demand items.
Fig. 5.27 Forecast service profile for tracking
If the number of tracking signals within the defined horizon exceeds the
threshold that is defined in the forecast profile, an automatic model selection is
executed.
5.3.3 Tripping
Tripping is another method to determine whether the forecast has a systematic

deviation to the real demand. However, tripping is only applicable to the forecast
models which use exponential smoothing. The result of tripping might be a new
initialization of the forecast model but not a change of the forecast model.
The idea of tripping is to count the number of periods where the actual demand is
outside the forecast plus its standard deviation. For tripping only the number of
subsequent values outside the standard deviation (to one side) count. The tripping
counter increases with each value that is outside the standard deviation (signs are
used—i.e. the tripping counter increases by one with each value that is above the
forecast plus the standard deviation and it decreases with each value that is below
the forecast minus the standard deviation). If the next value is within the standard
deviation, the tripping counter is reset to zero. If it is outside the standard deviation
but to the other side, it is set to one (or minus one, depending whether it is above or
below the borders). Figure 5.28 visualizes the function of the tripping counter.
The tripping counter is also reset if the forecast model changes or the parameters
change.
106 5 Forecasting
Demand
Forecast +
Standard Deviation
Forecast
Forecast -
Standard Deviation
Tripping
0 1 2 3 0 1 -1 -2 0 Counter
Fig. 5.28 Tripping
Tripping is performed independently for the demand quantities, the demand

items and the average demand quantity per item. It is however only available for the
forecast models first and second order exponential smoothing and the intermittent
forecast model.
The parameters for tripping—the limits for the trip length for the lower and the
upper demand—are defined independently for the demand quantity, the number of
order items and the average demand per order item in the forecast profile. Fig-
ure 5.29 shows these settings.
Demand
Item
Demand
per Item
© SAP AG
Fig. 5.29 Parameters for tripping in the forecast profile
If the trip length exceeds the limits that are defined in the forecast profile, a new
initialization of the forecast model is performed—starting from the point in time
where the trip length exceeded the limit. This implies that the history before this
point in time does not influence the forecast results any more.
5.4 Model Selection and Parameter Tuning 107
5.4 Model Selection and Parameter Tuning
5.4.1 Model Selection
Automatic model selection is either performed as a part of the composite forecast or

if model selection is configured in the planning service profile for forecasting (see
Fig. 5.30). As part of composite forecasting the automatic model selection is only
performed if the model evaluation indicates a bad performance of the model. If the
automatic model selection is chosen in the service profile, automatic model selec-
tion is performed anyway.
Fig. 5.30 Forecast service profile for automatic model selection
Another possibility to perform automatic model selection is to trigger it interac-

tively in the forecasting planning book.
For the automatic model section the system performs the tests for seasonality,
trend, sporadic behavior and whether the dynamic moving average model is
relevant. The test sequence is defined with the customizing path APO ! Supply
Chain Planning ! SPP ! Forecasting ! Configure Automatic Model Selection as
shown in Fig. 5.31. To each test one or more models are assigned. If the test is
positive, one of the assigned models is chosen—the lower the weighting factor, the
more likely the model is picked.
108 5 Forecasting
Fig. 5.31 Customizing for the automatic model selection
In this example first a test for seasonality is performed and the seasonal trend
model with fixed periods is selected if the test is positive. The test for trend will
choose second order exponential smoothing or linear regression. If this test is
unsuccessful too, the system tests whether the demand history has a sporadic
behavior and chooses the intermittent model or dynamic moving average. Only
then other forecast models might be chosen. The seasonal trend model is not
considered by automatic model selection. If the seasonal trend model is to be
used, it must be selected interactively in the forecast profile.
A change of the forecast strategy creates a trigger for the recalculation of the
historical forecast with the new forecast strategy. The change date of the forecast
strategy is recorded in the forecast profile.
To prevent a change of the forecast strategy it is possible to lock the forecast
strategy in the forecast profile. To prevent frequent changes of the forecast strategy
it is possible to use stability periods in the forecast profile. Figure 5.32 shows these
settings.
© SAP AG
Stability Periods
© SAP AG
Fig. 5.32 Locking and stability periods for the forecast strategies
5.4 Model Selection and Parameter Tuning 109
5.4.2 Parameter Tuning
Parameter tuning tests changes of the values for the alpha, beta and gamma factor in
order to reduce the forecast error. This function is only applicable to the forecast
models first order exponential smoothing (FOES), second order exponential
smoothing (SOES) and the seasonal trend model.
Two different functions exist for parameter tuning—rough-tuning and fine-tuning.
Parameter Rough-Tuning Rough-tuning of the parameters is performed as a part

of the composite forecasting (if the model performance was not satisfactory) or if it
is defined as a separate forecast planning step in the service profile.
The prerequisite for the automatic parameter tuning is that a smoothing factor set
is assigned to the ‘model parameter’-view of the forecast profile (see Fig. 5.34). The
smoothing factor set is defined with the customizing path APO ! Supply Chain
Planning ! SPP ! Forecasting ! Define Smoothing Factor Set, Fig. 5.33.
Fig. 5.33 Smoothing factor set
The forecast is performed for the smoothing parameters as defined in the forecast
profile and for any of the smoothing factor combinations as defined in the smooth-
ing factor set. For performance reasons only these combinations are used and not a
permutation of each parameter value. The combination with the smallest standard
deviation is used, and the parameters are saved in the forecast profile.
Parameter Fine-Tuning
Fine tuning is only performed if it is triggered interactively within the forecasting
planning book—e.g. because rough-tuning was not satisfactory. Fine-tuning is
based on a start value, an end value and an increment for each smoothing parameter
(if applicable). These settings are maintained in the ‘model parameter’-view of the
forecast profile as shown in Fig. 5.34.
110 5 Forecasting
Fig. 5.34 Settings for parameter tuning in the forecast profile
A permutation of all smoothing factor values is carried out. Therefore a big

difference between start and end value and small increments might lead to perfor-
mance issues.
5.5 Calculation of the Forecast
5.5.1 Forecast Horizons
Typically two horizons apply for forecasting: the number of periods for the demand
history and the number of periods for the forecast calculation. These horizons are
maintained in the ‘general data’-profile of the service profile for forecasting and are
restricted by the parameters in the ‘general’-view of the forecast profile. Figure 5.35
shows these entries in the forecast profile and in the service profile for forecasting.
Forecast Profile Service Profile for Forecasting
© SAP AG
© SAP AG
Fig. 5.35 Determination of the forecast horizons
The horizons of the forecast profile are used, and it is possible to extend or to
restrict the horizons of the service profile. However, if the horizons in the forecast
profile exceed the horizons in the service profile, a warning is issued.
For the calculation of the current period two alternatives exist. The first alterna-
tive is ignoring the customer orders of the current period and calculating the
forecast without this information. The second alternative is extrapolating the
current customer orders to the end of the period. In general the second
5.5 Calculation of the Forecast 111
alternative—to extrapolate the current customer orders—will provide the better

results the later in the period it is used. The parameter ‘forecast relevant workdays’
in the ‘general data’-profile controls that if the current workday is past this day the
demand history of the current period is extrapolated. Figure 5.36 shows an example
to visualize these alternatives.
Forecast Relevant Workdays > 15:

Calculate Forecast for the Current Period based on Demand History up to Previous Period
Last Period Current Period Next Period
Demand History 190 200 165
Forecast 210 220
Today
(15th Workday of the Month)
Forecast Relevant Workdays < 15:

Calculate Forecast for the Current Period by Scaling the Demand History of the Current Period
Last Period Current Period Next Period
Demand History 190 200 165
Forecast 231 220
Today
(15th Workday of the Month)
Fig. 5.36 Forecast relevant workdays and forecast for the current period
The forecast is performed on the 15th workday of the month. If the parameter
‘forecast relevant workdays’ contains a value above 15, the information about the
demand history of the current period is not taken into account. Assuming that the
demand history contains a trend, an appropriate forecast model would calculate the
forecast for the current and the next periods by extrapolating this trend—in this
example the forecast for the current period would be 210 pieces.
If the parameter ‘forecast relevant workdays’ contains a value below 15, the
forecast for the current period is not calculated by the forecast model but by
extrapolating the demand history of the current month. In this example the demand
history is 165 pieces—which relates to an average of 11 pieces per day and—
assuming 21 workdays—to a forecast of 231 pieces. This value is also used as the
demand history for the current period and is considered for forecasting.
5.5.2 Forecast Model Overview
Forecasting in service parts planning offers a couple of forecast models. All of these
models are univariate forecast models—in the current release no causal relationship
(e.g. to the installed base) is considered. Compared to Demand Planning in SAP
APO™ some additional forecast models—especially for slow moving parts—exist
112 5 Forecasting
(and some are missing, e.g. multiple linear regression). Depending on the forecast
model an initialization is required and outlier correction inherent, possible or not
possible.
The forecast is calculated for the demand quantity, the number of order items
and the average demand per order item. Out of these three parameters only two are
calculated independently, and the third is calculated by the other two. The leading
parameter is either the demand quantity or the number of order items. The average
demand per order item is calculated as a constant value using first order exponential
smoothing (except for dynamic moving average), and the dependent parameter is
calculated by the leading parameter and the average demand per order item.
Table 5.4 provides an overview of the forecast models in service parts planning.
Table 5.4 Forecast model overview

Leading Outlier
Forecast model Name parameter Initialization correction
First order exp. smoothing A1 Demand Yes Yes
First order exp. smoothing A2 Item Yes Yes
Second order exp. B1 Demand Yes Yes
smoothing
Moving average C1 Demand No Yes
Linear regression D1 Demand No Yes
Seasonal trend model E1 Demand Yes No
Seasonal trend fixed periods F1 Demand No Yes
Intermittent G1 Demand Yes Inherent
Dynamic moving average H1 Item No Inherent
Declining demand forecast I1 Demand No Inherent
Initialisation
If the forecast model uses a recursive algorithm—meaning the current value of a
term depends on the previous value of the same or another term—some periods of
demand history are required in order to provide these previous values for all terms.
For the initialization of the forecast model the global model initialisation data must
be maintained with the customizing path APO ! Supply Chain
Planning ! SPP ! Forecast ! Initialize Base Values. Within the ‘initialization’--
view of the forecast profile it is possible to maintain the parameters for the
determination of the upper and the lower MAD limit.
Parameter Overview
Depending on the forecast model different parameters are required. These
parameters are maintained in the ‘model parameters’-view of the forecast model,
and only those parameters are displayed which are relevant for the chosen forecast
model. Some of these parameters are only used by a specific forecast model,
others—like smoothing parameters—are used by several forecast models. Table 5.5
provides an overview of the more common parameters.
Table 5.5 Common forecast model parameters

Parameter A1 B1 C1 D1 E1 F1 G1 H1 I1
Alpha X X X
Beta X X
Gamma X
Smoothing Par. Set X X X
Time smoothing X
MAD smoothing X X
Trend delimiter X X X
Per. for trend line X X
Periods for std. dev. X X X X X X X X X
Smoothing Factors
The factors alpha, beta and gamma are smoothing factors for the calculation of the
base value, the trend and the seasonality when using exponential smoothing (first
order, second order or trend seasonal model) For the rough tuning of these smooth-
ing parameters a smoothing parameter set is required. If fine tuning is used, not only
the value of these parameters but also the start value, the end value and the
increment have to be maintained (see Sect. 5.4).
For the intermittent model (G1) a smoothing factor is used to calculate the
periods between the order items, and another smoothing factor for the mean average
deviation (MAD). The latter is also required for the dynamic moving average.
Forecast Trend Delimiter

The forecast models second order exponential smoothing (B1), linear regression
(D1) and seasonal trend (E1) do calculate a trend. After some periods this trend
might result in very high or very low forecast values, which does not necessarily
represent a likely forecast. Extreme forecast values can be avoided by using the
forecast trend delimiter which cuts off the trend—either after a certain number of
periods (parameter ‘forecast trend delimiter (temporal)’) or if the forecast value
exceeds the current value by a certain percentage. Figure 5.37 shows these settings
in the ‘model parameter’-view of the forecast profile for a restriction after 50 % or
12 periods.
Fig. 5.37 Forecast trend delimiter
114 5 Forecasting
The impact of the forecast trend delimiter is shown in Fig. 5.38—at the left
without trend delimiter and at the right with trend delimiter.
Fig. 5.38 Forecast without and with trend delimiter
Forecast Model Selection

The selection of the appropriate forecast model is of crucial importance for the
quality of the forecast. The most important factor to determine the forecast model is
the type of the demand history. Typical types of the demand history are constant
demand, trend, seasonal demand, seasonal demand with trend—and very often for
service parts—sporadic or intermittent demand. Towards the end of the life cycle
declining demand is another type. Figure 5.39 shows these demand history types.
Constant Trend Sporadic
Season Trend & Season Declining
Fig. 5.39 Demand history types
The selection of the forecast model is usually based on an analysis of the demand
history—either interactively or automated as described in Sect. 5.4. In the following
we describe very briefly the nine different forecast models for service parts
planning. The purpose is rather to give an idea about the rough properties of each
model than to describe in detail how they calculate the forecast. The latter is found
e.g. in the SAP online help.
First Order Exponential Smoothing

First order exponential smoothing (FOES) is often used as a default for a constant
forecast. Depending on the alpha smoothing factor the more recent demand has a
bigger influence on the forecast—the higher the alpha factor the bigger the influ-
ence of the more recent values. Common values for alpha are between 0.1 and 0.3.
In service parts planning it is possible to use this model with the demand quantity
(A1) or with the demand items as leading parameter (A2). In the latter case zero-
demand periods (with an undefined average demand per order item) are skipped for
calculation. Figure 5.40 shows an example for the forecasting with a first order
exponential smoothing model. In this case 4 years of demand history are used and
the forecast is calculated for 2 years.
Demand History Forecast
© SAP AG
Fig. 5.40 Forecasting with first order exponential smoothing
This example shows very clearly that the result of the first order exponential
smoothing is a constant value and that more recent values have a bigger impact.
Second Order Exponential Smoothing

If the demand history suggests a trend, second order exponential smoothing (SOES,
B1) is a very common forecast model. Additionally to the first order exponential
smoothing a term for the trend is added. This term is smoothed by the beta factor—
the higher the beta factor the bigger the influence of the more recent values.
Figure 5.41 shows the forecast with second order exponential smoothing for the
same history as in Fig. 5.40.
116 5 Forecasting
Fig. 5.41 Forecasting with second order exponential smoothing
Moving Average
The moving average (C1) is a simple model to determine a constant forecast. The
forecast is calculated as the average of the last NMA periods of the demand history.
Typical ranges for NMA are 6 to 12 periods—the bigger NMA, the more balanced the
forecast. NMA is maintained as ‘periods for moving average’ in the ‘model
parameters’-view of the forecast profile. Figure 5.42 shows an example for the
moving average.
Fig. 5.42 Forecasting with moving average
Linear Regression
Linear regression (D1) extrapolates the demand history with a straight line using the
method of the least squares as shown in Fig. 5.43. The number of historical periods
to determine the straight line is maintained as ‘periods for trend line’ in the ‘model
parameters’-view of the forecast profile.
Fig. 5.43 Forecasting with linear regression
Seasonal Trend Model

The seasonal trend model (E1) works similar like the second order exponential
smoothing but considers also seasonal patterns. The seasonal patterns are not
adapted from the demand history but modelled by seasonal coefficients which are
maintained explicitly—which is an advantage if only few periods of demand
history are available. Figure 5.44 shows an example for forecasting with the
seasonal trend model.
Fig. 5.44 Forecasting with the seasonal trend model
A prerequisite for the execution of the seasonal trend model is that a seasonal
coefficient group is assigned to the forecast profile. The seasonal coefficient group
is created with the customizing path APO ! Supply Chain Planning ! SPP !
Forecasting ! Define Seasonal Coefficients and contains seasonal indices for
12 periods, Fig. 5.45. These seasonal coefficients define the shape of the seasonal-
ity. In order not to smooth these coefficients the gamma factor should be zero.
118 5 Forecasting
Season Coefficient Group
© SAP AG © SAP AG
Fig. 5.45 Season coefficient group
Seasonal Trend Model with Fixed Periods

The seasonal trend model with fixed periods (F1) is the default model for service
parts with seasonal demand behavior. At least 24 months of demand history are
required for this forecast model. The annual trend is determined and the past
seasonality applied on top. The seasonal coefficients are calculated as an average
from the past years. If 36 periods of demand history are available, the trend is
calculated as the weighted average of the 3 years. The annual weighting factor is
defined in the forecast profile. Figure 5.46 shows an example for this forecast
model.
Fig. 5.46 Forecasting with seasonal trend model with fixed periods
Intermittent Model
The model for intermittent demand (H1) is designed for sporadic demand. Similar
to the Croston model, it calculates the demand quantity based on non-zero periods
and the duration between the demand periods. Exponential smoothing is applied to
calculate the durations between the demand periods, and—differing from the
Croston model—the demand quantities are determined as an average of the
non-zero periods. The result of the forecasting with the intermittent forecast
model is a constant forecast as shown in Fig. 5.47.
Fig. 5.47 Forecasting with the intermittent model
Dynamic Moving Average

The dynamic moving average (H1) is a modified moving average model especially
if the standard deviation of the demand is large—as is often the case for slow
moving parts. The first step for the forecast calculation is the determination of the
demand history. Using t-tests it is checked whether there are significant differences
in the more recent demand history compared to the less recent demand history. The
less significant differences exist, the more periods are used. After outlier correction
the forecast is calculated for the order items as an average of the demand history.
Figure 5.48 shows an example for forecasting with the dynamic moving average
model.
120 5 Forecasting
Fig. 5.48 Forecasting with the dynamic moving average model
The dynamic moving average model uses the weekly forecast values. These
values are available even if the periodicity for forecasting was set to month or
posting periods.
Declining Demand
The declining demand forecast is used for the end of a service part’s life cycle.
Assuming a constantly declining demand for a service part an exponential curve is
used for the future projection of the demand. The prerequisite for the model is that
there is a declining growth rate (Fig. 5.49).
Fig. 5.49 Forecasting with the declining demand forecast model
Other prerequisites are that the product is not marked as ‘new product’ and that
forecast values exist for the current period.
A detailed description of the forecast model algorithms is found in the SAP
online help for service parts planning.
5.5.3 Standard Deviation
The standard deviation σ is an indicator for the difference between the historical
forecast and the demand history and is therefore an indicator for the quality of the
forecast. The calculation of the standard deviation is based on a number of past
periods. The number of past periods is defined in the ‘model parameter’-view of the
forecast profile.
Assuming that the number of past periods for the calculation of the standard
deviation is smaller than the number of periods for the demand history, different
values exist for the standard deviation in the past periods. Therefore the value of the
standard deviation depends on the period. For future periods the last value of
standard deviation is applied and the standard deviation is constant (except for
the seasonal trend model with fixed periods). The standard deviation is calculated
for the demand quantities, the number of order items and the average demand per
order item, and for the (detailed) forecast and the disaggregated forecast respec-
tively. The standard deviation for the final forecast is either the standard deviation
of the detailed forecast or the disaggregated forecast—depending whether ‘use
statistical forecast’ is selected. Figure 5.50 shows the standard deviation for the
demand quantity in the forecasting planning book.
Fig. 5.50 Display of the standard deviation in the forecasting planning book
The standard deviation is calculated together with the mean average deviation
(MAD) after performing the forecast. The standard deviation in the past is required
for the model evaluation. The standard deviation for future periods is required for
the calculation of the EOQ and the safety stock (see Chap. 6).
5.5.4 Outlier Correction
The purpose of the outlier correction is to avoid that untypical values of the demand
history mess up the forecast. Therefore the demand history is adjusted automati-
cally before calculating the forecast. This adjustment is only temporary and not
saved—the original demand history remains unchanged. For most of the forecast
models outlier correction is an optional step, only for the intermittent model (G1),
the dynamic moving average (H1) and the declining demand forecast (I1) the
122 5 Forecasting
outlier correction is inherent and differs a little from the ‘normal’ procedure. For the
seasonal trend model (E1) outlier correction is not possible. The ‘normal’ outlier
correction for the forecast models A1 to D1 and F1 is described in the following.
Whether a historical demand value is considered as an outlier depends on its
difference to the historical forecast of that period. If this difference exceeds a
threshold, the demand history is adjusted (temporarily) to the boundary value.
Outlier correction is only performed for demand values that are exceptionally
high. Low values are not adjusted because periods with zero demand are common
for service parts. Figure 5.51 shows the effect of outlier correction.
Demand History
without Outliers
Demand History
Historical Forecast
+ Threshold
Historical Forecast
Historical Forecast
- Threshold
Fig. 5.51 Outlier correction
Differing from Demand Planning in SAP APO™, the historical forecast is used
and not the ex-post forecast.
Outlier correction is performed for the demand quantity and the average demand
per order item. The threshold depends on the standard deviation σ and a factor—α
for the demand quantity and β for the demand per order item. Formula 5.3 describes
the condition for an outlier (for the demand quantity):
ðDemand ðtÞ Forecast ðtÞÞ > α σ ðtÞ ð5:3Þ
Whether outlier correction is performed or not depends on the settings in the

‘general’-view of the forecast profile (except for the models G1, H1 and I1 where
outlier correction is inherent and therefore always performed). Figure 5.52 shows
the indicator for automatic outlier correction which controls that outlier correction
is performed (value ‘Z’). Outlier correction is performed before forecasting. The
parameters for the threshold definition (in relation to the standard deviation)—the α
and the β factor—are defined in the forecasting profile as well.
5.6 Forecast Approval 123
Fig. 5.52 Parameter for outlier correction in the forecast profile
With the parameter ‘offset forecast creation’ it is possible to shift the reference
period for the forecast. The standard setting for this offset is 1.
5.6 Forecast Approval
The purpose of the forecast approval is to determine the final forecast for the facing
locations. There are two forecasts available:
• the statistical forecast that was calculated based on the demand history of the
location and
• the disaggregated forecast that was calculated based on the aggregated demand
of all locations and disaggregated according to the individual statistical forecasts
of the locations.
Which of these forecasts is used as final forecast depends on the setting ‘Do Not
Use Disaggregated Forecast’ in the tab ‘general settings’ of the forecast profile of the
parent location (‘X’—statistical forecast, blank—disaggregated forecast), Fig. 5.53.
Interactively maintained forecast values always overwrite the calculated forecasts.
Fig. 5.53 Settings for the forecast release in the forecast profile
124 5 Forecasting
For each period the new forecast is compared with the previous forecast. If the
biggest deviation exceeds the threshold that is defined in the forecast profile (tab
‘general settings’, parameter ‘Approval: Maximum Deviation’), no final forecast is
calculated. In this case the final forecast of the previous planning run remains active
until the forecast values are manually approved. The planning log issues a warning
for this case.
Fig. 5.54 Forecast approval
The manual approval UI can be accessed directly from Forecast Matrix or with
the transaction /SAPAPO/SPPFCSTAPPR. For each of the location products
(in Fig. 5.54 product IS1_HALB_0002@QU6715 in location DCSPB2@QU6715)
the deviation is displayed (in this case 0.95). Entries are only displayed if there are
forecasts to be approved. The approval is executed for the highlighted lines by
pushing the “Approve”-button. In order to prepare the approval making properly,
there is the possibility to jump directly to the DRP Matrix, inventory matrix or to
the forecast matrix with the right pre-selected location product.
During the forecast approval forecast orders are created—these are displayed
also in the product view with the transaction /SAPAPO/RRP3. DRP requires these
forecast orders. Before the forecast approval the forecast exists only in the time
series in TSDM.
5.7 Life Cycle Planning 125
5.7 Life Cycle Planning
5.7.1 Phase-In Forecasting
The idea of phase-in forecasting is to use the demand history of other products
which have been recently introduced as a basis to determine the forecast for a new
product. The product group determines which products are used for a reference
demand history.
The phase-in forecasting for new products is done in two steps. In the first step
the demand history is scaled and stored in the phase-in profile, and in the second
step the scaled demand curve of the phase-in profile is applied for the new product.
Accordingly the service for new product forecasting (SPP_PHASE_IN) is
performed twice—with two different settings of the service profile. The service
profile for phase-in forecasting is defined with the customizing path APO ! Supply
Chain Planning ! SPP ! Forecasting ! Define Forecast Service Profile as
described in Sect. 5.2. Figure 5.55 shows the service profiles with the assignment
of the product group type and the control parameters ‘generate phase-in profile’ and
‘phase-in forecasting’.
Fig. 5.55 Service profile for Phase-In forecasting
Note that this service requires a package creation method of the type
PRODUCT_SIMPLE and not LOCATIONPRODUCT_PRODUCT.
The phase-in group defines how the demand curve in the phase-in profile is
created—the number of phase-in forecast values (‘length’), the maximum number
of demand history periods and the minimum number of reference products to create
the phase-in profile. The phase-in group is maintained with the customizing path
APO ! Supply Chain Planning ! SPP ! Forecasting ! Define Phase-In Group,
Fig. 5.56.
126 5 Forecasting
Fig. 5.56 Phase-in group
The phase-in group is linked to the service part by using the same name for the
product group. Figure 5.57 provides an overview of the settings for phase-in
forecasting.
Phase-In Forecasting
Service Profile Phase-In Profile
(Generate Phase-In Profile)
Identical Name
Product Group Type Product Group Phase-In Group
Product
Fig. 5.57 Structure for phase-in forecasting
The connection between the phase-in group and the product is displayed in the
forecast profile, Fig. 5.58. This assignment is done automatically and cannot be
changed interactively.
Fig. 5.58 Phase-in settings in the forecast profile
5.7 Life Cycle Planning 127
A prerequisite for phase-in forecasting is that the product is marked as a new

product. This flag is set in the ‘properties of SPP’-view of the product master as
shown in Fig. 5.59.
Fig. 5.59 Indicator for new product in the product master
5.7.2 Phase-Out Forecasting
Even if the production for the primary product has ceased, demand for the service
part might occur quite some time later. For legal but also for commercial reasons it
might therefore be required to keep the service part available for the customer.
The purpose of phase-out forecasting is to provide a reliable forecast for the
service part at the end of the life cycle. Similar to phase-in forecasting the phase-out
forecast is performed based on the demand history of reference products with the
following three steps:
1. The phase-out profile is calculated based on the historical demand of the

members of the phase-out group. The phase-out group contains percentages
for the declining of the forecast.
2. The demand history of the final year—i.e. the year when the production of the
primary product ended—is extrapolated by applying the percentages of the
phase-out profile.
3. The phase-out forecast is compared with the actual history on a regular basis. If
the threshold for the deviation is surpassed, an adjustment of the demand is
performed. The percentage for the adjustment is the mean of the deviation of the
last years.
The phase-out forecast is performed in yearly buckets. Therefore the time series
for yearly buckets have to be used in the ‘general data’-profile. Figure 5.60 shows
the ‘general data’-profile and the phase-out forecasting profile.
128 5 Forecasting
General Data Phase-Out Forecasting
© SAP AG
© SAP AG
Fig. 5.60 Phase-out forecast service
The forecast is only performed at the entry location of the respective product
with the planning service SPP_PHASE_OUT. It is also possible to perform the
phase-out forecasting and the adjustment interactively with the transaction /
SAPAPO/SPPLONGFCST. The phase-out profile is displayed in this transaction
as well. The generation of the phase-out profile however is only possible as a
planning service.
The phase-out group is defined with the customizing path APO ! Supply Chain
Planning ! SPP ! Forecasting ! Define Phase-Out Group, Fig. 5.61.
Fig. 5.61 Phase-out group
The ‘length of profile’ defines the number of years for the phase-out profile. The
minimum percentage value is used if the percentage value in the phase-out profile
should fall below this minimum value, and the percentage of reduction is used if the
forecast horizon exceeds the length of the profile. The phase-out group is assigned
to the ‘general’-view of the forecast profile for the entry location, Fig. 5.62.
5.8 Leading Indicator Based Forecasting 129
Fig. 5.62 Assignment of the phase-out group to the forecast profile
The prerequisite for phase-out forecasting is that the production end date of the
primary product (as maintained in the ‘SPP inventory balancing/surplus’-view of
the product master) is already reached, Fig. 5.63.
Fig. 5.63 Production end date
5.8 Leading Indicator Based Forecasting
5.8.1 Process Overview
Time series forecasting is sometimes not so successful because products are

characterized by factors like e.g. the life cycle situation, which cannot be well
enough reflected by these forecast models. Also e.g. in young industries like the
wind power and turbine industry often not sufficient demand history is available in
order to have a reliable basis for producing high performance forecasts. Here the
installed base as an alternative orientation indicator is helpful. Each windmill has
three rotor blades, which can break each from time to time or have to be treated with
a recurring maintenance. Since there is a positive correlation between the installed
number of windmills and rotor blades as the respective spare parts this can be a
good basis for forecast. Therefore SAP SPP offers an installed-base oriented
forecast solution, which can be considered as a somehow causal forecasting
method, since it is not only based on the time series of historic demands. It is the
so-called leading indicator based forecast. The installed base is usually defined as
the whole set of systems or products respectively a company has sold and which are
still in use as in the example of the wind turbine producer, whose customers still
have thousands of its products in use. This installed base of these windmills is likely
to need maintenance and spare parts in order to continue functioning.
130 5 Forecasting
SPP proposes as the three most common leading indicators the installed base, the
number of use of an installed base and the operating time. The installed base in our
example would be the number of wind mills which are still in use all over a certain
region, for which the forecast should be done. The operating time is the duration of
usage across all windmills still existing.
The indicator “number of use” represents discrete events in the lifetime of the
installed base. Looking at airlines, the installed base is the number of airplanes and
the operating time the flight hours. However, since take offs and landing puts more
stress on the airplanes than steady flight, number of use would represent the number
of take offs and landings.
Figure 5.64 shows the process overview how the OEMs would use the leading
indicators to get to the actual forecast figures of the corresponding service part.
Fig. 5.64 Overview of leading indicator based forecasting
The overall setting to activate the method of leading indicator-based forecast is

the assignment of the location product of the service part to a leading indicator
(installed base, number of uses, operating time). The forecast planning process
consists of two different planning services which have to be applied. The first
service, SPP_LFI_SERVICE, is a preparation process step and is responsible for
determining the demand history of the chosen leading indicator and the
corresponding coefficient. The coefficient is equivalent to the failure rate of a
certain service part and is described later.
Thereafter the statistical forecast is calculated with the standard planning service
(SPP_FCS_SERVICE) for the leading indicator as well as for the coefficient.
Alternatively the forecast for these variables can also be entered manually or by a
BAPI. At last the same forecast service calculates in the same run the forecast for
the service parts.
5.8.2 Basic Settings and Prerequisites
In order to activate the planning method “leading indicator based forecasting” for a
certain location product the relevant leading indicator in the leading indicator tab of
the forecast profile of the corresponding location product must be selected as shown
in Fig. 5.65.
Fig. 5.65 Leading indicator parameter in the forecast profile
For all forecast relevant locations of the same BOD below the entry location the
leading indicator must be the same. The available leading indicators in SPP standard
are INSTALLED_BASE, NUMBER_OF_USES and OPERATION_TIME.
After the leading indicator is defined the corresponding key figures appear in the
forecast matrix as can be seen in transaction /SAPAPO/SPPFCST and in Fig. 5.66.
132 5 Forecasting
Fig. 5.66 Additional leading indicator-specific key figures in forecast UI
Apart from the key figures that represent the historical and forecasted figures on
the leading indicators themselves, five other key figures become relevant:
– Demand: Leading-indicator-based forecast

– Demand: Std dev. LI-based forecast
– Demand: LI-based disaggregated forecast
– Demand: Standard deviation of leading indicator based disaggregated forecast
– Standard deviation of leading indicator
In any case—whether “installed base” or the other leading indicator types

(operating time or numbers of use) are used as leading indicator—it is needed to
have information of equipment data in SPP—including the Equipment-BOM’s—
and the number of installed bases. This information is loaded from ERP or any other
legacy system into the relevant BI-Objects in SPP from where they can be used for
leading indicator based forecasting. As seen in Fig. 5.67 this information is stored in
the APO-specific BI section—there in the data store object 9AEQBOM.The char-
acteristic 0EQUIPMENT being part of this DSO functions as the info provider for
the installed base, which represents all the currently installed final products at the
customer which require the service parts.
Fig. 5.67 Data store object (DSO) for equipment and BOM’s
5.8.3 Determination of the History of the Leading Indicator
Before the actual forecast for the leading indicator and its associated service part
can be done, the leading indicator history has to be determined. This is done with a
leading indicator based forecast preparation planning service which is called
SPP_LFI_SERVICE. This service is also responsible to determine the leading
indicator coefficient that represents the failure rate of the service part per installed
equipment. As a leading indicator the installed base can be used. The general idea
of using the installed base for forecasting is to determine the number of service parts
currently in use and their failure rate. The leading indicator is calculated using the
number of equipment (i.e. the finished product) in use and the coefficient of the
equipment BoM.
The failure rate history is calculated as the ratio of the real demand history to the
leading indicator history.
Figure 5.68 shows the planning steps, how the aggregated demand history of the
leading indicator and how the coefficient for every location product of the respec-
tive BOD individually is determined.
134 5 Forecasting
Fig. 5.68 Logic of leading indicator preparation planning service
After the relevant leading indicator is identified from the forecast profile of the
entry location, the actual calculation of the demand history of the leading indicator
is executed in two alternative ways depending on whether the leading indicator is
the installed base or the leading indicator is a key figure like the number of use or
the operating times. In both ways upfront the aggregated demand history of the
service part is determined.
Following that—if the leading indicator is the installed base—the service
SPP_LFI_SERVICE determines in which and in how many equipments the service
part is involved across all locations of a BOD. If the equipment has a BOM, in
which the service part is part of the BOM quantity coefficient of the service part is
taken into consideration. This figure is then multiplied with the actual demand of
the installed base and determined on the respective first stock-holding locations
each. The information on the numbers of equipment, its potential equipment-
BOM’s and the relation to the service part is stored and read from BI Data Store
Object (DSO) 9AEQBOM. Figure 5.67 shows the structure of this DSO.
The last step is to aggregate these demand figures up to the level of the entry
location and is stored in the time series ID “TSID_FINAL_HIST_LI.
If the leading indicator is not ‘installed base’ then the right branch of the
Fig. 5.68 shows how the demand history is determined.
The final demand history of the service parts is determined in the same manner
as in the case of the installed base.
In the following the determination of the equipment is made, which the respec-
tive service parts is attached to. Here only the fact, whether and where (on which
location) the equipment of the respective service part is existing. A BOM quantity
coefficient of the service part is not evaluated, because not needed. As a last step the
key figures of the either the leading indicator “no of uses” or “operation time” is
read out of the Info Cube 9AIBASKF and the demand history eventually is stored at
its corresponding first stock holding location. The structure of the Info Cube is
shown in Fig. 5.69.
Fig. 5.69 Info Cube 9AIBASKF
The relevant TDL time series ID in that respect is TSID_HIST_LI as defined in

the service profile delivered by SAP and shown in Fig. 5.70.
136 5 Forecasting
Fig. 5.70 Service profile of leading indicator preparation service
As the last step for all leading indicator types the failure rate (coefficient) is
determined by dividing the demand history of the service part by the history of the
leading indicator. This is done for the past periods for every location individually.
There is no aggregation of the coefficient values. E.g. a coefficient of 0.5 means that
in every second installed equipment a service part had to be provided.
This whole process is only valid for service parts that are not part of an active
supersession chain or part of a supersession chain of type 1:1.
5.8.4 Determination of the Forecast of the Leading Indicator

and the Relevant Service Parts
Finally the actual forecasting can take place with the standard planning service
SPP_FCS_SERVICE as used in the statistical forecast and described in Sect. 5.2.3.
This is selected by the parameter leading indicator values as shown in Fig. 5.71. If
the value “forecasted” is selected, the statistical forecast is done for the leading
indicator on the basis of the demand history that was determined by the preparation
service. In the same way a forecast for the coefficient can be determined.
Alternatively the forecast for both leading indicator and coefficient can be
maintained manually or with uploaded forecast figures via a BAPI. As a third
forecast alternative—only in case the leading indicator is a non-installed base one
(either operation time or number of uses)—the forecast service can derive the
demand history from the Info Cube “SPP: Installed Base Key Figures”
(9AIBASKF) and populates the value of the current period as the forecast value
for future periods.
For the coefficient it is possible to set a constant value as an alternative of
forecasting it. This is done in the forecast profile as shown in Fig. 5.71.
Fig. 5.71 Determination logic for future leading indicator values and coefficient values
At last the leading indicator based forecast of the service part itself takes place.
This is done by the multiplication of the forecasted figure of the leading indicator
with the forecasted coefficient figure of the same time bucket for every period.
In the course of leading indicator based forecasting an offset forecast creation—
as e.g. used for the determination of historical forecasts—with only a value of 1 is
allowed.
The leading indicator based forecast can be applied with the usual service
profile. The prerequisite which has to be set in in the service profile is parameter
“Consider leading indicator” as shown in Fig. 5.72.
If the forecast should be determined in an automatic and statistical way the
corresponding planning services have to be indicated accordingly.
Fig. 5.72 Activation parameter for LI-based forecasting in the various forecast service profiles
138 5 Forecasting
The planning services SPP_FCS_SERVICE, SPP-FCS_SERVICE_MSE,

SPP_FST_DISAGGREGATION, and SPP_FCS_RELEASE can be also used
optionally for leading indicator specific purposes. Then in any of these the parame-
ter “consider leading indicator” has be set as well, Fig. 5.72.
Economic Order Quantity and Safety Stock
6
Most of the service parts—especially in the automotive and the engineering industry—
have an immediate demand, i.e. the service part has to be available on stock. Since
the forecast is always just an estimation of the future demand, it is necessary to
compensate the deviations from the real demand (and the irregularities of the
supply) by safety stock.
Forecasting
Forecast Forecast Error
EOQ and Safety Stock Planning
Costs EOQ Calculation

Rules for
Deployment
Target Service Indicator
Level
Safety Stock Calculation
Lead Time
Deployment
EOQ Safety Stock
Indicator
DRP Deployment
Fig. 6.1 EOQ and safety stock planning process overview

140 6 Economic Order Quantity and Safety Stock
The amount of the safety stock depends primarily on the target service level—
i.e. how much risk is taken to be unable to deliver—and the height and the
reliability of the forecast as measured by the forecast error. The higher the target
service level and the higher the forecast and the forecast error are, the higher the
safety stock will be. Other factors that influence the safety stock quantity are the
lead time for replenishment and the order quantity. Increasing lead time requires
more safety stock as well as decreasing order quantity. Therefore the calculation of
the economic order quantity (EOQ) and the safety stock are performed in one
service. Figure 6.1 gives an overview of the EOQ and safety stock planning process.
EOQ and safety stock planning use only the forecast and the forecast error
measured by the standard deviation (and not the demand history). Based on the
forecast and the costs, first the EOQ is calculated and afterwards—taking the target
service level and the lead time into account—the safety stock. If normal distribution
is used to model the probability for customer orders (as opposed to Poisson
distribution) the determination of EOQ and safety stock is an iterative process.
Another result of the EOQ and safety stock planning is the determination of the
deployment indicator which decides whether the lead time for pull or for push
deployment is used for planning. This decision is based on predefined rules and
explained in Sect. 10.2.
EOQ and safety stock are used by DRP in order to determine the requirements
for procurement. Deployment considers the safety stock also for the calculation of
the replenishment quantities and EOQ for rounding. The deployment indicator is an
important parameter for both DRP and deployment.
6.2 Economic Order Quantity and Safety Stock
6.2.1 Economic Order Quantity
Each order costs money—not just the price for the goods but also transaction costs
related with placing the order and handling costs in the warehouse. From this point
of view it would be beneficial to place as little orders as possible, which would lead
to high ordering quantities and subsequently to high average storage levels. High
inventory levels are however undesired as well, mainly because of the capital
commitment. The economic order quantity determines the order quantity where
the total annual costs—i.e. the sum of the order quantity dependent annual
stockholding costs CANNSTH and order quantity independent order costs CANNORD
is minimal, Fig. 6.2.
6.2 Economic Order Quantity and Safety Stock 141
Cost
Total Cost
Stockholding Cost
Order Cost
EOQ Order Quantity
Fig. 6.2 Economic order quantity calculation
All the costs for the economic order calculation are maintained in the product
master. These costs are—like all the costs in SAP APO™—without any dimension
and not integrated with SAP ERP™. Therefore they represent rather weighting
factors than real costs.
Stockholding Costs
The annual stockholding costs CANNSTH are calculated as the capital commitment
per unit times the average stock on hand, formula (6.1). The average stock on hand
is the safety stock and half of the order quantity Q.
CANNSTH ¼ ðSafety Stock þ Q=2Þ FHC CP ð6:1Þ
Figure 6.3 shows the procurement cost CP which is maintained in the view ‘pro-
curement’ and represents the price of the service part.
Fig. 6.3 Procurement costs in the product master
The capital commitment per unit is represented by the procurement cost times
the holding cost factor FHC. The holding cost factor is maintained in the ‘SPP
DRP’-view of the product master. Figure 6.4 shows a holding cost factor of 0.5.
Fig. 6.4 Stock holding costs in the product master
Order Costs
The fixed order cost CORD represents the transaction costs and the handling costs in
the warehouse. Depending whether the product is procured via pull or via push
deployment, the cost might be different. If for example push deployment sends the
service part immediately to the next distribution centre, the effort for warehouse
management is lower than for a service part that is stored into the warehouse and
issued from the warehouse again. Figure 6.5 shows the maintenance of the fixed
order costs for pull and for push deployment in the ‘SPP inventory planning’-view
of the product master.
Fig. 6.5 Fix order costs in the product master
The annual order cost CANNORD however depends on the order quantity Q as
well because the lower the order quantity, the more often it is necessary to order and
the higher the annual order costs. For the calculation of the annual order cost
CANNORD the annual forecast QANNFC is used, formula (6.2).
CANNORD ¼ CORD QANNFC =Q ð6:2Þ
Determination of the Economic Order Quantity

The economic order quantity is calculated by applying the differential calculus to
the formulas (6.1) and (6.2). Formula (6.3) shows the result.
QEOQ2 ¼ 2 CORD QANNFC = ðFHC CP Þ ð6:3Þ
Accordingly, the EOQ increases with rising fix order costs and decreases with rising
procurement cost and the stock holding factor, Table 6.1.
Table 6.1 Dependency EOQ increases with rising. . . EOQ decreases with rising. . .
of the economic order
Fix order cost Procurement costs
quantity
Holding cost factor
The procurement costs for the EOQ calculation are applied for each location
from the location specific product master. At the entry location it is possible to
consider costs of scales as well.
6.2.2 Safety Stock
The purpose of the safety stock is to cover deviations of the demand and the supply.
The assumption for service parts planning is that the supply side is monitored very
carefully in order to keep the deviations to planning low and that the uncertainty on
the supply side is low compared to the uncertainty on the demand side. Since the
forecast is based on estimations, there is always a certain probability that the real
customer demand exceeds the forecast. This probability is the higher the bigger the
forecast error is. The basic idea of the safety stock is to cover for a certain
probability of increased customer demand. Covering 100 % would require infinite
safety stock but covering e.g. 95 % is possible and common with reasonable safety
stock. The percentage that defines which probability of increased customer demand
should be covered by safety stock is called target service level (TSL). Figure 6.6
visualises the forecasted demand and the probability of deviating customer
demands—in this case represented by the standard distribution. The width of this
graph is related to the forecast error. For a target service level of e.g. 90 % the
forecast has to be increased to a value where the area below that graph contains
90 % of the area of the total graph for the distribution.
Demand
Normal Distribution
90% of the Area

Forecast + Demand for 90% TSL
Forecast
Time
Fig. 6.6 Standard deviation, target service level and demand
Assuming a constant demand, the reorder point for the forecast is calculated as
the stock level that will just cover the demands for the lead time of the new
supply. In this case the new supply arrives just at the time of the stock-out. To
determine the safety stock for a target service level, the additional demand
(forecast + demand for 90 % TSL) is applied, which leads to an earlier projected
stock-out and therefore to an earlier respective higher reorder point. The safety
stock is the projected stock using the forecast (without additional demand) at the
point in time when the projected stock using the forecast and additional demand
becomes zero, Fig. 6.7.
Stock Forecast
Forecast + Demand for 90% TSL
Reorder Point
with Variance
Reorder Point
Safety Stock
Time
Lead Time
Fig. 6.7 Impact of the additional demand on the reorder point
The lead time consists of different master data parameters and is different for
push and for pull deployment. Section 8.3 describes how the lead times are
calculated.
6.2.3 Interdependency of EOQ, Safety Stock and TSL
The total target service level contains the horizon T before the reorder point
(i.e. outside the lead time) and the horizon TLT after the reorder point (i.e. within
the lead time). Therefore the total target service level is higher than the previously
calculated target service level within the lead time.
The bigger the EOQ, the longer the horizon outside the lead time and therefore
the higher the total target service level with the same safety stock—or the less
safety stock is required to meet the defined target service level. Figure 6.8 shows
how an increased EOQ—represented by a higher stock level at the start—leads to a
longer horizon outside the lead time and therefore to a higher total target service
level.
Stock
Lead Time
Lead Time
EOQ2 + Safety Stock
EOQ1 + Safety Stock
Reorder Point
Safety Stock
Safety Stock
Time
T1: Service Level 100% Lead Time: Service Level 90%
T2: Service Level 100% Lead Time: Service Level 90%
Fig. 6.8 Impact of the EOQ on the target service level and the safety stock
Table 6.2 lists the impact of the factors TSL, lead time, standard deviation
(forecast error) and EOQ on the safety stock.
Table 6.2 Dependency of the safety stock

Safety stock increases with rising. . . Safety stock decreases with rising. . .
Target service level Economic order quantity
Lead time
Standard deviation
Note that the absolute value of the forecast does not influence the safety stock
but the absolute value of the standard deviation. The lead time calculation is
explained in Sect. 8.3 about DRP.
Target Service Level Maintenance

For service parts planning the alpha target service level is used, i.e. the percentage
of orders that are fulfilled completely. The target service level is defined with the
transaction /SAPAPO/PINV_TL_MAIN. It is possible to define the target service
level on different levels—if no definition on product, location or product group
level exits, the fallback values are used (Fig. 6.9).
Fig. 6.9 Target service level definition
First the definition on location product level is checked. In this case an entry with
a blank product is ignored. In this table the entries are stored that were changed in
the interactive inventory planning. If no values are maintained here, the check is
continued at the product group level and from there to the global/local target safety
stock rules. These settings are on version and location level, and it is possible to
leave the location blank. The last check is for the global fallback values.
The target service level is the total target service level. The minimum TSL
represents the TSL within the lead time. It is also possible to limit the safety stock
values explicitly either by absolute values or by safety days’ supply—both as
minimum safety stock to ensure that a certain safety stock level is always kept as
well as maximum safety stock.
Normal Distribution vs. Poisson Distribution

The demand for service parts is usually caused by the failure of the original part.
The failure of a part is a rather seldom and discrete event, and the appropriate
distribution for seldom events is the Poisson distribution. Therefore the Poisson
distribution is often considered to be more appropriate for service parts (Muckstadt
2005). Whether the normal distribution or the Poisson distribution is used is defined
with the transaction /SAPAPO/PINV_MS_MAIN, Fig. 6.10.
Fig. 6.10 Model determination for the safety stock calculation
Using the normal distribution the safety stock is calculated as a buffer for
increased total order quantities, whereas with the Poisson distribution the safety
stock is calculated as a buffer for an increased number of order items (assuming that
each order item requests the average order quantity).
6.2.4 EOQ and Safety Stock Planning Service
The procedure for the calculation of EOQ and safety stock starts with the EOQ
calculation, and rounding is applied for the EOQ. The safety stock is calculated
based on the rounded EOQ. If normal distribution is applied the final determina-
tion of the EOQ and the safety stock is an iterative process with gradually
increasing or decreasing values—depending on the rounding profile (else incre-
ment of 1).
EOQ and safety stock planning is performed with the planning service
SPP_EOQSFT_SERVICE and is controlled by the planning service profile
(customising path APO ! Supply Chain Planning ! Service Parts Planning !
Inventory Planning ! Define Service Profile for EOQ/SFT calculation), Fig. 6.11.
The service profile contains the parameters for rounding—the rounding profile
and the indicator to round to the biggest pack size. The percentage for ‘reduce order
costs’ controls that rounding to the biggest pack size reduces the order costs by this
percentage.
Fig. 6.11 Service profile for EOQ and safety stock calculation
Another parameter is the maximum difference between the current and the
previous value for the safety stock (‘maximum safety stock difference’). If this
threshold is surpassed an interactive approval of the new values is required.
The option ‘use additional safety stock’ increases the calculated safety stock—
e.g. to buffer for the deviation of the average demand. The additional safety stock is
maintained in the target service level or in the ‘SPP inventory planning’-view of the
product master.
Adjust Safety Stock in the Network for Push Deployment

Safety stock is usually kept at all locations of the supply network. Even at the parent
locations safety stock is kept in order to buffer for deviations of the customer
demand at their child locations. This means that the safety stock at the parent
location is composed of safety stocks for each of its child locations. The advantage
of this is that the safety stock at the parent can be used more flexibly—e.g. the
safety stock for child location SPB1 could be used to supply child location SPG2 if
required. The disadvantage is that there is a lead time between parent and child.
Service parts planning offers two modes of replenishment, pull deployment and
push deployment (see Sect. 10.2). The assumption for push deployment is that the
parts are not stored into the warehouse at the parent location but sent immediately to
the child location. This procedure reduces the lead time compared to push deploy-
ment, where the parts have to be fetched from the warehouse first. Accordingly, a
different lead time is used for pull and for push deployment.
If the safety stock stored at the child location is not sufficient, some of the safety
stock at the parent location has to be transferred to the child location. This includes
all the warehouse related activities at the parent location and therefore requires the
lead times for pull deployment. If the child location is usually supplied via push
deployment there will be a difference between the lead times. To compensate this
increased lead time, it is possible to transfer a percentage of the parent’s safety
stock to the child location. This percentage is maintained in the target level settings
(parameter ‘push adjustment %’ in Fig. 6.9) and applies only to the portion of the
parent’s safety stock that was calculated for this child location. As an extreme, if all
child locations are replenished by push deployment and the percentage is set to
100, no safety stock remains at the parent location. The parameter ‘adjust for push
deployment’ in the service profile controls whether the safety stock is actually
adjusted for push deployment or not.
Constant and Non-Constant Safety Stock Models

If there are huge changes in the demand of a product—e.g. because of seasonality—
the safety stock must be adjusted in order to provide the same security for deviances
in the demand. Whether the safety stock planning calculates a constant or a
non-constant safety stock (and EOQ) depends on the forecast model. With the
customising path APO ! Supply Chain Planning ! Service Parts Planning ! Inven-
tory Planning ! Assign Inventory Planning Type to Forecast Strategy the dependency
of the safety stock model to the forecast model is defined, Fig. 6.12.
Fig. 6.12 Safety stock model
The parameter ‘seasonal’ is used by DRP for pre-season safety stock shift (see
Sect. 8.6.2).
Price Quantity Scales

When ordering huge quantities from a supplier it is common to get a lower price per
unit. These decreasing costs (price quantity scales) are not continuous but depend
on thresholds. For EOQ and safety stock planning the cost function in the
‘procurement’-view of the product master is used, Fig. 6.13.
Fig. 6.13 Cost function for price-quantity scales in the product master
Note that the price quantity scales which are maintained in the info record in
SAP ERP™ and transferred to SAP APO™ in the procurement relationship are
not used.
If price-quantity scales are used, the planning service calculates the EOQ and the
safety stock for each price quantity scale and selects the solution with the least
annual costs.
6.3 Planning Book for Inventory Planning 151
6.3 Planning Book for Inventory Planning
For interactive planning the planning book for inventory planning is used. It is
called with the transaction /SAPAPO/SPPINVP and offers a detailed view on the
input (e.g. standard deviation final forecast) and the output (e.g. EOQ and location’s
own safety stock). Figure 6.14 shows the planning book for inventory planning for
the product IS1_HALB_0001@QU6715 at the location DCSPB2@QU6715. In this
case a constant safety stock model was used without any rounding because the
economic order quantity of 28 pieces and the safety stock of 7.905 pieces do not
vary in future time buckets.
Fig. 6.14 Planning book for inventory planning
The parameters—costs, lead times and TSL—are displayed at the detailed

section of the screen, Fig. 6.15.
Fig. 6.15 Inventory planning details
The TSL can be changed there and will result in an entry in the TSL definition on
location product level as shown in Fig. 6.9. It is possible to simulate the inventory
planning and to save the results. Interactive inventory planning is however limited
to an interactive change of the parameters (e.g. the target service level) and does not
allow to change the EOQ and the safety stock directly.
The current period’s EOQ and safety stock are saved in the ‘SPP inventory
planning’-view of the product master, Fig. 6.16. If a constant safety stock model is
used, these values are applied by DRP and deployment (else the time series for
EOQ and safety stock are used).
Fig. 6.16 Economic order quantity and safety stock in the product master
EOQ and Safety Stock Approval

In case that the values for the EOQ and the safety stock differ largely from their
previous values it is necessary to approve the new values. This is possible in the
planning book. Figure 6.17 shows the message in the planning log and the approval
in the inventory planning book.
Fig. 6.17 Approval of safety stock in the inventory planning book
6.4 Additional Services 153
Alternatively the approval of the new safety stock can be executed in the
Planner’s Worklist as shown in Fig. 6.18. Also there the old and the new safety
stock are shown. In addition as decision support the maximum deviation in per-
centage (here no deviation at all is allowed, approvals are rather required after every
change) and the actual deviation in percentage is shown.
Fig. 6.18 Approval of safety stock in the planner’s worklist
The threshold for the approval is defined in the planning service profile (param-
eter ‘maximum SFT difference’, see Fig. 6.11).
6.4 Additional Services
6.4.1 Deployment Indicator Determination
The deployment indicator controls whether a location is replenished by pull

deployment (based on periodical deployment runs) or by push deployment (based
on goods receipt). Section 10.2 explains the difference in detail. However, during
the EOQ and safety stock calculation the deployment indicator is determined as
well based on rules that relate to the EOQ, the product group or the forecast. These
rules are defined with the transaction /SAPAPO/DEPL_IND_DEF and explained in
Sect. 10.2 as well.
6.4.2 ABC Classification
The ABC classification is performed by a separate service and sets the ABC
indicator in the ‘procurement’-view of the product master, Fig. 6.19.
Fig. 6.19 ABC indicator in the product master
The limits for the ABC classification are defined per location in the service
profile, Fig. 6.20.
Fig. 6.20 Service profile for ABC classification
The ABC classification service is SPP_INVP_ABCCLASS. The ABC classifi-

cation is however not used by service parts planning but by SAP EWM™.
Surplus and Obsolescence Planning
7
The goal of surplus and obsolescence planning is to identify inventory within the
supply network—i.e. the BOD—which exceeds the projected demand and therefore
only consumes warehouse space. In order to identify the surplus and remove it from
the concerned warehouses, first the total surplus within the supply network is
determined. This is done based on the total expected demand (including a safety
buffer) and the total available stock and the stock in transit. In a second step the total
surplus is disaggregated—in other words, the surplus quantities for the individual
locations are determined. If the value of the surplus is within the predefined limits,
orders for scrapping the surplus are created automatically. In the other case the
scrap orders need to be approved interactively. Figure 7.1 shows the overview of the
surplus and obsolescence planning process.
Inventory
Surplus Planning
Demand Retention Qty.
History Surplus Determination Determ. Table
Forecast Surplus Disaggregation

Flag as
Obsolete
Surplus
Value within
Limits? Obsolescence Check
Surplus Approval
Obsolete
Scrap Order
Fig. 7.1 Surplus planning and obsolescence check process overview

156 7 Surplus and Obsolescence Planning
The procedure for surplus determination differs depending on whether the

service part belongs to a primary product that is still produced or whether the
primary product is already out of production. If the primary product for the service
part is not produced any more and the retention date for this product is reached, this
product will become obsolete after the stock is used up. In this case the parameter
‘flag as obsolete’ is set per location product by the surplus planning service. The
obsolescence check service checks whether there is no more stock or stock in transit
and whether all location products are marked as ‘flag as obsolete’. In this case
another parameter—‘obsolete’—is set at product level and the service part can be
removed from the system.
Surplus Planning and Obsolescence Check Services

The planning service SPP_SOS_SURPLUS_DETERMINATION is used for surplus
planning and it requires the package creation method PRODUCT_SOR_SRPL_DET.
The planning service profile is defined with the customising path APO ! Supply Chain
Planning ! SPP ! Surplus and Obsolescence Planning ! define Service Profile for
Surplus and Obsolescence Planning and contains most of the planning parameters.
The obsolescence check requires a separate planning service with the technical
name SPP_SOS_OBSOLESCENCE_CHECK. This planning service is used with
the package creation method PRODUCT_SIMPLE. No service profile is required
for this service.
General Settings
The general settings for surplus and obsolescence planning are defined with the
transaction /SAPAPO/SORCUST as shown in Fig. 7.2.
Fig. 7.2 General settings for surplus and obsolescence planning
7.2 Surplus Quantity Determination 157
The general settings contain mainly fallback values for parameters like the
retention strategy group. Another parameter is the replenishment indicator value
in case of surplus and of obsolescence.
7.2 Surplus Quantity Determination
7.2.1 Overview and Common Steps
The first step for surplus planning is to determine the relevant products. Like the
other planning services, surplus planning uses selection profiles. Additionally it is
possible to add or remove individual products from the selection with the transac-
tion /SAPAPO/SORSELMOD, Fig. 7.3.
Fig. 7.3 Change selection
For the determination of the surplus quantity three different procedures exist,
depending whether the service part is still produced and whether it is a high volume
or a low volume part.
Current Model Part vs. Past Model Part

The service part is considered as a past model part if the primary product that
requires this service part is not produced any more. This is the case if the field
‘production end date’ in the product master is set and the year (and not just the date)
is elapsed. The production end date is first checked location specifically in the ‘SPP
inventory balancing/surplus’-view at the entry location. If this is empty, the pro-
duction end date in the ‘properties of SPP’-field is checked, Fig. 7.4.
Fig. 7.4 Production end date in the product master
If the service part is a past model part, the demand is calculated using phase-out
forecasting. The end of the service part’s planned availability is marked by the end
of the retention period—which is not a static value but determined in a
previous step.
For current part models either exponential smoothing is used—if it is a high
volume part—or the surplus is determined using values from the retention quantity
determination table. Exponential smoothing within surplus planning is performed
as an extrapolation of the last five periods’ demand (and does not use the algorithms
for forecasting). Figure 7.5 shows these three options for the determination of the
surplus quantity.
Past Model Yes

Part?
No
Retention Period
Determination
Yes High Volume No
Part?
Surplus Determination
Surplus Determination Surplus Determination
for Low Volume Parts with
for High Volume Parts with for Past Model Parts with
Retention Quantity
Exponential Smoothing Phase-Out Forecasting
Determination Table
Fig. 7.5 Process overview for surplus quantity determination
Each of these methods—exponential smoothing, retention quantity determina-

tion table and phase-out forecasting—calculates the medium- to long-term
requirements for the service part within the supply network. Only this amount—
the retention quantity—needs to be kept, and the surplus is calculated as the
difference between the stock and the stock in transit on one hand and the retention
quantity on the other.
Planning Mode
If a BOD has more than one entry location, either the whole supply network is
planned together or each network of an entry point individually. For example, if
different entry locations exist per region, this decision depends on the legal
requirements and the model policy. Technically this decision is modelled by the
parameter ‘planning mode’ in the service profile, Fig. 7.6.
Fig. 7.6 Planning mode (service profile)
The two alternatives for the planning mode are ‘plan for each BOD of an entry
location individually’ and ‘plan whole BOD together’.
7.2.2 Surplus Quantity Determination for Current Model Part
The surplus quantity is calculated as the total stock plus the stock in transit minus
the retention quantity, formula (7.1).
Surplus ¼ Stock þ Stock in Transit Retention Quantity ð7:1Þ
Different procedures are used for the determination of the retention quantity,
depending whether the service part is a high volume part or a low volume part—
and if it is a low volume part, whether it is a very low volume part or a not quite so
low volume part. Figure 7.7 shows the three checks how to determine which is
which. In total four horizons (Y into the future and X, W, Z into the past) are used
and three threshold values for the forecast and/or the demand history within these
horizons (A, B, C). Only the (released) final forecast is considered.
Forecast of next Y Yes

months B
No
High Volume Parts
Demand of last X Yes

months + Forecast current Retention Qty. = Estimated Demand (for V Years) * (1 + Safety Factor)
month A
No
Low Volume Parts
Demand of last W Yes

Retention Qty. = max {Min. Retention Qty., Last Z Months’ Demand}
months C
No
Retention Qty. = max {Min. Retention Qty, % of Last W Months’ Demand}
Fig. 7.7 Surplus quantity determination for current parts
If the service part is a high volume part, exponential smoothing is performed in

order to determine the forecast for the retention period (parameter V). The retention
period is maintained in years in the ‘properties of SPP’-view of the product master,
Fig. 7.8.
Fig. 7.8 Retention period for current model parts in the product master
The other parameters are maintained in the service profile as shown in Fig. 7.9.
A
X
B
Y
C
W
Z
© SAP AG
Fig. 7.9 Parameters for surplus quantity determination with exponential smoothing
Retention Quantity Determination Table

The safety factor for the high volume parts, the minimum retention quantity and the
percentage of the demand history for the low volume parts are maintained in the
retention quantity determination table (RQDT). The RQDT is maintained with the
transaction /SAPAPO/SORRETQTYDET, Fig. 7.10.
© SAP AG
Min. Keep Qty.
% of Demand
Safety Factor
© SAP AG
Fig. 7.10 Retention quantity determination table
The RQDT is a global setting and is selected according to the procurement costs
of the service part and the planning version.
7.2.3 Surplus Quantity Determination for Past Model Part
The prerequisites for the surplus quantity determination with phase-out forecasting
are that
• the year of the production end date for the service part has passed and that
• phase-out forecasting was performed.
The surplus quantity is determined as the available stock plus the stock in transit
minus the corrected gross demand (CGD), formula (7.2).
Surplus ¼ Stock þ Stock in Transit CGD ð7:2Þ
The corrected gross demand (CGD) is calculated as the maximum of the ‘gross
demand’ and the scaled demand of the past year as described in formula (7.3).
CGD ¼ max fGross Demand ; F1 Demand of Last Yearg ð7:3Þ
Only the forecast relevant demand of the last year is used (e.g. no future dated
orders). The factor F1 is maintained in the service profile as ‘factor for forecast-
relevant demand history of previous year’, Fig. 7.11.
Fig. 7.11 Parameters for surplus quantity determination with phase-out forecasting
The gross demand is calculated as the sum of the forecast and the scaled standard
deviation from the current period until the end of the retention period. The standard
deviation is scaled with the parameter ‘% of safety stock of phase-out forecast’ (F2).
Formula (7.4) describes the calculation of the gross demand.
X
Gross Demand ¼ i
ðForecast ½i þ F2 σ ½iÞ8i ∈ ð0, RPÞ ð7:4Þ
If the parameter ‘last purchase order’ is set in the ‘properties of SPP’-view of the
product master, additionally the factor ‘percentage for correction of standard
deviation’ is applied.
Retention Period
The retention period describes the horizon for the availability of a service part after
the production end date of its primary product. Even after the primary product is not
produced any more, there are legal requirements to keep the service part available
for a mandatory retention period. Often the service part is kept available for
additional periods.
The retention period contains several parts—the mandatory retention horizon
and one or more additional retention horizons. The relevant retention period
depends on the forecasted demand. If the forecasted demand falls below a
predefined threshold (the minimum demand of the retention strategy group), it is
not economic any more to keep the service part available. For each additional
retention horizon a different minimum demand can be defined. Figure 7.12
visualises the calculation of the retention period.
Mandatory Retention Horizon Additional Additional Additional

Retention Retention Retention
Demand
Horizon 1 Horizon 2 Horizon 3
Minimum
Demand
of RSG
Long Term
Forecast
2005 2006 2007 2008 2009 2010 2011 2012 2013 2013
Production
End Date Retention Period
Retention Date
Fig. 7.12 Determination of the retention period
In this example the retention period ends at the end of year 2011 because in year
2012 the forecasted demand is below the minimum demand.
The parameters for the calculation of the retention period—the mandatory
retention horizon, the additional maximum retention horizons and the minimum
demands—are maintained in the retention strategy group (RSG). The retention
strategy group is maintained with the transaction /SAPAPO/SORRETGRP,
Fig. 7.13.
Fig. 7.13 Retention strategy group
The additional maximum retention horizon starts at the end of the mandatory
retention horizon. The horizons within the additional maximum retention horizon
are maintained as cumulative values, i.e. the additional maximum retention horizon
defined in Fig. 7.13 is 5 years.
The retention strategy group is assigned to the product master in the location
specific ‘SPP inventory balancing/surplus’-view or in the general ‘properties of
SPP’-view of the product master, Fig. 7.14.
Fig. 7.14 Assignment of the retention strategy group to the product master
If there is no retention strategy group assigned to the product master, the

retention strategy group is selected by location and product group as defined in
the retention strategy group selection table with the transaction /SAPAPO/
SORRETGRPSEL, Fig. 7.15.
Fig. 7.15 Selection of the retention strategy group
As a last fallback the retention strategy group that is assigned to the general
settings is used.
Flag as Obsolete
If surplus is determined with phase-out forecasting, the mandatory retention hori-
zon has elapsed and the forecast is below the minimum demand as defined in the
retention strategy group—in other words: if the retention period has elapsed—the
parameter for ‘flag as obsolete’ is set (see Fig. 7.22). Another action is changing the
replenishment indicator as defined in the general settings. In the example that is
shown in Fig. 7.2 the replenishment indicator would be set to ‘non-stocked, locked’
(NL).
The parameter ‘flag as obsolete’ does not mean that service part is obsolete yet
but is used as an input for the obsolescence check service.
7.3 Surplus Disaggregation
The surplus is determined for the whole BOD (or for the sub-BOD below the entry
point). In order to remove the surplus, it is necessary to determine the surplus per
location. This is called surplus disaggregation.
The surplus disaggregation starts with the determination of the keep quantity per
location, and determines based on this the surplus quantity per location. It always
starts with the locations which are not stocked. For these the retention quantity is
zero. The stocked locations are sorted according to one of the following criteria:
7.3 Surplus Disaggregation 165
• demand history (ascending)

• forecast (ascending)
• potential surplus quantity (descending)
• potential days’ supply for surplus (descending)
A sorting of the locations by ascending demand history implies that the location
with the lowest demand history is the first to remove its surplus.
The sorting is defined in the service profile as shown in Fig. 7.16. For the sorting
according to the demand history or the forecast the considered horizon is specified
in the service profile as well—in this example 12 months each.
Fig. 7.16 Sorting of the locations for disaggregation (service profile)
The minimum retention quantity (MRQ) of the stocked location is calculated as

described in formula (7.5).
MRQ ¼ maxfðSFT þ EOQ þ DLT Þ ð1 þ FSFT Þ; DMRQ g ð7:5Þ
SFT is the safety stock, DLT the demand over the lead time and DMRQ the demand
over the horizon of the minimum retention quantity. The horizon for the minimum
retention quantity and the safety factor FSFT are defined in the ‘calculation of
surplus quantity per location’-fields of the service profile as shown in Fig. 7.16.
The surplus quantity per location is calculated location per location in their order
(first the non-stocked, then the stocked according to their sorting) until the total
surplus is reached. Other criteria to stop the further calculation of surplus quantities
per location are if the remaining surplus is below the average bin size or if the value
of the remaining surplus is below the minimum surplus value. The minimum
surplus value is defined in the location master as shown in Fig. 7.17. By remaining
surplus we understand the difference between the total surplus quantity and the sum
of the—already calculated—surplus quantities per location.
7.4 Surplus Approval
If the value of the surplus order at a location is above the threshold for the surplus
approval, an interactive surplus approval is required. The threshold for the surplus
approval is maintained in the location master with the transaction /SAPAPO/LOC3
as shown in Fig. 7.17.
Fig. 7.17 Threshold values for surplus approval in the location master
The interactive surplus approval is performed with the transaction /SAPAPO/

SPPSOR. Figure 7.18 shows the screen for the approval of two surplus orders for
the product NF1_HALB_0003@QU6715.
Fig. 7.18 Surplus approval
7.4 Surplus Approval 167
For each suggested surplus order it is possible to change the quantity, the scrap
indicator, the surplus decision code and the reason code. The order details show
additional information, Fig. 7.19.
Fig. 7.19 Surplus approval—details
The approval is performed by setting the flag for ‘approve’ as shown in Fig. 7.18.
Alternatively the approval can be made in Planner Planner’s Worklist (described
in more detail in Chap. 14).
Figure 7.20 shows the access to the query “Surplus Approval”. By indicating the
respective line of a product in focus the button “Surplus and Obsolescence
Approval” is ready to use.
Fig. 7.20 Surplus approval in the planner’s worklist
Surplus Decision Code, Scrapping Indicator and Reason Code

The decision code is defined with the customising path APO ! Supply Chain
Planning ! SPP ! Surplus and Obsolescence Planning ! Define Decision Codes
and defines what to do with the surplus order—whether to remove the quantity from
the available stock or not and whether to send the surplus order to SAP ERP™ or
not, Fig. 7.21.
Fig. 7.21 Surplus decision code
If the decision code is to scrap the surplus quantity, the order is transferred to
SAP ERP™ as a scrap order.
The scrapping indicator defines the actions for scrapping—possible alternatives
are to scrap entire stock, scrap the stock but retain remaining quantity or to scrap the
stipulated quantity. If the scrapping indicator is blank, no action is taken for scrapping.
Reason codes are used for reporting and defined with the customising path
APO ! Supply Chain Planning ! SPP ! Surplus and Obsolescence Planning !
Define Decision Reason Codes. Reason codes could be e.g. broken (BROK),
discontinued (DISC), engineering change (ENGI), surplus (SRPL) and dealer
termination (TERM).
The proposal value for the surplus decision code, the reason code and the
scrapping indicator are maintained in the service profile as shown in Fig. 7.22.
As a result of the approval step a demand element of the ATP category
SPPLIESCRT is created.
Fig. 7.22 Proposal for decision code, reason code and scrapping indicator
Processing of Surplus Orders

Unless the decision code for the surplus order is SCRAP, the approved surplus order
requires a subsequent processing step—e.g. to post a goods issue for the product.
The logic for this subsequent processing is defined in the BAdI /SAPAPO/
SOR_MANORD. The processing is triggered with the transaction /SAPAPO/
SPPMSP as shown in Fig. 7.23.
7.5 Obsolescence Check 169
Fig. 7.23 Processing of approved surplus orders
7.5 Obsolescence Check
The obsolescence check performs a check for all location products whether the
parameter ‘flag as obsolete’ is set and whether no stock and no stock in transit exists
any more. If both conditions are met, the parameter ‘obsolete’ is set for the product.
Figure 7.24 shows this procedure.
Fig. 7.24 Obsolescence check
Distribution Requirements Planning
8
One characteristic of the service parts planning solution is the tree structure which
is defined in the BOD. The implication of this structure is that the demand for the
whole network is sourced via external procurement at the entry location (or at the
entry locations, if the BOD has multiple entry locations). The purpose of DRP is to
determine the procurement quantity.
This is done by two alternative basic methods—either by reorder-point based
planning or by period-based planning. In the latter case the procurement quantity is
determined by taking into account the demands (forecast, safety stock, confirmed
stock transfer demands and fixed demands), the inventory, the confirmed receipts,
the lead times, the days of supply (i.e. the economic order quantity) and the pack
stages of the whole supply network. Figure 8.1 shows the process overview of DRP.
Fig. 8.1 DRP process overview

172 8 Distribution Requirements Planning
In the case of reorder-point based planning the procurement quantity is deter-

mined basically by the difference between the effective reorder point and the
available quantity of certain location product adjusted by potential rounding like
the pack stages as explained in detail in Sect. 10.11.
For most of the SPP-customers the reorder-point based planning method is the
first choice of applied planning mode when starting with an implemented solution.
The reason for that is either because the customer does not have sufficient experi-
ence with period-based planning in SPP yet or because there are too little historical
demand data yet for the respective products. In this case the forecast might be less
reliable as a reorder point. After a while the DRP planning mode can be changed per
location product—starting with the most critical ones.
The result of the DRP process are procurement proposals—either schedule lines
for scheduling agreements or purchase requisitions for contracts. Before the pro-
curement proposal is released and sent to the supplier it needs to be approved as
described in Chap. 9.
DRP Planning Elements

DRP is based on daily time buckets and orders (in contrast to forecasting and EOQ and
safety stock planning). The forecast orders are created from the forecast time series
during the forecast approval. The orders for the planned stock transfers are either just
temporary or stored in live cache as orders—depending on the parameter ‘save stock
transport requisitions’ in the DRP planning profile (see Fig. 8.73). For the planned stock
transfer between two locations and for the planned stock transfer between a parent
location and its virtual child location different ATP categories are used, Table 8.1.
Table 8.1 DRP Planning elements—ATP categories

DRP Element ATP Category Category text Category type
SPP Forecast KA SPP FCST Forecast
SPP Stock transfer (receipt) KB SPPSTR IN Receipt
SPP Stock transfer (demand) KC SPPSTR OUT Reqmt.
SPP Stock transfer VCL (receipt) KD SPPSTR-VR Receipt
SPP Stock transfer VCL (Demand) KF SPPSTR-VD Reqmt.
Neither the forecast nor the planned stock transfers are pegging relevant. The
order types for procurement, for stock transfer orders and for sales orders are the
same as in ‘normal’ SAP APO™.
8.2 DRP Logic 173
8.2 DRP Logic
8.2.1 DRP Matrix
The purpose of DRP is to calculate the net requirements for the whole supply
network (i.e. the BOD) and create procurement proposals. This is called ‘roll-up the
requirements’ to the entry location.
The independent demand is mainly the forecast at the child locations—other
demand elements are the future dated orders and the confirmed or fixed
requirements. The difference between the independent (total) demand and the
safety stock on one hand and the available stock and the fixed or confirmed receipts
on the other hand is the net requirement of the child location. DRP covers this net
demand by a planned stock transfer from the parent location. However, this planned
stock transfer creates a demand at the parent location—shifted by the lead time.
After performing a net requirements calculation for the parent location (planned
stock transfer requirements, fixed requirements and stock transfer orders minus
available stock and fixed receipts) the net requirement of the parent location is
covered by a planned stock transfer from the next level (the parent location’s parent
location) and so on until the entry location is reached. The net requirement of the
entry location is covered by a procurement proposal—either a schedule line or a
purchase requisition. Figure 8.2 shows the demand and the material flow and the
roll-up of the requirements for a two-level BOD.
Supplier
Material Flow
Entry / Parent Net Requirements
Location Demand Flow Calculation
Lead Time
Calculation
Child Location 1 Child Location 2 Net Requirements

Calculation
Roll-Up of the Requirements
Fig. 8.2 Roll-Up of the requirements in DRP
All planning data within the BOD including the inventory, the forecast and the
external procurement is stored and displayed in the DRP matrix.
Net Requirements Calculation

The net requirements calculation is performed for all stocked locations, and within
each location for all time buckets of the planning horizon. Based on the projected
stock of the previous period, the fixed gross receipts (e.g. stock in transit) of the
current period are added and the gross demands (e.g. forecast and stock transfer
requirements) are subtracted. If the calculated remaining quantity is below the

minimum safety stock level, the difference is the theoretical net demand. This net
demand is scheduled outside the freeze horizon to become the unrounded net
demand. This unrounded net demand is rounded according to the EOQ or the
EOQ POD (periods of demand) and the pack stages, and additionally stability
rules and supplier shut down is applied. The result is the constrained rounded net
demand—which represent the planned receipt from the supplier or the parent
location. The projected stock is the calculated remaining quantity (after subtracting
the total demand) plus the rounded net requirement. Figure 8.3 visualizes this
procedure. Only for the first day the real stock is used instead of the projected stock.
Receipt (Confirmed)
Total Gross
Total Gross Demand
Demand (Constrained)
Minimum
Rounded Net
Safety
Projected Stock
Stock Level
Projected Stock
Net Demand
Unrounded
Sub-
Add Schedule
tract Round
Receipts Delta
Demand
Day k-1 Day k Day k+1
Fig. 8.3 Steps for the net requirements calculation
The projected stock is either a positive value or zero. If the total gross demand is
not covered by the projected stock of the previous period plus the confirmed gross
receipts of the current period, a supply shortage occurs. This could be the case if the
gross demand increases within the freeze horizon or if the stability rules prevent
covering the demand. In this case the supply shortage of the previous period is used
instead of the projected stock as shown in Fig. 8.4.
Day k-1 Day k Day k+1
Minimum
Safety
Projected Stock
Stock Level
Demand (Constrained)
Sub-
Rounded Net
Add Schedule
tract Round
Receipts Delta
Receipt (Confirmed)
Demand
Total Gross Demand
Net Demand
Unrounded
Total Gross
Shortage
Supply
Fig. 8.4 Steps for the net requirements calculation—starting with a supply shortage
8.2 DRP Logic 175
Each of the quantities in Figs. 8.3 and 8.4 is displayed in the DRP matrix as a
separate key figure.
Key Figures
The DRP matrix is displayed with the transaction /SAPAPO/SPPDRPM and
provides an overview about the planning situation for a product in one location.
The virtual child is considered as a different location to the parent location. The
DRP matrix contains key figures with the demand, supply and inventory informa-
tion as shown in Fig. 8.5.
Fig. 8.5 DRP matrix
The ‘rounded net demand (constrained)’ (RND) represents the supply—either as

a schedule line from the supplier or as a planned distribution receipt. The ‘rounded
net demand (constrained)’ is calculated by applying the rounding profile, the
stability rules and the supplier shut down to the ‘unrounded net demand (adapted)’
(UND). The ‘unrounded net demand (adapted)’ already considers the lead time and
is calculated for the period k as the ‘planned minimum safety stock level’ (MSSL)
plus the ‘total gross demand’ (TGD) and the ‘supply shortage’ (SH) of the previous
period (e.g. due to lead time) minus the ‘projected stock’ (PS) of the previous period
and the ‘total gross receipts (confirmed)’ (TGR) as described in formula (8.1).
UND ðkÞ ¼ MSSL ðkÞ þ TGD ðkÞ þ SH ðk 1Þ PS ðk 1Þ TGR ðkÞ

ð8:1Þ
8k Lead Time
Either the projected stock or the supply shortage is zero. The ‘unrounded net
demand (adapted)’ and therefore also the ‘rounded net demand (constrained)’ is
placed at the last day of the lead time. Before that the ‘unrounded net demand
(adapted)’ is zero. The reason for this is that the net demand has the meaning of a
supply in the DRP matrix, and it is not possible to get a new supply within the
lead time.
The total gross demand includes the forecast, fixed demands, substitution
demand, distribution demand, confirmed distribution demand, customer demand
etc., Fig. 8.6.
Fig. 8.6 DRP matrix—total gross demand
The fixed demands might override or add to the forecast—this depends on the
category of the fixed demand (see Sect. 8.2.4 about fixed requirements). The
distribution demand contains both the planned distribution demand (as the result
of the DRP run) and the confirmed distribution demand (as the result of deployment
or inventory balancing). Customer demand is considered as open customer demand
if it is in the past or if it is a future dated order (FDO, see Sect. 8.2.2 about forecast
vs. customer requirements). In this example the overdue customer order is
registered as a confirmed transfer since the customer is a OEMMI-customer,
which can be seen with the ATP-category EF in the DRP matrix details in the
lower section of Fig. 8.6.
The total gross receipts contain mainly the fixed receipts (these are negative
fixed requirements), the confirmed distribution receipts (‘distribution receipt from
BOD’), the planned procurement from the supplier within the freeze horizon
(‘distribution receipt from supplier (frozen)’), interactively fixed receipts and the
stock in transit—both from the supplier and from a supplying location within the
network, Fig. 8.7.
8.2 DRP Logic 177
Fig. 8.7 DRP matrix—total gross receipt
DRP Matrix Usability

Within the DRP matrix it is possible to simulate the DRP run, but the result cannot
be saved. It is not possible to perform an interactive planning in the DRP matrix—to
add requirements or receipts the functionality for fixed requirements has to be used.
In Fig. 8.8 it is shown that the actual stock, the EOQ and the EOQ periods of
demand which are used for the rounding to days of supply (see Sect. 8.2.3) are
always displayed.
Fig. 8.8 DRP matrix usability
Using a different value for the variable time bucket profile it is possible to gain
an aggregated view of the plan, Fig. 8.9.
Fig. 8.9 Time bucket profiles for the DRP matrix
When comparing the monthly values for the forecast in the DRP matrix with the
forecasting planning book, it is likely to notice differences. These are due to the
scaling of the forecast—forecasting assumes a constant number of working days per
month (or per fiscal year period). This scaling factor is defined with the customizing
path APO ! Supply Chain Planning ! SPP ! Forecasting ! Make General
Settings Demand History (see also Sect. 3.2). The default scaling factor for months
and fiscal year periods is 21 as shown in Fig. 8.10 (see also Sect. 3.2.2).
8.2 DRP Logic 179
Fig. 8.10 Scaling factor for number of workdays in forecasting
The forecast from forecasting is divided by this scaling factor and transferred as
daily forecast to the DRP matrix—but now for each working day according to the
calendar for scaling. Formula (8.2) describes the difference in the monthly forecast
between forecasting and the DRP matrix.

ForecastDRP ¼ ForecastForecasting NWorkdays =Scaling Factor ð8:2Þ
The forecast from forecasting is therefore adjusted by the ratio of actual number of
working days NWorkdays and the scaling factor.
Overdue and Start of the Planning Horizon

In the column ‘overdue’ the past customer requirements, fixed requirements that are
not yet expired, past distribution demand and confirmed receipts are displayed.
Since there is no forecast consumption in service parts planning, past forecast does
not contribute to the overdue requirements. Whether the current date is displayed as
‘overdue’ or as the first future (i.e. planned) column depends on the start of the
planning horizon, Fig. 8.11.
Fig. 8.11 Overdue and start of the planning horizon
In the example shown in Fig. 8.11 the current day is 14th of November. For this
day a demand of 1,014.588 is due and a demand of 1,103 is already overdue. If the
start of the planning horizon is set to ‘tomorrow’, the current day is considered
already as past and the demands for the current day are considered as overdue.
Therefore the overdue demand increases to 2,103 (the missing 14.588 are the
forecast for the current day, and the ‘past’ forecast does not contribute to the
overdue demand).
The start of the planning horizon is defined in the DRP service profile
(customizing path APO ! Supply Chain Planning ! SPP ! DRP ! Define Ser-
vice Profile for DRP), Fig. 8.12.
Fig. 8.12 Parameter for the start of the planning horizon in the DRP service profile
The DRP service profile which is relevant for the DRP matrix is defined with the
customizing path SCM Basis ! Planning Service Manager ! Assign Standard
Service Profiles for UI, Fig. 8.13.
Fig. 8.13 Service profile for the DRP matrix
It is possible to define the service profile in the DRP matrix user specifically.
8.2 DRP Logic 181
8.2.2 Forecast Versus Customer Requirements
In service parts planning the customers do usually not order in advance but expect
the service part to be available. Therefore the SPP solution is mainly a make-to-
stock—or more accurately: procure-to-stock—business, and the driver for the
execution is the forecast and not the sales order. As a first approximation sales
orders are irrelevant for service parts planning.
There are however some exceptions where customers e.g. place orders quite
some time in advance. The approach of the service parts planning solution is to
consider these separately: These ‘future dated orders’ (FDO) are not considered in
the demand history and are therefore not covered by forecasting. Instead these
orders add to the total gross demand and are considered by DRP accordingly.
There are different circumstances, which can be modelled by customizing,
whether a sales order is considered as FDO. On the one hand it can be made
dependent on the difference between the required delivery date and the order creation
date. In Fig. 8.14 an example is shown, where the requested delivery needs to exceed
at least a threshold of 90 days after the creation date of the order before the order
becomes relevant for procurement planning and irrelevant for capture demand.
On the other hand an order can become a FDO dependent on the settings regarding
the relevant customer order types and item categories. Order types are represented in
SPP as so called “activity types”. Item categories are represented as “activity types”
Fig. 8.14 shows an example where item lines with an item category TAM in a
Fig. 8.14 Consideration of customer requirements
customer order of order type TA become a FDO. Additionally any item lines with an
item category of TANN in orders of any type are considered as FDO as well.
These settings are defined with the customizing path APO ! Supply Chain
Planning ! SPP ! Basic Settings ! Make Settings for Customer Demand,
Fig. 8.14 (see also Sect. 3.2.2).
The flag for FDO is set to the sales order by the ATP check during the transfer to
SAP APO™.
If sales orders lines or delivery order lines, whose requested delivery date moved
into the past (into the overdue column in the DRP matrix), should become relevant
for DRP, the flag in the dotted-lined box—as shown in Fig. 8.14—should be set.
These orders are considered as overdue. The activation of this flag is recommended
in most project-cases, because the corresponding forecast demand disappears as
soon as it moves into the past and therefore nor replenishment planning whatsoever
would take place.
What should be the content of the key figure “open customer demand” in the
DRP-Matrix as soon as it is overdue is defined in the TDL Semantic
“OPEN_CUST_DMD” as shown in Fig. 8.15.
Fig. 8.15 Content of order semantic “OPEN_CUST_DMD”
8.2 DRP Logic 183
In transaction /sapapo/TDL_APO_SEM it is assigned to the SNP category group

“SOD”, which contains the ATP categories BM (Sales order) and BR (Delivery). If
e.g. “delivery without charge” also should be considered as planning relevant as
soon it becomes overdue, then the ATP-category BQ should be also included in the
category group “SOD” on a project basis.
8.2.3 Rounding to Days of Supply
The order quantity is rounded to days of supply using the economic order quantity
(EOQ) or the EOQ periods of demand (POD). Though the EOQ is an absolute value
and is used in DRP to determine the order quantity, it is derived from a days of
supply calculation in inventory planning. Both EOQ and EOQ periods of demand
are calculated by the EOQ and safety stock service and stored in the ‘inventory
planning’-view of the product master, Fig. 8.16. If a non-constant safety stock
model is used, only the values for the first period are stored in the product master. In
this case the planning book for inventory planning (transaction /SAPAPO/
SPPINVP) has to be used in order to get an overview of the time dependent values
(see Sect. 6.3).
Fig. 8.16 EOQ and EOQ periods of demand (POD) in the product master
The lot size information in the ‘lot size’-view of the product master is ignored.
Whether the EOQ quantity or the EOQ POD is used depends on different settings
for the entry location and the child locations.
EOQ Versus EOQ POD for Entry Locations

Whether the EOQ quantity or the EOQ POD is used for the child locations depends
on the setting in the ‘SPP inventory planning’-view of the product master at the
entry location, Fig. 8.17.
Fig. 8.17 Use of EOQ or EOQ POD for the entry location
The value ‘01’ (EOQ manually locked) causes that the EOQ is used at the entry
location, while the values ‘02’ (EOQ period manually locked) and ‘03’ (not locked)
cause the use of the EOQ POD.
EOQ Versus EOQ POD for Child Locations

Whether the EOQ quantity or the EOQ POD is used for the child locations depends
on the general DRP setting in customizing (path APO ! Supply Chain
Planning ! SPP ! DRP ! Make General Settings for DRP), Fig. 8.18.
Fig. 8.18 Use of EOQ or EOQ POD for child locations
Figure 8.19 shows an example for the planning result when using the EOQ POD
for rounding to days’ supply. The first net demand occurs on the 24.07.2014. Since
the EOQ POD at that date is 7, the net demand of the next 7 days is ordered. The
EOQ quantity and the EOQ POD are displayed in the DRP matrix with the button
‘EOQ/POD’.
8.2 DRP Logic 185
Fig. 8.19 Result of the DRP run with rounding to the EOQ periods of demand
8.2.4 Fixed Requirements
It is not possible to perform an interactive planning in DRP in the sense of changing

the orders proposed by DRP in the DRP matrix. Planned distribution orders cannot
be changed at all, but it is possible to create additional fixed requirements with the
transaction /SAPAPO/SPPFIXREQ, Fig. 8.20.
Fig. 8.20 Fixed requirement
The fixed requirement contains information e.g. about the quantity and the dates
(from and to), the reason code and the demand type as shown in the details of the
fixed requirement, Fig. 8.21. Two dates are maintained: the ‘date from’ is the due
date and the ‘date to’ controls how long the fixed requirement will remain in the
‘overdue’-column.
There are three fixed demand types: No priority, priority and override. The
difference between a ‘priority’ and a ‘no priority’ fixed requirement is its prioriti-
zation during tier processing in deployment, see Sect. 10.4. Both types add to the
existing demands. A fixed requirement of the type ‘override’ however will replace
the forecast demand.
Fig. 8.21 Details of the fixed requirements
The reason code is a mandatory field for the creation of a fixed requirement.
It is defined with the customizing path APO ! Supply Chain
Planning ! SPP ! DRP ! Define Reason Codes for Fixed Demand, Fig. 8.22.
Fig. 8.22 Reason code for fixed requirements
The fixed requirements can be changed in date and quantity. To track these
changes an audit trail exists for each fixed requirement, Fig. 8.23.
Fig. 8.23 Audit trail for fixed requirements
8.3 Scheduling
The tasks for the scheduling in DRP are the determination of the lead times between
the supply chain partners (e.g. between supplier and location or between two
locations) and the consideration of calendars. Capacity constraints are not
considered.
8.3 Scheduling 187
Scheduling Settings in the DRP General Settings

In the general settings for DRP (customizing path APO ! Supply Chain
Planning ! SPP ! DRP ! Make General Settings for DRP) it is defined which
calendar is used for the scheduling of the planned stock transfers and schedule lines,
and whether a total procurement lead time or a more detailed component procure-
ment lead time is used for the scheduling of stock transfers, Fig. 8.24.
Fig. 8.24 General DRP settings for scheduling
With the definition of calendars it is defined whether the planning calendar for
SPP is used or separate calendars, i.e. the shipping calendar of the source locations,
the transportation calendar of the transportation lane and the receiving calendar of
the target location. The definition of the different calendars for the location is
described in Sect. 2.1.4.
There are two ways how to calculate the lead times in DRP. One is to use the
total procurement lead time in the transportation lane, the other is to calculate the
lead time based on different entries of the transportation lane, the product master
and the procurement relationship (component lead time). The setting ‘procurement
lead times in DRP’ defines which is used. This definition is per client.
Total Procurement Lead Time

The total procurement lead time is maintained in the transportation lane (transac-
tion /SAPAPO/SCC_TL1) on the ‘means of transport’- level, Fig. 8.25.
Fig. 8.25 Total procurement lead time in the transportation lane
Component Procurement Lead Time

The component procurement lead time is calculated using different entries from the
transportation lane, the product master and the procurement relationship. The lead
time depends on the application and whether pull or push deployment is used.
Figure 8.26 gives an overview for the lead time elements from a supplier to the
entry location and between a parent and a child location for the pull and the push
deployment case.
Pull Deployment
Transport Duration GR Time DRP Review GI Time Transport Duration GR Time

(Transp. Lane) (Product) (Product) (Product) (Transp. Lane) (Product)
Push Deployment
DRP Review Throughput GR Time Transport Duration GR Time

+ - +
(Product) (Product) (Product) (Transp. Lane) (Product)
Fig. 8.26 Lead time components for pull deployment and for push deployment
8.3 Scheduling 189
In this figure we presume that the default scheduling settings are used. Though it
is possible to configure the lead times in customizing, it is strongly recommended
not to make any changes. For each lead time between two partners of the supply
chain (e.g. location to location, supplier to location, . . .) a scheduling scenario
exists (to be precise, one scenario for pull deployment and one for push deploy-
ment). To this scheduling scenario a procurement lead time group ID is assigned.
This procurement lead time group ID is freely defined and contains one or more
elements (‘sequence’) which define the lead time. Figure 8.27 shows the structure
of the lead time customizing.
Scheduling Scenario
Proc. Lead Time Group ID
Sequence 1 Activity Type Proc. Lead Time Component
Sequence 2 Activity Type Proc. Lead Time Component
Sequence N Activity Type Proc. Lead Time Component
Fig. 8.27 Structure of the lead time customizing
The activity type defines which kind of activity contributes to the lead time.
Possible values are order processing, goods receipt, shipment, goods issue and
production. The procurement lead time component defines which master data
entry is used or whether synchronization with a calendar is performed. The
customizing settings are maintained with the path APO ! Supply Chain
Planning ! SPP ! Basic Settings ! Configure Scheduling, Fig. 8.28.
Fig. 8.28 Configuration of the scheduling scenarios
For the procurement lead time group there is a naming convention: the
components—i.e. the master data fields—are abbreviated as C2, C4 etc. The
correspondences for the master data fields are listed in Table 8.2. The procurement
lead time group IDs are named with the content of their components.
Table 8.2 Lead time relevant fields

Element Field name Master data View
C2 Review-time (Depl.) Product SPP Deployment
C2DEPL Review-time (DRP) Product SPP DRP
C3 Communication duration Transport lane Header
C4 GI Processing time Product GR/GI
C6 Transport duration Transport lane Means of transport
C7 Throughput time Product SPP DRP
C8 GR Processing time Product GR/GI
F Correct. Of fix period Transport lane Header
PH Partner horizon Transport lane Product
PLIFZ Planned delivery time Procurement relationship
Figure 8.29 shows the activity types and the procurement lead time components
for the example of the location to location lead time in case of pull deployment
(procurement lead time group ID ‘C2DEPL + C4, C6, C8’).
Fig. 8.29 Configuration of the component lead times
The elements C2, C2DEPL, C3, C4, C6, C7, C8, F and PLIFZ correspond to
fields in the master data. Table 8.2 lists the correspondence between the elements
and the master data fields. The elements C3, F, PH and PLIFZ are used for the
calculation of horizons for DRP (see Sect. 8.4). The component lead time consists
of different terms that are separated by commas. Each term is scheduled according
to its own calendar (e.g. shipping calendar, receiving calendar) and is either a
positive value or zero. SYNC means that the scheduled date of the previous term
is synchronized with the calendar and might be rescheduled. The terms are added.
Figure 8.30 shows the lead time relevant fields of the product master.
8.3 Scheduling 191
C8
C4
© SAP AG
C2
C7
© SAP AG
C2DEPL
© SAP AG
Fig. 8.30 Lead time relevant fields in the product master
The transport duration in the transportation lane is maintained in the view for the
means of transport as shown later in Fig. 8.36.
Scheduling and Demand Date

Scheduling is required in order to determine the demand date of a planned stock
transfer at the entry location. This applies both to a planned stock transfer or a
planned procurement. Figure 8.31 shows an example for a planned procurement
from a supplier.
Fig. 8.31 Scheduling with the lead time in the DRP matrix
Though there is already demand for the current planning period (24th of July),
the planned procurement will only be available on the 29th (key figure ‘rounded net
demand (constrained)’)—just after the lead time and—potentially—the goods
receipts processing time. The planned shipment from the supplier’s site is already
at the 25th (key figure ‘distribution receipt from supplier (constrained) by ship
date’). The difference between the net demand and the supply quantity is due to
the EOQ.
Scheduling Simulation and Explanation

For a better understanding of the scheduling results it is possible to simulate
scheduling for any scheduling scenario for a service part between two locations
with the transaction /SAPAPO/SPP_SCHD_EXP. Figure 8.32 shows the result for
Fig. 8.32 Scheduling simulation and explanation
8.4 Horizons 193
the scheduling scenario 2 (DRP lead time location to location for pull deployment)
between the locations PLSPG1@RME801 and PLSPG2@RME801. The individual
parts of this scheduling scenario—C2DEPL + C4, C6, C8 as shown in Fig. 8.29—
are listed with their durations. In this example the duration of each part is 24 h.
The scheduling direction is set with ‘’ as backward and with ‘+’ as forward.
8.4 Horizons
The DRP planning run creates, changes and deletes planned stock transfers and
schedule lines (respectively purchase requisitions). Depending on how far in the
future the order changes are due, not all changes are desired. Horizons are used to
restrict the automatic planning changes. For DRP the following four horizons are
relevant:
• Freeze horizon: The freeze horizon represents the physical lead time of the
supplier plus the plan review time, the communication time and the buffer for
the correction of the fixed period. Alternatively the freeze horizon can be defined
as a dynamic one in the corresponding product-specific transportation lane.
Additionally there is also the possibility to define a manual freeze horizon in
the transaction /SAPAPO/DRPRP (DRP/deployment planning lock). The lon-
gest of the 3—if maintained at all—is taken in the course of the planning
function
• Limited freeze horizon: The limited freeze horizon represents additionally the
production time of the supplier without the buffer for the correction of the fixed
period.
• Plan submission horizon: Within the plan submission horizon the scheduling
releases are transferred to the supplier (BAdI required, see Sect. 9.6)
• Planning horizon: DRP planning is only performed within this horizon.
These horizons are determined by different master data settings—similar to the

lead time. Figure 8.33 shows these four horizons.
Planning Horizon
Plan Submission Horizon

Partner Horizon
Limited Freeze Horizon

C2+C3, PLIFZ-C6, SYNC, C6, C8
Freeze Horizon
C2+C3+F, SYNC, C6, C8
Time
• No Automatic Changes • Limited Automatic Changes • Automatic Changes • Automatic Changes
• Alert for Shortage • Stability Rules Applied • Stability Rules Applied • No Stability Rules
Fig. 8.33 Horizons and stability rules
The planning horizon is restricted using the parameter ‘planning horizon’ in the
product specific view of the transportation lane. Given the default customizing, the
three horizons are defined by the master data entries shown in Fig. 8.34.
Plan Submission Horizon
Partner Horizon
(Transp. Lane)
Limited Freeze Horizon
DRP Review Communication Planned Del. Transport Duration Transport Duration GR Time
+ - +
(Product) (Transp. Lane) (Proc. Rel.ship) (Transp. Lane) (Transp. Lane) (Product)
Freeze Horizon
DRP Review Communication Fix Period Transport Duration GR Time

(Product) (Transp. Lane) (Transp. Lane) (Transp. Lane) (Product)
Legend
Synchronisation with the Calendar
Fig. 8.34 Lead time components for the horizons
The notation for the limited freeze horizon differs from the other ones. The term
‘planned delivery time (procurement relationship)—transport duration (transporta-
tion lane)’ is a positive value or zero, and it is scheduled separately. Therefore it is
not possible to simplify the formula for the limited freeze horizon.
8.4 Horizons 195
In the DRP matrix the freeze horizon and the limited freeze horizon are
displayed in grey resp. yellow, Fig. 8.35.
Fig. 8.35 Horizons in the DRP matrix
Table 8.2 lists the master data fields which correspond to the elements for the
calculation of these horizons. Some of these are new fields in the transportation
lane. Figure 8.36 shows these fields for the sake of better recognition. Note that the
‘header data’-view in the transportation lane is new.
Fig. 8.36 Lead time relevant fields in the transportation lane
8.5 Stability Rules
The stability rule defines in detail how far it is allowed to change the results of a
DRP planning run. Stability rules are defined for the limited freeze horizon and for
the plan submission horizon.
Stability Rule Structure and Assignment

The stability rule for DRP is maintained with the customizing path APO ! Supply
Chain Planning ! SPP ! DRP ! Define Stability Rules for DRP Horizons and
contains four different rules: for expedite and de-expedite orders within the limited
freeze horizon and the plan submission horizon. Figure 8.37 shows the structure of
the stability rule.
8.5 Stability Rules 197
Stability Rule for Limited Freeze Horizon

(De-Expedite)
Stability Rule for Limited Freeze Horizon DRP Service

(Expedite) Profile
Stability Rule DRP

Stability Rule for Plan Submission Horizon
(De-Expedite) Product
Stability Rule for Plan Submission Horizon

(Expedite)
Fig. 8.37 Stability rule assignment
The stability rule is assigned to the product in the ‘SPP DRP’-view or to the DRP
service profile. The standard stability rule of the DRP service profile is used if no
stability rule is assigned to the product, Fig. 8.38.
Fig. 8.38 Assignment of the stability rule to the product master
To take the stability rules into account, the parameter ‘apply stability rules’ must
be set in the DRP planning profile. Figure 8.39 shows this setting and the standard
stability rule.
Fig. 8.39 Apply stability rules and the standard stability rule in the DRP service profile
Stability Rule Logic

In comparison to the settings in the release creation profile in SAP ERP™ and SAP
APO™ procurement, the logic of the stability rules in DRP is far more complicated.
In order not to overstrain this topic, we are looking only at the functionality of the
stability rules within the limited freeze horizon.
The stability rules (for the limited freeze horizon) only come into consideration
if there are changes within the limited freeze horizon. Depending whether the
change means a shortage or an excess, the expedite rule (for shortage) or the
de-expedite rule (for excess) is used. Figure 8.40 shows a simplified flow chart
for the logic of the stability rules. The bold decisions and process steps are
explained in more detail separately.
Loop at Periods k of the Limited Freeze Horizon
Changes in Yes
No
Remaining Limited
Freeze H.?
No Existing No Yes Eligible for Yes Determine

Shortage?
Schedules? Expedite? Placement Period
Yes No
Each Period Method for

Order Scheduling?
Method for Single Order Single Calculate Largest

Order Scheduling? Order Shortage in Horizon
Schedule No
Each Orders According to
Rounded All Demands? Calculate
Period Net Demand is No Rounded Net Demand
Zero in All Remaining Yes
Periods?
Add Maximum of
Calculate & Add Largest Shortage and
Yes
Rounded Net Demand Rounded Net Demand
De-Expedite Re-plan from Placement

Delete Schedule Round Round
Each Period Period on
Reduction Check
Endloop
Fig. 8.40 Stability rule logic for the limited freeze horizon
Expedite
In the case of a shortage it is first checked whether the shortage is severe enough to
justify changes within the freeze horizon. This ‘eligible for expedite’-check
compares the shortage within the limited freeze horizon to the demand of the
next 21 days, whether the shortage is not too close at the end of the freeze horizon
and whether some days in the future there is still a shortage, Fig. 8.41.
Unrounded Net Demand Yes

in Period k > X% of the Gross Demand
of the Next 21 Days?
Period (k + Z -1) within

Limited Freeze Horizon?
Yes
Unrounded Net Demand

in Period k + Z -1 > Y% of the Gross Demand
Not Eligible for Expedite Eligible for Expedite
Fig. 8.41 Eligibility check for expedite
The parameters X, Y and Z are maintained in the stability rule for the limited
freeze horizon (expedite), Fig. 8.42. Note that only the flagged demand elements are
considered for the shortage calculation—if for example the forecast is not flagged, a
shortage due to uncovered forecast demand will not cause eligibility and therefore
no new order will be created within the limited freeze horizon. Another point
regarding the calculation of the shortage is that only the unrounded demand is
used, not the rounded demand.
Fig. 8.42 Stability rule for the limited freeze horizon (expedite)
If a shortage within a period of the limited freeze horizon is eligible, the next step
is to determine the date of the schedule line. The quantity of the schedule line
depends on the ‘orders scheduling’ parameters of the stability rule (see Fig. 8.42).
The period where the order is scheduled is not necessarily the same period where
the first shortage was eligible but might be earlier. The idea for this is that if the
additional effort respectively cost is accepted to order within the limited freeze
horizon, one might as well order early enough to cover an earlier shortage which did
not qualify for expedite orders. If there is an earlier period with a shortage that
exceeds W percent of the next 21 days’ gross demand, the order is placed in that
period, Fig. 8.43.
Loop at Periods j of the Limited Freeze Horizon

before the Eligible Period k
Unrounded Net Demand Yes

in Period j > W% of the Gross Demand
No
j=j+1
Endloop
Place Order in Period k Place Order in Period j
Fig. 8.43 Determine placement period for expedite
Here k is the period where a shortage was eligible and j is any period before that.
The parameter W is maintained in the stability rule for the limited freeze horizon
(expedite) as well. If this is desired, W has to be lower than X.
If the change is not eligible for expedite, the shortage is not covered in the
limited freeze horizon. Figure 8.44 shows an example for this case.
Fig. 8.44 Effect of stability rules in the DRP matrix
The rounded net demand (constrained)—which represents the planned receipts

from the supplier—does not react to the change in the demand and remains zero
until the end of the limited freeze horizon on the 22.11.3005.
Method for Order Scheduling

The stability rules offer three methods for order scheduling: Single order, each
individual period and no change of order quantity. Using ‘no change of order
quantity’ the stability rules prevents DRP from changing the orders—only alerts
are created. With the ‘each period’-method the additional order quantity is the
rounded net demand of the placement period, whereas the additional order quantity
with the ‘single order’-method is the maximum of the rounded net demand and the
biggest shortage within the limited freeze horizon, Fig. 8.45.
Fig. 8.45 Method for order scheduling
Given the multitude of parameters it is not easy to understand the results. Using
the method ‘each period’ and the setting ‘schedule orders according to all demands’
one has the best chances.
The flag for the change horizon controls that if there is no change within the
change horizon, no further action is taken. The reason is not to ‘disturb’ the supplier
unnecessarily. However, this flag might add to confusion when interpreting the
result of the DRP run.
De-Expedite
In case of an excess, the de-expedite branch of the flow chart in Fig. 8.40 becomes
relevant. If there is a schedule line to be reduced/deleted, one of the following
procedures is taken: If the method for order scheduling is ‘single order’, the
schedule line is deleted if the rounded net demand in all remaining periods is still
zero without the excess schedule line. For the ‘each period’-method Fig. 8.46 shows
the process flow.
No Schedule Yes
Orders According to
All Demands?
End Period = Maximum of Limited Replan from the
Freeze Horizon and POD of Schedule Line Excess Period on
End
Calculate Excess Stock from Actual Period to End Period
Loop at Periods k of the Limited Freeze Horizon
No
End Excess Stock > 0?
New Qty. = Schedule Qty. - Excess Stock
Reduction Qty. = Schedule Qty – Rounded New Qty.
Yes
Yes
Existing Schedules?
Reduction Qty > X % of
No the Gross Demand of the Next 21 Days
No End
AND Reduction Qty > Y % of the
Schedule Qty?
Yes
Schedule Qty. = Schedule Qty. – Reduction Qty.
Excess Stock = Excess Stock – Reduction Qty.
Endloop
Fig. 8.46 De-Expedite for ‘Each Period’-order scheduling
The parameters X and Y are maintained in the stability rule for the limited freeze
horizon (de-expedite), Fig. 8.47.
Fig. 8.47 Stability rule for the limited freeze horizon (De-Expedite)
If the total order quantity in the limited freeze horizon is reduced, an alert is
created. The prerequisite is that the checkbox ‘retain total order quantity’ in the
stability rule for de-expedite is marked.
Restriction in the Application of Stability Rules

There are some logical interactions between the application of stability rules within
the limited freeze horizon and some other features in DRP, which limit the full
functionality. E.g. the supplier’s constraint in regard of the function of substitution
of remanufactured product as well as the optimized procurements schemes in the

course of product group procurement are evaluated as higher constraints as the
stability rules. This impacts the changeability of orders accordingly. OSS note
1539877 gives more information on this.
8.6 DRP Features for Seasonality
8.6.1 Anticipated Demand Coverage
If a seasonal forecast model is used, the value of the forecast changes from month to
month (or from fiscal year period to fiscal year period). The forecast value is equally
distributed in DRP along the daily buckets in DRP. This might lead to a huge and
sudden increase of the demand from 1 day to the other.
The purpose of the anticipated demand coverage is to smooth the increase of the
demand by placing fixed requirements. The anticipated demand coverage works
only for the increase of the demand, not for the decrease. To keep the demand
balance, fixed receipts are placed a number of periods later, Fig. 8.48.
Forecast
Receipts Requirements
Time
Fixed Fixed
Time
Number
of Periods
Smoothed Forecast
Time
Fig. 8.48 Anticipated demand coverage
Both fixed requirements and fixed receipts are placed for the periods where no
smoothing applies. The reason for this is that the difference between the ‘valid
from’-date and the ‘valid to’-date of the fixed requirements spans the number of
periods that are used for the anticipated demand coverage—in the example shown
in Fig. 8.48 the fixed requirement has to be valid for two additional days until the
according fixed receipt is placed.
8.6 DRP Features for Seasonality 205
The number of the periods, the quantity of the fixed requirements and the
threshold for the anticipated demand coverage are defined with the customizing
path APO ! Service Parts Planning ! SPP ! DRP ! Anticipated Demand
Coverage ! Create Profile for Anticipated Demand Coverage, Fig. 8.49.
Fig. 8.49 Profile for anticipated demand coverage
The settings in Fig. 8.49 control that the increase in the daily forecast has to be
above ten to cause the anticipated demand coverage (‘daily forecast difference
threshold’) and the fixed requirements and receipts will cover 50 % of the increase
(‘percentage of forecast difference’). The shift between fixed requirements and
fixed receipts is 2 days—defined by the period indicator ‘day’ and the ‘number of
periods’. If another period indicator—e.g. ‘week’—is selected, only one fixed
requirement and/or fixed receipt is created for the whole week. If the period of
coverage by the economical order quantity is below 1 week, this might not be
sufficient to smooth the demand. The anticipated demand coverage profile is
assigned to the product in the ‘SPP DRP’-view, Fig. 8.50.
Fig. 8.50 Assignment of the ADC Profile to the product master
Figure 8.51 shows an example in the DRP matrix for the smoothing of the
increase. The ‘fixed demand (non-overriding)’ contains the fixed requirements for
anticipated demand coverage. Fixed receipts and requirement are identical with the
forecast increase concerning quantity. This is according to the setting (100 %) in the
Profile of Anticipated Demand Coverage as shown in Fig. 8.49. There might be a
shifting of the demand due to non-working days (as on 31st July 2014 in Fig. 8.51).
Fig. 8.51 Example for anticipated demand coverage in the DRP matrix
The reaction of the anticipated demand coverage at the end of the forecasting
period is shown in Fig. 8.52 for the same example. In this case the decrease is
smoothed.
Fig. 8.52 ADC—Smoothing of the forecast decrease at the end of the forecast period
The anticipated demand coverage is not part of the DRP planning service but
requires the separate planning service SPP_PFR. The service profile is created with
8.6 DRP Features for Seasonality 207
the customizing path APO ! Service Parts Planning ! SPP ! DRP ! Anticipated
Demand Coverage ! Define Service Profile for Anticipated Demand Coverage,
Fig. 8.53.
Fig. 8.53 Service profile for anticipated demand coverage
Figure 8.53 shows, the service profile for anticipated demand coverage contains
the reference to the DRP service profile as the only entry.
8.6.2 Pre-season Safety Stock Shift
If a product is subject to a seasonal demand, the safety stock might change from
season to season as well. If the seasonal behavior differs—e.g. because winter starts
earlier—the current safety stock might not be sufficient. Using the pre-season safety
stock shift DRP does not cover the actual safety stock but the maximum of the next
NSS periods, Fig. 8.54.
Safety Stock
Time
Planned Safety Stock
NSS = 2
Portion of Safety Stock Shift
Time
Fig. 8.54 Seasonal safety stock shift
The number of periods NSS depends on the procurement cost of the product and
is defined in a table with the customizing path APO ! Supply Chain
Planning ! SPP ! DRP ! Define Parameters for Pre-Season Safety Stock Shift,
Fig. 8.55.
Fig. 8.55 Parameters for pre-season safety stock shift
The first prerequisite for the pre-season safety stock shift is that a seasonal
forecast model is used for the location product and that there is a seasonal behavior
of the safety stock—which is modelled by the parameter ‘seasonal’ in the safety
stock model (see Fig. 6.12).
Fig. 8.56 Flag for pre-season safety stock shift in the DRP service profile
The pre-season safety stock shift is applied if the according flag is set in the DRP
service profile, Fig. 8.56. Another prerequisite is that the pre-season safety stock
shift is not inhibited for the location product in the product master, Fig. 8.57.
Fig. 8.57 Inhibit pre-season safety stock shift in the product master
8.7 Procurement Planning 209
Figure 8.58 shows the result in the DRP matrix for a number of periods NSS of
two:
Relevant Safety
Stock for DRP
Safety Stock from
EOQ & Safety Stock
Planning © SAP AG
Maximum: 377,11
Fig. 8.58 Example for pre-season safety stock shift in the DRP matrix
The key figure ‘safety stock’ contains the safety stock that was calculated by the
EOQ and safety stock service (see Chap. 6). The planned minimum safety stock
level—which is relevant for DRP—contains however the maximum safety stock of
the actual period plus the next two periods.
8.7 Procurement Planning
8.7.1 Sourcing
The purpose of DRP is to create schedule lines or purchase requisitions at the entry
location for the demand in the network. Contracts are the prerequisite for the use of
purchase requisitions. Both scheduling agreements and contracts are created in SAP
ERP™ and transferred to SAP APO™ via CIF as procurement relationships.
Figure 8.59 shows procurement relationships in SAP APO™ (transaction
/SAPAPO/PWBSRC1) based on scheduling agreements and on contracts.
Fig. 8.59 Procurement relationships
For external procurement it is possible to consider multiple sourcing using quota

arrangements (transaction /SAPAPO/SCC_TQ1) as shown in Fig. 8.60.
Fig. 8.60 Quota arrangement
The processing of the procurement proposals is described in Chap. 9.
8.7.2 Product Group Procurement
The idea of product group procurement is to reduce the fix order costs for slow
moving parts. E.g. if some products require the same set-up at the supplier, savings
are achieved by ordering these products together. The grouping for those products is
done via product groups of a defined product group type. This product group type is
defined in the general DRP settings with the customizing path APO ! Supply Chain
Planning ! SPP ! DRP ! Make General Settings for DRP, Fig. 8.61.
Fig. 8.61 Product group type for product group procurement (general DRP settings)
Figure 8.62 shows an example for product group procurement where part B is
procured before its demand date.
Demands (Parts A, B)
A B
A B B
Schedule Lines (Parts A, B)
Group Normal Time

Procurement Procurement
for Part B for Part B
Fig. 8.62 Example for product group procurement
Product group procurement is however only done if the savings exceed the costs
due to stock holding. As a result of product group procurement the ‘rounded net
demand (constrained)’ will be earlier than the ‘total gross demand’ and the
‘unrounded net demand (adapted)’. This leads to an increase in the projected
stock as shown in the DRP matrix in Fig. 8.63.
Fig. 8.63 Example in the DRP matrix for product group procurement
To determine the optimal procurement interval for product group procurement,

the total costs are calculated for all alternatives from monthly to yearly (increasing
by monthly steps). The result of the product group procurement is displayed in the
schedule board with the transaction /SAPAPO/SPPDRPSB, Fig. 8.64.
Fig. 8.64 Product procurement cost alternatives
The total costs consist of the stockholding costs and the set-up costs. The
stockholding costs are calculated as described in formula (8.3):
Stockholding Costs ¼ ½ ðSA þ SB Þ CPS 365 NM =12 ð8:3Þ
Where NM the number of month for product group procurement (2 months in

Fig. 8.64), SA is the stock after the procurement and SB the stock before the next
procurement, as shown in Fig. 8.65.
Stock
SA
SB
Time
Number of Months NM
Fig. 8.65 Stock after and before product group procurement
In the example shown in Fig. 8.64 the factor ½ (SA + SB) is 100 pieces. The
product storage cost CPS is maintained in the ‘procurement’-view of the location
product, Fig. 8.66.
Fig. 8.66 Product storage cost per day in the product master
If no product storage costs are maintained, the procurement costs times the stock
holding factor is used instead, formula (8.4).
Stockholding Costs ¼ ½ ðSA þ SB Þ CP FHC NM =12 ð8:4Þ
The procurement costs CP and the stock holding factor FHC are maintained in the
product master as shown in Fig. 8.67.
Fig. 8.67 Procurement costs and holding cost factor in the product master
The calculated stockholding costs are also displayed in the log. The set-up costs
are maintained in the procurement relationship (transaction /SAPAPO/PWBSRC1),
Fig. 8.68.
Fig. 8.68 Set-up costs in the procurement relationship
The set-up costs represent the costs for the whole product group, not just for the
single product. For the calculation of the set-up costs of the product group the set-up
cost of the service part is used which triggers the procurement. In order to avoid
inconsistencies, the set-up costs should have the same value for all members of the
product group.
8.7.3 Supplier Shutdown
In DRP it is possible to model shutdown times at the supplier—e.g. during summer

vacation. In this case the demand is sourced earlier. The supplier shutdown is
maintained as a master data with the transaction /SAPAPO/SPP_SSD, Fig. 8.69.
Fig. 8.69 Supplier shutdown maintenance
The demand for the shut down period is pulled forward according to the
percentage of periods. Figure 8.70 visualizes the way the percentage for periods
is used.
Demand
Supplier Shutdown Time
Period 1 2 3 4 5
% 10 50 10 10 20
Demand
Time
Fig. 8.70 Pull forward according to the percentage for periods
For the pull forward the calendar is not considered. If the demand is pulled to a
non-working day, it is added to the demand of the previous working day. The
supplier shutdown is assigned to the location product master in the ‘SPP DRP’-view
as shown in Fig. 8.71.
Fig. 8.71 Supplier shutdown assignment in the product master
The assignment of the supplier shutdown to the location product makes sense
when it is procured with a single supplier policy—since no supplier-specific
differentiation is possible in this case. Another use case is if not the supplier
shuts down but service parts logistics company which is running the SPP-system
itself—or at least some locations of it.
Alternatively the shut down profile can be assigned to the product-specific
section of the transportation lane connecting the supplier’s location and the respec-
tive target location, Fig. 8.72.
Fig. 8.72 Supplier shut down profile assignment in transportation lane
The target location does not need necessarily to be an entry location of the BOD.
In case of repair-or-buy planning where the external refurbishment is planned of
and for a location below the entry location, the supplier shut down is also applica-
ble. Another example is the process of push deployment from supplier where the
effective target location (to be delivered) is one of the locations below the entry
location. In this case the supplier shutdown profile is assigned to the transportation
lane from the supplier to the location of the second BOD level.
8.8 DRP Service
The service profile for DRP (planning service SPP_DRP) is defined with the
customizing path APO ! Supply Chain Planning ! SPP ! DRP ! Define Service
Profile for DRP as shown in Fig. 8.73. Most of the settings have already been
8.8 DRP Service 217
Fig. 8.73 DRP service profile
explained. Other settings allow to ignore the replenishment indicator and to create
purchase requisitions even if no procurement relationship is defined in DRP yet.
DRP Approval
DRP approval is explained in Chap. 9. Instead of performing the DRP approval as a
separate service it is also possible to integrate it into the DRP planning service. For
a separate DRP approval the entry ‘separate DRP approval’ must be selected. It is
also possible to skip the DRP approval by the setting ‘without DRP approval’.
From a performance perspective it is recommended to perform an integrated
DRP approval instead of a separate DRP approval.
Standard Service Profiles

The standard service profile for DRP GLOBAL_DEFAULT is created with the
customizing path APO ! Supply Chain Planning ! SPP ! DRP ! Create Global
Standard Service Profile for DRP and the standard profile for the automatic assignment
of profiles with the path APO ! Supply Chain Planning ! SPP ! DRP ! Anticipated
Demand Coverage ! Create Service Profile for Automatic Assignment of Profiles.
8.9 Repair or Buy Planning
8.9.1 Process Overview
In some cases the purpose of replenishment planning via DRP is not only the
replenishment via external procurement but also the internal sourcing via repairing
used and returned parts. Then the result of the DRP planning is not only schedule
lines or purchase requisitions but also planned refurbishment orders in case of an
in-house repair and subcontracting purchase requisitions in case of an external
repair. Using this variant of DRP planning is called “Repair or Buy” since the
possibility exists to choose one of these two types of replenishment or to mix these
depending on the individual situation.
Repair of used service parts as alternative to the procurement of new parts is—if
technically possible—mostly more cost-efficient and therefore promises a higher
margin. Sometimes parts customer even can expect a higher product quality of
repaired parts because the repair process is less industrialized and more accurate.
Examples of parts eligible for a repair option are expensive products like
generators, starters or diesel engines. Some companies’ business model is fully
based on used products that are recycled before they are sold again into the market
as overhauled products. So, if the return flow of the defect product would be
constant and plenty, no additional external procurement would be necessary.
The business process as it is represented in SPP is shown in Fig. 8.74.
Fig. 8.74 Process overview repair or buy
8.9 Repair or Buy Planning 219
A part is originally purchased as a new product from the part supplier, e.g. an
OEM. The service part logistics company (which runs the SPP-system) acts nor-
mally as a wholesaler and sells the new part to a final customer (e.g. a dealer or
service provider). After a certain runtime of the part or when the part breaks, the
customer sells this part back and returns it to the wholesaler. This returned part is
called unserviceable, since it is defect and cannot be used to fulfill (service) other
customer demands. When the repair is successfully finished, the part will be put
back into stock as a serviceable product that is ready to be used and to fulfill
upcoming customer demands. So, there will be two types of serviceable parts on
stock, i.e. new parts on one hand and repaired parts on the other hand in order to
guarantee differentiated treatment and pricings accordingly.
Serviceable Versus Unserviceable Products

In SAP the differentiation between unserviceable and serviceable parts is achieved
by using batches or storage locations as shown in Fig. 8.75.
Fig. 8.75 Sub-dividing serviceable and unserviceable
Batches are called versions in SPP and storage locations are sub-locations. This
means that e.g. serviceable products are only stored in storage locations that are
exclusively dedicated for serviceable products. The same applies for dedicated
batches.
In SPP this can be identified in stock overview per location product in transac-
tion /SAPAPO/RRP3, Fig. 8.76. In plant SPB1 10 serviceable products are stored in
sublocation SRVR and 20 unserviceable products in sublocation USRV.
Fig. 8.76 Serviceable and unserviceable sub-locations in stock overview
Also planned receipts (planned orders or purchase requisitions) and their depen-
dent demands are assigned to the sub-locations they belong to—so there is no risk
of mixing serviceable and unserviceable parts.
In order to enable the SPP planning service to differentiate between serviceable
and unserviceable parts it is not sufficient to separate the stock according to storage
location and batches. What is needed additionally is the allocation of the stock into
different ATP categories. Figure 8.77 shows that the stock which is stored in storage
location (sub-location) USRV is assigned to the ATP category UA whereas the
stock in storage location SRVR is assigned to the ATP category UD. Both these
ATP categories are not delivered by SAP as standard and therefore must be created
customer-specifically in customizing in the section NON-SAP-Categories as shown
in Fig. 8.77. These settings are accessed via path Advanced Planning and Optimiza-
tion ! Global Available-to-Promise (Global ATP) ! General Settings ! Maintain
Category.
Fig. 8.77 Determination of ATP-categories for serviceable and unserviceable parts
Eventually these settings are assigned to the appropriate stock semantics in the
TDL customizing as it is described in Sect. 2.4. Figure 8.77 in the lower part shows
how the ATP category UD (serviceable stock) is assigned to semantics
INV_REPAIRED. With this the categorized stock can be displayed in the DRP
matrix in the appropriate key figure and takes part in DRP planning respectively.
In order to point into the right ATP category when either doing a goods receipt or
a goods issue of either serviceable or unserviceable products, the so-called event-
driven quantity assignment (EDQA) is used which is already described in Sect.
10.2.2. With EDQA it can be achieved that stock is re-assigned from a certain ATP
category into another one depending on certain events and other criteria. Figure 8.78
shows how to configure EDQA so that it can be used for serviceable/unserviceable
part purposes.
Fig. 8.78 EDQA settings for differentiation between serviceable and unserviceable parts
In this the event activity “change stock data” (e.g. goods receipts) triggers the
change of the corresponding ATP category. Accordingly the EDQA activity is
assigned to the process category “RSTOK_USRV in this example. This process
category is assigned to different profiles. One is the category profile, which defines
that the ATP category CC (which is unrestricted use stock) should be replaced by
ATP category UA. The other is the condition profile, which defines under which
circumstances this change of ATP category shall take place—in this case the
condition is valid if the storage location involved is “USRV”. The condition profile
can be customized with transaction /SAPAPO/EDQA_PPN.
Repair or Buy Types

There are a few variations of the repair or buy planning logic and the corresponding
results. Figure 8.79 shows that there are basically three repair or buy functions. On
the one hand there is the alternative called “buy and calculate the unserviceable
stock at location”. Here DRP behaves as if no repair or buy function would be active
and all demand is covered by external procurement. But additionally the quantity of
the unserviceable product of the respective location is calculated for information
purposes as well as a basis for a potential consecutive inventory balancing step.
This unserviceable quantity will be considered as excess because at this location
never a repair will be triggered. However, the unserviceable parts may be repaired
at another location.
Fig. 8.79 Repair or buy process flow in SPP DRP
Another alternative is the function “only repair”. In a net demand situation at the
respective location the only way of fulfilling the demand is by repair. If no sufficient
unserviceable products are available in order to supply the repair process and if
external procurement is theoretically possible then an alert is raised (alert type
7890). The maximum quantity of unserviceable products that is available for repairs
is the projected unserviceable stock at the start of the repair process.
The third alternative is the function of “repair or buy” where in a net demand
situation the repair process is the first choice of procurement. However, if the
demand cannot be fulfilled in time or—if it is late—with reasonable costs for
delay then external procurement would be applied.
In both options “Repair or Buy” and “Only Repair” repair could be done
in-house or externally at special subcontractors. The in-house repair would be
modeled with planned orders and refurbishment orders whereas the external repair
would be modeled by a subcontracting process represented by subcontracting
purchase requisitions and subcontracting purchase orders.
8.9.2 Repair or Buy Planning Logic
Prerequisites and Master Data Settings

The prerequisites in the SPP-system are settings in the location product master as
well as in the customizing.
The activation of the repair-process as an alternative to the “normal” DRP
procurement planning is done in the location product master in the tab ‘DRP’ and
Fig. 8.80 Repair or buy specific settings in location product master
there in the sub-tab ”Kit to Stock/Repair or Buy” as seen in Fig. 8.80. In the
parameter “KtS/Repair or Buy” one of the four alternatives “Repair or Buy”,
“Only Repair”, “Buy and Calculate Unserviceable at Location” or “Off” (normal
DRP) can be chosen. In the field ‘Type of KtS/Repair‘ it is specified whether
internal or external repair is chosen or one of them preferred.
There is no additional parameter in the DRP-profile whatsoever so activate or
manipulate the repair-or Buy settings—apart from rules concerning rounding,
which is described further down this chapter.
Repair or Buy planning can be applied with both DRP planning modes—period-
based and reorder-point-based
Repair or Buy Specific Key Figures

As soon as repair or buy planning is activated in the DRP matrix additional key
figures appear. In Fig. 8.81 in the marked section 1 key figures related to the
unserviceable products as they are planned by DRP appear. It shows the projected
stock as the main key figure and all the sub-ordinated key figures that determine the
calculation of the projected stock. These are e.g. initial warehouse stock, forecast
demand for the unserviceable products, receipts and demand for the unserviceable
product (derived from planned orders, STOs or from substitution orders) as well as
transit stock of unserviceable products.
In the second marked section there is one key figure that is always available in
the DRP matrix but becomes especially relevant a soon as planned orders or
Fig. 8.81 Repair or buy

specific key figures in DRP
matrix
subcontracting purchase requisitions are created for repair purposes. Then the
dependent demand of the relevant unserviceable products as input components
(based on the BOM/PDS-explosion) is displayed here.
In the third marked section there are two key figures which represent the receipts
of serviceable products. The frozen product receipts comprises the manually fixed
planned orders or manually fixed subcontracting purchase requisitions as well as
manufacturing orders or subcontracting orders. The not frozen receipts comprise
the summed up product quantities included in planned orders and subcontracting
purchase requisitions.
Forecast Planning of Unserviceable Products

One important information for calculating future available stock of unserviceable
products (projected stock) is the expected return of used or defect products. The
expected returns, which will be available for repair, can be forecasted in SPP. But
the forecast will not be made by the usual forecast service (e.g. planning service
SPP_FCS_SERVICE). The determination of repairable return forecast is rather
supported by DRP via three different methods, which can be chosen via settings
in the respective location master (the prerequisite settings of this methods is shown
in Fig. 8.80.):
• Either the forecast can be loaded into SPP from an external source via a BAPI.
• Alternatively a method can be chosen that is based on forecast-specific time
series, for which the corresponding profiles are maintained the DRP-specific
customizing.
• “Based on demand forecast”: Applying this logic the forecast demand of the
original new part is taken into consideration as a planning basis. The assumption
is that the new part will be returned on a regular basis after an average run time
of usage by the customer. Since not all returned products are good enough only a
certain percentage can been taken into consideration. Additionally only a certain
yield percentage of the repair process is taken into consideration. Eventually the
potential receipt of repaired quantity is shifted in time according to a certain
experienced average duration which is represented in the location master as
return time for unserviceable products.
Figure 8.82 shows a result of the returns forecast determination. E.g. the forecasted
demand of the serviceable product on the 30th May 2014 is corrected by the factor
“%Good Quantity of the Returned Quantity” (0.8) and by the factor “% Yield of
Repaired Products” (0.9). Therefore the original forecast of 5,714 results in a return
forecast of 4,114. This figure eventually is time-shifted according to the Return
Time of Unserviceable Products (2 day).
Fig. 8.82 Determination return forecast based on serviceable demand forecast
Net Demand Determination of Unserviceable Products

Figure 8.83 gives an idea on how the net demand calculation and fulfillment
combined among unserviceable and serviceable products works.
The DRP matrix is subdivided into two parts. In the upper part the situation of
the unserviceable part of the product IS1_HALB_0003@QU6715 after the DRP
planning run is shown whereas in the lower part the corresponding situation of the
serviceable part of the same location product is shown. The net requirement
determination and fulfillment of the unserviceable is done in a similar manner as
described in Sect. 8.2. One difference is that the return forecast is not interpreted as
demand but as receipt in each respective bucket. E.g. in bucket of the 1st May the
projected stock of the previous bucket (here the overdue column; a quantity of 10) is
increased by the Repairable Returned Forecast of the respective bucket (quantity
2,743) and decreased by a Unserviceable Product Demand (Not frozen) of 6, which
results in a new projected stock at the 1st May of 6,743.
In the lower section the projected stock of the serviceable on 1st May is
determined by subtracting the Total Gross Demand from the projected stock of
the previous bucket and adding the Total Gross Receipt to Receipts to it. Indeed, at
the 6th May a receipt is necessary in order to avoid Supply Shortage. Hidden behind
the quantity of 3 of the key figure Total Gross Receipt there is a planned order for
refurbishment.
Due to BOM explosion and production lead time this planned order causes a
dependent demand of 6 for the unserviceable part at 1st May represented in the line
of key figure ‘Unserviceable Product Demand (Not frozen)’. This is shown with the
dotted line.
Fig. 8.83 Combined net demand calculation serviceable and unserviceable
On the 7th May the planning situation of the serviceable runs into a supply
shortage. Reason for that is that there are not sufficient unserviceable available on
the 2nd May (4 instead of 12) in order to fulfill the need of 5,571 of serviceables. No
external procurement for potential compensation of the gap is triggered due the fact
that here the type of KtS is set to “Only Repair”. A (temporary) lack of coverage is
accepted in this case.
BOM Explosion and Scheduling

In any case of repair (internal or external) a BOM explosion is needed in order to
determine the components needed and their quantity. In SAP ERP as the leading
master data system this is defined in the BOM. In APO this corresponds with
the Production Data Structure as shown in Fig. 8.85 in the lower section. There is
defined as a recursive bill of material that 2 unserviceable products are
needed to create 1 serviceable product of the same location product
IS1_HALB_0003@QU6715. The relation between BOM output and BOM input
is shown in the DRP Matrix in Fig. 8.84 where a planned order or subcontracting
purchase requisition always needs twice the quantity of unserviceables to create the
required quantity of serviceables (a quantity of 3 on the 6th May causes a dependent
demand of 6 at the 1st May).
Fig. 8.84 Relationship between serviceable product receipts and unserviceable product demand
in the DRP matrix
The time span between the dependent demand and product receipt is derived
from the location product as shown in Fig. 8.85.
Fig. 8.85 Master data for creation for internal repair orders
The replenishment lead time as illustrated in the DRP matrix above is deter-
mined in DRP planning based on scheduling scenarios as described in Sect. 8.3. For
repair purposes there are specific scenarios applied as shown in Fig. 8.86.
In case of internal repair via refurbishment the whole production lead time is
equivalent to the setting in the field “Time for internal KIT to Stock/Repair” of the
respective location product master. No processing times from the PDS are taken
into consideration.
In case of external repair the procurement lead time group ID “PLIFZ-C6,
SYNC, C6, SYNC_SGR, C8 (DRP/Deployment Matrix: External Refurbishment/
Kit-to-Stock)” is interpreted. Figure 8.86 shows e.g. that for determination of the
production lead time in this case the transportation lead time from the external
subcontractor location to the receiving location is subtracted from the overall
planned delivery time as it is defined in the location product master in the
procurement tab.
Additionally there are specific scheduling scenarios for determining repair based
freeze horizons for internal and external repair cases.
Fig. 8.86 Repair or Buy specific scheduling scenarios
Lot Size Determination and Rounding of Repair or Buy Planning Results

In case of repair planning rounding to pack sizes (as described in Sect. 2.1.6 for
non-repair purposes) is not supported. Rounding rather takes place based on lot
sizes as they are defined directly in the location product master in tab lot size in the
field rounding values. Also rounding profiles can be used which are defined
generally in customizing and assigned to the location products as shown in

Fig. 8.87.
Fig. 8.87 Rounding and lot size settings in location product
These rounding profiles should not be mixed up with the rounding profiles as
they are used in various SPP service profiles like DRP, deployment, EOQ/SIB and
inventory balancing, even though the naming is identical.
Rounding results can be adjusted by applying min or max lot sizes as they are
defined in the location product master in the tab lot size.
If the rounded value exceeds the currently available stock of serviceables in the
respective bucket (projected stock) then conflict rules need to be applied. These are
assigned to the DRP service profile as shown in Fig. 8.88.
Fig. 8.88 DRP service profile: settings of RoB-specific conflict rules at lot size rounding
The rule “Ignore Lot Size” says that in case that this conflicts appears the system
uses the smaller of either the unrounded net demand or the available quantity of
unserviceables. The alternative rule “Greatest Quantity according to lot sizes (
Maximum Quantity” applies the rounding to lot sizes in any case. It then uses the
greatest possible rounding value which is still smaller or equal to the available
quantity of unserviceables.
Source Determination
In case that the repair or buy logic is set to ‘repair’ the further setting of Type of
Repair determines which source type should be taken—either PDS for internal
repair purposes or the external procurement relationship for external repair.
If the repair or buy logic ‘repair or buy’ is chosen, then both sourcing types can
be used to fulfill the net demand depending on certain circumstances and setting. A
repair or buy decision based on cost is applied. Figure 8.89 shows the equation on
which the decision is based on and also shows where the containing variables are
derived from.
Fig. 8.89 Cost calculation as basis for repair or buy decision
NP represents the number of periods of delays which are caused by late

repair and are still acceptable based on cost comparison. NP is calculated as the
difference of the procurement cost CP and the repair cost CR divided by the cost
of late requirement coverage per product and period (CDCP). This logic can be
changed by customer-specific development using the BADI SAPAPO/
DRP_REPAIR_OR_BUY.
CR and CDCP are derived from the location product master (tab DRP and sub tab
Kit to Stock/Repair or Buy). The procurement costs are defined in the location
product master in tab procurement.
The result of this planning decision can also be mixed procurement. As soon as
the potential late fulfillment by repair becomes too expensive the system changes to
external procurement.
Horizons and Stability Rules

A specific planning horizon for Kit to Stock/Repair can be defined in the location
product master. After the end of this horizon the “normal” DRP procurement logic
is applied. In contrast to that there is the possibility to define a no-repair horizon.
This horizon is determined via the procurement lead time plus a buffer in days
(as defined in the location product master).
Stability rules as described in Sect. 8.5 are not applied for repair or buy planning.
The quantities to be expedited and de-expedited in order to comply with the
stability rules are only calculated but not applied—the system will not change the
existing orders.
Excess Stock of Unserviceable in Supersession and FFF-Classes

At the end of the actual replenishment planning, the DRP planning logic checks
whether the respective location product planned is part of an active supersession
chain (i.e. successor product planning start is not in the future). If this is the case and
if repair or buy logic is applied for the successor in the supersession chain then an
excess stock of the predecessor is determined. This excess stock is forwarded to the
successor via a substitution order. A restriction is that the supersession must be a
fully interchangeable 1:1 supersession.
Display and Manual Change of Planning Result

All the relevant orders resulting from repair or buy planning—i.e. also planned
orders and refurbishment orders—can be displayed and changed in the Schedule
Maintenance Board for External Procurement (transaction /SAPAPO/SPPDRPSB).
Figure 8.90 shows that these orders can be created manually as well.
Fig. 8.90 Schedule maintenance board for external procurement displaying planned orders for
repair
8.10 Kit to Stock Planning
8.10.1 Overview
Often different service parts belong technically to each other or several service
parts should be handled together due to sales and marketing reasons. These kits
require special consideration by planning. A kit has its own product number and a
bill of material that lists the individual service parts.
Prerequisites
In SPP the prerequisite above all is to have a production data structure (PDS)
available of usage type PP/DS (which is the production planning module) as shown
in Fig. 8.91.
Fig. 8.91 Production data structure (PDS) of a kit
8.10 Kit to Stock Planning 235
The decisive information for kitting is which are the input components and what
quantity of them is needed in order to build a certain quantity of the kit.
The function of kit planning is switched on in the location product master of the
kit, as shown in Fig. 8.92.
Fig. 8.92 Location product master: setting of alternative kit to stock planning options
Similar to repair planning there are two options of kit planning available, “Kit to
Stock Only” and “Kit to Stock or Buy”. In the latter option DRP fulfills covers the
remainder of the demands (what could not be fulfilled by in-house manufacturing of
the kits) with regular external procurement.
Further specifications regarding the type of kitting are made via the parameter
‘Type of KtS/Repair’ as shown in Fig. 8.93.
Fig. 8.93 Alternative types of kit to stock planning
It can be chosen whether the kitting should be made exclusively in-house or

externally at a subcontractor. When applying the in-house kitting, planned orders
would be created as planning result. Applying the external kitting, subcontracting
purchase requisition would be created as planning result by utilizing the PP/DS
scenario ‘subcontracting without source location’ (see Dickersbach . . ..). Alterna-
tively it can be selected that both are possible at the same time but with preference
to either external or in-house kitting. This means that DRP planning would always
choose the preferred KtS type, i.e. if “Internal Preferred” is set then planned orders
would be created and never subcontracting purchase requisitions instead. But
manually this could be overruled by creating subcontracting purchase requisitions
in the schedule maintenance planning board (transaction/SAPAPO/SPPDRPSB).
Kit to Stock planning can be applied with both DRP planning modes—period-
based and reorder point-based.
8.10.2 Kit to Stock Planning Logic and Parameters (Determinants)
Basically the kit planning logic is very similar to the repair planning logic. Many
features are identical and in the following only the differences and features which
are especially typical for kitting are explained.
Horizons and Shut Down Period

There are four different horizons that are relevant and influence the kit planning
process:
– planning horizon in the product-specific transportation lane

– planning horizon in the location product master
– no repair horizon
– kit to stock shut down period
These horizons are explained in the following.

The planning horizon is defined in the product-specific transportation lane—as
shown in Fig. 8.94—and determines the number of days from “now” into the future
the kit planning will be executed in case external kitting is chosen,
i.e. subcontracting purchase requisitions would be created as receipt elements.
Fig. 8.94 Planning horizon

for external kitting planning
In case of internal kitting the planning horizon in the location product master is
relevant as shown in Fig. 8.95.
Fig. 8.95 Planning horizon for internal kitting planning
If nevertheless within these planning horizons some restrictions should be

modelled then a horizon for no kitting and a period for shut down can be defined.
The no repair horizon defines working days in which kitting orders may not be
generated. This horizon results from the buffer defined in the location product
specific field as shown in Fig. 8.96 plus the procurement lead time for either
planned orders or subcontracting purchase requisitions.
Fig. 8.96 Buffer hours as input for the definition of no repair horizon
Furthermore a kit to stock shut down period can be specified for the location
product of a kit. For that a profile of the kit to stock shut down period needs to be
defined upfront as separate master data. This profile does not differ from supplier
shut down profile but is defined with transaction /SAPAPO/SPP_KSD. How the
profile is structured and its effects is described in detail in Sect. 8.7.3. In this respect
Fig. 8.97 shows how the quantity of aggregated demand which is needs to be pulled
forward in case that shut down is determined.
After the scheduling of a kitting order it is checked if the order overlaps with the
kit-to-stock shutdown period. Overlap means that at least the end or the start of the
kitting order must lie within shutdown period, Fig. 8.97.
Fig. 8.97 Determination of relevant demands in KtS shut down period
In case of kit-to-stock or buy, the kitting order overlapping a shutdown is not

created and the unrounded net demand isn’t reduced by the kitting logic. This
means DRP will try to cover the demand by a normal procurement.
In case of kit-to-stock only, the algorithm aggregates the net demands of all
periods which may be covered by a kitting order falling into the shutdown. The last
period to be considered is the end of the shutdown plus the processing time of a
kitting order. The aggregated demand is pulled forward and distributed to period
before the start of the shutdown period according to the logic as described in
Sect. 8.7.3. When the DRP run has already created a kitting order in the period
where the demand is pulled to, then the pulled demand is added to this order.
Otherwise a new kitting order is created. In both cases the order quantity is rounded.
The following special cases have to be taken care of:
– If the pulling forward happens to another shutdown period, then it is pulled again
according to the second shutdown.
– If the pulling forward happens into a horizon in that no kitting orders are created,
the system reacts similarly as for the freeze horizon for normal supplier shut
down, means nothing can be pulled into this horizon. Instead the demand would
be pulled to the first period without a shutdown after this horizon. If there is no
period without a shutdown before the period the demand is pulled from, then
nothing is pulled.
After pulling the demand the projected stock is recalculated starting at the first
period a quantity is pulled to.
Kit or Buy Decision

Unlike in repair planning, in kit planning the decision between the alternatives
kitting or buying is not made based on costs.
In the case of “Kit or Buy” in any case kitting is the procurement alternative of
first choice. But as soon as the demand is in one of the restricted horizons—freeze
horizon or KtS shut down period—sourcing is changed to regular external procure-
ment. In case of an existing shut down period this applies to all demands whose
potential kitting order would overlap with the shutdown period as described.
In case of using KtS only regular procurement is not possible at all as fallback. If
nevertheless demands exist in the shutdown periods then the aggregated quantity is
pulled forward. If demand exists in the period where no kitting is allowed then the
demand is left unfulfilled and rather an alert is generated (alert type 7897).
Scheduling and rounding for planned orders and subcontracting purchase
requisitions are done according to same logic as in repair planning.
Result and Analysis of KtS Planning

The planning situation of kits can be displayed and analyzed in either the DRP
Matrix or the external procurement—schedule maintenance board. Unlike in repair
planning the appearance of the DRP Matrix does not change compared to regular
DRP planning. The relevant key figure is shown in Fig. 8.98. No matter whether the
receipt element is a subcontracting purchase requisition or a planned order, all are
aggregated in the key figure Product Rcpt (Kit-to-Stk, Not Froz). All planned
receipt elements and all manufacturing orders as well as all subcontracting purchase
orders are aggregated in the key figure Product Rcpt (Kit-to-Stk, Not Froz). All
dependent requirements of any of these orders are aggregated in the key figure
Dependent Demand.
Fig. 8.98 Example of kit to stock product receipt in DRP matrix and external procurement
schedule line maintenance board
In the lower section of Fig. 8.98 the subcontracting purchase requisition with its
receipt quantity of 260 and its dependent demand can be seen at one glance in an
overview. Here this order could also be changed or deleted manually as well as
totally new ones could be created—either subcontracting purchase requisitions or
planned orders.
8.11 Reorder Point-Based Planning
Overview
There are two planning modes in DRP available. The period-based planning has been
explained so far in the chapters above. As an alternative there is the reorder point-based
planning (ROP-based planning) which is less complex to configure and to apply. It is
based more on static figures, i.e. it does not focus on future forecast in a time-phased
manner as period-based planning does. It rather compares a reorder point level against
current inventory and planned receipts. Therefore it is appropriate to be applied for
products for which forecast is hard to determine or simply not necessary. These could
be products with little turnover due to the fact they are slow movers generally or
because they are newly launched with no reliable figures yet like demand history.
8.11 Reorder Point-Based Planning 241
Determination of Planning Mode

The planning mode is controlled by settings in the location product master data in
the DRP tab and there in the sub tab “General”. As seen in Fig. 8.99, there are two
alternatives—Period-Based and Reorder-Point-Based.
Fig. 8.99 Location product master: setting of planning mode
This parameter can be set manually—either individually or via mass mainte-

nance. It can also be determined by a PSM planning service and automatically set
for all location products selected for this planning service. The corresponding
service profile is accessed via transaction S_A7P_41000198, Fig. 8.100.
Fig. 8.100 Service profile for automatic determination of DRP planning mode
In this service profile an ID for general data of a forecast profile needs to be

referenced, in which among others the time series for historical data is specified.
The second field (Historical Periods) specifies how many periods of the historical
demand should be considered during planning. The algorithm identifies the number
of historical sales order line items in this horizon. This is used within the BAdI
‘Determine DRP Planning Mode’ (/SAPAPO/DRP_PLANNING_MODE)—which
is delivered by SAP with already active coding and logic—for determining the
planning mode by comparing it with a figure (Upper Limit for Reorder-Point-Based
Planning) that is specified in customizing via the path Advanced Planning and
Optimization ! Service Parts Planning ! Distribution Requirements Planning
(DRP) ! Determination of DRP Planning Mode ! Make Settings for BAdI for
DRP Planning Mode, Fig. 8.101.
Fig. 8.101 Setting of upper limit of sales order items for reorder point planning mode
If the number of sales order line items for the time period in the past that are
defined in the service profile for DRP planning mode is greater than or less than the
upper limit defined here, the system sets the DRP planning mode to period-based. It
the number of line times less than the system set the planning mode to reorder point
based.
Running this planning service can be modelled as recurring event if the demand
pattern of the respective product is volatile or if it a product whose turnover is rising
sharply. Then the trigger SPP_FCST_CHG_PLNMODE can be used. The prereq-
uisite for setting this trigger is the activation of the parameter “Trigger Determina-
tion of DRP Planning Mode”, set in the location product master in the DRP tab as
shown in Fig. 8.99. The trigger is set for the planning service SPP_DRP_PLAN-
NING_MODE as soon as a new forecast for the respective location product is
created and finally approved.
Determination of Available Quantity in ROP Planning

Once the ROP planning mode is chosen, a specific logic for determination of the
available quantity is applied, which later is compared with the reorder point level in
order to find out whether there is a need for replenishment. Figure 8.102 shows in
the DRP matrix the key figures which contribute to the determination of the
available quantity. On one hand there are demand elements. The dependent demand
is derived from either planned orders (e.g. for the purposes of repair or kit to stock
planning) or dependent demand derived from subcontracting purchase orders
(in case of external repair or external kitting). Any kind of substitution demand is
also taken into consideration.
Fig. 8.102 DRP matrix: key figures that determine the available quantity in ROP planning
On the other hand there are stock and receipt figures, which contribute as
positive figures to the available quantity balance. Next to the initial warehouse
stock there are confirmed distribution receipts from within the BOD (stock transfer
orders) as well as fixed distribution receipts from suppliers (scheduling agreement
schedule line or fixed requisition or purchase orders), substitution receipts from
e.g. 1:1 supersession in case the product is the successor in an active supersession
chain or if it is part of a FFF-class.
Whether all or only parts of the supplier receipt should be considered is deter-
mined in the DRP service profile. Figure 8.103 shows that this is specified by
choosing the relevant horizon in which the receipt elements should be taken into
account. Either the whole horizon can be chosen or only the replenishment lead
time (which is equivalent to the limited freeze horizon).
Fig. 8.103 DRP service profile: setting for determination of available quantity (supplier receipts)
The same specification can also be made for the demand elements “Dependent
Demand” and “FFF Substitution Demand”, Fig. 8.104.
Fig. 8.104 DRP Service profile: setting for determination of available quantity (dependent and
substitution demands)
Figure 8.105 shows how the available quantity is determined considering the
horizon settings in the DRP service profile.
Fig. 8.105 ROP Planning: determination of available quantity considering horizons
In this case the assumption is that for the supplier receipt, for the dependent
demand and for the FFF substitution demand the relevant horizon is set to “replen-
ishment lead time”. Accordingly the available quantity is calculated adding the
various receipt elements existing over the lead time to the initial warehouse stock
and subtracting the substitution demands and dependent demands. The last distri-
bution receipt from supplier is ignored since it is outside the limited freeze horizon.
Net Requirement Calculation of Reorder Point Based Planning

Basically the reorder point based planning does not consider future expected
demand elements as the period-based planning does. No regular forecast
demand or fixed demand elements are taken into consideration for the net
requirement calculation unless the standard logic is changed via BAdI ‘Determine
Additional Quantities for Reorder-Point-Based Planning’ (/SAPAPO/
ROP_ADDITIONAL_QTYS). Also no safety stock demand nor any real customer
demands like future dated orders are considered.
Figure 8.105 shows that additionally to the reorder point level—which could
represent fictitiously e.g. safety stock or/and any demand over lead time—real
distribution demand (either planned or confirmed) are considered for determination
the gross demand.
Finally the net requirements is the difference between the gross demand and the
available quantity as it is determined shown in Fig. 8.105, i.e. the unrounded net
demand represents the difference between the available quantity and the effective
reorder point, Fig. 8.106. On the basis of that replenishment is prepared and triggered.
Fig. 8.106 ROP Planning: determination of net demand
The reorder point is defined in the location product master in DRP tab and there
in the sub-tab “ROP Planning” (Fig. 8.107).
Fig. 8.107 ROP Planning: setting of reorder point in location product master
The determined unrounded net demand will be rounded by either applying the
function “Rounding to Maximum Stock”—if it is activated in the same tab in the
location product master. Otherwise the regular rounding to EOQ /EOQ-periods or
to pack sizes is applied as described the Sect. 8.2.
Planning Result, BOD Structure and DRP Matrix

The result of the ROP planning for a particular product is a procurement plan
consisting of receipt elements across all locations which are members of the BOD.
For one particular location product the result of a particular run can never be more
than one receipt order line at a time. The potential receipt elements are planned
stock transfers among the locations within a BOD. Furthermore the receipt
elements are procurement proposals as purchase order item schedule lines or
scheduling agreement schedule lines. Also planned orders and subcontracting
purchase requisition can be the resulting receipt elements as soon as the ROP
planning is combined with repair or buy planning or kit-to-stock planning.
If a parent location is set to ROP planning then all its child locations need to be
set on ROP planning, too. This is a hard constraint, which otherwise causes an error
in the planning due to BOD inconsistencies. Whereas a ROP-based planned child
location can have a parent location with period-based planning settings.
Locations of the same level can have different planning modes as long as the
parent is period-based as is illustrated in Fig. 8.108.
Fig. 8.108 Planning mode: consistent setting across all BOD-locations
Figure 8.109 shows an example where all the locations involved are set to
ROP-based planning. The DRP matrix appearance changes as soon as the planning
mode is set to ROP-based planning, especially the number of key figures of the relevant
Fig. 8.109 ROP Planning: example on cross-location planning results and key figures
demand elements are very much limited. Only ‘Planned Distribution Demands’,
‘Conformed Distribution Demands’, ‘Dependent Demands’ and ‘Substitution demands’
are shown and would be considered in DRP planning. In contrast to that no forecast, no
customer orders and no fixed demands are displayed since these are not considered.
It shows that that rounded net demands are rolled up from the child location
SPG1 (v), SPG2, and SPP1 to the parent location SPG1, which is summed as
planned distribution demand of 91. This figure plus the reorder point is calculated
as the effective reorder point level. This is compared at location SPG1 with the sum
of the initial warehouse, the in transit and the distribution receipt, which are
aggregated 100. The result of the DRP planning in SPG1 is seen in the key figure
‘Rounded Net Demand (Constrained)’, which is 1. Since there is no rounding
applied here, the system replenishes only up to the reorder point. No projected
stock is displayed here since no time-phased planning takes place.
The planner has to take up a different personal view in order to be fully able to
interpret the result. This view can be taken by using the external procurement—
delivery schedule maintenance board. There the existing orders can be analyzed
including the planned orders, purchase requisitions or schedule lines that were
generated by the DRP run. If within the BOD any location product with reorder-
point-based planning mode exists then an additional column in the header section
appear as shown in Fig. 8.110.
Fig. 8.110 External procurement—delivery schedule maintenance board: ROP-indicator
Restrictions/Differences to the Period-Based Planning Mode

For reorder-point-based planning the product group procurement function is appli-
cable. Another difference is that a ROP-planned location product in an existing
active supersession chain—no matter if what type (1:1 etc.)—is ignored in a
situation of excess. Accordingly no substitution orders would ever be generated
by DRP in this planning mode.
Similarly the substitution of remanufactured products is not supported for
ROP-planned location products. If substitution of remanufactured products is
applied on an entry location that has an ROP child location, then the distribution
of substitution receipts does not consider the distribution demand at the ROP child
location.
Procurement Approval
9
The purpose of the procurement approval process is to prevent an unusually high

procurement—quantity or value—without notice. The procurement approval pro-
cess is subsequent to the DRP run, Fig. 9.1.
DRP
Procurement
Proposal
Procurement
DRP Approval Approval
Mass Approval
Approval Rules
Yes
Maximum Values Exception? Interactive Approval
No
Yes
Sched.Agr.? Release Creation
No
Purchase
Release
Requisition
Procurement
Execution
Fig. 9.1 Procurement approval process overview

250 9 Procurement Approval
Releases are only created after the procurement is approved. Basis for the
procurement approval are the approval rules and maximum values for some of
the rules. The procurement approval is followed by the procurement execution,
where the information is sent to the supplier via EDI or via SAP SNC™.
Procurement Order Types

Service parts planning assumes that procurement using scheduling agreements is
the common case. Alternatively it is possible to use purchase requisitions with
reference to a contract. The objects and the process steps for approval differ only
slightly (Table 9.1).
Table 9.1 Procurement order types

Procurement relationship with supplier Scheduling agreement Contract
Procurement relationship per service Scheduling agreement Contract item
part item
Planning result Delivery schedule Purchase
requirements
Single procurement element Schedule line Purchase requirement
Release creation Release n.a.
Purchase order creation n.a. Purchase order item
In the case that scheduling agreements are used, the approval is performed for
the delivery schedule—i.e. for all the schedule lines—of a scheduling agreement
item. If contracts are used, each purchase requisition is approved separately. In the
following we focus on the description of the procurement with scheduling
agreements.
Approval Steps and Status of the Scheduling Agreement Item

There are up to three different approval steps:
• the approval service (which is either integrated into the DRP service or a
separate service, see Sect. 8.8) checks whether any rules are violated and creates
alerts
• the mass approval allows to check the value (the total value and the difference to
the last DRP run) for a selection of products and to approve or reject the whole
selection
• the interactive approval is required for those scheduling agreement items which
contain schedule lines with alerts.
Note that always the complete delivery schedule is approved and not the individ-
ual schedule line. Depending on the compliance with the rules and the approval step,
the status of the scheduling agreement item changes. Figure 9.2 provides an over-
view about the scheduling agreement item statuses (SAI) and the approval steps.
9.1 Process Overview 251
DRP
No Approval Separate Approval

DRP Approval? DRP Approval
Integrated Approval
Yes
Rule Conform?
No
SAI Status SAI Status
Mass Approval Mass Approval
No
Approve? Approve?
Yes Yes
SAI Status Interactive Approval No
Approve?
(Schedule Board)
Yes
SAI Status SAI Status SAI Status
Release Creation
SAI Status
Fig. 9.2 Approval and status of scheduling agreement items
If a rule is violated an alert is created—this is visualised by the bell in the status.

The status of the scheduling agreement item is displayed in the schedule board with
the transaction /SAPAPO/SPPDRPSB, Fig. 9.3.
Fig. 9.3 Status of the scheduling agreement item in the schedule board
The setting for the DRP approval (integrated, separate or no approval) is done in
the DRP service profile, Fig. 9.4.
Fig. 9.4 DRP approval setting in the DRP service profile
If an integrated DRP approval is performed, the service profile for the DRP
approval has to be referenced from the DRP service profile.
9.2 Approval Rules
The approval rules check whether the procurement proposal by DRP is within the
defined limits. This determines the status of the procurement proposal—i.e. the
status of the scheduling agreement item or the purchase requisition. The assignment
of the alert type and whether the rule is active and used for the DRP result is defined
with the customising path APO ! Supply Chain Planning ! SPP ! DRP ! DRP
Approval ! Define DRP Approval Rules, Fig. 9.5.
Fig. 9.5 Approval rules
The violation of a rule triggers an alert. Some of the rules—namely /SAPAPO/

CL_RL_MAX_DELTA_VALUE, /SAPAPO/CL_RL_MAX_VALUE and
/SAPAPO/CL_RL_MAX_DMNDFREQ—are related to maximum values. These
values are defined in the maximum value profile with the transaction /SAPAPO/
DRPC_EP, Fig. 9.6.
9.3 Procurement Approval Service 253
Fig. 9.6 Profile for maximum values
The maximum value profile is assigned to the product master in the DRP view as
shown in Fig. 9.7.
Fig. 9.7 Assignment of the maximum value profile to the product master
Note that there is no default maximum value profile. Notes 925171 and 929169
provide additional information for the creation of own approval rules.
9.3 Procurement Approval Service
The procurement approval service profile is defined with the customising path
APO ! Supply Chain Planning ! SPP ! DRP ! DRP Approval ! Define Service
Profile for DRP Approval and contains the maximum procurement lead time,
Fig. 9.8.
Fig. 9.8 Service profile for procurement approval
The DRP approval service is SPP_DRP_APPROVAL and requires a location

product related process profile.
9.4 Mass Approval
The purpose of the mass approval is to gain an overview of the procurement value
for a group of products in order to avoid an unnoticed abnormal increase in the
ordered value. The selection of the products is possible by product name, product
group, supplier, BOD and others. The mass approval is performed with the transac-
tion /SAPAPO/SPPDRPAPPR, Fig. 9.9.
Fig. 9.9 Mass approval
From the entry screen it is possible to call SAP BI™ reports and to approve or
reject the procurement proposals for the selection. There are two reports to display
the entire DRP results and the biggest changes. Figure 9.10 shows the report for the
display of the DRP results.
9.4 Mass Approval 255
Fig. 9.10 SAP BI™ report for the DRP results
All newly created schedule lines and purchase requisitions are considered as
DRP result. Since DRP performs a regenerative planning (in contrast to net change
planning), all non-fixed receipts are considered here (i.e. purchase orders are
excluded).
The report offers various options for visualisation—from swapping the axes to
diagrams, Fig. 9.11.
Fig. 9.11 Diagrams within the DRP result-report
The prerequisite for the reporting is that the queries are defined in the global
setting for DRP approval (customising path APO ! Supply Chain
Planning ! SPP ! DRP ! DRP Approval ! Make General Settings for DRP
Approval Parameters), Fig. 9.12.
Fig. 9.12 General settings for DRP approval
9.5 Interactive Approval in the Schedule Board
The interactive approval of procurement proposals is performed in the schedule

board with the transaction /SAPAPO/SPPDRPSB, Fig. 9.13.
Fig. 9.13 Schedule board for interactive approval
Note that the whole delivery schedule is approved, not an individual schedule
line. It is possible though to create, change or delete schedule lines.
9.6 Release Creation 257
There are maximum limits for the individual approval. These limits are defined
per user with the customising path APO ! SPP ! DRP ! DRP Approval ! Define
Management Approval as shown in Fig. 9.14.
Fig. 9.14 Approval limits per user
9.6 Release Creation
The release creation for service parts planning is performed like for standard
procurement with scheduling agreements (see Dickersbach 2008). The only excep-
tion is that the status of the scheduling agreement item has to be ‘approved’ before
the releases are created. The transaction for release creation is /SAPAPO/
PWBSCH1 as shown in Fig. 9.15.
Fig. 9.15 Release creation
The release creation horizon of the release profile is overruled by the plan
submission horizon if the BAdI SMOD_MMPUR is implemented.
9.7 Procurement Execution
For the execution of the procurement the release is sent to the supplier. The
common method is to use EDI for large suppliers and suppliers with a well
developed IT landscape.
For small and medium suppliers it is however possible to apply SAP SNC™ in
order to integrate them into the planning environment for service parts management
with a comparatively low effort. In this case the release is sent as an IDOC from
SAP APO™ via SAP PI™—where it is converted to the XML format—to SAP
SNC™. In SAP SNC™ the supplier creates an advanced shipping notification
(ASN) which is sent via SAP PI™ to SAP ERP™ as an inbound delivery. In SAP
ERP™ a validation of the ASN is performed, where its plausibility is checked
(e.g. whether a scheduling agreement item for this product with the supplier exists).
After the validation an acknowledgement is sent back to SAP SNC™ and the
inbound delivery is sent to SAP EWM™ as an inbound delivery notification
(IDN). This inbound delivery notification can be activated in the background to
9.7 Procurement Execution 259
become an inbound delivery in SAP EWM™, and goods receipt can be posted.
Figure 9.16 shows the document flow for procurement execution.
Fig. 9.16 Process steps and document flow for procurement execution
Essential for the procurement execution process is that the supplier sends ASNs
to SAP ERP™.
Monitoring of the Release Transfer to SAP SNC™

The transfer of the release from SAP APO™ to SAP PI™ and from SAP PI™ to
SAP SNC™ is monitored in both systems (SAP PI™ for the transfer from SAP
APO™ to SAP PI™, SAP SNC™ for the transfer from SAP PI™ to SAP SNC™)
with the transaction SXMB_MONI.
Monitoring of the Release Message in SAP XI
© SAP AG
Message ID
Monitoring of the Release Message in SAP ICH is the same
© SAP AG
Fig. 9.17 Monitoring of the release message in SAP PI™ and SAP SNC™
Figure 9.17 shows the monitoring for a successful transfer—the message ID for a
release is the same in both systems. The same transaction is used in SAP SNC™ to
monitor the transfer of the message from SAP PI™ to SAP SNC™.
ASN Creation in SAP SNC™

The supplier for service parts selects the scheduling agreement items with their
releases using the menu path Release Process ! Release Overview Supplier as
shown in Fig. 9.18. The just-in-time (JIT) releases require the confirmation via
ASN, therefore these are selected (1) and the details displayed (2).
Select JIT Releases and

press ‘Details’ 1
© SAP AG
Fig. 9.18 Selection of the JIT-releases
In the next screen the schedule lines are displayed. The ASN is created by
selecting the schedule line and pressing the button ‘create ASN’, Fig. 9.19.
Fig. 9.19 Create ASN for schedule line
Fig. 9.20 Save and publish ASN
In the next screen the shipping date and the delivery date can be adjusted if they
differ from the dates in the schedule line. The supplier/external number for the ASN
is maintained in this screen as well. As the last step the ASN is saved and published
to SAP ERP™ as shown in Fig. 9.20.
ASN Validation in SAP ERP™

The ASN in SAP SNC™ corresponds to an inbound delivery in SAP ERP™. The
inbound delivery is displayed, changed and copied in SAP ERP™ with the transac-
tion VL60. The transaction VL33N for inbound deliveries can also be used for
display only. Figure 9.21 shows the inbound delivery that was transferred from SAP
SNC™. The field ‘external ID’ in the header data shows the ASN number defined in
SAP SNC™.
Fig. 9.21 Inbound delivery (SAP ERP™)
In order to use the transaction VL60 it is necessary to assign the user to a user
group with the customising transaction VL60P2. The user group is assigned with
the same transaction to the profile VL60ALL (the profile is defined with the
customising path Logistics Execution ! SPM ! Extended Inbound Delivery
Processing (SPM) ! UI Profiles ! Maintain Profile ! Assign Profile Modules to
UI Profile). It might also be necessary to activate the enhancements for service parts
management with the customising path Logistics Execution ! SPM ! Activate
Enhancements for Service Parts Management (SPM) ! Activate Enhancements
for Service Parts Management.
ASN Acknowledgement
After the validation the order number of the SAP ERP™ inbound delivery is sent as
an acknowledgement to SAP SNC™. With the menu path ASN Maintenan-
ce ! ASN Overview Supplier the order number of the SAP ERP™ inbound delivery
is displayed as ‘internal ASN number’, Fig. 9.22.
Fig. 9.22 ASN acknowledgement—SAP ERP™ order number in SAP SNC™
Goods Receipt
After the validation the inbound delivery is sent to SAP EWM™ as an inbound
delivery notification. This inbound delivery notification is activated in the back-
ground to become an inbound delivery as well. With the transaction /SCWM/PRDI
goods receipt in SAP EWM™ is performed, Fig. 9.23. Before posting the goods
receipt in SAP EWM™, first the inbound delivery has to be selected and changed
(1), then it has to be posted that the delivery is ‘in yard’ (2) and it is unloaded
(‘unload’, 3) before goods receipt can be posted (4).
1 2 3 4
© SAP AG
© SAP AG
Fig. 9.23 Goods receipt in SAP EWM™
Table 9.2 provides an overview about the inbound delivery status depending on
the postings.
Table 9.2 Inbound delivery status

Status Goods Warehouse
posting Transit status Unloading receipt Put away activity
None In transit Not started Not started Not Not started
started
In yard Registered in Not started Not started Not Not started
yard started
Unload Registered in Completed Not started Not Partially
yard started completed
Goods Registered in Completed Completed Not Partially
receipt yard started completed
The goods receipt is finally published to SAP ERP™—usually in the

background.
For test purposes it is also possible to post stock from a flat file using the
transaction /SCWM/ISU.
Deployment
10
Deployment is concerned with the distribution of the goods along the BOD. While
DRP calculates the requirements along the BOD in order to determine the procure-
ment quantity at the entry location, deployment creates stock transfer orders from
each parent location to its child locations. Figure 10.1 shows an overview of the
process.
EOQ & Safety

Stock Planning
Confirmed/Fixed Fixed Conf. Stock

Safety Stock Forecast Inventory
Receipt Requirement Transfer Rqmt.
Deployment Order Due List

Deployment
Indicator
Rounding
Profile Stock Transfer
Order
Stock Transfer
Execution
Fig. 10.1 Deployment process overview
To be precise, deployment creates a stock transfer with categories EF (Deploy-

ment: purchase requisition) and EG (Deployment: Release for stock transfer requi-
sition). The ‘real’ stock transfer order is created in SAP ERP and only available in
SPP after transfer. For ease of reading we will nevertheless refer to the result of the
deployment as stock transfer order.

266 10 Deployment
The functionality for deployment in service parts planning differs in several

points from deployment as in Supply Network Planning in SAP APO™. Two major
differences are that the stock transfer order is always due today, i.e. there are no
stock transfer orders created for future dates, and that the type of the demand
(e.g. forecast or sales order) is grouped into tiers and is taken into consideration
for the determination of the deployment quantities. Another feature is that deploy-
ment does not rely on the results of a previous DRP run but recalculates the
requirements in the part of the BOD using the DRP algorithms. Therefore it is
not necessary for deployment that planned stock transfer requirements exist.
Deployment is performed from the parent location to its direct child locations. If
the BOD contains more than two levels, multiple deployment runs are required. For
each parent location a deployment run is required to replenish the inventory from
the entry location to the last customer facing location. Figure 10.2 shows this using
the BOD from Fig. 2.2 as an example.
Stuttgart
Deployment Run
Virtual Child
Location
Lyon Lille Frankfurt Stuttgart
Deployment Run Deployment Run

Virtual Child
Location
London Lille Köln Berlin
Fig. 10.2 Deployment runs to replenish the entire BOD
In this case three deployment runs are required. Note that no stock transfer is
created to the virtual child locations.
Figure 10.3 shows the flow chart for deployment. Depending whether the
available quantity for deployment (ATD, available-to-deploy) at the parent location
exceeds the demand of the child locations over the lead time or not, deployment
proceeds in two different ways.
If the available quantity is above the demand over the lead time, a fair share
calculation is performed to determine the deployment quantities for each location.
These quantities might be reduced if they exceed the accepted storage quantity of the
target location. The accepted storage quantity is represented by the time supply limit
(TSL). As a last step rounding is performed according to the standard sequence rules.
In the other case the parent location does not have enough quantity available to
cover the children’s requirements over the lead time. The demand over the lead
time at the child location is an overdue demand at the parent location. For this
overdue demand tier processing is performed, where the demand elements are
sorted according to their priority tiers. In the subsequent step the fair share calcula-
tion is applied to the priority tiers in order to determine the deployment quantities,
and rounding is performed according to the sequence rules for the tiers.
10.2 Pull Deployment and Push Deployment 267
Available Qty. ³ No
Demand Over
Lead Time?
Tier Processing
Yes
Fair Share Fair Share

for Time Periods for Tiers
Apply
Time Supply Limit
Std. Sequence Tier Sequence

Rounding
Rules Rules
Create Stock
Transfer
Fig. 10.3 Flow chart for deployment
10.2 Pull Deployment and Push Deployment
10.2.1 Difference Between Pull and Push Deployment
There are two different ways to perform deployment in service parts planning, these
are pull deployment and push deployment. Pull deployment is performed by regular
deployment planning runs and is triggered by a need at the child location—similar
like the deployment in Supply Network Planning in SAP APO™. In contrast to this,
push deployment is triggered by a goods receipt at the parent location, and the
goods are not stored into the bins in the warehouse but sent to the child locations.
Push deployment is intended for fast moving parts and has the advantage that it
leads to a faster replenishment along the BOD.
Deployment Lead Time

The lead time for deployment (and for DRP and inventory planning as well) differs
depending on the use of pull or push deployment, because push deployment is
usually faster. Therefore different scheduling scenarios are used for these two
deployment strategies. The scheduling scenarios are described in Sect. 8.3.
268 10 Deployment
Deployment Indicator
The deployment indicator is a setting in the ‘SPP deployment’-view of the product
master and defines whether pull or push deployment lead times are used for
planning, Fig. 10.4. The deployment indicator of the product at the target location
is the one which is used.
Fig. 10.4 Deployment indicator in the product master
There are three values for the deployment indicator: Plan to push, plan to pull
and pull only. Table 10.1 describes the implication of these values for the deploy-
ment strategy and the lead time for planning.
Table 10.1 Deployment indicator

Deployment indicator Deployment strategy Lead time for planning
Plan to push Push or pull Push
Plan to pull Push or pull Pull
Pull only Pull Pull
The lead times for pull or push deployment are used for planning purposes.
The first line in the table represents e.g. a product, which is potentially deployed
alternately by push deployment and then by pull deployment. This can lead to the
following situation: Using push deployment the planning service considers only target
locations (and their respective net demand), if they are assigned with Plan-to-Push or
Plan-to Pull indicators, i.e. the whole available quantity is deployed to these location.
Pull-Only locations are not taken into consideration, even though they could have
demand potentially, too. In the following pull deployment planning run for the same
product—and assuming that the push lead time is shorter than the pull lead time—,
this could lead to a supply shortage. In order to overcome this a parameter in the
deployment service profile can be set, which forces the system to consider “pull-only”
location’s demand also in push deployment nevertheless, Fig. 10.5.
Fig. 10.5 Flag in the deployment service profile for consideration of pull only locations in push
deployment
Pull deployment creates stock transfers for all child locations which have an
actual demand over lead time—independent of the deployment indicator. Push
deployment might create stock transfers to child locations which are ‘plan to
push’ or ‘plan to pull’. For the scheduling of the stock transfer the lead times of
the effective deployment mode is used—i.e. pull lead times if created by pull
deployment and push lead times if created by push deployment.
Except for the difference in determining the available quantity for deployment
(which is only the remainder of the goods receipt quantity after EDQA in the case of
push deployment), the different lead times and the different triggers, pull and push
deployment behave the same.
The deployment indicator is determined by the planning service for EOQ and
safety stock (see Sect. 6.4) based on the rules that are defined with the transaction
/SAPAPO/DEPL_IND_DEF, Fig. 10.6.
Rule
Product Group (Deployment)
© SAP AG
© SAP AG
Product Product
Group Type Group
© SAP AG
Rule Assignment
© SAP AG
Fig. 10.6 Rules for deployment indicator determination
The rule determines either based on the EOQ, the product group (as shown in
Fig. 10.6) or the forecast the deployment indicator. The fallback indicator is defined
at the bottom of the rule—in this case ‘planned: pull’. The rule is assigned per
location, per product or per location product in the same transaction.
270 10 Deployment
10.2.2 Event Driven Quantity Assignment
Push deployment is triggered by goods receipt. This trigger is modelled using the
functionality for event driven quantity assignment (EDQA). EDQA is used for
other purposes as well, e.g. the change of ATP categories. The configuration of
EDQA is done with the transaction /SAPAPO/EDQA_PD as Fig. 10.7 shows.
Activity
© SAP AG
© SAP AG
Process Category
Event for Process Category Profile for Process Category
Order Due List Condition Profile Category Profile
© SAP AG
Fig. 10.7 Structure of the EDQA configuration
Process Category
Push deployment is configured in the process category—or to be more precise, in
the ‘event for process category’ which contains settings defined with the process
category as key. The event for the process category contains the event itself—in this
case EDQA—and the order due list (ODL).
The process category contains as well a condition profile and—optionally—a
category profile. The condition profile restricts the process category by fields from a
field catalogue—e.g. material and plant. Push deployment is only performed for
goods receipts which match this selection.
The category profile is used in order to change ATP categories. In the SPM
solution the stock category is changed depending on the storage location—whether
it is stored in the warehouse or still on a receiving dock. The process category itself
is assigned to an activity—for push deployment to the activity ‘change stock data’.
These activities are pre-defined.
Order Due List

Before deploying the receipt quantity it is checked whether there are customer
orders with backlog. In this case the quantity is used to cover the open orders first.
To determine these orders the order due list (ODL) is used.
The ODL processing is similar to the backorder processing (BOP) but leaner. It
is based on the order due list where order priorities can be adjusted interactively.
The ODL is defined with the customizing path APO ! Global
ATP ! EDQA ! Quantity Assignment to Order Due List ! Configure Order Due
List, Fig. 10.8.
Fig. 10.8 Order due list
Like backorder processing, the order due list requires a filter type and a sort
profile. When defining the fields for the filter type and the sort profile for the ODL,
the field catalogue for ODL and not for BOP should be used, Fig. 10.9.
Field Catalogue for BOP
© SAP AG
Field Catalogue for ODL

XOR
© SAP AG
© SAP AG
Fig. 10.9 Different field catalogues for BOP and ODL
A technical prerequisite for EDQA is that the event linkage (transaction

/SAPAPO/EDQA_EC) is active, Fig. 10.10.
272 10 Deployment
Fig. 10.10 Event linkage
Push deployment requires two functions: the deployment itself and the EDQA.
EDQA creates a log of its own which is displayed with the transaction /SAPAPO/
EDQA as Fig. 10.11 shows.
Fig. 10.11 Log for EDQA
10.3 Available Quantity and Demands for Deployment
The basis for deployment is the determination of the available quantity and the
requirements. Deployment does not rely on the results of previous planning pro-
cesses but does both by itself.
Available Quantity
When push deployment is used, the available quantity for deployment is the
remainder of the goods receipt quantity which is not assigned to the order due list
by EDQA. For pull deployment however it is necessary to determine the available
quantity based on the inventory and the confirmed customer orders. For this a
product availability check is performed using the ATP group of the location product
10.3 Available Quantity and Demands for Deployment 273
and the business event defined in the general settings for deployment (transaction
/SAPAPO/DEPLCUST).
If no business event is maintained, no ATP check is performed but the initial
stock as displayed in the DRP matrix is used. Note 902556 provides hints about the
definition of the scope of check.
In any case—no matter whether applying the method according to ATP or
according to the initial stock—the requirements for previously created stock
transfers are already subtracted upfront from the initial available quantity during
the deployment internal net requirements calculation. The reason for that is that
they are already assigned to approved STO’s.
Deployment Matrix
The deployment matrix contains the demands for deployment and is calculated by
deployment based on the DRP matrices. The deployment matrix differs slightly
from the DRP matrix: the demands are cumulated, the available quantity is deter-
mined via ATP check and—this is probably the biggest difference—the demand of
some of the child locations is netted with the parent location. This is the case if one
of the following conditions applies:
• the location is a virtual child location

• the location does not have a compatible deployment indicator, e.g. if the
deployment indicator is set to ‘pull only’ during push deployment
• the deployment indicator is set to ‘plan to pull’ or ‘pull only’ and the location
does not have an actual demand over the lead time.
This netting makes the result sometimes a little bit hard to understand.
The relevant parts of the deployment matrix is displayed in the deployment
simulation UI (see Sect. 10.8) and in the planning log UI.
Deployment Flexibility in the Supply Chain

As the real demand at the child locations might differ from the forecasted demand, a
premature deployment to the child locations reduces the flexibility within the
supply chain to supply the child locations according to their future needs. An
example is shown in Fig. 10.12, where deployment distributes the all of the parent
location’s inventory—in this example 800 pieces—evenly to both child locations A
and B. Because the real customer demand differs from the forecast, 3 days later it is
obvious that child B will run out of stock while child A still has excess stock.
274 10 Deployment
Today Today + 3 Days
100 100 100 100 Forecast 100 100 100 100 100 80 60 100 Sales 100 130 150 100
Forecast Forecast Sales Forecast Sales Forecast
Child A Child B Child A Child B
400 400 160 20
Parent Parent
0 0
Fig. 10.12 Deployment of the complete stock at the parent location
Since there is no more stock left at the parent, a more costly lateral transfer from
A to B is required. This situation can be avoided by retaining some stock at the
parent. Figure 10.13 shows the same initial situation as in Fig. 10.12, but some stock
is still kept at the parent location.
Today Today + 2 Days
100 100 100 100 100 100 100 100 100 80 100 100 100 130 100 100
Forecast Forecast Sales Forecast Sales Forecast
Child A Child B Child A Child B
300 300 120 70
Parent Parent
200 200
Fig. 10.13 Deployment with retaining stock at the parent location
Because stock is kept at the parent location, covering the difference between
forecast and actual sales is possible with a new deployment from the parent
location. There are two factors in favor of retaining inventory at the parent location:
One is to limit the portion of the available deployment quantity at the parent
location that is used to supply the child locations, and the other is to limit the
supply quantity to the child location. The first is modelled by future due receipts and
the second by the time supply limit.
Future Due Receipts

When the deployment quantities are calculated, the demand of all child locations
and the safety stock of the parent location are taken into consideration. However,
stock transfer orders are not created for all locations, e.g.
10.3 Available Quantity and Demands for Deployment 275
• if the location is a virtual child location

• if the location does not have a compatible deployment indicator, e.g. if the
deployment indicator is set to ‘pull only’ during push deployment
• if the deployment indicator is set to ‘plan to pull’ or ‘pull only’ and the location
does not have an actual demand over the lead time
In this case the demand of these locations is netted with the parent location.
Whether and how far future receipts are included into this netting depends on the
parameter ‘horizon for expected receipts’ in the ‘product’-view of the transporta-
tion lane, Fig. 10.14.
Fig. 10.14 Horizon for

expected receipts in the
transportation lane
If nothing is maintained, no future receipts are considered for the netting at the
location. The consequence of this ‘conservative’ setting is that less stock is avail-
able for deployment to the child locations.
Time Supply Limit for Period-Based Planned Products

The time supply limit (TSL) determines how much stock is acceptable at the target
location (from a deployment perspective). This value depends on the demand of the
target location and is calculated as described in formula (10.1).
TSL ¼ min fGRLTþAGD þ SSLTþAGD þ EOQLTþAGD ; GRMGD g ð10:1Þ
GRLT+AGD denotes the gross demand over lead time plus the days defined in the
parameter ‘additional gross demand’, SSLT+AGD the safety stock and EOQLT+AGD
the economic order quantity for the same time horizon. If the safety stock and the
EOQ are time dependent, the highest values within the time period is used. GRMGD
276 10 Deployment
is the gross requirement for the number of days as defined in the parameter
‘maximum gross demand’. The parameters ‘additional gross demand’ and ‘maxi-
mum gross demand’ are defined in the service profile for deployment, in the
location product and in the TSL parameter table. Figure 10.15 describes how the
relevant setting is determined.
Parameter ‘EOQ
No
Period for TSL Parameter
Determination’
is Set?
Yes
TSL Parameter Yes

TSL Parameter No
in Location Product
Table Maintained?
Maintained?
Yes No
Matching Entry in No
TSL Parameter Table?
Yes
TSL Parameters from AGD = 0; MGD from TSL Parameters from

TSL Parameter Table Service Profile Location Product
Fig. 10.15 Determination of the TSL parameters
Figure 10.16 shows the parameter ‘EOQ period for TSL parameter determina-
tion’ and the TSL parameter ‘maximum gross demand’ in the service profile for
deployment (transaction /SAPAPO/DEPLSPRF).
Fig. 10.16 TSL Parameter in the service profile
10.4 Priority Tiers, Fair Share and Sequence Rules 277
The table for TSL parameters is maintained with the transaction /SAPAPO/
TSLPAR. Figure 10.17 shows the parameters ‘additional gross demand’ and ‘max-
imum gross demand’ in the product master of the child location.
Fig. 10.17 TSL Parameters in the product master
Assuming that sufficient stock is available, only the maximum deployable

quantity is sent to the child location. The maximum deployable quantity (MDQ)
is the difference to the time supply limit (TSL), i.e. the TSL minus the stock at the
child location and the stock in transit—unless the demand over lead time (DOLT)
exceeds the TSL, formula (10.2).
MDQ ¼ max fTSL StockChild Location In Transit; DOLTg ð10:2Þ
Time Supply Limit for Reorder-Point-Based Planned Products

In case the location product is planned with a planning mode “reorder-point-
planning”, the determination of the TSL follows a different logic.
The formula is as follows:
TSLROP ¼ MAX ½Reorder point; Maximum stock level þ EOQ:
EOQ is the economic order quantity. Reorder point and maximum stock level and
EOQ will be taken from the DRP matrix of the ROP location.
10.4 Priority Tiers, Fair Share and Sequence Rules
Different demands types are assigned to priority tiers in order to ensure that the
most important demands are covered first by deployment in case that the available
quantity for deployment is less than the demand over lead time. There are nine
different pre-defined tiers, and Table 10.2 lists an option how to define these. It is
however possible to define the priorities also differently. It is not mandatory to use
all tiers. If demand types are left out, they have the lowest priority below all other
tiers.
278 10 Deployment
Table 10.2 Option for definition of priority tiers

Priority Tier
1 Backorders
2 Prioritized fixed requirements
3 Demand over replenishment lead time: forecast, stock transfer requirements,
substitution requirements
4 Safety stock of the child location
5 Fixed requirements (non-prioritized)
6 Proportion of the parent’s safety stock at the child location
7 Safety stock of the parent location
8 Requirements for anticipated demand coverage
9 Additional demand due to rounding
Confirmed stock transfer orders reduce the available quantity for deployment
upfront and do not have to be defined as a priority tier.
The priority tiers are defined with the transaction /SAPAPO/TIERDEF, as
shown in Fig. 10.18. Since deployment is performed from the parent to its direct
children, the priority tiers apply also only to the demand types of the direct children.
Fig. 10.18 Priority tiers and sequence rules
In the same transaction sequence rules are defined and assigned to the tiers. The
purpose of the sequence rules is to define the sequence of locations in which
rounding of fair share quantities is performed. The standard sequence rules are
applied if the available quantity for deployment is higher than the demand over lead
time. In the other case the sequence rule is applied which is assigned to the tier
where fair share is performed.
Example Without Tier Processing

The following example helps to understand how deployment calculates the deploy-
ment quantities using fair share and rounding in case that the available quantity for
deployment is above the children’s demands over the lead time. The initial situation
for this example is shown in Fig. 10.19 where the locations A and B are supplied by
the parent location C. The planning situation is simplified in order to make the
example easier—e.g. the parent location does not have any own requirements in this
case. Both locations have forecast demands and fixed requirements; location B has
additionally a backorder (i.e. a customer order which is overdue for delivery). The
net demand of the child locations is cumulated. The first date for the cumulated net
demand is at the end of the lead time. Both child locations A and B have current
stock of 10 pieces. The lead time from C to A is 2 days and from C to B 3 days.
a 10 Stock b 10 Stock
Backorders Backorders 20
Forecast 10 10 10 10 15 15 Forecast 10 10 10 10 15 15 15
Fix Rqmt. 10 Fix Rqmt. 5
Fix Rqmt. (Prio) 10 10 Fix Rqmt. (Prio) 20
Cum. Net Demand 30 40 50 75 90 Cum. Net Demand 60 70 85 105 120
Overdue Overdue
Lead Time Lead Time
B
c 150 Stock
A
Cum. Rqmt. from A 30 40 50 75 90
Cum. Rqmt. from B 60 70 85 105 120
C Cum. Total Rqmt. 90 110 135 180 210

Overdue Days
Fig. 10.19 Deployment example—initial situation
The diagram at the bottom of Fig. 10.19 shows the demand situation at the parent
location C. The cumulated net demand of the child locations is shifted by the lead
time, therefore the demand over lead time at the child locations—in this a total of
90 pieces—is overdue at the parent location. For this example we assume 150 pieces
of stock at the parent location C.
Deployment determines the order quantity for the stock transfer by allocating the
available quantity to the child location according to the left branch of the flow chart
shown in Fig. 10.3: Fair share, applying the TSL and rounding. Fair share
determines the first proposal for the stock transfers. Figure 10.20 provides an
overview about this procedure (assuming that no restrictions due to TSL apply).
280 10 Deployment
150 Stock
C Day1 Day2 Day3 Day4

Cumulated Requirement from A 30 40 50 75 90
Cumulated Requirement from B 60 70 85 105 120
Total Cumulated Requirement 90 110 135 180 210
Overdue
Fair Share of 15
Delta Quantities Fair Share Fair Share
Location Delta Qty.
Qty. (Delta) Qty. (Total)
Delta Requirement from A 30 10 10 25 15 A 25 8.333 58.333
Fair
Delta Requirement from B 60 10 15 20 15 B 20 6.666 91.666
Share
Total Delta Requirement 90 20 25 45 30
Remaining Deployment Quantity 150 60 40 15 - Rounding
Overdue Rounding
Sequence Location
Qty. (Total) (Rounded)
1 A 58.333 60
2 B 91.666 90
Fig. 10.20 Deployment example without tier processing
The available stock of 150 pieces is sufficient to cover the demand of the next
2 days (135 pieces cumulated) completely and the demand of the third day
(180 pieces cumulated) partially. This analysis is done at the parent location,
i.e. the demand for the next day at the parent location origins from a demand of
the lead time plus 1 day at the child location. In the third day there are delta
requirements of 25 pieces from location A and of 20 pieces from location
B. However, there are only an additional 15 pieces stock left. The allocation of
these 15 pieces to the child locations A and B is performed with fair share. The fair
share quantity FS allocates the remaining deployment quantity (RDQ) proportionally
to the delta requirement DR of the child locations in this time bucket, formula (10.3).
X
FSChild ¼ RDQ DRChild = DRAll Children ð10:3Þ
In this example the fair share quantity for location A is calculated as

FSA ¼ 15 25=ð25 þ 20Þ ¼ 8:333 ð10:4Þ
and the fair share quantity for location B to 6.666 pieces accordingly. The total fair
share quantity is determined by adding the cumulated demand of the previous days
(which is covered by the available deployment quantity in any case). For location A
the total fair share quantity becomes 58.333 pieces and for location B 91.333 pieces.
In the next step rounding is performed according to standard sequence rules—in
this case first the location A is rounded to the pack stage of 10 pieces to a
deployment quantity of 60 pieces. In order not to exceed the available quantity,
the deployment quantity for location B is rounded downward to 90 pieces. Unless
the maximum deployable quantity restricts these quantities, two stock transfers are
created—to location A with 60 pieces and to location B with 90 pieces.
Note that as the result of deployment only one stock transfer is created per
location, and that the stock transfer is always due today.
Example with Tier Processing

For the same situation as shown in Fig. 10.19 we assume that only a stock of
60 pieces is available at the parent location C. Since the demand over lead time is
90 pieces, now tier processing is performed by splitting the demands over the lead
time (which are overdue at the parent location) into the tier categories as defined in
the table for priority tiers. Figure 10.21 shows this example for the tier definition as
listed in Table 10.2.
60 Stock
C
Cumulated Requirement from A 30 40 50 75 90
Overdue
60 Stock
Tier Processing
Tier 1 Tier 2 Tier 3 Tier 4 Tier 5
Cumulated Requirement from A - 10 20 20 30
Delta Quantities Fair

Share Fair Share of 20
Tier 1 Tier 2 Tier 3 Tier 4 Tier 5 Location Delta Qty.
Qty. (Delta) Qty. (Total)
Delta Requirement from A - 10 10 - 10 A 10 5 15
Delta Requirement from B 10 20 30 - - B 30 15 45
Total Delta Requirement 10 30 40 - 10
Remaining Deployment Quantity 60 50 20 - - Rounding
Rounding
Tier Fair Share Fair Share
Location
Sequence Qty. (Total) (Rounded)
1 B 45 50
2 A 15 10
Fig. 10.21 Result of the deployment run
The procedure for determining the deployment quantity with tier processing is
similar to the procedure shown in Fig. 10.20—the main difference is that fair share
is performed now for tiers instead of days.
Demand over Lead Time Determination for Reorder-Point-Based Planned

Products
In case a product is assigned to the DRP planning mode “reorder-point-based” then
deployment with priority tier processing is also possible but the determination of
the demand over lead time—which is compared with the available quantity in order
to identify a priority tier processing situation—follows a different logic. The
formula is the following:
282 10 Deployment
Demand over lead time ¼ ROP Planned minimum safety stock level:
The resulting demand over lead time contains all types of demand—not only
forecast demand.
Furthermore the demand over lead time is assigned to priority tier DEMLT.
Special Fair Share

If fair share in the course of priority tier processing takes place at levels where
either open customer orders or prioritized fixed requirements are involved a special
fair logic is applied—and not the one described above. Since individual orders are
available in the data base including priority, due dates and start dates, this informa-
tion can be used as criteria for allocation in a fair share situation. Figure 10.22
shows the applied logic.
Fig. 10.22 Logic of special fair share determination
If fair share is triggered at a priority tier level where prioritized fixed requirements
are assigned to, these are sorted according to their priorities. The available quantity is
allocated along the list of fixed requirements from top to the bottom until it is used
up. If there are two or more fixed requirements with the same priority in a fair share
situation and a tie needs to be broken then the start dates are used.
If fair share is triggered at a priority tier level where open customer orders (back
orders) are involved then the fair share uses the so-called SPP-priorisation (if the
customizing in the general deployment settings is made accordingly). Figure 10.23

shows the setting which can be accessed via customizing path APO ! Service Parts
Planning (SPP) ! Deployment ! Make General Settings for Deployment.
Fig. 10.23 General deployment settings: special fair share
The SPP prioritization controls that the sorting takes place by order type, item
categories and delivery priorities of the sales orders.
These criteria are defined in another customizing table as shown in Fig. 10.24
and are accessed via customizing path APO ! Service Parts Planning (SPP) !
Basic Settings ! Make General Settings for Customer Demand. In the following
dialog structure node “Document Type (Priority)” the sorting criteria is specified.
Fig. 10.24 Detailed settings for SPP-prioritization
284 10 Deployment
If SPP prioritization is not selected then the sorting is according to the ODL
sorting—if the respective back order is part of any ODL. If this is not the case, the
back orders are sorted by their due dates.
10.5 Push Deployment from Supplier
Overview
Service parts companies apply different strategies as far as local sourcing is
concerned. Either a pure local sourcing is used, where e.g. a regional distribution
center (DC) is responsible for a country and negotiates fully responsible with the
suppliers and operates daily business with them autonomously. In this case a BOD
would be modeled like shown in Fig. 10.25.
Fig. 10.25 BOD

representing two
independently operating
regions
This autonomous regional DC is represented as a separate entry location

(E2) and would keep and operate the contracts like scheduling agreements at its
level. DRP would create the schedule lines and releases accordingly for this level.
On the other hand, there can be procurement strategies where the central
headquarter (E1)—as illustrated in Fig. 10.26—is responsible for administering
and documenting the relationship to the supplier and for keeping the contracts at
central level as well as deciding for the rough replenishment planning. The delivery
to the respective regional DCs is fine-planned by the regional DCs themselves in the
sense of creating the schedule releases.
Fig. 10.26 BOD

representing fully
subordinated regional
distribution centers
10.5 Push Deployment from Supplier 285
The physical delivery is then always faced directly to the regional DCs if net
demand exists there. This scenario is covered in SPP with the process of Push
Deployment from Supplier (PDfS) and the BOD will be modelled as illustrated in
Fig. 10.26.
SPP Process of Push Deployment from Supplier

The result of push deployment from supplier is scheduling agreement schedule lines
from the external supplier to a location of any BOD-level below the entry location.
This respective target location must be defined as potential bypass location and
must have demand in order to get schedule lines. The result of the planning run will
never contain any stock transfers as in standard push deployment or pull deploy-
ment. From that perspective PDfS service is more a supplement to a DRP run than a
deployment run. Figure 10.27 shows a planning process where PDfS is a part of.
Fig. 10.27 Planning process in context of push deployment from supplier
The straight arrows upwards show the rolling up of the requirements in the usual
way, which is managed by a regular DRP run. What is also covered by the DRP is
the creation of the schedule lines from the supplier to the entry location with the
ATP category LP-EIN represented by the white curved arrow in the figure. In the
following PDfS planning run a schedule line would be created represented by the
dark LP-EIN and the corresponding dark curved arrow heading towards location
SPB2. In the next consecutive planning run, pull deployment could create stock
transfers in the usual way.
286 10 Deployment
What is identical between PDfS and standard deployment is that the actual
deployment decision and subsequent order creation is only triggered if there is a
demand over lead at the respective bypass location (here SPB2). Furthermore e.g. if
more than one child location have demand to be fulfilled the standard fair share
logic is applied as described in Sect. 10.4 as well as the standard tier processing as
long as supply shortage exists.
The planning service run of push deployment from supplier is always a
subsequent run of—and even dependent from— the DRP planning run in any
case. Reason is that PDfS needs already existing scheduling lines or—alterna-
tively—scheduling releases as prerequisites for creating new schedule lines. Spe-
cifically it diverts schedule lines which are heading towards the entry location to the
bypass location as the new target location.
Activating the PDfS for a location product does not mean that the bypass
location is exclusively delivered by the supplier—also normal delivery from the
parent location is possible. Since the service is not included in the EDQA like in the
standard push deployment, it is applied with the transaction /SAPAPO/PE_RUN or
scheduled like any other SPP PSM planning service. Eventually the location which
is marked as PDfS (“bypass location”) and serviced accordingly can nevertheless be
delivered from its entry location with STO via standard deployment as well. In case
of a situation where stock is available at the entry location in order to fulfill an
urgent demand, the standard pull deployment is also an alternative. Generally
speaking it is up to the individual business requirement of the service parts logistics
company which way of delivery to prefer—whether via bypass or via the “normal”
internal way along the BOD.
Figure 10.28 shows an example where the first choice of delivery is the internal
way applying the usual pull deployment. That means in job chain design (the
sequence of the planning runs) after the DRP run the “normal” pull deployment is
executed and only then PDfS.
Fig. 10.28 Example 1 on interaction between standard deployment and push deployment from
supplier
The situation and result in Fig. 10.27 is the following: child location SPG1 has a
demand of 60. Location SPB2 is defined for potential push deployment from
supplier (bypass location marked as the black box) and also has a demand of 60.
Altogether is rolled up. Since 50 out of the aggregated demand of 120 can be
covered by the stock of the entry location a replenishment of quantity of 70 is
triggered from the supplier to the entry location by DRP.
The next planning run is normal pull deployment which supplies a quantity of
50 from the entry location to location SPB2 to fulfil the demand there, assuming it is
higher priority tier than the demand at location SPG1. Only now as the last
consecutive planning run PDfS is executed. It fulfills the remaining demand of
10 of the bypass location SPB2 directly from the supplier.
What is not shown in the figure is that in the following the remaining schedule
line of 60 (which is required to cover the demand of SPG1) would go the normal
way to the entry location before normal deployment would create a stock transfer in
the next planning cycle.
In contrast to that Fig. 10.29 shows an example where the PDfS planning runs
before normal pull deployment. In this case the direct delivery from the supplier to
the bypass location (SPB2) covers the whole demand.
Fig. 10.29 Example 2 on interaction between standard deployment and push deployment from
supplier
These two examples show that the definition of a location as relevant for PdfS
does not mean that it is then strictly delivered only directly from the supplier. PDfS
is rather used as a replenishment alternative dependent on the current supply and
demand situation of the respective location product at the bypass location.
If a strict bypass solution is wanted then this is not the right solution. Then a
different design needs to be modelled, preferably via a BOD, where the bypass
location is modelled as an additional entry location, Fig. 10.25.
288 10 Deployment
Prerequisites and Relevant Settings

Push deployment from supplier is to some extent a variant of the deployment mode
‘push deployment’. Accordingly the first prerequisite is the setting of the deploy-
ment indicator either to ‘plan to push’ or ‘plan to pull’—not ‘pull only’—in the
location master.
Furthermore the product master needs to be set generally as applicable for PdfS.
Figure 10.30 shows this parameter in the tab “Properties of SPP”.
Fig. 10.30 Indicator for push deployment from supplier at product level
Additionally the field “Carry Out Push Deployment from Supplier (Location
Product)” in the tab “Deployment” must be set as Fig. 10.31 shows.
Fig. 10.31 Indicator for push deployment from supplier at location product level
The function can generally be switched on or off or it can follow the setting as it
is on product level in the tab “Properties SPP”.
Another prerequisite in the area of master data is the need to have external
procurement relationship master data not only for the usual business relationship
between the supplier and the entry location but also between the supplier and the
corresponding bypass location (location of the second level) for the same product.
Figure 10.32 shows the consequence of this by displaying the planning result in the
schedule line maintenance board (transaction/SPPDERPSB).
Fig. 10.32 External for procurement document for entry location and bypass location shown in
the external procurement—delivery schedule maintenance board
It shows that the product IS1_HALB_0009 can be procured by two different

purchasing documents (scheduling agreements)—one for location SPB1 and the
other for SPB2, where the latter is a subordinated location of the SPB1 in the
corresponding BOD of the product.
The actual planning run is executed with a separate PSM planning profile. It is
done with the transaction /SAPAPO/PE_RUN when it is scheduled within a job or
manually if an exceptional planning run is needed. This profile is also maintained
with the transaction /SAPAPO/PE_CFG as described in Sect. 2.3.
What is different compared to a normal deployment planning profile (pull or
push deployment) is that that the containing process profile is based on package
creation method “simple method”. Accordingly the selection profile being part in
the planning profile for PDfS needs to be of selection type “product”. In the service
list of the PDfS planning profile the planning service “SPP_DEPL_FROM_-
SUPPLIER” has to be selected—and not “SPP_DEPL” as in the normal deploy-
ment (push or pull deployment), Fig. 10.33.
Fig. 10.33 Definition of planning service for push deployment from supplier in the respective
PSM planning profile
290 10 Deployment
PDfS Horizons and Quantity Calculation

Only if there is demand over lead time at the location products which are defined as
potentially taking part in PDfS then the actual deployment logic is applied and
receipt elements are created. The determination of the demand over lead time takes
place as in the normal pull or push deployment. PDfS is applicable for two level
push deployment as well as a multi-level push deployment, where in the latter case
the typical specific logic of quantity determination is applied as described in
Sect. 10.6.1. Multi-Level Push deployment
The determination of the available quantity is solely based on the quantity of the
existing schedule lines for the corresponding entry locations created with one of the
previous DRP runs. The other determinant for identifying the right quantity is the
PDfS planning horizon as it is defined in the deployment service profile of the PDfS
planning run, which Fig. 10.34 shows.
Fig. 10.34 Deployment service profile: definition of planning horizon for push deployment from
supplier and activation of consideration of planning horizon of previous horizon
The schedule lines and releases within the planning horizon (looking at the
arrival date at the entry location) represent the available quantity which might be
used for PDfS.
Part or all of this available quantity can even be pulled forward if necessary and
possible under replenishment lead time considerations.
Figure 10.35 shows a situation after a DRP run. From the child location, which is
the bypass location, the demands are rolled up to the entry location (the middle
section of the figure). In order cover the aggregated demand on the entry location
schedule lines are created—each with shipping dates at the supplier location and
receipt dates at the entry location.
Fig. 10.35 Planning horizon for push deployment from supplier as input parameter for determi-
nation of available quantity
The grey box at the entry location represents the PDfS horizon (13 days). All
schedule lines with receipt date inside this horizon are considered as available
quantity (those at the day 4 and day 9). The availability date at the bypass location is
calculated using forward scheduling from the shipping date from the supplier.
Also in PDfS it can happen that several planning runs create several orders for
the same demand—each order in every planning run—and therefore cause an
excess-supply. This is a similar effect as described in Sect. 10.11 (scheduling) for
normal deployment. The reason there as well as in the case of PDfS is that the
availability date of the order created by the planning service lies outside of the
DRP-replenishment lead time of the target location. The consequence is that in the
following planning run this order does not count as supply in the course of the net
requirement calculation. The net demand will be covered once again etc.
The workaround for that is illustrated in Fig. 10.36.
292 10 Deployment
Fig. 10.36 Workaround for avoiding multiply fulfillment of same demand in PDfS
In order to avoid that the order lies outside of the DRP-specific replenishment
lead time between the two locations, this must be longer than the sum of PDfS
planning and the replenishment lead time between supplier and entry location as it
is applied by deployment. The example shows that the planning horizon for PDfS is
8 days (bubble number 3). Together with the replenishment lead time between
supplier and entry location of 2 days (bubble number 1) this sums up to 10 days. The
DRP replenishment lead time between the two locations in question is bigger,
(11 days as shown next to bubble number 2). The requirement that the availability
date of the order must lie within the DRP-lead time is fulfilled. These circumstances
are explained in more detail in OSS note 1389734.
Scheduling
For the scheduling of schedule lines a specific scheduling scenario exists, which
Fig. 10.37 shows. The components are the transportation lead time defined in the
transportation lane between the supplier location and the bypass location plus the
good receipts time at the bypass location.
Fig. 10.37 Scheduling scenario for push deployment from supplier
The direction is always a forward scheduling starting with the shipping date of
the schedule line as it has been created in the previous DRP run. An implication of
that scheduling logic is that the schedule line will not always be just in time after it
has been diverted by PDfS. Figure 10.38 shows an example where the internal lead
time along the BOD is 2 days from the supplier to the entry location and another
2 days from the entry location to the child location, which leads to an overall lead
time of 4 days. In contrast to this the replenishment lead time from the supplier to
the bypass location is 3 days.
Fig. 10.38 Example for PDfS-specific scheduling and its consequences
This leads in this case to an early delivery of about 1 day at the bypass location.
An overall stock increase at the bypass location is the consequence, which is not
always wanted by the service parts logistics company. The trade-off between the
advantage of utilizing the bypass functionalities in the course of push deployment
from supplier and potential early deliveries has to be considered and therefore the
design of the system implementation around this process has to be made carefully.
Planning Result and Analysis

The planning results can be analyzed in the DRP matrix as shown in Fig. 10.37.
294 10 Deployment
Fig. 10.39 Results of push deployment from supplier planning in the DRP matrix
Figure 10.39 shows that the schedule lines created by the push deployment from
supplier service are shown in the key figure “Distr. Receipt from Supplier (Frozen)”
at the bypass location (in this example at SPB2). As side effect it can also be seen in
this figure that this receipt comes 1 day too early since the actual demand is due
only at the 30th May.
The same can be viewed with the external procurement—delivery schedule
maintenance board, Fig. 10.40.
Fig. 10.40 Results of push deployment from supplier planning in the external procurement—
delivery schedule maintenance board
A quantity of 70 is expected both at 29th May 2014 and 4th June 2014—after
3 days of delivery time each arriving at the bypass location SPB2.
10.6 Multi-level-Deployment 295
It has to be known that no deployment approval can be applied in order to

approve the planning results of push deployment from supplier. Rather the procure-
ment approval has to be applied, if necessary at all.
10.6 Multi-level-Deployment
10.6.1 Multi-level Push Deployment
Overview
In regard to inbound and outbound handling as well as regarding warehouse
activities, it is often the right idea to bypass some dispensable steps in the supply
chain. Push deployment is a solution to achieve this. But the “normal” push
deployment focuses on only two levels of the respective BOD (source to target)
where—simply speaking—only putting the service parts into the warehouse at the
source location is left out as has been shown above. In a more complex distribution
network there are many intermediate locations. Of course these intermediate
locations serve purposes of e.g. storing, consolidating, inspection, re-packaging
etc. But may be skipped in the case of urgent demands on the lowest levels of the
BOD it is a big advantage to skip the intermediate locations on the way to the final
destination. For this purpose deployment offers the multi-level push deployment
variant. The result of the multi-level push deployment is stock transfer orders
directly from the source location to the customer facing location.
In contrast to normal deployment—where several deployment runs are neces-
sary, one for each BOD-level as described in Sect. 10.2—with multi-level push
deployment one single deployment run is sufficient to supply the respective product
to all locations with demands including down to the very final consumer-location as
shown in Fig. 10.41.
Fig. 10.41 Multi-level push deployment in principle
296 10 Deployment
In this case stock transfers are created in one single deployment run which
supply locations of level 2 (SPG1) and level 3 (SPG2, SPP1) of the BOD from
the entry location of level 1 (SPB1) directly (e. g. a stock transfer from SPB1 to
SPG2) as illustrated by the arrows in the figure.
Determination of Demand for Multi-level Push Deployment

The demand for multi-level push deployment is determined by ‘rolling up’ the
demand of each location in the BOD along the BOD as shown in Fig. 10.42. This is
called proposed quantity (dotted lines). This proposed quantity is calculated for all
locations except the entry location.
The proposed quantity is calculated in the same way as if it was a two-level
deployment. Apart from that certain restrictive aspects are ignored, which would be
considered in a conventional two-level deployment:
– prohibition of distribution to locations (in case a DRP/deployment planning lock

was set in the transaction /SAPAPO/DRPPR for the respective period) is
ignored.
– in case multi-level deployment is executed within the scenario ‘push deployment
from contract packager’ the residual quantity is not taken as if it was assigned to
the location where the contract packager belongs to. Here also the full quantity is
taken into consideration as proposed quantity.
In contrast to these restrictive factors rounding is considered in the usual way.
Fig. 10.42 Proposed quantity and deployed quantity
This proposed quantity acts as an intermediate or virtual stock transfer that

fulfills all demands on the child locations and below. It can also be interpreted as
a temporary stock transfer per runtime and is not the quantity of the stock transfer
order (that is still to be created).
Figure 10.42 shows a situation where a demand quantity of 36 is rolled up to the
intermediate location SPG1 (demand of 20 from SPG2 and a demand of 16 from
SPP1 each marked with the dotted lines). Summing up with the SPG1’s own
demand of 14 altogether a demand quantity of 50 is rolled up to the parent location.
The rolled up quantities act as proposed quantities.
This rolling up to determine the proposed quantity on each level happens in a
recursive logic and continues downwards the BOD until it reaches the lowest levels.
The number of recursion depends on the number of BOD sub-levels below the first
level.
Deployed Quantity
In Fig. 10.42 the deployed quantity is shown in the document symbols attached to
the thick non-dotted arrows. This is the quantity of stock transfers which will be
created. Deployed quantities are calculated between the entry location and the child
locations of any level which have net demand (or from the supplier’s location in
case of push deployment from supplier). In contrast to normal deployment, multi-
level push deployment will never generate stock transfers between child locations
(e.g. SPG1 to SPP1).
Fig. 10.43 Result overview on multi-level push deployment
298 10 Deployment
Figure 10.43 shows the deployment result screen, where it can be seen that
several sections were generated during a single deployment run. The first section is
for the sub-BOD below SPB1 and the second for the sub-BOD below SPG1.
Furthermore it can be seen that two quantities are displayed—proposed quantity
and deployed quantity. In this case a proposed quantity of 50 was determined from
location SPB1 to location SPG1 but no deployed quantity. This means that SPG1
has no own demands. There will no stock transfer be generated to SPG1. The
proposed quantity will be passed on to the location on the next level.
Replenishment Lead Time in Multi-level Push Deployment

Two deficits in regard to quantity determination have to be kept in mind. In case of a
stock transfer that skips one or more the standard time supply limit (TSL) can be too
limiting since the TSL is based on the replenishment lead time of a child location to
its direct parent location. Though it is a prerequisite for multi-level push deploy-
ment to have also transportation lanes that connect all locations of the BOD directly
with the entry location nevertheless only the replenishment lead time of the direct
parent is used, which is too short in most cases. To overcome this limitation there is
the BADI /SAPAPO/DEPL_TSL_PARAMETERS to extend the TSL as necessary.
Another deficit which is also caused by a too small replenishment lead time
arises in the course of priority tier processing. If deployment discovers a short
supply situation it activates the tier processing in order to identify all demand types
of the respective BOD level directly below the parent location. It collects all
demand types within the replenishment lead time. However, across e.g. a three or
four level BOD the demands of locations on the lowest level have in reality a much
longer replenishment lead time up to the entry location than considered by SPP and
therefore would not take part in priority tier processing. If it is required to overcome
this limitation then multi-level tier processing can be activated which is described
further down in this in chapter.
Determination of Available Quantity for Multi-level Push Deployment

The determination of the available (distributable) quantity for potential stock
transfers works as follows:
First of all it has to be differentiated between available quantity at the entry
location and available quantity of locations at intermediate levels. The entry
location supplies all demand-carrying locations within the BOD, also the interme-
diate locations. The distributable quantity for multi-level push deployment is—like
for (single level) push deployment—the just received quantity on dock (probably
only the remainder after the fulfilment of backorders). No future receipts whatso-
ever are included.
At the intermediate locations the available quantity is calculated based on only
the receipts to be virtually deployed. Since—in contrasts to pull deployment—no
physical deployment takes place between the intermediate and final child locations,
no physical stock is taken into consideration to determine the available quantity.
Effectively the proposed quantity to the respective intermediate location
(as determined in the previous step and described above) is taken as distributable
quantity. This is illustrated in Fig. 10.44, where the deployment log view of the
deployment and inventory balancing screen (transaction /SAPAPO/SPPDEPL) is
shown. A multi level push deployment run has been executed for a three level BOD.
The BOD with SPB1 as the entry location is shown at top of the figure.
Fig. 10.44 Available quantity at intermediate location
300 10 Deployment
The intermediate location SPG1 as the child location to SPB1 has no own
demand. Therefore the proposed quantity of 20 between SPB1 and SPG1 is
interpreted as available quantity of location SPG1 and will be passed on to its
child location SPG2 as stock transfer (deployed quantity).
As seen in Fig. 10.45 the function of multi-level push deployment is activated in
the service profile for deployment and can be applied to BODs with the maximum
number of five levels.
Fig. 10.45 Activation of multi-level push deployment
Multi-level deployment is only applicable in the deployment mode “push

deployment”. This means that only if the deployment mode PUSH or PUSH_SIM
is set in the service profile then the multi-level deployment indicator is effective as
Fig. 10.46 Planning modes of multi-level push deployment
Multi-level Push Deployment Result and Simulation

The multi-level approach can be identified and validated in the log view or via
deployment simulation—both are available with the transaction /SAPAPO/
SPPDEPL. Deployment simulation shows a result section where one section
consists normally of a STO overview view, the normal shipping view and—if
expedited STOs exist—the expedited shipping view. When simulating multi-level
push deployment then as many result sections as sub-BOD levels exist are
displayed (the number of sub-BOD levels is the number of BOP levels minus one).
Figure 10.47 compares the result overview screen of a two level deployment
(above) with the one of a multi-level deployment for a three level BOD (below).
Fig. 10.47 Result screen two level versus multi-level push deployment
It is shown in the result screen of multi-level push deployment (below) that the
two sub-BOD-levels are named after the corresponding entry location (SPB1) and
the intermediate location (SPG1).
Several sections—each for the respective sub-BOD-levels—are also shown in
the corresponding log file (transaction /SAPAPO/SPP_PE_LOG or /SAPAPO/
SPPDEPL) as seen in Fig. 10.48.
302 10 Deployment
Fig. 10.48 Multi-level push deployment log file
All features of multi-level push deployment are also valid for the process of push
deployment from supplier without any exception. Therefore this process is not
described explicitly.
10.6.2 Multi-level Tier Processing
Elimination Anonymization of Demand Types Across BOD-Levels

Even if multi-level push deployment is applied still a deficit remains in regards of
multi-level consideration of all demands types in a prioritized way across a BOD as
soon as a short supply situation exists. Demands lower than the second BOD-level
(from the perspective of the entry location) are anonymized when they are rolled
up. E.g. in a three level BOD the demand derived from a backorder on a third level
location will be interpreted as tier “demand over lead time” on the corresponding
second level location. This is the tier where all the demands coming from lower
level locations are aggregated. The tier “demand over lead time” is normally
classified as low priority in customizing. As a consequence most probably the
available stock is sent to a location where it is not needed that urgently. So it
might happen that safety stocks are fulfilled in one location and a backorder demand
in another location (at a lower level than 2) remains unfulfilled. This situation will
definitely cause customer dissatisfaction.
The following example in Fig. 10.49 illustrates this:
Fig. 10.49 Multi-level push deployment in principle
The thin, curved arrows represent the rolling up of the requirements to the next
BOD-level each. The location SPG2 on level 3 has two overdue sales orders with
demand quantity of 50 together. Backorders—as usual in typical business
scenarios—is per assumption assigned to priority tier level 1.
It can be seen that planned distribution demand at location SPG1 is interpreted as
demand over lead time and assigned to priority tier 5. The safety stock at location
SPB2 is assigned to priority tier 3. Therefore SPB2 gets all stock from its parent SPB1.
In order to overcome this phenomenon the function of multi-level tier processing
can be applied. Multi-level tier processing does not interpret dependent demands of
locations lower than second level as tier “demand over lead time” but rolls up all
tier requirements of all sub-trees below a location of level 2 as the original tier
requirement and aggregates all these requirements per priority tier. Eventually all
these tier requirements are summed up with the own requirements of the same
priority tier of this particular second level location. This provides a detailed
decision basis of the structure of all tier requirements of all locations projected up
to the second level.
A comparison between a deployment decision without and with multi-tier
processing is shown in an example of Fig. 10.50, 10.51 and 10.52.
Figure 10.50 shows the initial situation as displayed in the DRP-Matrix, in
particular the situation of two child locations of level 2, which are SPB2 and
SPG1, next to the situation of SPG1’s child location SPPP. At first glance a compet-
ing situation can be observed between the supply shortage of SPB2 and SPP1. SPB2’s
supply shortage is derived from a non-prioritized fixed demand (which is an assigned
to the priority tier 3), whereas SPP1’s supply shortage of 157 units is mainly derived
from an open customer order of 120 units (which is assigned to priority 1).
304 10 Deployment
Fig. 10.50 Example of multi-level tier processing: part 1
For this BOD two variants of multi-level push deployment and their respective
results are shown. The first is without and the other is with the functionality of
multi-level tier processing.
Figure 10.51 shows the result of a multi-level push deployment planning run
without multi-level tier processing. Since there is an overall shortage situation
within this BOD (available quantity of 132 units versus requirements over lead
time of 195 units) this shows the inability to cover all the priority tier requirements
of all the child locations further down the BOD.
The available quantity of 132 units at the entry location SPB1 has to fulfill
demands over lead time of altogether 195 units. A demand of 165 units is derived
from location SPG1 whereas 30 units are from SPB2 (requirements over lead time).
The lower part of Fig. 10.35 shows the result in the sub-BOD-level for location SPG1.
In the location SPP1 there is a requirement of 120 units assigned to tier 1, which
represents the open customer order. From the perspective of location SPG1 this
customer order is displayed as priority tier 1 demand of 120 units from location SPP1.
This priority tier 1 demand is rolled up one level as shown in the upper part of
Fig. 10.35. Here this customer order ends up in priority tier 5 (“demand over
replenishment lead time”) together with other demands. From the perspective of
location SPB1 it is displayed as priority tier 5 demand from location SPG1.
Still looking from location SPB1 there is another demand of 23 units (25 units
rounded) of priority tier 4 from location SPB2. This demand has its origin from a
prioritized fixed demand and is now rated as higher, i.e. priority tier 4 versus priority
tier 5 of the customer order. So, this will be prioritized during deployment and is
completely fulfilled (including rounding) by stock transfers whereas the customer
order will only be partially fulfilled with the remaining quantity of 105 units
(107 subtracted by 2 due to rounding restrictions). Accordingly a stock transfer is
created from SPB1 to SPP1 with a quantity of 105 units as well as a stock transfer from
SPB1 to SPG1 with a quantity of 25 units. A quantity of 2 units remains at the parent
location. However, fulfilling fixed demands over customer order is usually not desired.
In contrast to this Fig. 10.52 shows the result of the deployment planning with
multi-level tier processing.
306 10 Deployment
It can be seen that the full demand quantity of 120 units of the open customer
order is fulfilled by the stock transfer from SPB1. The assigned priority tier 1 to the
demand of quantity of 120 units is propagated up to the next BOD-level and is
considered there (since on SPG1 there is confirmed supply of 100 units, the result of
the netting with the demand quantity of 120 units plus some other tier 2 demand of
20 units resulting in 40 units is shown).
Determination of Tier Requirements of the Sub-trees Below a Location

In order to understand the final deployment results it is helpful to know the
following specific logic of multi-level tier processing:
To determine the right requirement quantity for tier processing, all the different
requirements within the lead time have to be identified. The lead time in a two level
deployment is known and therefore also what periods to consider with their
requirements.
In case of a multi-level tier processing the extended lead time has to be
calculated step-by-step down to the very last BOD-levels. To get the last period
inside the overall BOD lead time, deployment searches for the last period that rolls
up a requirement to a period inside the lead time on level 2.
As part of that logic it is possible that additional periods are inside the lead time
down from level 2. However, this is irrelevant because they have no net demand as
illustrated in Fig. 10.53.
Fig. 10.53 Multi-level tier processing: scope of relevant demands across all levels
The thick arrows are the requirements that are rolled up as tier requirements to
the next higher level and where they are aggregated with other tier requirements.
Doing this the last period can be identified which takes part in tier processing and
which is aggregating tier requirements up to level 2. At level of location SPX1 it is
shown that the last potential period of the replenishment lead time (the grey
buckets) does not take part since this has a requirement of 0. So, only two times
50 units are rolled up and will be sorted into the corresponding priority tier on level
of location SPP1 before they are aggregated with the own tier requirement of
location SPP1 level. This logic continues until level 2 is reached.
Further information on the detailed logic is available in the SAP online help.
When using priority tier processing the special fair share logic behaves differ-
ently to the way it is described in Sect. 10.4. Since the individual sales order items at
any location below level 2 are aggregated after they have been rolled up to the
second BOD-level special fair share among order items cannot be applied anymore.
This implies that no sorting by e.g. due date is possible anymore. Instead all the
rolled up and aggregated orders are treated as one single order on level 2. These
orders will be covered after the orders from level 1 and 2. Furthermore these orders
are covered in the order the locations are sorted by the sequence rules. This
exceptional behavior of the special fair share logic also applies to prioritized
fixed demands.
Multi-level Tier Processing Result and Analysis (Log)

There is no explicit hint in the corresponding log file that any deployment decision
was made based on multi-level tier processing. The best way to analyze the
deployment decisions is the result sections in the deployment protocol in transac-
tion /SAPAPO/SPPDEPL.
308 10 Deployment
10.7 Express Shipments
If it is possible to cover a demand in time or earlier by choosing a faster but more

expensive means of transport, this shipment is called ‘expedited’. The prerequisite
for expedited shipments are:
• there is a faster but more expensive means of transport,

• the product is not excluded from expedited shipment (a setting in the ‘properties
of SPP’-view of the product master) and
• there are tier requirements eligible for expedited shipment.
Whether a tier requirement is eligible for expedited shipment or not is defined in

the service profile for deployment, Fig. 10.54. In this case demands belonging to
tier 1 or to tier 2 are eligible.
Fig. 10.54 Eligible tiers for expedited shipment
10.8 Deployment Simulation 309
If there are demands eligible for expedited shipment, the deployment run is
performed first for the expedited shipments and then with the remaining quantity for
the normal demands. Stock transfer orders for expedited shipment are displayed
separately in the result screen of deployment simulation (see Sect. 10.8) and in the
log for deployment.
Other parameters for expedited shipment are the settings for maximum weight,
volume and dimension for expedited shipment in the header data of the transporta-
tion lane, Fig. 10.55. These are economical limits and not technical limits (since
they are independent of the means of transport).
Fig. 10.55 Parameters to limit the expedited shipment per transportation lane
The length, width, height, total volume, and total weight for the requested
quantity is taken from the packaging specification, which is attached to the respec-
tive product. These dimensions specified in the minimum level of the packaging
specification are the relevant ones. If a dimension is not maintained or a packaging
specification is not available at all, the corresponding dimension from product
master is used as a fallback
If the potential expedited shipment exceeds these limits, the expedited shipment
is created only within these limits.
10.8 Deployment Simulation
It is possible to simulate the deployment run both for pull and for push deployment.
The prerequisite is that service profiles for the simulation of pull and push deploy-
ment exist. Whether a profile is suitable depends on the planning mode which has to
be PULL_SIM or PUSH_SIM. These profiles are assigned to the planning service
SPP_DEPL with the customizing path SCM Basis ! Planning Service
Manager ! Assign Standard Service Profile for UI. Here it is also possible to
define service profiles user specifically, Fig. 10.56.
310 10 Deployment
© SAP AG
© SAP AG
Fig. 10.56 Deployment service profile and assignment for simulation
The deployment simulation is performed with the transaction /SAPAPO/

SPPDEPL. The mode switches between push or pull deployment. For the simula-
tion of push deployment the cursor must be placed at the parent location and the
available quantity—the quantity for the simulated goods receipt—has to be
maintained interactively. For the simulation of pull deployment the cursor can be
placed on any of the child locations, Fig. 10.57.
Fig. 10.57 Deployment simulation
10.8 Deployment Simulation 311
The result of the deployment simulation is displayed in different views. The STO
overview, the normal shipping view, the express shipping view (if needed) and the
tier requirements view (if needed).
The stock transfer overview shows the available quantity for deployment and for
each of the locations additional information, e.g.:
• whether the location is a parent location

• whether the demands of the location are netted with its parent location (see
Sect. 10.3)
• the calculated deployment quantities for the child locations (‘deployed
quantity’)
• whether a stock transfer order would have been created (checkbox ‘STO’)
• the quantities of the stock transfer orders for expedited shipment and for normal
shipment
Figure 10.58 shows an example, where out of the 200 available pieces none is
kept at the parent location SPB1 and 190 pieces are sent to the location SPG1 as
normal shipments. 10 pieces are sent to SPB2 as express shipments as indicated in
the column “expedited Qty” . The planned physical shipment is indicated with
“STO” flagged
Fig. 10.58 Result of the deployment simulation
More detailed information is available in the deployment views ‘express ship-

ment’ and ‘normal shipping’, Fig. 10.59. Here the part of the deployment matrix is
displayed which is the basis for the calculation of the deployment quantities.
312 10 Deployment
Fig. 10.59 Detailed views for the deployment simulation result
In the ‘express shipment’-view only plant SPB2 has tier requirements which are
eligible for expedited shipment—in this case 17 pieces of tier 3. These 17 pieces are
first rounded up to 20, allocated and then reduce the available quantity as well as the
demand—in the ‘express shipment’-view the requirements over lead time for the
location SPB1 are 425 pieces, whereas in the ‘normal shipping’-view the
requirements over lead time are reduced to 405.
The tiers—as displayed in the detailed views—contain the cumulated demands. In
the ‘normal shipping’-view the cumulated requirements of the locations SPB2 and
SPG1 for tier 4 and tier 5 are displayed. The demand types are however of the tiers 2, 3
and 5 and are covered by the available quantity. Since this requirement of 405 pieces is
not covered by the available quantity of 180 anymore, fair share is performed. In this
case the fair share is very simple: SPG1 gets all the remaining quantity of 180 pieces.
In order to identify all the priority tiers in detail there is a third view—the Tier
Requirement view. This is available additionally for the normal shippings as well as
for the express shipments. Figure 10.60 shows the Tier Requirement view for the
express shipments.
Fig. 10.60 Detailed view of tier requirements of the deployment simulation result
10.9 Stock Transfer Approval 313
There all priority tiers including the corresponding demand figures are shown at
one glance starting with the tier 0. The tier 0 represents the Total Gross Receipt
(Confirmed), e.g. stock and confirmed stock transfers. Also receipts for net
demands, which are pulled forward due to e.g. supplier shut down are included
there. The negative figure of 20 of PrioTier 0 for SPB2 is derived from a stock
transfer of type “normal STO”. Effectively this is available quantity for other
upcoming demand on this location. This available quantity is consumed and
reduced by a quantity of 7 in PrioTier 3 (which is derived from prioritized fixed
demand). The remaining 13 are further consumed in PrioTier 3 by a quantity of
10 (which is derived from a non-prioritized fixed demand.
For the location SPG1 a demand of 2 in PrioTier 3 exists (which again is derived
from a non-prioritized). In PrioTier 5 a demand of another 400 exists (which is
derived from planned distribution demand to child locations on lower levels below
SPG1). The aggregated resulting figure of 402 is displayed in the corresponding cell
for PrioTier 5, Fig. 10.60.
10.9 Stock Transfer Approval
If the flag for ‘confirm stock transport orders’ is set in the service profile, all the
stock transfer requirements are not released automatically but require an interactive
approval, Fig. 10.61.
Fig. 10.61 Stock transfer approval
314 10 Deployment
The stock transfer approval is performed with the same transaction /SAPAPO/
SPPDEPL as the deployment simulation. After saving the approval the status of the
order changes to ‘approved’ and the stock transfer order is sent to SAP ERP™.
10.10 Stock Transfer Execution
The stock transfer execution involves three systems and two locations. The
processing of the stock transfer order is done mainly in SAP ERP™, SAP
EWM™ posts the goods issue and the goods receipt and—after approving the
stock transfer—SAP APO™ reflects the current data for planning purposes. Fig-
ure 10.62 provides an overview of the document flow across the three systems for
the source and the target location.
SAP APO mySAP ERP SAP EWM

Source Target Source Target Source Target
STO
STO Approval PO (STO)
Automatic Delivery Creation
Delivery Delivery PO (STO)

PO (STO)
Delivery
Goods Issue
Goods Issue Goods Issue Goods Issue
Inbound Delivery Creation
PO Memo Inbound Delivery Inbound Delivery
Goods Receipt
Goods Receipt Goods Receipt Goods Receipt
Fig. 10.62 Order flow for the stock transfer execution
After transferring the stock transfer order to SAP ERP™ a delivery is created
immediately at the source location. The delivery is transferred to SAP EWM™—
which is displayed in SAP ERP™ by the status ‘distributed’ in the delivery,
Fig. 10.63 (transaction VL03N).
10.10 Stock Transfer Execution 315
Fig. 10.63 Outbound delivery with status ‘Distributed’ in SAP ERP™
Based on this delivery it is possible to post the goods issue in SAP EWM™. The
goods issue will trigger in SAP ERP™ the creation of an inbound delivery at the
target location. SAP EWM™ finally posts the goods receipt based on the inbound
delivery.
For stock transfers within a company the order type UBL is used, for cross
company stock transfer the order type UB. The delivery type NL is assigned for the
stock transfer within a company and delivery type NLCC for cross company stock
transfer. Even for stock transfers within a company an info record is required
because the confirmation control (0004) has to be maintained. The automatic
creation of a delivery is defined with the customizing path Materials
Management ! Purchasing ! Purchase Order ! Set Up Stock Transport
Order ! Activate Automatic Delivery Creation and CRM Billing, Fig. 10.64.
Fig. 10.64 Automatic delivery creation
316 10 Deployment
10.11 Scheduling
The tasks for scheduling in deployment are the determination of the lead times
between the two locations within a BOD and the consideration of calendars.
Capacity constraints are not considered.
One of the differences between scheduling in DRP and in deployment is that
deployment schedules time continuously while DRP schedules only in buckets.
These discrepancies require cautious and coordinated modelling of the scenarios.
An example is described further down.
The general settings as described in Sect. 8.3 are as valid in DRP as for
deployment. Whether to apply a total procurement lead time or more detailed
component lead time in deployment is defined there. In any case the scheduling
in deployment is transportation-lane based scheduling. The duration for using a
total procurement lead time for scheduling a stock transfer is maintained in the
mode of transport specific section of the transportation lane of the two locations
involved. Using the component lead time the different components are maintained
in different master data objects and eventually put together depending whether pull
or push deployment is applied. Compared to DRP the components for deployment
differ in some parts as shown in Fig. 10.65.
Fig. 10.65 Lead time components in deployment
Calendars are needed to identify the working and non-working days and to
schedule the durations as well as start and end dates of the various activities into
an appropriate working time section. Planning calendars are used which are based
on factory calendars and are represented as time streams in SPP. Each location can
have its own calendars. Using the total lead time method the planning calendar of
the corresponding sending location is used. Using the component lead time method
for scheduling the different time components different calendars are used.
Table 10.3 shows which calendar type is used for which lead time component.
10.11 Scheduling 317
Table 10.3 Calendar types per lead time component

Lead time comp Calendar type Master data source
Time between deployment runs Shipping calendar Location master
Review time Shipping calendar Location master
Communication time Receiving calendar Location master
GI time Shipping calendar Location master
Transport time Transportation calendar Transportation lane master
GR time Receiving calendar Location master
Throughput time Production calendar Location master
The throughput time is used in push deployment and replaces GR and GI-time
Scheduling Direction
In most planning systems there are two different scheduling directions available.
On one hand forward scheduling and on the other hand backward scheduling. Latter
is normally used if a certain deadline should be reached without delivering the
products unnecessarily too early. The dates determined represent the latest possible
dates. It therefore eliminates any time buffers, but also reduces lead time and
therefore also reduces the average overall stock level.
SPP deployment triggers the generation of stock transfers at the latest possible
moment, i.e. when the planned demand start date (which is rolled up by DRP) is in
the DRP overdue column. Therefore the start date of the potential stock transfer is
always “now”. This is the reason why the standard scheduling direction is forward
scheduling. Nevertheless there is also an alternative scheduling direction which is
not a pure backward scheduling but a so-called “forward and backward schedul-
ing”. This can be set in customizing as shown in Fig. 10.66 and accessed with path
APO ! Supply Chain Planning ! Service Parts Planning ! Deployment ! Make
General Settings for Deployment.
Fig. 10.66 Activation of forward and backward scheduling
As the name says it is a combination of both directions in order to shorten the

lead time. Figure 10.67 shows an example on forward scheduling as the first part of
“forward and backward scheduling”.
318 10 Deployment
Fig. 10.67 Forward scheduling in deployment
The component lead time in this case comprises only goods issue time at the
sending location, transportation time and good receipt time at the receiving loca-
tion. For simplification reason both locations—sending and receiving locations—
are shown in this one figure. The lower row—in particular the white windows—
shows the working hours of the shipping and good issue department of the sending
location. In SPP this is modelled by the shipping calendar (every week-day open
from 8 a.m. till 6 p.m. without any break). The row in the middle shows the
transportation time windows represented by the transportation calendar (from
Wednesday to Friday each available from 6 a.m. till 11 p.m.). The upper row shows
the working time windows of the goods receipt department of the receiving location
represented by the receiving calendar (every week-day from 9 a.m. till 5 p.m.).
Assuming the deployment planning run ends on Monday at 4 p.m. then good
issue starts immediately after that at 4 p.m. and lasts until 6 p.m. (illustrated by the
thick arrow). Since no transportation takes place on Mondays and Tuesdays there is
a waiting time until the beginning of the next possible transportation shift. Waiting
times are illustrated by the thin arrows. Transportation finishes after 11 h at
5 p.m. on Wednesday, which coincidentally is shift end of the warehouse staff in
the receiving location. Therefore the GR activity can only start at the next day,
which is Thursday 9 p.m. Good receipt activities take 4 h and end at 1 p.m., which is
the final availability date of the stock transfer.
It can be seen that there is a certain waste of lead time. In order to shorten the
lead time backward scheduling is applied right away as a second step as illustrated
in Fig. 10.68. From the end date of the last activity (goods receipt) determined in the
forward scheduling step now backward scheduling is executed. Now the stock
transfer needs only to start on Wednesday, 10 a.m. instead of Monday 4 p.m. So
most of the waiting time can be eliminated and causes to start the first activity of the
order not earlier than necessary.
Fig. 10.68 Backward scheduling in deployment
The results of scheduling a stock transfer are the durations and the related start
and end dates of the individual activities. A crucial date is the delivery date which is
equivalent with the end date of the transportation activity. The delivery date is the
only date that is transferred to SAP ERP when the stock transfer is sent to SAP ERP
and converted into a stock transfer order. In the SD module of SAP ERP it has to be
safeguarded that the consecutive obligatory transportation and delivery scheduling
will determine a more or less similar result regarding the start date and end date of
the order—e.g. by applying the conditions technique for flexible durations for pick,
pack and load such that its sum is comparable to the goods issue processing time of
the stock transfer as determined in SPP.
Risk of Late STO Availability Due to a Conflicting Scheduling Situation

Between DRP and Deployment
DRP’s smallest time and scheduling granularity is a daily bucket. On the time
stream a bucket starts at 00.00:00 a.m. and ends at 11:59:59 p.m.
When scheduling an order by DRP the final result is mostly an approximation,
where the main goal is to identify at which days the first activity of an order starts
and on which day the last activity of an order ends. For an example let us assume
that the overall duration of a DRP stock transfer requisition is 8 days, If a DRP
planning run finishes at 5 o’clock and the start of the DRP STR is immediately due
then the order end date and time is not at 5 o’clock at the 9th day but at 23:59:59
p.m. at the 8th day. This logic also applies to the determination of the BOD-internal
replenishment lead time by DRP as Fig. 10.69 shows.
320 10 Deployment
Fig. 10.69 Late fulfillment of demand over lead time by a deployment-scheduled STO
The calculation of the lead time between locations comprises e.g. review time,
goods issue time, transportation time and goods receipt time. If the sum of these
make up exactly 8 days then the lead time ends exactly at the very end of the 8th day
no matter at what time on day 1 the lead time starts.
If under these circumstances deployment identifies demand over lead time and
creates a STO by considering the same time components for scheduling then the
STO duration would also be exactly 8 days. But since deployment is more accurate
as far as scheduling is concerned (based on seconds), the start is at 5 am. Accord-
ingly the end date of the STO is exactly 8 days later at 5 a.m. at day 9—which is
outside of the lead time. Receipt elements that are outside the lead time are no valid
receipts from a DRP point of view and would be therefore ignored. As a conse-
quence this would cause DRP to create stock transfers again for the purpose of
fulfillment of the same demand.
One way to overcome this risk of too late STO availability is to extend the
DRP-specific lead time compared to the deployment-specific lead time. An exam-
ple could be to define the deployment review time much shorter than the DRP
review time. OSS note 1139313 gives an official recommendation for workarounds
on that topic.
Scheduling According to Geo Route

The way of scheduling the stock transfers in deployment and inventory balancing
described so far is more or less rough. However, in SAP ERP there is a way to apply
a more detailed scheduling—be it for different workloads, quantities, time
pressures or costs.
In order to provide similar scheduling options like SAP ERP a routing guide
based scheduling can be applied in SPP. The method is then generally applicable in
SPP since it is switched on in customizing in the general settings, as can be seen in
Fig. 10.70.
Fig. 10.70 Activation of routing-guide-based scheduling
As prerequisites for using this scheduling method routes have to exist in SPP.
The routes are either maintained in mass mode by applying a BAPI or interactively
with transaction /SCTM/ROUTE as is shown in Fig. 10.71. A route consists of a
header part where the ID, the description, max weight, max height, length, width
etc. are maintained.
Fig. 10.71 Snapshot on route master data
322 10 Deployment
The detailed part of a route consists of several tabs where the most important is
the “leg” part. The legs represent the different parts of the routes, i.e. the lanes from
one node to the next in a network including the mode of transport. The lead time is
derived from the geo-coordinates of the locations involved in the legs of the route.
If approval necessity is activated in the deployment service profile then the
selected route is displayed in the deployment approval screen.
Fig. 10.72 Information of routes used in deployment planning
Figure 10.72 shows that the fields.
• Route
• Geography Group
• Export Relevancy
• Next Cross Docking Location and
• Transportation Service Provider
are displayed, which are specific to route-based scheduling. These columns also
appear in the SPP planner’s worklist and the customer’s worklist for the STO
queries.
There is no other UI in SPP where it can be identified whether the dates were
determined by route-based scheduling. In SAP ERP this information is displayed as
soon as the stock transfer is integrated to SAP ERP. If necessary or wanted, the
route can be changed manually in the STO.
As described in Sect. 8.3, there are scheduling scenarios which represent the way
and content of scheduling in the various business processes and its alternatives.
Since route-based scheduling is an alternative to the lane-based scheduling, it
differs in some parts. The differentiators are the lead time components. For the
route-based scheduling there are two special lead time components in order to
integrate the content of routes into the scheduling scenarios: These are “RF”, which
stands for fastest route, and “RC”, which stands for cheapest route. The scheduling
scenarios that are dealing with routes and where these special lead time components
are integrated in Table 10.4:
Table 10.4 Overview on route-specific scheduling scenarios

Procurement lead
Scheduling scenario time group
59: Deployment: location/contract packager to location (push, routing C7,RC,C8
guide)
60: Deployment: location to location (pull, routing guide) C4,RC,C8
61: Deployment: location/contract packager to location (push, routing C7,RF,C8
guide, expedited shipment)
62: Deployment: location to location (pull, routing guide, expedited C4,RF,C8
shipment)
63: Deployment: location/contract packager to contract packager (push, C7,RC
routing guide)
64: Deployment: location to contract packager (pull, routing guide) C4,RC
65: Deployment: location/contract packager to contract packager (push, C7,RF
routing guide, expedited shipment)
66: Deployment: location to contract packager (pull, routing guide, C4,RF
expedited shipment)
Using transportation lane-based scheduling all of the different scenarios can be

scheduled forward or backward depending on the general customizing settings in
deployment as described in this chapter. In route-based scheduling only forward
scheduling is possible and therefore the corresponding customizing parameter is
removed as soon route-based scheduling is activated.
How in detail a route is determined in SAP APO—e.g. via the configurable
process scheduling—is not subject of this book.
Inventory Balancing
11
The supply of locations is done via deployment along the BOD. Lateral stock
transfers are usually avoided because there are more costly: The service part has
to transferred one more time, which means additional costs, and the lateral transfer
itself might be less cost efficient due to low volume. In exceptional cases a lateral
stock transfer is desired nevertheless.
Inventory Receipts Requirements
Inventory Balancing
Rounding Excess and Need
Profile Determination
Trigger
Costs Cost and Benefit Analysis
Stock Transfer Approval
Stock Transfer
Order
Stock Transfer
Execution
Fig. 11.1 Inventory balancing process overview

326 11 Inventory Balancing
The purpose of inventory balancing is to supply locations laterally—i.e. not along

the regular paths of the BOD—in case of need at one location and surplus at the other
location. As an exception also the supply between two locations of different levels of
a respective BOD could be possible if needed. The restriction is that the direction
could be only upstream, i.e. from child location to a parent location. The supply from
a parent to child location is technically not possible, since this is in the planning
responsibility of deployment. Fig. 11.1 shows the inventory balancing process in
principle with its inherent functions of “Excess and Need determination” and “Cost
and Benefit analysis” as well the relevant input and resulting output factors.
The nature of inventory balancing is short term and is intended in most cases as
an optional step if deployment fails to supply the needs.
Inventory balancing in SPP can be applied for serviceable products as well as for
unserviceable products. The use of balancing of unserviceable products is intended
as optional in the course of a repair-to-stock process. The repair either is externally
made by subcontracting or takes place at a certain location, where not sufficient
unserviceable products could be available in order to fulfill the dependent demand
coming from the work orders or subcontracting orders. If at other locations within
the BOD an excess of the same unserviceable products exists the inventory balanc-
ing for unserviceable products is applied. Since the need is generated by a DRP run,
this creates a certain trigger (SPP_UNSRV_INSUFF), which initiates the actual
inventory balancing run for the respective product.
In the following the general principles of inventory balancing are explained with
regard to balancing of serviceable products. If the process in regard to unservice-
able differs, this is mentioned.
Example
A BOD with a very simple structure is used as an example for inventory balancing. This
simple BOD contains the parent SPG1 and two children SPG2 and SPB1, Fig. 11.2. The
normal way of supply is via deployment from the parent to the children along the BOD.
Inventory Balancing
projected Inventory
projected Inventory
SPG2 SPB1
BOD
Deployment
projected Inventory
SPG1
Fig. 11.2 Example for inventory balancing
11.2 Inventory Balancing Area 327
In this example however, there is a shortage for the child SPB1 which cannot be covered
by the parent. Therefore the shortage at SPB1 will remain even after deployment.
Inventory balancing now checks whether there is another location with surplus
in the near. Whether a location is considered to be ‘in the near’ is modeled by the
inventory balancing area. If this is the case, a transportation lane exists between the
locations and the savings by a stock transfer exceed the costs by a threshold, a
lateral stock transfer is created—in this example from SPG2 to SPB1. Inventory
balancing does only create stock transfers outside the ‘normal’ BOD relationship.
Inventory balancing might also be triggered by a de-stocking decision or by
supersession in order to get rid of the predecessor product.
11.2 Inventory Balancing Area
The inventory balancing area contains those locations which are allowed to perform
these lateral stock transfers. The inventory balancing area is modeled as a hierar-
chy. A dummy location (which is not used for any other purpose) defines the name
of the inventory balancing area, and all locations of the inventory balancing area are
assigned to this dummy location. The hierarchy structure for this hierarchy is
assigned to the general settings for inventory balancing. Figure 11.3 gives an
overview of these settings. Note that not the ID but the name (i.e. the short text)
of the hierarchy is used in the assignments.
General Settings for

Inventory Balancing
Hierarchy Structure NAME Hierarchy
Hierarchy Structure ID
Inventory Balancing Area

(Dummy Location)
Fig. 11.3 Structure of the settings for the inventory balancing area
Dummy Location for Inventory Balancing Area

The dummy location is created in SAP APO™ with the transaction /SAPAPO/
LOC3 as shown in Fig. 11.4. Since the location is interactively created and not
transferred from SAP ERP™, it is necessary to assign the location explicitly to the
active model 000.
Fig. 11.4 Dummy location for the inventory balancing area
Hierarchy for Inventory Balancing

The hierarchy for inventory balancing (here: SPP_INVBAL_AREAS) is
maintained like any other hierarchy with the transaction /SAPAPO/RELHSHOW
and with reference to the hierarchy structure for inventory balancing areas (here:
SPP_INVBALANCING), Fig. 11.5. The inventory balancing area (here:
SPPINVBALAREA) is the dummy location that is assigned at the first level of
the hierarchy.
Fig. 11.5 Inventory balancing area
11.2 Inventory Balancing Area 329
In this example the inventory balancing area SPPINVBALAREA is defined by

the dummy location SPPINVBALAREA, and the locations PLSPB1@RME801,
PLSPG1@RME801 and PLSPG2@RME801 are assigned to the dummy location
(the parent location has to be assigned as well). This is one prerequisite for stock
transfers between PLSPG2@RME801 and PLSPB1@RME801—a transportation
lane between the locations is the other. As a last step the hierarchy has to be
assigned to the active model 000.
Hierarchy Structure
The hierarchy structure for inventory balancing areas is defined with the
customizing path APO ! Master Data ! Hierarchy ! Define Hierarchy Structure
and relates to the object ‘location’ and has a link to the table /SAPAPO/
RELEHLOC, Fig. 11.6.
Fig. 11.6 Hierarchy structure for inventory balancing
Assignment of the Hierarchy Structure for Inventory Balancing Area

As a last step the hierarchy structure is assigned to the general settings for inventory
balancing. Only one hierarchy structure can be used for inventory balancing. This is
defined with the customizing path APO ! Supply Chain Planning ! SPP ! Inventory
Balancing ! Make General Settings for Inventory Balancing, Fig. 11.7.
Fig. 11.7 Assignment of the hierarchy structure for inventory balancing
11.3 Excess and Need Determination
The prerequisite for a lateral stock transfer is that there is at least one location with
excess inventory and one location with a shortage. Therefore the first step in
inventory balancing is the determination of locations with need and locations
with excess.
Lateral stock transfers are usually an additional effort. Therefore it is important
to ensure that the excess inventory is not just a momentary state to cover
requirements in the very near future. Before the location with excess inventory
transfers its stock to the location with need it should also be checked that the parent
location will not cover the need in the meantime. These checks are performed using
three parameters for the excess check date, the need check date and the need
verification date.
Excess Determination
For the excess determination only the stock on hand is considered. The projected
stock (without receipts) describes how much stock is left if all requirements are
covered by the current stock. In case of inventory balancing for unserviceable
products the relevant demand, which is subtracted from the stock on hand is derived
from the key figures Unserviceable Products Demand (Frozen) and Unserviceable
Products Demand (Inv.Bal.-STO). Forecast for returned products, unserviceable
stock in transit or future receipts of unserviceable products from stock transport
orders are not taken into account. If the projected stock (without receipts) at the
excess check date and at the day after is still above the safety stock, the difference to
the safety stock is used as excess inventory for inventory balancing, Fig. 11.8.
Projected Stock (without Receipts) Projected Stock (with Receipts)
Safety Stock
Excess Inventory Time

X Days
X+1 Days
Excess Check Date
Fig. 11.8 Excess determination
Figure 11.8 shows also that the later the excess check date, the smaller the excess
inventory.
11.3 Excess and Need Determination 331
Need Determination for Serviceable Products

For the need determination for serviceable three checks are performed:
1. Is there a net requirement at the need check date?

2. Is there still a net requirement at the need verification date?
3. Does the parent also have a net requirement at the need check date?
Only if all three conditions are met a need is calculated at the location. The need
is calculated as the net requirement at the need check date. Figure 11.9 shows the
need determination (without the check at the parent location). The need quantity is
the net demand at the need check date.
Projected Stock (with Receipts)

Need
Safety Stock
Time
Net Demand
M Days
Need Check Date
N Days
Need Verification Date
Fig. 11.9 Need determination
Check Date Parameters

The parameters for the dates are defined in the inventory balancing parameter
profile with the transaction /SAPAPO/RDPLPRF. The inventory balancing para-
meter profile is assigned to the inventory balancing area with the transaction
/SAPAPO/RDPLPRFA, Fig. 11.10.
© SAP AG
Inventory Balancing Area Inventory Balancing Parameter Profile

(Dummy Location)
© SAP AG
Excess Check Horizon X Need Verification Horizon N
Need Check Horizon M
Fig. 11.10 Maintenance of excess check and need check dates
Need Determination for Unserviceable Products

For the need determination for unserviceable product two DRP Matrix situations are
compared with each other. The first matrix is created taking the real physical stock
of unserviceable products into account as well as the demand for repaired product as
determined by the DRP repair-stock planning process. In contrast to that the second
(fictive) DRP matrix assumes the available physical stock of unserviceable products
as unlimited. The result is number of repaired products which can be theoretically
reached. The difference between the number of repaired products of the second and
first DRP matrix are compared. The difference is considered as the need.
Inventory Balancing Work Queue

The excess and the need determination is performed for all locations within the
inventory balancing area. The locations are sorted by their excess respectively their
need and the highest excess is matched with the highest need. If the cost and benefit
analysis turns out to be favorable, a stock transfer is created, else the excess is
matched with the next need—and cost and benefit analysis is performed again.
After each stock transfer the locations are re-sorted by their excess and need.
Figure 11.11 shows the flow chart for this procedure.
Sort Locations
by Excess
Sort Locations
by Need
Match Location with

Highest Excess
and Highest Need
Create Stock Yes Cost-Benefit

Transfer Analysis positive?
No
Match Excess with

Next Need
Fig. 11.11 Flow chart for matching of excess and demand
This flow is repeated until all excess locations are processed. Figure 11.12 shows
an example for the inventory balancing work queue. The inventory balancing area
contains five locations; two locations with excess inventory and two locations with
need. This example assumes that the cost and benefit analysis supports all
suggestions for stock transfers.
11.4 Cost and Benefit Analysis 333
Location Excess Stock Transfer 17 Location Need

1st Iteration
SPG2 30 AUT1 17
BEL2 21 FRA2 16
AUT1 - FRA1 10
FRA1 - SPG2 -
FRA2 - BEL2 -
Re-Sorting

2nd Iteration
BEL2 21 FRA2 16
SPG2 13 FRA1 10
AUT1 - AUT1 -
FRA1 - SPG2 -
FRA2 - BEL2 -
Re-Sorting

3rd Iteration
SPG2 13 FRA1 10
BEL2 5 FRA2 -
AUT1 - AUT1 -
FRA1 - SPG2 -
FRA2 - BEL2 -
Fig. 11.12 Example for the inventory balancing work queue (#SAP AG)
In this example all locations belong only to one inventory balancing area. Since
one location can belong to more than one inventory balancing area, all involved
locations have to be considered. Before a stock transfer is created, additionally it
must be checked whether the locations belong to the same inventory balancing area.
11.4 Cost and Benefit Analysis
11.4.1 Cost and Benefit Analysis Overview
If the difference between the savings and the move costs is above the threshold that
is defined in the inventory balancing service, a stock transfer for inventory balanc-
ing is created. The savings contain the inventory savings SINV, the warehouse space
savings SW, and the service benefit SSB.
SINV þ SW þ SSB Move Costs Threshold ð11:1Þ
The inventory and the warehouse space savings apply at the source location and the
service benefit at the target location.
In case of inventory balancing for unserviceable products the savings contain the
“savings through repair” SR instead of service benefit SSB. Savings through repair
are determined by subtracting the cost of repair (as described in Sect. 8.10) from the
procurement costs.
The threshold is defined in the service profile for inventory balancing with
the customizing path APO ! Supply Chain Planning ! SPP ! Inventory
Balancing ! Define Service Profile for Inventory Planning, Fig. 11.13.
Fig. 11.13 Service profile for inventory balancing
11.4.2 Inventory Savings
The annual inventory costs are the procurement costs CP for the product times the
annual forecast QANNFC multiplied by the holding cost factor FHC. The inventory
savings at the source location are the portion of the deployed quantity QINVBAL,
formula (11.2a).
SINV ¼ FHC CP Q2INVBAL =QANNFC ð11:2aÞ
The procurement costs are maintained in the ‘procurement’-view of the product

master. The holding cost factor FHC represents the average inventory in the ware-
house and is maintained in the product master, Fig. 11.14.
Fig. 11.14 Holding cost factor in the product master
In case of inventory balancing for unserviceable products, the calculation differs

slightly from the one used for serviceable products. At locations that do not have
demand for repaired products, the system calculates the inventory savings from
reduced stockholding costs as follows
SINVRN ¼ FHC CP QINVBA ð11:2bÞ
Regarding all other locations, where repaired products are needed, formula (11.2a)
is applied.
11.4.3 Warehouse Space Savings
The warehouse space savings apply at the supplying location and represent the
benefit by freeing up warehouse capacity. The warehouse space savings SW are
calculated as
SW ¼ S TRUNC ðQINVBAL =QBIN Þ SB ð11:3Þ
where S is a factor, QINVBAL the quantity for inventory balancing, QBIN the average
bin quantity and SB the savings per bin. The warehouse space savings depend on the
utilization of the bins (QBIN) and the warehouse. This information is maintained as
static parameters in the product master respectively in the WSS storage type
settings. The warehouse utilization is not directly used in formula (11.3) but for
the determination of the savings factor S in the warehouse space savings profile.
Figure 11.15 provides an overview of the involved entities and parameters.
Location
Bin Type WSS Storage Warehouse Space

Type Savings Profile
Warehouse Savings Factor
Utilisation S
Savings per Bin

Product
Average Bin
Quantity
Fig. 11.15 Entities and parameters for the warehouse space saving
The average bin quantity for the bin type (parameter ‘WSS storage type’) is
maintained in the product master as shown in Fig. 11.16.
Fig. 11.16 Average bin quantity and bin type
The factor S is calculated using the warehouse space savings profile and the
settings for the WSS storage type per location as shown in Fig. 11.17.
Fig. 11.17 Determination of the factor S based on the estimated utilization
The WSS storage type settings contain the savings per bin SB as well and are
maintained with the transaction /SAPAPO/RDPLWSTYPLOC. Note that the stor-
age bin type has to match the WSS storage type in the product master.
Fig. 11.18 Warehouse space savings profile
The parameters F1, F2, X and Y are defined with the transaction /SAPAPO/
RDPLWSSPRF in the warehouse space savings profile, Fig. 11.18. The warehouse
space savings profile finally is assigned to the location in the ‘SPP’-view,
Fig. 11.19.
Fig. 11.19 Assignment of the warehouse space savings profile to the location
11.4.4 Service Benefit
The service benefit takes the prevented loss of an order into account and is therefore
only calculated if inventory balancing is triggered by an unsuccessful deployment
run (trigger SPP_PULL_DEPL_NOSUCC) or by an expedited demand in the
firmed horizon (trigger SPP_EXPEDITE_FIRMHOR). Another characteristic of
the service benefit calculation is that the benefit from a prevented loss is maintained
per order item and not per missing quantity. Figure 11.20 shows the maintenance of
the savings from a prevented loss in the product master.
Fig. 11.20 Savings from prevented loss (product master)
The service benefit SSB is calculated as the number of benefiting items times the
savings from prevented loss, formula (11.4).
SSB ¼ NBI SPL ð11:4Þ
SPL are the savings from prevented loss as maintained in the product master and NBI
the number of benefiting items.
Number of Benefiting Items

The number of benefiting items NBI is calculated by dividing the quantity QLP that
prevents a loss by the forecast for the average item quantity FCIQ, formula (11.5).
NBI ¼ QLP =FCIQ ð11:5Þ
The quantity QLP that prevents the loss is the minimum of the transferred quantity
by inventory balancing QINVBAL and the shortage quantity QSHORTAGE, formula
(11.6).
QLP ¼ min fQINVBAL ; QSHORTAGE g ð11:6Þ
If the excess inventory within the inventory balancing area does not cover the
complete shortage, the service benefit applies only to those items covered by the
transferred quantity. Figure 11.21 shows the calculation of the loss prevention
quantity QLP for the case that the shortage exceeds the excess inventory.
Projected Stock Projected Stock with Inventory Balancing

Projected Stock without Inventory Balancing
QINVBAL
Time
QSHORTAGE
QLP = QINVBAL
Constrained Lead Time for Supply from Parent Location
Fig. 11.21 Loss prevention quantity (shortage exceeds excess supply)
The dotted line shows the expected shortage quantity if the location has to
wait until the parent location is able to send supplies. A lateral stock transfer within
the inventory balancing area is faster and covers a portion of the shortage—
nevertheless there will be a new shortage situation before the supply from the
parent arrives. Therefore the whole stock transfer quantity QINVBAL contributes to
the service benefit.
Projected Stock
Projected Stock with Inventory Balancing
Projected Stock without Inventory Balancing
QINVBAL
Time
QSHORTAGE
QLP = QSHORTAGE
Constrained Lead Time for Supply from Parent Location
Fig. 11.22 Loss prevention quantity (inventory balancing exceeds shortage)
In the other case the stock transfer quantity QINVBAL exceeds the shortage. This
might be the case if the safety stock is replenished as well or if the transfer quantity
is rounded. In this case not the whole stock transfer quantity QINVBAL contributes to
the service benefit but only the shortage quantity QSHORTAGE, Fig. 11.22.
Based on the loss prevention quantity QLP the number of benefiting items is
calculated using the average demand quantity per item of the forecast.
11.4.5 Move Costs
The move costs consist of the goods issue costs at the source location, the transport
costs and the goods receipt costs at the target location. These parameters are shown
in Fig. 11.23.
Product Master Source Location Transportation Lane
© SAP AG
Product Master Target Location
© SAP AG
© SAP AG
Fig. 11.23 Parameter for the move costs
The transport costs are maintained in the transportation lane per means of
transport and not per product. The base unit of the transport cost must be maintained
in the product master as well—either as base unit or as an alternative unit of
measure.
11.5 Inventory Balancing Services
The service profile for inventory balancing for serviceable products is defined with
the customizing path APO ! Supply Chain Planning ! SPP ! Inventory
Balancing ! Define Service Profile for Inventory Planning and contains the
rounding profile, the threshold for the cost-benefit analysis and the time series for
the forecast, Fig. 11.24.
11.6 Inventory Balancing Stock Transfer Approval 341
Fig. 11.24 Service profile for inventory balancing for serviceable products
In contrast there is a separate service profile for unserviceable products,

which can be accesses via customizing path APO ! Supply Chain
Planning ! SPP ! Inventory Balancing ! Define Service Profile for Inv. Bal. of
Unserviceable Prod.
Fig. 11.25 Service profile for inventory balancing for unserviceable products
As shown in Fig. 11.25 a service profile for serviceable products is assigned to

the service profile for unserviceable products in order to utilize its logic.
There is also the choice whether to use cost-benefit analysis or not by activating
the corresponding flag.
11.6 Inventory Balancing Stock Transfer Approval
Depending on the general settings for inventory balancing (see Fig. 11.7) an
interactive confirmation of stock transfer orders might be required. The stock
transfer approval is performed with the transaction /SAPAPO/SPPDEPL as
described in Sect. 10.7. In this UI there are two sub-tabs—one for deployment
STO’s and the other for Inventory Balancing STO’s. Inventory Balancing STO’s
for unserviceable products are indicated as such.
Alternately the approval can be executed from the Planner’s Worklist as shown
Fig. 11.26.
Fig. 11.26 STO approval query in the planner’s worklist
By highlighting one or more lines at once, these orders can be approved or

rejected by pushing the button indicated in the figure. The result of this action is
saved immediately.
Interchangeability
12
There are two types of interchangeability which are used and supported by SPP.
One is the supersession chain, which models the replacement of part by one or more
other parts in the sense phasing out an old part and phasing in the new parts.
The other supported interchangeability type is the FFF-class, which models a
group of almost identical parts that are constantly interchangeable—without any
start or end dates in the sense of phasing out and phasing in.
12.1 Process Overview of Supersession
The replacement of a service part with another service part (or with several other
service parts) is called supersession. Reasons for supersession might be changes in
the product, changes in the service parts portfolio or changes in the sales package—
e.g. from a kit to separate service parts or the other way around. Therefore
supersession is not an independent process but relies mainly on the service parts
planning processes manage demand, forecasting, EOQ and safety stock planning,
and DRP as well as deployment. The objective for supersession is to use up the
stock (and also the planned supply) of the predecessor entirely so that the phase-in
of the successor should be right in time almost synchronously to the final use-up of
the predecessor. In order to reach that SPP calculates the key dates for planning
with supersession. These dates are stored in service parts specific fields of the
interchangeability master. Therefore the use of the interchangeability function
differs significantly from standard SAP APO™.
Out of the dates that service parts planning uses for supersession, two dates are
required for the process overview: The pending obsolescence date (POD, in stan-
dard SAP APO™ known as the start date of the interchangeability) and the
successor product planning date (SPPD) which describes the date where planning
for the successor product must start.
If the POD is reached, the supersession service calculates the other relevant dates
for the supersession, among these the SPPD. Only after the SPPD is reached,

344 12 Interchangeability
realignment copies the demand history of the predecessor service part to the history
of the successor service part. Forecasting then calculates the forecast for the
successor product based on this transferred demand history. This forecast is addi-
tional, because the demand history of the predecessor remains and therefore a
forecast is calculated also for the predecessor. The same applies to EOQ, safety
stock calculation and deployment which is done for both the predecessor and the
successor.
If everything runs smoothly, the demand for the predecessor is covered with the
remaining stock and existing fixed supply whereas new supplies are already avail-
able to cover the demand for the successor. In case of an imbalance—either because
the stock for the predecessor is not sufficient to cover the demand (for the prede-
cessor) or because there is stock left—DRP creates substitution orders to cover the
demand for the successor with supply elements of the predecessor or the other way
around. Figure 12.1 shows the process overview of service parts planning with
supersession.
Interchangeability Demand History

Master (Predecessor)
POD No Try
Realignment
POD
reached? again
Yes Demand History

(Successor)
Supersession
Service
Forecasting
SPPD
SPPD Yes
reached? Forecast
EOQ &
Safety Stock
DRP
EOQ
No Imbalance for Yes
Predecessor?
Safety Stock
Schedule Line Substitution

(Successor) Order
Fig. 12.1 Service parts planning with supersession
12.2 Interchangeability Master 345
The main features to consider supersession for service parts planning are the
supersession service, the realignment of demand history and the interchangeability
master. The forecasting and the EOQ and safety stock planning functionality is not
affected by supersession at all. The only planning area which offers additional
functionality is DRP—and to some extent deployment—with the creation of sub-
stitution orders.
In case the setting is chosen, that deployment does not include the substitution
orders into the deployable quantity, then excess supplies of the predecessor at the
entry location will not be transferred to cover a demand for the successor product
at the child locations. This will cause an imbalance in the short-term planning,
which will be resolved by the ATP check for the sales order. The prerequisite is
that rules-based ATP is used with a location substitution procedure that checks
the entry location and that the interchangeability master is used for product
substitution.
12.2 Interchangeability Master
Interchangeability Master for Supersession Chains

Supersession in service parts planning requires the master data object ‘interchange-
ability group’ which is maintained with the transaction /INCMD/UI. There are two
types of interchangeability groups that are relevant for SPP, supersession chains—
that are the focus of this section—and form, fit, function (FFF)-classes that will be
described in Sect. 12.9. Supersession chains are used to model the life cycle of
service parts. The key feature of supersession chains is that they allow a predeces-
sor—successor relationship with distinct dates. The replacement type defines the
relationship between the predecessor and the successor—e.g. A will be replaced by
B AND C—this will be explained in a later section. First of all there is a ‘valid
from’-date, which determines the date from which on the successor product should
be used. This date is entered when creating the interchangeability group and
corresponds to the pending obsolescence date (POD). There are several POD’s
per supersession chain—one cross location specific attribute as well as one for each
location involved in the BOD. All the POD’s of a specific supersession chain can be
different.
Fig. 12.2 Interchangeability master
In the location dependent part of the interchangeability group there are further
relevant dates stored as shown in Fig. 12.2. These are the following:
• the successor product planning date (SPPD) defines when planning for the
successor product starts
• the successor product receipt date (SPRD) is the first date when the successor
product is available at the entry location. It is also called date of last safety stock,
since it is the point in time from when on the safety stock of the predecessor is
not considered anymore
• the stock exhaustion date (SED) is the projected stock-out for the predecessor.
• the stock exhaustion warning date (SEWD) is used to check whether the
calculation for the SED is still correct.
• the Final Date defines that a supersession chain has finished and a potential
subsequent supersession chain (which is logically and due to business reasons
aligned) begins to be active.
The interchangeability group and its dates can be changed only until realignment
is run.
For service parts planning it is required to maintain the interchangeability group
location dependent as well for the entry location. Most of the information is
maintained without reference to the location as shown on the bottom left part of
Fig. 12.2. In this case a substitution from the predecessor product

IS1_HALB_004@QU6715 to the successor product IS1_HALB_006@QU6715
takes place with the quantity relation of 1 to 1. The quantities are defined by the
preceding respectively succeeding quantity factor and the type of the substitution
by the replacement.
Replacement Types of Supersession Chains

In service parts it is usual to have situations where one product is replaced by one
single other product (1:1) or by several other products (1:N). Also the inverse case
is possible that multiple products are replaced by one successor (N:1), which is
shown in Fig. 12.3.
Fig. 12.3 Example of a N:1 AND supersession chain
In case of a 1:N replacement two different ways of replacement are possible.

First, product A could be a kit consisting of products X and Y, and A should not
be sold any longer as a kit but rather as individual products X and Y. This
example shows that the replacement takes place in a way where all N products
altogether replace the one single product (AND), The other example is that the
predecessor product A was used in models X and Y, and is now replaced in
model X with successor product B, and in model Y with successor product
C. This situation, where several products alternatively replace one product is a
logical OR, Fig. 12.4.
Fig. 12.4 Example of a 1:N OR supersession chain
The replacement type describes the relation between predecessor and successor,
i.e. whether it is a 1:1, 1:N, N:1 or a1:0 relation and—if there are multiple
predecessors or successors—whether it is an AND or an OR.
Table 12.1 shows the supported replacement types in SPP.
Table 12.1 Replacement types for supersession chains used and supported by SPP
Successor’s ratio
Predecessor’s
ratio 1 N(m) 0
1 Supported Supported, both AND Supported
and OR
n Supported, both AND Not supported Not supported
and OR
0 Not supported Not supported Not supported
In SPP only N:M relations are not supported. However, to ensure that the other
relations are supported the customizing flag for “de-activate PP/DS” in the inter-
changeability settings with IMG path SCM BASIS ! Master Data ! Product and
Location Interchangeability ! Application Settings ! General Settings must be
set to active (Fig. 12.5).
Fig. 12.5 Customizing parameter for de-activation of PP/DS logic
A special case of replacement types is the N:1 (OR). This requires a modeling of
N separate supersession chains, all of which having the replacement type of N:1
(OR). Furthermore all of these supersession chains need to have the same predeces-
sor as well as the identical POD’s accordingly.
In case of a 1:0 replacement—i.e. a discontinuation—all relevant dates are set to
current supersession planning service run date at the same time—except the SED,
which can be calculated as if it was an non-1:0 replacement. The use-up strategy
can be set to “Yes”, “No” or “Restricted”. If it is set to “No” nevertheless the gATP
check must be applied in order to use up the remaining stock.
One special example of the replacement type 1:1 is the partial substitution in
SPP. In service parts industry it is also common to substitute only a portion of an
existing predecessor. This means that the predecessor is left alive, but a portion of
its demand history is passed on to a new or existing product as a successor in a
certain point in time. This situation of partial substitution is represented by the
replacement type of 1:1 partial. That means that the predecessor has one successor
that takes over only parts of the demand history. This is specified in the cross-
location specific attributes of the interchangeability master (Fig. 12.6).
Fig. 12.6 Example of a partial product substitution supersession chain
Regarding the realignment of the data history additionally a realignment end

date is specified in the entry-location specific attributes. This is set by Change
Notification Agent (can) as soon as the replenishment indicator is changed in a
location product which is part of an active supersession chain with a replenishment
type of 1:1 partial. After the realignment end date no realignment of the
predecessor’s demand history is assigned to the successor.
The replacement types are defined in the customizing via IMG path SCM BASIS
! Master Data ! Product and Location Interchangeability ! Application
Settings ! Maintain Interchangeability Group Types and Assign Replacement
Types as shown in Fig. 12.7.
Fig. 12.7 Customizing settings of replacement types
The replacement types are applicable only to supersession chains (as far as
SPP is concerned)—and not to FFF-classes. For the supersession chains eight
replacement types are delivered per default. The assignment of replacement types
to the interchangeability group types is done in customizing via IMG path SCM
BASIS ! Master Data ! Product and Location Interchangeability ! Application
Settings ! Maintain Interchangeability Group Types and Assign Replacement
Types as shown in Fig. 12.8.
Fig. 12.8 Customizing settings of group types
12.3 Supersession Service 351
When creating an interchangeability group of type supersession chain, the

replacement type needs to be selected then accordingly as shown in Fig. 12.9.
Fig. 12.9 Example of replacement type selection in the supersession chain to be created
12.3 Supersession Service
As mentioned in Sect. 12.2 the supersession functionality in service parts planning

relies fully on a set of dates in the supersession chain:
• the successor product planning date (SPPD)

• the successor product receipt date (SPRD)
• the stock exhaustion date (SED)
• the stock exhaustion warning date (SEWD)
• the Final Date
These dates are determined by the supersession service planning run.

Figure 12.10 shows the PSM planning profile with the corresponding service
profile and planning service “SPP_SUPERSESSION” attached to it. SPP_
SUPERSESSION requires a package creation method for location products. In
particular the package creation method LOCATIONPRODUCT_SUPERSESSION
is recommended by SAP and even necessary, if parallel processing is chosen for
planning. Otherwise also the package creation method LOCATIONPRO-
DUCT_PRODUCT can be applied.
Fig. 12.10 Supersession service profile in PSM planning profile
The service profile for supersession is defined with the customizing path APO !
Supply Chain Planning ! SPP ! Supersession ! Define Service Profile for
Supersession.
Figure 12.11 shows the customizing details of the service profile. The field
‘maximum stock exhaustion horizon’ is a threshold for the calculation of the super-
session dates: If SED is over the max. horizon, then 12.31.9999 is saved as SED. It is
required by DRP and visible to the users that the chain has been processed.
Fig. 12.11 Supersession service profile
Though supersession can also be used for products that are reorder-point
(ROP) based planned (see DRP chapter) the following needs to be considered.
Based on the DRP planning mode of the location product the supersession
service will set the dates SPPD, SPRD, SED, SEWD altogether to the current
date which means that the successor product is immediately active for planning.
Reason for that is that the excess of the predecessor cannot be determined in case
of ROP based planning because the demand situation of the predecessor outside
the lead time is not evaluated. Also the demand date at the successor is not
known exactly.
The prerequisite to apply this logic to ROP based products is activated with the
parameter “Check and Determine Dates for ROP Products” as shown in Fig. 12.11.
Another prerequisite is that for the predecessor all location products of the entry
location’s sub-BOD are set to ROP based planned. Having the SED set to the
current date has the consequence that current stock will not be used up—since both
deployment and inventory balancing will not consider this product anymore. A
recommendation for this situation could be to set the replenishment indicator of a
predecessor to NS interactively and execute inventory balancing before running the
supersession service for ROP based products.
A planning run for a supersession planning profile is executed for all active
supersession chains in the SPP system. The planning run checks if the valid-from
date of a respective supersession chain is reached. If this is the case then further
planning relevant dates are calculated. This planning run should take place daily.
Reason is that there is no comparison-check between the actual run date and POD of
the supersession chain in question upfront and so the chain takes part on a
prophylactic basis.
The supersession service determines the various dates according to a specific
logic based on lead times and buffers. Once the dates are determined the subsequent
PSM planning services behave in a specific way in order to reach the supersession
specific business goals that are described in detail in the following.
Pending Obsolescence Date (POD)

The POD is maintained in the interchangeability master as ‘valid from’-date—
either manually or automatically by customer-specific logic when creating the
interchangeability master via CIF integration or a BAPI-based solution.
Fig. 12.12 Functional reaction when reaching pending obsolescence date
As soon as the interchangeability master data is created in the system a trigger

for the supersession service is set. Each time the service checks whether the POD
has been reached. If so, all SPP relevant dates—except SEWD—are calculated,
Fig. 12.12. The corresponding trigger is not consumed at runtime, but rather as soon
as SEWD has reached The POD is the starting point in the calculation logic for the
determination of SED and the date of last demand (DOLND), which both are
described in detail later in this chapter.
Stock Exhaustion Date (SED)

The stock exhaustion date (SED) is the date where the stock for the predecessor
product is used up.
Fig. 12.13 Recalculation of SED is done between POD and SEWD
The SED is calculated considering the sum of all stocks and all receipts on all
locations of the predecessor product netted against all demands (forecasts, fixed
requirements and dependent demands) of all locations in the BOD—starting from
the beginning of the planning horizon. The SED is actually the date where the days
of supply end. The SED is calculated for each location of the BOD and consolidated
at the entry location and registered there. The SED is one date that is saved per entry
location.
The SED is calculated the first time after POD has been reached and is
re-calculated with every new supersession planning run until SEWD is reached,
for which Fig. 12.13. shows an exemplary point in time.
In case of a customer location (location type 1010—see Chap. 15 OEM MI) no
stock of the respective locations is taken into consideration when calculating the
SED.
Fig. 12.14 Functional planning reaction when reaching stock exhaustion date
From SED on no receipt elements should exist for the predecessor anymore
(except late receipts).
After SED—as shown in Fig. 12.14—DRP does not execute any more net
demand calculation for the predecessor and further replenishment or deployment
stops. That means DRP considers only demands of the successors. If in case of an
use-up strategy ¼ “yes” some unexpected stock is still available then it will not be
used-up anymore after SED. If the supersession chain has a use-up-strategy ¼ “no”
then the SPPD as well as the SED are both set to today immediately.
In case of ROP based planned products the SED as well as all the other dates are
set immediately to the planning date of the supersession service.
Successor Product Planning Date (SPPD)

Based on this SED the supersession service calculates the SPPD. The idea is that the
supersession planning service is performed daily so that the SPPD—among SED
and SPRD—is updated regularly. The scheduling elements for this calculation are
the (longest) lead time from the supplier to the entry location plus the lead time
within the BOD—both for the successor product as shown in Fig. 12.15.
Fig. 12.15 Dates for the supersession
In case of 1:N substitution, then the supersession service uses the longest
replenishment lead time of all succeeding products into account.
Additionally a buffer can be considered. The buffer is defined with the
customizing path APO ! Supply Chain Planning ! SPP ! Supersession !
Make Settings for Calculating Supersession Times or with the transaction /
SAPAPO/SPRSCUST in the general settings for supersession, Fig. 12.16.
Fig. 12.16 General settings for supersession
The buffer consists of two elements, an absolute number of days defined in the
general settings plus a percentage of the safety stock.
Fig. 12.17 Functional planning reaction when reaching successor product planning date
The SPPD represents the point in time where the successor product is planned
the first time, illustrated in Fig. 12.17. Subsequently demand history realignment
takes place the first time with the service SPP_PDEM_SUPERSESSION_RLG,
i.e. the whole predecessor’s demand history is copied to the successor. This is based
on the generated trigger SPP_BOD_CHANGE_INCMD. In the case of 1:1 and 1:N
AND relationship types the same value of the predecessor’s demand history is
copied to every successor product. In case of a 1:N OR relationship type every
successor product is provided with proportional value of demand history compared
to the original predecessor’s demand history. In the following (until date of last net
demand has been reached) new upcoming demand history of the predecessor is
automatically copied to the successor on an incremental basis without the need to
run the realignment service explicitly again.
No trigger for the predecessor product is set after the realignment service
planning run. For the successor product the trigger “SPP_RLG_DONE” is set,
which is relevant for a potential stocking or de-stocking run—here the planning
process steps and the corresponding logic does not differ from none-supersession
cases.
The application and logic of the forecast planning run is the same as if the
products (predecessor and successor) were not part of an active supersession
chain. I. e. once the demand realignment has been executed, the trigger “SPP_
RLG_DONE” is set. This triggers the forecast planning runs for the successor
product.
The application and logic of the EOQ/SFT planning run is the same as if the
products (predecessor and successor) were not part of an active supersession chain.
I.e. once the forecast has been executed the trigger “SPP_FCST_CHANGE” is set
which triggers the EOQ/SFT planning run for the successor product.
Furthermore for the successor product DRP and deployment takes place the first
time (even though the latter does not always make sense in such early life cycle
stage of the successor).
The SPPD is the point in time where first the SEWD is calculated by the
supersession service.
Successor Product Receipt Date (SPRD)

The successor product receipt date (SPRD) is identified after the SPPD and before
the stock exhaustion warning date (SEWD) on the timeline as shown in Fig. 12.18.
It is calculated starting at SED by scheduling backwards and subtracting the
longest BOD-internal lead times. Optionally the same buffer as applied for SPPD
can be subtracted as well (if specified in customizing). Figure 12.15 shows these
steps.
Fig. 12.18 Functional planning reaction when reaching successor product receipt date
The SPRD represents the date on which the first physical goods receipts of the
successor products happens at the entry location. Concurrently at this point in
time no safety stock of the predecessor is considered anymore in the net
requirements planning. That means net demand at the entry location due to
stock below safety stock would not cause DRP to generate purchase requisitions
nor would net demand due to stock below safety stock at the child location cause
stock transfers to be generated. For that reason SPRD is also called date of last
safety stock.
Stock Exhaustion Warning Date

The stock exhaustion warning date (SEWD) is used to monitor the current SED. By
default the SED is recalculated until the SEWD is reached. The SEWD is usually
calculated once—on the first run on the day where the SPPD is reached—and
retains this initial value. In the general settings for the supersession as shown in
Fig. 12.16 it is defined which components are used to calculate the SEWD. The
settings shown in the figure represent a situation, where the SEWD is identical with
SPRD (since no supplier procurement lead time is used).
After SEWD is reached, no date in the respective supersession chain is
re-calculated anymore by the supersession service. If—by any reason—SED
moves to a point in time before SEWD an alert will be issued (alert type 7855).
Date of Last Net Demand (DOLND)

The date of last net demand (DOLND) is a DRP-specific date but with special
meaning in respect to supersession. The DOLND is not stored explicitly in the
supersession chain. It is rather the later date of either the POD + limited freeze
horizon or the SED as shown in Fig. 12.15. The determination is defined in the
delivered standard logic of the BADI /SAPAPO/INC_LAST_NETDEMAND.
Obviously the determination of the DOLND can be changed within this BADI on
a project basis. If POD-based (periods of demand) DRP-rounding is used then only
the periods until the end of this date are considered.
In case of 1:0 supersession the DOLND is set immediately to the SPPD by the
PSM supersession service.
The DOLND determines the end of automatic net requirements calculation
and latest replenishment date of the predecessor product by DRP in case
of a supply shortage on the entry location. Via the BAdI /SAPAPO/INC_
LAST_NETDEMAND the definition of this date can be done more differentiated
depending on the planning service used. E.g. it can be defined that the DOLND is
identical with SED if a DRP planning is executed. In contrast to that DOLND could
be identical with the end date of the horizon “POD + limited freeze horizon + a
buffer” if deployment is applied. In contrast to the SED the DOLND is calculated
for each location within a BOD separately. Therefore the situation can be
configured that DRP has already stopped procurement on entry location level, but
still replenishes BOD-internally on child location level.
The BAdI /SAPAPO/INC_LAST_NETDEMAND is not only applicable for

period-based planned parts as predecessor products in a supersession chain but
also for reorder-point-based planned parts.
Final Date
The Final Date is optional. It is only calculated and relevant if the sequencing
feature is activated in the supersession service profile (flag “Use Chain Sequencing”
and “Use Item Sequencing”), as shown in Fig. 12.19, As soon as a final date of a
supersession chain has moved into the past the supersession chain is defined as
finished.
Fig. 12.19 Activation of chain sequencing and item sequencing in the service profile
The Chain Sequencing focuses on business requirement of many service parts

companies where supersessions of parts take place often and where the successor
only lives shortly before it is superseded by the next successor soon. The involved
corresponding supersession chains are logically connected to each other as a virtual
sequence. This means that the successor of one supersession chain is the predeces-
sor of the subsequent supersession chain etc. The supersession chains are all
existing in the SPP system and all have the same POD. An example would be
that currently a part A is actively superseded by part B. Soon B will be superseded
by C. To a later stage C is superseded by D, where latter case should also be
documented already in the SPP-system. Without the function Chain Sequencing
and Item Sequencing, each supersession chain would be considered by the
supersession service independently. Figure 12.20 shows that as soon POD is

reached the dates (SPPD, SED etc.) of the active supersession chains would be
calculated in the way as described above.
Fig. 12.20 Example of independent consideration of two supersession chains of a logical

sequence
In case of A!B these dates are distributed along the time line since there is
active stock, supply, demand and forecast existing. In case of the supersession chain
B!C all the corresponding planning dates are set to today.
With the active function of Chain Sequencing, the active items of the superses-
sion chains in a sequence are compared and consequently the B!C chain would not
be evaluated until the final date of A!B is over.
Fig. 12.21 Example consideration of two supersession chains of a logical sequence with active
function of chain sequencing
In the example in Fig. 12.21 the Final Date of supersession chain A!B is still far
in the future. Therefore there is no determination of any of the outstanding planning
dates for supersession chain B!C yet. Supersession chain B!C will stay only with
the POD and only at the 17th July the dates like SPPD and SED will be calculated
by the supersession service.
The Item Sequencing is applied for determination the active item. If a certain
sequence of several supersession chains, e.g. A!B, B!C, C!D existed, then it
would be necessary to identify an active item. Without the function of Item
Sequencing, this is the predecessor product across all the supersession chains of
the sequence, whose POD moved into past most recently. Using the Item Sequenc-
ing function a product is only considered as an active item as soon as POD has
moved into past, but as long the final date has not moved into the past yet.
The calculation of Final Date is similar to the determination of SEWD,
i.e. starting backward scheduling from the stock exhaustion date (SED) several
time components (i.e. Supplier Lead time, BOD Internal Lead Time, Safety days
and a general buffer—which can be defined in customizing—is optionally
subtracted. Figure 12.22 shows the corresponding customizing screen, which can
be accessed via path Advanced Planning and Optimization ! Supply Chain
Planning ! Service Parts Planning (SPP) ! Supersession ! Settings for Calcu-
lating Supersession Times
Fig. 12.22 Customizing settings for determination of final date
Reports Supporting the Supersession Service

The Supersession Obsolescence report /INCMD/SUSOBS_UPDATE is responsible
to save performance. It indicates all supersession chains as obsolete, whose SED
and SEWD are passed. This way these supersession chains are filtered out by the
package creation method when running the supersession service. Therefore the
planning is more efficient and faster. SAP recommends running the service
regularly.
The Supersession Cutover report /SAPAPO/SPRS_CUTOVER supports to han-
dle old out-dated supersession chains which are loaded from legacy systems into
SPP during cutover. Once all the supersession chains are loaded into SPP, the report
evaluates them one-by-one and if the predecessors have no more stock and orders, it
saves SED, SEWD and Final Date as today. It can then manipulate the SPPD to
create a pseudo-sequence for realignment. This means the SPPD of the chains in
sequence will have 1 day difference in the correct order.
Without this report the same effect could be only achieved by using the super-
session service in several steps and therefore would be much slower. The report
only needs to be run at once.
12.4 Realignment for Supersession
The purpose of the realignment step within supersession is to provide the successor
product with a data history in order to enable forecasting and inventory planning for
the successor product. The service profile for realignment is defined with the
customizing path APO ! Supply Chain Planning ! SPP ! Forecasting ! Define
Service Profile for Reorganization of Demand History, Fig. 12.23.
Fig. 12.23 Realignment service profile for supersession
The entry ‘days in the past’ indicates how far the SPPD is allowed to be in the
past in order to be still considered in realignment. If the SPPD is not reached, no
realignment is performed. In case this parameter is set to zero then it is
recommended to run the realignment service daily.
As the result of the realignment step the history for forecasting is created for the
successor product. This includes the changes for the demand history in
9ADEMMUL—which is used by forecasting—but not on the item level in
9ARAWMUL. The history is displayed with the transaction /SAPAPO/SPPDMDH.
12.6 DRP with Supersession 365
12.5 Stocking/De-Stocking with Supersession
Even after SED is reached for the predecessor this does not mean that its stocking
indicator is set to NS. If one wants it to be set to NS this needs to be done via
stocking/de-stocking (or surplus and obsolescence planning). The question in
stocking/de-stocking in respect to supersession is, when the changes of the replen-
ishment indicator in the predecessor location product and the successor location
products are set.
As soon as SPPD is reached a trigger-based realignment is executed in order to
transfer the demand from the predecessor to the successor. This again causes the
generation of the trigger SPP_RLG_DONE for the successor product, which
initiates the replenishment indicator to be set to ST by the following stocking
service. So, from SPPD on all products involved in the supersession chain are
normally planning relevant. This will stay until the predecessor products will be set
to NS either manually or triggered by surplus and obsolescence planning decision
(but that might take some time). Generally there is no need to set the replenishment
indicator of the predecessor immediately back to NS, e.g. because after the SED
some stock of the predecessor could suddenly appear due to return from customer or
because of inventory differences. Then the deployment or other SPP planning
services should still have the chance to detect this stock and to use it for certain
purposes including e.g. scrapping.
12.6 DRP with Supersession
DRP starts with the procurement of the successor product at the SPPD. The idea of
service parts planning with supersession is to determine this date in such a way that
the supply for the predecessor product covers the demand for the predecessor
product and the successor product is only procured for the demand of the successor
product. Usually there are differences between the plan and the reality, and in this
case it is desired to use the supply of the predecessor to cover the demand of the
successor—or the other way around.
Substitution Orders
To model the coverage of one product by the other substitution orders
are created. The characteristic of substitution orders is that they are a supply
for one product and a demand for the other. Thus they virtually transfer the
supply from stock and receipt elements from the predecessor to the successor
(until SED is reached). Figure 12.24 shows the substitution orders in the
DRP matrix. In this case the substitution order uses supply of the predecessor
product IS1_HALB_0004@QU6715 to cover demand for the successor product
IS1_HALB_0006@QU6715.
Fig. 12.24 Substitution order in the DRP matrix
Using the function for details it is possible to display the substitution order,
Fig. 12.25.
Fig. 12.25 Substitution order detail
12.6 DRP with Supersession 367
The substitution orders exist solely in SAP APO™ and have no corresponding
object in SAP ERP™. The prerequisite for DRP to create substitution orders is that
the interchangeability direction is of type “full”.
Limited Consideration Between SPPD and SED

As result of the realignment the history of the preceding product was copied to the
succeeding product. In the subsequent processes forecast and EOQ and safety stock
planning have been performed for both the predecessor product and the successor
product. In order to prevent an unlimited double procurement the net requirements
planning is restricted for products involved in supersessions as shown in Fig. 12.26.
Fig. 12.26 Horizons for DRP with supersession
After the DOLND of the predecessor no planning is performed any more for the
predecessor. Until the SED still the full forecast of the predecessor is considered but
from SPPD on only a portion of the successor’s forecast at the same time,
i.e. between the SPPD and the DOLND only the difference between the forecast
of the predecessor and the successor is relevant for the planning of the successor
product in order to avoid double procurement. Within this period for the determi-
nation of the successor’s forecast its actual forecast is subtracted from the
predecessor’s forecast of the same bucket. The difference is taken for planning
purposes. This works only with full precision as long the supersession chain is of
type 1:1. The reason is that in case of 1:n still the complete predecessor’s forecast is
subtracted (instead of 1/N) from the successor’s forecast. This deficit becomes more
decisive the bigger n becomes.
12.7 Deployment with Supersession
Due to the fact that a deployment run has an integrated DRP run inside,
deployment behaves in a similar way like DRP in respect to supersession.
Deployment fulfills all demand of the predecessor on child locations that have
their demand date before the SED with stock of the same predecessor. Demands
later than this date stay unfulfilled. This applies also to backorders, i.e. sales order
items whose material staging date based on requested delivery date is beyond the
SED. As far as the successor is concerned, demand over lead time is considered
by the deployment run as if the product was not in an active interchangeability
group. That is valid totally independent from the dates determined by
supersession.
Consider a situation of a demand for the successor with demand date later than
SED. At the same time no stock is available at the successor but stock on the
predecessor is available (e.g. due to unplanned overdelivery by supplier e.g.). In
case of full interchangeability DRP would create substitution orders as described
in the previous section. In deployment service there is the option to consider these
substitution orders as receipt and therefore as part of the distributable quantity in
the deployment decision or not. If not, the stock of the predecessor stays unused
and the demand for the successor stays unfulfilled by deployment. In case the
demand element is a sales order a workaround is to use rules-based ATP with
product and location substitution in order to “find” the appropriate available stock
on the parent location of the customer facing location, where it originally was
“ignored” by deployment. So, if the setting in the service profile is as it is shown
in Fig. 12.27 then deployment is “blind” for substitution receipts.
Fig. 12.27 Supersession-specific deployment setting: include substitution order quantity
12.7 Deployment with Supersession 369
If the parameter is set active then the distributable (deployable) quantity is

increased by the substitution orders accordingly. For the portion of the substitution
order the stock transfer is created for the predecessor (though there is no demand at
the target location). The interpretation of this result requires a good knowledge
about the current product substitutions.
This is explained in the following with an example in Fig. 12.28 that shows the
DRP matrix for predecessor and successor at both the source and the target
locations.
Fig. 12.28 Example on including substitution receipts into available deployment quantity
In this example deployment takes place from SPB1 (source) to SPB2 (target).
There is a demand of 100 units on the successor product
IS1_HALB_0006@QU6715 on the child location SPB2. At the source resp. the
parent location SPB1 there is available quantity (initial warehouse stock) of 10 units
on the successor product IS1_HALB_0006@QU6715 and 80 units on the prede-
cessor product IS1_HALB_0004@QU6715—so in total 90 units out of the required
100 units can be supplied. As explained before, deployment will create two stock
transfers, a stock transfer of 10 units for the successor IS1_HALB_0006@QU6715
and another stock transfer of 80 units for the predecessor
IS1_HALB_0004@QU6715. This result is displayed in SPP as follows:
– in the target resp. child location the receipts from the stock transfers are
displayed ‘as they occur’, i.e. receipts of 80 units for the predecessor (2b) and
10 units for the successor (1). The supersession relation is not reflected which
leads to shortage of 90 units at the successor (instead of 10 units) and a surplus of
80 units at the predecessor.
– In the source resp. parent location the supersession relation causes the creation of
a substitution order as a substitution demand at the predecessor and a substitution
receipt at the successor (2b). Unfortunately this leads to a doubling of the
demand at the predecessor as well as to a doubling of the receipts at the successor
so that it seems as if there was a shortage at the predecessor and a surplus at the
successor.
So the situation in the DRP Matrix appears to be a little bit misleading.
12.8 Inventory Balancing with Supersession
When the POD is reached the trigger SPP_SUPERSESSION is set for the prede-
cessor that initiates the inventory balancing for the respective product. This is
applicable only for products that are superseded with a use-up-strategy which is
not “no”. The inventory balancing for the preceding product reduces its effective
excess check horizon in order to allow the inventory to be distributed. As a result
stock transfers from the child locations with an excess get created to their parent
location as well as among the child locations.
12.9 Interchangeability with FFF-Classes
The other interchangeability type supported by SPP is the FFF class. It is a group
combining products which are fully exchangeable due to fact that they are almost
identical in regard of e.g. form, fit and functions—at least from a perspective of
planning and sales needs. The FFF class has no validity period. Therefore all
members are interchangeable with each other in any point in time.
Therefore all the dates which play a decisive role in the supersession chain do
not exist in this case and therefore the interchangeability logic applied for FFF
classes is different. If a demand arises for a product which is not available then the
system can search for any available alternative within the FFF-classes and therefore
the delivery will be most probably right in time.
Master Data of FFF Classes

The fully exchangeable parts are grouped in a FFF class. This FFF class consists of
several FFF subsets for, each location of the BOD- and declares one part of the
group as leading part. The leading part must be the same across all the FFF subsets
of a FFF class. The maintenance is accessed with the same transaction as in case of
a supersession chain, which is /INCMD/UI, Fig. 12.29.
12.9 Interchangeability with FFF-Classes 371
Fig. 12.29 Master data of FFF class
When entering the transaction first the group type for FFF class has to be
selected before getting offered the right display or maintenance UI for FFF classes.
From the “details”-view in this UI the subsets of a FFF-class is accessed.
Fig. 12.30 Master data of FFF subsets
Figure 12.30 shows the overview of the corresponding subsets of the FFF class
(group 47 as shown in Fig. 12.25). Each has an own subset ID (FFF subset numbers
56 to 61). When clicking on the hyperlink of the ID the details can be accessed as
Fig. 12.31 shows.
Fig. 12.31 Details of FFF subset master data
The FFF subset is subdivided into a header part, which contains the definition of
the leading part, and into a member part, which contains all the interchangeable
location products. Further details of FFF-classes can be found in Dickersbach,
Supply Chain Management with APO 2008.
DRP with FFF-Classes

The logic of DRP and the corresponding net requirements calculation is different
than in the case if supersession chains. Figure 12.32 illustrates that netting among
the members of a FFF subset takes place on a certain location level (here: child
locations SPB2 and SPG1) before any potential remaining net demand is rolled up
to the next parent. The result of the netting is either net demand or an excess supply,
where the excess is the projected stock minus the safety stock. Since all demands
and receipts are aggregated on the leading product, a potential net demand can only
be rolled on the level of the leading product. As a prerequisite of the consolidated
netting on the level of the leading part, substitution orders are generated from or to
the leading part. Consequently there are never substitution orders between
non-leading parts. There is no such logic for virtual child locations. Demand on
the virtual child location is consolidated in the BOD in the usual way as described in
Chap. 8.
Fig. 12.32 Illustration on demand and supply netting among FFF subsets members on location
level
Figure 12.32 shows that once the net demand was rolled up in the next step the
netting takes place on parent level—here location SPB1. Netting is managed by
transferring demand or excess supply from one member part to the other via
substitution orders. These orders are represented as ATP-category GB (demand at
the source location part) and GA (receipt at the receiving location part. This is
Fig. 12.33 Example on demand and supply netting via substitution order (part 1)
The figure furthermore shows the stock and demand situation of one of the
non-leading parts IS1_HALB_0008. There is physical stock of 10 units available
today on the 11th June. On the 12th June there is a planned fixed requirement of
77 units as well as a fixed demand of 20 at 13th June. Even though the stock
could easily be used for partly fulfilling the demand of 77 units on the following
day, the netting logic nevertheless virtually transfers the stock to the leading part
for the time being. Reason for that is that the netting should take place on the
leading part per definition and the BOD-internal or the external procurement
would takes place on the level of this leading part, if overall net requirement
would be left over.
Figure 12.34 shows that on the following day a demand of 77 units (derived from
the fixed demand of the non-leading part IS1_HALB_0008) needs to be fulfilled by
substation orders. This causes a substitution demand on the level of the leading part
IS_HALB_0009, which then partly consumes the substitution receipts in the over-
due column of Fig. 12.33.
Fig. 12.34 Example on demand and supply netting via substitution order (part 2)
For products that are members of an active FFF-class the DRP planning run
needs to be executed with a separate DRP planning profile. The reason for this is
that these products need to be treated with a different package creation method,
which is specified in separate PSM process profile as Fig. 12.35 shows. This process
profile is then part of the DRP planning profile.
Fig. 12.35 Example of FFF class specific PSM process profile
Inventory Balancing with FFF-Classes

The inventory balancing logic for products which are part of a FFF-subset differs
from the standard logic. The main difference is that in the course of a cost-benefit-
analysis not only the corresponding information of one particular product—e.g. the
leading part—is taken into account but of all products that are involved in the
FFF-subset. The prerequisite of the application of this specific logic is that all
non-leading product of an excess location need to be also members of the subset of
the shortage location in the respective balancing area. If this is the case inventory
balancing creates stock transfers in the usual way also for the non-leading products.
Capture/Manage Demand and Forecast with FFF-Classes

Member parts of a FFF-subset are treated by the capture and manage planning
service as well as by forecast service of any kind as if they were not members of
FFF-subsets.
Sales Order Fulfilment
13
Within service parts management two scenarios for sales order fulfilment exist:
sales from stock and third party order processing (TPOP). Depending on the system
landscape—whether SAP CRM™ or SAP ERP™ is used for sales order taking—
only sales from stock is possible, since TPOP requires SAP CRM™.
Sales from stock is the common scenario where a sales order is confirmed (and
delivered from) based on available stock. If service parts planning has been
performed properly, this should be possible—unless it was decided that the cus-
tomer facing location should not contain any stock (see Chap. 4). In this case—or if
the customer demand exceeds the forecast and the safety stock—it is checked
whether any other distribution centre within the supply network is able to confirm
the sales order. For the check within the supply network (i.e. the BOD) rules-based
ATP is used. In the second scenario, third party order processing, the service part is
procured directly from the supplier to the customer. Neither scenario is part of
service parts planning, but at least the more straightforward scenario of sales from
stock is briefly introduced in order to complete the picture from a supply chain
management point of view.
In the following we describe the order fulfilment process for service parts
management in the full blown version including the four systems SAP CRM™
for sales, SAP APO™ for the rules-based ATP check, SAP ERP™ for the
processing of the deliveries and SAP EWM™ for goods issue. Figure 13.1 shows
the process overview of sales order fulfilment and the document flow between the
systems. The process starts with the creation of the sales order in SAP CRM™ and
the call of rules-based ATP in SAP APO™. Assuming that there is sufficient stock
on hand, the sales order item is confirmed, and the sales order is saved in SAP
CRM™. This sales order is transferred to SAP APO™ and to SAP ERP™. In SAP
APO™ it is a sales order as well but in SAP ERP™ it is reflected as an unchecked
delivery. Changes in the sales order will be transferred to both SAP APO™ and SAP
ERP™. The next step is to process the unchecked deliveries in SAP ERP™—i.e. to

378 13 Sales Order Fulfilment
create a (normal) delivery for the unchecked delivery. At this point in time the ATP
check is performed again, but not necessarily in SAP APO™. As result a delivery is
created and sent to SAP APO™ (where it replaces the sales order) and to SAP
EWM™.
Fig. 13.1 Sales order processing—process overview
In SAP EWM™ the delivery is first reflected as an outbound delivery notifica-

tion but can be activated in the background to become an outbound delivery order.
For the outbound delivery order a warehouse task and subsequently a warehouse
order is created and confirmed in SAP EWM™, and goods issue is posted. The
posting of the goods issue is then transferred to SAP ERP™ and from SAP ERP™
to SAP APO™.
13.2 Sales Order Taking
13.2.1 Basic Sales Configuration for SAP CRMTM
The purpose of this paragraph is to provide a very rough overview about the entities
which are required for sales order processing in SAP CRM™ for someone who is
only familiar with SAP ERP™ and SAP APO™.
13.2 Sales Order Taking 379
The organisation structure for sales, the order types and the item categories are
created in SAP ERP™ and transferred to SAP CRM™. The order type in SAP
ERP™ corresponds to the transaction type in SAP CRM™. Figure 13.2 shows the
correspondence of these entities. In SAP CRM™ up to three transaction types can
be assigned per user in the user profile and are displayed in the icon bar.
Fig. 13.2 Basic configuration in SAP CRM™
The ATP profile in SAP CRM™ corresponds to the requirements profile in

SAP APO™ (see Sect. 13.3). There is however no integration for these settings,
therefore it has to be ensured during the implementation that corresponding
entities exist with the same name. The ATP profile is defined in SAP CRM™
with the customising path CRM ! Basic Functions ! Availability
Check ! Availability Check Using SAP APO ! Define ATP Profile and assigned
to the item category with the customising path CRM ! Basic
Functions ! Availability Check ! Availability Check Using SAP APO ! Assign
ATP Profile to Item Category, Fig. 13.3. The ATP profile in SAP CRM™ does
not contain any information and is only used to select the requirements profile in
SAP APO™.
Item Category
ATP Profile
© SAP AG
© SAP AG
Fig. 13.3 Assignment of the ATP profile to the item category
The transaction type in SAP CRM™—which corresponds to the order type in

SAP ERP™—is maintained with the customising path CRM ! Transac-
tions ! Basic Settings ! Define Transaction Types, and the item category with
the customising path CRM ! Transactions ! Basic Settings ! Define Item
Categories. Finally, the assignment of the item categories to the transaction type
is performed with the customising path CRM ! Transactions ! Basic
Settings ! Define Item Category Determination as shown in Fig. 13.4.
Fig. 13.4 Assignment of item categories to the transaction type
13.2.2 Sales Order Taking in SAP CRMTM
Sales orders in SAP CRM™ are created with the transaction CRMD_ORDER as
shown in Fig. 13.5. In this example the transaction type ‘XX sell from stock’ is used
for a sales order of ten pieces of the material ZZXX_SPARE. The confirmed
13.2 Sales Order Taking 381
quantity is the result of the rules-based ATP check in SAP APO™. Other results of
the rules-based ATP check are the creation of a sub-item (for the same material) and
that the delivering plant is entered in the field ‘vendor’. This information is
transferred from SAP APO™.
Transaction Type Order Number
Item
Sub-Item
© SAP AG
Delivering Plant
Fig. 13.5 Sales order in SAP CRM™
In the sales order not only the requested and confirmed dates are recorded but
also the times—differing from SAP ERP™. Figure 13.6 shows the schedule lines
for this sales order.
Fig. 13.6 Schedule lines in the SAP CRM™ sales order
Sales Order in SAP APO™

The sales order is transferred to SAP APO™ and displayed in the product view
(transaction /SAPAPO/RRP3) as shown in Fig. 13.7. Two lines are displayed for
the sub-item, one with the request and one with the confirmation. The main item is
not transferred at all.
Fig. 13.7 Sales order in SAP APO™
13.3 ATP Check
Depending on the settings in the item category (see Fig. 13.3) SAP CRM™ calls the
rules-based ATP check in SAP APO™. In order to display the result of the ATP
check the user parameter APO_ATP_PARA has to be set to ‘5’ in SAP CRM™.
Fig. 13.8 Requirements profile in SAP APO™
Requirements Profile
Since SAP CRM™ does not have a requirements class, the parameters for the ATP
check in SAP APO™ are defined in the requirements profile. The sales order in
SAP CRM™ contains only the ATP profile, and the name of the ATP profile is used
to select the requirements profile in SAP APO™. Figure 13.8 shows the
13.3 ATP Check 383
requirements profile which is defined in the SAP APO™ customising with the path
APO ! Global ATP ! General Settings ! Maintain Requirements Profile.
In SAP CRM™ there is no connection between sales organisation and/or
material to a delivering plant. Therefore the start location—the location where
the first ATP check is performed—is determined by SAP APO™ using rules-based
ATP. The rule strategy for the rule to determine this start location is also maintained
in the requirements profile.
Rules-Based ATP with SAP CRM™

For the service parts management scenario two rules are required: one to determine
the start location for the ATP check and another rule for location substitution (and
product substitution if supersession is used). This makes the configuration of the
rules-based ATP check more complex than usual. Figure 13.9 shows the settings for
this configuration.
Fig. 13.9 Parameters for the rules-based ATP check in SAP APO™
The sales order from SAP CRM™ contains an ATP profile. With the ATP profile
the requirements profile in SAP APO™ is found, and from the requirements profile
the rule strategy and the first rule to determine the start location.
Now the information is complete to perform an ATP check in SAP APO™:
Material and action from the sales order, start location from the first rule and check
mode from the requirements profile or the product master. If it is defined in the
check instructions to perform a rules-based ATP—as required for the service parts
management scenario—additionally the technical scenario and the business trans-
action is taken from the requirements profile.
Rule for the Determination of the Start Location

The rule for the determination of the start location contains a location substitution
procedure which contains the start location as the only location. The difference to
the ‘normal’ location substitution procedure as used in the rules-based ATP is that
the type of the procedure has to be ‘3’ (list for CRM). Figure 13.10 shows a location
substitution procedure for the determination of the start location.
Fig. 13.10 Location substitution procedure for the determination of the start location
Rule for Rules-Based ATP

The rule for rules based ATP contains another location substitution procedure of the
type ‘0’ where a sequence of locations is maintained. With this type of location
substitution procedures at least two locations are required, Fig. 13.11.
Fig. 13.11 Location substitution procedure for rules-based ATP
The properties and settings for rules-based ATP and location substitution are
described in the literature (Dickersbach 2008).
Check Instructions
Among the rules-based ATP settings within the check instructions the parameter
‘create sub-item’ has to be selected in order to ensure a smooth integration with
SAP CRM™, Fig. 13.12.
13.5 Goods Issue 385
Fig. 13.12 Check instructions for rules-based ATP
13.4 Processing of Unchecked Deliveries
The sales order is transferred from SAP CRM™ to SAP ERP™ as an unchecked
delivery. This unchecked delivery is however not displayed in the stock/
requirements list. Therefore the stock/requirements list does not show the correct
requirements situation. These unchecked deliveries are only displayed with the
transaction VL06U.
The delivery is created in SAP ERP™ as a subsequent document to the
unchecked delivery (instead from the sales order as in the straightforward SAP
ERP™ sales order fulfilment process). The transaction to check the unchecked
deliveries and convert them to deliveries is VL10UC.
13.5 Goods Issue
The goods issue is posted in SAP EWM™. The prerequisite for the goods issue is
that the delivery is transferred to SAP EWM™ as an outbound delivery order.
Based on this outbound delivery order a warehouse task is created and a warehouse
order is created and confirmed before goods issue is posted. Figure 13.13 shows
these steps.
Outbound Create
Delivery Order Warehouse Task
Warehouse Task
Create
Warehouse Order
Warehouse Order
Confirm
Warehouse Order
Warehouse Order
Post Goods Issue
(Confirmed)
Goods Issue
Fig. 13.13 Steps for posting goods issue in SAP EWM™
The outbound delivery is displayed in SAP EWM™ with the transaction/

SCWM/PRDO. It is possible to use the delivery number from SAP ERP™ as a
search criterion. Figure 13.14 shows the SAP EWM™ outbound delivery order to
the SAP ERP™ delivery 80008837.
Fig. 13.14 Outbound delivery order in SAP EWM™
If the outbound delivery order is not found, one possible reason is that the wrong
warehouse is selected. The warehouse is changed with the menu path
Settings ! Default Values as shown in Fig. 13.15.
Fig. 13.15 Change the warehouse
Warehouse Task
In the next step a warehouse task is created for the outbound delivery order with the
menu path Outbound Delivery Order ! Follow-On Functions ! Warehouse Task,
Fig. 13.16.
Fig. 13.16 Create warehouse task
Figure 13.17 shows the request for the warehouse task with the warehouse
request number 46117.
Fig. 13.17 Warehouse task
In the details of the warehouse task the default values for the source bin and the
destination bin are maintained, Fig. 13.18.
Fig. 13.18 Default values for warehouse task
These default values are required for the creation of the warehouse task. Fig-
ure 13.19 shows the steps for the creation of the warehouse task.
© SAP AG
© SAP AG
Fig. 13.19 Necessary steps for creating a warehouse task
Warehouse Order
Based on the warehouse task it is possible to create a warehouse order as Fig. 13.20
shows.
Fig. 13.20 Create warehouse order
In the next step the warehouse order is confirmed with the transaction /SCWM/
TO_CONF, Fig. 13.21.
1 2
© SAP AG
© SAP AG
Fig. 13.21 Confirmation of the warehouse order
Finally the goods issue is posted with the transaction /SCWM/PRDO as

Fig. 13.22 shows. The goods issue is transferred to SAP ERP™ and from SAP
ERP™ to SAP APO™.
Fig. 13.22 Goods issue
Monitoring and Reporting
14
14.1 Monitoring and Reporting Overview
Within the service parts management solution different tools exist for monitoring
and reporting. Monitoring is used to observe the supply chain in order to help the
planner intervening in case of imbalances and other problems. Imbalances are
shown in the shortage monitor, and for other problems the alert monitor is used.
Both tools are in SAP SNC™ and allow the supplier to have a look at the
imbalances and other problems that concern him. As a third tool in SAP SNC™,
the SPP cockpit provides an overview of the planning situation of a service part
within the BOD—e.g. stock, stock in transit, forecast etc. The data for monitoring in
SAP SNC™ is read mainly from tables that are used (and filled) by SAP APO™
applications.
Another tool, which embraces all the single tools mentioned and combines them
in an overviewing cockpit is the Planner Worklist. It also combines monitoring
tasks with the possibility of gathering additional information and with the possibil-
ity of executing necessary planners-typical actions
Reporting on the other hand is used to evaluate the performance of the supply
chain on a regular basis. The major information is the outbound performance
towards the customers (here the service level is the most important KPI), the
performance within the supply chain (e.g. whether the planned lead times are
kept) and the performance of the suppliers. The information of the reporting is
used for medium- or long-term structural and strategic decisions.
These reports are available as business content in SAP BI™. The data basis for
these reports is pre-processed in SAP SCM™ before it is transferred for reporting to
SAP BI™.

392 14 Monitoring and Reporting
14.2 Planner’s and Customer’s Worklist
14.2.1 Overview of Planner’s and Customer’s Worklist
For both the planner and the customer—usually dealer—SPP provides an entry point.
The planner’s worklist is the entry point for the planner and a composite application
cockpit that gives an overview of the monitoring results and alerts. It also allows the
planner to perform actions like approving orders directly in order to support him in
the daily routine work, but also in expediting and firefighting. For more details it is
possible to navigate from the planner’s worklist to the respective transactions.
Analogously the customer’s worklist provides an overview for the customer.
The various monitoring tools are used by the planner separately and in parallel in
order to get the right insight and all the necessary perspectives about the situation of
his respective area of responsibility. Besides the planner needs to check on a regular
basis whether some actions are required in order to intervene where necessary. The
options to intervene are scattered in different transactions. In order to consolidate
and simplify the workflow the planner’s worklist combines all the necessary
information in one place, provides the user a general overview of the work environ-
ment and is a starting point for any necessary confirmative and corrective action. It
is based on webDynpro technology and appears in a web-based way accordingly.
The planner’s worklist contains different queries and offers flexible selection
criteria and layouts. Furthermore there are functions integrated in the work list that
allow to either to perform necessary actions directly or to navigate to the relevant
transactions—in order to see more details or to execute the required action there.
But already the work lists itself contains quite a lot of information, and it can be
extended by individual configuration. This additional information is known as
‘detail components’. Detail components and the related business context viewer
are described in more detail later in this chapter.
The available queries are grouped into categories that indicate their purpose. The
three categories are monitoring, alerts and action required as shown in the starting
page of the Planner’s Worklist, Fig. 14.1.
Fig. 14.1 Starting page of the planner’s worklist
14.2 Planner’s and Customer’s Worklist 393
The planner’s worklist can be restricted by various selection criteria like prod-
uct, location, planner, product group etc. The criteria depend on the query.
The user groups that are addressed by the worklist are on one hand the planners
inside the own company. On the other hand information is provided for customers
as dealers or service providers who are replenished through OEM managed inven-
tory (see Chap. 15) and are represented as locations of location type 1010. Accord-
ingly there are two different worklist application types, the planner’s work list and
the customer’s work list. The customer’s worklist includes much less queries than
the planner’s worklist since not all information is necessary or appropriate for
publication to the customer.
The planner’s worklist is accessed via the transaction /SAPAPO/
SPP_PLN_LIST or via logging in to the SAP NetWeaver Business Client
(NWBC). Access via NWBC is the preferable option because some functions are
only available using NWBC.
The core of the planner’s worklist is the queries. These provide the planner a
consolidated overview about situations of interests or of necessary deeper investi-
gation and give guidance on where actions are required. The queries are categorized
as ‘monitoring’, ‘alerts’ and action required’. In the SPP version as delivered by
SAP there exist 15 queries, i.e. 6 queries of category ‘action required’, 3 queries of
category ‘alerts’ and 6 queries of category ‘Monitoring’. Part of each query is the
selection criteria, which can be pre-specified upfront and saved. Furthermore the
layout of each query can be modified and personalized. Personalization means that
the appearance of the worklist is changed as far as the visibility of the queries, their
names, their sorting and positioning and the availability of the selection criteria is
concerned. Also additional queries can be created by the user. The headline of one
example is shown in Fig. 14.2 where it is marked in the box with dotted lines.
By clicking on the hyperlink of the headline of a query the respective detailed
information opens in the lower section as can been seen in Fig. 14.2.
Fig. 14.2 User defined query for display of STOs
14.2.2 Action Required Queries in Planner’s Worklist
An example of the category ‘action required’ is the query ‘STO Approval’ as shown
in Fig. 14.3. In a personalized query all STOs for a specific selection are displayed
that are subject to approval or rejection. When selecting a STO the possible actions
for this order are offered to planner—in this case ‘approve’ and ‘reject’. These have
the same effect as if done directly with the transaction /SAPAPO/SPPDEPL as
described in Chap. 10. Additionally it is possible to navigate to the SPP Cockpit
(see Sect. 14.5), the interactive inventory planning screen (equivalent to transaction
/SAPAPO/SPPINVP) or to the DRP-matrix.
Fig. 14.3 STO approval in planner’s worklist

Another example for a query of the ‘action required’ category is the stocking/
destocking approval. As described in Sect. 4.4, after a stocking or destocking
planning service has been executed and the replenishment indicator has been
changed this decision can be finally approved by the planner. Using the planner’s
worklist the planner is informed about this pending decision via the corresponding
query as shown in Fig. 14.4.
Fig. 14.4 Stocking/De-stocking approval in planner’s work List
Navigation is done for the selected location product with the ‘stocking /
de-stocking approval’ button. The approval screen shows all location products of
all locations that are part of the BOD. All old and new replenishment indicators of
this location product are displayed and are ready to be approved or rejected by the
planner. The action taken here has direct impact on the parameter of the
master data.
For additional information the navigation to the SPP Cockpit and the
product detail is available, Fig. 14.5. These tools are explained in Sects. 14.5 and
14.6. Moreover the whole content can be printed from here or exported to MS
Excel.
Fig. 14.5 Planner’s work list: navigation from query to SPP cockpit
Table 14.1 gives an overview of the queries that are used for ‘actions required’.
Good further and detailed explanation is given in the SAP online help.
Table 14.1 Overview on all queries of category “action required”

Query Purpose of query Navigation away to
Stocking/ Providing an overview of the stocking/destocking • SPP Cockpit
destocking information for the planner, containing all pending • Product detail
approval approvals. These can be approved by navigating to • Stocking/
the stocking / destocking approval UI destocking approval
UI
Forecast Providing an overview of all forecasts which are • Forecasting
approval subject to approval • DRP
• Inventory planning
• Product detail
Procurement Providing an overview of all procurement • Order maintenance
approval documents which are subject to approval (Schedule board)
• Product detail
• SPP Cockpit
• Shortage monitor
STO approval Providing an overview of all procurement • Deployment/
documents that are subject to approval invent bal.
• Product detail
• SPP Cockpit
Safety stock Providing an overview of all location products that • Deployment/
approval have a newly determined safety stock quantity inventory bal.
assigned and are subject to approval • Product detail
• Inventory planning
• Forecast
• DRP
14.2.3 Alert Queries in Planner’s Worklist
The ‘alerts’ category shows a statistical overview of alerts similar to the ‘statistical
view’ of the alert monitor (see Sect. 14.4). There have to be multiple work lists for
alerts because the order of the key fields are different and influence directly the
statistical result. Therefore there are two queries in the ‘alerts’ category. The
category-based overview of all alerts types (DRP, supersession, surplus and obso-
lescence etc.) shows the number of alerts per alert type and their priorities and
whether they are new, in process, completed or retained. It is possible to navigate to
the underlying alerts in the alert monitor for further analysis and processing,
Fig. 14.6. The alert monitor is described in Sect. 14.4.
Fig. 14.6 Planner’s work list: navigation from alert query to alert monitor
For the product-based alert queries the primary grouping criterion for the alerts
is the location product and therefore gives a different perspective to the alerts in the
supply chain.
The third alert query is location-based as shown in Fig. 14.7.
Fig. 14.7 Location-based alert query
14.2.4 Monitoring Queries in Planner’s Worklist
As an example for the category ‘monitoring’ the query ‘stocking/de-stocking’

shows specifically the replenishment indicator as it appears to be before and after
a stocking planning run. Additional information like the assigned BOD and the
stocking stability period helps the planner to understand the result of the stocking
planning service. After selection of a row of interest the navigation options to other
monitoring screens and tools—in Fig. 14.8 the SPP cockpit and the product detail—
become active. Navigation is only available when accessing the worklist via the
NWBC.
Fig. 14.8 Monitoring query: possibilities of navigation to other SPP monitoring tools
Another useful case of monitoring a certain situations via the worklist is the
focus on critical and non-critical products.
Fig. 14.9 Monitoring query: critical products
Figure 14.9 shows certain key figures like days supply or the sum of the
backorder quantity per location product attached to the products that are classified
as critical or non-critical. The shortage status is derived from the result of the
shortage analysis, where the criticality of a product is determined as described in
Sect. 16.6. From the critical products query the planner can navigate to the product
detail, the SPP cockpit and to the shortage monitor. Especially the shortage monitor
is an appropriate tool for analysis of critical products (see Sect. 14.3). In Fig. 14.10
the beginning criticality of the product is caused by an overdue sales order with the
order number 460.
Furthermore there is the possibility of postponing the period of observation by
setting an on-hold-date. This causes the entry to re-appear again at that date—or
until the planner sets manually the indicator “viewed” as active as can be seen in
Fig. 14.10 in the box with dotted lines.
Fig. 14.10 Planner’s work list: navigation possibility from critical products to shortage monitor
Table 14.2 gives an overview of the queries that are used for ‘monitoring’.
Table 14.2 Overview of all queries of category “monitoring”

Query Purpose of query Navigation away to
Surplus Providing an overview of products which have • Product detail
surplus. The column structure of the work list is • Surplus and
based on the header component of the ‘Surplus obsolescence
and Obsolescence Approval UI approval
• SPP Cockpit
Stocking/De- Providing an overview of stocking/destocking • SPP Cockpit
Stocking information for the planner. The main • Product detail
information is to show the replenishment • Stocking/
indicator value and the related change destocking
information. In addition it is shown whether the approval UI
stocking / destocking has to be approved
Procurement Providing an overview of all procurement • Order
documents independent of their status. The maintenance
planner has no means of approval or rejection • Product detail
• SPP Cockpit
• Shortage monitor
STO Providing an overview of all STOs, including • Deployment/
unserviceable STOs and OEM-Managed Inventory Bal.
Inventory STOs • Product detail
• SPP Cockpit
Critical products Providing an overview of all critical/potentially • Product detail
critical products based on the shortage analysis. • SPP Cockpit
The column structure of the work list is based • Schedule board
upon the columns of the shortage monitor • Shortage monitor
‘location product view’
It is possible to save entries as “viewed” and “on-
hold”
Supplier overview Providing an overview of all critical/potentially None
for critical products critical products based on the shortage analysis
aggregated on supplier level. The column
structure of the work list is based on the columns
of the supplier overview of the shortage analysis
Critical sales orders Providing an overview of all critical sales orders. • Product detail
These are defined as sales orders with a backorder
quantity > 0
14.2.5 Customer’s Worklist and its Queries
The customer’s worklist is called via WebUI from outside the firewall of the SPP
system with the generic URL “http://<Host-Name>:<Port-Numbers>/sap/bc/
webdynpro/sapapo/puia_dealer_worklist?sap-language ¼ <Language>” (host name,
port number and language as indicated in <>-brackets have to be defined customer-
specifically). The start page of the log in is shown in Fig. 14.11.
Fig. 14.11 Log in to SAP NetWeaver business client (NWMC)
Alternatively the customer’s worklist is accessible with transaction /SAPAPO/

SPP_DLR_LIST.
A prerequisite for web access is to have the netweaver business client (NWBC)
installed either locally (at the customer’s PC) or on a WTS at the OEM.
Another decisive prerequisite is that the customer has a user and a profile in SPP.
This user is assigned to an internet user, which again has to be assigned to a business
partner with transaction BP. The business partner can be assigned to one or multiple
customer locations in the master data. This means that the user is able to see all data for
locations his business partner is assigned to. The relevant user does not need to be an
explicit planner in SPP and need not to be assigned to one correspondingly. The system
only checks whether the user is assigned to the right location. If optionally the user is
assigned to a planner then the system checks both whether the user is assigned to the
dealer location, and whether that the location product is applicable to the user’s planner.
The user cannot access any other screens. Therefore there is also no possibility to
navigate to other tools for more details.
There are five queries available for the customer, three of the category “Action
required” and two of the category “Monitoring”, Fig. 14.12.
Fig. 14.12 Overview on all standard query in customer’s work list
In Table 14.3 all the available queries are described in short.
Table 14.3 Overview on all queries in customer’s worklist as delivered by SAP

Customer
worklist Purpose of work list Follow-up action
Stocking/ Display the stocking/destocking Agree/disagree by button. If disagree,
destocking information for the dealer, containing an alert gets raised in order to inform
agreement all recently approved stocking/ the planner
destocking decisions by the planner
for dealer locations. The
replenishment indicator was already
changed by the planner but the dealer
will be informed of the change by this
worklist
STO Displays all VMI STOs for the dealer Approve/reject orders or change of
approval that are subject to approval or quantity accordingly and accept these
rejection changes
Excess stock Displays the excess stock of the Follow-up processes can be started by
respective location products at a the dealer with the button ’execute’.
dealer location calculated by a The follow-up logic will not be
planning service. Follow-up provided by SAP but has to be
processes can be started by the dealer implemented by a customer in a BadI
with the button ’execute’. The follow-
up logic will not be provided by SAP
but has to be implemented by a
customer in a BadI
Stocking/ Displays the stocking/destocking None
destocking information for the dealer. The main
information is to show the
replenishment indicator value and the
related change information. In
addition the information whether the
stocking / destocking has to be agreed
or disagreed will be shown
Supersession Displays information on all None
supersession chains in the customer
location that are becoming active
soon
14.2.6 Configuration of Worklists
Personal Object Worklist as a Framework

The planner’s worklist is technically based on a framework called personal object
work list (POWL) that can provide and list business objects centrally and allows
specific activities (actions) based on these business objects. This idea of centrally
providing all properties of a POWL is technically represented by one central,
standardized class—the so called feeder class. This feeder class communicates
with the database selecting specific data and forwards the data to an internal
cache and refreshes the planner’s worklist on the user’s client on demand as
illustrated in Fig. 14.13. Moreover the feeder class introduces the handling of
actions initiated by the user while pressing a button.
Fig. 14.13 Technical POWL framework
If e.g. customer specific queries are needed with an own logic they have to be
developed on the basis of a feeder class. In order to use the defined framework
functions all application feeder classes have to be assigned to a POWL Type ID that
represents the corresponding queries as shown in Fig. 14.14 where the structure of
the corresponding customizing settings is illustrated.
Fig. 14.14 Relationship of customizing tables regarding POWL configuration
The POWL Type ID on the other side is linked to the Query ID which defines the
categories, the description, selection criteria etc. The POWL TYPE ID is also
linked to the application it belongs to. This also links to the roles to which the
user is eventually assigned to.
This structure is defined in the so-called POWL Administrator Cockpit and can
be accessed via the customizing path ! Cross-Application Components !
Personal Object Worklist ! Cockpit for POWL Administration (as of SAP

NetWeaver 7.02). Alternatively the transaction POWL_COCKPIT can be used to
enter the cockpit, which is the central single point of entry to perform different
administrator activities relevant for POWL development, customizing, and testing.
Figure 14.15 shows the customizing transaction POWL_QUERY where the
query IDs are assigned to a POWL type ID.
Fig. 14.15 Part of customizing transaction POWL_QUERY
Here e.g. it is possible to hide or activate queries in general for all users. Hiding
is done by deleting the respective POWL type ID and leave the field blank as shown
in Fig. 14.15 for the example of the location-based Alerts that are represented by
POWL type ID “SPP_PLANNER_ALERTS_3”.
This configuration applies also to the customer’s worklist.
Context and Detail Information Functions

In both the planner’s worklist and the customer’s worklist there are possibilities to
integrate further information in respect to certain business objects like a product in
focus.
Detail Components
The detail component is a feature that can display further context information in one
or several form views for all the standard queries as they are named in the table in
Fig. 14.16. E.g. as standard business content SAP delivers two implementations
representing product-dependent master data information and location-product-
dependent master data information. This Business Content can be utilized in the
Planner’s Work List UI when clicking on the hyperlink of a product as shown in
Fig. 14.16.
Fig. 14.16 Detail components information in forecast approval query
In this case two so-called detail component groups are assigned to the query
“Forecast Approval”, one for product-specific data and the other one for location-
product-specific data.
The customizing for the definition of the detail component and the
corresponding assignment is found with path Advanced Planning & Optimization
! Supply Chain Planning ! Service Parts Planning ! Monitoring ! Detail
Component for Planner’s Worklist and Customer’s Worklist !Maintain Detail
Component. Figure 14.17 shows how the relevant information is derived,
i.e. which methods of which class are utilized in order to dynamically generate
the display of form view fields according to given DDIC structures. If the source of
information is distributed then more than one DDIC structure has to be specified
and assigned to a group each.
Fig. 14.17 Part of customizing of detailed component
Eventually the Group ID’s are grouped into a Detail ID. This Detail ID is
assigned to the query type ID to which it belongs to and which it supports with
the right information.
This example shows that in the course of the query “Stocking approval” the
evaluation of product-specific (Group ID G01) and location-product-specific
(Group ID G02) data is provided.
Business Content Viewer

On the other hand there are functions of the so-called Business Content Viewers
(BCVs). This is a framework which in general is available for all Business Suite
applications that are based on webDynpro ABAP as UI-application technology. The
BCVs allow these applications to integrate all kind of additional information right
into the context of an application with low effort. This information is of analytical
and supplementary type in the form of tables or graphics and is displayed in the side
panel of the respective UI. The collected data is represented in the side panel as
query views, tables or charts.
Fig. 14.18 Access to additional information in the planner’s worklist
The side panels are opened from any query in the work list by pressing the button
“additional information” as shown in Fig. 14.18.
Table 14.4 shows the standard Business Content delivered by SAP. Within the
side panel one can choose between three major topics as analytical information to
be displayed information on stock, information on alerts and shortages and infor-
mation on demand and forecast.
Table 14.4 Overview on the business content for usage in the business content viewer as
delivered by SAP
Category Query Type Query ID Chart Id
Alerts Alert Table 1SPP_QV_ALERTS 1SPP_TV_ALERTS
and overview
shortage Shortage Table 1SPP_QV_SHORT 1SPP_TV_SHORT
overview
Stock Stock Table 1SPP_QV_STOCK 1SPP_TV_STOCK
overview
Forecast History Chart 1SPP_QV_FCST_DEM_TS 1SPP_CH_FCST_DEM_TS
and
forecast
(demand)
History Chart 1SPP_QV_FCST_ITEM_TS 1SPP_CH_FCST_ITEM_TS
and
forecast
(item)
Current Table 1SPP_QV_CUR_FCST 1SPP_TV_CUR_FCST
demand
and
forecast
The stock overview is subdivided and detailed regarding the included stock
types as can be seen in Fig. 14.19.
Fig. 14.19 Overview on

stock information in BCV
side panel
Alerts and shortages are subdivided into information about the existing alert
types, their number of alerts in addition to information about the criticality status
and days of supply and open quantity of the respective product. The information is
always specific to the product or location product of the line in the main screen,
which is currently highlighted as can be seen in Fig. 14.20.
Fig. 14.20 Overview on alerts and shortages in the BCV side panel
Graphic-based information content is delivered for demand and forecast. There

is a graph for comparison of historical demand and forecast on a quantity basis.
Also a graph of the same type of comparison on the basis of number of items is
available as shown in Figs. 14.21 and 14.22.
Fig. 14.21 Graphical overview on history and forecast in the BCV side panel
Fig. 14.22 Graphical overview on history and forecast in the BCV side panel
For the purpose of configuring and adding customer-specific Business Content

the Business Configuration Center offers a dedicated WebDypro User Interface,
Fig. 14.23. This can be entered also via the transaction NWBC in combination with
the Business role SAP_BCV_ADMIN attached to the respective user. Alternatively
starting from the SAPGUI the transaction /SCF/WD_START can be used in
combination with specifying /BCV/WDA_CFG_ENTRY as the respective
WD-Application ID.
Fig. 14.23 Overview on the business configuration center
Here new content can be configured and added by e.g. creating new BAPI data
provider and testing them, configuring Search Connectors (which enable the con-
nection to the data provider), configuring BCV queries (which define the data
selection), configuring query views (which define the graphical representation)
and configuring the overview presentation (which are responsible for layout etc).
Further information is found in detail in SAP online help.
Note that the context key—if it is necessary to be specified in regard to creating
an overview and a query—is always “/SAPAPO/SPP_PW1”, which stands for
Planner’s worklist in SPP.
14.3 Shortage Monitor
All monitoring tools in SAP SNC™ are accessible from SAP SCM™ with the
transaction /SAPAPO/SPP. For an external supplier it is possible to access SAP
SNC™ via internet with a URL (Hamady, Leitz 2008).
Planning Service for the Shortage Monitor
The data for the shortage analysis is based on the service parts planning applications in
SAP APO™. The prerequisite to view this data in the shortage monitor is the prepara-
tion of this data with the planning service SPP_SHORTAGE_MONITOR. This service
does not require a service profile but a process profile with the package creation method
PRODUCT_SIMPLE. This planning service needs to be performed with the planning
service manager as for the other planning services and as described in Sect. 2.3.
Shortage Overview
The shortage overview shows at a glance the number of products with low safety
days’ supply (‘critical products’), backorders and overdue schedule lines, Fig. 14.24.
Fig. 14.24 Shortage overview
14.3 Shortage Monitor 411
The shortage overview is the default application when entering SAP SNC™ as a
planner via the transaction /SAPAPO/SPP. For more details the shortage monitor
is used.
Safety Days’ Supply for the Shortage Monitor The shortage monitor is based on
the safety days’ supply. This safety days’ supply is calculated by the planning
service SPP_SHORTAGE_MONITOR as the minimum of 2 safety days’ supplies:
• safety days’ supply based on the average consumption of the 7 days

• safety days’ supply based on the demand as shown in the DRP matrix
Only the stock on hand is used for this calculation, not the planned receipts.
Figure 14.25 shows an example for the calculation of the safety days’ supply—in
this case the safety days’ supply based on the demand of the DRP matrix is the
shorter and therefore used as the resulting safety days’ supply.
Current Stock on Hand
Projected Stock without Receipts based on Average Consumption
Projected Stock without Receipts based on Demand
Safety Days’ Supply
Safety Days’ Supply Lead

Including Lead Time Time
Fig. 14.25 Safety days’ supply for the shortage monitor
Whether the lead time is subtracted from the safety days’ supply or not depends
on the parameter ‘days’ supply including procurement lead time’ in the general
settings for the shortage analysis (see Fig. 14.26).
Criticality Status and Open Quantity

The shortage monitor classifies products into critical, potentially critical and non
critical depending on their safety days’ supply at the entry location. The limits for
these categories are also maintained in the general settings for the shortage analysis
(with the customizing path APO ! Supply Chain Planning ! SPP ! Monitoring
! Shortage Analysis ! Make General Settings for Shortage Analysis). Fig-

ure 14.26 shows an example with the thresholds of 5 days for critical products
and 10 days for potentially critical products.
Fig. 14.26 General settings for the shortage analysis
The product is not critical any more if the safety days’ supply is above the limit
for the potentially critical product. In this example stock for 10 days is required in
order to keep the product not critical. The open quantity is the missing quantity
which is required additionally to the current stock in order to achieve that the
product is not critical any more. Criticality, open quantity and stock on hand are
displayed in the shortage monitor.
Shortage Monitor
The navigation with transactions is not possible within SAP SNC™. Instead a
navigation bar exists on the left side of the screen. Figure 14.27 shows this
navigation bar and the shortage monitor. In this example the selection was restricted
by planner.
14.3 Shortage Monitor 413
Fig. 14.27 Shortage monitor
The shortage monitor shows at a first glance the available stock (80 pieces for the
first product), the open quantity (490 pieces) and the days’ supply (1.7 days). In the
details of the location product additional information as the demand frequency, the
backlog and others are displayed as shown in Fig. 14.28.
Fig. 14.28 Shortage monitor—location product details
It is possible to branch from the shortage monitor directly to other tools as

e.g. the alert monitor, the SPP cockpit or the product detail.
The order in which the location products are displayed is defined with the
customising path APO ! Supply Chain Planning ! SPP ! Monitoring !
Shortage Analysis ! Define Sorting in Location Product View as shown in
Fig. 14.29—in this case descending according to the demand frequency and
ascending according to the shortage status.
Fig. 14.29 Sorting of location products in the shortage monitor
14.4 Alert Monitor
The alert monitor notifies the planner about irregularities and problems in the
supply chain. Some of the potential problems are connected with the procurement
of the service parts. Since the alert monitor for service parts planning is part of SAP
SNC™ the supplier can access the alert monitor as well and react and comment on
the alerts that are connected with him.
Alert Types
There are predefined alert types for the different kinds of irregularities and
problems, and most of these alerts are raised by the planning applications. The
other two alert types allow the planner to create an alert interactively if he notices
something odd that is not covered by any of the predefined alert types. Additionally
it is possible to create alert types customer specifically—however, the report to
raise the alert has to be created customer specifically as well. Table 14.5 lists some
of the alert types with their meaning and their category. The alert types 7805
(problem report) and 7856 (information) are only used for the interactive creation
of alerts by the planner.
14.4 Alert Monitor 415
Alert Monitor
The alert monitor is called from the navigation bar at the left as shown in Fig. 14.30.
Here it is possible to select the alerts by planner (parameter ‘analyst’), location,
product, alert type and more. It is mandatory to select by alert type—in order to
display all alert types ‘*’ is allowed.
Fig. 14.30 Alert selection
The result of the alert selection is displayed in the statistical view. Here all alerts
are listed by alert type, and the number of alerts with their priority and their status
(new, in process, completed, retained) are displayed as well, Fig. 14.31.
Fig. 14.31 Statistical view and alert type view
Table 14.5 Alert types (excerpt)

Alert
Alert category type Alert type name
Forecasting 7815 Forecasting phase-in
Inventory planning 7842 Missing planning data for EOQ/SS
7843 Safety stock has too large a discrepancy
7844 Missing planning data for stocking
7846 Missing planning data for de-stocking
Surplus and Obs. service 7875 No surplus quantity determination for location
7876 Product is set to obsolete
DRP 7816 Invalid or missing master data (location product)
7817 Invalid or missing master data (product/
shipment)
7818 Inconsistency for Virtual Consolidation
Location
7819 No valid packaging specification
7867 Inconsistency for replenishment indicator
7820 Requirements cannot be pulled
7821 Supplier shut down and supplier split
7822 Supersession: firmed schedules
(continued)
14.4 Alert Monitor 417
Table 14.5 (continued)

Alert
Alert category type Alert type name
DRP Approval 7824 Manual review
7827 New product
7828 DRP De-expedite from limited freeze horizon
7829 Change in limited freeze horizon
7830 Discrepancy in supply figures
7831 Pending obsolescence starts
7833 Anonymous purchase requisition created
7834 Product group procurement
7835 Ordering reason causes manual review
7836 Maximum schedule line value
7837 Maximum schedule line value change
7839 Outline agreement obsolete bef. end of freeze
hor.
7840 Maximum total lead time
External Order Approval 7857 Value of schedule line too high
(EOA) 7858 Quantity change over limit value
7859 Value of network stock over limit value
7860 Excess days on hand
Over schedule 7806 Overdue scheduling agreement schedule lines
7812 Uncovered Conf. with shipping date in the past
Delivery 7808 Early delivery
7809 Overdelivery
Supersession 7855 Stock exhaustion before warning date
7870 Pending obsolescence date was changed
7871 Inconsistent supersession master data
7878 Supersession chain not released
The alerts that belong to the alert type are displayed by double click. Figure 14.31
shows the 2 DRP alerts of the type ‘Repair or Buy Alerts’. Each alert has a number,
and in the first rows the location and the product are displayed. Additional details
are displayed in the ‘form’-view, Fig. 14.32.
Fig. 14.32 Alert details in the ‘Form’-view
Status Sequence
To each alert type a status sequence is assigned which defines the reactions to the
alerts. When an alert is raised, the status of the alert is ‘new’ (SN). Other statuses
are ‘in process’ (SP) and ‘confirmed’ (SC). The status sequence defines—
depending on the current status of the alert—who (the planner respectively analyst
or the supplier) is allowed to perform an activity (e.g. to edit, reject or confirm the
alert) and what the resulting status is going to be. Figure 14.33 shows the definition
of the status sequences with the customising path Advanced Planning and Optimi-
zation ! Supply Chain Planning ! Service Parts Planning ! Monitoring ! SPP
Alert Monitor ! Make General Settings for Alerts
Fig. 14.33 Status sequences
The status sequence ‘2’ describes a simple and common procedure where the
planner confirms the new alert during the alert processing. In contrast to this simple
procedure, the status sequence ‘5’ describes a more elaborate procedure with
interaction between the planner and the supplier, Fig. 14.34.
Alert Generation Planner (Analyst) Supplier
Alert
Status SN
No Yes
o.k.?
Assign Note Confirm
Alert
Reject
Status SP
Confirm
Alert
Status SC
Fig. 14.34 Procedure for the status sequence ‘5’
14.5 SPP Cockpit 419
The status sequence is assigned to the alert types with the same
customising path.
Alert Type Customizing

The customizing for the alert types is performed with the same customizing path
Advanced Planning and Optimization ->. Supply Chain Planning ! Service Parts
Planning ! Monitoring ! SPP Alert Monitor ! Make General Settings for Alerts
as the definition of the status sequence. Besides the status sequence, each alert type
has a validity period (in days) and a response time (in days)—after this time a
response from the planner respectively the supplier is expected. Whether the alert is
visible for the planner (analyst), the supplier or both is part of the alert type
customizing as well. Figure 14.35 shows an excerpt of this customizing.
Fig. 14.35 Customising for alerts types
14.5 SPP Cockpit
The SPP cockpit allows the planner to gain a quick overview about some key
measures of a service part—for all locations of the BOD. Among these key
measures are
• available stock on hand

• stock in transit
• forecast
The forecast is the final forecast of the current period as displayed in the forecast
planning book.
Fig. 14.36 SPP cockpit
The forecast of the parent location is shown and not of the virtual child location.
Figure 14.36 shows the SPP cockpit with all three location products of the BOD for
the product SPP_HAWA_0001@RME801. It is possible to branch from the SPP
cockpit to the shortage monitor, to the alert monitor, to the product detail and to a
detailed view of the planning situation at a certain location (with the pushbutton
‘forms’), Fig. 14.37.
14.6 Product Detail 421
Fig. 14.37 SPP-cockpit—detail for a product location
14.6 Product Detail
The product detail combines master data and transactional data information for the
selected location products in one place. Figure 14.38 shows that the product detail is
subdivided in to several tabs for the respective data.
Fig. 14.38 Product detail
The product detail contains information on
– product master
– external procurement master data
– open procurement schedule lines
– open ASNs
– aggregated demand history ( BOD-wide overview or location-specifically)
– forecast
– safety stock and EOQ-
– inventory planning data
– fixed demands
– active supersessions
– overall stock data
for the selected products. As an example Fig. 14.39 shows the “BOD: Demand
and order item” tab and the “Loc.: Demand and order item” tab.
Fig. 14.39 Examples for product details tabs
In the upper part of Fig. 14.39 item demand and aggregated demand history are
presented on a time-oriented aggregation level (here 2014 and 2013) for those
locations that are members of the respective BOD. In the lower parts these figures
are shown in detail on monthly level and specifically for the location product
selected upfront. Furthermore the data can be optionally selected for the facing or
the corresponding stockholding location.
14.7 Reporting 423
Fig. 14.40 Stock overview in product details
Another option in product details is to select interesting information on stock in

an overview.
Figure 14.40 shows that the tab “stock” contains data on location product level
differentiated by e.g. stock types—since this list contains a lot of columns only a
section is shown here. Apart from information on quality inspection stock, blocked
stock, unrestricted use stock other attributes of the stock is listed like repaired stock,
inbound delivery stock in yard, excess stock, unserviceable stock etc.
The figure also shows that the stock data is aggregated to sub-BOD-levels as
well as to overall BOD-wide stock levels.
14.7 Reporting
Within the service parts management solution several reports are provided as
business content to measure and analyse the performance of the supply chain.
These reports are available with the SAP NetWeaver usage type Business Intelli-
gence (SAP BI™). The report to measure the outbound performance towards the
customer is the service fill monitor, the report to measure the performance within
the supply chain the inbound monitor and the supplier delivery performance rating
for procurement. In the following we will describe the service fill monitor as an
example for the reporting capabilities.
Service Fill Monitor

The service fill monitor is a report within SAP BI™ to evaluate the service level—
both the alpha and the beta service level. Figure 14.41 shows the report for the beta
service level—i.e. the service level based on the fulfilled quantities. The incredibly
low service level in this example is due to the test data.
Fig. 14.41 Service fill monitor
The service fill monitor provides also additional information to analyse which
location of the BOD causes the service loss. Since the use of rules-based ATP with
location substitution is part of the service parts management solution and some
locations are not stocked on purpose, this is not self-evident. The concept to
differentiate between these cases is to review all the involved locations during the
rules-based ATP check. The start location as determined by the first rule during the
ATP check is the customer facing location (see Sect. 13.3). If the replenishment
indicator of the customer facing location allows stocking, this is also the first
stockholding location. If the replenishment indicator is set to ‘not stocked’, the
next location with a replenishment indicator for ‘stocked’ is the first stockholding
location. The next location is defined by the location substitution procedure of the
second rule of rules-based ATP. The first stockholding location is the location
which is supposed to confirm and deliver the sales order. This is however not
necessarily the case, and then the next location within the substitution procedure is
checked. This location might or might not confirm the request. In order to distin-
guish between the different reasons for location substitution the following naming
convention is used:
• standard: The customer facing location is the first stockholding location and
confirms the request
• redirected: The customer facing location is set to ‘not stocked’ and the first
stockholding location confirms the request
• referred: The customer facing location is set to ‘stocked’ but is not able to
confirm the request. The request is confirmed by another location in the BOD
• redirected then referred: The customer facing location is set to ‘not stocked’ but
the first stockholding location is not able to confirm the request. The request is
confirmed by another location in the BOD
14.7 Reporting 425
The quantities in the service fill monitor are broken down to these categories.
Figures 14.42 and 14.43 show an example in order to illustrate these categories.
Standard Redirected
Stock Stock
Stocked Stocked
Stuttgart Stuttgart
Stock Stock
Stocked Stocked
Confirmed
Frankfurt Stuttgart Frankfurt Stuttgart
Sales Order
Stock
Stocked Not Stocked

Köln Berlin Köln Berlin
Confirmed
Sales Order Sales Order
Fig. 14.42 Location substitution: standard and redirected
Referred Redirected then Referred
Stock Stock
Stocked Stocked
Confirmed
Stuttgart Stuttgart
Sales Order
Stock
Stocked Stocked
Confirmed
Frankfurt Stuttgart Frankfurt Stuttgart
Stocked Not Stocked

Köln Berlin Köln Berlin
Fig. 14.43 Location substitution: referred and redirected then referred
The service fill monitor is primarily based on the sales order from SAP CRM™
or SAP ERP™ and the goods issue from SAP EWM™ via SAP ERP™. The data is
however first processed in SAP APO™: First the service fill decision is calculated
and then the service loss analysis performed. The processed data is finally sent to
SAP BI™. Figure 14.44 shows the data flow.
SAP BI
Reporting
Service Fill Monitor
SAP APO SAP EWM
Service Fill Decision Service Loss Analysis
Sales Order Goods Issue Goods Issue
SAP CRM SAP ERP
Fig. 14.44 Data flow for the service fill monitor
Original Equipment Manufacturer
Managed Inventory 15
15.1 OEM MI Process
Overview
For many years meanwhile a cross-company planning method called vendor-
managed inventory has developed from a trend to a widespread and well acknowl-
edged planning strategy. VMI is conceptually based on the idea of quick response
and continuous replenishment.
In VMI the supplier takes over responsibility for replenishment of its
customer—both planning and execution. So, he is fully responsible for the
customer’s stock availability and economic stock management.
Cooperating much closer the two or more partnering companies in a supply
chain achieve a higher availability with a much lower stock level. Reason for that is
that e.g. the well-known bullwhip effect (caused by too big lot sizes and delayed
replenishment triggers) can be minimised due to the fact that no or only little
buffers are necessary because one order level in the supply chain actually can get
rid of since the planning and delivering instance is the same player in the supply
chain as well has the supplier much more visibility about the demand and supply
situation which leads to higher replenishment precision. On the other side the
replenishment itself can happen much more frequently, which has the effect of
smaller ordering lot size, which again leads to less overall stock in the supply chain?
For which product groups VMI should be applied or not is a matter of deeper
research and basic strategic decision in the respective supply chain partners.
E.g. most of time it is a problem for the wholesalers and retailer to move these
kinds of responsibilities to the manufacturer since this is originally one of the core
competences of this industry. Also the coordination and synchronisation with all the
supplying partners from the perspective of a certain wholesaler or retailer, in order
to smooth the traffic on his dock is always a reason for deeper discussions and

428 15 Original Equipment Manufacturer Managed Inventory
changing responsibility.1 In any case the reduction of transactional cost is always an

argument pro VMI. The VMI-Concept is incorporated in the SPP as a so-called
OEM MI, which stands for Original Equipment Manufacturer Managed Inventory.
Prerequisite above all is a tight and trustful, but also legally robust relationship
between the two partners—on the one hand the supplier, means the OEM like a
manufacturer in the consumer goods industry and—on the other hand—its cus-
tomer, which could be the wholesaler, the retailer or—as an exception also—
important big end-customers. Within this relationship the customer sends his
POS-data, which is used as demand history, on a regular and validated basis to
the OEM as well as information on stock levels of all the single products, which are
subject to VMI. In the end the OEM plans and coordinates the delivery (including
minimum and maximum lot sizes and time of delivery) within an agreed quantity
corridor (minimum and maximum inventory at the customer).
Fig. 15.1 Information and material flow in an OEM MI-process
Figure 15.1 shows the typical information flow of sales and stock data from the
customer to the OEM and the planning results back to the customer. This is the basis
for the physical process flow of goods from the supplier to the customer.
Overview OEM MI in SPP

Within SPP, OEM MI means the planning of customer locations that are connected
via an interface with the OEM’s SPP system. The backend system for sales of the
OEM-locations as they are represented in SPP can be ERP (lean-OEM MI) or CRM
as far as SAP is concerned. Figure 15.2 illustrates the data, information and
responsibilities in regard to SPP.
1
W.-R. Bretzke (2010): Logistische Netzwerke, Seite. 287.
15.1 OEM MI Process 429
The customer is represented by a location on the lowest level in the BOD. The
customer (dealer or service provider) sends his data (e.g. from a dealer management
system) via internet with an XML-message to the OEM’s SPP-system. This data is
current stock data as well as sales data (e.g. POS). This sales data is received in the
BI-module of SPP, then is transformed and updated by transformation rules and
updates rules and saved as raw data and demand history for the customer’s location
products.
These demand data can be realigned, if necessary due to potential change by
supersession or by changes of the respective replenishment indicator.
Following that SPP decides either to stock or to destock a service part at the
customer’s location. If the decision is made to stock a service part, it becomes
relevant for further planning at the customer’s location. If SPP Inventory Planning
decides not to stock a service part, the service part is not relevant for further
planning at the customer’s and the demand history for the service part at the
customer’s or dealer’s location is included in the demand history of the service
part’s demand history at the parent location.
Following that SPP offers the customer to approve or reject the stocking or
de-stocking decision. The customer is informed via his worklist about e.g. the
potential upcoming change of a replenishment indicator and can react via the
worklist by approving the decision made by SPP. If he decides to reject this is
interpreted as counter-proposal by system and does not have direct impact to
decision. It rather causes the creation of a corresponding alert for the planner so
that he can contact the customer and discuss the new replenishment indicator.
Following that, SPP creates a forecast for the future demand at the customer’s
location based on the demand history. The result of the forecast planning can
displayed in the usual UI as for other OEM-internal BOD-locations.
Following that SPP calculates the EOQ and the safety stock in mutual depen-
dence to achieve a defined target service level and also to optimize the purchase
order and stockholding costs. The result of the EOQ and safety stock determination
can displayed in the usual UI as for other OEM-internal BOD-locations.
Following that SPP executes DRP to organize the replenishment planning. The
DRP planning result can be displayed in the usual UI as for other OEM-internal
BOD-locations.
Following that deployment decides—based on the demands determined by
DRP—how to distribute the goods within the BOD. It creates stock transport orders
for stock transfer between OEM locations and replenishment orders for stock
transfer between an OEM location and a customer or dealer location. These stock
transfer proposals can be approved by the customer via worklist. An Approval of
rejection has direct impact on the deployment planning results. As soon as the
replenishment order is approved, it is transferred to SAP ECC via Core Interface
(CIF) and SAP ECC creates a respective sales order. This sales order is send to the
customer for confirmation.
Following that an outbound delivery in the issuing plant (which is the parent
location of the respective customer location) is created in SAP ECC and the goods
issue is posted based on this. The information about this outbound delivery and
stock posting is send to SPP immediately.
In the following SPP receives the information about the goods receipt at the
customer’s location as proof of delivery and an updated stock information for the
customer’s location from the customer. To provide this information, the customer
sends an XML message of type ProductActivityNotification that contains the up-to-
date stock information for his location.
Fig. 15.2 Overview on SPP planning in the OEM MI-process
The OEM’s planner is responsible for all master data of all the objects involved
in the SPP process (e.g. activation of a product for the OEM MI-process) whereas
the customer’s planner’s task is to monitor the situation and the planning results as
well as tasks like approving, rejecting or slightly modifying some parts of the
planning results.
15.2 Master Data for OEM MI
In order to activate generally the process of OEM MI planning in SPP, the following
setting in the master data has to be made. Since a B2B business is represented in the
SPP-System, the corresponding partners and locations must exist as master data. On
one hand the supplier location, which is the delivering respectively the customer
facing OEM-location, and which is in SPP of location type 1001 (plant) or 1002
(distribution center). On the other hand the customer (end customer, wholesaler or
15.2 Master Data for OEM MI 431
retailer) needs to be modelled as a separate location of location type 1010 (cus-

tomer). This customer location extends the corresponding BOD and is integrated as
location of the lowest child level in the hierarchy as shown in Fig. 15.3.
Fig. 15.3 Customer-location-level a the BOD
In order to do an OEM MI-planning for a product, this needs to be created as

location product master data in the customer location. Besides the necessary
replenishment indicator, which does not need to be set as non-stocked, the decisive
parameter to activate the OEM MI-Planning functionalities is the field “relevant for
OEM-managed inventory” in the tab “inventory planning” as shown in Fig. 15.4.
Fig. 15.4 Setting of OEM MI-relevancy customer location product master data
The location product at the customer is generated automatically by the core

interface (CIF) from release ECC 6.0 EhP 4 on (parameter “customer material” in
section material dependent objects). As precondition the customer-material-info-
record for the corresponding material and its customer is required.
Almost all modules within SPP are affected by OEM MI-based planning or
behave at least slightly different compared to the non-OEM MI type of planning.
The following gives an overview what and how the differences are.
15.3 Capture and Manage Demand for OEM MI
The customer needs to send its sales data to the OEM in order to get the planning
services done in SPP system. This sales data is e.g. POS-data, which is derived from
the corresponding Dealer Management System.
In contrast to the OEM’s own sales data, the customer’s sales data from DMS is
received and validated by SAP PI (SAP Process Integration, the Enterprise Appli-
cation Interface Platform of SAP Netweaver) before it is passed on to the
SPP-System and there to the BI module as shown in Fig. 15.5.
Fig. 15.5 Illustrated data capture compared between dealer and OEM-system
The data transfer from the customer system (DMS) is done via XML-messages,
which are more or less text files with a certain hierarchical structure and notification
and are exchanged via the internet. These XML-messages are received by the SAP
interface called Product Activity Notification, which is incorporated in the SAP PI.
OEM MI-Specific BI-Objects and Processes

There are OEM MI-specific BI-objects for organising capture and manage demand
that provide a specific extraction and transformation logic and need to be defined
and activated upfront. The upload structure for the demand history is shown in
Fig. 15.6.
15.3 Capture and Manage Demand for OEM MI 433
Fig. 15.6 Overview of BI-objects in the OEM MI data capture process
There is a generic and delta-enable data source called 9A_APO_OEM

MISO_XML_DATA (entries can be seen in table /BI0/9AAOEM MIS00), where
the received content of the B2B messages is stored at first before it is transferred to
the data store object 9AOEM MIS.
In the following the OEM MI-specific update rule 89OEM MIS passes the data
on to the info provider 9ARWADAT and 9ADEAMD before it ends up in the
Multi-Provider 9ADEMMUL and 9ARAWMUL and is stored together with all the
other demand history data from the OEM-locations.
Unlike for loading sales data from CRM or from ERP, there is no way to use an
alternative csv-load for customer’s sales data. All that exists is a report for test
purposes (/SAPAPO/SPP_SE_PRODACT_O_TEST) to validate the XML-message
structure und load stock for test purposes.
Not only sales data is transported via XML-messages but also the relevant stock
data that is needed for net demand calculation in DRP. Nevertheless both sales and
stock data can be combined within one single XML-message. The stock informa-
tion contains the quantity and the time stamp of the unrestricted-use stock—quality-
inspection stock, blocked stock, stock in transit etc. are not considered since only
the stock is needed which is immediately ready for sales.
Demand Categories and Demand Realignment

When capturing the sales data and managing the sales history an important param-
eter is the demand category as described in Sect. 3.2. Out of the eight predefined
demand categories four are OEM MI-related and have the purpose to differentiate
forecast-relevant from forecast-irrelevant demand items. CRM_INACT,
ERP_INACT, XML_INACT all declare their attached historical demand as

forecast-irrelevant whereas XML_ACTIVE is responsible for declaring the
attached historical demand as forecast-relevant, Fig. 15.7.
Fig. 15.7 OEM MI-specific demand categories
The main purpose of having OEM MI-specific demand categories is to be able to

determine a certain status of each location product in relation to OEM
MI. Generally speaking the behaviour of the planning tasks and services done in
course of OEM MI depend on the OEM MI-status of a location product. Especially
in capture and manage demand considering these statuses helps to avoid double
counting of historical demand at locations that are involved in an OEM MI-process.
There are three statuses: non-OEM MI, OEM MI-passive and OEM MI-active.
Fig. 15.8 Determination of OEM MI-related planning status
15.3 Capture and Manage Demand for OEM MI 435
Figure 15.8 shows the determination of the different statuses. Dependent from
the settings in respect to the BOD-structure, to the OEM MI-parameter and the
replenishment indicator as shown in Fig. 15.8 a special planning service logic is
applied, e.g. in respect to realignment. OEM MI-active means that both the OEM
MI-relevancy (as shown in Fig. 15.4) parameter in the location product master is set
and additionally the replenishment indicator is set to ST. In contrast to that OEM
MI-passive means that the replenishment indicator is set to NS. Non-OEM MI
means replenishment is NS and no OEM MI-relevance parameter is set, even
though the customer location could be integrated in SPP and in the BOD as location
of type 1010.
Assuming an example where the demand history originally was loaded from
SAP ERP (of the OEM) onto the level of the customer-facing location as the first
stockholding location, i.e. the virtual child of SPP1. Later one of SPP1’s customers
(CUST1) was integrated into the planning network (BOD and CUST1 also
contributed his own sales data by transferring the appropriate XML-messages.
This requires the demand categories to change. I.e. the sales data on the level of
CUST1 were activated by setting the demand category XML_ACTIV whereas all
the demand data on location SPP1, which have CUST1 as a ship-to location, needs
to be de-activated by setting the demand category to ERP_INACT (in this case the
connected sales system is SAP ERP and not a SAP CRM). This needs to be done to
avoid double-counting of the demand history.
The sales data on level of CUST1 is taken as relevant because the assumption is
that this data is more precise since the dealer has direct contact to the final customer.
Fig. 15.9 Realignment behaviour dependent from OEM MI-related planning status
Assuming subsequently—as illustrated in Fig. 15.9—the SPP planning service

for de-stocking decides to change the replenishment indicator from ST to NS, the
following realignment service for stocking/de-stocking changes the historical
demand items from XML_ACTIVE to XML-INACT on the customer location
products accordingly. Correspondingly all the related inactive history demand
items are changed from ERP_INACT to NONE, since they are active now and
replace the demand at the customer location CUST1 for planning purposes.
Additionally to the stocking/de-stocking realignment service as seen above, all

the other realignment services are also capable of interpreting the OEM MI-status
dependent situation accordingly. When the supersession service e.g. sets the replen-
ishment indicator of the predecessor from ST to NS (as soon as the product planning
start date of the successor is reached) the consecutive supersession realignment
service changes all relevant data for the successor product from XML_ACTIVE to
XML_INACT and vice versa.
The logic of the BOD-realignment is the same as in a non-OEM MI-case.
When applying the promotion demand realignment service in the context of an
OEM MI-customer location, the behaviour of setting the demand categories is as
follows: Assuming originally the demand items on a customer facing location that
has an customer location as ship-to-location have the demand category
PROMO_DEM. Whenever the replenishment indicator of the associated customer
location changes—either from NS to ST or vice versa or in this sequence back and
forth, the demand category of the demand items of the OEM-location delivering the
customer-location stays always as PROMO_DEM. The realignment will not change
these demand categories e.g. to ERP_INACT when the demand category on
demand items on the customer-location changes to XML_ACTIVE. Section 3.3
describes how the demand category PROMO_DEM is changed at all at
OEM-locations. On customer-location the demand category PROMO_DEM can
never be set since the demand history is not accessible for manual change via
transaction /SAPAPO/DMDH as shown in Fig. 15.10.
Fig. 15.10 PROMO_DEM demand category in OEM MI-process
15.6 DRP for OEM MI 437
15.4 Inventory Planning for OEM MI
The stocking/de-stocking decision service and the safety stock and EOQ planning
service are applicable in the same way for customer locations as for all the other
OEM-locations and apply the same logic. Additionally providing information on
the results of services to dealers is made possible via the Customer’s Worklist as
described in Sect. 14.2, e.g. if the replenishment indicator has been changed by the
stocking service. If additionally the option of customer approval is activated in the
location product master, the dealer could even reject or approve the planning
explicitly. Furthermore this would cause the alert 7896 for the OEM-planner,
who could eventually re-think the decision.
15.5 Forecasting for OEM MI
As described in Chap. 5 in the various statistical forecast methods in SPP are

applied both the detailed forecasting on one hand and the aggregated and
disaggregated on the other hand. In case of a BOD that has a customer location
on its lowest level the disaggregation of the forecast is not done down to this very
lowest level. Reason for that is that there is no inventory balancing between a
customer location and its supplying customer-facing location nor among different
customer locations. Since there is no forecast on this level it cannot be approved
either.
15.6 DRP for OEM MI
The basic logic of the DRP service is also valid for applying it in a context where
customer locations are involved. One restriction is that no repair-or-buy and no kit-
to-stock scenarios can be applied in the customer location itself. This restriction
also applies to forecasting, inventory planning, and inventory balancing. Further-
more no third-party order processing can be applied if the customer location would
function as the corresponding customer. This also includes that no push deployment
from supplier is possible, where a direct shipment from supplier to one of the child
locations below the entry location takes place. As soon as this child location would
be a customer location an error message would be thrown. Neither can the customer
location act as an entry location—in that case an alert of type 7877 would be raised.
In the DRP matrix in the key figure ‘Confirmed Distribution Demand’ and
‘Distribution Receipt from BOD (Confirmed)’ not only stock transfer orders but
also OEM MI stock transfer orders are included as soon as the receiving location of
the STO is a customer location. The ATP category of the OEM MI-STO is BF for
the supply side and EK (TLB Sales Order) for the demand side. The latter is per
default part of the SNP-Category group S03, Fig. 15.11.
Fig. 15.11 ATP categories

of OEM MI-STO’s
As shown in Fig. 15.12 this category group is assigned to the relevant order
semantic ORDER_STO_VMI_DMD which is assigned to the corresponding key
figure of the DRP matrix (as described in Sect. 2.4) and can be accessed in
customizing with following IMG paths in the customizing: APO ! Basic Settings
! Transaction Data Layer (TDL) ! Configure Settings for TDL Semantics.
Fig. 15.12 Assignment ATP-category groups to order semantics of OEM MI-STO
Correspondingly this is displayed in the DRP matrix when clicking into the
details of the respective cell of the key figure. Here ‘STO created by Deployment’
has the ATP categories EK on the demand side and BF on the supply side—no
matter whether the order is already integrated with ERP or not as shown in
Fig. 15.13.
15.6 DRP for OEM MI 439
Fig. 15.13 Details of OEM MI-STO shown in DRP matrix
In the DRP matrix an additional column indicates whether the respective loca-
tion is an customer location by the indicator ‘Non-OEM Location’ as shown in
Fig. 15.14. This is also applicable for all other interactive planning UIs in SPP that
are called with the transactions /SAPAPO/SPPFCST, /SAPAPO/SPPINVP, /
SAPAPO/SPPDRPM, /SAPAPO/SPPDEPL, /SAPAPO/PARTDET, /SAPAPO/
COCKPIT, and /SAPAPO/SPPDRPSB.
The button ‘Show Complete BOD’ resp. ‘Show Filtered BOD’ controls whether
the customer location is displayed.
Fig. 15.14 Complete BOD including—NON-OEM location
15.7 Deployment and Inventory Balancing for OEM MI
The resulting order of a deployment is a stock transfer of type OEM MI as soon as

the receiving location is an customer location. The type of the stock transfer can be
seen in the transaction /SAPAPO/SPPDEPL in the section for approvals. Here it is
also indicated whether the approval should be done by the customer via customer’s
work list or not as shown in Fig. 15.16. The relevant setting is made in the location
product master in the tab “deployment” (Fig. 15.15).
Fig. 15.15 Impossible trial of approval of OEM MI-STO by OEM-planner
15.7 Deployment and Inventory Balancing for OEM MI 441
Fig. 15.16 Overview on access point to the Planner’s Work List
The proposed quantity of a STO could be changed by the customer in his

worklist if required. As prerequisites this would have to be pre-defined in the
customer approval setting in location master and additionally the BADI /
SAPAPO/SPP_STO_DLR_QTY_CHECK would need to be defined and activated.
In the case of special fair share as described in Sect. 10.4 there is a functional
difference for OEM MI. Deployment with special fair share cannot be applied for
back orders because these orders do not have all the required information as they do
in the standard case.
Operative inventory balancing is not executed on customer location level even
though the actual calculation of excess can be done. This excess stock can then be
communicated to the customer/dealer via their respective worklist as described in
Sect. 14.2. If excess stock exists and the dealer wants to get rid of it then he can
trigger a re-transfer back to the OEM outside of SPP planning functionalities. If the
dealer accepts the excess stock he can alternatively delete the information in the
dealer’s worklist.
The OEM MI stock transfer is integrated to SAP ERP as a sales order on the side
of the customer facing location (note: the history is now recorded at the customer
location). In Fig. 15.17 this is the sales order 712 in location SPP1—here both the
DRP matrix in SPP and the sales order in SAP ERP (transaction VA03) are shown.
Fig. 15.17 Appearance of the OEM MI-Sales Order compared between SPP and ERP
As a prerequisite for the integration in SAP ERP settings like the definition of a
default sales order type for the plant and the involved sales area (that is responsible
of selling the service parts to the dealer) are required. This customizing setting is
maintained via ! APO ! Integration with other SAP-components ! Application-
specific settings and enhancements ! Settings and enhancement for Sales Orders
! Settings for vendor-managed inventory (VMI) ! APO ! Supply Chain
Planning ! SPP ! Basic Settings ! Make Settings for Customer Demand,
Fig. 15.18.
Fig. 15.18 Relevant customizing setting in ERP for VMI (OMEMMI) sales orders
In later planning cycles when capturing the sales order, these types of sales
orders—the VMI-orders —will be filtered out and will not be counted as demand
history in SPP.
Everything described above concerning the publication back to SAP ERP is also
possible in the same way when using SAP CRM as back end system.
15.8 Supersession for OEM MI 443
15.8 Supersession for OEM MI
A slight difference exists in the way the stock exhaustion date (SED) of the
predecessor is calculated as soon as a customer location is part of the BOD. As
explained in Sect. 12.2 the SED is determined by applying a DRP-based net
demand calculation taking into account all stocks, all supplies and all demands
BOD-wide. In case of OEM MI the SED of the customer location is calculated in an
isolated way taking only its demands, stocks and supplies into account. Therefore
the SED at the customer location can be later than the overall SED of the BOD. This
independent calculation of the use up of the predecessor’s stock is done mainly
because there is no inventory balancing on the customer location level.
In contrast to the SED the product planning date will be defined for the whole
BOD altogether—valid also for the customer location since it is stored at the
corresponding entry location of the BOD.
If supersession is applied at a customer location in the BOD but the customer/
dealer does not want to have a supersession planning—especially the use-up of
existing stock of the predecessor—there is a parameter on the location product
master to be set. The effect of the parameter “No Substitution Orders for 1:1
Supersession” is that the “old” stock of the predecessor is not considered as supply
for the succeeding product on this respective level even though the overall use-up
strategy is “full”. As a consequence the customer can send back the remaining stock
of the predecessor product on an extraordinary and manual basis to the supplier.
There this remaining stock could be used for the regular supersession planning
process at the customer facing locations. Effectively the parameter lifts up the
execution of the supersession planning one BOD-level higher. This applies not only
for product substitution in the course of supersession, but also in the course of
substitution of remanufactured products. The parameter “No Substitution Orders
for 1:1 Supersession” is focused on the OEM MI process but can also be applied in
“normal” OEM-locations, where the actual application of the supersession can be
passed on to all the next BOD-levels.
Outlook
16
16.1 Current and Future Improvements: “Customer

Connection” Programs
Similar to the other components of the SAP Business Suite (SAP ERP, SAP CRM,
etc.), SPP within SAP SCM was improved over many years, adding new
functionalities that are described in this second edition, like the SPP Planner’s
Worklist, OEM Managed Inventory or Leading Indicator Forecast.
The most recent improvements were developed in a so-called “Customer Con-
nection” program that needs to be triggered via one of the SAP User Groups (see
www.sap.com/communities/user-groups.html ).
Once a “Customer Connection” project for a certain “Focus Topic” is accepted
by SAP, SAP structures each project with a dedicated timeline and scope. The
project subsequently enters the collection phase where customers submit “improve-
ment requests” via http://influence.sap.com, a dedicated collaboration platform.
When a significant number of customers subscribe to an improvement request
(by simply clicking the “subscribe” button), it becomes eligible for possible devel-
opment. SAP then selects eligible requests to develop and works in collaboration
with the users to deliver the improvements.
The first Customer Connection program for SPP started July 2013 and delivers
15 improvements that can be found—together with the related SAP notes—at
http://sapimprovementfinder.com by just entering “SPP” in the search field. The
highlights include
– SAP note 1994781, which dramatically improves the usability of the SPP
application log by providing the infrastructure for enhancing application
messages with product, location, BOD, etc.
– SAP note 1982983, adding two well-known algorithms (the event-oriented type
1 or cycle alpha service level and the quantity-oriented type 2 or beta service
level) to the one that was originally implemented in the combined EOQ and
safety stock calculation in SPP

446 16 Outlook
– Improvement “Standard reporting on planning quality” (BI part only available

via support pack), which provides new BI extractors for forecast, EOQ, safety
stock, projected and actual stock and queries on these key figures with drilldown
/ aggregation options like location > region > country, BOD > sub-BOD and
product > product group > product group type.
The second Customer Connection program for SPP will start September 2014.
While it is active, the submitted improvement requests can be seen via http://
influence.sap.com. Once it is finished, the improvements will be available via
http://sapimprovementfinder.com.
16.2 SPP on HANA
With the release to customer for the enhancement package 3 of SAP SCM 7.0 on
13.08.2013, SPP as part of SAP SCM is available on HANA, SAP’s In-Memory
database (High Performance Analytic Appliance).
Due to performance improvements in some of SPP’s most critical planning
services when running on HANA, this break-through technology enhances SPP’s
ability to handle extremely high volumes of service parts. Several SPP customer
implementations handle more than 100 million SKUs, there are ramp-ups to
200 million and plans to extend to 500 million SKUs.
Right now, August 2014, there are two customer Proof of Concepts ongoing for
HANA based Analytics for SPP with customer data exported from their respective
productive SPP systems.
First results show
– The ability to access ALL SPP data (except liveCache and ODM) :
• From demand history to forecast and inventory planning data, as well as
projected stock and all master data!
– Easy ad hoc reporting
• By the use of SAP Lumira or Excel Analysis Office
– The ability to compare different simulation versions
• . . . is definitely the most significant achievement, the “Holy Grail” of SPP
– There is no need to migrate SPP to HANA
• The complete functionality is available in a HANA sidecar approach,
whereby only the relevant tables need to be replicated via standard tool
SLT, which makes prototyping very easy
As an example of the potential for HANA based Analytics, today one customer
who doesn’t use HANA regularly extracts the forecast data after the monthly
forecasting run into BI. Due to the high data volume the BI extraction takes up to
5 days. After the extraction the BI Queries run reasonably fast. However, using the
POC on HANA, the same amount of data could be processed on-the-fly within
2 minutes without the need for the 5-day BI extraction.
16.3 SPP and EIS 447
Due to the benefits realized in these customer Proof of Concepts, SAP is

evaluating whether it could bring these HANA based Analytics for SPP into
standard.
16.3 SPP and EIS
In 2013 SAP acquired SmartOps, the leader in the market of Enterprise Inventory
Optimization software. EIS (Enterprise Inventory and Service Level Optimization)
is the flagship product, providing multi echelon inventory optimization.
At the time of printing this second edition, SAP is evaluating the integration of
SPP with EIS, combining the strengths of these two products. In a combined system
landscape, SPP inventory planning would offer the options to run the safety stock
calculation and forecast error calculation, considering supply risk and variability,
in EIS.
OSS Notes
1620810 Implementation recommendations for EhP2 of APO 7.0 SPP

1139313 Deployment creates multiple stock transport orders
1389734 Push deployment from supplier creates multiple orders
1454648 Reset steps of supersession realignment
991613 gATP simulation in historical data capture and maintenance
1592280 ATP BAdI not called during SPP demand capture
1610427 Forecast profile: calculate and save offset parameters
1539877 Stability rule not applied in Limited Freeze Horizon
902556 SPP pull deployment: ATP check of distributable quantity
913863 TDL: Composite SAP note for the transaction data layer
925171 DRP Approval: add new approval rule
929169 DRP Approval: add new approval rule (BAdI)

Management for Professionals, DOI 10.1007/978-3-662-45433-6
Abbreviations
ADC Anticipated demand coverage

APO Advanced planner and optimiser
ASN Advanced shipping notification
ATD Available-to-deploy
ATP Available-to-promise
BAdI Business add-in
BAPI Business application interface
BOD Bill of distribution
BOP Backorder processing
BI Business information warehouse
CIF Core interface
CRM Customer relation management
DP Demand planning
DRP Distribution requirements planning
EDI Electronic data interface
EDQA Event driven quantity assignment
EOQ Economical order quantity
ERP Enterprise resource planning
EWM Extended warehouse management
FC Forecast
FDO Future dated order
FOES First order exponential smoothing
GUID Global unique identifier
ICH Inventory collaboration hub
IDN Inbound delivery notification
JIT Just in time
KF Key figure
KPI Key performance indicator
MAD Mean average deviation
MRP Material requirements planning
ODL Order due list
ODM Order data manager

452 Abbreviations
POD Pending obsolescence date

POD Periods of demand
PSM Planning service manager
qRFC Queued remote function call
RFC Remote function call
RQDT Retention quantity determination table
RSG Retention strategy group
SAD Smoothed average deviation
SCM Supply chain management
SED Stock exhaustion date
SEWD Stock exhaustion warning date
SNP Supply network planning
SOES Second order exponential smoothing
SPM Service parts management
SPP Service parts planning
SPPD Successor product planning date
SPRD Successor product receipt date
STO Stock transfer order
TDL Transaction data layer
TPOP Third party order processing
TSDM Time series data manager
TSL Time supply limit
TSL Target service level
UI User interface
VCL Virtual child location
VLCO Virtual location for consolidated ordering
WSS Warehouse space savings
XI Exchange infrastructure
Transactions
For the quick access of some functions this chapter provides a list of useful
transactions for planning with characteristics. Most of these have been explained
in the text.
Master data
Description of the transaction Transaction in SAP APO™
BOD /SAPAPO/BOD001
Assignment of product to BOD /SAPAPO/PROD2BOD_M
Display assignment product-BOD /SAPAPO/PROD_DISP
Display assignment BOD-product /SAPAPO/PROD2BODDISP
Regional pattern /SAPAPO/RGPAT01
Assignment of product to RGP /SAPAPO/PROD2RGP_M
Display assignment product-RGP /SAPAPO/PROD2RGPDISP
Product /SAPAPO/MAT1
Location /SAPAPO/LOC3
Packaging specification /SCWM/PACKSPEC
Test rounding /SAPAPO/AC12
Planner /SAPAPO/PLANNER
Planning profile /SAPAPO/PE_CFG
Execute planning service /SAPAPO/PE_RUN
Planning service log /SAPAPO/PE_LOG_DISP
Planning service log SLG1
Trigger /SAPAPO/TRIGGER
TDL semantics /SCMB/TDL_SEMANTIC
Time series type /SCA/TSDMCFG
TDL tools /SCMB/TDL_TOOLS
Number ranges for TDL /SCMB/TDL_ORDERGUIDS
TDL time series data /SAPAPO/TDL_TS_TEST
TDL order data /SAPAPO/TDL_ORD_TEST
TDL inventory data /SAPAPO/TDL_INV_TEST
Simulation and simulation version /SAPAPO/SPPSIM
Model and version maintenance /SAPAPO/MVM
SPP Simulation: create snapshots /SAPAPO/SPPSNAPSHOT
(continued)

454 Transactions

/SAPAPO/SPPSNAPSHDEL SPP Simulation: Delete Snapshots
TDL: configure decision tables /SCMB/72000010
SPP simulation: version profile /SAPAPO/SPPSIMVERPRF
Capture demand
Administrator workbench RSA1OLD
Administrator workbench RSA1
Info object master data RSDMD
Customising of demand categories /SAPAPO/PDEMCUST
Fiscal year variant OB29
Adjustment of aggregated demand /SAPAPO/SPPDMDH
Adjustment of order items /SAPAPO/SPPDMRD
Real-time data acquisition monitor RSRDA
Maintain data realignment steps /SAPAPO/PDEM_RLGSTEP
Stocking decision
Maintenance of decision tables /SAPAPO/SPPINVPDEC
Exclusion tables /SAPAPO/PINV_EX_MAIN
Stocking/destocking approval /SAPAPO/SPPINVAPPR
Forecasting
Planning book for forecasting /SAPAPO/SPPFCST
Semantics for add. key figures /SAPAPO/TDL_APO_SEM
Forecast profile /SAPAPO/SPPFCSTPRF
Historical forecast /SAPAPO/SPPFCSTTRACK
Forecast approval /SAPAPO/SPPFCSTAPPR
Product view /SAPAPO/RRP3
Phase-out forecasting /SAPAPO/SPPLONGFCST
EOQ and safety stock planning

Target service level maintenance /SAPAPO/PINV_TL_MAIN
Normal or poisson distribution /SAPAPO/PINV_MS_MAIN
Planning book for inventory plan /SAPAPO/SPPINVP
Deployment indicator determination /SAPAPO/DEPL_IND_DEF
Transactions 455
Surplus and obsolescence planning

General settings for surplus /SAPAPO/SORCUST
RQDT /SAPAPO/SORRETQTYDET
Retention strategy group /SAPAPO/SORRETGRP
RSG selection table /SAPAPO/SORRETGRPSEL
Surplus approval /SAPAPO/SPPSOR
DRP and procurement approval

DRP matrix /SAPAPO/SPPDRPM
Fixed requirements /SAPAPO/SPPFIXREQ
Transportation lane /SAPAPO/SCC_TL1
Procurement relationships /SAPAPO/PWBSRC1
Scheduling simulation and explanation /SAPAPO/SPP_SCHD_EXP
Quota arrangements /SAPAPO/SCC_TQ1
Schedule board /SAPAPO/SPPDRPSB
Supplier shutdown /SAPAPO/SPP_SSD
Mass approval /SAPAPO/SPPDRPAPPR
Release creation /SAPAPO/PWBSCH1
Release issue /SAPAPO/PWBSCH2
Assign standard service profiles for UI /SAPAPO/72000069
Kit-to-stock shutdown /SAPAPO/SPP_KSD
Monitoring
Shortage overview /SAPAPO/SPP
Planner’s worklist /SAPAPO/SPP_PLN_LIST
Customer’s worklist /SAPAPO/SPP_DLR_LIST
Role maintenance PFCG
Assignment of users to planners /SAPAPO/USRPLN
Launch NWBC NWBC
POWL administrator cockpit POWL_COCKPIT
Supplier view /SAPAPO/SPP_SUPPLIER
Customer view (internal) /SAPAPO/SPP_CUSTOMER
SPP: delete alerts /SCA/SPP_ALERT_DEL
456 Transactions
Description of the transaction Transaction in SAP SNC™ and SAP XI™

Monitoring of XML messages SXMB_MONI
Description of the transaction Transaction in mySAP ERP™

Inbound delivery VL33N
Copy inbound delivery VL60
Description of the transaction Transaction in SAP EWM™

Goods receipt /SCWM/PRDI
Post stock from file (test only) /SCWM/ISU

Determination of the deployment indicator /SAPAPO/DEPL_IND_DEF
EDQA configuration /SAPAPO/EDQA_PD
EDQA event linkage /SAPAPO/EDQA_EC
EDQA log /SAPAPO/EDQA
TSL parameters /SAPAPO/TSLPAR
Service profile for deployment /SAPAPO/DEPLSPRF
Priority tiers /SAPAPO/TIERDEF
Deployment simulation /SAPAPO/SPPDEPL
Inventory balancing area /SAPAPO/RELHSHOW
Inv. balancing parameter profile /SAPAPO/RDPLPRF
Assign inv. bal. par. prof. to IBA /SAPAPO/RDPLPRFA
WSS storage type settings /SAPAPO/RDPLWSTYPLOC
Warehouse space savings profile /SAPAPO/RDPLWSSPRF
Overview and simulation of EDQA /SAPAPO/EDQA_OS
Inventory balancing unsrv. par. prf. /SAPAPO/SPP_IBUN_PRP
Inv. balancing unsrv. area-parprf /SAPAPO/SPP_IBUN_PPA
Supersession
General settings for supersession /SAPAPO/SPRSCUST
Interchangeability group /INCMD/UI
Transactions 457
Sales order fulfilment

Description of the transaction Transaction in mySAP CRM™
Sales order CRM_ORDER
Description of the transaction Transaction in mySAP ERP™

Display unchecked deliveries VL06U
Check unchecked deliveries VL10UC
Description of the transaction Transaction in SAP EWM

Outbound delivery /SCWM/PRDO
Confirm warehouse order /SCWM/TO_CONF
References
Literature
Arnold, D., Isermann, H., Kuhn, A., & Tempelmeier, H. (2002). Handbuch logistik. Berlin:
Springer.
Bretzke, W. R. (2008, 2010). Logistische Netzwerke 2. wesentlich bearbeitete und erweiterte
Auflage. Berlin: Springer.
Dickersbach, J. T. (2008). Supply chain management with SAP APO. Berlin: Springer.
Leitz, A. (2005). Supplier collaboration mit dem mySAP SCM inventory collaboration Hub. Bonn:
Galileo Press GmbH.
Muckstadt, J. A. (2005). Analysis and algorithms for service parts supply chains. New York:
Springer Science+Business Media Inc.
SAP Online Help for SPP in SAP SCM 7.0. http://help.sap.com/saphelp_scm700_ehp03/helpdata/
en/a3/7ed240caeb752ae10000000a155106/frameset.htm
SCOR. Supply-Chain Operations Reference-model. SCOR Overview 7.0 1_06.pdf. http://www.
supply-chain.org/site/scor7booklet2.jsp

Index
A D
ABC classification, 153f Data source, 51
Additional safety stock, 148 Days of supply, 183ff
Adjust safety stock, 148 Decision profile, 74
Advanced shipping notification (ASN), 260ff Decision tables, 71f
Aggregated forecast, 83 Declining demand, 120
Aggregation, 54, 57 Delivery, 248
Alert monitor, 397ff Delivery schedule, 250
Alert types, 396, 414 Demand category, 54f
Anticipated demand coverage, 204ff Deployment indicator, 22, 153, 268f
Approval rules, 252f Deployment matrix, 273, 311
ASN validation, 262 Disaggregated forecast, 83
ATP category, 172 DRP matrix, 173ff
ATP check, 382ff Dynamic moving average, 119
ATP profile, 379
Authorised stocking list, 67
Available quantity for deployment, 272f E
Economic order quantity, 139ff, 171, 183
Event driven quantity assignment, 270ff
B Excess determination, 330
Bill of distribution, 8 Exclusion tables, 75
Business content, 50 Expedited shipments, 308f
Business type, 21 Exponential smoothing, 158
F
C
Fair share, 277ff
Calendar, 25, 60, 179
First order exponential smoothing, 112
Capture demand, 50ff
First stockholding location, 54f
Check instructions, 384
Fiscal year variant, 57f
Component procurement lead time, 188ff
Fixed requirements, 185f, 204
Composite forecast, 82
Forecast approval, 123f
Consolidated ordering, 12
Forecast horizon, 110f
Contract, 172, 209
Forecast model, 108ff
Contract packager, 21
Forecast profile, 89ff
Core interface (CIF), 5
Forecast service, 94ff
Cost and benefit analysis, 333ff
Forecast trend delimiter, 113f
Criticality status, 408f
Freeze horizon, 193
Current model part, 157, 159ff
Future dated order, 85f, 181
Customer facing location, 55f
Future due receipts, 274f

462 Index
G O
Goods issue, 21, 385ff Obsolescence check, 156, 169
Goods issue cost, 340 Obsolete, 164, 169
Goods receipt, 21, 263f Offset, 98
Goods receipt cost, 340 Open quantity, 408
Operational planning, 6
Order cost, 140f, 142
H Order due list, 270f
Hierarchy, 327f Outlier correction, 119f
Hierarchy structure, 15, 19, 328 Overdue, 179
Historical forecast, 97ff
Holding cost factor, 142, 213, 314
Horizon for expected receipts, 275 P
Horizons, 193ff Packaging specification, 27f
Packaging specification group, 26
Parameter tuning, 109f
I Past model part, 157, 161ff
Initialisation, 112 Pending obsolescence date, 345
Interchangeability master, 349 Periodicity, 57
Intermittent model, 119f Periods of demand, 173, 276ff
Inventory balancing area, 327ff Phase-in forecasting, 125f
Inventory savings, 333 Phase-in group, 125f
Phase-out forecasting, 127f, 143f
K Phase-out group, 120f
Key figure, 85f, 175f Planner, 30f
Key figure view, 86f Planning
book for forecasting, 84ff, 88
book for inventory planning, 151ff
L horizon, 193
Last purchase order, 162 mode, 159
Lead time, 230 profile, 32f
Level set, 26 service, 30f
Level type, 26 service manager, 31ff
Life cycle, 125ff Plan submission horizon, 193
Limited freeze horizon, 193 Poisson distribution, 147f
Linear regression, 113 Pre-season safety stock shift, 207ff
Location, 23, 290f Prevented loss, 337f
Log, 38 Preventive maintenance, 2
Price quantity scales, 150f
Primary products, 1
M Priority tiers, 277f
Manage demand, 61ff Process category, 270
Mass approval, 254f Process profile, 32f
Master data, 5, 13 Procurement cost, 212, 334
Maximum value profile, 252f Product group, 23
Model selection, 107ff procurement, 209ff
Move costs, 333 type, 24
Moving average, 112f Production, 2
MRP area, 21 Product master, 23
Product storage cost, 212
Projected stock, 173
N Promotion, 63
Need determination, 331f Pull deployment, 267ff
Net requirements calculation, 173ff Purchase requisition, 250
Normal distribution, 144, 147f Push deployment, 267ff
Index 463
Q Stability rules, 196ff

Quota arrangement, 210 Standard deviation, 121f
Start of planning horizon, 179
Status, 250f
R Status sequence, 418f
Realignment, 63ff, 349f
Stock exhaustion date, 354
Reason code, 167f
Stock exhaustion warning date, 346, 360
Regional pattern, 18
Stockholding cost, 141f, 211
Regional stocking, 75 Stock transfer approval, 313, 341
Release creation, 257f
Substitution order, 365f
Release transfer, 259f
Successor product planning date, 356
Remanufacturing, 3
Successor product receipt date, 356
Repair, 3 Supersession, 343ff
Replenishment indicator, 63f
Supersession service, 344, 351f
Replication, 51
Supplier shutdown, 214f
Requirements profile, 379, 383 Supply shortage, 174
Retention period, 1, 160, 162f
Surplus approval, 166ff
Retention quantity determination table, 161
Surplus decision code, 167f
Retention strategy group, 164f
Surplus disaggregation, 165f
Rounding profile, 26ff, 28f, 147 Surplus planning, 156ff
Rule for de-stocking, 68f
Surplus quantity determination, 157ff
Rule for stocking, 68f
S T
Safety days’ supply, 411 Tactical planning, 6
Safety stock, 139ff Target service level, 143, 146f, 151
Sales order, 377 Tier processing, 279
Savings per bin, 335 Time bucket profile, 167
Scaling, 59f, 178 Time supply limit, 257ff
Schedule board, 211, 250, 256f Total procurement lead time, 187f
Scheduling, 186ff Tracking, 101f
agreement, 209, 250ff Transactional data layer, 40ff, 50
scenario, 189f Transport costs, 340
simulation, 192 Trigger, 38f
Scrapping indicator, 167f Tripping, 105f
Seasonal trend model, 107f
Seasonal trend model with fixed periods, 108
Second order exponential smoothing, 115 U
Selection profile, 34f Unchecked delivery, 385f
Sequence rules, 277ff
Service benefit, 337ff
Service fill monitor, 423ff V
Service parts, 1 View, 23
Set-up cost, 213 Virtual child location, 13
Ship-from location, 55 Virtual location for consolidated ordering, 18
Shortage monitor, 391
Shortage overview, 410
Simulation, 44ff W
Snapshot, 47f Warehouse order, 388f
Sporadic demand, 2 Warehouse space savings, 333ff
SPP cockpit, 419f Warehouse space savings profile, 333
Stability period, 75 Warehouse task, 387ff

SPP Springer Book - Second Edition PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SPP Springer Book - Second Edition PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Management for Professionals

Service Parts Planning

ISSN 2192-8096 ISSN 2192-810X (electronic)

Library of Congress Control Number: 2015937186

Springer Heidelberg New York Dordrecht London

Printed on acid-free paper

Springer-Verlag GmbH Berlin Heidelberg is part of Springer Science+Business Media

Jörg Thomas Dickersbach and Michael F. Passon

1 Service Parts Planning Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 1

7 Surplus and Obsolescence Planning . . . . . . . . . . . . . . . . . . . . . . . . 155

13.3 ATP Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

1.1 Supply Chain Management for Service Parts

Supply chain management is the process of planning, implementing, and

High Number of Service Parts

# Springer-Verlag Berlin Heidelberg 2015 1

Mercedes-Benz e.g. guarantees an availability of 10 years after the production end

Authorized Stocking List

Availability and Safety Stock

Service Parts Production

1.2 Overview on Systems and Processes for Service Parts

• sales, claims and returns, and entitlement management

1.3 Processes for Service Parts Planning

Service Parts Execution

Service Parts Planning Within SAP APO™

Service Parts Planning Overview

Tactical Planning Operative Planning

Stocking & Procurement

Manage Demand Procurement

EOQ & Safety Stock Inventory Balancing

Surplus & Stock Transfer

Service Parts Planning Service Parts Execution

Fig. 1.3 Overview of service parts planning processes

• decision about stocking or de-stocking

for each location product and—optionally—the scrapping of surplus quantity.

customer facing warehouses have sufficient inventory to fulfil the customer

Business Scenarios and Business Processes Available in SPP

Table 1.1 Overview on 1. Inbound Planning Scenario

Fig. 1.4 Overview on the main material flows planned by SPP

The process “procure to stock” is mainly represented by the services and

Fig. 1.5 SPP-processes in inbound planning stream

can be executed also in-house or externally at subcontracting partners. In both cases

Fig. 1.6 SPP-processes in the outbound planning stream

The process “Internal outbound of stock” (process number 2.2) is mainly

locations of immediately previous levels. Under certain circumstances it is neces-

1.3.1 Scope and Limitations of This Book

2.1 Master Data

2.1.1 Bill of Distribution

Virtual Child Location

Example for a Bill of Distribution

# Springer-Verlag Berlin Heidelberg 2015 13

London Köln Berlin

Lyon Lille Frankfurt

Fig. 2.1 Example for a supply chain

Each of the distribution centres—except Frankfurt—sell service parts to

Lyon Lille Frankfurt Stuttgart

London Lille Köln Berlin

Fig. 2.2 Bill of distribution for the example

BOD 1 BOD 2 BOD 3

Fig. 2.3 BOD modelling alternatives

Fig. 2.4 Hierarchy structure for the BOD

Fig. 2.5 Product-relevant hierarchy structures

Indicator for Virtual Child Location

Fig. 2.6 BOD maintenance