04H Sub Networks

Specification for Extensions of S&OP on HANA:
Planning Units
April 19th, 2016
1. Introduction
The Supply Chain master data model used by the SCM Planning Operator in S&OP
describes the entire supply chain of a company, at least the entire part of the supply
chain to be considered within S&OP. By the superordinate term SCM Planning
Operator we refer to SCM planning algorithms in S&OP, i.e. SCM heuristic and the
optimizer which are used to compute a supply plan.
Based on organizational or regional responsibilities, in general planners often do not
plan the entire model but rather just a sub-network they are responsible for or want to
manage in a particular step. These sub-networks are denoted in the following as
Planning Units (PUs). Meanwhile, it was decided to rename the term Planning Units
into Sub-Networks as of IBP 4.0. However, this rename is not yet applied to this
documentation.
Such a PU is built, like the entire network, from nodes (which are location products or
customer products) and arcs (which connect these nodes to model transport links
between them). An attribute in the location product master data defines to which PU
a location product belongs. So, PUs can be structured by product groups or regions
or any other property of locations, products, or location products.
There is a set of location products that a user is allowed to display data for. This is
defined via S&OP Visibility Filters (see the S&OP documentation on users and roles).
All node-related and all arc-related key figures of these location products are
available as input to the SCM Planning Operator in the planning session. Also all
customer products related to the selection are used in the planning session.
A planner can select one or several PUs before starting a new planning session.
These selected PUs, briefly called the selection or the selected PUs, implicitly
define the set of location products which are changeable for an SCM Operator call.
One can configure which Planning Units a user is allowed to change and hence
which ones are available for planning with the SCM Operator. This has to be a
subset of the Visibility Filter.
When calling the SCM Planning Operator the system computes a supply plan for the
selected PUs. This means the supply plan computations take as input Consensus
Demands if they are to be satisfied by (at least) one of the selected PUs and the
computations take as input the results (Dependent Location Demands and
Transports) of the planning runs of neighboring not selected PUs, which are
Page 1
downstream (being supplied by the PUs to be planned). The SCM Operator stops at
the boundaries of the selected PUs to prevent that the supply plans of the
neighboring PUs are overwritten.
Supply plans can be computed individually for PUs (or selections of them) in an
arbitrary order. Therefore, the system needs to support all possible situations in
which a supply plan does or does not exist for all or some neighboring PUs. This
document will explain the boundary logic in more detail in a sub-sequent section.
2. Assumptions
We assume that for Planning Units the following assumptions hold:
a) An attribute Planning Unit on location product level defines the PU of a location
product. This implies that each location product belongs to at most one PU. If the
attribute Planning Unit has an initial value the corresponding location product does
not belong to any PU.
b) Customer Products and with this Customer Demands do not belong to Planning
Units.
c) Customer Demands can in general be supplied from several locations belonging to
different PUs. Heuristic and optimizer then will propagate only a portion of the
Customer Demand to the selected PUs which is computed with the quotas of the
customer sourcing master data. For example if a Customer Demand of 10 units has
to be sourced from a location product in PU A with 30% and from another location
product in PU B with 70% the SCM Operator would compute a fraction of the total
Consensus Demand of 3 units if the user selects only PU A for a planning session.
d) Before starting a planning session, the user can specify one or several Planning
Units to be selected for this planning session. It is not possible to only select parts of
PUs. However, given sufficient permissions a user can select no Planning Unit, in
which case the whole network is selected. The system then will load the entire model
into this planning session and the SCM Operator will compute a plan for the entire
network, if called. The SCM Planning Operator will change key figures only within the
boundaries of the selected PUs, i.e. only those key figures which belong to location
products within these PUs and key figures belonging to arcs of which at least one of
the two connected location products belong to one of the selected PUs. However,
there is an exception to this rule which is explained around figure 9b in section 3.2.
Which PU a user is allowed to select for planning and whether or not the user can
plan the entire network is configured via a new type of permission.
f) If the user wants to change the selection of location products to be planned, he has
to terminate (save and/or cancel) the current and start a new planning session, with
changed PU selection criteria.
Page 2
g) Each output and each input product (better to say each output and each input
location product) of a production source should belong to a Planning Unit. Each
output and each input product can belong to another Planning Unit. However, the
model is less complex if all output and all input products, i.e. the entire production
source of supply belongs to only one Planning Unit.
If you assign different PUs to output and input products, i.e. if not the entire
production source is modelled within one single PU, additional cost key figures have
to be populated before you run the S&OP Optimizer to compute a supply plan for the
some of the affected PUs. (See chapter 6).
h) Resources are not assigned explicitly to PUs.
i) It is not allowed to model a resource which is used by location products of different
PUs. If resource R is used by location products (via P-rules) of PU A and by location
products of PU B, the capacity demand of R would be incomplete if a user selects
only PU A or B. Hence, the optimizer would compute a supply plan without taking into
account the entire capacity demand of R. We might therefore add checks to prevent
resources being used by different PUs.
3. Boundary Logic
3.1 The Concept of the Boundary Logic
As explained in section 1 Planning Units are introduced to enable planners to plan
sub-networks, i.e. merely the part of the entire supply chain they are responsible for
or interested in. To do so, planners can select just one PU or they can combine
several PUs into one selection.
For example, several global planners, each responsible for a product group, might
plan for selections of PUs where the individual PUs represent all the regional part of
a product groups supply chain. The complete selection represents the global plan.
After this step two planning processes have to be performed in order to achieve a
common global plan for the entire company. First, the global supply plans of the
product groups have to be combined into one common global supply plan containing
all products. Second, the regional planners might have to adapt the global product
group plans to their regional needs and limitations. In the sequel we describe in detail
how these two processes can be managed by S&OP on HANA.
A transportation sourcing rule (T-rule) crosses the border between two PUs, if the
ship-to location product belongs to PU A and the ship-from location product to PU B.
We differentiate between inner and outer border arcs. Inner border arcs cross the
border between two selected PUs. Outer border arcs cross the border between a
selected and a not selected PU.
Page 3
If a planner has selected several PUs, it is assumed that he is responsible for the
whole selection and therefore allowed to generate a new plan or to change the
existing one for this entire selection. His responsibility ends at the Outer Border Arcs
meaning that the system should prevent him from making changes to neighboring
location products outside his selection. A result of his planning process is a supply
plan for his selection and certain proposals (concerning demand and supply) at the
outer border arcs. Planners of neighboring PUs or neighboring sub-networks should
be able to see the outer border proposals, but both parties have to negotiate to find
an agreement called Outer (Border) Handshake about how much demand is
propagated up-stream and how much supply is provided down-stream along the
supply chain.
A (global) planner who is responsible for a selection of PUs might want to fix certain
decisions at the inner border arcs to make these decisions binding restrictions for his
subordinate regional planners. We call this the Inner (Border) Handshake. While an
Outer Handshake is a result of a negotiation between planners on the same level, the
Inner Handshake is an alignment of high-level global plans with subordinate local
plans.
3.2 Examples
Figure 1 depicts a (simplified) representation of a selection of two Planning Units A
and B. For simplicity both PUs are made up of only one location product. Starting
point for this example is one customer demand of 20 units.
The planner has selected both PUs so that PU A and B are part of the planning.
Figure 1 illustrates the result of the SCM Planning Operator. We assume in this and
in all subsequent examples and figures that the planning horizon is only one period
and stock on-hand is zero. In addition, it is assumed no lead time between the two
locations.
In all sub-sequent figures you will see the selected PUs in front of a blue background,
in Figure 1 these are both PUs A and B. Key figures in blue color belong to the
selection, i.e. they might be updated by the SCM Planning Operator. Key figures in
green color belong to PU B, if B is not selected (and therefore will not be updated by
the SCM Planning Operator). Key figures in red color belong to PU A, if A is not
selected (and therefore will not be updated by the SCM Planning Operator).
Page 4
Planning Session within Two Selected Planning Units

Selection = {A, B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
D:
S:
R:
N:
DCD: 20
CR: 20
D:
N:
R:
S:
Dependent Demand
Supply
Total Receipts
Net Demand
20
20
20
20
BB
OLD: 20
D:
N:
R:
S:
TR: 20
DCD:
OLD:
CR:
TR:
Dep. Customer Demand

Outbound Location Demand
Customer Receipts
Transport Receipts
20
20
20
20
OLD: 20
TR: 20
ATR:
Adjusted Transport
IPUDLD: Inter-Planning Unit Loc. Demand
IPUTR: Inter-Planning Unit Transport
2014 SAP AG. All rights reserved.
Figure 1: Planning a Selection of two Planning Units
In Figure 1 we see the following flow: a Dependent Customer Demand of 20 is

sourced from PU A corresponding to location product DC1 / P1. The derived Net
Demand of 20 is propagated along a location source to location product DC2 / P1
which belongs to PU B. Distribution center DC2 gets its Net Demand of again 20
units satisfied by a transport receipt (from somewhere not shown) and therefore can
deliver 20 units to DC1. As both PUs are selected nothing special happens at the
Inner Border Arc between DC1 and DC2.
Once the planner is satisfied with his plan he can fix demand and supply at the
inner border arcs. To perform this Inner (Border) Handshake he just has to set an
Adjusted Transport as one can see in Figure 2. It should be clear that Figure 2
shows the result of a heuristic run after the user has entered the value 16 into the
Adjusted Transport (ATR). With the Adjusted Transport the planner has fixed supply
and as a consequence the corresponding Outbound Location Demand at that arc.
Note: Adjusted Transports key figure here has the very same behavior as in
situations without PUs or within a PU.
Page 5
Inner Border Handshake via Adjusted Transport

Selection = {A, B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
BB
OLD: 16
20
20
16
20
TR: 16
D:
N:
R:
S:
16
16
16
16
OLD: 16
TR: 16
ATR: 16
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 2: Inner (Border) Handshake via Adjusted Transport
In a next step a planner selects only PU A (see Figure 3). Then the heuristic Infinite
with No Shortages will compute for this selection the supply plan shown by Figure 3.
Based on a Consensus Demand of 20 the resulting Net Demand is 20. As the
Adjusted Transport is set to 16 (either by a global planner as shown in Figure 2 or by
PU B), the heuristic propagates an Outbound Location Demand of 16 in upstream
direction. As PU B is not part of the selection, this demand propagation stops at the
outer border arc. The selected PU A computes its supply plan based on the given
Transport Receipts of 16 which happens to be fixed by the Adjusted Transport from
the previous planning step performed globally or by the planner of PU B.
In Figure 3 we see two new key figures:
- IPUDLD: Inter-Planning Unit Dependent Location Demand
- IPUTR: Inter-Planning Unit Transport Receipts
Both IPU-key figures are used to decouple two neighboring PUs and therefore they
have a specific semantic at outer border arcs. They are ignored at inner border arcs.
We will explain their functionality in detail starting with Figure 6.
Page 6
Planning PU A (Supply defined via ATR)

Selection = {A}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
20
20
16
20
OLD: 16
IPUDLD:
TR: 16
D:
N:
R:
S:
16
16
16
16
OLD: 16
TR: 16
ATR: 16
IPUTR:
PU A respects supply
fixed by global
planner or PU B
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 3: Planning of PU A only whereas supply is given by key figure ATR
The difference of the following example in Figure 4 compared to the one in Figure 3
is that ATR is not set or was blanked out by the planner. If ATR (and key figure
IPUTR) is initial the SCM Planning Operator then takes the value in key figure
Transport (TR) as the given supply for PU A. This value (which is 16 in Figure 4)
defines the supply for PU A. PU A cannot assume to get more and it cannot take less
even in a case in which it would need less than the given supply of 16 units. For
that reason the TR value as the ATR is modelled as a pseudo-hard constraint for
the optimizer.
Page 7
Planning PU A (Supply defined via TR)

Selection = {A}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
20
20
16
20
OLD: 20
IPUDLD:
TR: 16
D:
N:
R:
S:
16
16
16
16
OLD: 16
TR: 16
ATR:
IPUTR:
PU A respects supply
computed by the
global planner or PU B
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR was blanked

out before
ATR:
Adjusted Transport
Figure 4: Planning PU A only whereas supply is given by key figure Transport
In contrast to the previous example (Figure 4) the next example (Figure 5) shows a
situation in which none of the supply key figures TR, ATR, or IPUTR stores a value.
This constellation exists if PU B was not yet planned at all for that period or if the
planner of PU B has deleted his plan. As a consequence, no supply is defined for PU
A which results in a Receipts quantity of zero as depicted by Figure 5.
Page 8
Planning PU A (no Supply defined)

Selection = {A}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
20
20
0
20
OLD: 20
IPUDLD:
TR:
D:
N:
R:
S:
OLD:
TR:
ATR:
IPUTR:
PU A has no supply
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
No supply
determined by PU B
ATR:
Adjusted Transport
Figure 5: Planning PU A only whereas no supply is pre-defined by PU B
In such a situation as shown in Figure 5 the planner of PU A might want to set a

certain supply value in order to be able to simulate the consequences on PU A. This
is illustrated by Figure 6 in which the planner of PU A has set a Transport of 20 units
via key figure IPUTR. Populating this key figure has two effects:
1. IPUTR defines supply for PU A as an absolute value, meaning that PU A has
to receive this quantity (and not less even if it would need less) and PU A
cannot get more (even if it would need more to satisfy its demands).
2. As IPUTR overrules ATR and TR a non-initial value in that key figure
decouples PU A from PU B in that sense that whatever and whenever PU B
has published a value in ATR or TR, PU A will ignore it and will take the
supply defined in IPUTR instead.
Based on the IPUTR value of 20 units, now PU A assumes to get this supply. As a
consequence the resulting Projected Inventory (which is not displayed) at DC1 will be
zero in contrast to the situation given by Figure 5 in which the resulting Projected
Inventory will be -20.
Setting a value into key figure IPUTR is part of the Outer Border Handshake in
which both planners have agreed on how much goods will be delivered from PU B to
PU A. The planner of PU A will set the agreed amount into IPUTR to fix this supply
Page 9
for his PU. And, as we will see below, the planner of PU B has to fix this supply too
via key figure ATR in order to manifest the Outer Border Handshake on his side.
Planning of PU A based on IPUTR

Selection = {A}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
20
20
20
20
OLD: 20
IPUDLD:
TR:
D:
N:
R:
S:
OLD:
TR:
ATR:
IPUTR: 20
Planner A decouples
PU A from PU B
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 6: Planning of PU A only based in IPUTR
The only difference between the examples of Figures 6 and 7 is that in Figure 7 the
incoming Customer Demand is 13 instead of 20 units. As IPUTR still is set to 20 and
as PU A has to take the entire supply PU A is able to satisfy the Customer Demand
and it builds up a Projected Inventory (not displayed) of 7 units at the end of the
depicted planning period. As mentioned above, the supply key figures TR, ATR and
IPUTR define absolute fixed values meaning that PU A has to receive exactly the
quantity defined in one of these key figures independent of the actual Net Demand of
PU A and independent of what PU B really is able to deliver.
As shown in Figure 7 the IPUTR impacts the Outbound Location Demand as it
overrules (not overwrites) the Net Demand.
Page 10
Planning of PU A based on Excessive Supply

Selection = {A}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 13
CR: 13
D:
N:
R:
S:
13
13
20
13
OLD: 20
IPUDLD:
TR:
D:
N:
R:
S:
OLD:
TR:
ATR:
IPUTR: 20
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 7: Planning of PU A only based on an excessive supply
Figure 8 below continues the example of Figure 6, but with the change that now PU
B was selected to be planned independently. The Outbound Location Demand (OLD)
computed during the planning process of PU A now is input for PU B. Based on this
Dependent Demand PU B computed (as shown in Figure 8) a Supply of 20 units.
Key figure Inter-Planning Unit Dependent Location Demand (IPUDLD) is a key
figure in which a user can enter values to over-rule the OLD values. If key figure
IPUDLD contains a non-initial value (zero or any other integer value) the SCM
Planning Operator takes this non-initial value from IPUDLD as input for PU B to
compute its Dependent Demand as we will explain in the sequel.
This logic of IPUDLD versus OLD decouples PU B from PU A because the input for
PU B is not always and immediately changed after PU A has generated a new plan, it
stays constant until someone (presumably the planner of PU B) changes or blanks
out the IPUDLD value(s).
Page 11
Planning of PU B
Selection = {B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
OLD: 20
20
20
20
20
IPUDLD:
TR: 20
D:
N:
R:
S:
20
20
20
20
OLD: 20
TR: 20
ATR:
IPUTR: 20
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 8: Planning of PU B only
In Figure 9 we now assume that the planner of PU B has used the optimizer to
compute a supply plan for his planning unit (whereas the plan shown in Figure 8
possibly was computed with the heuristic or the optimizer.) What we see in Figure 9
is that supply now is lower (16 units) than the Dependent Demand (20 units) clearly
indicating that the optimizer could not find enough supply to satisfy the entire demand
of 20 units given by PU A. As a result the transport from PU B into PU A contains 16
units only. As IPUTR is still 20, there is no impact on PU A. A value in key figure
IPUTR protects the downstream Planning Unit A from being updated while PU B is
planned.
Page 12
Example 6: Re-Planning of PU B with Optimizer

Selection = {B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
20
20
20
20
OLD: 20
D:
N:
R:
S:
IPUDLD:
TR: 16
16
16
16
16
OLD: 16
TR: 16
ATR:
IPUTR: 20
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 9: Supply plan of PU B computed with the optimizer
If there was no IPUTR set (as shown in Figure 9b) the transport quantity computed
by planner B would be immediately updated into PU A as shown by Figure 9b.
The system updates key figures Total Receipts, Projected Inventory and Deficit at the
receiving location product (DC1 in PU A). All other key figures of DC1 which depend
on Total Receipts will be updated when Planning Unit A is planned again.
In general, only key figures belonging to the selected Planning Units are updated by
the S&OP operator (heuristic or optimizer). As an exception to this rule, only the key
figures Total Receipts, Projected Inventory and Deficit are updated outside the
selection, if key figure IPUTR is initial.
Page 13
Example 6: Re-Planning of PU B with Optimizer

Selection = {B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
20
20
16
20
OLD: 20
IPUDLD:
TR: 16
D:
N:
R:
S:
16
16
16
16
OLD: 16
TR: 16
ATR:
IPUTR:
Immediate update of
Total Receipts, Proj.
Inventory and Deficit
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 9b: Update of downstream Planning Unit
If the planner of PU B decided to fix his supply he would have to populate key figure
Adjusted Transport (ATR) as shown in Figure 10 which shows the result after the
planner has entered / copied the value 16 into key figure ATR and after he has called
the SCM Planning Operator. It is noticeable that the ATR value in Figure 10 overrules the OLD (and if IPUDLD is non-initial, the IPUDLD value as well) when PU B
computes its Dependent Demand. For that reason the Dependent Demand (D) at
DC2 is 16 (derived from ATR) and not 20 units.
As mentioned above, setting a value into ATR is the task resulting out of the Outer
Border Handshake which the planner of PU B has to perform. According to this
agreement he should fix his supply (and by doing so implicitly the incoming demand)
in order to guarantee the agreed supply to PU B.
As in Figure 10 key figure IPUTR contains a value PU A is protected and hence not
updated after the planner of PU B has updated key figure ATR. If IPUTR was initial,
the update of key figure ATR would lead to an update of key figures Total Receipts,
Projected Inventory and Deficit of location product DC1 / P1 in PU A.
Page 14
Planning of PU B: Fixing Supply

Selection = {B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 20
CR: 20
D:
N:
R:
S:
OLD: 20
20
20
20
20
D:
N:
R:
S:
IPUDLD:
TR: 16
16
16
16
16
OLD: 16
TR: 16
ATR: 16
IPUTR: 20
Planner B fixes
his supply
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 10: Fixing Supply of PU B
With Figure 11 we continue the example of Figure 10. The user has selected PU A
again and he has increased the Customer Demand from 20 to 21. In addition, the
assumption here is that the planner wants to generate a supply plan for this
increased Customer Demand independently of the supply which was fixed by himself
(in key figure IPUTR) or his colleague, the planner of PU B who has set key figure
ATR. To be able to ignore the fixed supply the SCM Planning Operator will offer a
new parameter (Compute Expected Supply). If this parameter is chosen the system
will ignore (but not delete) the values in key figures TR, ATR and IPUTR and it will
compute the supply which is needed to satisfy the demand of PU A (which is 21 units
in Figure 11) and it will update these computed supplies into key figure IPUTR. This
functionality is illustrated in Figure 11 as the fixed supply values are stroked through
and it is visible that IPUTR gets updated by the expected supplies.
Page 15
Planning PU A ignoring IPUTR and supply from PU B

Selection = {A}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 21
CR: 21
D:
N:
R:
S:
21
21
21
21
OLD: 21
D:
N:
R:
S:
IPUDLD:
TR: 16
16
16
16
16
OLD: 16
TR: 16
ATR: 16
IPUTR: 20
IPUTR: 21
PU A computes
expected supply
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
PU A updates
IPUTR
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
Operator parameter:
Compute_Exp_Supply = YES
ATR:
Adjusted Transport
Figure 11: Planning PU A independently of fixed Supply
For the example of Figure 12 it is assumed that the planner of PU B removed

(blanked out) the value in key figure ATR and that he entered a new value into
IPUDLD (of 18 units). The result computed by the S&OP heuristic is shown by Figure
12. The ATR has no effect anymore and the IPUDLD value over-rules the OLD value
while the heuristic computes a supply plan for PU B. As we will see in chapter 5 the
IPUDLD value over-rules the OLD as well when the S&OP Optimizer is chosen as
planning algorithm.
Page 16
Removing Outer Border Handshake

Selection = {B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 21
CR: 21
D:
N:
R:
S:
21
21
21
21
OLD: 21
IPUDLD: 18
TR: 18
D:
N:
R:
S:
18
18
18
18
OLD: 18
TR: 18
ATR:
IPUTR: 21
Planner B blanked
out ATR
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 12: Blanking out ATR values and entering a value into IPUDLD
We assume that meanwhile the planners of PU A and B had their Outer Border
Handshake agreement according to which 20 units should be supplied from PU B to
A. Figure 13 illustrates what happens if the planner of PU B enters this agreement
into the system, i.e. into key figure ATR. The supply plan which is computed after the
planner of PU B has called the SCM Planning Operator is given by Figure 13.
Again, the ATR over-rules the demand key figures, i.e. OLD and IPUDLD which
becomes visible by the Dependent Demand of DC2, which is 20 (and not 18 or 21).
The planner of PU B can optionally set the IPUDLD value to 20 as well (which is not
assumed for Figure 13.) The situation might look more logical if IPUDLD was set to
the same value as the fixed supply (ATR). However, the planner could also decide to
leave IPUDLD unchanged, for instance, to remember himself what the original
demand was (before the ATR was set according to the Outer Border Handshake.
Page 17
PU B fixes Outer Border Handshake

Selection = {B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 21
CR: 21
D:
N:
R:
S:
21
21
21
21
OLD: 21
D:
N:
R:
S:
IPUDLD: 18
TR: 20
20
20
20
20
OLD: 20
TR: 20
ATR: 20
IPUTR: 21
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 13: PU B fixes Outer Border Handshake again
As mentioned above already, both planners have to implement the agreement of the
Outer Border Handshake and this means that the planner of PU A also has to fix the
agreed quantities. This part of the process is visualized by Figure 14 which shows
the result of the SCM Planning Operator after planner B has entered the agreed
supply of 20 units into IPUTR. As the Customer Demand is still 21 units and as PU A
gets only 20, PU A cannot satisfy the entire demand.
Page 18
PU A fixes Outer Border Handshake

Selection = {A}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 21
CR: 21
D:
N:
R:
S:
21
21
20
21
OLD: 20
IPUDLD: 18
TR: 20
D:
N:
R:
S:
20
20
20
20
OLD: 20
TR: 20
ATR: 20
IPUTR: 20
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 14: Result of the Outer Border Handshake
To make our example even more interesting Figure 15 continues with a scenario in
which a (global) planner again selected both Planning Units. The SCM Planning
Operator, when called, blanks out and ignores all IPUDLD and IPUTR values at inner
border arcs, i.e. at arcs which cross two selected PUs.
The SCM Planning Operator then re-plans the entire selected model without the
demands and supplies previously fixed via the two IPU key figures. However, as ATR
is not blanked out the supply between both PUs is still fixed in the example of Figure
15. Figure 16 then shows what happens after a user has removed the ATR value.
Now the heuristic is able to plan the entire model without any limitations concerning
supply between the two PUs.
Page 19
Planning both PUs again

Selection = {A, B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 21
CR: 21
D:
N:
R:
S:
BB
OLD: 20
21
21
20
21
D:
N:
R:
S:
IPUDLD:
TR: 20
20
20
20
20
OLD: 20
TR: 20
ATR: 20
IPUTR:
IPU values at inner

border arcs blanked
out automatically
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 15: Planning both PUs again
Planning both PUs after removing ATR

Selection = {A, B}
Planning Unit B
Planning Unit A
DC2 / P1
DC1 / P1
A
C1
DCD: 21
CR: 21
D:
N:
R:
S:
21
21
21
21
BB
OLD: 21
D:
N:
R:
S:
IPUDLD:
TR: 21
21
21
21
21
OLD: 21
TR: 21
ATR:
IPUTR:
Global planner
removed ATR
D:
S:
R:
N:
Dependent Demand
Supply
Total Receipts
Net Demand
DCD:
OLD:
CR:
TR:

Customer Receipts
Transport Receipts
ATR:
Adjusted Transport
Figure 16: Planning both PUs after removing ATR

Page 20
3.3 Final Remarks

The two IPU Key Figures IPUDLD and IPUTR are taken into account only at Outer
Border Arcs. If within another selection an outer border arc becomes an inner border
arc, the IPU Key Figures are blanked out and ignored by the SCM Planning
Operator.
IPUDLD is an input and output key figure of S&OP. It is input as it is editable and a
user can enter values into that key figure. However, it will be blanked out if the
related arc becomes an inner border arc.
Key Figure IPUTR is also an input and output key figure. It is editable and therefore
input to the SCM Planning Operator and in case the parameter Compute Expected
Supply is used (Figure 11) the operator writes computed supply into it so that it is an
output key figure as well. And it will be blanked out if it becomes an inner border arc.
The technical name of key figure Inter-Planning Unit Dependent Location Demand
(IPUDLD) is IPUDEPENDENTLOCATIONDEMANDDS, the key is: product, location,
ship-to location. Note: The suffix DS refers to the fact that this key figure is a
Downstream Key Figure. (The concept and background of Downstream Key Figures
is described in the specification The Operators Key Figures.)
The technical name of key figure Inter-Planning Unit Transport Receipts (IPUTR)
is IPUTRANSPORT, the key is: product, location, ship-from location.
The boundary logic is mainly controlled by these two IPU Key Figures and Adjusted
Transports (ATR) which users have to manage. To support the users in this task one
can configure special copy-functions to copy values from TR into ATR and from OLD
into IPUDLD or from ATR into IPUTR.
It is also important to be able to remove (to blank out) values in these key figures. For
instance, a planner might want to remove the IPU values (and, of course, the
Adjusted Transport values) while simulating a scenario without the boundary
conditions that are the result of a Handshake as described above. Another process
requesting the ability to blank out these values is the beginning of a new planning
cycle, after rolling forward the supply plan by one month to the future. To support
such processes S&OP on HANA will offer dedicated calls of the SCM Planning
Operator to selectively blank out the ATR, IPUTR and IPUDLD key figures in
upstream and downstream direction.
It also might be useful to have functions to blank out selectively the IPU values at
inner border arcs.
Page 21
4. Cost and Revenue Key Figures

4.1 Inter-Planning Unit (IPU) Non-Delivery Costs and Revenue
Products which are sold to the market do have in S&OP on HANA a sales price
which is stored in key figure Non-Delivery Cost Rate. These non-delivery costs are
essential to motivate the optimizer to satisfy the given Consensus Demands. In its
objective function the optimizer takes into account the difference between Consensus
Demand and the Total Constrained Demand, i.e. the difference between the
requested quantity and the planned supply for a customer. Within the objective
function this difference is multiplied by the corresponding Non-Delivery Cost Rate
(period by period) and as the objective is to minimize the sum of all costs the
optimizer will try to minimize the difference between Consensus Demands and Total
Constrained Demands.
Semi-finished products which are supplied by an upstream PU to another
downstream PU do not have necessarily a market sales price and therefore no nondelivery costs. Without these non-delivery costs, however, the optimizer might decide
not to ship and hence not to produce, procure or transport anything while computing
a supply plan for the upstream PU. As the objective of the optimizer is to minimize
the sum of all costs there is no incentive for the optimizer to deliver anything if there
are no non-delivery costs. For that reason S&OP offers the key figure IPU NonDelivery Cost Rate (where IPU stands for Inter-Planning Unit) to store intra
company sales or procurement prices, i.e. the company internal prices which define
the prices (per unit of measure - piece or ton) according to which goods are sold /
bought from one upstream PU to / by another downstream PU.
The technical name of the IPU Non-Delivery Cost Rate is
IPUNONDELIVERYCOSTRATE and the key is: product, ship-to location. The key
figure values relate to the delivery time (arrival time) at the destination which is called
ship-to location.
The optimizer will use these IPU Non-Delivery Cost Rates for a location product if
this location product receives its Receipts from a ship-to location outside of the
selected PUs. In detail, the IPU Non-Delivery Costs are computed (per period) by
multiplying the IPU Non-Delivery Cost Rates by the non-delivered quantities, i.e. by
the difference between key figure Net Demand and Receipts at the receiving
location. As Net Demand and Receipts are not depicted we assume for the example
of Figure 17 that Net Demands are equal to the OLD values and Receipts are equal
to the values in key figure Transport Receipts. The IPU Non-Delivery Costs of DC2
then are:
IPU Non-Delivery Costs (P, DC2) =
(21 0) * 41 + (22 - 11) * 42 + (23 - 12) * 43 + (24 - 13) *44
Page 22
How Optimizer computes IPU Non-Delivery Costs

IPU Non-Delivery
Cost Rate (P,NULL,DC1)
41 42 43 44
DLD (P,DC2,DC1)
OLD (P,DC1,DC2)
22 23 24
21 22 23 24
DC1
B
Lead time = 1
Tr. Receipts 0 11 12 13 (P,DC1,DC2)
DC2
Tr. Supply 11 12 13
(P,DC2,DC1)
Figure 17: IPU Non-Delivery Costs at the border between Planning Units
4.2 Inter-Planning Unit Receipts Costs

Wherever a Planning Unit receives semi-finished products from another Planning
Unit (and not from outside the company) there exists, analogously to the IPU NonDelivery Cost Rates, the need to define intra company (procurement) costs.
Therefore, S&OP offers key figure IPU Receipts Cost Rate to model intra company
procurement costs for goods which are supplied by another (upstream) PU.
The technical name of the IPU Receipts Cost Rate is IPURECEIPTCOSTRATE and
the key is: product, location. The key figure values refer to the delivery time at the
destination.
Figure 18 demonstrates (by the four dotted lines between key figures IPU Receipts
Cost Rate and Transport Receipts) how the optimizer calculates the IPU Receipts
costs. To do so, the values of both key figures are multiplied period by period:
IPU Receipts Costs (P, DC1) = 31 * 0 + 32 * 11 + 33 * 12 + 34 * 13
Page 23
IPU Receipts Costs

IPU Receipts
Cost Rate (P,DC1)
IPU Non-Delivery
Cost Rate (P, NULL,DC1)
31 32 33 34
41 42 43 44
DLD (P,DC2,DC1)
OLD (P,DC1,DC2)
A
DC1
22 23 24
21 22 23 24
B
Lead time = 1
DC2
Tr. Supply 11 12 13
(P,DC2,DC1)
Figure 18: Calculation of IPU Receipts Costs
The SCM Operator has no output key figure for IPU Receipts Costs, however, it is
possible for a user to configure this calculation as part of a calculated key figure
which then could be displayed on the S&OP user interface.
The overall procurement costs of a Planning Unit can be derived by aggregating the
IPU Receipts Costs and the normal Receipts Costs related to U-rules connected with
location products belonging to that PU.
IPU Non-Delivery Costs and IPU Receipts Costs are taken into account, only when a
user decided to restrict the planning session and hence the SCM Planning Operator
to one or several PUs instead of the entire network and if the corresponding location
products are at the border of the selected PUs.
4.3 Transportation Costs between Planning Units

Transportation costs are to be incurred at shipping location but for the period in which
a transport arrives at its destination, i.e. at delivery / arrival time. In order to achieve
this S&OP on HANA offers key figure Transport Receipts Ship-To which has the key
structure (product, location, ship-to location) as depicted in Figure 19 in the lower
right area. This output key figure contains the same values as key figure Transport
Receipts, the only difference is the key structure which is for Transport Receipts
Page 24
(product, location, ship-from location). This means this key figure is based on delivery
times at the ship-to location. To be related to the delivery date means that the
transportation costs are computed for the period in which transports arrive at their
destination.
The technical name of the output key figure Transport Receipts Ship-To is
TRANSPORTSHIPTO and the key is: product, location, ship-to location.
Calculation of Transport Costs

IPU Receipts
Cost Rate (P,DC1)
IPU Non-Delivery
31 32 33 34
41 42 43 44
DLD (P,DC2,DC1)
OLD (P,DC1,DC2)
22 23 24
21 22 23 24
DC1
B
Lead time = 1
DC2
Tr. Supply 11 12 13
Transport Receipts Ship-To
(P,DC2,DC1)
0 11 12 13 (P,DC2,DC1)
(P,DC2,DC1)
Transport Cost Rate
1
Figure 19: Calculation of Transportation Costs

Key figure Transport Receipts Ship-To allows computing transportation costs by
simply multiplying its values by the values of key figure Transport Cost Rate - period
by period as indicated by the dotted lines in Figure 19. This means:
Transportation Costs (P, DC2, DC1) = 0 * 1 + 11 * 2 + 12 * 3 + 13 * 4
This simple calculation is possible because both key figures do have the same key
structure. As the SCM Planning Operator does not offer an output key figure for
transportation costs a user would have to configure a calculated key figure according
to this simple calculation in order to display transportation costs per lane. An
aggregation over all outgoing lanes will give the overall transportation costs of a
location product. The optimizer calculates the transportation costs based on this logic
while computing a cost-optimal supply plan.
In Figure 19 the transportation costs are computed for DC2 (= location) related to the
delivery time of the transports at their destination (Ship-to location) - which is DC1.
This can be seen as the quantities stored in key figure Transportation Receipts ShipPage 25
to are stored in the same periods as in Transport Receipts which are related to the
delivery time. Fixed transport costs are not considered in Figure 19, but one would
have to follow the same pattern as for the variable transportation costs.
While computing a supply plan for a Planning Unit or a selection of PUs the optimizer
takes into account the IPU Non-Delivery Costs, the IPU Receipts Costs and all other
costs, like the (normal) transportation costs (in downstream direction, i.e. for all
transports starting in the selected PUs), production costs etc.
4.4 Revenue of Planning Units

The revenue of a PU is equivalent to the Non-Delivery Costs. However, as the SCM
Planning Operator does not offer an output key figure for revenue or Non-Delivery
Costs a user has to configure a calculated key figure. The revenue is needed to
derive for instance, the margin of a PU which can be computed out of revenue and
the (configured) key figures transportation costs and IPU Receipts Costs.
Figure 20 illustrates how a key figure would have to be configured to compute the
revenue of a PU along an Outer Border Arc starting at a location (DC2) and
connected with its ship-to location (DC1).
Calculating Revenue
IPU Non-Delivery
41 42 43 44
DLD (P,DC2,DC1)
OLD (P,DC1,DC2)
22 23 24
21 22 23 24
DC1
B
Lead time = 1
DC2
Tr. Supply 11 12 13
(P,DC2,DC1)
Transport Receipts Ship-To 0 11 12 13 (P,DC2,DC1)
Figure 20: Calculation Revenue

Page 26
As indicated by the dotted lines the revenue for this lane can be calculated by simply
multiplying the values in key figure Non-Delivery Cost Rate, period by period, by key
figure Transport Receipts Ship-to, which is:
Revenue (P,DC1) = 0 * 11 + 11 * 42 + 12 * 43 + 13 * 44
5. Networks of Planning Units

5.1 Introduction
In all previous sections of this document we have limited our considerations to just
two PUs as such simple examples are both good enough to explain the basics of the
functionality related with PU and easy to understand. If, however, a supply chain
model contains several PUs which span a network of PUs additional questions have
to be answered. We also have to consider cases in which Consensus Demands are
sourced to multiple PUs.
5.2 Consensus Demands sourced to multiple Planning Units

Consensus Demands can be sourced via Customer Sourcing-rules (C-rules) to one
or several location products and these location products can belong to one or several
PUs. If for a Consensus Demand there exists only one C-rule (to exactly one location
product) then the sourcing process is quite simple: the entire demand will be
propagated to this location product.
Figure 21 illustrates a more complex model in which Consensus Demands (in five
periods) are sourced according to the given quotas to four different location products
(DC1, DC2, DC3 and DC4) belonging to two PUs (A and B). If the selection of the
planning session contains the entire model, i.e. both PUs, the Consensus Demands
of 100 units (in each period) are sourced to 50% to DC1, 10% to DC2, 20% to DC3
and 20% to DC4. The Outbound Customer Demands (OCD) are set accordingly.
Usually, if no constraints limit the supply (as assumed for Figure 21) the S&OP
Heuristic computes Customer Receipts (CR) matching exactly the OCDs as shown
in Figure 21.
Page 27
Supply Plan Generated by Heuristic for Entire Model

Customer A / Product P
50%
10%
OCD:
50 | 50 | 50 | 50 | 50
CR:
50 | 50 | 50 | 50 | 50
OCD:
10 | 10 | 10 | 10 | 10
CR:
10 | 10 | 10 | 10 | 10
OCD:
20 | 20 | 20 | 20 | 20
CR:
20 | 20 | 20 | 20 | 20
OCD:
20 | 20 | 20 | 20 | 20
CR:
20 | 20 | 20 | 20 | 20
DC1
DC2
CD: 100 | 100 | 100 | 100 | 100

TC: 100 | 100 | 100 | 100 | 100
20%
20%
CD: Consensus Demand

TC: Total Cust. Receipts
OCD: Outbound Customer Demand

CR: Customer Supply
DC3
DC4
AOCD: Adjusted Outb. Cust. Demand

ACR: Adjusted Customer Receipts
Figure 21: Consensus Demand sourced to four location products in 2 PUs

If, however, the selection contains PU A only the SCM Planning Operator will use
only that portion of the Consensus Demands which should be satisfied out of PU A.
This portion is derived by multiplying the quotas of the C-rules connecting the
Consensus Demand with one of the location products of PU A and the amount of the
Consensus Demand. In the example of Figure 21 this means that 100 * 50% + 100 *
10% = 60 units are sourced to PU A in total if the user has selected only PU A as
shown by Figure 22 for which it is assumed that no supply plan was yet computed for
PU B (as no values are displayed for the two lanes to DC3 and DC4.)
If the user performs the S&OP Heuristic it propagates 50 units along the C-rule to
DC1 and 10 units along the C-rule to DC2 and the S&OP Heuristic tries to satisfy the
Outbound Customer Demands at each lane as shown by Figure 22. If, however,
the user runs the S&OP Optimizer the objective is to satisfy this demand of 60 units
disregarding the quotas, i.e. the optimizer tries to supply 60 units in total from any
location in PU A, independently of the given quotas. We therefore call the relevant
portion of the Consensus Demand to be supplied by a selected PU the Planning
Unit Dependent Demand (PU DD) which is just a term we introduce for the
explanations in this document. PU DD is not a key figure of S&OP on HANA.
For the example of Figure 22 this means that the S&OP Optimizer will try to satisfy a
PU DD of 60 units and it depends on the costs (production, procurement and
transportation costs) and available capacities and other constraints how much is
delivered from DC1 and how much from DC2. The objective is to find a cost optimal
supply plan. One possible result of the S&OP Optimizer is depicted by Figure 23.
Page 28
Supply Plan Generated by Heuristic for PU A

50%
10%
OCD:
50 | 50 | 50 | 50 | 50
CR:
50 | 50 | 50 | 50 | 50
OCD:
10 | 10 | 10 | 10 | 10
CR:
10 | 10 | 10 | 10 | 10
DC1
DC2
CD: 100 | 100 | 100 | 100 | 100

TC: 60 | 60 | 60 | 60 | 60
20%
20%

OCD:
CR:
OCD:
CR:

CR: Customer Supply
DC3
DC4

Figure 22: Selection contains only Planning Unit A: Result of the Heuristic
Supply Plan Generated by Optimizer for PU A

50%
10%
OCD:
60 | 40 | 60 | 50 | 55
CR:
60 | 40 | 60 | 50 | 55
OCD:
CR:
0 | 20 |
0 | 20 |
0 | 10 |
0 | 10 |
DC1
0
0
DC2
CD: 100 | 100 | 100 | 100 | 100

TC: 60 | 60 | 60 | 60 | 55
20%
20%

OCD:
CR:
OCD:
CR:

CR: Customer Supply
DC3
DC4

Figure 23: Possible result of the S&OP Optimizer if only PU A is selected

Page 29
As shown in Figure 23, in period 1 the optimizer decided to deliver the entire PU DD
of PU A from DC1 and nothing from DC2. In period 2, in contrast, it decided to deliver
only 40 units from DC1 and the remaining portion (20) from DC2 for any reason
which cannot be concluded out of this Figure. In period 5 the optimizer was not able
to satisfy the entire demand; it just could provide 55 units from DC1.
With key figures Adjusted Customer Dependent Demand, Adjusted Outbound

Customer Demand and Adjusted Customer Receipts / Supply a user of S&OP on
HANA can impact the logic computing the portion of the Consensus Demands which
is sourced along a lane (for the Heuristic) or to the selected PUs (in case the
Optimizer is chosen), i.e. the PU DD. Input key figure Adjusted Dependent
Customer Demand (ADCD) affects the Dependent Customer Demand, however it
depends on the planning algorithm (Heuristic or Optimizer) how this is done in detail.
For the S&OP Heuristic the ADCD fixes the Dependent Customer Demand for
exactly that lane (C-rule) the user has defined the ADCD. The ADCD over-rules the
quantity which is derived out of Consensus Demand multiplied by the quota of the
corresponding C-rule. For the S&OP Optimizer it impacts the entire PU DD. We will
explain this along the figures below.
The Adjusted Outbound Customer Demand is the upstream key figure
corresponding to the downstream key figure ADCD. So both key figures store the
same values, but lead-time shifted, and hence both have the same effect from a
logical perspective. In the sequel we limit the explanations to the Adjusted Outbound
Customer Demand as we usually use the upstream key figures for explanations.
The technical name of Adjusted Outbound Customer Demand is
ADJDEPENDENTCUSTOMERDEMAND and its key is: Customer, Product, Location.
The technical name of Adjusted Dependent Customer Demand is
ADJDEPENDENTCUSTOMERDEMANDDS and its key is: Customer, Product,
Location.
A user can also impact the lane-specific Dependent Customer Demands and the PU
DD via key figure Adjusted Customer Receipts (ACR) and Adjusted Customer
Supply (ACS). As ACR is the upstream key figure corresponding to the downstream
key figure ACS we again explain the functionality only for the upstream key figure
ACR.
The technical name of Adjusted Customer Receipts is
ADJUSTEDCONSTRAINEDDEMAND and the key contains these attributes:
Customer, Product, Location.
The technical name of Adjusted Customer Supply is
ADJUSTEDCONSTRAINEDDEMANDDS with the key: Customer, Product, Location.
Page 30
A user might use both key figures, the Adjusted Outbound Customer Demand and
the Adjusted Customer Receipts simultaneously. We therefore explain in the sequel
the effect of both key figures when used exclusively and in their combination. We first
look at the S&OP Heuristic and then at the S&OP Optimizer. To do so, we refer to
the example of Figure 21 as a starting point. We assume that a user entered values
for the Adjusted Outbound Customer Demand (AOCD) in periods 2 and 5 (as shown
by Figure 24) and values for Adjusted Customer Receipts (ACR) in periods 3, 4 and
5 at the lane to DC1.
Supply Plan Generated by Heuristic for PU A+B

50%
10%
AOCD:
OCD:
| 40 |
|
| 60
50 | 40 | 40 | 70 | 45
ACR:
CR:
|
| 40 | 70 | 45
50 | 40 | 40 | 70 | 45
OCD:
10 | 10 | 10 | 10 | 10
CR:
10 | 10 | 10 | 10 | 10
OCD:
20 | 20 | 20 | 20 | 20
CR:
20 | 20 | 20 | 20 | 20
OCD:
20 | 20 | 20 | 20 | 20
CR:
20 | 20 | 20 | 20 | 20
DC1
DC2
CD: 100 | 100 | 100 | 100 | 100

TC: 100 | 090 | 090 | 120 | 095
20%
20%


CR: Customer Supply
DC3
DC4

Figure 24: Result of the S&OP Heuristic for PU A and B
It is now assumed that a user selected both PUs (A and B) and that he runs the
S&OP Heuristic. Figure 24 shows the resulting supply plan.
In period 1 there is no difference compared to the initial plan given by Figure 21
which is not surprising as no entries for AOCD or ACR exist in period 1, i.e. there is
no change compared to Figure 21 at all.
In period 2 the AOCD of 40 units reduces (over-writes) the Dependent Customer
Demand of 50 units which were derived (in Figure 21) via the quota of 50%. As a
consequence the S&OP Heuristic computes a reduced Supply of 40 units; it does not
make sense to ship more than the demand requests. This means, the AOCD impacts
the OCD which is propagated along the lane / C-rule it is defined for. In this example
it lowers the OCD from 50 to 40 units. As the PU DD is the sum of the OCDs of all
Page 31
incoming lanes to that PU the AOCD also has an impact on the PU DD in the
example here it lowers the PU DD for PU A to 50 units (without AOCD it was 60).
This is the reason why in period 2 only 90 (and not 100) units are supplied to the
customer.
In period 3 there is an entry for ACR of 40 units. This fixes the Customer Receipts to
40 units. As a consequence to a fixed supply element the SCM Planning Operator
adjusts (fixes) the corresponding demand element which is the Outbound Customer
Demand at that lane in that period. The OCD value is therefore set to 40 as well.
In period 4 the user again has entered a value into key figure ACR. In contrast to
period 3, this value (70) is higher than the previously computed OCD - which was
derived via the quota multiplied by the Consensus Demand, i.e. 50% * 100 = 50. An
ACR higher than the previously computed OCD is especially interesting when the
optimizer is chosen (which we will see below).
In period 5, the user has entered values in both, the AOCD and the ACR. The 45
units in key figure ACR has the strongest impact, it fixes the Customer Receipts and
as a consequence the corresponding OCD. The AOCD of 60 has no effect on the
heuristic. However, this will be different for the S&OP Optimizer, as we will see in the
sequel.
It is important to realize that the Total Customer Receipts deviate from the
Consensus Demands (of 100 in each period) in periods 2 to 5 which is a
consequence of the defined AOCD and ACR values.
The key figures AOCD and ACR have a slightly different behavior when the S&OP
Optimizer is used instead the S&OP Heuristic. This is explained along Figures 25
and 26.
If the user runs the S&OP Optimizer for the example given by Figure 24 and he
selects PU A only the result might look like as in Figure 25. The result might look like
the plan shown in Figure 25 but it could also be different dependent on how costs
and constraints are set, which is not visible. In addition, it is assumed for Figure 25
that the key figures OCD and CR at lanes to DC3 and DC4 have not been changed
since the last run displayed by Figure 24 so that they still store the same values as in
Figure 24 - which is intended as PU B was not selected for this run. In other words,
values in key figures at the lanes to DC3 and DC4 are not deleted just because they
do not belong to the new selection of PUs.
In period 1 the PU DD is 60 units which are satisfied completely from DC1 (for
instance because this is the solution with the lowest costs in period 1).
For period 2 the user has entered an AOCD of 40 units which limits the OCD along
this lane. As a consequence the sourced Consensus Demand along the lane to DC1
is 40 only, whereas the sourced Consensus Demand to DC2 is still 100 * 10% = 10,
Page 32
so that the PU DD in total is 40 + 10 = 50 units. The optimizer decided to satisfy the

entire PU DD from DC1 (and nothing from DC2) as it did set key figure CR to 50 in
period 2. As explained at the end of section 3.1 in the documentation Operators Key
Figures, the optimizer always copies the computed values returned in output key
figure Customer Receipts into key figure Outbound Customer Demand (and
analogously the corresponding downstream key figure Customer Supply into
Dependent Customer Demand DCD). For that reason key figure OCD also contains a
value of 50 in period 2.
Supply Plan Generated by Optimizer for PU A

50%
10%
AOCD:
OCD:
| 40 |
|
| 60
60 | 50 | 40 | 70 | 45
ACR:
CR:
|
| 40 | 70 | 45
60 | 50 | 40 | 70 | 45
OCD:
CR:
0 | 0 | 20 |
0 | 0 | 20 |
DC1
0 | 25
0 | 25
DC2
CD: 100 | 100 | 100 | 100 | 100

TC: 100 | 090 | 100 | 110 | 110
20%
20%

OCD:
20 | 20 | 20 | 20 | 20
CR:
20 | 20 | 20 | 20 | 20
OCD:
20 | 20 | 20 | 20 | 20
CR:
20 | 20 | 20 | 20 | 20

CR: Customer Supply
DC3
DC4

Figure 25: Possible result of the S&OP Optimizer with PU A selected

For period 3 the user entered an ACR of 40 units which fixes the supply (CR) to 40
for this lane (and as consequence as explained above this fixes the OCD to 40 as
well). However, as the PU DD is still 60 units (as there is no value for AOCD) the
optimizer delivers the remaining 20 units from DC2 if there are no constraints
preventing this, as assumed for the solution of Figure 25. In contrast to the heuristic
the optimizer ignores the quotas and it balances the supply between all lanes going
to the selected PUs (here PU A only). If one location product is not able to fulfill the
entire PU DD and if the costs are accordingly, the optimizer will try to compensate
shortages at one lane by additional deliveries via alternative lanes.
In period 4 there is an entry in key figure ACR of 70 units fixing the supply in this
period to that value. As there is no entry for AOCD the PU DD still is 60 units which
means that the actual (fixed) supply now over-fulfills the PU DD (by 10 units). As the
Page 33
user has not selected PU B there is no possibility for the optimizer to balance this
out, for instance by lowering supply coming from locations in PU B. For that reason
the Total Customer Receipts is 110 in period 4, and hence 10 units above the
Consensus Demand.
In period 5 we have an AOCD of 60 and an ACR of 45. The AOCD increases the PU
DD from 60 to 70 units: 60 units along the lane to DC1 (due to the AOCD) plus 100 *
10% = 10 units along the lane to DC2. This means, the optimizer should satisfy a
demand of 70 units in total from PU A. As the supply from DC1 is limited to 45 it
compensates this by increasing the supply from DC2 to 25 so that in total the
supply from PU A is 45 + 25 = 70 units. As a consequence of the increased PU DD
and as the supply from PU B is still 40 the overall receipts (Total Customer Receipts)
are 110 and hence are over-delivering the Consensus Demand of only 10 units. But,
this is exactly what should be possible via key figure AOCD: a user should be able to
impact the delivered quantities without the need to change Consensus Demands nor
quotas.
In the context of period 5 in Figure 25 it becomes obvious that the ACR has an
impact (if optimizer is chosen) only in cases where it (better to say the sum of all
ACR at all lanes) is greater than the PU DD. In such cases the PU DD is increased to
the sum of all ACR of all lanes. In this example the sum of all ACR is 45 and the PU
DD is 60 + 10 = 70 and hence, the ACR does not increase the quantity which is
delivered from PU A in total, it is still 45 + 25 = 70 which is the PU DD.
The next interesting case is shown by Figure 26 which is the same example as in
Figure 25 with the only difference that the user now selected both PUs (A and B)
and not just PU A.
Figure 26 shows one possible result of the optimizer meaning that depending on the
defined costs and constraints (such as available capacity supply) it could be different.
It is important to be aware that the PU DD is computed with respect to all selected
PUs. In Figure 25 the PU DD was computed only for PU A, in Figure 26 it is
computed for both PUs.
In period 1 the PU DD for PU A, denoted as PU DD(A) is 60 and the PU DD(B) for
PU B is 40 so that the optimizer is fed with an overall PU DD(A+B) of 100 units. (In
Figure 25 this was just 60 units as only PU A was selected). The optimizer decided to
deliver the entire quantity (100 units) from DC1.
For period 2 the user defined an AOCD of 40 units which impacts the PU DD(A): the
Dependent Customer Demand at this lane is limited to 40 (instead to 50 without the
AOCD) so that the overall PU DD(A+B) is computed by:
PU DD(A+B) = 40 + 100 * 10% + 100 * 20% + 100 * 20% = 90 units.
Page 34
Supply Plan Generated by Optimizer for PU A+B

50%
AOCD:
| 40 |
|
| 60
OCD: 100 | 90 | 40 | 70 | 45
ACR:
|
| 40 | 70 | 45
CR:
100 | 90 | 40 | 70 | 45
10%
OCD:
0 | 0 | 60 | 30 |
CR:
0 | 0 | 60 | 30 |
OCD:
0| 0|
0|
0 | 65
CR:
0| 0|
0|
0 | 65
OCD:
0| 0|
0|
0| 0
CR:
0| 0|
0|
0| 0
DC1
DC2
CD: 100 | 100 | 100 | 100 | 100

TC: 100 | 090 | 100 | 100 | 110
20%
20%


CR: Customer Supply
DC3
DC4

Figure 26: Possible result of the S&OP Optimizer with PU A+B selected
Here again, the optimizer decided to supply the entire demand from DC1. Obviously
it is cost-optimal to ship the entire quantity from DC1.
In period 3 there is an Adjusted Customer Receipts (ACR) of 40 units which fixes the
supply at this lane to 40. As there is no AOCD defined, the PU DD(A+B) is again 100.
The optimizer tries to fulfill the entire PU DD(A+B) and for that reason it had to ship
the remaining quantity (60 units) from another location than DC1.
In period 4 the user entered an ACR (70 units) which is higher than the dependent
demand (50 units) derived out of the quota for the lane to DC1. This ACR fixes the
supply to 70 at this lane. The optimizer usually does not over-deliver Consensus
Demands, if avoidable, and hence it compensates this higher Customer Receipts
from DC1 by a lower supply from DC2 of 30 units only.
Due to the AOCD of 60 units in period 5 the PU DD (A+B) is 110 which is
computed as for period 2 (see above), but now with these 60 units instead of the 40
units in period 2. This means, in total the optimizer tries to satisfy a demand of 110.
As the supply from DC1 is fixed to 45 units the optimizer decided to deliver the
remaining 65 units from somewhere else. In this solution the optimizer decided to
ship 65 units from DC3, for instance as DC2 could not provide the relevant capacity
or for any other reason.
Page 35
5.3 Planning Units with multiple outgoing sourcing rules

Figure 27 illustrates a network of Consensus Demands and PUs. (The figure is
related to one product and shows for this product a Consensus Demand of customer
C1 and location products in three Planning Units A, B and C. The Consensus
Demand can be sourced via three Customer Sourcing Rules (C-rules) in upstream
direction to PU B and PU C. PU A contains two locations (DC1 and DC2). The Net
Demand of DC1 can be propagated to PU B (DC3 and DC4), to PU C (DC5) and
along sourcing rules within the PU A itself. Within the PU A the Net Demand of DC1
can be sourced via a T-rule to DC2, to a production process (P-rule) consuming
component X1 at the same location (DC1) and remaining quantities can be sourced
to a U-rule as depicted in Figure 27.
Network of Planning Units

Planning Unit B
50%
C1
DC3
B
DC4
Planning Unit A
A
DC1
Planning Unit C
DC5
5%
T-rule
A
DC2
DC1/ A
X1
Figure 27: Network of Consensus Demands and PUs
Section 5.2 explained everything around a Consensus Demand being sourced to

multiple PUs. Section 5.3 now explains how the SCM Planning Operator handles
cases in which a user selects a PU with outgoing Outer Border Arcs (in upstream
direction). Section 5.4 then considers examples with ingoing Outer Border Arcs.
Figure 28 zooms into the model given by Figure 27. (To simplify the example the Pand U-rule connected with DC1 in PU A and the Consensus Demand are removed.)
Page 36
It is assumed that a user selected PU A only and performed the S&OP Heuristic for
this selection. It is further assumed that DC1 received a Dependent Demand (D) of
100 and 200 units in periods 1 and 2 from previous locations (in downstream
direction). The heuristic computed a Net Demand (N) of 100 and 200 units when PU
A was planned before. This Net Demand is propagated along all sourcing rules
according to their quotas so that the result shown by Figure 28 is generated.
50% of the Net Demand at DC1 is propagated along a T-rule to DC2 and the
heuristic then computes Net Demand and everything else for DC2. As a result the
Transport Receipts (TR) from DC2 to DC1 is computed as well. In contrast to this
inner arc the heuristic does not compute Transport Receipts at the Outer Border Arcs
(from DC3, DC4, and DC5) as this key figure at the Outer Border Arcs - is an input
for PU A and will be populated or changed only when PU B and C are planned. This
implies that if key figure TR stored values from a previous run then these values still
would be visible and taken as input for PU A, but not changed by a planning run of
PU A. In Figure 28 it is assumed that PU B and C have not yet been planned at all
because key figure TR does not store any value yet and hence TR remains empty
after the planning run for PU A. And as consequence, the supply at these lanes for
PU A is zero. As a consequence the Receipts at DC1 contain only the Transports
coming from DC2. As the heuristic (No Shortages) always supplies the entire
Dependent Demand the resulting Projected Stock (I) is negative (assuming Stock-on
hand is zero).
Propagating of Net Demand by S&OP Heuristic

Planning Unit B
Planning Unit A
DC1
D: 100 | 200
I: -50 | -100
N: 100 | 200
R: 50 | 100
S: 100 | 200
DC3
B
DC4
50%
OLD: 50 | 100
TR:
50 | 100
DC2
D:
I:
N:
R:
S:
D: Dependent Demand
I: Projected Stock
50 |
0|
50 |
50 |
50 |
100 A
0
100
100
100
N: Net Demand
R: Tot. Receipts
Planning Unit C
C
DC5
S: Supply
Page 37
OLD: Outbound Location Demand

TR: Transport Receipts
Figure 28: Propagation of Net Demand by S&OP Heuristic
If parameter Compute Expected Supply (introduced with Figure 11) was set to
Yes the plan of Figure 28 would look like slightly differently: the S&OP Heuristic
would assume to receive the expected supply, i.e. the Receipts at DC1 would be
100 and 200 in periods 1 and 2 as this is needed to satisfy the demand and, as a
consequence, the Projected Stock would be zero in both periods. Key figure TR at
the Outer Border Arcs still would remain unchanged, i.e. would still contain no values,
as TR still is an input key figure to PU A. Key figure IPUTR would be updated by the
expected transport quantities, i.e. 10 units from DC3, 20 from DC4 and 20 from DC5
(in period 1).
If a user ran the S&OP Optimizer the example of Figure 28 could lead to a different
result as well. If parameter Compute Expected Supply was set to No then the
available supply from PU B and C is zero so that the optimizer would try to satisfy the
entire demand (PU DD) from DC2. If parameter Compute Expected Supply was set
to Yes then the optimizer might decide to receive the entire quantity from DC2 and
nothing from PU B and C or it might decide to receive the entire quantity from PU B
and / or C or any mixture of both depending on whether constraints limit the supply
from DC2 and depending on the IPU Receipts Cost Rate in comparison to the costs
for receiving the goods from DC2 (which include transportation costs from DC2,
inventory holding costs at DC2 and procurement or production costs at DC2). As
mentioned around Figure 18 the IPU Receipt Cost Rate has the key (product,
location). For that reason, DC1 pays the same procurement price independent
whether goods are received from DC3, DC4 or DC5. The optimizer therefore
evaluates PU-internal costs (from DC2) against PU-external procurement costs for
receiving goods from an upstream PU, i.e. in this example here PU B or C.
Figure 29 considers the same example as Figure 28, but the supply plan now is
computed by the S&OP Optimizer. Again PU A is selected, parameter Compute
Expected Supply is set to No and it is assumed that DC2 is not able to deliver
anything in period 1 (for instance due to a shutdown). Hence, the supply from DC2 is
zero. In contrast to Figure 28, now it is assumed that PU C was planned in the
meantime and that the responsible planner of PU C decided to ship 10 units from
DC5 to DC1 in both periods. As parameter Compute Expected Supply is set to No
the available supply from PU B is still zero (based on the fact that key figure TR is
still initial at the lanes from DC3 and DC4). As a consequence DC1 receives only the
10 units coming from DC5. As explained in the documentation Operators Key
Figures, section 4.4 the optimizer always copies key figure Receipts into key figure
Net Demand and Supply into Dependent Demand (as the optimizer does not
compute any demand key figures) which is the reason why these key figures are
equal to 10 as well. It is important to know that the SCM Operator updates output key
figure OLD (with a value zero or 10 in this example).
Page 38
For period 2 it is assumed that DC2 is able to supply 80 units. From PU C (DC5) the
supply is again 10 so that altogether the Receipts at DC1 are 90 units. (Note: From
Figure 28, however, we know that the Dependent Demand was 200 units.
Unfortunately this information gets lost when calling the optimizer which is
unavoidable as the optimizer does not compute demand key figures explicitly.)
(Possible) Result of the S&OP Optimizer

Planning Unit B
Planning Unit A
DC1
D:
I:
N:
R:
S:
10 |
10 |
10 |
10 |
10 |
90
0
90
90
90
DC3
B
DC4
50%
OLD:
TR:
0 | 80
0 | 80
DC2
D:
I:
N:
R:
S:
D: Dependent Demand
I: Projected Stock
0 | 80 A
0|
0
0 | 80
0 | 80
0 | 80
N: Net Demand
R: Tot. Receipts
Planning Unit C
C
DC5
S: Supply

Figure 29: Result when applying the optimizer
In Figure 30 we consider the same example as in Figure 29. The difference is that
the parameter Compute Expected Supply now is set to Yes meaning that the SCM
Operator can assume to get exactly the supply along the Outer Border Arcs which is
needed to satisfy the demand at DC1. As in period 1 DC2 still is not able to deliver
anything the entire Net Demand at DC1 is received from DC3, DC4 and DC5. The
received quantity is split over these three lanes according to their quotas which are
normalized to 100% for this computation. This means that 1/5 (= 20 units) of the Net
Demand is received from DC3, 2/5 (= 40 units) is transported from DC4 and DC5
each. It is important to see that key figure TR at these Outer Border Arcs is not taken
as input (this is the reason why the 10 units planned by PU C are ignored) and it is
not updated by the planning run (which is the reason why TR is still initial at the two
lanes to PU B and still 10 at the lane to PU C).
For period 2 it is again (as in Figure 29) assumed that DC2 is able to supply only 80
units so that the remaining 120 units are requested from PU B and C. Again these
120 units are distributed over the three Outer Border Arcs based on the normalized
Page 39
quotas so that finally 24 units are transported from DC3, 48 from DC4 and DC 5
each.
S&OP Optimizer with Compute Expected Supply = Yes

Compute Expected Supply
= YES
Planning Unit A
DC1
D: 100 |
I:
0 |
N: 100 |
R: 100 |
S: 100 |
200
0
200
200
200
Planning Unit B
B
DC3
B
DC4
50%
OLD: 0 | 80
TR:
0 | 80
DC2
D:
I:
N:
R:
S:
D: Dependent Demand
I: Projected Stock
0|
0|
0|
0|
0|
80 A
0
80
80
80
N: Net Demand
R: Tot. Receipts
Planning Unit C
C
DC5
S: Supply

Figure 30: Result of optimizer with Compute Expected Supply = Yes
5.4 Planning Units with multiple incoming sourcing rules

Section 5.3 described the logic around PUs along outgoing Outer Border Arcs to
multiple other PUs in upstream direction. This section explains the logic for supply
chain models containing PUs with multiple incoming Outer Border Arcs - as depicted
by Figure 31. In this figure we see four PUs (A, B, C and D). PU A and PU B were
already planned and Figure 31 just depicts the Net Demands which were computed
for DC1 and DC2 in that precedent planning step. (Figure 31 does not explain how
these Net Demands have been derived as this is not important in this context here.)
As part of this precedent planning step the Net Demands were propagated
independent whether heuristic or optimizer was chosen - based on the quotas along
the outgoing T-rules as Outbound Location Demands (OLD) to the locations in PU C
and D as described in section 5.2. From the perspective of PU C and D these are
incoming sourcing rules.
The situation given by Figure 31 is the starting point for the sub-sequent
explanations.
Page 40
Multiple Incoming Sourcing Rules: Initial Plan

Planning Unit C
Planning Unit A
DC1
D:
I:
N: 100 | 100 | 100 | 100 | 100
R:
S:
50%
IPUDLD: |
|
|
|
OLD:
50 | 50 | 50 | 50 | 50
ATR:
TR:
|
|
|
|
|
|
|
|
DC3
D:
I:
N:
R:
S:
DC4
D:
I:
N:
R:
S:
Planning Unit B
DC2
D:
I:
N:
R:
S:
1|
2|
3|
4|
D: Dependent Demand N: Net Demand

I: Projected Stock
R: Tot. Receipts
DC5
Planning Unit D
D:
I:
N:
R:
ATR:
Adj. Transport Receipts
IPUDLD: IPU Depend. Loc. Dem.

Figure 31: Initial Plan of Example with Multiple Incoming Sourcing Rules
We continue this example with Figure 32. It is assumed that the user selected PU C
to perform the S&OP Heuristic. Prior to the run of the heuristic he entered values in
key figure IPUDLD (in periods 2 and 5) and he entered values in key figure Adjusted
Transport Receipts ATR (in periods 3, 4 and 5) at the lane between DC1 and DC3.
(We have chosen the same values as for the example in Figure 24 as the logic of key
figures IPUDLD and ATR is analogous to the key figures AOCD and ACR. IPUDLD
and ATR impact the SCM Operators behavior at T-rules (between locations)
whereas AOCD and ACR impact C-rules (between customers and locations) in a
very similar way.
Based on these assumptions and input data the S&OP Heuristic computes the
supply plan shown by Figure 32. As PU C consists out of DC3 and DC4 the SCM
Planning Operator reads key figures IPUDLD and OLD as input and it then calculates
all key figures related with these two location products, among them the node related
key figures like Dependent Demand, Projected Stock, Net Demand, Receipts and
Supply and the arc related key figures as Transport Receipts. As DC5 belongs to PU
D which is not selected nothing is computed for that location product.
Page 41
Multiple Incoming Sourcing Rules: Heuristic

Planning Unit C
Planning Unit A
DC1
D:
I:
N: 100 | 100 | 100 | 100 | 100
R:
S:
50%
IPUDLD: | 40 |
|
| 60
OLD:
50 | 50 | 50 | 50 | 50
ATR:
TR:
|
| 40 | 70 | 45
50 | 40 | 40 | 70 | 45
DC3
D:
I:
N:
R:
S:
50 |
0|
50 |
50 |
50 |
40 |
0|
40 |
40 |
40 |
40 |
0 |
40 |
40 |
40 |
70 |
0|
70 |
70 |
70 |
12 |
0|
12 |
12 |
12 |
13 |
0 |
13 |
13 |
13 |
14 |
0|
14 |
14 |
14 |
45
0
45
45
45
DC4
D:
I:
N:
R:
S:
Planning Unit B
DC2
D:
I:
N:
R:
S:
1|
2|
3|
4| 5

I: Projected Stock
R: Tot. Receipts
11 |
0|
11 |
11 |
11 |
DC5
15
0
15
15
15
Planning Unit D
D:
I:
N:
R:
ATR:

Figure 32: Supply Plan generated by S&OP Heuristic
As there are no Consensus Demands involved in this example the heuristic starts to
read the incoming demands which are the values in key figure IPUDLD or, if none
exists, values in key figure OLD. For that reason in period 1 the heuristic reads a
Dependent Demand of 50 units for DC3 and 11 units (10 from DC1 and 1 from DC2)
for DC4. The heuristic supplies the entire demand from both locations (50 from DC4
and 11 from DC4) and it updates key figure Transport Receipts (TR) accordingly.
In period 2 the value in key figure IPUDLD (40 units) is taken as incoming demand
for DC3 and hence the provided Supply is 40 as well. When the heuristic is chosen
the impact of IPUDLD and ATR is limited mainly to the Outer Border Arcs for which
these entries are defined. This is analogous to the functionality of key figures AOCD
and CR as explained in section 5.2.
It is remarkable that key figure OLD belongs to PU A and not to PU B. For that
reason OLD is not updated when PU C is planned and that is why the values in OLD
at the lane between DC1 and DC3 do not match with the values in key figure TR and
ATR at that Outer Border Arc (in periods 2, 3, 4 and 5). These OLD values will be
updated during the next planning run for PU A.
In period 3 the user limited the Transport Receipts to 40 units (by entering a value of
40 units into key figure ATR). As a consequence the SCM Operator over-rules the
Page 42
OLD while computing the Dependent Demand for PU C so that the Dependent
Demand is 40 (and not 50).
In period 4 the user set an Adjusted Transport Receipts of 70 units which is higher
than the sourced Net Demand of only 50 units at this lane. (This sourced Net
Demand is derived by the Net Demand at DC1 multiplied by the quota of that lane,
i.e. for the example here: 100 * 50% = 50 units). The heuristic therefore plans to
deliver 70 units. It is important to see that the S&OP Heuristic does not reduce the
supply via the second lane to DC1; from DC4 to DC1 it still transports the sourced
Net Demand of 10 units. This means the S&OP Heuristic does not balance the
quantities between the various lanes; as mentioned above the impact of key figure
ATR is limited to the Outer Border Arc for which it is defined.
In period 5 the user sets an IPUDLD value of 60 and an Adjusted Transport Receipts
of 45. This example shows that fixing the supply to 45 units dominates the IPUDLD
as the heuristic transports 45 units and not the requested 60. The S&OP Heuristic
does not increase the transport quantity at another lane (from DC4 to DC1 in this
example) to compensate the quantity below the requested demand. For that reason
the transport quantity from DC4 to DC1 satisfies only the sourced Net Demand at this
lane and not the missing 25 units from the lane above. Such a balancing is
provided by the S&OP Optimizer only as we will see in the sequel.
Figure 33 shows the result for the example introduced by Figure 31 when the
optimizer was called. Again, as assumed for Figure 32, PU A and PU B have been
planned before.
In period 1 the Net Demand which is sourced from PU A to PU C in total, the
Planning Unit Dependent Demand (PU DD(A->C)), is 60 units. The PU DD(A->C) is
the sum of the sourced Net Demands of all incoming Outer Border Arcs. In the
example of Figure 33 the PU DD(A->C) is: 100 * 50% + 100 * 10% = 60 units. This
PU DD is computed by the SCM Planning Operator right prior to the optimizer run
and it is passed to the optimizer as input.
As mentioned in conjunction with Figure 32, key figure OLD is not updated while PU
C is planned (and PU A and PU B are not selected). This means that the OLD values
at all incoming lanes to PU C do not match with their corresponding ATR and TR
value at this Outer Border Arc as they would do if this were inner arcs.
The PU DD(A->D) sourced from PU A to PU D is 40 units which however is not
considered here, as PU D is not selected for this planning session.
In period 1 the optimizer decided (for instance due to costs) to deliver the entire PU
DD(A->C) from DC3 and nothing from DC4 as shown by Figure 33.
Page 43
Multiple Incoming Sourcing Rules: Optimizer

Planning Unit C
Planning Unit A
DC1
D:
I:
N: 100 | 100 | 100 | 100 | 100
R:
S:
50%
IPUDLD: | 40 |
|
| 60
OLD:
50 | 50 | 50 | 50 | 50
ATR:
TR:
|
| 40 | 70 | 45
60 | 50 | 40 | 70 | 45
DC3
D:
I:
N:
R:
S:
60 |
0|
60 |
60 |
60 |
50 |
0|
50 |
50 |
50 |
40 |
0 |
40 |
40 |
40 |
70 |
0|
70 |
70 |
70 |
45
0
45
45
45
2|
0|
2|
2|
2|
23 |
0 |
23 |
23 |
23 |
4|
0|
4|
4|
4|
30
0
30
30
30
DC4
D:
I:
N:
R:
S:
Planning Unit B
DC2
D:
I:
N:
R:
S:
1|
2|
3|
4| 5

I: Projected Stock
R: Tot. Receipts
1|
0|
1|
1|
1|
DC5
Planning Unit D
D:
I:
N:
R:
ATR:

Figure 33: Multiple Incoming Sourcing Rules: Optimizer

In period 2 the PU DD(A->C) of 60 is reduced to 50 units as the IPUDLD of 40 units
at the lane to DC3 sets the sourced Net Demand at this lane to 40 whereas at the
lane to DC4 the sourced Net Demand still is 10, so the actual PU DD(A->C) is 40 +
10 = 50 units. Here again, the optimizer decided to deliver the entire PU DD of PU C
from DC3.
In period 3 the user fixed the supply from DC3 to 40 as the ATR is set to 40.
However, the PU DD(A->C) is still 60 units. The optimizer tries to compensate the
missing quantity of 20 units and therefore it plans a transport from DC4 of 20 units.
As a consequence, PU A receives the entire requested demand (PU DD(A->C)) of 60
units.
In period 4 the user increased the PU DD(A->C) from 60 to 70 units as the ATR is set
to 70. The only thing the optimizer can do to compensate this over-delivery is to set
the transport at the lane from DC4 to zero which however does not prevent that the
entire shipped quantity is 10 units above the original demand (PU DD(A->C)) of 60
units.
In period 5 the PU DD(A->C) is again 60 units which is actually increased to 70 by
the IPUDLD of 60 units. (The remaining 10 units are sourced via the T-rule to DC4.)
As in this period the supply at this lane is fixed to 45 units the optimizer compensates
the missing quantity via the lane from DC4 as it sets the transport quantity to 25 so
that in total 70 units, i.e. exactly the (increased) PU DD(A->C) is supplied from PU C
to PU A.
Page 44
6. Planning Units and Production Sources

All previous chapters of this documentation were about the usage of Planning Units
in conjunction with transport sources of supply. This chapter explains how PUs can
be used in conjunction with production sources.
In most cases, all output and all input products of a production source belong to the
same PU. The production process then is modelled entirely within that PU. However,
it is also possible to assign input and output products (main output and all coproducts) of one production source arbitrarily to several different PUs. If a planner
selects all involved PUs so that all output and input products are part of the selection,
the entire production source will be handled by heuristic and optimizer in the same
way as if all output and input products would belong to one PU. If, in contrast, the
planner selects only one or a subset of all involved PUs the planning process
becomes much more difficult which is the reason why SAP recommends to avoid
such a model, i.e. to assign all output and input products to the same PU.
6.1 S&OP Heuristic infinite / no shortages

Figure 34 illustrates a production source in which the output product and both
components belong to different PUs. The output product belongs to PU A,
component C1 to PU B and component C2 to PU C. The production source S1 of
Figure 34 is defined for product P1 in plant PL1.
Planning Unit A selected

PU B
PU A
PL1 P1
DCD: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 C1
PL1 P1 S1
D:
I:
N:
S:
R:
P: 10
AP:
PU C
PL1 C2
D:
I:
N:
S:
R:
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
R: Total ReceiptsI:
P: Production
AP: Adj. Production
DCD: Dep. Customer Demand

DPD: Dep. Production Demand
PC:
Production Component
IPUPC: IPU Production
Figure 34: Example with different PUs for output product and components
Page 45
It can be assumed that the supply plan shown by Figure 34 was computed by the
S&OP heuristic. As only PU was selected the heuristic computed demand and supply
key figures only for location product PL1 P1 and the connected arc-related key
figures (which are shown in red). The Dependent Customer Demand of 10 units
caused a Net Demand of 10 in that location product which is propagated as
Dependent Product Demand. However, as both components C1 and C2 belong to
other PUs (B and C) the demand propagation terminated in front of these two
location products. The heuristic simply assumes to get the requested demand of 10
units as supply (indicated by key figure Production Component).
Figure 35 shows the result of the heuristic after it was applied to PU B to plan
component C1 in plant PL1.
Planning Unit B selected

PU B
PU A
PL1 P1
DCD: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 C1
PL1 P1 S1
D:
I:
N:
S:
R:
10
0
10
10
10
P: 10
AP:
PU C
PL1 C2
D:
I:
N:
S:
R:
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
R: Total ReceiptsI:
P: Production
AP: Adj. Production

PC:
Figure 35: Planning Unit B selected to plan component C1
The Dependent Product Demand (DPD) was taken as input for PU B and the
heuristic did fulfill this demand, as the corresponding supply is set to 10 units. This
supply is updated into key figure IPUPC (Inter-Planning Unit Production Component
Usage). This key figure is colored in green to indicate that it belongs to the
responsibility of the planner of PU B.
Page 46
Key
figure
IPUPC
is
an
output key figure. Its technical name

IPUPRODUCTIONCOMPONENTDS and it has the following attributes in its key:
is
Output Product - Location - Product - Source ID

Figure 36 shows the analogous result after PU C was planned by the heuristic.
Planning Unit C selected

PU B
PU A
PL1 P1
DCD: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 C1
PL1 P1 S1
D:
I:
N:
S:
R:
10
0
10
10
10
P: 10
AP:
PU C
PL1 C2
D:
I:
N:
S:
R:
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
R: Total ReceiptsI:
P: Production
AP: Adj. Production
10
0
10
10
10

PC:
Figure 36: Result after planning PU C
Figure 37 shows the result of a new run of the heuristic after the demand of product
P1 increased from 10 to 12 units. The heuristic propagated this higher demand
through the production source, but it did not change the plan for both components, as
they belong to different PUs.
By comparing the values in key figures IPUPC and PC the planner can see the
supply of the components which is currently requested by PU A and it can see the
actual supply provided by the delivering PUs, B and C. A difference, like in Figure 37,
indicates that expected and actual supply are not in sync and hence the planners of
the three PUs should synchronize their plans.
Page 47
Planning Unit A selected again

PU B
PU A
PL1 P1
DCD: 12
D:
I:
N:
S:
R:
12
00
12
12
12
PL1 C1
PL1 P1 S1
D:
I:
N:
S:
R:
10
0
10
10
10
P: 12
AP:
PU C
PL1 C2
D:
I:
N:
S:
R:
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
R: Total ReceiptsI:
P: Production
AP: Adj. Production
10
0
10
10
10

PC:
Figure 37: Re-planning of PU after demand increased
6.2 S&OP Optimizer

The heuristic infinite / no shortages will always keep the component quantities in
sync. This means that all components will be delivered in exactly that quantity which
is needed to produce a certain amount of the output product, so that there will be no
surplus of one or several components. The reason is that this heuristic will not
consider any constraints limiting the required component quantities. This is different
for the optimizer as it takes into account more limiting constraints which might reduce
the supply of one or several components. In Figure 38 we see a supply plan which
was generated by the optimizer while first PU A, then B and finally C was planned.
PU A requested 10 units of both components to produce the entire demand of 10
units of the output product P1. However, the optimizer could not find a solution so
that both PU B and C satisfy the entire component demand. The supply of
component C1 from PU B is only 8, the supply of component C2 from PU C is only 5
units.
Page 48
Example 4: Selected Planning Unit C (Optimizer)

PU B
PU A
DC1 K1
PL1 P1
DCD: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 P1 S1
D:
I:
N:
S:
R:
P: 10
AP:
PU C
DC1 K2
D:
I:
N:
S:
R:
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
08
00
08
08
08
R: Total ReceiptsI:
P: Production
AP: Adj. Production
05
00
05
05
05

PC:
Figure 38: Possible solution of the optimizer
There are several alternatives how component supplies can be synchronized. One
option is that the planner of PU A sets the minimum component supply in key figure
Adjusted Production as illustrated by Figure 39. This seems to be the best feasible
solution if PU B and C cannot not increase their supply to the requested demand of
10 units. Figure 39 shows the resulting supply plan after PU A was re-planed by the
optimizer based on the value entered in Adjusted Production which enables PU A
to produce and hence to supply only 5 units.
In order to finally synchronize the component supply the planner of PU B would have
to re-plan its Planning Unit as well so that the actual supply of component C1 is
decreased to 5 units which is not yet done in the situation shown by Figure 39.
Page 49
PU A planned by Optimizer with Adjusted Production

PU B
PU A
DC1 K1
PL1 P1
DCD: 05
D:
I:
N:
S:
R:
05
05
05
05
05
PL1 P1 S1
D:
I:
N:
S:
R:
P: 05
AP: 05
08
00
08
08
08
PU C
DC1 K2
D:
I:
N:
S:
R:
05
00
05
05
05
Planner of PU A can set

Adjusted Production = 5
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
R: Total ReceiptsI:
P: Production
AP: Adj. Production

PC:
Figure 39: Re-planning PU A with Adjusted Production
To use the optimizer in the context of production sources with output products and
components belonging to different PUs it is indispensable to populate an additional
cost key figure, the Inter-Planning Unit Receipts Cost Rate. (Technical name is
IPURECEIPTCOSTRATE, key is Product and Location). This key figure represents
the cost of each component for the use case in which only the PU of the output
product is selected to be planned by the optimizer. In this case, the optimizer uses
the values in this key figure as receipts cost of the components. Without these
receipts costs the price of these components would be zero which would not reflect
the reality and might direct the optimizer into a wrong direction. In use cases where
the components belong to the same PU as the output products or in use cases where
all involved PUs are selected (in the example here, if PU A, B and C would be
selected) the optimizer computes the costs of the components internally, based on
their procurement, transportation and production costs.
6.3 Co-Production
When assigning the main output product and co-products to different PUs this
complicates the planning process of production sources as well. Figure 40 shows a
supply plan, computed by the S&OP heuristic for a production source in which the
main output product (P1) belongs to PU A whereas its co-product (CO) belongs to
another planning unit, PU B. Component K1 belongs to PU C
Page 50
Co-Products with different Planning Units

PU C
PU A
PL1 P1
DCD: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 K1
PL1 P1 S1
P:
10
DPD:
10
PC:
10
IPUPC:
D:
I:
N:
S:
R:
PL1 CO S1
P:
10
PU B
PL1 CO
DCD: 05
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
D:
I: 10
N:
S:
R: 10
R:
P:
Total Receipts
Production

PC:
Figure 40: Supply plan generated by heuristic for PU A
Figure 40 shows the supply plan which the heuristic computed after PU A was
selected. The arriving Dependent Customer Demand (of 10 units) for the main output
product P1 causes a Net Demand of 10 which triggers a Production Receipts of 10
(produced by production source S1) and which causes a Dependent Production
Demand (DPD) of 10 units for component K1. The example in Figure 40 is based on
a Production Coefficient of 1:1 between main output and co-product which means
that by producing 10 units of the main output product 10 units of the co-product are
produced as well. These 10 units of the co-product are depicted as Production
Receipts of location product PL1 / CO in the same quantity.
If now PU B, i.e. the PU of the co-product is planned, the heuristic will compute the
plan shown by Figure 41. As the demand for the co-product is 5 units only, the
Production Receipts determined by the main output product covers this demand
excessively so that the remaining quantity builds up a Projected Inventory of 5 units.
Page 51
Result after Planning PU B

PU C
PU A
PL1 P1
DCD: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 K1
PL1 P1 S1
P:
10
DPD:
10
PC:
10
IPUPC:
D:
I:
N:
S:
R:
PL1 CO S1
P:
10
PU B
PL1 CO
DCD: 05
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
D:
I:
N:
S:
R:
R:
P:
05
05
00
05
10
Total Receipts
Production

PC:
Figure 41:Result after Planning PU B
A logical next step would be to plan PU C which delivers component K1. The result is
shown by Figure 42.
Page 52
Result after Planning PU C

PU C
PU A
PL1 P1
DCD: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 K1
PL1 P1 S1
P:
10
DPD:
10
PC:
10
IPUPC: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 CO S1
P:
10
PU B
PL1 CO
DCD: 05
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
D:
I:
N:
S:
R:
R:
P:
05
05
00
05
10
Total Receipts
Production

PC:
Figure 42: Result after planning PU C
If Dependent Customer Demand for the main output product changes (as shown in
Figure 43, from 10 to 7 units), it makes sense to re-plan PU A. Figure 43 shows the
result of the heuristic.
The new resulting Production Receipts are immediately propagated to the co-product
which leads to a lower Projected Inventory (now only 2, before the change it was 5).
The reduced Production Receipts also decreases the Dependent Production
Demand for component K1.
Page 53
Result after Re-Planning PU A

PU C
PU A
PL1 P1
DCD: 07
D:
I:
N:
S:
R:
07
00
07
07
07
PL1 K1
PL1 P1 S1
P:
07
DPD:
07
PC:
07
IPUPC: 10
D:
I:
N:
S:
R:
10
00
10
10
10
PL1 CO S1
P:
07
07
PU B
PL1 CO
DCD: 05
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
D:
I:
N:
S:
R:
R:
P:
05
02
00
05
07
Total Receipts
Production

PC:
Figure 43: Result after Re-Planning PU A
As a reaction to the changed demand of the main output product P1, the other PUs,
i.e. PU B and C should be re-planned as well. The result is depicted by Figure 44.
The demand and supply of component K1 is adapted accordingly, nothing needed to
be changed for the co-product.
Page 54
Result after Re-Planning PU B and C

PU C
PU A
PL1 P1
DCD: 07
D:
I:
N:
S:
R:
07
00
07
07
07
PL1 K1
PL1 P1 S1
P:
07
DPD:
07
PC:
07
IPUPC: 07
D: 07
I: 00
N: 07
S: 07
R: 07
PL1 CO S1
P:
07
PU B
PL1 CO
DCD: 05
D:
I:
N:
S:
Dependent Demand
Projected Inventory
Net Demand
Supply
D:
I:
N:
S:
R:
R:
P:
05
02
00
05
07
Total Receipts
Production

PC:
Figure 44: Supply plan after PU B and C have been re-planned
Page 55

04H Sub Networks

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04H Sub Networks

Uploaded by

Copyright:

Available Formats

Specification for Extensions of S&OP on HANA:

Planning Session within Two Selected Planning Units

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 1: Planning a Selection of two Planning Units

In Figure 1 we see the following flow: a Dependent Customer Demand of 20 is

Inner Border Handshake via Adjusted Transport

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 2: Inner (Border) Handshake via Adjusted Transport

Planning PU A (Supply defined via ATR)

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 3: Planning of PU A only whereas supply is given by key figure ATR

Planning PU A (Supply defined via TR)

Dep. Customer Demand

ATR was blanked

2014 SAP AG. All rights reserved.

Figure 4: Planning PU A only whereas supply is given by key figure Transport

Planning PU A (no Supply defined)

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 5: Planning PU A only whereas no supply is pre-defined by PU B

In such a situation as shown in Figure 5 the planner of PU A might want to set a

Planning of PU A based on IPUTR

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 6: Planning of PU A only based in IPUTR

Planning of PU A based on Excessive Supply

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 7: Planning of PU A only based on an excessive supply

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 8: Planning of PU B only

Example 6: Re-Planning of PU B with Optimizer

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 9: Supply plan of PU B computed with the optimizer

Example 6: Re-Planning of PU B with Optimizer

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 9b: Update of downstream Planning Unit

Planning of PU B: Fixing Supply

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 10: Fixing Supply of PU B

Planning PU A ignoring IPUTR and supply from PU B

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 11: Planning PU A independently of fixed Supply

For the example of Figure 12 it is assumed that the planner of PU B removed

Removing Outer Border Handshake

Dep. Customer Demand

2014 SAP AG. All rights reserved.

PU B fixes Outer Border Handshake

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 13: PU B fixes Outer Border Handshake again

PU A fixes Outer Border Handshake

Dep. Customer Demand

2014 SAP AG. All rights reserved.

Figure 14: Result of the Outer Border Handshake

Planning both PUs again